From owner-freebsd-current@FreeBSD.ORG Sun May 31 01:46:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A335106566B for ; Sun, 31 May 2009 01:46:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 284768FC12 for ; Sun, 31 May 2009 01:46:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAa8S-000Bvr-Hp for current@freebsd.org; Sun, 31 May 2009 01:46:53 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 0EFAC1C3EFF8 for ; Sun, 31 May 2009 10:46:52 +0900 (JST) Date: Sun, 31 May 2009 10:46:51 +0900 Message-ID: From: Randy Bush To: current In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 01:46:53 -0000 > this time it actually said something interesting on console! > > for some values of 'interesting' :) > > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapspace(3): failed > swap_pager_getswapsp > a > lcatale t(ra1p 612): : pafgae ifaullte wdhi > e sin wkearnepl m_odpe > acpugied =r 1_; agpiec itd s= w01a > afasulpt vairtcuael (ad3dre)ss := 0x0f > odfalulet dc > e s =w saupeprv_isopr awgrieter _dagtae, ptagse nowta ppressepnat > 0inest(ru3ct)i:on pfoinateir l= e0dx2 > :0sxfwfaffpff_ffp80a47gc25e6 > rst_acgk eptoinsterw a p s =p 0ax2c8:0exf(3ff)ff:f80 7f9fd1a680i > poieadme > ntserw a p _ =p 0xag28e:0rxf_fffgff8e07t9fsd16we0 > 0xdep ssegpmenta c= beas(e 30x0), :lim itf 0xaffifflf,e tydpe > 1bs > w =a DpPL _0, ppraesg 1,e lorng_ 1g, deef3t2 s0,w garapn s1 > ledaocceseso(r 3ef)la:gs =f ianteirrulpt eendab > , rseswumae, pIOP_L p= a0 > gcuerrren_t pgroecests s = w789a (psysslpogad) > ctreap( n9umb)er: = f12 > epainilc:e pdag > fsauwlta > pcp_uipd =a 1g > eUptime: 9h50m49s > Physical memory: 4083 MB > Dumping 1958 MB: > > a bit better in last night's syslog, possibly during backup randy May 30 00:40:14 work0 kernel: lock order reversal: May 30 00:40:14 work0 kernel: 1st 0xffffff0057d019d0 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 May 30 00:40:14 work0 kernel: 2nd 0xffffff8052c01aa0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2556 May 30 00:40:14 work0 kernel: 3rd 0xffffff0004b8d098 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 May 30 00:40:16 work0 kernel: lock order reversal: May 30 00:40:16 work0 kernel: 1st 0xffffff8052c01aa0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2556 May 30 00:40:16 work0 kernel: 2nd 0xffffff00d35c7d30 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 May 30 00:50:14 work0 kernel: lock order reversal: May 30 00:50:14 work0 kernel: 1st 0xffffff00d35c7d30 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:297 May 30 00:50:14 work0 kernel: 2nd 0xffffff0057d019d May 30 00:50:14 work0 kernel: 0 ufs (ufs) @ /u May 30 00:50:14 work0 kernel: s May 30 00:50:15 work0 kernel: r/src/sys/ May 30 00:50:15 work0 kernel: ufs/ffs/ May 30 00:50:15 work0 kernel: ffs_snap May 30 00:50:15 work0 kernel: shot.c: May 30 00:50:15 work0 kernel: 1587 May 30 01:45:21 work0 kernel: May 30 01:45:21 work0 kernel: May 30 01:45:21 work0 kernel: Fatal trap 12: page fault while in kernel mode May 30 01:45:21 work0 kernel: cpuid = 0; apic id = 00 May 30 01:45:21 work0 kernel: fault virtual address = 0x0 May 30 01:45:21 work0 kernel: fault code = supervisor write data, page not present May 30 01:45:21 work0 kernel: instruction pointer = 0x20:0xffffffff8047c256 May 30 01:45:21 work0 kernel: sta May 30 01:45:21 work0 kernel: c May 30 01:45:21 work0 kernel: k pointer = 0x28:0xffffff807a057680 May 30 01:45:21 work0 kernel: frame pointer = 0x28:0xffffff807a0576e0 May 30 01:45:21 work0 kernel: code segment = base 0x0, limit 0xfffff, type 0x1b May 30 01:45:21 work0 kernel: = DPL 0, pres 1, long 1, def32 0, gran May 30 01:45:21 work0 kernel: 1 May 30 01:45:21 work0 kernel: processor eflags = interrup May 30 01:45:21 work0 kernel: t enabled, resume, May 30 01:45:21 work0 kernel: IOPL = 0 May 30 01:45:21 work0 kernel: current process May 30 01:45:21 work0 kernel: = 9181 (nfcapd) May 30 02:10:04 work0 syslogd: kernel boot file is /boot/kernel/kernel -30- From owner-freebsd-current@FreeBSD.ORG Sun May 31 01:51:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15D18106566C for ; Sun, 31 May 2009 01:51:32 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id DA4188FC19 for ; Sun, 31 May 2009 01:51:31 +0000 (UTC) (envelope-from ler@lerctr.org) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Received:Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:Importance:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=GIPRM4ZHIHcSYVMss5TnUp4/UTBOnaP9Sr4hZbYy8aLI5xM1g/vVPALe48nXS2nNszohHqdYO5D+Easl8wt+2hu7GMMr2HYfBRKUd/omY/BkC9kOAYcP0lAbi/mdN720VzPrD+DhliH9gJqcGky4Ocl2sK6jp/d+2bUJGWS+WFQ=; Received: from localhost.lerctr.org ([127.0.0.1]:61441 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAaCv-000AP5-Pb; Sat, 30 May 2009 20:51:31 -0500 Received: from 76.205.169.61 (SquirrelMail authenticated user ler) by webmail.lerctr.org with HTTP; Sat, 30 May 2009 20:51:29 -0500 Message-ID: In-Reply-To: References: Date: Sat, 30 May 2009 20:51:29 -0500 From: "Larry Rosenman" To: "Randy Bush" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -3.1 (---) X-LERCTR-Spam-Score: -3.1 (---) X-Spam-Report: SpamScore (-3.1/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, TW_CG=0.077, TW_PL=0.077, TW_YD=0.077 X-LERCTR-Spam-Report: SpamScore (-3.1/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, FM_MULTI_ODD2=1.1, TW_CG=0.077, TW_PL=0.077, TW_YD=0.077 DomainKey-Status: no signature Cc: current Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 01:51:32 -0000 On Sat, May 30, 2009 8:46 pm, Randy Bush wrote: >> this time it actually said something interesting on console! >> >> for some values of 'interesting' :) >> >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapspace(3): failed >> swap_pager_getswapsp >> a >> lcatale t(ra1p 612): : pafgae ifaullte wdhi >> e sin wkearnepl m_odpe >> acpugied =r 1_; agpiec itd s= w01a >> afasulpt vairtcuael (ad3dre)ss := 0x0f >> odfalulet dc >> e s =w saupeprv_isopr awgrieter _dagtae, ptagse nowta >> ppressepnat >> 0inest(ru3ct)i:on pfoinateir l= e0dx2 >> :0sxfwfaffpff_ffp80a47gc25e6 >> rst_acgk eptoinsterw a p s =p 0ax2c8:0exf(3ff)ff:f80 7f9fd1a680i >> poieadme >> ntserw a p _ =p 0xag28e:0rxf_fffgff8e07t9fsd16we0 >> 0xdep ssegpmenta c= beas(e 30x0), :lim itf 0xaffifflf,e >> tydpe >> 1bs >> w =a DpPL _0, ppraesg 1,e lorng_ 1g, deef3t2 s0,w >> garapn s1 >> ledaocceseso(r 3ef)la:gs =f ianteirrulpt eendab >> , rseswumae, pIOP_L p= a0 >> gcuerrren_t pgroecests s = w789a (psysslpogad) >> ctreap( n9umb)er: = f12 >> epainilc:e pdag >> fsauwlta >> pcp_uipd =a 1g >> eUptime: 9h50m49s >> Physical memory: 4083 MB >> Dumping 1958 MB: >> >> > > a bit better in last night's syslog, possibly during backup > > randy > > > May 30 00:40:14 work0 kernel: lock order reversal: > May 30 00:40:14 work0 kernel: 1st 0xffffff0057d019d0 ufs (ufs) @ > /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 > May 30 00:40:14 work0 kernel: 2nd 0xffffff8052c01aa0 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:2556 > May 30 00:40:14 work0 kernel: 3rd 0xffffff0004b8d098 ufs (ufs) @ > /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 > May 30 00:40:16 work0 kernel: lock order reversal: > May 30 00:40:16 work0 kernel: 1st 0xffffff8052c01aa0 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:2556 > May 30 00:40:16 work0 kernel: 2nd 0xffffff00d35c7d30 snaplk (snaplk) @ > /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 > May 30 00:50:14 work0 kernel: lock order reversal: > May 30 00:50:14 work0 kernel: 1st 0xffffff00d35c7d30 snaplk (snaplk) @ > /usr/src/sys/kern/vfs_vnops.c:297 > May 30 00:50:14 work0 kernel: 2nd 0xffffff0057d019d > May 30 00:50:14 work0 kernel: 0 ufs (ufs) @ /u > May 30 00:50:14 work0 kernel: s > May 30 00:50:15 work0 kernel: r/src/sys/ > May 30 00:50:15 work0 kernel: ufs/ffs/ > May 30 00:50:15 work0 kernel: ffs_snap > May 30 00:50:15 work0 kernel: shot.c: > May 30 00:50:15 work0 kernel: 1587 > May 30 01:45:21 work0 kernel: > May 30 01:45:21 work0 kernel: > May 30 01:45:21 work0 kernel: Fatal trap 12: page fault while in kernel > mode > May 30 01:45:21 work0 kernel: cpuid = 0; apic id = 00 > May 30 01:45:21 work0 kernel: fault virtual address = 0x0 > May 30 01:45:21 work0 kernel: fault code = supervisor write data, page > not present > May 30 01:45:21 work0 kernel: instruction pointer = > 0x20:0xffffffff8047c256 > May 30 01:45:21 work0 kernel: sta > May 30 01:45:21 work0 kernel: c > May 30 01:45:21 work0 kernel: k pointer = 0x28:0xffffff807a057680 > May 30 01:45:21 work0 kernel: frame pointer = > 0x28:0xffffff807a0576e0 > May 30 01:45:21 work0 kernel: code segment = base 0x0, limit 0xfffff, > type 0x1b > May 30 01:45:21 work0 kernel: = DPL 0, pres 1, long 1, def32 0, gran > May 30 01:45:21 work0 kernel: 1 > May 30 01:45:21 work0 kernel: processor eflags = interrup > May 30 01:45:21 work0 kernel: t enabled, resume, > May 30 01:45:21 work0 kernel: IOPL = 0 > May 30 01:45:21 work0 kernel: current process > May 30 01:45:21 work0 kernel: = 9181 (nfcapd) > May 30 02:10:04 work0 syslogd: kernel boot file is /boot/kernel/kernel See Kip's replies in my ZFS Crash thread. I suspect you have compression turned on in ZFS, and there is an unbounded allocation of memory in the ZFS (de)compression code. Kip is working on a patch to put some bounds on it. I've changed my tunables to not allow the ARC to grab ALL of physmem (vfs.zfs.arc_max) and testing a full backup now. Waiting, patiently, for code patch from Kip. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Sun May 31 01:53:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B542106567A for ; Sun, 31 May 2009 01:53:07 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCF58FC13 for ; Sun, 31 May 2009 01:53:07 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAaEU-000Bx2-7q; Sun, 31 May 2009 01:53:06 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id AA7181C3F768; Sun, 31 May 2009 10:53:05 +0900 (JST) Date: Sun, 31 May 2009 10:53:05 +0900 Message-ID: From: Randy Bush To: "Larry Rosenman" In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 01:53:07 -0000 > I suspect you have compression turned on in ZFS for the third time, i do not. randy From owner-freebsd-current@FreeBSD.ORG Sun May 31 02:50:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B267106564A for ; Sun, 31 May 2009 02:50:38 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id F2EF38FC18 for ; Sun, 31 May 2009 02:50:37 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n4V2oF5c073447; Sat, 30 May 2009 19:50:16 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 8x8y68en4cw8r2k6yuiw9eb3tn; Sat, 30 May 2009 19:50:15 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A21F067.6000202@freebsd.org> Date: Sat, 30 May 2009 19:50:15 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: Mel Flynn References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <4A20D97B.1030609@freebsd.org> <20090530070306.GQ48776@hoeg.nl> <200905301224.40156.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200905301224.40156.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , freebsd-current@freebsd.org Subject: Re: Linking with libarchive fails (Was: Re: buildworld fails.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 02:50:38 -0000 Mel Flynn wrote: > On Saturday 30 May 2009 09:03:06 Ed Schouten wrote: >> * Tim Kientzle wrote: >>> You need: LDADD=-larchive -lmd -lcrypto >>> >>> One of the formats supported by libarchive has recently >>> gained support for some cryptographic extensions which >>> rely on the 'md' and 'crypto' libraries. >> Can't this be solved by linking libarchive to libmd and libcrypto? That >> way you don't have to link against those libraries explicitly. > > On a related note I find it illogical that SHA385/SHA512 is not in libmd while > 256 and lower are. Is this a legal thing or infrastructure? Don't know. Looks like OpenBSD has SHA384 and SHA512 in their standard libraries, so we should be able to crib from there. I don't know the legal issues, though. Tim From owner-freebsd-current@FreeBSD.ORG Sun May 31 03:44:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5F6106564A for ; Sun, 31 May 2009 03:44:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 29A208FC0A for ; Sun, 31 May 2009 03:44:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAbyk-000C6o-Hc for current@freebsd.org; Sun, 31 May 2009 03:44:58 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 09D741C479C0 for ; Sun, 31 May 2009 12:44:58 +0900 (JST) Date: Sun, 31 May 2009 12:44:57 +0900 Message-ID: From: Randy Bush To: FreeBSD Current In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: yakpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 03:44:59 -0000 and one more, this from serial console Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8047c1da stack pointer = 0x28:0xffffff807a156630 frame pointer = 0x28:0xffffff807a1566f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1385 (nfcapd) trap number = 12 panic: page fault cpuid = 0 due to when it happens, about 01:50 when there are no cron jobs or anything obvious, i am suspecting this is not the same as kern/134011 it did not leave a dump. and i could not force one as it required a power cycle to get the box's attention. nfcapd is a flow data capture from a couple of lighly loaded (10-20Mbps) routers. randy --- and no, i am not using zfs compression From owner-freebsd-current@FreeBSD.ORG Sun May 31 03:26:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD4651065674 for ; Sun, 31 May 2009 03:26:15 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: from web39108.mail.mud.yahoo.com (web39108.mail.mud.yahoo.com [209.191.87.227]) by mx1.freebsd.org (Postfix) with SMTP id 6B9DD8FC0C for ; Sun, 31 May 2009 03:26:15 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: (qmail 1422 invoked by uid 60001); 31 May 2009 02:59:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243738772; bh=0vI5JqEODa/FQGs0jTqyCL4MPvBkjJFeRRRLqXKRRYc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=ILYxE6RszyykQpDOPfAHvIYx59wVlHwbLF/byDC3Otk744Imq7xvmQffClPneSPptgGJ5ZGPaNk0ZFDBDSpPGQuMcRBjz8mP4zKE4Zy9GHBsg/1dxOra/EflT5WAkMow4VWmLrUOWCaIr07McxWuWZnCSENQOIWKcjhvdHry92w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Sf6WbYn9z/Adv3Y/V7ZMy6EhjQK7NgqmA6Jwx2a5EP2ieoT5jCXKBEvMACwxJUQlrq9fuNG+H2l508ThIpXOUejNUwrfBPC2cUud1LQpQkLJJ3EMub0fTppjlWDfUrzN8lT3pGz1fVSmeOKQMsYl7Vl0XuGwRdfanpdF3qFtR6U=; Message-ID: <951233.95131.qm@web39108.mail.mud.yahoo.com> X-YMail-OSG: K3TnU4QVM1kglo4GGdSougEZYuQI1iHHE.MPOsvG54BqrlSFaym9vPz__PBY3tSPXGu5y0bDQmn.Ob4u5biSWGZm5VqnFsu0gyEvUEsH5.S4AXTdu6AaTqtqf5wwZFYHkabVc2VmZ75jF08X4g6p.KmCXJTfyx2qxG5N7cGU87t5xBg8BBNRvLfjgP_vQgpItN3VW4BollJJWtboDPXxgCXwRfpgUqq3nkn.HviMKHWyIRqJJNWgc_COnLG57ACb1vu0VuqQUf_nXmWiEi01UamRsxl.PUDNdyfB.ioxbbsKNJ5WSVERT3Jxdll9WdmuhqEZMUNM Received: from [87.118.104.203] by web39108.mail.mud.yahoo.com via HTTP; Sat, 30 May 2009 19:59:32 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Sat, 30 May 2009 19:59:32 -0700 (PDT) From: bf To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 31 May 2009 03:52:50 +0000 Cc: attilio@FreeBSD.org, ohartman@mail.zedat.fu-berlin.de Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 03:26:16 -0000 >2009/5/30 Attilio Rao : >> 2009/5/30 O. Hartmann : >>> Attilio Rao wrote: >>>> 2009/5/30 O. Hartmann : >>>> >>>>> Hello. >>>>> I realized a significant slowdown of FreeBSD 8.0-CURRENT/amd64 on every >>>>> box I run. I have the most recent FreeBSD 8.0-CURRENT/amd64 with custom >>>>> kernel and switched off every debugging. I see a drastic slowdown >>>>> whenever heavy I/O on UFS2 and ZFS partitions is performed and whenever >>>>> some compilation is done (compiling world and kernel). ... >Also, did you compile the single-core athlon64 without the option SMP? > >Thanks, >Attilio I'm running the r193133 amd64 with a custom kernel and all debugging off on an AMD Athlon64 3400+ single-core, and I haven't noticed any significant slowing, although I haven't been doing any systematic benchmarking. What would be the penalties of running an SMP -CURRENT kernel on single-core hardware with no hyperthreading? Can anyone quantify the typical added overhead? Or, counterintuitively, would an SMP kernel be better in some ways? Regards, b. From owner-freebsd-current@FreeBSD.ORG Sun May 31 03:55:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99E34106566C; Sun, 31 May 2009 03:55:22 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 36B118FC0C; Sun, 31 May 2009 03:55:21 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so3691350ywe.13 for ; Sat, 30 May 2009 20:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=1MltuZKN4yjeAEcteP6FvknHBWAKclV6TLI8xHhE4Ds=; b=euOzr+dKzFGXikSBjrGNFEAL+3kFUQ+35ktxCRtWqTxIoWaT0mLwy4PMCjAvR+++w0 TViDsEK6I0SGEM8ZhK5jj5XZjGgkLvOiQLmTJcGghHhrLc3K56gT5sWRpissqnxueMII BUS+5R9+HmSQBxebroIluMa6zu7xwGlyul/eA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L8qDLOsDJIkDQ/IWKcoxgAspxD3IzK6diqO8iBF7UZBJX96cga4LliLQ7KVpSpvYrH 8ojgx7b4FxMw+BbTthg8s18COl8SInnF7FygnpcV3Z64Jg0UFHzSLJn1vIucmTLXjy03 Oj0htSdybTU2e2zlxfiat/IdPnF5jm0yJ4pKI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.154.17 with SMTP id b17mr5723386ane.45.1243742121430; Sat, 30 May 2009 20:55:21 -0700 (PDT) In-Reply-To: <951233.95131.qm@web39108.mail.mud.yahoo.com> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> Date: Sat, 30 May 2009 20:55:21 -0700 X-Google-Sender-Auth: 648ec9cd2455da07 Message-ID: <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> From: Kip Macy To: bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, ohartman@mail.zedat.fu-berlin.de, freebsd-current@freebsd.org Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 03:55:22 -0000 > > I'm running the r193133 amd64 with a custom kernel and all debugging off > on an AMD Athlon64 3400+ single-core, and I haven't noticed any significa= nt > slowing, although I haven't been doing any systematic benchmarking. > > What would be the penalties of running an SMP -CURRENT kernel on > single-core hardware with no hyperthreading? Can anyone quantify the > typical added overhead? =A0Or, counterintuitively, would an SMP kernel > be better in some ways? > He is trying to diagnose if the problem was introduced by enabling adaptive spinning on sx locks. They're only enabled on SMP kernels. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Sun May 31 04:12:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B164D106566B for ; Sun, 31 May 2009 04:12:56 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: from web39108.mail.mud.yahoo.com (web39108.mail.mud.yahoo.com [209.191.87.227]) by mx1.freebsd.org (Postfix) with SMTP id 70E738FC16 for ; Sun, 31 May 2009 04:12:56 +0000 (UTC) (envelope-from bf2006a@yahoo.com) Received: (qmail 47610 invoked by uid 60001); 31 May 2009 04:12:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1243743176; bh=8JNMLZbOpJdmwmsq7t19mODiVdg802oelMuCf+u6YWU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q97csoGEJtRSHoLNBbuapniS2t2h/ZiQmRJFPybMoPFSePW/J3chonKtXqU+6wzJHpbD/ebcJ/fQvC1bH4o1AEtFR+sjJnOtjFqUGJEKF/DeTZ8YnahIfI7zS7/7wwdVoCQdEu7MkIOxCcUCymGJ+8J7p95qtvUt6g0nCHkILhY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=U3ZUX745EJaB6JxI5TCt8gbfJd+73bXGtJ8t0qdVepwY72ggBkmdkvmOUI6/raSeVDWdatMLqNK4bLPVJ1dg9+sVvc2HBkd4t/lUfVLOgblFYmWdUxLwsOdK+dt97D+iXQGIhQiiSY9ZBxYXWz+bxcEEMGRZjjylj2WrQLyK1h8=; Message-ID: <15091.46749.qm@web39108.mail.mud.yahoo.com> X-YMail-OSG: xR5qX08VM1lZYn4DiANOdo6008d.yx8.0Jli6OhJeRsjUqpx0NbGvCNBOotJB5VPyAKUowwR5rGRxB73kMXERxSmBpkrAAIKcYas7yAyPBBquVFfiriCJfafsOPz_zXAZewAue4qNJKX5pzwE_9PwDagxW5FKwSYhcNnmyuKxSXFNeJQ8ThE5PGSMa2wodpuaHLOm2fFRxK3IlHiyJj8mQq5ed1ThA5fivvGTBd5bEfVm2YhNXN7O598XE3EmMmAsADNyoNhBr3izFXb42ixy3QpZ3OevBr4YVAL_JD.MEN7lqEyqhe3MzBnq_8P1FE3Fnx8jGU- Received: from [94.76.247.138] by web39108.mail.mud.yahoo.com via HTTP; Sat, 30 May 2009 21:12:55 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.10 Date: Sat, 30 May 2009 21:12:55 -0700 (PDT) From: bf To: Kip Macy MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 31 May 2009 05:10:29 +0000 Cc: attilio@freebsd.org, ohartman@mail.zedat.fu-berlin.de, freebsd-current@freebsd.org Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 04:12:56 -0000 --- On Sat, 5/30/09, Kip Macy wrote: > From: Kip Macy > Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 > To: "bf" > Cc: freebsd-current@freebsd.org, attilio@freebsd.org, ohartman@mail.zedat= .fu-berlin.de > Date: Saturday, May 30, 2009, 11:55 PM > > > > I'm running the r193133 amd64 with a custom kernel and > all debugging off > > on an AMD Athlon64 3400+ single-core, and I haven't > noticed any significant > > slowing, although I haven't been doing any systematic > benchmarking. > > > > What would be the penalties of running an SMP -CURRENT > kernel on > > single-core hardware with no hyperthreading? Can > anyone quantify the > > typical added overhead? =A0Or, counterintuitively, > would an SMP kernel > > be better in some ways? > > >=20 > He is trying to diagnose if the problem was introduced by > enabling > adaptive spinning on sx locks. They're only enabled on SMP > kernels. >=20 > Cheers, > Kip >=20 So I inferred from his request to have Oliver (the original poster) revert r193011. But it seems unlikely that this is solely or even mostly responsible for the slowdown, as Oliver reported that it first began to occur several weeks ago, and Attilio only committed r193011 on Friday -- unless Oliver independently added ADAPTIVE_SX to his custom kernel a few weeks ago. In any event, I'm still interested in any reports of the relative performance of SMP vs. UP kernels on UP hardware that=20 anyone is able to share. Thanks, b.=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:08:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03E67106566B for ; Sun, 31 May 2009 06:08:55 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id CC64D8FC0A for ; Sun, 31 May 2009 06:08:54 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 1D88E71F42E; Sun, 31 May 2009 02:08:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdjqgeKiqiLZ; Sun, 31 May 2009 02:08:53 -0400 (EDT) Received: from [10.0.0.248] (c-24-56-252-57.customer.broadstripe.net [24.56.252.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id B41A971F42A; Sun, 31 May 2009 02:08:53 -0400 (EDT) Message-ID: <4A221EF2.6010607@egr.msu.edu> Date: Sun, 31 May 2009 02:08:50 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090418) MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current , Larry Rosenman Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:08:55 -0000 Randy Bush wrote: >> I suspect you have compression turned on in ZFS >> > > for the third time, i do not. > > randy > _______________________________________________ > 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" > > Do you have vfs.zfs.mdcomp_disable enabled and was it enabled before creating much of your files? It might fall under the same bucket if you have lots of files perhaps. From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:12:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BB07106566C for ; Sun, 31 May 2009 06:12:43 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id E47988FC15 for ; Sun, 31 May 2009 06:12:42 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so3616972yxb.13 for ; Sat, 30 May 2009 23:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=u5F5bRbgFYpjasw/bBDSwXFwkArlEsGA5ViDB4f9nw4=; b=uaIDXMKC0tMzIToc5YQUXxCLHMr8q+z6KaoqZr16X1CM+D1DieXcthF34uTiIk8jj6 sS+f8qBnFNTcxBn2ylFarYk1Ti62gHDK/uGOtMcUlxLuyT+MwOp+ytSryWelIKUUsWVz qYnB66NajR3i9Awd1iYPHuoRyfEGz1Opx2RyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y9BCvCL2c/d9yS5voU51fJiINHciF4vMi6koMZ8ROMqeWaFxReCOd2Eep0ooYAdjaq XLi1dQDH6C8nqCXzOWMtR97v2xuhHRh2zeRKtEbhYvj1+Zb3hES562dIc7tAK+bqf8jt jD+6bqy1sfp/O3v/dQNZVM073Nd4YCIbFQnTY= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.105.15 with SMTP id d15mr5558397anc.140.1243750362317; Sat, 30 May 2009 23:12:42 -0700 (PDT) In-Reply-To: <4A221EF2.6010607@egr.msu.edu> References: <4A221EF2.6010607@egr.msu.edu> Date: Sat, 30 May 2009 23:12:42 -0700 X-Google-Sender-Auth: 8e31da3fdc2f38ec Message-ID: <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> From: Kip Macy To: Adam McDougall Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randy Bush , current , Larry Rosenman Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:12:43 -0000 This isn't unique to ZFS. On Sat, May 30, 2009 at 11:08 PM, Adam McDougall wro= te: > Randy Bush wrote: >>> >>> I suspect you have compression turned on in ZFS >>> >> >> for the third time, i do not. >> >> randy >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> >> > > Do you have vfs.zfs.mdcomp_disable enabled and was it enabled before > creating much of your files? =A0It might fall under the same bucket if yo= u > have lots of files perhaps. > _______________________________________________ > 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 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:22:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3209A106566C for ; Sun, 31 May 2009 06:22:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 0DABF8FC12 for ; Sun, 31 May 2009 06:22:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAeRL-000CKP-Kq; Sun, 31 May 2009 06:22:39 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 1F6801C5681B; Sun, 31 May 2009 15:22:39 +0900 (JST) Date: Sun, 31 May 2009 15:22:38 +0900 Message-ID: From: Randy Bush To: Adam McDougall In-Reply-To: <4A221EF2.6010607@egr.msu.edu> References: <4A221EF2.6010607@egr.msu.edu> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current , Larry Rosenman Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:22:41 -0000 > Do you have vfs.zfs.mdcomp_disable enabled nope > and was it enabled before creating much of your files? nope do i want to? From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:27:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4782C106564A for ; Sun, 31 May 2009 06:27:00 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2725F8FC15 for ; Sun, 31 May 2009 06:27:00 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAeVW-000CL5-SG; Sun, 31 May 2009 06:26:59 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 59F681C56E24; Sun, 31 May 2009 15:26:58 +0900 (JST) Date: Sun, 31 May 2009 15:26:58 +0900 Message-ID: From: Randy Bush To: Kip Macy In-Reply-To: <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Adam McDougall , current , Larry Rosenman Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:27:00 -0000 > This isn't unique to ZFS. >>>> I suspect you have compression turned on in ZFS >>> for the third time, i do not. >> Do you have vfs.zfs.mdcomp_disable enabled and was it enabled before >> creating much of your files? =A0It might fall under the same bucket if y= ou >> have lots of files perhaps. kip, you'll notice i have another message out there with a different $subject, yakpf. i am beginning to suspect that i have two separate proble= ms. the other one may or may not be zfs related, it has only happened just this way on the amd64 zfs system. the OTHER problem, possibly not kern/134011 Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x0 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff8047c1da stack pointer =3D 0x28:0xffffff807a156630 frame pointer =3D 0x28:0xffffff807a1566f0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 1385 (nfcapd) trap number =3D 12 panic: page fault cpuid =3D 0 randy From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:27:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A26106564A; Sun, 31 May 2009 06:27:23 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2BE458FC22; Sun, 31 May 2009 06:27:22 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4V4AVdM009714; Sun, 31 May 2009 14:10:31 +1000 Received: from [114.76.235.20] (c114-76-235-20.farfl3.nsw.optusnet.com.au [114.76.235.20]) (authenticated sender horst.burkhardt) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n4V4ARfW031327; Sun, 31 May 2009 14:10:29 +1000 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: Tim Kientzle In-Reply-To: <4A21F067.6000202@freebsd.org> References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <4A20D97B.1030609@freebsd.org> <20090530070306.GQ48776@hoeg.nl> <200905301224.40156.mel.flynn+fbsd.current@mailing.thruhere.net> <4A21F067.6000202@freebsd.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-j+MFYHVrTJL6TNkTTo0l" Date: Sun, 31 May 2009 14:10:36 +1000 Message-Id: <1243743036.16061.17.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 Cc: current@freebsd.org Subject: Re: Linking with libarchive fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:27:23 -0000 --=-j+MFYHVrTJL6TNkTTo0l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-05-30 at 19:50 -0700, Tim Kientzle wrote: > Don't know. Looks like OpenBSD has SHA384 and SHA512 > in their standard libraries, so we should be able > to crib from there. >=20 > I don't know the legal issues, though. Caveat Emptor: IANAL. As I understand it, the master servers are in Canada, meaning export cryptography restrictions aren't applicable. If that's your concern, then basically your answer is it's perfectly safe to go ahead.=20 (Then again, I may be thinking of the OpenBSD project servers...) =20 Licencing would almost certainly NOT be an issue. If deRaadt has an issue then we'd soon know I'm sure ;) --- --- Just as an aside, are you guys still not supporting lzma in bsdtar? Because if the reasons are the same as the last time I got in touch with you, this may interest you...=20 -rw-r--r-- 1 root root 15K Mar 12 23:09 /usr/lib/liblzmadec.a -rw-r--r-- 1 root root 809 Mar 12 23:09 /usr/lib/liblzmadec.la lrwxrwxrwx 1 root root 19 Mar 12 23:10 /usr/lib/liblzmadec.so -> liblzmadec.so.0.0.0* lrwxrwxrwx 1 root root 19 Mar 12 23:10 /usr/lib/liblzmadec.so.0 -> liblzmadec.so.0.0.0* -rwxr-xr-x 1 root root 14K Mar 12 23:09 /usr/lib/liblzmadec.so.0.0.0* meaning there is now a library you can dynamically link to at least for the purposes of decompression. --- --- -- Horst. --=-j+MFYHVrTJL6TNkTTo0l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkoiAzwACgkQRtTtv0BbTe7jhQCgtGeyhOcv9+kaapg8bYLeinao Sk8AoIxPotPdUgmF7wFZCf0NA/lreUiM =siGw -----END PGP SIGNATURE----- --=-j+MFYHVrTJL6TNkTTo0l-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:45:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E591065673 for ; Sun, 31 May 2009 06:45:18 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 985D28FC18 for ; Sun, 31 May 2009 06:45:18 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id EB9ADCC9; Sun, 31 May 2009 02:45:17 -0400 (EDT) Received: from localhost ([127.0.0.1]:28743 helo=ichotolot.servalan.com) by servalan.servalan.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAePV-0004Mm-D3 for freebsd-current@freebsd.org; Sun, 31 May 2009 01:20:45 -0500 To: freebsd-current@freebsd.org Date: Sun, 31 May 2009 01:20:45 -0500 From: Richard Todd Message-Id: <20090531064517.EB9ADCC9@mx1.synetsystems.com> Subject: Bug in recent large_alloc changes to the ZFS zio code? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:45:19 -0000 Okay, I'm looking at the recent changes in the ZFS zio code to change how data buffers are allocated (svn r192207). The old code for zio_data_buf_alloc just called kmem_alloc (the Solaris compatibility one), which in turn called malloc() with M_WAITOK, so it would always be guaranteed of getting a valid, non-null pointer. Fair enough. The new code has an alternate code path, where in "arc_large_memory_enabled" mode, it calls the new function zio_large_malloc instead. zio_large_malloc in turn tries a few times to allocate the required pages using vm_phys_alloc_contig, but if that fails goes ahead and returns NULL. Here's the problem. As near as I can tell, none of the code that calls zio_data_buf_alloc appears to check for the possibility that the returned pointer could be NULL, which I guess is reasonable as the original code never could return NULL. However, the new large malloc code *can* return NULL, which causes the obvious problem. The other day I mentioned here a panic I saw where under sufficiently heavy load the GEOM code was complaining that it had been given a NULL data pointer. It seems to me that that was likely because zio had tried to allocate a data buffer and gotten a NULL pointer instead. From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:54:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73AE106564A for ; Sun, 31 May 2009 06:54:47 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7508FC13 for ; Sun, 31 May 2009 06:54:47 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so3692474ana.13 for ; Sat, 30 May 2009 23:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/jq+x5HVCLMDsiwYsKBuZDsENJMR0oEFQ7tsuXzExcg=; b=N86E6gRx1EwJkLWWdYhI9LPcFVwICLnaU/IP9rWm3biF6R8+w/RGZTrRIx630KFjfb rJvubA5yWzIR9PdN5KdKjvBuA0B76m0X88KAu7rmeoyTxQGcqWQcYfAiRjnCmHsb02Jg CUPM17atYlGJ4DvFFp6qWohHZjfcLgzWuwSaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nYUCUVCutvyGMjsqxQvh20sACfYn3sjqkKkUEguyrsZIkio1VCXHabJCl42RC5OmKQ lPCBBmP/kBfB0zib9evgoXJxBuW2VA3230GLdqyMjTVM97lThXjmdeZeAGD00UbVE9BI eFF9Zw7JDkjDtxnD80tztvEwlyQ8rWyCNUesk= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.105.15 with SMTP id d15mr5577460anc.140.1243752887036; Sat, 30 May 2009 23:54:47 -0700 (PDT) In-Reply-To: <20090531064517.EB9ADCC9@mx1.synetsystems.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> Date: Sat, 30 May 2009 23:54:47 -0700 X-Google-Sender-Auth: 6bdf777d2fb698aa Message-ID: <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> From: Kip Macy To: Richard Todd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Bug in recent large_alloc changes to the ZFS zio code? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 06:54:48 -0000 http://svn.freebsd.org/changeset/base/192360 On Sat, May 30, 2009 at 11:20 PM, Richard Todd wrote: > Okay, I'm looking at the recent changes in the ZFS zio code to change how > data buffers are allocated (svn r192207). =A0The old code for > zio_data_buf_alloc just called kmem_alloc (the Solaris compatibility > one), which in turn called malloc() with M_WAITOK, so it would always > be guaranteed of getting a valid, non-null pointer. =A0Fair enough. > The new code has an alternate code path, where in "arc_large_memory_enabl= ed" > mode, it calls the new function zio_large_malloc instead. =A0zio_large_ma= lloc > in turn tries a few times to allocate the required pages using > vm_phys_alloc_contig, but if that fails goes ahead and returns NULL. > > Here's the problem. =A0As near as I can tell, none of the code that calls > zio_data_buf_alloc appears to check for the possibility that the > returned pointer could be NULL, which I guess is reasonable as the origin= al > code never could return NULL. =A0However, the new large malloc code *can*= return > NULL, which causes the obvious problem. =A0The other day I mentioned here= a > panic I saw where under sufficiently heavy load the GEOM code was > complaining that it had been given a NULL data pointer. =A0It seems to me= that > that was likely because zio had tried to allocate a data buffer and gotte= n > a NULL pointer instead. > > > > _______________________________________________ > 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 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Sun May 31 07:14:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3209A1065689 for ; Sun, 31 May 2009 07:14:04 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 017228FC2C for ; Sun, 31 May 2009 07:14:03 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n4V6ioto075355; Sat, 30 May 2009 23:44:50 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 7jnsg5kt2b9jazkzryv65255kw; Sat, 30 May 2009 23:44:50 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A222762.4040505@freebsd.org> Date: Sat, 30 May 2009 23:44:50 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090409 SeaMonkey/1.1.15 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= References: <57200BF94E69E54880C9BB1AF714BBCB5DE72E@w2003s01.double-l.local> <4A20D97B.1030609@freebsd.org> <20090530070306.GQ48776@hoeg.nl> <200905301224.40156.mel.flynn+fbsd.current@mailing.thruhere.net> <4A21F067.6000202@freebsd.org> <1243743036.16061.17.camel@horst-tla> In-Reply-To: <1243743036.16061.17.camel@horst-tla> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: lzma and bsdtar X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 07:14:04 -0000 Horst Günther Burkhardt III wrote: > > Just as an aside, are you guys still not supporting lzma in bsdtar? bsdtar in -CURRENT does support lzma and xz compression and decompression by feeding the data through the external lzma, unlzma, xz, and unxz command-line programs. This only works if you have those programs installed from the archivers/lzmautils-devel port, of course, and it's significantly slower than using the library support. There is an option in libarchive to compile against the liblzma library for direct support of these formats. Of course, that requires you to have the libraries installed first (from archivers/lzmautils-devel port) and then recompiling libarchive. (See comments in /usr/src/lib/libarchive/Makefile for how to turn on the liblzma support.) I would like to import liblzma (not liblzmadec) into the FreeBSD base system. Liblzma is generously licensed and supports both writing and reading and also supports the newer "xz" file format. Once that is done, we can turn on the full libarchive/bsdtar support for lzma/xz by default. I don't have time to work on this right now, unfortunately. Tim From owner-freebsd-current@FreeBSD.ORG Sun May 31 08:05:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A160110656C7 for ; Sun, 31 May 2009 08:05:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA588FC12 for ; Sun, 31 May 2009 08:05:21 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=yvZruqbWXv0A:10 a=xODBgVONFsUA:10 a=s3GZ4sBfdV5ZOj9QIVMA:9 a=4AN2s5NgUAAQgFT3Jt4A:7 a=-uaPUWrekuNEggOJxOd7qI9u0WEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1248598301; Sun, 31 May 2009 10:05:20 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 31 May 2009 10:09:26 +0200 User-Agent: KMail/1.9.7 References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <4A2173A7.3090100@omnilan.de> In-Reply-To: <4A2173A7.3090100@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905311009.27818.hselasky@c2i.net> Cc: Harald Schmalzbauer Subject: Re: USB (internally fixed) card reader questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 08:05:23 -0000 On Saturday 30 May 2009, Harald Schmalzbauer wrote: > Hans Petter Selasky schrieb am 30.05.2009 12:03 (localtime): > ... > > > If recompiling hald and checking that libusb is up to date, > > see /usr/src/lib/libusb, does not solve your problem, then write me some > > text about how to get going using usbconfig, and I will add it as a > > workaround FAQ for USB flash cards. > > After updating to todays -current and all ports (including hal), I can > again use the `true > /dev/da0` trick and with the second insertion of > the card hal "exports" the media. That's same like with 7-stable before. > But inserting a UFD leads to hal death. > Here's what I get from dmesg: > ugen3.3: at usbus3 > umass1: on usbus3 > umass1: SCSI over Bulk-Only; quirks = 0x0000 > umass1:6:1:-1: Attached to scbus6 > xptioctl: pass driver is not in the kernel > xptioctl: put "device pass" in your kernel config file > (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition > (probe0:umass-sim1:1:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim1:1:0:0): Not ready to ready change, medium may have > changed > (probe0:umass-sim1:1:0:0): Retrying Command (per Sense Data) > da4 at umass-sim1 bus 1 target 0 lun 0 > da4: Removable Direct Access SCSI-2 device > da4: 40.000MB/s transfers > da4: 249MB (511488 512 byte sectors: 64H 32S/T 249C) > GEOM: da4: partition 1 does not start on a track boundary. > GEOM: da4: partition 1 does not end on a track boundary. > GEOM_LABEL: Label for provider da4s1 is msdosfs/BIOS-UFD. > > Before the UFS plugin I had some hald-addon-storage: /dev/da0 etc. > These are all gone, just these left: > 1084 ?? Ss 0:00,43 /usr/local/sbin/hald > 1088 ?? I 0:00,04 hald-runner > 1122 ?? I 0:00,01 hald-addon-mouse-sysmouse: /dev/ums0 > (hald-addon-mouse-sy) > 1132 ?? I 0:00,01 hald-addon-mouse-sysmouse: /dev/ums1 > (hald-addon-mouse-sy) > 1156 ?? S 0:00,04 hald-addon-storage: /dev/acd0 > (hald-addon-storage) > 1158 ?? S 0:00,07 hald-addon-storage: /dev/acd1 > (hald-addon-storage) > 1439 ?? S 0:00,01 hald-addon-storage: /dev/probe0 > (hald-addon-storage) > > Now I have some essential question: > I know that inserting a Flash Card in a fixed USB card reader doesn't > inform the kernel that there's a new media, so I have to issue a write > request to get the GEOM notified. This is not easily fixable, as far as > I remember some discussion at least one year ago. > But after GEOM knows about the new labels, hal still doesn't catch them. > First I have to pull out and reinsert the card. > Is that fixable? I think you have to ask some file system guys. Usually I use: cat /dev/null > /dev/daX > > Do I have to use `camcontrol eject` before removing flash cards from > fixed readers? Depends on the firmware in the reader. Usually not. > > Any hope for my UFD-hal problem? > Especially the "xptioctl: put "device pass" in your kernel config file" > error message seems very odd to me. Did you try adding "device pass" to your kernel config? --HPS From owner-freebsd-current@FreeBSD.ORG Sun May 31 09:10:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C4491065686 for ; Sun, 31 May 2009 09:10:40 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 18FED8FC08 for ; Sun, 31 May 2009 09:10:39 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 182D5CC3; Sun, 31 May 2009 04:45:54 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAfn1-00078o-Jt; Sun, 31 May 2009 02:49:07 -0500 Date: Sun, 31 May 2009 02:49:07 -0500 From: Richard Todd To: Kip Macy Message-ID: <20090531074907.GA26858@ichotolot.servalan.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Bug in recent large_alloc changes to the ZFS zio code? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 09:10:40 -0000 On Sat, May 30, 2009 at 11:54:47PM -0700, Kip Macy wrote: > http://svn.freebsd.org/changeset/base/192360 > Ah. Hmm. So if I'm reading this right, you already backed out that change in the master SVN repo, right? Well, *something* weird's going on, because that change never seems to have made it to the CVS version of the repo or to the cvsup sites, because I'm not seeing it there; see for yourself at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ . The commit log for 192360 never showed up in CVSROOT-src/commitlogs/sys either. So it looks like bits are falling on the floor somewhere between the SVN and CVS repos. From owner-freebsd-current@FreeBSD.ORG Sun May 31 09:30:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B87DB106564A for ; Sun, 31 May 2009 09:30:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC248FC13 for ; Sun, 31 May 2009 09:30:01 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n4V9TxP8005997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 May 2009 11:29:59 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A224E0B.3040901@omnilan.de> Date: Sun, 31 May 2009 11:29:47 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Hans Petter Selasky References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <4A2173A7.3090100@omnilan.de> <200905311009.27818.hselasky@c2i.net> In-Reply-To: <200905311009.27818.hselasky@c2i.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig80B3C3876FCBDE95EFDA2B45" Cc: freebsd-current@freebsd.org Subject: Re: USB (internally fixed) card reader questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 09:30:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig80B3C3876FCBDE95EFDA2B45 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hans Petter Selasky schrieb am 31.05.2009 10:09 (localtime): > On Saturday 30 May 2009, Harald Schmalzbauer wrote: >> Hans Petter Selasky schrieb am 30.05.2009 12:03 (localtime): =2E.. >> inform the kernel that there's a new media, so I have to issue a write= >> request to get the GEOM notified. This is not easily fixable, as far a= s >> I remember some discussion at least one year ago. >> But after GEOM knows about the new labels, hal still doesn't catch the= m. >> First I have to pull out and reinsert the card. >> Is that fixable? >=20 > I think you have to ask some file system guys. >=20 > Usually I use: >=20 > cat /dev/null > /dev/daX >=20 >> Do I have to use `camcontrol eject` before removing flash cards from >> fixed readers? >=20 > Depends on the firmware in the reader. Usually not. >=20 >> Any hope for my UFD-hal problem? >> Especially the "xptioctl: put "device pass" in your kernel config file= " >> error message seems very odd to me. >=20 > Did you try adding "device pass" to your kernel config? Hello, of course I have pass in the kernel, otherwise neither cd nor any = other da device was working... Thnaks, -Harry --------------enig80B3C3876FCBDE95EFDA2B45 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.11 (FreeBSD) iEYEARECAAYFAkoiThcACgkQLDqVQ9VXb8gAhwCgu8c3CQRzVGgKQlD5qGZvVDJJ oDAAoKxXYazXGrcbwxV/VVQwKoWwXkY3 =lOPn -----END PGP SIGNATURE----- --------------enig80B3C3876FCBDE95EFDA2B45-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 12:33:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ED2B1065673 for ; Sun, 31 May 2009 12:33:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id EA77B8FC2C for ; Sun, 31 May 2009 12:33:00 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAkDk-000CpG-NM for current@freebsd.org; Sun, 31 May 2009 12:33:00 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 37DFB1C72925 for ; Sun, 31 May 2009 21:33:00 +0900 (JST) Date: Sun, 31 May 2009 21:33:00 +0900 Message-ID: From: Randy Bush To: current User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 12:33:01 -0000 8-current a few hours old, i386 ===> usr.bin/ee (install) install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg gencat:No such file or directory *** Error code 1 Stop in /usr/src/usr.bin/ee. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 # cat /etc/make.conf NO_BIND=true NO_FORTRAN=true NO_I4B=true NO_IPFILTER=true NO_KERBEROS=true NO_MAILWRAPPER=true NO_OBJC=true NO_SENDMAIL=true NO_GAMES=true NO_PROFILE=true MAKE_IDEA=YES COMPAT4X=no WITHOUT_X11=yes USA_RESIDENT=YES randy From owner-freebsd-current@FreeBSD.ORG Sun May 31 13:06:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADB78106566B; Sun, 31 May 2009 13:06:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6FAA48FC18; Sun, 31 May 2009 13:06:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VD6d4h044474; Sun, 31 May 2009 09:06:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VD6c0B090638; Sun, 31 May 2009 09:06:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BD2927302F; Sun, 31 May 2009 09:06:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531130638.BD2927302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 09:06:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 13:06:43 -0000 TB --- 2009-05-31 12:20:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 12:20:10 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-31 12:20:10 - cleaning the object tree TB --- 2009-05-31 12:20:47 - cvsupping the source tree TB --- 2009-05-31 12:20:47 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-31 12:21:16 - building world TB --- 2009-05-31 12:21:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 12:21:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 12:21:16 - TARGET=ia64 TB --- 2009-05-31 12:21:16 - TARGET_ARCH=ia64 TB --- 2009-05-31 12:21:16 - TZ=UTC TB --- 2009-05-31 12:21:16 - __MAKE_CONF=/dev/null TB --- 2009-05-31 12:21:16 - cd /src TB --- 2009-05-31 12:21:16 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 12:21:20 UTC 2009 >>> 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 [...] ===> lib/bind/bind9 (all) cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind9/ lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token *** Error code 1 Stop in /src/lib/bind/bind9. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 13:06:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 13:06:38 - ERROR: failed to build world TB --- 2009-05-31 13:06:38 - 2176.62 user 196.48 system 2787.71 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 13:53:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733011065680 for ; Sun, 31 May 2009 13:53:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [77.221.156.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2CEEE8FC16 for ; Sun, 31 May 2009 13:53:06 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (blacklion.static.corbina.ru [89.179.122.169]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 3149613DF46 for ; Sun, 31 May 2009 17:36:11 +0400 (MSD) Date: Sun, 31 May 2009 17:36:17 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1009314136.20090531173617@serebryakov.spb.ru> To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: AOE on FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 31 May 2009 13:53:06 -0000 Hello, Current. Information about AOE (ATA Over Ethernet) on FreeBSD (http://support.coraid.com/support/freebsd/) is outdated. Any news? Maybe, native (not third-party) client & target in pipeline? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-current@FreeBSD.ORG Sun May 31 14:07:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41397106566B; Sun, 31 May 2009 14:07:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E34CD8FC1F; Sun, 31 May 2009 14:07:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VE7eGc049653; Sun, 31 May 2009 10:07:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VE7epi026757; Sun, 31 May 2009 10:07:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 73B657302F; Sun, 31 May 2009 10:07:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531140740.73B657302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 10:07:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 14:07:44 -0000 TB --- 2009-05-31 13:06:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 13:06:38 - starting HEAD tinderbox run for mips/mips TB --- 2009-05-31 13:06:38 - cleaning the object tree TB --- 2009-05-31 13:07:07 - cvsupping the source tree TB --- 2009-05-31 13:07:07 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-05-31 13:07:28 - building world TB --- 2009-05-31 13:07:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 13:07:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 13:07:28 - TARGET=mips TB --- 2009-05-31 13:07:28 - TARGET_ARCH=mips TB --- 2009-05-31 13:07:28 - TZ=UTC TB --- 2009-05-31 13:07:28 - __MAKE_CONF=/dev/null TB --- 2009-05-31 13:07:28 - cd /src TB --- 2009-05-31 13:07:28 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 13:07:29 UTC 2009 >>> 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 [...] gzip -cn /src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -c /src/usr.bin/kdump/kdump.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -c ioctl.c ioctl.c: In function 'ioctlname': ioctl.c:153: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:187: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:2609: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 14:07:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 14:07:40 - ERROR: failed to build world TB --- 2009-05-31 14:07:40 - 2780.90 user 325.90 system 3661.38 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 15:11:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E095E106566B; Sun, 31 May 2009 15:11:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A61698FC08; Sun, 31 May 2009 15:11:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VFBLwf075415; Sun, 31 May 2009 11:11:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VFBL1i075978; Sun, 31 May 2009 11:11:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9CA817302F; Sun, 31 May 2009 11:11:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531151121.9CA817302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 11:11:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 15:11:25 -0000 TB --- 2009-05-31 13:53:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 13:53:34 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-31 13:53:34 - cleaning the object tree TB --- 2009-05-31 13:54:03 - cvsupping the source tree TB --- 2009-05-31 13:54:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-31 13:54:29 - building world TB --- 2009-05-31 13:54:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 13:54:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 13:54:29 - TARGET=powerpc TB --- 2009-05-31 13:54:29 - TARGET_ARCH=powerpc TB --- 2009-05-31 13:54:29 - TZ=UTC TB --- 2009-05-31 13:54:29 - __MAKE_CONF=/dev/null TB --- 2009-05-31 13:54:29 - cd /src TB --- 2009-05-31 13:54:29 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 13:54:33 UTC 2009 >>> 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 [...] gzip -cn /src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump (all) cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c ioctl.c: In function 'ioctlname': ioctl.c:153: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:187: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:2609: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 15:11:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 15:11:21 - ERROR: failed to build world TB --- 2009-05-31 15:11:21 - 3690.01 user 355.28 system 4667.29 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 15:22:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A2D8106564A; Sun, 31 May 2009 15:22:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id E63098FC17; Sun, 31 May 2009 15:22:08 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VFM6G2056451; Sun, 31 May 2009 11:22:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VFM62t071530; Sun, 31 May 2009 11:22:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5D65B7302F; Sun, 31 May 2009 11:22:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531152206.5D65B7302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 11:22:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 15:22:09 -0000 TB --- 2009-05-31 14:07:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 14:07:40 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-05-31 14:07:40 - cleaning the object tree TB --- 2009-05-31 14:08:20 - cvsupping the source tree TB --- 2009-05-31 14:08:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-05-31 14:08:45 - building world TB --- 2009-05-31 14:08:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 14:08:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 14:08:45 - TARGET=sparc64 TB --- 2009-05-31 14:08:45 - TARGET_ARCH=sparc64 TB --- 2009-05-31 14:08:45 - TZ=UTC TB --- 2009-05-31 14:08:45 - __MAKE_CONF=/dev/null TB --- 2009-05-31 14:08:45 - cd /src TB --- 2009-05-31 14:08:45 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 14:08:46 UTC 2009 >>> 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 [...] gzip -cn /src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump (all) cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c ioctl.c: In function 'ioctlname': ioctl.c:151: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:185: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:2607: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 15:22:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 15:22:06 - ERROR: failed to build world TB --- 2009-05-31 15:22:06 - 3452.33 user 350.86 system 4465.84 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 16:18:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975CB106566C; Sun, 31 May 2009 16:18:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4383F8FC13; Sun, 31 May 2009 16:18:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VGICWH078989; Sun, 31 May 2009 12:18:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VGIC7K001324; Sun, 31 May 2009 12:18:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0D6AE7302F; Sun, 31 May 2009 12:18:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531161812.0D6AE7302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 12:18:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 16:18:16 -0000 TB --- 2009-05-31 15:11:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 15:11:21 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-05-31 15:11:21 - cleaning the object tree TB --- 2009-05-31 15:11:55 - cvsupping the source tree TB --- 2009-05-31 15:11:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-31 15:12:03 - building world TB --- 2009-05-31 15:12:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 15:12:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 15:12:03 - TARGET=sun4v TB --- 2009-05-31 15:12:03 - TARGET_ARCH=sparc64 TB --- 2009-05-31 15:12:03 - TZ=UTC TB --- 2009-05-31 15:12:03 - __MAKE_CONF=/dev/null TB --- 2009-05-31 15:12:03 - cd /src TB --- 2009-05-31 15:12:03 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 15:12:05 UTC 2009 >>> 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 [...] gzip -cn /src/usr.bin/jot/jot.1 > jot.1.gz ===> usr.bin/kdump (all) cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c ioctl.c: In function 'ioctlname': ioctl.c:151: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:185: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:2607: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 16:18:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 16:18:12 - ERROR: failed to build world TB --- 2009-05-31 16:18:12 - 3434.06 user 341.05 system 4010.34 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 16:24:05 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72C41106566C; Sun, 31 May 2009 16:24:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 38A9C8FC19; Sun, 31 May 2009 16:24:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CCBCC46B2D; Sun, 31 May 2009 12:24:04 -0400 (EDT) Date: Sun, 31 May 2009 17:24:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: jeff@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@FreeBSD.org, current@FreeBSD.org Subject: scheduler IPIs during shutdown (was: svn commit: r193170 - projects/pnet/sys/kern (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 16:24:05 -0000 Hi Jeff-- I think the reason we're now seeing panics like the: spin lock 0xc08a7e80 (sched lock 1) held by 0xc508b460 (tid 100005) too long As well as the ones occasionally reported on the lists on SMP boxes (kern/134584, etc) is that we're shutting down CPUs while holding their thread locks and then trying to start work on them. Obviously, this is doomed to failure for a number of reasons :-). Without trying to solve the general problem of CPUs coming and going for 8.0, I think we do need some short-term solution for the release. The basic scenario, as I understand it so far, is: - System shutdown kicks off, and CPU 0 starts IPIing CPUs to shut them down, which apparently can occur while holding the thread lock: db> trace 100005 Tracing pid 11 tid 100005 td 0xc4d546c0 cpustop_handler(2,c4a53b64,c0b70cad,c0d9c680,c4a53ae4,...) at cpustop_handler+0x32 ipi_nmi_handler(c0d9c680,c4a53ae4,2,f,c4d52a90,...) at ipi_nmi_handler+0x2f trap(c4a53b70) at trap+0x2d calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xc0887a61, esp = 0xc4a53bb0, ebp = 0xc4a53bdc --- sched_switch(c4d546c0,0,60c,187,5dd9d2a1,...) at sched_switch+0x401 mi_switch(60c,0,c0c3d1ae,813,1,...) at mi_switch+0x200 sched_preempt(c4d546c0,1,c4d54d80,c4a53cb4,c0b5428e,...) at sched_preempt+0x9f ipi_bitmap_handler(8,28,28,31,c0d8e500,...) at ipi_bitmap_handler+0x34 Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x2e --- interrupt, eip = 0xc0856a17, esp = 0xc4a53c8c, ebp = 0xc4a53cb4 --- _thread_lock_flags(c4d546c0,0,c0c3d1ae,a04,c4d546c0,...) at _thread_lock_flags+0x177 sched_idletd(0,c4a53d38,c0c36ad3,335,c4d52a90,...) at sched_idletd+0x251 fork_exit(c0888510,0,c4a53d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc4a53d70, ebp = 0 --- - hardclock fires on CPU 0 and tries to schedule a SWI -- typically softclock or netisr, which bumps into the "leaked" thread lock: db> bt Tracing pid 1 tid 100002 td 0xc4d54d80 kdb_enter(c0c3b5e5,c0c3b5e5,c0c39ccd,c4a49ad0,0,...) at kdb_enter+0x3a panic(c0c39ccd,c4d546c0,c0d8eb44,c4d546c0,186a5,...) at panic+0x136 _mtx_lock_spin_failed(1,9,c0c36d52,320,0,...) at _mtx_lock_spin_failed+0x51 _thread_lock_flags(c4d54240,0,c0c36d52,320,dd313180,...) at _thread_lock_flags+0x175 intr_event_schedule_thread(c4a49b58,c4a49b68,c0915dc4,c4d3a180,0,...) at intr_event_schedule_thread+0xc7 swi_sched(c4d3a180,0,c4a49b74,c0859a2f,c0d893d4,...) at swi_sched+0x28 netisr_sched_poll(c0d893d4,c4a49b88,c0824064,0,2,...) at netisr_sched_poll+0x24 hardclock_device_poll(0,2) at hardclock_device_poll+0xcf hardclock(0,c0b74a49,0,27f,5dd9e8a2,...) at hardclock+0x44 lapic_handle_timer(c4a49bb0) at lapic_handle_timer+0x9f Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc0b74a49, esp = 0xc4a49bf0, ebp = 0xc4a49c0c --- DELAY(f4240,0,c4d40980,c4a49c2c,c08653d3,...) at DELAY+0x89 cpu_reset(f4240,c4a49c68,c0865eaf,0,0,...) at cpu_reset+0xd5 shutdown_reset(0,0,c0c3b4a3,1a7,0,...) at shutdown_reset+0x23 boot(c0d89210,0,c0c3b4a3,ad,c4a49d2c,...) at boot+0x75f reboot(c4d54d80,c4a49cf8,4,c0c428a4,c0d1dc28,...) at reboot+0x4b syscall(c4a49d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 Possibly hardclock should simply know not to kick off softclock at that point in the shutdown (just like I've taught it not to kick off netisr in the device_polling code in my branch), but more generally, sched_ule probably needs to not hold the per-cpu runqueue lock, and/or sched_ule needs to not try to start work on CPUs that aren't running. If the SWI is pinned on or bound to an already shut down CPU, then we should in fact panic, but otherwise it seems it should preempt the current thread and run it on the CPU managing the shutdown. Or, we could go with the old-world order view and not allow interrupts to fire, but I wonder if all our device drivers would be comfortable with that. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Sun, 31 May 2009 13:52:17 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r193170 - projects/pnet/sys/kern Author: rwatson Date: Sun May 31 13:52:17 2009 New Revision: 193170 URL: http://svn.freebsd.org/changeset/base/193170 Log: Add a shutdown handler for device polling -- don't issue wakeups to the netisr once file systems are done syncing, otherwise the scheduler may generate IPIs to CPUs that have already been shutdown, leading to a panic. As similar panics (spin lock 0xc0d8e500 (sched lock 1) held by 0xc4d546c0 (tid 100005) too long) have been reported on both 7.x and 8.x in other code, we might want to think about whether there's some missing scheduler shutdown logic to handle this case for unpinned/unbound threads by migrating them to the CPU managing the shutdown and allowing them to preempt. Modified: projects/pnet/sys/kern/kern_poll.c Modified: projects/pnet/sys/kern/kern_poll.c ============================================================================== --- projects/pnet/sys/kern/kern_poll.c Sun May 31 12:36:14 2009 (r193169) +++ projects/pnet/sys/kern/kern_poll.c Sun May 31 13:52:17 2009 (r193170) @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include /* needed by net/if.h */ #include @@ -110,6 +111,7 @@ SYSCTL_UINT(_kern_polling, OID_AUTO, bur static int netisr_poll_scheduled; static int netisr_pollmore_scheduled; +static int poll_shutting_down; static int poll_burst_max_sysctl(SYSCTL_HANDLER_ARGS) { @@ -261,10 +263,19 @@ struct pollrec { static struct pollrec pr[POLL_LIST_LEN]; static void +poll_shutdown(void *arg, int howto) +{ + + poll_shutting_down = 1; +} + +static void init_device_poll(void) { mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); + EVENTHANDLER_REGISTER(shutdown_post_sync, poll_shutdown, NULL, + SHUTDOWN_PRI_LAST); } SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, NULL); @@ -288,7 +299,7 @@ hardclock_device_poll(void) static struct timeval prev_t, t; int delta; - if (poll_handlers == 0) + if (poll_handlers == 0 || poll_shutting_down) return; microuptime(&t); From owner-freebsd-current@FreeBSD.ORG Sun May 31 16:39:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38426106566B; Sun, 31 May 2009 16:39:26 +0000 (UTC) (envelope-from zec@icir.org) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by mx1.freebsd.org (Postfix) with ESMTP id B711C8FC13; Sun, 31 May 2009 16:39:25 +0000 (UTC) (envelope-from zec@icir.org) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id n4VGKNbn004874; Sun, 31 May 2009 18:20:24 +0200 (CEST) Received: from [192.168.200.102] ([161.53.19.79]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 31 May 2009 18:20:06 +0200 From: Marko Zec To: freebsd-current@freebsd.org Date: Sun, 31 May 2009 18:20:01 +0200 User-Agent: KMail/1.9.10 References: <20090531161812.0D6AE7302F@freebsd-current.sentex.ca> In-Reply-To: <20090531161812.0D6AE7302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905311820.01915.zec@icir.org> X-OriginalArrivalTime: 31 May 2009 16:20:06.0490 (UTC) FILETIME=[A90403A0:01C9E20B] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 16:39:26 -0000 Mea culpa, should be fixed already with r193177. Marko On Sunday 31 May 2009 18:18:12 FreeBSD Tinderbox wrote: > TB --- 2009-05-31 15:11:21 - tinderbox 2.6 running on > freebsd-current.sentex.ca TB --- 2009-05-31 15:11:21 - starting HEAD > tinderbox run for sparc64/sun4v TB --- 2009-05-31 15:11:21 - cleaning the > object tree > TB --- 2009-05-31 15:11:55 - cvsupping the source tree > TB --- 2009-05-31 15:11:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s > /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-05-31 15:12:03 - building > world > TB --- 2009-05-31 15:12:03 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-31 15:12:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-31 15:12:03 - TARGET=sun4v > TB --- 2009-05-31 15:12:03 - TARGET_ARCH=sparc64 > TB --- 2009-05-31 15:12:03 - TZ=UTC > TB --- 2009-05-31 15:12:03 - __MAKE_CONF=/dev/null > TB --- 2009-05-31 15:12:03 - cd /src > TB --- 2009-05-31 15:12:03 - /usr/bin/make -B buildworld > > >>> World build started on Sun May 31 15:12:05 UTC 2009 > >>> 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 > > [...] > gzip -cn /src/usr.bin/jot/jot.1 > jot.1.gz > ===> usr.bin/kdump (all) > cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace -I/src/usr.bin/kdump > -I/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c > /src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/src/usr.bin/kdump/../ktrace > -I/src/usr.bin/kdump -I/src/usr.bin/kdump/../.. -std=gnu99 > -fstack-protector -c ioctl.c ioctl.c: In function 'ioctlname': > ioctl.c:151: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' ioctl.c:185: error: invalid application of 'sizeof' to > incomplete type 'struct vi_req' ioctl.c:2607: error: invalid application of > 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 > > Stop in /src/usr.bin/kdump. > *** Error code 1 > > Stop in /src/usr.bin. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-05-31 16:18:12 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-05-31 16:18:12 - ERROR: failed to build world > TB --- 2009-05-31 16:18:12 - 3434.06 user 341.05 system 4010.34 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full > _______________________________________________ > 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 May 31 17:09:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE464106564A for ; Sun, 31 May 2009 17:09:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7D98FC22 for ; Sun, 31 May 2009 17:09:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4463346B2D; Sun, 31 May 2009 13:09:23 -0400 (EDT) Date: Sun, 31 May 2009 18:09:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randy Bush In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: yakpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 17:09:24 -0000 On Sun, 31 May 2009, Randy Bush wrote: > and one more, this from serial console > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff8047c1da > stack pointer = 0x28:0xffffff807a156630 > frame pointer = 0x28:0xffffff807a1566f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1385 (nfcapd) > trap number = 12 > panic: page fault > cpuid = 0 > > due to when it happens, about 01:50 when there are no cron jobs or anything > obvious, i am suspecting this is not the same as kern/134011 > > it did not leave a dump. and i could not force one as it required a power > cycle to get the box's attention. > > nfcapd is a flow data capture from a couple of lighly loaded (10-20Mbps) > routers. Is it possible to use options KDB_TRACE and KDB_PANIC to dump a stack trace to the serial console to use as a starting point for debugging? And/or DDB scripting to run various debugging commands which log to serial console or a textdump? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun May 31 17:33:17 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0658D106566B; Sun, 31 May 2009 17:33:17 +0000 (UTC) (envelope-from sson@FreeBSD.org) Received: from www.son.org (son.org [199.239.233.23]) by mx1.freebsd.org (Postfix) with ESMTP id B8AB78FC18; Sun, 31 May 2009 17:33:11 +0000 (UTC) (envelope-from sson@FreeBSD.org) Received: from NextStepNG.son.org (adsl-76-203-228-11.dsl.rcsntx.sbcglobal.net [76.203.228.11]) (authenticated bits=0) by www.son.org (8.13.6.20060614/8.13.6) with ESMTP id n4VHM4GL066221; Sun, 31 May 2009 12:22:05 -0500 (CDT) Message-Id: From: Stacey Son To: lev@FreeBSD.org In-Reply-To: <1009314136.20090531173617@serebryakov.spb.ru> Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 (Normal) Date: Sun, 31 May 2009 12:22:04 -0500 References: <1009314136.20090531173617@serebryakov.spb.ru> X-Mailer: Apple Mail (2.930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@FreeBSD.org Subject: Re: AOE on FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 17:33:17 -0000 Hi, I did some work on the AoE initiator years ago. I also created a patch for one of the user level targets (see http://people.freebsd.org/~sson/aoe/vblade-freebsd.patch) . If there is enough interest I could dust off this code and get in ready to commit. I would estimate about two weeks given what I have on my plate currently and what I believe needs to be rewritten in the initiator. Is there a good amount of interest for this? Best Regards, -stacey. On May 31, 2009, at 8:36 AM, Lev Serebryakov wrote: > Hello, Current. > > Information about AOE (ATA Over Ethernet) on FreeBSD > (http://support.coraid.com/support/freebsd/) is outdated. > Any news? Maybe, native (not third-party) client & target in > pipeline? > > -- > // Black Lion AKA Lev Serebryakov > > _______________________________________________ > 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 May 31 18:36:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F36106564A; Sun, 31 May 2009 18:36:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 84A3B8FC12; Sun, 31 May 2009 18:36:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VIaLbF086329; Sun, 31 May 2009 14:36:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VIaLPm086978; Sun, 31 May 2009 14:36:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6F6C37302F; Sun, 31 May 2009 14:36:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531183621.6F6C37302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 14:36:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 18:36:25 -0000 TB --- 2009-05-31 16:20:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 16:20:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-05-31 16:20:01 - cleaning the object tree TB --- 2009-05-31 16:21:25 - cvsupping the source tree TB --- 2009-05-31 16:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-05-31 16:21:35 - building world TB --- 2009-05-31 16:21:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 16:21:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 16:21:35 - TARGET=amd64 TB --- 2009-05-31 16:21:35 - TARGET_ARCH=amd64 TB --- 2009-05-31 16:21:35 - TZ=UTC TB --- 2009-05-31 16:21:35 - __MAKE_CONF=/dev/null TB --- 2009-05-31 16:21:35 - cd /src TB --- 2009-05-31 16:21:35 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 16:21:36 UTC 2009 >>> 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 Sun May 31 18:23:03 UTC 2009 TB --- 2009-05-31 18:23:03 - generating LINT kernel config TB --- 2009-05-31 18:23:03 - cd /src/sys/amd64/conf TB --- 2009-05-31 18:23:03 - /usr/bin/make -B LINT TB --- 2009-05-31 18:23:03 - building LINT kernel TB --- 2009-05-31 18:23:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 18:23:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 18:23:03 - TARGET=amd64 TB --- 2009-05-31 18:23:03 - TARGET_ARCH=amd64 TB --- 2009-05-31 18:23:03 - TZ=UTC TB --- 2009-05-31 18:23:03 - __MAKE_CONF=/dev/null TB --- 2009-05-31 18:23:03 - cd /src TB --- 2009-05-31 18:23:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 31 18:23:03 UTC 2009 >>> 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 -frename-registers -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/vfs_cache.c /src/sys/kern/vfs_cache.c: In function 'vn_vptocnp_locked': /src/sys/kern/vfs_cache.c:1075: error: 'startvp' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1075: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_cache.c:1075: error: for each function it appears in.) /src/sys/kern/vfs_cache.c: In function 'vn_fullpath1': /src/sys/kern/vfs_cache.c:1180: error: 'fullpath' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1189: error: invalid type argument of 'unary *' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 18:36:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 18:36:21 - ERROR: failed to build lint kernel TB --- 2009-05-31 18:36:21 - 6293.23 user 649.77 system 8179.97 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 19:07:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80F03106566B; Sun, 31 May 2009 19:07:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 42BBB8FC13; Sun, 31 May 2009 19:07:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VJ7UqH088802; Sun, 31 May 2009 15:07:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VJ7UEc024771; Sun, 31 May 2009 15:07:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 75BBB7302F; Sun, 31 May 2009 15:07:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531190730.75BBB7302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 15:07:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 19:07:34 -0000 TB --- 2009-05-31 17:28:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 17:28:50 - starting HEAD tinderbox run for i386/i386 TB --- 2009-05-31 17:28:50 - cleaning the object tree TB --- 2009-05-31 17:29:31 - cvsupping the source tree TB --- 2009-05-31 17:29:31 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-05-31 17:29:40 - building world TB --- 2009-05-31 17:29:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 17:29:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 17:29:40 - TARGET=i386 TB --- 2009-05-31 17:29:40 - TARGET_ARCH=i386 TB --- 2009-05-31 17:29:40 - TZ=UTC TB --- 2009-05-31 17:29:40 - __MAKE_CONF=/dev/null TB --- 2009-05-31 17:29:40 - cd /src TB --- 2009-05-31 17:29:40 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 17:29:41 UTC 2009 >>> 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 Sun May 31 18:53:19 UTC 2009 TB --- 2009-05-31 18:53:19 - generating LINT kernel config TB --- 2009-05-31 18:53:19 - cd /src/sys/i386/conf TB --- 2009-05-31 18:53:19 - /usr/bin/make -B LINT TB --- 2009-05-31 18:53:19 - building LINT kernel TB --- 2009-05-31 18:53:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 18:53:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 18:53:19 - TARGET=i386 TB --- 2009-05-31 18:53:19 - TARGET_ARCH=i386 TB --- 2009-05-31 18:53:19 - TZ=UTC TB --- 2009-05-31 18:53:19 - __MAKE_CONF=/dev/null TB --- 2009-05-31 18:53:19 - cd /src TB --- 2009-05-31 18:53:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 31 18:53:20 UTC 2009 >>> 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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/vfs_cache.c /src/sys/kern/vfs_cache.c: In function 'vn_vptocnp_locked': /src/sys/kern/vfs_cache.c:1075: error: 'startvp' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1075: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_cache.c:1075: error: for each function it appears in.) /src/sys/kern/vfs_cache.c: In function 'vn_fullpath1': /src/sys/kern/vfs_cache.c:1180: error: 'fullpath' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1189: error: invalid type argument of 'unary *' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 19:07:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 19:07:30 - ERROR: failed to build lint kernel TB --- 2009-05-31 19:07:30 - 4629.06 user 445.24 system 5920.13 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 19:53:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69210106564A; Sun, 31 May 2009 19:53:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3F5368FC14; Sun, 31 May 2009 19:53:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VJqwaf091724; Sun, 31 May 2009 15:52:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VJqwJt013471; Sun, 31 May 2009 15:52:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3DE4D7302F; Sun, 31 May 2009 15:52:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531195258.3DE4D7302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 15:52:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 19:53:02 -0000 TB --- 2009-05-31 19:07:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 19:07:30 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-05-31 19:07:30 - cleaning the object tree TB --- 2009-05-31 19:07:45 - cvsupping the source tree TB --- 2009-05-31 19:07:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-05-31 19:07:52 - building world TB --- 2009-05-31 19:07:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 19:07:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 19:07:52 - TARGET=ia64 TB --- 2009-05-31 19:07:52 - TARGET_ARCH=ia64 TB --- 2009-05-31 19:07:52 - TZ=UTC TB --- 2009-05-31 19:07:52 - __MAKE_CONF=/dev/null TB --- 2009-05-31 19:07:52 - cd /src TB --- 2009-05-31 19:07:52 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 19:07:53 UTC 2009 >>> 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 [...] ===> lib/bind/bind9 (all) cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind9/ lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token *** Error code 1 Stop in /src/lib/bind/bind9. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 19:52:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 19:52:58 - ERROR: failed to build world TB --- 2009-05-31 19:52:58 - 2174.12 user 195.50 system 2727.33 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 20:05:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64ABC106566C for ; Sun, 31 May 2009 20:05:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2510B8FC1D for ; Sun, 31 May 2009 20:05:08 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id A111B348F3D; Sun, 31 May 2009 16:05:07 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 31 May 2009 16:05:07 -0400 X-Sasl-enc: Nm8l2sVOtyJFy3Vzx3P5VpNA6rjRXo5w6BIgrKUI2pt/ 1243800306 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id BAB8239400; Sun, 31 May 2009 16:05:06 -0400 (EDT) Message-ID: <4A22E2F1.6070404@incunabulum.net> Date: Sun, 31 May 2009 21:05:05 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: deeptech71@gmail.com References: <4A1DD57A.7010704@gmail.com> <4A1E9831.4010606@incunabulum.net> <4A1EC8FB.6090206@gmail.com> <4A1FBFF5.6090103@incunabulum.net> <4A20791D.5070209@gmail.com> In-Reply-To: <4A20791D.5070209@gmail.com> Content-Type: multipart/mixed; boundary="------------050205070009090208030305" Cc: freebsd-current@freebsd.org Subject: Re: panic: igmp_v3_dispatch_general_query: called when version 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 20:05:08 -0000 This is a multi-part message in MIME format. --------------050205070009090208030305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit deeptech71@gmail.com wrote: > Bruce Simpson wrote: >> I may not get free time to fix this right away, are you able to test a >> patch when I can make one available? > > Sure. Thanks. Can you please test this patch and let me know if it works for you? You ran into a race where the v3 link timer could be set but not cancelled when the version changes; that function is trying to be too smart about the work it has to do. There are some more things in there than 'just' the change you need, I want to bring in some of the MLDv2 changes which tighten query processing. I've checked it into Perforce for now and can merge it in the week. thanks, BMS --------------050205070009090208030305 Content-Type: text/plain; name="igmpv3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="igmpv3.diff" ==== //depot/user/bms/netdev/sys/netinet/igmp.c#232 - /home/bms/p4/netdev/sys/netinet/igmp.c ==== --- /tmp/tmp.94699.26 2009-05-31 20:58:26.000000000 +0100 +++ /home/bms/p4/netdev/sys/netinet/igmp.c 2009-05-31 20:52:56.000000000 +0100 @@ -98,7 +98,8 @@ static int igmp_handle_state_change(struct in_multi *, struct igmp_ifinfo *); static int igmp_initial_join(struct in_multi *, struct igmp_ifinfo *); -static int igmp_input_v1_query(struct ifnet *, const struct ip *); +static int igmp_input_v1_query(struct ifnet *, const struct ip *, + const struct igmp *); static int igmp_input_v2_query(struct ifnet *, const struct ip *, const struct igmp *); static int igmp_input_v3_query(struct ifnet *, const struct ip *, @@ -700,7 +701,8 @@ * VIMAGE: The curvnet pointer is derived from the input ifp. */ static int -igmp_input_v1_query(struct ifnet *ifp, const struct ip *ip) +igmp_input_v1_query(struct ifnet *ifp, const struct ip *ip, + const struct igmp *igmp) { INIT_VNET_INET(ifp->if_vnet); struct ifmultiaddr *ifma; @@ -708,20 +710,18 @@ struct in_multi *inm; /* - * IGMPv1 General Queries SHOULD always addressed to 224.0.0.1. + * IGMPv1 Host Mmembership Queries SHOULD always be addressed to + * 224.0.0.1. They are always treated as General Queries. * igmp_group is always ignored. Do not drop it as a userland * daemon may wish to see it. + * XXX SMPng: unlocked increments in igmpstat assumed atomic. */ - if (!in_allhosts(ip->ip_dst)) { + if (!in_allhosts(ip->ip_dst) || !in_nullhost(igmp->igmp_group)) { IGMPSTAT_INC(igps_rcv_badqueries); return (0); } - IGMPSTAT_INC(igps_rcv_gen_queries); - /* - * Switch to IGMPv1 host compatibility mode. - */ IN_MULTI_LOCK(); IGMP_LOCK(); @@ -734,6 +734,9 @@ goto out_locked; } + /* + * Switch to IGMPv1 host compatibility mode. + */ igmp_set_version(igi, IGMP_VERSION_1); CTR2(KTR_IGMPV3, "process v1 query on ifp %p(%s)", ifp, ifp->if_xname); @@ -791,12 +794,29 @@ struct ifmultiaddr *ifma; struct igmp_ifinfo *igi; struct in_multi *inm; + int is_general_query; uint16_t timer; + is_general_query = 0; + /* - * Perform lazy allocation of IGMP link info if required, - * and switch to IGMPv2 host compatibility mode. + * Validate address fields upfront. + * XXX SMPng: unlocked increments in igmpstat assumed atomic. */ + if (in_nullhost(igmp->igmp_group)) { + /* + * IGMPv2 General Query. + * If this was not sent to the all-hosts group, ignore it. + */ + if (!in_allhosts(ip->ip_dst)) + return (0); + IGMPSTAT_INC(igps_rcv_gen_queries); + is_general_query = 1; + } else { + /* IGMPv2 Group-Specific Query. */ + IGMPSTAT_INC(igps_rcv_group_queries); + } + IN_MULTI_LOCK(); IGMP_LOCK(); @@ -809,16 +829,37 @@ goto out_locked; } + /* + * Ignore v2 query if in v1 Compatibility Mode. + */ + if (igi->igi_version == IGMP_VERSION_1) + goto out_locked; + igmp_set_version(igi, IGMP_VERSION_2); timer = igmp->igmp_code * PR_FASTHZ / IGMP_TIMER_SCALE; if (timer == 0) timer = 1; - if (!in_nullhost(igmp->igmp_group)) { + if (is_general_query) { /* - * IGMPv2 Group-Specific Query. - * If this is a group-specific IGMPv2 query, we need only + * For each reporting group joined on this + * interface, kick the report timer. + */ + CTR2(KTR_IGMPV3, "process v2 general query on ifp %p(%s)", + ifp, ifp->if_xname); + IF_ADDR_LOCK(ifp); + TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { + if (ifma->ifma_addr->sa_family != AF_INET || + ifma->ifma_protospec == NULL) + continue; + inm = (struct in_multi *)ifma->ifma_protospec; + igmp_v2_update_group(inm, timer); + } + IF_ADDR_UNLOCK(ifp); + } else { + /* + * Group-specific IGMPv2 query, we need only * look up the single group to process it. */ inm = inm_lookup(ifp, igmp->igmp_group); @@ -827,32 +868,6 @@ inet_ntoa(igmp->igmp_group), ifp, ifp->if_xname); igmp_v2_update_group(inm, timer); } - IGMPSTAT_INC(igps_rcv_group_queries); - } else { - /* - * IGMPv2 General Query. - * If this was not sent to the all-hosts group, ignore it. - */ - if (in_allhosts(ip->ip_dst)) { - /* - * For each reporting group joined on this - * interface, kick the report timer. - */ - CTR2(KTR_IGMPV3, - "process v2 general query on ifp %p(%s)", - ifp, ifp->if_xname); - - IF_ADDR_LOCK(ifp); - TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - if (ifma->ifma_addr->sa_family != AF_INET || - ifma->ifma_protospec == NULL) - continue; - inm = (struct in_multi *)ifma->ifma_protospec; - igmp_v2_update_group(inm, timer); - } - IF_ADDR_UNLOCK(ifp); - } - IGMPSTAT_INC(igps_rcv_gen_queries); } out_locked: @@ -931,10 +946,13 @@ INIT_VNET_INET(ifp->if_vnet); struct igmp_ifinfo *igi; struct in_multi *inm; + int is_general_query; uint32_t maxresp, nsrc, qqi; uint16_t timer; uint8_t qrv; + is_general_query = 0; + CTR2(KTR_IGMPV3, "process v3 query on ifp %p(%s)", ifp, ifp->if_xname); maxresp = igmpv3->igmp_code; /* in 1/10ths of a second */ @@ -945,7 +963,7 @@ /* * Robustness must never be less than 2 for on-wire IGMPv3. - * FIXME: Check if ifp has IGIF_LOOPBACK set, as we make + * FUTURE: Check if ifp has IGIF_LOOPBACK set, as we will make * an exception for interfaces whose IGMPv3 state changes * are redirected to loopback (e.g. MANET). */ @@ -968,6 +986,33 @@ nsrc = ntohs(igmpv3->igmp_numsrc); + /* + * Validate address fields and versions upfront before + * accepting v3 query. + * XXX SMPng: Unlocked access to igmpstat counters here. + */ + if (in_nullhost(igmpv3->igmp_group)) { + /* + * IGMPv3 General Query. + * + * General Queries SHOULD be directed to 224.0.0.1. + * A general query with a source list has undefined + * behaviour; discard it. + */ + IGMPSTAT_INC(igps_rcv_gen_queries); + if (!in_allhosts(ip->ip_dst) || nsrc > 0) { + IGMPSTAT_INC(igps_rcv_badqueries); + return (0); + } + is_general_query = 1; + } else { + /* Group or group-source specific query. */ + if (nsrc == 0) + IGMPSTAT_INC(igps_rcv_group_queries); + else + IGMPSTAT_INC(igps_rcv_gsr_queries); + } + IN_MULTI_LOCK(); IGMP_LOCK(); @@ -980,8 +1025,19 @@ goto out_locked; } - igmp_set_version(igi, IGMP_VERSION_3); + /* + * Discard the v3 query if we're in Compatibility Mode. + * The RFC is not obviously worded that hosts need to stay in + * compatibility mode until the Old Version Querier Present + * timer expires. + */ + if (igi->igi_version != IGMP_VERSION_3) { + CTR3(KTR_IGMPV3, "ignore v3 query in v%d mode on ifp %p(%s)", + igi->igi_version, ifp, ifp->if_xname); + goto out_locked; + } + igmp_set_version(igi, IGMP_VERSION_3); igi->igi_rv = qrv; igi->igi_qi = qqi; igi->igi_qri = maxresp; @@ -989,41 +1045,23 @@ CTR4(KTR_IGMPV3, "%s: qrv %d qi %d qri %d", __func__, qrv, qqi, maxresp); - if (in_nullhost(igmpv3->igmp_group)) { + if (is_general_query) { /* - * IGMPv3 General Query. * Schedule a current-state report on this ifp for * all groups, possibly containing source lists. - */ - IGMPSTAT_INC(igps_rcv_gen_queries); - - if (!in_allhosts(ip->ip_dst) || nsrc > 0) { - /* - * General Queries SHOULD be directed to 224.0.0.1. - * A general query with a source list has undefined - * behaviour; discard it. - */ - IGMPSTAT_INC(igps_rcv_badqueries); - goto out_locked; - } - - CTR2(KTR_IGMPV3, "process v3 general query on ifp %p(%s)", - ifp, ifp->if_xname); - - /* * If there is a pending General Query response * scheduled earlier than the selected delay, do * not schedule any other reports. * Otherwise, reset the interface timer. */ + CTR2(KTR_IGMPV3, "process v3 general query on ifp %p(%s)", + ifp, ifp->if_xname); if (igi->igi_v3_timer == 0 || igi->igi_v3_timer >= timer) { igi->igi_v3_timer = IGMP_RANDOM_DELAY(timer); V_interface_timers_running = 1; } } else { /* - * IGMPv3 Group-specific or Group-and-source-specific Query. - * * Group-source-specific queries are throttled on * a per-group basis to defeat denial-of-service attempts. * Queries for groups we are not a member of on this @@ -1033,7 +1071,6 @@ if (inm == NULL) goto out_locked; if (nsrc > 0) { - IGMPSTAT_INC(igps_rcv_gsr_queries); if (!ratecheck(&inm->inm_lastgsrtv, &V_igmp_gsrdelay)) { CTR1(KTR_IGMPV3, "%s: GS query throttled.", @@ -1041,8 +1078,6 @@ IGMPSTAT_INC(igps_drop_gsr_queries); goto out_locked; } - } else { - IGMPSTAT_INC(igps_rcv_group_queries); } CTR3(KTR_IGMPV3, "process v3 %s query on ifp %p(%s)", inet_ntoa(igmpv3->igmp_group), ifp, ifp->if_xname); @@ -1465,7 +1500,7 @@ IGMPSTAT_INC(igps_rcv_v1v2_queries); if (!V_igmp_v1enable) break; - if (igmp_input_v1_query(ifp, ip) != 0) { + if (igmp_input_v1_query(ifp, ip, igmp) != 0) { m_freem(m); return; } @@ -1907,6 +1942,7 @@ static void igmp_set_version(struct igmp_ifinfo *igi, const int version) { + int old_version_timer; IGMP_LOCK_ASSERT(); @@ -1914,7 +1950,6 @@ version, igi->igi_ifp, igi->igi_ifp->if_xname); if (version == IGMP_VERSION_1 || version == IGMP_VERSION_2) { - int old_version_timer; /* * Compute the "Older Version Querier Present" timer as per * Section 8.12. @@ -1947,6 +1982,11 @@ /* * Cancel pending IGMPv3 timers for the given link and all groups * joined on it; state-change, general-query, and group-query timers. + * + * Only ever called on a transition from v3 to Compatibility mode. Kill + * the timers stone dead (this may be expensive for large N groups), they + * will be restarted if Compatibility Mode deems that they must be due to + * query processing. */ static void igmp_v3_cancel_link_timers(struct igmp_ifinfo *igi) @@ -1963,21 +2003,21 @@ IGMP_LOCK_ASSERT(); /* - * Fast-track this potentially expensive operation - * by checking all the global 'timer pending' flags. + * Stop the v3 General Query Response on this link stone dead. + * If fasttimo is woken up due to V_interface_timers_running, + * the flag will be cleared if there are no pending link timers. */ - if (!V_interface_timers_running && - !V_state_change_timers_running && - !V_current_state_timers_running) - return; - igi->igi_v3_timer = 0; + /* + * Now clear the current-state and state-change report timers + * for all memberships scoped to this link. + */ ifp = igi->igi_ifp; - IF_ADDR_LOCK(ifp); TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) { - if (ifma->ifma_addr->sa_family != AF_INET) + if (ifma->ifma_addr->sa_family != AF_INET || + ifma->ifma_protospec == NULL) continue; inm = (struct in_multi *)ifma->ifma_protospec; switch (inm->inm_state) { @@ -1987,12 +2027,19 @@ case IGMP_LAZY_MEMBER: case IGMP_SLEEPING_MEMBER: case IGMP_AWAKENING_MEMBER: + /* + * These states are either not relevant in v3 mode, + * or are unreported. Do nothing. + */ break; case IGMP_LEAVING_MEMBER: /* - * If we are leaving the group and switching - * IGMP version, we need to release the final - * reference held for issuing the INCLUDE {}. + * If we are leaving the group and switching to + * compatibility mode, we need to release the final + * reference held for issuing the INCLUDE {}, and + * transition to REPORTING to ensure the host leave + * message is sent upstream to the old querier -- + * transition to NOT would lose the leave and race. * * SMPNG: Must drop and re-acquire IF_ADDR_LOCK * around inm_release_locked(), as it is not @@ -2007,15 +2054,16 @@ inm_clear_recorded(inm); /* FALLTHROUGH */ case IGMP_REPORTING_MEMBER: - inm->inm_sctimer = 0; - inm->inm_timer = 0; inm->inm_state = IGMP_REPORTING_MEMBER; - /* - * Free any pending IGMPv3 state-change records. - */ - _IF_DRAIN(&inm->inm_scq); break; } + /* + * Always clear state-change and group report timers. + * Free any pending IGMPv3 state-change records. + */ + inm->inm_sctimer = 0; + inm->inm_timer = 0; + _IF_DRAIN(&inm->inm_scq); } IF_ADDR_UNLOCK(ifp); } --------------050205070009090208030305-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 20:11:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 487B4106567A; Sun, 31 May 2009 20:11:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0A4FF8FC20; Sun, 31 May 2009 20:11:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VKBo8D080138; Sun, 31 May 2009 16:11:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VKBnNU045079; Sun, 31 May 2009 16:11:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BC8B07302F; Sun, 31 May 2009 16:11:49 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531201149.BC8B07302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 16:11:49 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 20:11:54 -0000 TB --- 2009-05-31 18:36:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 18:36:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-05-31 18:36:21 - cleaning the object tree TB --- 2009-05-31 18:36:54 - cvsupping the source tree TB --- 2009-05-31 18:36:54 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-05-31 18:37:02 - building world TB --- 2009-05-31 18:37:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 18:37:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 18:37:02 - TARGET=pc98 TB --- 2009-05-31 18:37:02 - TARGET_ARCH=i386 TB --- 2009-05-31 18:37:02 - TZ=UTC TB --- 2009-05-31 18:37:02 - __MAKE_CONF=/dev/null TB --- 2009-05-31 18:37:02 - cd /src TB --- 2009-05-31 18:37:02 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 18:37:06 UTC 2009 >>> 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 Sun May 31 19:59:53 UTC 2009 TB --- 2009-05-31 19:59:53 - generating LINT kernel config TB --- 2009-05-31 19:59:53 - cd /src/sys/pc98/conf TB --- 2009-05-31 19:59:53 - /usr/bin/make -B LINT TB --- 2009-05-31 19:59:53 - building LINT kernel TB --- 2009-05-31 19:59:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 19:59:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 19:59:53 - TARGET=pc98 TB --- 2009-05-31 19:59:53 - TARGET_ARCH=i386 TB --- 2009-05-31 19:59:53 - TZ=UTC TB --- 2009-05-31 19:59:53 - __MAKE_CONF=/dev/null TB --- 2009-05-31 19:59:53 - cd /src TB --- 2009-05-31 19:59:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 31 19:59:53 UTC 2009 >>> 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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/vfs_cache.c /src/sys/kern/vfs_cache.c: In function 'vn_vptocnp_locked': /src/sys/kern/vfs_cache.c:1075: error: 'startvp' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1075: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_cache.c:1075: error: for each function it appears in.) /src/sys/kern/vfs_cache.c: In function 'vn_fullpath1': /src/sys/kern/vfs_cache.c:1180: error: 'fullpath' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1189: error: invalid type argument of 'unary *' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 20:11:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 20:11:49 - ERROR: failed to build lint kernel TB --- 2009-05-31 20:11:49 - 4482.10 user 449.92 system 5728.21 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 20:16:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA088106567F for ; Sun, 31 May 2009 20:16:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 613D98FC33 for ; Sun, 31 May 2009 20:16:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MArSa-0006GB-M6 for current@freebsd.org; Sun, 31 May 2009 23:16:48 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n4VKGjuC006799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 31 May 2009 23:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n4VKGjHV015427 for ; Sun, 31 May 2009 23:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n4VKGjq9015426 for current@freebsd.org; Sun, 31 May 2009 23:16:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 May 2009 23:16:45 +0300 From: Kostik Belousov To: current@freebsd.org Message-ID: <20090531201645.GW1927@deviant.kiev.zoral.com.ua> References: <20090531183621.6F6C37302F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UYlS7R7B/6gq3w4G" Content-Disposition: inline In-Reply-To: <20090531183621.6F6C37302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MArSa-0006GB-M6 5828e136e4351ef2744f22d9b18f896e X-Terabit: YES Cc: Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 20:16:52 -0000 --UYlS7R7B/6gq3w4G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, May 31, 2009 at 02:36:21PM -0400, FreeBSD Tinderbox wrote: > TB --- 2009-05-31 16:20:01 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-05-31 16:20:01 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2009-05-31 16:20:01 - cleaning the object tree > TB --- 2009-05-31 16:21:25 - cvsupping the source tree > TB --- 2009-05-31 16:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-05-31 16:21:35 - building world > TB --- 2009-05-31 16:21:35 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-31 16:21:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-31 16:21:35 - TARGET=amd64 > TB --- 2009-05-31 16:21:35 - TARGET_ARCH=amd64 > TB --- 2009-05-31 16:21:35 - TZ=UTC > TB --- 2009-05-31 16:21:35 - __MAKE_CONF=/dev/null > TB --- 2009-05-31 16:21:35 - cd /src > TB --- 2009-05-31 16:21:35 - /usr/bin/make -B buildworld > >>> World build started on Sun May 31 16:21:36 UTC 2009 > >>> 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 Sun May 31 18:23:03 UTC 2009 > TB --- 2009-05-31 18:23:03 - generating LINT kernel config > TB --- 2009-05-31 18:23:03 - cd /src/sys/amd64/conf > TB --- 2009-05-31 18:23:03 - /usr/bin/make -B LINT > TB --- 2009-05-31 18:23:03 - building LINT kernel > TB --- 2009-05-31 18:23:03 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-05-31 18:23:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-05-31 18:23:03 - TARGET=amd64 > TB --- 2009-05-31 18:23:03 - TARGET_ARCH=amd64 > TB --- 2009-05-31 18:23:03 - TZ=UTC > TB --- 2009-05-31 18:23:03 - __MAKE_CONF=/dev/null > TB --- 2009-05-31 18:23:03 - cd /src > TB --- 2009-05-31 18:23:03 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Sun May 31 18:23:03 UTC 2009 > >>> 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 -frename-registers -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/vfs_cache.c > /src/sys/kern/vfs_cache.c: In function 'vn_vptocnp_locked': > /src/sys/kern/vfs_cache.c:1075: error: 'startvp' undeclared (first use in this function) > /src/sys/kern/vfs_cache.c:1075: error: (Each undeclared identifier is reported only once > /src/sys/kern/vfs_cache.c:1075: error: for each function it appears in.) > /src/sys/kern/vfs_cache.c: In function 'vn_fullpath1': > /src/sys/kern/vfs_cache.c:1180: error: 'fullpath' undeclared (first use in this function) > /src/sys/kern/vfs_cache.c:1189: error: invalid type argument of 'unary *' > *** Error code 1 Should be fixed by r193186. Sorry. --UYlS7R7B/6gq3w4G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoi5awACgkQC3+MBN1Mb4jNdACeMJlaOvPBYJv6OsEzLq3dSoE8 5AAAoI55KY44f7+REHcNdWEh70rkXbV3 =IaLv -----END PGP SIGNATURE----- --UYlS7R7B/6gq3w4G-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 16:32:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4D81065672 for ; Sun, 31 May 2009 16:32:53 +0000 (UTC) (envelope-from r.neese@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 1EDC88FC20 for ; Sun, 31 May 2009 16:32:53 +0000 (UTC) (envelope-from r.neese@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so804125rvb.3 for ; Sun, 31 May 2009 09:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=53RBZKQT3sVLm/TS0pVQEt4DamE7kVWFKfCg08m3M8s=; b=uCs+eJQh7rgOe3i9Aaj0PON7Vmyy8sr4PouIUQwPa0qfnESYByS3SutEx1wEK/OAsx uc/LRLx4WPu0ZYuZt2ySPqJvFFLtQP4WR9lBHt0P7oVh75dg1NGBErg2un42sHMkwQhX MOUGIBGg3plQ3PlcQFgEKcOVED6SZJWzsJhsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=mDjTY96duaLbSt6oJrVSvz9Am2Ko3OzDUrwsWFXiotPnIep/gdP/FxcfV98hna+yXY Fec7VG9guBmOZu77yQF60ynQwUk9a4vj6WvTiQ76ZFzg3hu1FbFs/UTpnZEnKSNMB0Mc ZGDe5hZuW1u7+eJpF5t2fgEQwfsuBr3Zt8xKA= Received: by 10.140.126.19 with SMTP id y19mr4928550rvc.115.1243785905455; Sun, 31 May 2009 09:05:05 -0700 (PDT) Received: from unixdawg-laptop.localnet (pool-96-235-0-144.pitbpa.east.verizon.net [96.235.0.144]) by mx.google.com with ESMTPS id b39sm10291098rvf.7.2009.05.31.09.05.04 (version=SSLv3 cipher=RC4-MD5); Sun, 31 May 2009 09:05:04 -0700 (PDT) From: Richard Neese To: freebsd-current@freebsd.org Date: Sun, 31 May 2009 12:05:02 -0400 User-Agent: KMail/1.11.2 (Linux/2.6.28-12-generic; KDE/4.2.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905311205.02507.r.neese@gmail.com> X-Mailman-Approved-At: Sun, 31 May 2009 21:00:25 +0000 Subject: making world on 7.2 to update to 8.0-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 16:32:53 -0000 when running make buildworld on 7.2 to update to 8.0 current I get the fallowing error ===> usr.bin/kdump (all) cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c /usr/src/usr.bin/kdump/kdump.c cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c ioctl.c: In function 'ioctlname': ioctl.c:1089: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:1405: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' ioctl.c:2679: error: invalid application of 'sizeof' to incomplete type 'struct vi_req' *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 switch-1# uname -a FreeBSD switch-1.daemonswitch.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue May 12 14:35:01 EDT 2009 root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER i386 Copyright (c) 1992-2009 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 7.2-RELEASE #0: Tue May 12 14:35:01 EDT 2009 root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ (2099.96-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 real memory = 518979584 (494 MB) avail memory = 498069504 (474 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 From owner-freebsd-current@FreeBSD.ORG Sun May 31 21:07:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B2A106566C for ; Sun, 31 May 2009 21:07:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 53FEC8FC1C for ; Sun, 31 May 2009 21:07:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 770F41CD2A; Sun, 31 May 2009 23:07:40 +0200 (CEST) Date: Sun, 31 May 2009 23:07:40 +0200 From: Ed Schouten To: Richard Neese Message-ID: <20090531210740.GI48776@hoeg.nl> References: <200905311205.02507.r.neese@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="REpkP7z4J/KxIT5U" Content-Disposition: inline In-Reply-To: <200905311205.02507.r.neese@gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current Subject: Re: making world on 7.2 to update to 8.0-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 21:07:42 -0000 --REpkP7z4J/KxIT5U Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Richard Neese wrote: > when running make buildworld on 7.2 to update to 8.0 current I get the=20 > fallowing error=20 Just update your sources and try again. Good luck! :-) --=20 Ed Schouten WWW: http://80386.nl/ --REpkP7z4J/KxIT5U Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoi8ZwACgkQ52SDGA2eCwU3WgCcDe7AGE4FgM9PeCkD3m4UAZm2 ozAAn3kXbqBOOzaqz91II12yZ2W6/pBu =jW1S -----END PGP SIGNATURE----- --REpkP7z4J/KxIT5U-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 21:10:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A32F106564A for ; Sun, 31 May 2009 21:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D8EDC8FC08 for ; Sun, 31 May 2009 21:10:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A11E241C756; Sun, 31 May 2009 23:10:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id W7JyFGVJ+HQA; Sun, 31 May 2009 23:10:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 5147F41C732; Sun, 31 May 2009 23:10:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 7810B4448E6; Sun, 31 May 2009 21:08:37 +0000 (UTC) Date: Sun, 31 May 2009 21:08:37 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Richard Neese In-Reply-To: <200905311205.02507.r.neese@gmail.com> Message-ID: <20090531210753.Y3234@maildrop.int.zabbadoz.net> References: <200905311205.02507.r.neese@gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: making world on 7.2 to update to 8.0-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 21:10:07 -0000 On Sun, 31 May 2009, Richard Neese wrote: > when running make buildworld on 7.2 to update to 8.0 current I get the > fallowing error That was a temp. build failure on CURRENT. You should update and try again. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sun May 31 21:49:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3E761065672; Sun, 31 May 2009 21:49:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id AB16E8FC13; Sun, 31 May 2009 21:49:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VLnUwR088355; Sun, 31 May 2009 17:49:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n4VLnUWa097657; Sun, 31 May 2009 17:49:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 650A47302F; Sun, 31 May 2009 17:49:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090531214930.650A47302F@freebsd-current.sentex.ca> Date: Sun, 31 May 2009 17:49:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 21:49:33 -0000 TB --- 2009-05-31 20:11:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-05-31 20:11:49 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-05-31 20:11:49 - cleaning the object tree TB --- 2009-05-31 20:12:04 - cvsupping the source tree TB --- 2009-05-31 20:12:04 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-05-31 20:12:13 - building world TB --- 2009-05-31 20:12:13 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 20:12:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 20:12:13 - TARGET=powerpc TB --- 2009-05-31 20:12:13 - TARGET_ARCH=powerpc TB --- 2009-05-31 20:12:13 - TZ=UTC TB --- 2009-05-31 20:12:13 - __MAKE_CONF=/dev/null TB --- 2009-05-31 20:12:13 - cd /src TB --- 2009-05-31 20:12:13 - /usr/bin/make -B buildworld >>> World build started on Sun May 31 20:12:14 UTC 2009 >>> 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 Sun May 31 21:37:41 UTC 2009 TB --- 2009-05-31 21:37:41 - generating LINT kernel config TB --- 2009-05-31 21:37:41 - cd /src/sys/powerpc/conf TB --- 2009-05-31 21:37:41 - /usr/bin/make -B LINT TB --- 2009-05-31 21:37:42 - building LINT kernel TB --- 2009-05-31 21:37:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-31 21:37:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-31 21:37:42 - TARGET=powerpc TB --- 2009-05-31 21:37:42 - TARGET_ARCH=powerpc TB --- 2009-05-31 21:37:42 - TZ=UTC TB --- 2009-05-31 21:37:42 - __MAKE_CONF=/dev/null TB --- 2009-05-31 21:37:42 - cd /src TB --- 2009-05-31 21:37:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun May 31 21:37:42 UTC 2009 >>> 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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/vfs_cache.c /src/sys/kern/vfs_cache.c: In function 'vn_vptocnp_locked': /src/sys/kern/vfs_cache.c:1075: error: 'startvp' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1075: error: (Each undeclared identifier is reported only once /src/sys/kern/vfs_cache.c:1075: error: for each function it appears in.) /src/sys/kern/vfs_cache.c: In function 'vn_fullpath1': /src/sys/kern/vfs_cache.c:1180: error: 'fullpath' undeclared (first use in this function) /src/sys/kern/vfs_cache.c:1189: error: invalid type argument of 'unary *' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-31 21:49:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-31 21:49:30 - ERROR: failed to build lint kernel TB --- 2009-05-31 21:49:30 - 4660.90 user 430.15 system 5860.25 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun May 31 21:55:53 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02140106566B; Sun, 31 May 2009 21:55:53 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from mail.moehre.org (mail.moehre.org [195.96.32.7]) by mx1.freebsd.org (Postfix) with ESMTP id 71A5E8FC0C; Sun, 31 May 2009 21:55:52 +0000 (UTC) (envelope-from coco@executive-computing.de) Received: from localhost (unknown [195.96.32.7]) by mail.moehre.org (Postfix) with ESMTP id 9B3FD4D4411; Sun, 31 May 2009 23:35:57 +0200 (CEST) X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.864, BAYES_00=-2.599] autolearn=ham Received: from mail.moehre.org ([195.96.32.7]) by localhost (mail.moehre.org [195.96.32.7]) (amavisd-new, port 10024) with ESMTP id WfSwQO+X2bWl; Sun, 31 May 2009 23:35:53 +0200 (CEST) Received: from probsd.c0c0.intra (p54B0CDD3.dip.t-dialin.net [84.176.205.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: coco@executive-computing.de) by mail.moehre.org (Postfix) with ESMTP id B644E4D440F; Sun, 31 May 2009 23:35:52 +0200 (CEST) Message-ID: <4A22F82C.1020902@executive-computing.de> Date: Sun, 31 May 2009 23:35:40 +0200 From: Marco Steinbach User-Agent: Thunderbird 2.0.0.16 (X11/20080928) MIME-Version: 1.0 To: Martin Wilke References: <20090527134343.GB1104@bsdcrew.de> In-Reply-To: <20090527134343.GB1104@bsdcrew.de> Content-Type: multipart/mixed; boundary="------------050106090308080209020506" Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 21:55:53 -0000 This is a multi-part message in MIME format. --------------050106090308080209020506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Howdy, [...] > > Happy Testing :-) [...] I've successfully migrated two Microsoft Windows 2003 Server Standard x64 Edition SP2 testing machines (running MS IIS, MS SQL Server and an inhouse application) from VMWare Server 1.0.9 on Wintel to virtualbox-2.2.2r1985 on a freshly installed FreeBSD/amd64 7.2-RELEASE with sources as of the day before yesterday. I'm using "Internal network" to connect both machines, and so far VirtualBox played nicely during my 24 hour testing run. As this is a lab machine, I'm in a position to fiddle with it at will; just tell me what you'd like to see tested, if anything. CPU is an AMD Athlon X2 Dual Core (4850e), 8GB RAM, mainboard is a MSI K9N Neo V3 and the graphics card is an ATI X550. I've attached the dmesg. Thank you for bringing VirtualBox to FreeBSD ! MfG CoCo --------------050106090308080209020506 Content-Type: text/plain; name="dmesg_amd64.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg_amd64.txt" Copyright (c) 1992-2009 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 7.2-RELEASE #0: Sat May 30 22:08:10 CEST 2009 root@amd64.c0c0.intra:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Processor model unknown (2487.35-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 usable memory = 8576651264 (8179 MB) avail memory = 8275107840 (7891 MB) ACPI APIC Table: <112007 APIC1437> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <112007 RSDT1437> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, fed40000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x2f00-0x2fff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe8ff000-0xfe8fffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfe8fec00-0xfe8fecff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered uhub2: on uhub1 uhub2: single transaction translator uhub2: 4 ports with 4 removable, self powered ums0: on uhub2 ums0: 6 buttons and Z dir. ukbd0: on uhub2 kbd2 at ukbd0 pci0: at device 7.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f mem 0xfe9ffc00-0xfe9ffc7f irq 16 at device 10.0 on pci1 miibus0: on xl0 xlphy0: <3Com internal media interface> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:d1:dc:9a xl0: [ITHREAD] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 9.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xf80-0xf87,0xf00-0xf03,0xe80-0xe87,0xe00-0xe03,0xa800-0xa80f mem 0xfe8fc000-0xfe8fdfff irq 20 at device 10.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:84:e5:8b re0: [FILTER] pcib4: at device 13.0 on pci0 pci4: on pcib4 vgapci0: port 0xe000-0xe0ff mem 0xd0000000-0xdfffffff,0xfebf0000-0xfebfffff irq 18 at device 0.0 on pci4 vgapci1: mem 0xfebe0000-0xfebeffff at device 0.1 on pci4 pcib5: at device 14.0 on pci0 pci5: on pcib5 acpi_button0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 device_attach: powernow1 attach returned 6 orm0: at iomem 0xc0000-0xccfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-slave UDMA100 ad4: 70911MB at ata2-master UDMA33 GEOM_LABEL: Label for provider ad4 is ufsid/480d2ea502086cea. ad6: 476940MB at ata3-master UDMA33 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider ad4s1a is ufsid/49f799813ea0cd84. GEOM_LABEL: Label for provider ad4s1d is ufsid/49f79982611d27c6. GEOM_LABEL: Label for provider ad4s1e is ufsid/49f799812c579861. GEOM_LABEL: Label for provider ad4s1f is ufsid/49f79982e4f05972. GEOM_LABEL: Label for provider ad4s1g is ufsid/49f79981ae90b18d. GEOM_LABEL: Label for provider ad6s1a is ufsid/4a21796b43811700. GEOM_LABEL: Label for provider ad6s1d is ufsid/4a21798334fc09fb. GEOM_LABEL: Label for provider ad6s1e is ufsid/4a21796bcafd5289. GEOM_LABEL: Label for provider ad6s1f is ufsid/4a217981cae1eba9. GEOM_LABEL: Label for provider ad6s1g is ufsid/4a21796bf2f7b23f. Trying to mount root from ufs:/dev/ad6s1a GEOM_LABEL: Label ufsid/4a21796b43811700 removed. GEOM_LABEL: Label for provider ad6s1a is ufsid/4a21796b43811700. GEOM_LABEL: Label ufsid/4a21796bcafd5289 removed. GEOM_LABEL: Label for provider ad6s1e is ufsid/4a21796bcafd5289. GEOM_LABEL: Label ufsid/4a21796bf2f7b23f removed. GEOM_LABEL: Label for provider ad6s1g is ufsid/4a21796bf2f7b23f. GEOM_LABEL: Label ufsid/4a217981cae1eba9 removed. GEOM_LABEL: Label for provider ad6s1f is ufsid/4a217981cae1eba9. GEOM_LABEL: Label ufsid/4a21798334fc09fb removed. GEOM_LABEL: Label for provider ad6s1d is ufsid/4a21798334fc09fb. GEOM_LABEL: Label ufsid/4a21796b43811700 removed. GEOM_LABEL: Label ufsid/4a21796bcafd5289 removed. GEOM_LABEL: Label ufsid/4a21796bf2f7b23f removed. GEOM_LABEL: Label ufsid/4a217981cae1eba9 removed. GEOM_LABEL: Label ufsid/4a21798334fc09fb removed. re0: link state changed to UP GEOM_LABEL: Label ufsid/480d2ea502086cea removed. GEOM_LABEL: Label ufsid/49f79981ae90b18d removed. GEOM_LABEL: Label ufsid/49f79982e4f05972 removed. GEOM_LABEL: Label ufsid/49f799812c579861 removed. GEOM_LABEL: Label ufsid/49f79982611d27c6 removed. GEOM_LABEL: Label ufsid/49f799813ea0cd84 removed. GEOM_LABEL: Label for provider ad4 is ufsid/480d2ea502086cea. GEOM_LABEL: Label ufsid/480d2ea502086cea removed. GEOM_LABEL: Label for provider ad4 is ufsid/480d2ea502086cea. GEOM_LABEL: Label for provider ad4s1 is ufsid/4a22affdfa67615f. GEOM_LABEL: Label ufsid/480d2ea502086cea removed. GEOM_LABEL: Label ufsid/4a22affdfa67615f removed. GEOM_LABEL: Label for provider ad4 is ufsid/480d2ea502086cea. GEOM_LABEL: Label for provider ad4s1 is ufsid/4a22affdfa67615f. GEOM_LABEL: Label ufsid/480d2ea502086cea removed. GEOM_LABEL: Label ufsid/4a22affdfa67615f removed. drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] --------------050106090308080209020506-- From owner-freebsd-current@FreeBSD.ORG Sun May 31 22:24:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F151065674 for ; Sun, 31 May 2009 22:24:50 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7DA258FC27 for ; Sun, 31 May 2009 22:24:50 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MAtSS-0003G2-9T for freebsd-current@freebsd.org; Sun, 31 May 2009 22:24:49 +0000 Received: from 200.41.broadband11.iol.cz ([90.178.41.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 May 2009 22:24:48 +0000 Received: from gamato by 200.41.broadband11.iol.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 May 2009 22:24:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: martinko Date: Mon, 01 Jun 2009 00:24:36 +0200 Lines: 18 Message-ID: References: <200902100908.n1A989IJ034744@lurza.secnetix.de> <49923B2F.2080804@mawer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 200.41.broadband11.iol.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.18) Gecko/20081125 SeaMonkey/1.1.13 In-Reply-To: <49923B2F.2080804@mawer.org> Sender: news Subject: Re: CFT: Graphics support for /boot/loader X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 22:24:51 -0000 Antony Mawer wrote: > Do you know if it would be hard to modify splash(4) to supports 640x480 > 4-bit images? At the moment, according to the man page: > > "If the standard VGA video mode is used, the size of the bitmap must > be 320x200 or less." > > I would find a 640x480 image with a custom 16 colour palette and > appropriate dithering much more attractive than the current 320x200 but > with 256 colours offering (ignoring VESA, which seems to have varied > levels of support). > > At the moment, a 640x480 4-bit image is just gives me a blank screen > unless I load the VESA module (and on a VESA capable machine) also VESA is unsupported on amd64 :-/ and even with VESA splash(4) limits images to 1024x768 :-( From owner-freebsd-current@FreeBSD.ORG Sun May 31 22:43:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA83B106567F; Sun, 31 May 2009 22:43:23 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A59858FC0C; Sun, 31 May 2009 22:43:23 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAtkR-000DpY-8T; Sun, 31 May 2009 22:43:23 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id BAB101C9CC4C; Mon, 1 Jun 2009 07:43:22 +0900 (JST) Date: Mon, 01 Jun 2009 07:43:22 +0900 Message-ID: From: Randy Bush To: Robert Watson In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Current Subject: Re: yakpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 22:43:25 -0000 > Is it possible to use options KDB_TRACE and KDB_PANIC to dump a stack > trace to the serial console to use as a starting point for debugging? increase size or weight of clue bat please. /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 randy From owner-freebsd-current@FreeBSD.ORG Sun May 31 23:52:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 237D6106566B for ; Sun, 31 May 2009 23:52:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 03AEB8FC1C for ; Sun, 31 May 2009 23:52:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAuov-000Dvs-4D for current@freebsd.org; Sun, 31 May 2009 23:52:05 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 980851CA21BA for ; Mon, 1 Jun 2009 08:52:04 +0900 (JST) Date: Mon, 01 Jun 2009 08:52:04 +0900 Message-ID: From: Randy Bush To: current User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: lor vfs_bio/ufs_dirhash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 May 2009 23:52:06 -0000 FreeBSD xx 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Sun May 31 22:52:41 UTC 2009 root@xx:/usr/obj/usr/src/sys/XXXX amd64 i think this may be different than 261 sorry, this is all i got on serial console randy --- lock order reversal: 1st 0xffffff8052aba050 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2556 2nd 0xffffff0004f53000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x31c VOP_CREATE_APV() at VOP_CREATE_APV+0xb1 vn_open_cred() at vn_open_cred+0x3fd kern_openat() at kern_openat+0x159 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (5, FreeBSD ELF64, open), rip = 0x800c0bfcc, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe860 --- -30- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:26:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2785B106566C for ; Mon, 1 Jun 2009 00:26:37 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D9FEC8FC08 for ; Mon, 1 Jun 2009 00:26:36 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAvMH-000EFq-EX; Mon, 01 Jun 2009 00:26:34 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id B2A781CA5108; Mon, 1 Jun 2009 09:26:32 +0900 (JST) Date: Mon, 01 Jun 2009 09:26:32 +0900 Message-ID: From: Randy Bush To: Kip Macy In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:26:37 -0000 and again, but i got a debugger prompt! swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swap_pager_getsw eaatalp trsapp 1a2: pcagee (fault whi3le )in: ke rnfela moidel udcp id s=w a1;p a_pipc aidge = r01_ fagulte vtirtsuawl aaddpresssp = a0x0c d a(ul3t )co:de =f suaperivlisoer rdea datsa,w paagep n_otp paregseernt _ingsterutctisonw paointpers =p 0ax2c0:0exf(ff3fff)ff:80a4eac0 stack pointer = 0x28:0xffffff807a02eab0 frame pointer = 0x28:0xffffff807 a0fa2ielace0 ecod ssegwmeant p =_ bpasae g0xe0,r l_imgite 0txfsfffwfa, tpypes 0px1ab de e=( D1PL6 0), :pr es f1,a illoneg 1d, f3s2 w0, agrapn _1 pproacegsseorr e_flaggs e= tinstewrrauptp esnabpleda, creesum(e,3 )IO:PL =f 0 cesirrelnte pdro s s = w148a (pspa__zipo) a[thread pid 148 tid 100134 ] Stopped at fletcher_2_native+0x20: addq (%rdi),%rcx db> trace Tracing pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- db> alltrace Tracing command nfprofile pid 3400 tid 100316 td 0xffffff0076469000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_getswapspace() at swp_pager_getswapspace+0x34 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_contig_launder() at vm_contig_launder+0x1de zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_read() at dbuf_read+0x1e9 dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x9a dmu_tx_count_write() at dmu_tx_count_write+0x291 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (4, FreeBSD ELF64, write), rip = 0x80088016c, rsp = 0x7fffffffe388, rbp = 0x9 --- Tracing command exim-4.69-3 pid 3375 tid 100300 td 0xffffff0080204000 Tracing command exim-4.69-3 pid 3373 tid 100306 td 0xffffff0076416ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command perl pid 3367 tid 100299 td 0xffffff0080204390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_lock_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1 swp_pager_strategy() at swp_pager_strategy+0x24 swap_pager_getpages() at swap_pager_getpages+0x31f vm_fault() at vm_fault+0x653 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8006dbeca, rsp = 0x7fffffffeb60, rbp = 0x10c1ff8 --- Tracing command exim-4.69-3 pid 3366 tid 100308 td 0xffffff0076416390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip = 0x80143c86c, rsp = 0x7fffffffe188, rbp = 0xd --- Tracing command sh pid 3365 tid 100307 td 0xffffff0076416720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9d8, rbp = 0xd25 --- Tracing command cron pid 3364 tid 100161 td 0xffffff0006aeaab0 Tracing command httpd pid 3359 tid 100199 td 0xffffff0006f66720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3358 tid 100287 td 0xffffff0080207390 Tracing command httpd pid 3357 tid 100327 td 0xffffff00148e1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3348 tid 100231 td 0xffffff0076469390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 3346 tid 100089 td 0xffffff0006072ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command exim-4.69-3 pid 3345 tid 100304 td 0xffffff0080222720 Tracing command exim-4.69-3 pid 3344 tid 100295 td 0xffffff0080205390 Tracing command exim_tidydb pid 3343 tid 100321 td 0xffffff009a115000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x800d7f8f4, rsp = 0x7fffffffe748, rbp = 0x3000 --- Tracing command sh pid 3341 tid 100297 td 0xffffff0080204ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe678, rbp = 0x8a9 --- Tracing command httpd pid 2331 tid 100069 td 0xffffff0004fb2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command mail pid 2227 tid 100278 td 0xffffff0080223ab0 Tracing command sh pid 2226 tid 100150 td 0xffffff0006b05390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe558, rbp = 0x8a9 --- Tracing command sh pid 2225 tid 100280 td 0xffffff0080223390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe238, rbp = 0x8a9 --- Tracing command sh pid 2218 tid 100274 td 0xffffff0066a07390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command sh pid 2217 tid 100312 td 0xffffff00ce0a7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800932e4c, rsp = 0x7fffffffe9f8, rbp = 0x8a9 --- Tracing command cron pid 2216 tid 100185 td 0xffffff0006f70000 Tracing command sshguard pid 2135 tid 100315 td 0xffffff009a114ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80084139c, rsp = 0x7fffffbfef38, rbp = 0x4a231c83 --- Tracing command sshguard pid 2135 tid 100284 td 0xffffff0080222000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe pipe_read() at pipe_read+0x2c4 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x80085e18c, rsp = 0x7fffffffe878, rbp = 0x1 --- Tracing command httpd pid 2104 tid 100285 td 0xffffff0080207ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x8052d3480, rsp = 0x7fffffffe8b8, rbp = 0x805bc1218 --- Tracing command httpd pid 1839 tid 100251 td 0xffffff0066a08ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command emacs pid 1647 tid 100290 td 0xffffff0080206720 Tracing command httpd pid 1615 tid 100296 td 0xffffff0080205000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command httpd pid 1612 tid 100298 td 0xffffff0080204720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9f8, rbp = 0x7fffffffea7c --- Tracing command bash pid 1466 tid 100232 td 0xffffff005700a390 Tracing command sshd pid 1464 tid 100238 td 0xffffff0066a0f000 Tracing command inet_gethost pid 1455 tid 100277 td 0xffffff005700d720 Tracing command inet_gethost pid 1454 tid 100276 td 0xffffff005700dab0 Tracing command inet_gethost pid 1453 tid 100091 td 0xffffff0006072390 Tracing command inet_gethost pid 1452 tid 100247 td 0xffffff0066a0bab0 Tracing command inet_gethost pid 1451 tid 100275 td 0xffffff0066a07000 Tracing command getty pid 1440 tid 100227 td 0xffffff005700b720 Tracing command getty pid 1439 tid 100244 td 0xffffff0066a0c720 Tracing command getty pid 1438 tid 100248 td 0xffffff0066a0b720 Tracing command getty pid 1437 tid 100166 td 0xffffff000639dab0 Tracing command getty pid 1436 tid 100233 td 0xffffff005700a000 Tracing command getty pid 1435 tid 100240 td 0xffffff0066a0e720 Tracing command getty pid 1434 tid 100246 td 0xffffff0066a0c000 Tracing command getty pid 1433 tid 100245 td 0xffffff0066a0c390 Tracing command getty pid 1432 tid 100243 td 0xffffff0066a0cab0 Tracing command getty pid 1431 tid 100242 td 0xffffff0066a0e000 Tracing command perl5.8.9 pid 1392 tid 100237 td 0xffffff0066a0f390 Tracing command perl5.8.9 pid 1391 tid 100239 td 0xffffff0066a0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x800c1fe4c, rsp = 0x7fffffffeb08, rbp = 0x7fffffffeb9c --- Tracing command nfcapd pid 1389 tid 100158 td 0xffffff0006aeb720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command nfcapd pid 1386 tid 100203 td 0xffffff004851a720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF64, recvfrom), rip = 0x800839a3c, rsp = 0x7fffffffddd8, rbp = 0x802900000 --- Tracing command perl5.8.9 pid 1383 tid 100236 td 0xffffff0004fde390 Tracing command perl5.8.9 pid 1382 tid 100230 td 0xffffff005700aab0 Tracing command perl5.8.9 pid 1381 tid 100235 td 0xffffff0048145720 Tracing command httpd pid 1379 tid 100178 td 0xffffff00067feab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip = 0x801294eac, rsp = 0x7fffffffe9d8, rbp = 0x7fffffffea5c --- Tracing command perl5.8.9 pid 1375 tid 100202 td 0xffffff004851aab0 Tracing command httpd pid 1374 tid 100082 td 0xffffff0004fadab0 Tracing command dhcpd pid 1368 tid 100224 td 0xffffff005700c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007af10c, rsp = 0x7fffffffea38, rbp = 0x8 --- Tracing command cron pid 1357 tid 100229 td 0xffffff005700b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80093739c, rsp = 0x7fffffffeb28, rbp = 0x2c --- Tracing command sshd pid 1347 tid 100228 td 0xffffff005700b390 Tracing command httpd pid 1323 tid 100225 td 0xffffff005700c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80130510c, rsp = 0x7fffffffea48, rbp = 0 --- Tracing command sc_serv pid 1321 tid 100219 td 0xffffff005700d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1320 tid 100218 td 0xffffff005700d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1319 tid 100217 td 0xffffff0006f70720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1318 tid 100216 td 0xffffff0006f70ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1317 tid 100215 td 0xffffff0048162000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1316 tid 100214 td 0xffffff0048162390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1315 tid 100213 td 0xffffff0048162720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1314 tid 100212 td 0xffffff0048162ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1313 tid 100211 td 0xffffff0048422000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1312 tid 100177 td 0xffffff0006f28000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x354ca79c, rbp = 0 --- Tracing command sc_serv pid 1311 tid 100182 td 0xffffff0006b05ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x314cc40c, rbp = 0x7d0 --- Tracing command sc_serv pid 1310 tid 100171 td 0xffffff0006ec9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2d4cc3ec, rbp = 0x2d4cc440 --- Tracing command asterisk pid 1303 tid 100271 td 0xffffff0066a0fab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800e0439c, rsp = 0x7fffff7f1b78, rbp = 0x7fffff7f1c70 --- Tracing command asterisk pid 1303 tid 100267 td 0xffffff00765a9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffff82eea8, rbp = 0 --- Tracing command asterisk pid 1303 tid 100266 td 0xffffff00765aa000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 do_cv_wait() at do_cv_wait+0x57a __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff86be28, rbp = 0x8010060c0 --- Tracing command asterisk pid 1303 tid 100265 td 0xffffff00765aa390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8a8d98, rbp = 0x801006280 --- Tracing command asterisk pid 1303 tid 100264 td 0xffffff00765aa720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff8e5d98, rbp = 0x801006440 --- Tracing command asterisk pid 1303 tid 100263 td 0xffffff00765aaab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff922d98, rbp = 0x801006600 --- Tracing command asterisk pid 1303 tid 100262 td 0xffffff00765ab000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff95fd98, rbp = 0x8010067c0 --- Tracing command asterisk pid 1303 tid 100261 td 0xffffff00765ab390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff99cd98, rbp = 0x801006980 --- Tracing command asterisk pid 1303 tid 100260 td 0xffffff00765ab720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffff9d9d98, rbp = 0x801006b40 --- Tracing command asterisk pid 1303 tid 100259 td 0xffffff00765abab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa16d98, rbp = 0x801006d00 --- Tracing command asterisk pid 1303 tid 100258 td 0xffffff00765ad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa53d98, rbp = 0x801006ec0 --- Tracing command asterisk pid 1303 tid 100257 td 0xffffff00765ad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffa90d98, rbp = 0x801007080 --- Tracing command asterisk pid 1303 tid 100256 td 0xffffff0004fb2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffacdd98, rbp = 0x801007240 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb0aec8, rbp = 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb47e68, rbp = 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffb84ee8, rbp = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800c2e1ec, rsp = 0x7fffffbc1e98, rbp = 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffbfee38, rbp = 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800dcb53c, rsp = 0x7fffffffe948, rbp = 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80144e10c, rsp = 0x7fffffffe6f8, rbp = 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeaf2be8, rbp = 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb33be8, rbp = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffeb74be8, rbp = 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = 0x8014a218c, rsp = 0x7ffffebb5be8, rbp = 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip = 0x801409a9c, rsp = 0x7ffffebf6f08, rbp = 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7ffffedf7e88, rbp = 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7ffffeff8f18, rbp = 0 --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffff1f9f08, rbp = 0 --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff5fbbc8, rbp = 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff7fcbc8, rbp = 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffff9fdbc8, rbp = 0x801608c80 --- Tracing command mysqld pid 1288 tid 100207 td 0xffffff004851a000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x8012af1ec, rsp = 0x7fffffbfebc8, rbp = 0x801608e40 --- Tracing command mysqld pid 1288 tid 100116 td 0xffffff0006049ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x8014a210c, rsp = 0x7fffffffe558, rbp = 0xb --- Tracing command sc_serv pid 1266 tid 100198 td 0xffffff0006f66ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1265 tid 100197 td 0xffffff00480ac000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1264 tid 100186 td 0xffffff00480a8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1263 tid 100187 td 0xffffff00480a8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1262 tid 100196 td 0xffffff00480ac390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1261 tid 100092 td 0xffffff0006072000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1260 tid 100195 td 0xffffff00480ac720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3474f79c, rbp = 0 --- Tracing command sc_serv pid 1259 tid 100194 td 0xffffff00480acab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x3075140c, rbp = 0x7d0 --- Tracing command sc_serv pid 1258 tid 100193 td 0xffffff0006e39000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c7513ec, rbp = 0x2c751440 --- Tracing command sc_serv pid 1257 tid 100192 td 0xffffff0006e39390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1256 tid 100191 td 0xffffff0006e39720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1255 tid 100190 td 0xffffff0006e39ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1254 tid 100189 td 0xffffff00480a8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1253 tid 100188 td 0xffffff00480a8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1252 tid 100078 td 0xffffff0006022390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1251 tid 100179 td 0xffffff00067fe720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x344f779c, rbp = 0 --- Tracing command sc_serv pid 1250 tid 100184 td 0xffffff0006f70390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x304f940c, rbp = 0x7d0 --- Tracing command sc_serv pid 1249 tid 100167 td 0xffffff000639d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0x2c4f93ec, rbp = 0x2c4f9440 --- Tracing command sc_serv pid 1139 tid 100165 td 0xffffff0006aea000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1134 tid 100162 td 0xffffff0006aea720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1129 tid 100100 td 0xffffff0006044000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1124 tid 100121 td 0xffffff00060cf720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1119 tid 100099 td 0xffffff0006044390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1114 tid 100079 td 0xffffff0004fb0000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1109 tid 100098 td 0xffffff0006044720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1104 tid 100153 td 0xffffff0006b04720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1099 tid 100120 td 0xffffff00060cfab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1094 tid 100115 td 0xffffff0006099000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1089 tid 100075 td 0xffffff0004fb0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1084 tid 100074 td 0xffffff0004fb0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd73c, rbp = 0xffffddc8 --- Tracing command sc_serv pid 1079 tid 100085 td 0xffffff0004fad390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1074 tid 100154 td 0xffffff0006b04390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command sc_serv pid 1069 tid 100114 td 0xffffff0006099390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = 0x2814ef27, rsp = 0xffffd74c, rbp = 0xffffddd8 --- Tracing command irrd pid 1058 tid 100102 td 0xffffff000609d390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80088e10c, rsp = 0x7fffffffda48, rbp = 0x400 --- Tracing command beam pid 1051 tid 100155 td 0xffffff0006021390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x800b931ec, rsp = 0x7fffffbfee88, rbp = 0x800f08e40 --- Tracing command beam pid 1051 tid 100093 td 0xffffff000604cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x4e9067, rsp = 0x7fffffffc260, rbp = 0x7fffffffc290 --- Tracing command epmd pid 1049 tid 100117 td 0xffffff0006049720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x80096810c, rsp = 0x7fffffffe8c8, rbp = 0x3ff --- Tracing command ntpd pid 999 tid 100086 td 0xffffff0004fad000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d4910c, rsp = 0x7fffffffec18, rbp = 0x7fffffffed40 --- Tracing command smartd pid 941 tid 100084 td 0xffffff0006021720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800ca039c, rsp = 0x7fffffffeaa8, rbp = 0x4a231d9b --- Tracing command tac_plus pid 922 tid 100151 td 0xffffff0006b05000 Tracing command md0 pid 853 tid 100090 td 0xffffff0006072720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b md_kthread() at md_kthread+0x15a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f52d40, rbp = 0 --- Tracing command unbound pid 816 tid 100096 td 0xffffff000604c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x44eb53, rsp = 0x7fffffffe408, rbp = 0x80173b650 --- Tracing command syslogd pid 787 tid 100070 td 0xffffff0004fb1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_contig_launder() at vm_contig_launder+0xb5 zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+0xae dbuf_hold_impl() at dbuf_hold_impl+0x1ea dbuf_hold_level() at dbuf_hold_level+0x1a dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x52 dmu_tx_count_write() at dmu_tx_count_write+0x178 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 writev() at writev+0x41 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (121, FreeBSD ELF64, writev), rip = 0x800834d3c, rsp = 0x7fffffffcaf8, rbp = 0 --- Tracing command devd pid 665 tid 100073 td 0xffffff0004fb1000 Tracing command zil_clean pid 179 tid 100113 td 0xffffff0006099720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc5d40, rbp = 0 --- Tracing command zil_clean pid 178 tid 100083 td 0xffffff0004fad720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f2fd40, rbp = 0 --- Tracing command zil_clean pid 177 tid 100112 td 0xffffff0006099ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fc0d40, rbp = 0 --- Tracing command zil_clean pid 176 tid 100111 td 0xffffff000609b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fbbd40, rbp = 0 --- Tracing command zil_clean pid 175 tid 100109 td 0xffffff000609b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb1d40, rbp = 0 --- Tracing command zil_clean pid 174 tid 100080 td 0xffffff0006022000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f20d40, rbp = 0 --- Tracing command zil_clean pid 173 tid 100108 td 0xffffff000609bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079facd40, rbp = 0 --- Tracing command zil_clean pid 172 tid 100104 td 0xffffff000609cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f98d40, rbp = 0 --- Tracing command zil_clean pid 171 tid 100072 td 0xffffff0004fb1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ef8d40, rbp = 0 --- Tracing command zil_clean pid 170 tid 100110 td 0xffffff000609b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fb6d40, rbp = 0 --- Tracing command txg_thread_enter pid 168 tid 100107 td 0xffffff000609c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a zio_wait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xee spa_sync() at spa_sync+0x355 txg_sync_thread() at txg_sync_thread+0x28f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a07dd40, rbp = 0 --- Tracing command txg_thread_enter pid 167 tid 100106 td 0xffffff000609c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079fa2d40, rbp = 0 --- Tracing command vdev:worker ad10s1 pid 166 tid 100105 td 0xffffff000609c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f9dd40, rbp = 0 --- Tracing command vdev:worker ad6s1 pid 165 tid 100077 td 0xffffff0004fb0390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f11d40, rbp = 0 --- Tracing command vdev:worker ad8s2 pid 164 tid 100087 td 0xffffff0006049390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079f43d40, rbp = 0 --- Tracing command vdev:worker ad4s2 pid 163 tid 100149 td 0xffffff00060d0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a079d40, rbp = 0 --- Tracing command spa_zio pid 162 tid 100148 td 0xffffff00060d0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a074d40, rbp = 0 --- Tracing command spa_zio pid 161 tid 100147 td 0xffffff0006399000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06fd40, rbp = 0 --- Tracing command spa_zio pid 160 tid 100146 td 0xffffff0006399390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a06ad40, rbp = 0 --- Tracing command spa_zio pid 159 tid 100145 td 0xffffff0006399720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a065d40, rbp = 0 --- Tracing command spa_zio pid 158 tid 100144 td 0xffffff0006399ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a060d40, rbp = 0 --- Tracing command spa_zio pid 157 tid 100143 td 0xffffff000639b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a05bd40, rbp = 0 --- Tracing command spa_zio pid 156 tid 100142 td 0xffffff000639b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a056d40, rbp = 0 --- Tracing command spa_zio pid 155 tid 100141 td 0xffffff000639b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a051d40, rbp = 0 --- Tracing command spa_zio pid 154 tid 100140 td 0xffffff000639bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a04cd40, rbp = 0 --- Tracing command spa_zio pid 153 tid 100139 td 0xffffff000639c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a047d40, rbp = 0 --- Tracing command spa_zio pid 152 tid 100138 td 0xffffff000639c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a042d40, rbp = 0 --- Tracing command spa_zio pid 151 tid 100137 td 0xffffff000639c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a03dd40, rbp = 0 --- Tracing command spa_zio pid 150 tid 100136 td 0xffffff000639cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sx_xlock_hard() at _sx_xlock_hard+0x1a7 _sx_xlock() at _sx_xlock+0xc1 dbuf_write_ready() at dbuf_write_ready+0xbf arc_write_ready() at arc_write_ready+0x2c zio_ready() at zio_ready+0x3a zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a038d40, rbp = 0 --- Tracing command spa_zio pid 149 tid 100135 td 0xffffff000639d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a033d40, rbp = 0 --- Tracing command spa_zio pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a02ed40, rbp = 0 --- Tracing command spa_zio pid 147 tid 100133 td 0xffffff000609d720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a029d40, rbp = 0 --- Tracing command spa_zio pid 146 tid 100132 td 0xffffff000609dab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a024d40, rbp = 0 --- Tracing command spa_zio pid 145 tid 100131 td 0xffffff00060c8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01fd40, rbp = 0 --- Tracing command spa_zio pid 144 tid 100130 td 0xffffff00060c8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a01ad40, rbp = 0 --- Tracing command spa_zio pid 143 tid 100129 td 0xffffff00060c8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a015d40, rbp = 0 --- Tracing command spa_zio pid 142 tid 100128 td 0xffffff00060c8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a010d40, rbp = 0 --- Tracing command spa_zio pid 141 tid 100127 td 0xffffff00060ca000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a00bd40, rbp = 0 --- Tracing command spa_zio pid 140 tid 100126 td 0xffffff00060ca390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a006d40, rbp = 0 --- Tracing command spa_zio pid 139 tid 100125 td 0xffffff00060ca720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807a001d40, rbp = 0 --- Tracing command spa_zio pid 138 tid 100124 td 0xffffff00060caab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ffcd40, rbp = 0 --- Tracing command spa_zio pid 137 tid 100123 td 0xffffff00060cf000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8079ff7d40, rbp = 0 --- Tracing command flowcleaner pid 44 tid 100068 td 0xffffff0004f0b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 flowtable_cleaner() at flowtable_cleaner+0x13a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077be1d40, rbp = 0 --- Tracing command softdepflush pid 43 tid 100067 td 0xffffff0004f0b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 softdep_flush() at softdep_flush+0x2c0 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bdcd40, rbp = 0 --- Tracing command syncer pid 42 tid 100066 td 0xffffff0004f0b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c sched_sync() at sched_sync+0x4de fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd7d40, rbp = 0 --- Tracing command vnlru pid 41 tid 100065 td 0xffffff0004f0bab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vnlru_proc() at vnlru_proc+0x607 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bd2d40, rbp = 0 --- Tracing command vaclean pid 40 tid 100064 td 0xffffff0004f0c000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c vn_rele_async_cleaner() at vn_rele_async_cleaner+0x119 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bcdd40, rbp = 0 --- Tracing command bufdaemon pid 39 tid 100063 td 0xffffff0004f0c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 buf_daemon() at buf_daemon+0x14a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc8d40, rbp = 0 --- Tracing command pagezero pid 38 tid 100062 td 0xffffff0004f0c720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 vm_pagezero() at vm_pagezero+0x73 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bc3d40, rbp = 0 --- Tracing command vmdaemon pid 37 tid 100061 td 0xffffff0004f0cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bbed40, rbp = 0 --- Tracing command pagedaemon pid 36 tid 100060 td 0xffffff0004f0e000 cpustop_handler() at cpustop_handler+0x3b ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x1b8 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8049f404, rsp = 0xffffffff808e6820, rbp = 0xffffff8077bb94b0 --- DELAY() at DELAY+0x64 ns8250_putc() at ns8250_putc+0x9a uart_cnputc() at uart_cnputc+0x4e cnputc() at cnputc+0x49 putchar() at putchar+0x6a kvprintf() at kvprintf+0x81 vprintf() at vprintf+0x3e printf() at printf+0x67 swp_pager_getswapspace() at swp_pager_getswapspace+0xc7 swap_pager_putpages() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_pageout_clean() at vm_pageout_clean+0xfc vm_pageout() at vm_pageout+0x1168 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb9d40, rbp = 0 --- Tracing command g_mirror boot pid 35 tid 100059 td 0xffffff0004f0e390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b g_mirror_worker() at g_mirror_worker+0xb1c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bb4d40, rbp = 0 --- Tracing command l2arc_feed_thread pid 34 tid 100058 td 0xffffff0004f0e720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c l2arc_feed_thread() at l2arc_feed_thread+0x169 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077bafd40, rbp = 0 --- Tracing command arc_reclaim_thread pid 9 tid 100057 td 0xffffff0004f0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c arc_reclaim_thread() at arc_reclaim_thread+0x2ba fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077baad40, rbp = 0 --- Tracing command usbus4 pid 33 tid 100056 td 0xffffff0004ec6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba5d40, rbp = 0 --- Tracing command usbus4 pid 32 tid 100055 td 0xffffff0004ec6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077ba0d40, rbp = 0 --- Tracing command usbus4 pid 31 tid 100054 td 0xffffff0004ec6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b9bd40, rbp = 0 --- Tracing command usbus4 pid 30 tid 100053 td 0xffffff0004ee8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b96d40, rbp = 0 --- Tracing command usbus3 pid 29 tid 100052 td 0xffffff0004ee8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b91d40, rbp = 0 --- Tracing command usbus3 pid 28 tid 100051 td 0xffffff0004ee8720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b8cd40, rbp = 0 --- Tracing command usbus3 pid 27 tid 100050 td 0xffffff0004ee8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b87d40, rbp = 0 --- Tracing command usbus3 pid 26 tid 100049 td 0xffffff0004ee9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b82d40, rbp = 0 --- Tracing command usbus2 pid 25 tid 100048 td 0xffffff0004ee9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b7dd40, rbp = 0 --- Tracing command usbus2 pid 24 tid 100047 td 0xffffff0004ee9720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b78d40, rbp = 0 --- Tracing command usbus2 pid 23 tid 100046 td 0xffffff0004ee9ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b73d40, rbp = 0 --- Tracing command usbus2 pid 22 tid 100045 td 0xffffff00015b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b6ed40, rbp = 0 --- Tracing command usbus1 pid 21 tid 100044 td 0xffffff0004ec3000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b69d40, rbp = 0 --- Tracing command usbus1 pid 20 tid 100043 td 0xffffff0004ec3390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b64d40, rbp = 0 --- Tracing command usbus1 pid 19 tid 100042 td 0xffffff0004ec3720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5fd40, rbp = 0 --- Tracing command usbus1 pid 18 tid 100041 td 0xffffff0004ec3ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b5ad40, rbp = 0 --- Tracing command usbus0 pid 17 tid 100040 td 0xffffff0004ec4000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b55d40, rbp = 0 --- Tracing command usbus0 pid 16 tid 100039 td 0xffffff0004ec4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b50d40, rbp = 0 --- Tracing command usbus0 pid 15 tid 100038 td 0xffffff0004ec4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b4bd40, rbp = 0 --- Tracing command usbus0 pid 14 tid 100037 td 0xffffff0004ec4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b46d40, rbp = 0 --- Tracing command sctp_iterator pid 8 tid 100036 td 0xffffff0004ec6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b sctp_iterator_thread() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b41d40, rbp = 0 --- Tracing command xpt_thrd pid 7 tid 100020 td 0xffffff0001563000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b xpt_scanner_thread() at xpt_scanner_thread+0x3a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000076d40, rbp = 0 --- Tracing command system_taskq pid 6 tid 100015 td 0xffffff00014d1720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800005dd40, rbp = 0 --- Tracing command system_taskq pid 5 tid 100014 td 0xffffff00014d1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000058d40, rbp = 0 --- Tracing command yarrow pid 13 tid 100013 td 0xffffff00014d2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 random_kthread() at random_kthread+0x1ad fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000053d40, rbp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xffffff00014b6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_down() at g_io_schedule_down+0x250 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000049d40, rbp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xffffff00014b6720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_up() at g_io_schedule_up+0x154 g_up_procbody() at g_up_procbody+0x6f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000044d40, rbp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xffffff00014b6ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_event_procbody() at g_event_procbody+0xa1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003fd40, rbp = 0 --- Tracing command intr pid 12 tid 100035 td 0xffffff0001563720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8077b39d40, rbp = 0 --- Tracing command intr pid 12 tid 100034 td 0xffffff0001563ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100033 td 0xffffff00015b2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075b6fd40, rbp = 0 --- Tracing command intr pid 12 tid 100032 td 0xffffff00015b2390 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100031 td 0xffffff00015b2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xffffff00015b2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807566ad40, rbp = 0 --- Tracing command intr pid 12 tid 100029 td 0xffffff00015b4000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100026 td 0xffffff00014d2720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100021 td 0xffffff0001561ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100019 td 0xffffff0001563390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000071d40, rbp = 0 --- Tracing command intr pid 12 tid 100018 td 0xffffff00014c7ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100016 td 0xffffff00014d1390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000062d40, rbp = 0 --- Tracing command intr pid 12 tid 100008 td 0xffffff00014c7000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800003ad40, rbp = 0 --- Tracing command intr pid 12 tid 100007 td 0xffffff00014c7390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000035d40, rbp = 0 --- Tracing command intr pid 12 tid 100006 td 0xffffff00014c7720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000030d40, rbp = 0 --- Tracing command intr pid 12 tid 100005 td 0xffffff00014b4000 fork_trampoline() at fork_trampoline Tracing command idle pid 11 tid 100004 td 0xffffff00014b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000026d40, rbp = 0 --- Tracing command idle pid 11 tid 100003 td 0xffffff00014b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000021d40, rbp = 0 --- Tracing command init pid 1 tid 100002 td 0xffffff00014b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x40c62c, rsp = 0x7fffffffe808, rbp = 0x401d40 --- Tracing command audit pid 10 tid 100001 td 0xffffff00014b6000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a audit_worker() at audit_worker+0x77 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000017d40, rbp = 0 --- Tracing command kernel pid 0 tid 100028 td 0xffffff00015b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800009ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100027 td 0xffffff00015b4720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000099d40, rbp = 0 --- Tracing command kernel pid 0 tid 100025 td 0xffffff00014d2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008fd40, rbp = 0 --- Tracing command kernel pid 0 tid 100024 td 0xffffff0001561000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800008ad40, rbp = 0 --- Tracing command kernel pid 0 tid 100023 td 0xffffff0001561390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000085d40, rbp = 0 --- Tracing command kernel pid 0 tid 100022 td 0xffffff0001561720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000080d40, rbp = 0 --- Tracing command kernel pid 0 tid 100017 td 0xffffff00014d1000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000067d40, rbp = 0 --- Tracing command kernel pid 0 tid 100012 td 0xffffff00014d2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800004ed40, rbp = 0 --- Tracing command kernel pid 0 tid 100000 td 0xffffffff806d8920 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 scheduler() at scheduler+0x292 mi_startup() at mi_startup+0x59 btext() at btext+0x2c db> From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:29:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E7ED1065688 for ; Mon, 1 Jun 2009 00:29:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 335028FC14 for ; Mon, 1 Jun 2009 00:29:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAvPZ-000EGI-Uh for current@freebsd.org; Mon, 01 Jun 2009 00:29:58 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 655F21CA55ED for ; Mon, 1 Jun 2009 09:29:57 +0900 (JST) Date: Mon, 01 Jun 2009 09:29:57 +0900 Message-ID: From: Randy Bush To: current In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:29:58 -0000 > ===> usr.bin/ee (install) > install -s -o root -g wheel -m 555 ee /usr/bin > cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > gencat:No such file or directory > *** Error code 1 > > Stop in /usr/src/usr.bin/ee. > *** Error code 1 > > Stop in /usr/src/usr.bin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 new cvsup rm -rf /usr/obj no help, repeats randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:31:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDD6A1065686 for ; Mon, 1 Jun 2009 00:31:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2C4628FC0C for ; Mon, 1 Jun 2009 00:31:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so3762881yxb.13 for ; Sun, 31 May 2009 17:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Je6MuY2y/ltT4xbSU/eOaBbg7TpJCZSAus+UahO34W0=; b=KYamen0i3aAP0NhkTS7Y6Pj8tPYvmeYE010su09veg7aR8n7W9NKmIb8I0Ccy9wZv9 K4NFOpKeJCKjd6IF5LQrCkth/LX2CYLfihfj1RP+CcE3ylWhQaKwFkcj2klOGPcn8uwb KjDDITriGED2q6FEvo3pGPtu3PSi2TouGTCIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=YNvCIbZYy4MEx+z/U3jTENnNoNOeXhF37WvA54st6m1ViI8jrOkKtMgEoQtm1DKAsi UsypC3oIKI2TyL9TqX/bK3iWCRnwm+6b6BGChEsklKhRG9LP7RYKJ8Sz0Uc2yvPe9+SI AROuJSW5rLA7dSyROacdoGTjsonnZFroPrJ8M= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.197.2 with SMTP id u2mr3773330anf.192.1243816304434; Sun, 31 May 2009 17:31:44 -0700 (PDT) In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> Date: Sun, 31 May 2009 17:31:44 -0700 X-Google-Sender-Auth: e664ca80bbda4dbf Message-ID: <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> From: Kip Macy To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:31:46 -0000 Are your sources from CVS or svn? The backtrace indicates that you have code that I backed out a little over a week ago. On Sun, May 31, 2009 at 5:26 PM, Randy Bush wrote: > and again, but i got a debugger prompt! swap_pager_getswapspace(3): faile= d swap_pager_getswapspace(3): failed swap_pager_getswapspace(3): failed swa= p_pager_getsw eaatalp trsapp 1a2: pcagee (fault whi3le )in: ke rnfela moide= l udcp id s=3Dw a1;p a_pipc aidge =3D r01_ fagulte vtirtsuawl aaddpresssp = =3D a0x0c d a(ul3t )co:de =3Df suaperivlisoer rdea datsa,w paagep n_otp par= egseernt _ingsterutctisonw paointpers =3Dp 0ax2c0:0exf(ff3fff)ff:80a4eac0 s= tack pointer =3D 0x28:0xffffff807a02eab0 frame pointer =3D 0x28:0xffffff807= a0fa2ielace0 ecod ssegwmeant p =3D_ bpasae g0xe0,r l_imgite 0txfsfffwfa, t= pypes 0px1ab de e=3D( D1PL6 0), :pr es f1,a illoneg 1d, f3s2 w0, agrapn _1 = pproacegsseorr e_flaggs e=3D tinstewrrauptp esnabpleda, creesum(e,3 )IO:PL = =3Df 0 cesirrelnte pdro s s =3D w148a (pspa__zipo) a[thread pid 148 tid 100= 134 ] Stopped at fletcher_2_native+0x20: addq (%rdi),%rcx db> trace Tracing= pid 148 tid 100134 td 0xffffff000639d390 fletcher_2_native() at fletcher_2= _native+0x20 zio_checksum_compute() at zio_checksum_compute+0xe0 zio_checks= um_generate() at zio_checksum_generate+0x2b zio_execute() at zio_execute+0x= 77 taskq_thread() at taskq_thread+0x1d1 fork_exit() at fork_exit+0x12a fork= _trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffff= f807a02ed40, rbp =3D 0 --- db> alltrace Tracing command nfprofile pid 3400 = tid 100316 td 0xffffff0076469000 sched_switch() at sched_switch+0x190 mi_sw= itch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_loc= k_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1= swp_pager_getswapspace() at swp_pager_getswapspace+0x34 swap_pager_putpage= s() at swap_pager_putpages+0x185 vm_pageout_flush() at vm_pageout_flush+0x1= 4f vm_contig_launder() at vm_contig_launder+0x1de zio_data_buf_alloc() at z= io_data_buf_alloc+0xd6 arc_get_data_buf() at arc_get_data_buf+0x1c9 arc_buf= _alloc() at arc_buf_alloc+0xae dbuf_read() at dbuf_read+0x1e9 dmu_tx_check_= ioerr() at dmu_tx_check_ioerr+0x9a dmu_tx_count_write() at dmu_tx_count_wri= te+0x291 dmu_tx_hold_write() at dmu_tx_hold_write+0x4a zfs_freebsd_write() = at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP_WRITE_APV+0x126 vn_write(= ) at vn_write+0x221 dofilewrite() at dofilewrite+0x85 kern_writev() at kern= _writev+0x60 write() at write+0x54 syscall() at syscall+0x1dd Xfast_syscall= () at Xfast_syscall+0xd0 --- syscall (4, FreeBSD ELF64, write), rip =3D 0x8= 0088016c, rsp =3D 0x7fffffffe388, rbp =3D 0x9 --- Tracing command exim-4.69= -3 pid 3375 tid 100300 td 0xffffff0080204000 Tracing command exim-4.69-3 pi= d 3373 tid 100306 td 0xffffff0076416ab0 sched_switch() at sched_switch+0x19= 0 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sle= epq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at slee= pq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockas= ync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvloc= k+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 kern_fcntl() at kern_fcntl= +0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x1dd Xfast_syscall() at = Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, fcntl), rip =3D 0x80143c= 86c, rsp =3D 0x7fffffffe188, rbp =3D 0xd --- Tracing command perl pid 3367 = tid 100299 td 0xffffff0080204390 sched_switch() at sched_switch+0x190 mi_sw= itch() at mi_switch+0x21d turnstile_wait() at turnstile_wait+0x234 _mtx_loc= k_sleep() at _mtx_lock_sleep+0xd6 _mtx_lock_flags() at _mtx_lock_flags+0xe1= swp_pager_strategy() at swp_pager_strategy+0x24 swap_pager_getpages() at s= wap_pager_getpages+0x31f vm_fault() at vm_fault+0x653 trap_pfault() at trap= _pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc,= rip =3D 0x8006dbeca, rsp =3D 0x7fffffffeb60, rbp =3D 0x10c1ff8 --- Tracing= command exim-4.69-3 pid 3366 tid 100308 td 0xffffff0076416390 sched_switch= () at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at = sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sl= eepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlock= async() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadv= lock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 ker= n_fcntl() at kern_fcntl+0xc3b fcntl() at fcntl+0x3b syscall() at syscall+0x= 1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (92, FreeBSD ELF64, f= cntl), rip =3D 0x80143c86c, rsp =3D 0x7fffffffe188, rbp =3D 0xd --- Tracing= command sh pid 3365 tid 100307 td 0xffffff0076416720 sched_switch() at sch= ed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_sw= itch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait= _sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern= _wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall(= ) at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip =3D 0x80= 0932e4c, rsp =3D 0x7fffffffe9d8, rbp =3D 0xd25 --- Tracing command cron pid= 3364 tid 100161 td 0xffffff0006aeaab0 Tracing command httpd pid 3359 tid 1= 00199 td 0xffffff0006f66720 sched_switch() at sched_switch+0x190 mi_switch(= ) at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_si= gnals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+= 0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf= _advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_A= DVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at sy= scall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD= ELF64, flock), rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rbp =3D 0x7fff= ffffea7c --- Tracing command httpd pid 3358 tid 100287 td 0xffffff008020739= 0 Tracing command httpd pid 3357 tid 100327 td 0xffffff00148e1ab0 sched_swi= tch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() = at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e= sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advl= ockasync() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_std= advlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 = flock() at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_= syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip =3D 0x801294eac, = rsp =3D 0x7fffffffe9f8, rbp =3D 0x7fffffffea7c --- Tracing command httpd pi= d 3348 tid 100231 td 0xffffff0076469390 sched_switch() at sched_switch+0x19= 0 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sle= epq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at slee= pq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockas= ync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvloc= k+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a sys= call() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (= 131, FreeBSD ELF64, flock), rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rb= p =3D 0x7fffffffea7c --- Tracing command httpd pid 3346 tid 100089 td 0xfff= fff0006072ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch= +0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sle= epq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() = at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at = lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() a= t VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xf= ast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock)= , rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rbp =3D 0x7fffffffea7c --- T= racing command exim-4.69-3 pid 3345 tid 100304 td 0xffffff0080222720 Tracin= g command exim-4.69-3 pid 3344 tid 100295 td 0xffffff0080205390 Tracing com= mand exim_tidydb pid 3343 tid 100321 td 0xffffff009a115000 sched_switch() a= t sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at slee= pq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b = vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at = trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip =3D 0x800d7f8f4, rs= p =3D 0x7fffffffe748, rbp =3D 0x3000 --- Tracing command sh pid 3341 tid 10= 0297 td 0xffffff0080204ab0 sched_switch() at sched_switch+0x190 mi_switch()= at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_sig= nals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0= x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait= 4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 ---= syscall (7, FreeBSD ELF64, wait4), rip =3D 0x800932e4c, rsp =3D 0x7fffffff= e678, rbp =3D 0x8a9 --- Tracing command httpd pid 2331 tid 100069 td 0xffff= ff0004fb2000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+= 0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at slee= pq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() a= t _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlock() at l= f_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at= VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+0x1dd Xfa= st_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64, flock),= rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rbp =3D 0x7fffffffea7c --- Tr= acing command mail pid 2227 tid 100278 td 0xffffff0080223ab0 Tracing comman= d sh pid 2226 tid 100150 td 0xffffff0006b05390 sched_switch() at sched_swit= ch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x= 123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() = at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0= x3cc wait4() at wait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xf= ast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wait4), rip =3D 0x800932e4c= , rsp =3D 0x7fffffffe558, rbp =3D 0x8a9 --- Tracing command sh pid 2225 tid= 100280 td 0xffffff0080223390 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_si= g+0x16 _sleep() at _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at w= ait4+0x35 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 = --- syscall (7, FreeBSD ELF64, wait4), rip =3D 0x800932e4c, rsp =3D 0x7ffff= fffe238, rbp =3D 0x8a9 --- Tracing command sh pid 2218 tid 100274 td 0xffff= ff0066a07390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+= 0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at slee= pq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() a= t _sleep+0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall= () at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, F= reeBSD ELF64, wait4), rip =3D 0x800932e4c, rsp =3D 0x7fffffffe9f8, rbp =3D = 0x8a9 --- Tracing command sh pid 2217 tid 100312 td 0xffffff00ce0a7390 sche= d_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_swit= ch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+= 0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe ke= rn_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0x1= dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, wai= t4), rip =3D 0x800932e4c, rsp =3D 0x7fffffffe9f8, rbp =3D 0x8a9 --- Tracing= command cron pid 2216 tid 100185 td 0xffffff0006f70000 Tracing command ssh= guard pid 2135 tid 100315 td 0xffffff009a114ab0 sched_switch() at sched_swi= tch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0= x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_= sig() at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep(= ) at kern_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscal= l+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF= 64, nanosleep), rip =3D 0x80084139c, rsp =3D 0x7fffffbfef38, rbp =3D 0x4a23= 1c83 --- Tracing command sshguard pid 2135 tid 100284 td 0xffffff0080222000= sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq= _switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sig= nals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2= fe pipe_read() at pipe_read+0x2c4 dofileread() at dofileread+0xa1 kern_read= v() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast= _syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = =3D 0x80085e18c, rsp =3D 0x7fffffffe878, rbp =3D 0x1 --- Tracing command ht= tpd pid 2104 tid 100285 td 0xffffff0080207ab0 sched_switch() at sched_switc= h+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x1= 23 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at= vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap() at trap+0x58d ca= lltrap() at calltrap+0x8 --- trap 0xc, rip =3D 0x8052d3480, rsp =3D 0x7ffff= fffe8b8, rbp =3D 0x805bc1218 --- Tracing command httpd pid 1839 tid 100251 = td 0xffffff0066a08ab0 sched_switch() at sched_switch+0x190 mi_switch() at m= i_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals(= ) at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _= sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+0xd8d lf_advlo= ck() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0xb3 VOP_ADVLOCK= _APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall() at syscall+= 0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131, FreeBSD ELF64= , flock), rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rbp =3D 0x7fffffffea= 7c --- Tracing command emacs pid 1647 tid 100290 td 0xffffff0080206720 Trac= ing command httpd pid 1615 tid 100296 td 0xffffff0080205000 sched_switch() = at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sle= epq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleep= q_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasy= nc() at lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvloc= k() at vop_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock(= ) at flock+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscal= l+0xd0 --- syscall (131, FreeBSD ELF64, flock), rip =3D 0x801294eac, rsp = =3D 0x7fffffffe9f8, rbp =3D 0x7fffffffea7c --- Tracing command httpd pid 16= 12 tid 100298 td 0xffffff0080204720 sched_switch() at sched_switch+0x190 mi= _switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_= catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_w= ait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at lf_advlockasync+= 0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at vop_stdadvlock+0x= b3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flock+0x13a syscall= () at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (131,= FreeBSD ELF64, flock), rip =3D 0x801294eac, rsp =3D 0x7fffffffe9f8, rbp = =3D 0x7fffffffea7c --- Tracing command bash pid 1466 tid 100232 td 0xffffff= 005700a390 Tracing command sshd pid 1464 tid 100238 td 0xffffff0066a0f000 T= racing command inet_gethost pid 1455 tid 100277 td 0xffffff005700d720 Traci= ng command inet_gethost pid 1454 tid 100276 td 0xffffff005700dab0 Tracing c= ommand inet_gethost pid 1453 tid 100091 td 0xffffff0006072390 Tracing comma= nd inet_gethost pid 1452 tid 100247 td 0xffffff0066a0bab0 Tracing command i= net_gethost pid 1451 tid 100275 td 0xffffff0066a07000 Tracing command getty= pid 1440 tid 100227 td 0xffffff005700b720 Tracing command getty pid 1439 t= id 100244 td 0xffffff0066a0c720 Tracing command getty pid 1438 tid 100248 t= d 0xffffff0066a0b720 Tracing command getty pid 1437 tid 100166 td 0xffffff0= 00639dab0 Tracing command getty pid 1436 tid 100233 td 0xffffff005700a000 T= racing command getty pid 1435 tid 100240 td 0xffffff0066a0e720 Tracing comm= and getty pid 1434 tid 100246 td 0xffffff0066a0c000 Tracing command getty p= id 1433 tid 100245 td 0xffffff0066a0c390 Tracing command getty pid 1432 tid= 100243 td 0xffffff0066a0cab0 Tracing command getty pid 1431 tid 100242 td = 0xffffff0066a0e000 Tracing command perl5.8.9 pid 1392 tid 100237 td 0xfffff= f0066a0f390 Tracing command perl5.8.9 pid 1391 tid 100239 td 0xffffff0066a0= eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sl= eepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch= _signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep= +0x2fe kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at sy= scall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD E= LF64, wait4), rip =3D 0x800c1fe4c, rsp =3D 0x7fffffffeb08, rbp =3D 0x7fffff= ffeb9c --- Tracing command nfcapd pid 1389 tid 100158 td 0xffffff0006aeb720= sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq= _switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sig= nals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2= fe soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+= 0x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at sysc= all+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD EL= F64, recvfrom), rip =3D 0x800839a3c, rsp =3D 0x7fffffffddd8, rbp =3D 0x8029= 00000 --- Tracing command nfcapd pid 1386 tid 100203 td 0xffffff004851a720 = sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_= switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sign= als+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2f= e soreceive_dgram() at soreceive_dgram+0x182 kern_recvit() at kern_recvit+0= x2de recvit() at recvit+0x21 recvfrom() at recvfrom+0x82 syscall() at sysca= ll+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (29, FreeBSD ELF= 64, recvfrom), rip =3D 0x800839a3c, rsp =3D 0x7fffffffddd8, rbp =3D 0x80290= 0000 --- Tracing command perl5.8.9 pid 1383 tid 100236 td 0xffffff0004fde39= 0 Tracing command perl5.8.9 pid 1382 tid 100230 td 0xffffff005700aab0 Traci= ng command perl5.8.9 pid 1381 tid 100235 td 0xffffff0048145720 Tracing comm= and httpd pid 1379 tid 100178 td 0xffffff00067feab0 sched_switch() at sched= _switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_swit= ch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_s= ig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe lf_advlockasync() at = lf_advlockasync+0xd8d lf_advlock() at lf_advlock+0x47 vop_stdadvlock() at v= op_stdadvlock+0xb3 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 flock() at flo= ck+0x13a syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 -= -- syscall (131, FreeBSD ELF64, flock), rip =3D 0x801294eac, rsp =3D 0x7fff= ffffe9d8, rbp =3D 0x7fffffffea5c --- Tracing command perl5.8.9 pid 1375 tid= 100202 td 0xffffff004851aab0 Tracing command httpd pid 1374 tid 100082 td = 0xffffff0004fadab0 Tracing command dhcpd pid 1368 tid 100224 td 0xffffff005= 700c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d= sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_ca= tch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() = at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_s= elect+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscal= l() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D = 0x8007af10c, rsp =3D 0x7fffffffea38, rbp =3D 0x8 --- Tracing command cron p= id 1357 tid 100229 td 0xffffff005700b000 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sl= eepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() a= t sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at ke= rn_nanosleep+0x118 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd= Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nan= osleep), rip =3D 0x80093739c, rsp =3D 0x7fffffffeb28, rbp =3D 0x2c --- Trac= ing command sshd pid 1347 tid 100228 td 0xffffff005700b390 Tracing command = httpd pid 1323 tid 100225 td 0xffffff005700c000 sched_switch() at sched_swi= tch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0= x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_= sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig= +0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 sel= ect() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_sy= scall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D 0x80130510c, rs= p =3D 0x7fffffffea48, rbp =3D 0 --- Tracing command sc_serv pid 1321 tid 10= 0219 td 0xffffff005700d000 sched_switch() at sched_switch+0x190 mi_switch()= at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_sig= nals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timed= wait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at= seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_= select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint= 0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2= 814ef27, rsp =3D 0x3474f79c, rbp =3D 0 --- Tracing command sc_serv pid 1320= tid 100218 td 0xffffff005700d390 sched_switch() at sched_switch+0x190 mi_s= witch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_ca= tch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleep= q_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwa= it() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at= linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() = at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = =3D 0x2814ef27, rsp =3D 0x3075140c, rbp =3D 0x7d0 --- Tracing command sc_se= rv pid 1319 tid 100217 td 0xffffff0006f70720 sched_switch() at sched_switch= +0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x12= 3 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig= () at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x= 18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_= select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80= _syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_se= lect), rip =3D 0x2814ef27, rsp =3D 0x2c7513ec, rbp =3D 0x2c751440 --- Traci= ng command sc_serv pid 1318 tid 100216 td 0xffffff0006f70ab0 sched_switch()= at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sl= eepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e slee= pq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_= timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_sel= ect+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscal= l+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux= ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x344f779c, rbp =3D 0 --= - Tracing command sc_serv pid 1317 tid 100215 td 0xffffff0048162000 sched_s= witch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch(= ) at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x2= 4e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() = at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at k= ern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32= _syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142= , Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x304f940c, rbp = =3D 0x7d0 --- Tracing command sc_serv pid 1316 tid 100214 td 0xffffff004816= 2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sl= eepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch= _signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_time= dwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_s= elect() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_sysca= ll() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- = syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2c4= f93ec, rbp =3D 0x2c4f9440 --- Tracing command sc_serv pid 1315 tid 100213 t= d 0xffffff0048162720 sched_switch() at sched_switch+0x190 mi_switch() at mi= _switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals()= at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_s= ig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltd= wait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select= +0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_s= yscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef2= 7, rsp =3D 0x344f779c, rbp =3D 0 --- Tracing command sc_serv pid 1314 tid 1= 00212 td 0xffffff0048162ab0 sched_switch() at sched_switch+0x190 mi_switch(= ) at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_si= gnals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_time= dwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() a= t seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux= _select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xin= t0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x= 2814ef27, rsp =3D 0x304f940c, rbp =3D 0x7d0 --- Tracing command sc_serv pid= 1313 tid 100211 td 0xffffff0048422000 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at = sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c se= ltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select= () at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_sysca= ll() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select),= rip =3D 0x2814ef27, rsp =3D 0x2c4f93ec, rbp =3D 0x2c4f9440 --- Tracing com= mand sc_serv pid 1312 tid 100177 td 0xffffff0006f28000 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_tim= edwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedw= ait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x= 610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19= c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32= , linux_select), rip =3D 0x2814ef27, rsp =3D 0x354ca79c, rbp =3D 0 --- Trac= ing command sc_serv pid 1311 tid 100182 td 0xffffff0006b05ab0 sched_switch(= ) at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at s= leepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sle= epq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv= _timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_se= lect+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_sysca= ll+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linu= x ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x314cc40c, rbp =3D 0x7= d0 --- Tracing command sc_serv pid 1310 tid 100171 td 0xffffff0006ec9720 sc= hed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_sw= itch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signal= s+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_s= ig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select()= at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at= ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall= (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2d4cc3ec, = rbp =3D 0x2d4cc440 --- Tracing command asterisk pid 1303 tid 100271 td 0xff= ffff0066a0fab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switc= h+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sl= eepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x1= 9 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x118 nanosle= ep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() at Xfast_= syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip =3D 0x800e043= 9c, rsp =3D 0x7fffff7f1b78, rbp =3D 0x7fffff7f1c70 --- Tracing command aste= risk pid 1303 tid 100267 td 0xffffff00765a9ab0 sched_switch() at sched_swit= ch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x= 123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() = at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at= seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_sysca= ll() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D = 0x800dcb53c, rsp =3D 0x7fffff82eea8, rbp =3D 0 --- Tracing command asterisk= pid 1303 tid 100266 td 0xffffff00765aa000 sched_switch() at sched_switch+0= x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 = sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig()= at sleepq_timedwait_sig+0x19 _sleep() at _sleep+0x235 do_cv_wait() at do_c= v_wait+0x57a __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at sys= call+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD = ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x7fffff86be28, rbp =3D 0x80= 10060c0 --- Tracing command asterisk pid 1303 tid 100265 td 0xffffff00765aa= 390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sle= epq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_= signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+= 0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_= wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 = --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x= 7fffff8a8d98, rbp =3D 0x801006280 --- Tracing command asterisk pid 1303 tid= 100264 td 0xffffff00765aa720 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_si= g+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_= cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscal= l() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = =3D 0x800c2e1ec, rsp =3D 0x7fffff8e5d98, rbp =3D 0x801006440 --- Tracing co= mmand asterisk pid 1303 tid 100263 td 0xffffff00765aaab0 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_w= ait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at = do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at= syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, Free= BSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x7fffff922d98, rbp =3D = 0x801006600 --- Tracing command asterisk pid 1303 tid 100262 td 0xffffff007= 65ab000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d= sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_ca= tch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sl= eep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op= _cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0= xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp = =3D 0x7fffff95fd98, rbp =3D 0x8010067c0 --- Tracing command asterisk pid 13= 03 tid 100261 td 0xffffff00765ab390 sched_switch() at sched_switch+0x190 mi= _switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_= catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_w= ait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __um= tx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_= syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op),= rip =3D 0x800c2e1ec, rsp =3D 0x7fffff99cd98, rbp =3D 0x801006980 --- Traci= ng command asterisk pid 1303 tid 100260 td 0xffffff00765ab720 sched_switch(= ) at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at s= leepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sle= epq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait(= ) at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall= () at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454,= FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x7fffff9d9d98, rbp= =3D 0x801006b40 --- Tracing command asterisk pid 1303 tid 100259 td 0xffff= ff00765abab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+= 0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at slee= pq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() a= t _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __um= tx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_sysc= all+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, r= sp =3D 0x7fffffa16d98, rbp =3D 0x801006d00 --- Tracing command asterisk pid= 1303 tid 100258 td 0xffffff00765ad000 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleep= q_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 _= _umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfa= st_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_o= p), rip =3D 0x800c2e1ec, rsp =3D 0x7fffffa53d98, rbp =3D 0x801006ec0 --- Tr= acing command asterisk pid 1303 tid 100257 td 0xffffff00765ad390 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e = sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wa= it() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c sysc= all() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (4= 54, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x7fffffa90d98, = rbp =3D 0x801007080 --- Tracing command asterisk pid 1303 tid 100256 td 0xf= fffff0004fb2390 sched_switch() at sched_switch+0x190 mi_switch() at mi_swit= ch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at s= leepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep(= ) at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at _= _umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_s= yscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec= , rsp =3D 0x7fffffacdd98, rbp =3D 0x801007240 --- Tracing command asterisk = pid 1303 tid 100255 td 0xffffff0004fb2720 sched_switch() at sched_switch+0x= 190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 s= leepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() = at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c= seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x= 1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, = poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffb0aec8, rbp =3D 0x5fe768 --- Tr= acing command asterisk pid 1303 tid 100252 td 0xffffff0066a08720 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e = sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at = _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 = syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscal= l (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffb47e68, = rbp =3D 0 --- Tracing command asterisk pid 1303 tid 100206 td 0xffffff00485= 1a390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d s= leepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catc= h_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_tim= edwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll(= ) at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall= +0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D = 0x7fffffb84ee8, rbp =3D 0x801008ac8 --- Tracing command asterisk pid 1303 t= id 100205 td 0xffffff0004fde720 sched_switch() at sched_switch+0x190 mi_swi= tch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catc= h_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_= sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_o= p_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_sysc= all() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip= =3D 0x800c2e1ec, rsp =3D 0x7fffffbc1e98, rbp =3D 0x801008c80 --- Tracing c= ommand asterisk pid 1303 tid 100204 td 0xffffff0004fdeab0 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_= wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e sel= tdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd = Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll= ), rip =3D 0x800dcb53c, rsp =3D 0x7fffffbfee38, rbp =3D 0x801008e48 --- Tra= cing command asterisk pid 1303 tid 100103 td 0xffffff000609d000 sched_switc= h() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at= sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e s= leepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x1= 7e seltdwait() at seltdwait+0xac poll() at poll+0x3f3 syscall() at syscall+= 0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64= , poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffffe948, rbp =3D 0x7fffffffecf= 0 --- Tracing command exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720= sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq= _switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sig= nals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_= wait_sig+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0= x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at = Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D 0x80144= e10c, rsp =3D 0x7fffffffe6f8, rbp =3D 0x1 --- Tracing command mysqld pid 12= 88 tid 100272 td 0xffffff0066a07ab0 sched_switch() at sched_switch+0x190 mi= _switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_= catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_w= ait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_gene= ric+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 = read() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_sys= call+0xd0 --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp = =3D 0x7ffffeaf2be8, rbp =3D 0x8038eb0e8 --- Tracing command mysqld pid 1288= tid 100270 td 0xffffff00765a9000 sched_switch() at sched_switch+0x190 mi_s= witch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_ca= tch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wai= t_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generi= c+0x1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 re= ad() at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_sysca= ll+0xd0 --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp =3D = 0x7ffffeb33be8, rbp =3D 0x8038e30e8 --- Tracing command mysqld pid 1288 tid= 100269 td 0xffffff00765a9390 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_si= g+0x16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x= 1025 dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read()= at read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0= xd0 --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7f= fffeb74be8, rbp =3D 0x8038db0e8 --- Tracing command mysqld pid 1288 tid 100= 268 td 0xffffff00765a9720 sched_switch() at sched_switch+0x190 mi_switch() = at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_sign= als() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x= 16 _sleep() at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025= dofileread() at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at = read+0x54 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 = --- syscall (3, FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7ffffe= bb5be8, rbp =3D 0x8034f50e8 --- Tracing command mysqld pid 1288 tid 100223 = td 0xffffff005700c720 sched_switch() at sched_switch+0x190 mi_switch() at m= i_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals(= ) at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _= sleep() at _sleep+0x2fe kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigw= ait() at sigwait+0x74 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_s= yscall+0xd0 --- syscall (429, FreeBSD ELF64, sigwait), rip =3D 0x801409a9c,= rsp =3D 0x7ffffebf6f08, rbp =3D 0x801608040 --- Tracing command mysqld pid= 1288 tid 100220 td 0xffffff005700cab0 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleep= q_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 _= _umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfa= st_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_o= p), rip =3D 0x8012af1ec, rsp =3D 0x7ffffedf7e88, rbp =3D 0x801608200 --- Tr= acing command mysqld pid 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch= () at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at = sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sl= eepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _c= v_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_s= elect+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast_syscal= l() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D = 0x8014a210c, rsp =3D 0x7ffffeff8f18, rbp =3D 0 --- Tracing command mysqld p= id 1288 tid 100221 td 0xffffff0004fde000 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sl= eepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() a= t sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c = seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() a= t select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0= xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D 0x8014a210c, rsp =3D 0= x7fffff1f9f08, rbp =3D 0 --- Tracing command mysqld pid 1288 tid 100210 td = 0xffffff0048422390 sched_switch() at sched_switch+0x190 mi_switch() at mi_s= witch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() a= t sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sle= ep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() a= t __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfas= t_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af= 1ec, rsp =3D 0x7fffff5fbbc8, rbp =3D 0x801608900 --- Tracing command mysqld= pid 1288 tid 100209 td 0xffffff0048422720 sched_switch() at sched_switch+0= x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 = sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at s= leepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7= d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd= Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _um= tx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff7fcbc8, rbp =3D 0x801608ac0 --= - Tracing command mysqld pid 1288 tid 100208 td 0xffffff0048422ab0 sched_sw= itch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch()= at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24= e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_= wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c sy= scall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall = (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff9fdbc8= , rbp =3D 0x801608c80 --- Tracing command asterisk pid 1303 tid 100255 td 0= xffffff0004fb2720 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at= sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+= 0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwai= t+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at X= fast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb5= 3c, rsp =3D 0x7fffffb0aec8, rbp =3D 0x5fe768 --- Tracing command asterisk p= id 1303 tid 100252 td 0xffffff0066a08720 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sl= eepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() a= t sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c = seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1= dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, p= oll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffb47e68, rbp =3D 0 --- Tracing co= mmand asterisk pid 1303 tid 100206 td 0xffffff004851a390 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_t= imedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_time= dwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x3f3 syscall(= ) at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (209, = FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffb84ee8, rbp =3D = 0x801008ac8 --- Tracing command asterisk pid 1303 tid 100205 td 0xffffff000= 4fde720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d= sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_ca= tch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sl= eep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op= _cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0= xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp = =3D 0x7fffffbc1e98, rbp =3D 0x801008c80 --- Tracing command asterisk pid 13= 03 tid 100204 td 0xffffff0004fdeab0 sched_switch() at sched_switch+0x190 mi= _switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_= catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_w= ait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+= 0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfa= st_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c= , rsp =3D 0x7fffffbfee38, rbp =3D 0x801008e48 --- Tracing command asterisk = pid 1303 tid 100103 td 0xffffff000609d000 sched_switch() at sched_switch+0x= 190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 s= leepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sl= eepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at selt= dwait+0xac poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() = at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D 0x800= dcb53c, rsp =3D 0x7fffffffe948, rbp =3D 0x7fffffffecf0 --- Tracing command = exim-4.69-3 pid 1289 tid 100094 td 0xffffff000604c720 sched_switch() at sch= ed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_sw= itch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait= _sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwa= it() at seltdwait+0xac kern_select() at kern_select+0x610 select() at selec= t+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 ---= syscall (93, FreeBSD ELF64, select), rip =3D 0x80144e10c, rsp =3D 0x7fffff= ffe6f8, rbp =3D 0x1 --- Tracing command mysqld pid 1288 tid 100272 td 0xfff= fff0066a07ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch= +0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sle= epq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() = at _sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread(= ) at dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 sy= scall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall = (3, FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7ffffeaf2be8, rbp = =3D 0x8038eb0e8 --- Tracing command mysqld pid 1288 tid 100270 td 0xffffff0= 0765a9000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_= catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _= sleep+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at= dofileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscal= l() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, = FreeBSD ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7ffffeb33be8, rbp =3D = 0x8038e30e8 --- Tracing command mysqld pid 1288 tid 100269 td 0xffffff00765= a9390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d s= leepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catc= h_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _slee= p+0x2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dof= ileread+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() = at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, Free= BSD ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7ffffeb74be8, rbp =3D 0x80= 38db0e8 --- Tracing command mysqld pid 1288 tid 100268 td 0xffffff00765a972= 0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleep= q_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_si= gnals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x= 2fe soreceive_generic() at soreceive_generic+0x1025 dofileread() at dofiler= ead+0xa1 kern_readv() at kern_readv+0x60 read() at read+0x54 syscall() at s= yscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD = ELF64, read), rip =3D 0x8014a218c, rsp =3D 0x7ffffebb5be8, rbp =3D 0x8034f5= 0e8 --- Tracing command mysqld pid 1288 tid 100223 td 0xffffff005700c720 sc= hed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_sw= itch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signal= s+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe = kern_sigtimedwait() at kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 sy= scall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall = (429, FreeBSD ELF64, sigwait), rip =3D 0x801409a9c, rsp =3D 0x7ffffebf6f08,= rbp =3D 0x801608040 --- Tracing command mysqld pid 1288 tid 100220 td 0xff= ffff005700cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switc= h+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sl= eepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep()= at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __= umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_sy= scall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af1ec,= rsp =3D 0x7ffffedf7e88, rbp =3D 0x801608200 --- Tracing command mysqld pid= 1288 tid 100222 td 0xffffff0004fb2ab0 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at = sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c se= ltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 select() at = select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd= 0 --- syscall (93, FreeBSD ELF64, select), rip =3D 0x8014a210c, rsp =3D 0x7= ffffeff8f18, rbp =3D 0 --- Tracing command mysqld pid 1288 tid 100221 td 0x= ffffff0004fde000 sched_switch() at sched_switch+0x190 mi_switch() at mi_swi= tch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at = sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0= x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait= +0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() = at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, Fre= eBSD ELF64, select), rip =3D 0x8014a210c, rsp =3D 0x7fffff1f9f08, rbp =3D 0= --- Tracing command mysqld pid 1288 tid 100210 td 0xffffff0048422390 sched= _switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switc= h() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0= x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_= cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c= syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- sysca= ll (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff5fb= bc8, rbp =3D 0x801608900 --- Tracing command mysqld pid 1288 tid 100209 td = 0xffffff0048422720 sched_switch() at sched_switch+0x190 mi_switch() at mi_s= witch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() a= t sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sle= ep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() a= t __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfas= t_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af= 1ec, rsp =3D 0x7fffff7fcbc8, rbp =3D 0x801608ac0 --- Tracing command mysqld= pid 1288 tid 100208 td 0xffffff0048422ab0 sched_switch() at sched_switch+0= x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 = sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at s= leepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7= d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd= Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _um= tx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff9fdbc8, rbp =3D 0x801608c80 --= - Tracing command asterisk pid 1303 tid 100255 td 0xffffff0004fb2720 sched_= switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch= () at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x= 24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig()= at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 poll() at poll+0x= 3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- sy= scall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffb0ae= c8, rbp =3D 0x5fe768 --- Tracing command asterisk pid 1303 tid 100252 td 0x= ffffff0066a08720 sched_switch() at sched_switch+0x190 mi_switch() at mi_swi= tch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at = sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0= x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait= +0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xf= ast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53= c, rsp =3D 0x7fffffb47e68, rbp =3D 0 --- Tracing command asterisk pid 1303 = tid 100206 td 0xffffff004851a390 sched_switch() at sched_switch+0x190 mi_sw= itch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_cat= ch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq= _timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwai= t() at seltdwait+0x56 poll() at poll+0x3f3 syscall() at syscall+0x1dd Xfast= _syscall() at Xfast_syscall+0xd0 --- syscall (209, FreeBSD ELF64, poll), ri= p =3D 0x800dcb53c, rsp =3D 0x7fffffb84ee8, rbp =3D 0x801008ac8 --- Tracing = command asterisk pid 1303 tid 100205 td 0xffffff0004fde720 sched_switch() a= t sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at slee= pq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq= _wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() a= t do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() = at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, Fr= eeBSD ELF64, _umtx_op), rip =3D 0x800c2e1ec, rsp =3D 0x7fffffbc1e98, rbp = =3D 0x801008c80 --- Tracing command asterisk pid 1303 tid 100204 td 0xfffff= f0004fdeab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0= x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleep= q_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_si= g() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at poll+0x3f= 3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- sysc= all (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffffbfee38= , rbp =3D 0x801008e48 --- Tracing command asterisk pid 1303 tid 100103 td 0= xffffff000609d000 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at= sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_w= ait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac poll() at pol= l+0x3f3 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --= - syscall (209, FreeBSD ELF64, poll), rip =3D 0x800dcb53c, rsp =3D 0x7fffff= ffe948, rbp =3D 0x7fffffffecf0 --- Tracing command exim-4.69-3 pid 1289 tid= 100094 td 0xffffff000604c720 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_si= g+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwait() at seltdwait+0xac k= ern_select() at kern_select+0x610 select() at select+0x56 syscall() at sysc= all+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD EL= F64, select), rip =3D 0x80144e10c, rsp =3D 0x7fffffffe6f8, rbp =3D 0x1 --- = Tracing command mysqld pid 1288 tid 100272 td 0xffffff0066a07ab0 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e = sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceiv= e_generic() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 ker= n_readv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd= Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read)= , rip =3D 0x8014a218c, rsp =3D 0x7ffffeaf2be8, rbp =3D 0x8038eb0e8 --- Trac= ing command mysqld pid 1288 tid 100270 td 0xffffff00765a9000 sched_switch()= at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sl= eepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e slee= pq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_ge= neric() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_re= adv() at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfa= st_syscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), ri= p =3D 0x8014a218c, rsp =3D 0x7ffffeb33be8, rbp =3D 0x8038e30e8 --- Tracing = command mysqld pid 1288 tid 100269 td 0xffffff00765a9390 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_w= ait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generi= c() at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv(= ) at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_s= yscall() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip = =3D 0x8014a218c, rsp =3D 0x7ffffeb74be8, rbp =3D 0x8038db0e8 --- Tracing co= mmand mysqld pid 1288 tid 100268 td 0xffffff00765a9720 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wai= t_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe soreceive_generic(= ) at soreceive_generic+0x1025 dofileread() at dofileread+0xa1 kern_readv() = at kern_readv+0x60 read() at read+0x54 syscall() at syscall+0x1dd Xfast_sys= call() at Xfast_syscall+0xd0 --- syscall (3, FreeBSD ELF64, read), rip =3D = 0x8014a218c, rsp =3D 0x7ffffebb5be8, rbp =3D 0x8034f50e8 --- Tracing comman= d mysqld pid 1288 tid 100223 td 0xffffff005700c720 sched_switch() at sched_= switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switc= h+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_si= g() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe kern_sigtimedwait() at= kern_sigtimedwait+0x4b9 sigwait() at sigwait+0x74 syscall() at syscall+0x1= dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (429, FreeBSD ELF64, s= igwait), rip =3D 0x801409a9c, rsp =3D 0x7ffffebf6f08, rbp =3D 0x801608040 -= -- Tracing command mysqld pid 1288 tid 100220 td 0xffffff005700cab0 sched_s= witch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch(= ) at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x2= 4e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv= _wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c s= yscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall= (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7ffffedf7e8= 8, rbp =3D 0x801608200 --- Tracing command mysqld pid 1288 tid 100222 td 0x= ffffff0004fb2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_swi= tch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at = sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0= x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait= +0x56 kern_select() at kern_select+0x610 select() at select+0x56 syscall() = at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, Fre= eBSD ELF64, select), rip =3D 0x8014a210c, rsp =3D 0x7ffffeff8f18, rbp =3D 0= --- Tracing command mysqld pid 1288 tid 100221 td 0xffffff0004fde000 sched= _switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switc= h() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0= x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig(= ) at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at= kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd Xfast= _syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, select), r= ip =3D 0x8014a210c, rsp =3D 0x7fffff1f9f08, rbp =3D 0 --- Tracing command m= ysqld pid 1288 tid 100210 td 0xffffff0048422390 sched_switch() at sched_swi= tch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0= x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig()= at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wai= t+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+= 0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64= , _umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff5fbbc8, rbp =3D 0x8016089= 00 --- Tracing command mysqld pid 1288 tid 100209 td 0xffffff0048422720 sch= ed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_swi= tch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals= +0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe d= o_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x= 5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- sys= call (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffff7= fcbc8, rbp =3D 0x801608ac0 --- Tracing command mysqld pid 1288 tid 100208 t= d 0xffffff0048422ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi= _switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals()= at sleepq_catch_signals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _s= leep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait()= at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xf= ast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x8012= af1ec, rsp =3D 0x7fffff9fdbc8, rbp =3D 0x801608c80 --- Tracing command mysq= ld pid 1288 tid 100207 td 0xffffff004851a000 sched_switch() at sched_switch= +0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x12= 3 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait_sig() at= sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe do_cv_wait() at do_cv_wait+0= x7d4 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x5c syscall() at syscall+0x1= dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (454, FreeBSD ELF64, _= umtx_op), rip =3D 0x8012af1ec, rsp =3D 0x7fffffbfebc8, rbp =3D 0x801608e40 = --- Tracing command mysqld pid 1288 tid 100116 td 0xffffff0006049ab0 sched_= switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch= () at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x= 24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_si= g+0x17e seltdwait() at seltdwait+0xac kern_select() at kern_select+0x610 se= lect() at select+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_s= yscall+0xd0 --- syscall (93, FreeBSD ELF64, select), rip =3D 0x8014a210c, r= sp =3D 0x7fffffffe558, rbp =3D 0xb --- Tracing command sc_serv pid 1266 tid= 100198 td 0xffffff0006f66ab0 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_ti= medwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait()= at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at lin= ux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at X= int0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D = 0x2814ef27, rsp =3D 0x3474f79c, rbp =3D 0 --- Tracing command sc_serv pid 1= 265 tid 100197 td 0xffffff00480ac000 sched_switch() at sched_switch+0x190 m= i_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq= _catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sl= eepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c selt= dwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select()= at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall= () at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), r= ip =3D 0x2814ef27, rsp =3D 0x3075140c, rbp =3D 0x7d0 --- Tracing command sc= _serv pid 1264 tid 100186 td 0xffffff00480a8ab0 sched_switch() at sched_swi= tch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0= x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_= sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig= +0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 lin= ux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0= x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux= _select), rip =3D 0x2814ef27, rsp =3D 0x3474f79c, rbp =3D 0 --- Tracing com= mand sc_serv pid 1263 tid 100187 td 0xffffff00480a8720 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_tim= edwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedw= ait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x= 610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19= c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32= , linux_select), rip =3D 0x2814ef27, rsp =3D 0x3075140c, rbp =3D 0x7d0 --- = Tracing command sc_serv pid 1262 tid 100196 td 0xffffff00480ac390 sched_swi= tch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() = at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e= sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at= _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at ker= n_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_s= yscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, = Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2c7513ec, rbp =3D= 0x2c751440 --- Tracing command sc_serv pid 1261 tid 100092 td 0xffffff0006= 072000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d = sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_cat= ch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_ti= medwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern= _select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_sys= call() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --= - syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2= c7513ec, rbp =3D 0x2c751440 --- Tracing command sc_serv pid 1260 tid 100195= td 0xffffff00480ac720 sched_switch() at sched_switch+0x190 mi_switch() at = mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals= () at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait= _sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at sel= tdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_sele= ct+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80= _syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814e= f27, rsp =3D 0x3474f79c, rbp =3D 0 --- Tracing command sc_serv pid 1259 tid= 100194 td 0xffffff00480acab0 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_= signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_ti= medwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait()= at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at lin= ux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at X= int0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D = 0x2814ef27, rsp =3D 0x3075140c, rbp =3D 0x7d0 --- Tracing command sc_serv p= id 1258 tid 100193 td 0xffffff0006e39000 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sl= eepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() a= t sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c = seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_sele= ct() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_sys= call() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select= ), rip =3D 0x2814ef27, rsp =3D 0x2c7513ec, rbp =3D 0x2c751440 --- Tracing c= ommand sc_serv pid 1257 tid 100192 td 0xffffff0006e39390 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_t= imedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_time= dwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+= 0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x= 19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF= 32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x344f779c, rbp =3D 0 --- Tr= acing command sc_serv pid 1256 tid 100191 td 0xffffff0006e39720 sched_switc= h() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at= sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e s= leepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _= cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_= select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_sys= call+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Li= nux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x304f940c, rbp =3D 0= x7d0 --- Tracing command sc_serv pid 1255 tid 100190 td 0xffffff0006e39ab0 = sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_= switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sign= als+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait= _sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select= () at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() = at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- sysca= ll (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2c4f93ec= , rbp =3D 0x2c4f9440 --- Tracing command sc_serv pid 1254 tid 100189 td 0xf= fffff00480a8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_swit= ch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at s= leepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x= 19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+= 0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa= ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscal= l+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rs= p =3D 0x344f779c, rbp =3D 0 --- Tracing command sc_serv pid 1253 tid 100188= td 0xffffff00480a8390 sched_switch() at sched_switch+0x190 mi_switch() at = mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals= () at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait= _sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at sel= tdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_sele= ct+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80= _syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814e= f27, rsp =3D 0x304f940c, rbp =3D 0x7d0 --- Tracing command sc_serv pid 1252= tid 100078 td 0xffffff0006022390 sched_switch() at sched_switch+0x190 mi_s= witch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_ca= tch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleep= q_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwa= it() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at= linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() = at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip = =3D 0x2814ef27, rsp =3D 0x2c4f93ec, rbp =3D 0x2c4f9440 --- Tracing command = sc_serv pid 1251 tid 100179 td 0xffffff00067fe720 sched_switch() at sched_s= witch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch= +0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwai= t_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_s= ig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 l= inux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xin= t0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, lin= ux_select), rip =3D 0x2814ef27, rsp =3D 0x344f779c, rbp =3D 0 --- Tracing c= ommand sc_serv pid 1250 tid 100184 td 0xffffff0006f70390 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_t= imedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_time= dwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+= 0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x= 19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF= 32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x304f940c, rbp =3D 0x7d0 --= - Tracing command sc_serv pid 1249 tid 100167 td 0xffffff000639d720 sched_s= witch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch(= ) at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x2= 4e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() = at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at k= ern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32= _syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142= , Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0x2c4f93ec, rbp = =3D 0x2c4f9440 --- Tracing command sc_serv pid 1139 tid 100165 td 0xffffff0= 006aea000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_= catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv= _timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 k= ern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_= syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85= --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D = 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing command sc_serv pid 1134 tid 100= 162 td 0xffffff0006aea720 sched_switch() at sched_switch+0x190 mi_switch() = at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_sign= als() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedw= ait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at = seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_s= elect+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0= x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x28= 14ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing command sc_serv = pid 1129 tid 100100 td 0xffffff0006044000 sched_switch() at sched_switch+0x= 190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 s= leepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() = at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c= seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_sel= ect() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_sy= scall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_selec= t), rip =3D 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing = command sc_serv pid 1124 tid 100121 td 0xffffff00060cf720 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_= timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_tim= edwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select= +0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0= x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux EL= F32, linux_select), rip =3D 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffd= dc8 --- Tracing command sc_serv pid 1119 tid 100099 td 0xffffff0006044390 s= ched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_s= witch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signa= ls+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_= sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select(= ) at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() a= t ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscal= l (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0xffffd74c,= rbp =3D 0xffffddd8 --- Tracing command sc_serv pid 1114 tid 100079 td 0xff= ffff0004fb0000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switc= h+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sl= eepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x1= 9 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0= x56 kern_select() at kern_select+0x610 linux_select() at linux_select+0xfa = ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall= +0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp= =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing command sc_serv pid 1109 ti= d 100098 td 0xffffff0006044720 sched_switch() at sched_switch+0x190 mi_swit= ch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch= _signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_t= imedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait(= ) at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() at li= nux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at = Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D= 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing command sc_= serv pid 1104 tid 100153 td 0xffffff0006b04720 sched_switch() at sched_swit= ch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x= 123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_s= ig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+= 0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610 linu= x_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x= 80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_= select), rip =3D 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tra= cing command sc_serv pid 1099 tid 100120 td 0xffffff00060cfab0 sched_switch= () at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at = sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sl= eepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _c= v_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_s= elect+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32_sysc= all+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Lin= ux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0x= ffffddc8 --- Tracing command sc_serv pid 1094 tid 100115 td 0xffffff0006099= 000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sle= epq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_= signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timed= wait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_se= lect() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_syscal= l() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- s= yscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0xffff= d73c, rbp =3D 0xffffddc8 --- Tracing command sc_serv pid 1089 tid 100075 td= 0xffffff0004fb0720 sched_switch() at sched_switch+0x190 mi_switch() at mi_= switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() = at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_si= g+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdw= ait+0x56 kern_select() at kern_select+0x610 linux_select() at linux_select+= 0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_sy= scall+0x85 --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27= , rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing command sc_serv pid 10= 84 tid 100074 td 0xffffff0004fb0ab0 sched_switch() at sched_switch+0x190 mi= _switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_= catch_signals() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sle= epq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltd= wait() at seltdwait+0x56 kern_select() at kern_select+0x610 linux_select() = at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall(= ) at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, linux_select), ri= p =3D 0x2814ef27, rsp =3D 0xffffd73c, rbp =3D 0xffffddc8 --- Tracing comman= d sc_serv pid 1079 tid 100085 td 0xffffff0004fad390 sched_switch() at sched= _switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_swit= ch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_timedw= ait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() at _cv_timedwait= _sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at kern_select+0x610= linux_select() at linux_select+0xfa ia32_syscall() at ia32_syscall+0x19c X= int0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142, Linux ELF32, l= inux_select), rip =3D 0x2814ef27, rsp =3D 0xffffd74c, rbp =3D 0xffffddd8 --= - Tracing command sc_serv pid 1074 tid 100154 td 0xffffff0006b04390 sched_s= witch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch(= ) at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x2= 4e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait_sig() = at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select() at k= ern_select+0x610 linux_select() at linux_select+0xfa ia32_syscall() at ia32= _syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85 --- syscall (142= , Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D 0xffffd74c, rbp = =3D 0xffffddd8 --- Tracing command sc_serv pid 1069 tid 100114 td 0xffffff0= 006099390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_= catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv= _timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 k= ern_select() at kern_select+0x610 linux_select() at linux_select+0xfa ia32_= syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x85= --- syscall (142, Linux ELF32, linux_select), rip =3D 0x2814ef27, rsp =3D = 0xffffd74c, rbp =3D 0xffffddd8 --- Tracing command irrd pid 1058 tid 100102= td 0xffffff000609d390 sched_switch() at sched_switch+0x190 mi_switch() at = mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signals= () at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwait= _sig+0x19 _cv_timedwait_sig() at _cv_timedwait_sig+0x18c seltdwait() at sel= tdwait+0x56 kern_select() at kern_select+0x610 select() at select+0x56 sysc= all() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (9= 3, FreeBSD ELF64, select), rip =3D 0x80088e10c, rsp =3D 0x7fffffffda48, rbp= =3D 0x400 --- Tracing command beam pid 1051 tid 100155 td 0xffffff00060213= 90 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d slee= pq_switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_s= ignals+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0= x2fe do_cv_wait() at do_cv_wait+0x7d4 __umtx_op_cv_wait() at __umtx_op_cv_w= ait+0x5c syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 -= -- syscall (454, FreeBSD ELF64, _umtx_op), rip =3D 0x800b931ec, rsp =3D 0x7= fffffbfee88, rbp =3D 0x800f08e40 --- Tracing command beam pid 1051 tid 1000= 93 td 0xffffff000604cab0 sched_switch() at sched_switch+0x190 mi_switch() a= t mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at s= leepq_wait+0x4d _sleep() at _sleep+0x34b vm_fault() at vm_fault+0x14c9 trap= _pfault() at trap_pfault+0x128 trap() at trap+0x58d calltrap() at calltrap+= 0x8 --- trap 0xc, rip =3D 0x4e9067, rsp =3D 0x7fffffffc260, rbp =3D 0x7ffff= fffc290 --- Tracing command epmd pid 1049 tid 100117 td 0xffffff0006049720 = sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_= switch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_sign= als+0x24e sleepq_timedwait_sig() at sleepq_timedwait_sig+0x19 _cv_timedwait= _sig() at _cv_timedwait_sig+0x18c seltdwait() at seltdwait+0x56 kern_select= () at kern_select+0x610 select() at select+0x56 syscall() at syscall+0x1dd = Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (93, FreeBSD ELF64, selec= t), rip =3D 0x80096810c, rsp =3D 0x7fffffffe8c8, rbp =3D 0x3ff --- Tracing = command ntpd pid 999 tid 100086 td 0xffffff0004fad000 sched_switch() at sch= ed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_sw= itch+0x123 sleepq_catch_signals() at sleepq_catch_signals+0x24e sleepq_wait= _sig() at sleepq_wait_sig+0x16 _cv_wait_sig() at _cv_wait_sig+0x17e seltdwa= it() at seltdwait+0xac kern_select() at kern_select+0x610 select() at selec= t+0x56 syscall() at syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 ---= syscall (93, FreeBSD ELF64, select), rip =3D 0x800d4910c, rsp =3D 0x7fffff= ffec18, rbp =3D 0x7fffffffed40 --- Tracing command smartd pid 941 tid 10008= 4 td 0xffffff0006021720 sched_switch() at sched_switch+0x190 mi_switch() at= mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_catch_signal= s() at sleepq_catch_signals+0x24e sleepq_timedwait_sig() at sleepq_timedwai= t_sig+0x19 _sleep() at _sleep+0x235 kern_nanosleep() at kern_nanosleep+0x11= 8 nanosleep() at nanosleep+0x6e syscall() at syscall+0x1dd Xfast_syscall() = at Xfast_syscall+0xd0 --- syscall (240, FreeBSD ELF64, nanosleep), rip =3D = 0x800ca039c, rsp =3D 0x7fffffffeaa8, rbp =3D 0x4a231d9b --- Tracing command= tac_plus pid 922 tid 100151 td 0xffffff0006b05000 Tracing command md0 pid = 853 tid 100090 td 0xffffff0006072720 sched_switch() at sched_switch+0x190 m= i_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq= _wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b md_kthread() at md_kth= read+0x15a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampol= ine+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079f52d40, rbp =3D 0 --- Tr= acing command unbound pid 816 tid 100096 td 0xffffff000604c000 sched_switch= () at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at = sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x= 34b vm_fault() at vm_fault+0x14c9 trap_pfault() at trap_pfault+0x128 trap()= at trap+0x58d calltrap() at calltrap+0x8 --- trap 0xc, rip =3D 0x44eb53, r= sp =3D 0x7fffffffe408, rbp =3D 0x80173b650 --- Tracing command syslogd pid = 787 tid 100070 td 0xffffff0004fb1ab0 sched_switch() at sched_switch+0x190 m= i_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq= _wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vm_contig_launder() at= vm_contig_launder+0xb5 zio_data_buf_alloc() at zio_data_buf_alloc+0xd6 arc= _get_data_buf() at arc_get_data_buf+0x1c9 arc_buf_alloc() at arc_buf_alloc+= 0xae dbuf_hold_impl() at dbuf_hold_impl+0x1ea dbuf_hold_level() at dbuf_hol= d_level+0x1a dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x52 dmu_tx_count_w= rite() at dmu_tx_count_write+0x178 dmu_tx_hold_write() at dmu_tx_hold_write= +0x4a zfs_freebsd_write() at zfs_freebsd_write+0x3e1 VOP_WRITE_APV() at VOP= _WRITE_APV+0x126 vn_write() at vn_write+0x221 dofilewrite() at dofilewrite+= 0x85 kern_writev() at kern_writev+0x60 writev() at writev+0x41 syscall() at= syscall+0x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (121, Free= BSD ELF64, writev), rip =3D 0x800834d3c, rsp =3D 0x7fffffffcaf8, rbp =3D 0 = --- Tracing command devd pid 665 tid 100073 td 0xffffff0004fb1000 Tracing c= ommand zil_clean pid 179 tid 100113 td 0xffffff0006099720 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x1= 7a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork= _trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffff= f8079fc5d40, rbp =3D 0 --- Tracing command zil_clean pid 178 tid 100083 td = 0xffffff0004fad720 sched_switch() at sched_switch+0x190 mi_switch() at mi_s= witch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_= wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b= fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --= - trap 0, rip =3D 0, rsp =3D 0xffffff8079f2fd40, rbp =3D 0 --- Tracing comm= and zil_clean pid 177 tid 100112 td 0xffffff0006099ab0 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a = taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_tr= ampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80= 79fc0d40, rbp =3D 0 --- Tracing command zil_clean pid 176 tid 100111 td 0xf= fffff000609b000 sched_switch() at sched_switch+0x190 mi_switch() at mi_swit= ch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wai= t+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fo= rk_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- t= rap 0, rip =3D 0, rsp =3D 0xffffff8079fbbd40, rbp =3D 0 --- Tracing command= zil_clean pid 175 tid 100109 td 0xffffff000609b720 sched_switch() at sched= _switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_swit= ch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a tas= kq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_tramp= oline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079f= b1d40, rbp =3D 0 --- Tracing command zil_clean pid 174 tid 100080 td 0xffff= ff0006022000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+= 0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0= x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_= exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap= 0, rip =3D 0, rsp =3D 0xffffff8079f20d40, rbp =3D 0 --- Tracing command zi= l_clean pid 173 tid 100108 td 0xffffff000609bab0 sched_switch() at sched_sw= itch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+= 0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_= thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoli= ne() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079facd= 40, rbp =3D 0 --- Tracing command zil_clean pid 172 tid 100104 td 0xffffff0= 00609cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d= _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exi= t() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0,= rip =3D 0, rsp =3D 0xffffff8079f98d40, rbp =3D 0 --- Tracing command zil_c= lean pid 171 tid 100072 td 0xffffff0004fb1390 sched_switch() at sched_switc= h+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x1= 23 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thr= ead() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline(= ) at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079ef8d40,= rbp =3D 0 --- Tracing command zil_clean pid 170 tid 100110 td 0xffffff0006= 09b390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d = sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _c= v_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit()= at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, ri= p =3D 0, rsp =3D 0xffffff8079fb6d40, rbp =3D 0 --- Tracing command txg_thre= ad_enter pid 168 tid 100107 td 0xffffff000609c000 sched_switch() at sched_s= witch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch= +0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a zio_w= ait() at zio_wait+0x61 dsl_pool_sync() at dsl_pool_sync+0xee spa_sync() at = spa_sync+0x355 txg_sync_thread() at txg_sync_thread+0x28f fork_exit() at fo= rk_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D = 0, rsp =3D 0xffffff807a07dd40, rbp =3D 0 --- Tracing command txg_thread_ent= er pid 167 tid 100106 td 0xffffff000609c390 sched_switch() at sched_switch+= 0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123= sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a txg_thread_= wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0= xb5 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe= --- trap 0, rip =3D 0, rsp =3D 0xffffff8079fa2d40, rbp =3D 0 --- Tracing c= ommand vdev:worker ad10s1 pid 166 tid 100105 td 0xffffff000609c720 sched_sw= itch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch()= at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _slee= p+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exi= t+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp= =3D 0xffffff8079f9dd40, rbp =3D 0 --- Tracing command vdev:worker ad6s1 pi= d 165 tid 100077 td 0xffffff0004fb0390 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b vdev_geom_worker() a= t vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a fork_trampoline() at= fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079f11d40, rbp= =3D 0 --- Tracing command vdev:worker ad8s2 pid 164 tid 100087 td 0xffffff= 0006049390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x= 21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4= d _sleep() at _sleep+0x34b vdev_geom_worker() at vdev_geom_worker+0xa3 fork= _exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- tra= p 0, rip =3D 0, rsp =3D 0xffffff8079f43d40, rbp =3D 0 --- Tracing command v= dev:worker ad4s2 pid 163 tid 100149 td 0xffffff00060d0720 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b v= dev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x12a f= ork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xff= ffff807a079d40, rbp =3D 0 --- Tracing command spa_zio pid 162 tid 100148 td= 0xffffff00060d0ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_= switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq= _wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33= b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe -= -- trap 0, rip =3D 0, rsp =3D 0xffffff807a074d40, rbp =3D 0 --- Tracing com= mand spa_zio pid 161 tid 100147 td 0xffffff0006399000 sched_switch() at sch= ed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_sw= itch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a t= askq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_tra= mpoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807= a06fd40, rbp =3D 0 --- Tracing command spa_zio pid 160 tid 100146 td 0xffff= ff0006399390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+= 0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0= x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_= exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap= 0, rip =3D 0, rsp =3D 0xffffff807a06ad40, rbp =3D 0 --- Tracing command sp= a_zio pid 159 tid 100145 td 0xffffff0006399720 sched_switch() at sched_swit= ch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x= 123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_th= read() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline= () at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a065d40= , rbp =3D 0 --- Tracing command spa_zio pid 158 tid 100144 td 0xffffff00063= 99ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d s= leepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv= _wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() = at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip= =3D 0, rsp =3D 0xffffff807a060d40, rbp =3D 0 --- Tracing command spa_zio p= id 157 tid 100143 td 0xffffff000639b000 sched_switch() at sched_switch+0x19= 0 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sle= epq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() = at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at f= ork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a05bd40, rbp = =3D 0 --- Tracing command spa_zio pid 156 tid 100142 td 0xffffff000639b390 = sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_= switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait(= ) at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at for= k_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0= , rsp =3D 0xffffff807a056d40, rbp =3D 0 --- Tracing command spa_zio pid 155= tid 100141 td 0xffffff000639b720 sched_switch() at sched_switch+0x190 mi_s= witch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wa= it() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at tas= kq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tr= ampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a051d40, rbp =3D 0 -= -- Tracing command spa_zio pid 154 tid 100140 td 0xffffff000639bab0 sched_s= witch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch(= ) at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _c= v_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+= 0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp = =3D 0xffffff807a04cd40, rbp =3D 0 --- Tracing command spa_zio pid 153 tid 1= 00139 td 0xffffff000639c000 sched_switch() at sched_switch+0x190 mi_switch(= ) at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() a= t sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thr= ead+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoli= ne+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a047d40, rbp =3D 0 --- Tra= cing command spa_zio pid 152 tid 100138 td 0xffffff000639c390 sched_switch(= ) at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at s= leepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait= +0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a = fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xf= fffff807a042d40, rbp =3D 0 --- Tracing command spa_zio pid 151 tid 100137 t= d 0xffffff000639c720 sched_switch() at sched_switch+0x190 mi_switch() at mi= _switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleep= q_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x3= 3b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe = --- trap 0, rip =3D 0, rsp =3D 0xffffff807a03dd40, rbp =3D 0 --- Tracing co= mmand spa_zio pid 150 tid 100136 td 0xffffff000639cab0 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_wait() at sleepq_wait+0x4d _sx_xlock_hard() at _sx_xlock= _hard+0x1a7 _sx_xlock() at _sx_xlock+0xc1 dbuf_write_ready() at dbuf_write_= ready+0xbf arc_write_ready() at arc_write_ready+0x2c zio_ready() at zio_rea= dy+0x3a zio_execute() at zio_execute+0x77 taskq_thread() at taskq_thread+0x= 1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe= --- trap 0, rip =3D 0, rsp =3D 0xffffff807a038d40, rbp =3D 0 --- Tracing c= ommand spa_zio pid 149 tid 100135 td 0xffffff000639d000 sched_switch() at s= ched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_= switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a= taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_t= rampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8= 07a033d40, rbp =3D 0 --- Tracing command spa_zio pid 148 tid 100134 td 0xff= ffff000639d390 fletcher_2_native() at fletcher_2_native+0x20 zio_checksum_c= ompute() at zio_checksum_compute+0xe0 zio_checksum_generate() at zio_checks= um_generate+0x2b zio_execute() at zio_execute+0x77 taskq_thread() at taskq_= thread+0x1d1 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tramp= oline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a02ed40, rbp =3D 0 --- = Tracing command spa_zio pid 147 tid 100133 td 0xffffff000609d720 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_w= ait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x1= 2a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D = 0xffffff807a029d40, rbp =3D 0 --- Tracing command spa_zio pid 146 tid 10013= 2 td 0xffffff000609dab0 sched_switch() at sched_switch+0x190 mi_switch() at= mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sl= eepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+= 0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0= xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a024d40, rbp =3D 0 --- Tracing= command spa_zio pid 145 tid 100131 td 0xffffff00060c8000 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x1= 7a taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork= _trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffff= f807a01fd40, rbp =3D 0 --- Tracing command spa_zio pid 144 tid 100130 td 0x= ffffff00060c8390 sched_switch() at sched_switch+0x190 mi_switch() at mi_swi= tch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wa= it+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b f= ork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- = trap 0, rip =3D 0, rsp =3D 0xffffff807a01ad40, rbp =3D 0 --- Tracing comman= d spa_zio pid 143 tid 100129 td 0xffffff00060c8720 sched_switch() at sched_= switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switc= h+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a task= q_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampo= line() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a01= 5d40, rbp =3D 0 --- Tracing command spa_zio pid 142 tid 100128 td 0xffffff0= 0060c8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d= _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exi= t() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0,= rip =3D 0, rsp =3D 0xffffff807a010d40, rbp =3D 0 --- Tracing command spa_z= io pid 141 tid 100127 td 0xffffff00060ca000 sched_switch() at sched_switch+= 0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123= sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_threa= d() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() = at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a00bd40, r= bp =3D 0 --- Tracing command spa_zio pid 140 tid 100126 td 0xffffff00060ca3= 90 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d slee= pq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wa= it() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at = fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = =3D 0, rsp =3D 0xffffff807a006d40, rbp =3D 0 --- Tracing command spa_zio pi= d 139 tid 100125 td 0xffffff00060ca720 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() a= t taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fo= rk_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807a001d40, rbp = =3D 0 --- Tracing command spa_zio pid 138 tid 100124 td 0xffffff00060caab0 = sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_= switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait(= ) at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b fork_exit() at for= k_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0= , rsp =3D 0xffffff8079ffcd40, rbp =3D 0 --- Tracing command spa_zio pid 137= tid 100123 td 0xffffff00060cf000 sched_switch() at sched_switch+0x190 mi_s= witch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wa= it() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at tas= kq_thread+0x33b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tr= ampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8079ff7d40, rbp =3D 0 -= -- Tracing command flowcleaner pid 44 tid 100068 td 0xffffff0004f0b000 sche= d_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_swit= ch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sl= eep() at _sleep+0x335 flowtable_cleaner() at flowtable_cleaner+0x13a fork_e= xit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap = 0, rip =3D 0, rsp =3D 0xffffff8077be1d40, rbp =3D 0 --- Tracing command sof= tdepflush pid 43 tid 100067 td 0xffffff0004f0b390 sched_switch() at sched_s= witch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch= +0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335= softdep_flush() at softdep_flush+0x2c0 fork_exit() at fork_exit+0x12a fork= _trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffff= f8077bdcd40, rbp =3D 0 --- Tracing command syncer pid 42 tid 100066 td 0xff= ffff0004f0b720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switc= h+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq= _timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c sched_sync() at sche= d_sync+0x4de fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tramp= oline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077bd7d40, rbp =3D 0 --- = Tracing command vnlru pid 41 tid 100065 td 0xffffff0004f0bab0 sched_switch(= ) at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at s= leepq_switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at = _sleep+0x335 vnlru_proc() at vnlru_proc+0x607 fork_exit() at fork_exit+0x12= a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0= xffffff8077bd2d40, rbp =3D 0 --- Tracing command vaclean pid 40 tid 100064 = td 0xffffff0004f0c000 sched_switch() at sched_switch+0x190 mi_switch() at m= i_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at= sleepq_timedwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c vn_rele_async= _cleaner() at vn_rele_async_cleaner+0x119 fork_exit() at fork_exit+0x12a fo= rk_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfff= fff8077bcdd40, rbp =3D 0 --- Tracing command bufdaemon pid 39 tid 100063 td= 0xffffff0004f0c390 sched_switch() at sched_switch+0x190 mi_switch() at mi_= switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at s= leepq_timedwait+0x4d _sleep() at _sleep+0x335 buf_daemon() at buf_daemon+0x= 14a fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe= --- trap 0, rip =3D 0, rsp =3D 0xffffff8077bc8d40, rbp =3D 0 --- Tracing c= ommand pagezero pid 38 tid 100062 td 0xffffff0004f0c720 sched_switch() at s= ched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_= switch+0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep= +0x335 vm_pagezero() at vm_pagezero+0x73 fork_exit() at fork_exit+0x12a for= k_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffff= ff8077bc3d40, rbp =3D 0 --- Tracing command vmdaemon pid 37 tid 100061 td 0= xffffff0004f0cab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_w= ait+0x4d _sleep() at _sleep+0x34b vm_daemon() at vm_daemon+0x4d fork_exit()= at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, ri= p =3D 0, rsp =3D 0xffffff8077bbed40, rbp =3D 0 --- Tracing command pagedaem= on pid 36 tid 100060 td 0xffffff0004f0e000 cpustop_handler() at cpustop_han= dler+0x3b ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x1b8 nm= i_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip =3D 0xffffffff8049f404,= rsp =3D 0xffffffff808e6820, rbp =3D 0xffffff8077bb94b0 --- DELAY() at DELA= Y+0x64 ns8250_putc() at ns8250_putc+0x9a uart_cnputc() at uart_cnputc+0x4e = cnputc() at cnputc+0x49 putchar() at putchar+0x6a kvprintf() at kvprintf+0x= 81 vprintf() at vprintf+0x3e printf() at printf+0x67 swp_pager_getswapspace= () at swp_pager_getswapspace+0xc7 swap_pager_putpages() at swap_pager_putpa= ges+0x185 vm_pageout_flush() at vm_pageout_flush+0x14f vm_pageout_clean() a= t vm_pageout_clean+0xfc vm_pageout() at vm_pageout+0x1168 fork_exit() at fo= rk_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D = 0, rsp =3D 0xffffff8077bb9d40, rbp =3D 0 --- Tracing command g_mirror boot = pid 35 tid 100059 td 0xffffff0004f0e390 sched_switch() at sched_switch+0x19= 0 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sle= epq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b g_mirror_worker() a= t g_mirror_worker+0xb1c fork_exit() at fork_exit+0x12a fork_trampoline() at= fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077bb4d40, rbp= =3D 0 --- Tracing command l2arc_feed_thread pid 34 tid 100058 td 0xffffff0= 004f0e720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_time= dwait+0x4d _cv_timedwait() at _cv_timedwait+0x18c l2arc_feed_thread() at l2= arc_feed_thread+0x169 fork_exit() at fork_exit+0x12a fork_trampoline() at f= ork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077bafd40, rbp = =3D 0 --- Tracing command arc_reclaim_thread pid 9 tid 100057 td 0xffffff00= 04f0eab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21= d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_timed= wait+0x4d _cv_timedwait() at _cv_timedwait+0x18c arc_reclaim_thread() at ar= c_reclaim_thread+0x2ba fork_exit() at fork_exit+0x12a fork_trampoline() at = fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077baad40, rbp = =3D 0 --- Tracing command usbus4 pid 33 tid 100056 td 0xffffff0004ec6390 sc= hed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_sw= itch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at= _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit= +0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp = =3D 0xffffff8077ba5d40, rbp =3D 0 --- Tracing command usbus4 pid 32 tid 100= 055 td 0xffffff0004ec6720 sched_switch() at sched_switch+0x190 mi_switch() = at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at = sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x= 14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe= --- trap 0, rip =3D 0, rsp =3D 0xffffff8077ba0d40, rbp =3D 0 --- Tracing c= ommand usbus4 pid 31 tid 100054 td 0xffffff0004ec6ab0 sched_switch() at sch= ed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_sw= itch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_= process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampol= ine() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b9b= d40, rbp =3D 0 --- Tracing command usbus4 pid 30 tid 100053 td 0xffffff0004= ee8000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d = sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _s= leep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at = fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = =3D 0, rsp =3D 0xffffff8077b96d40, rbp =3D 0 --- Tracing command usbus3 pid= 29 tid 100052 td 0xffffff0004ee8390 sched_switch() at sched_switch+0x190 m= i_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq= _wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2= _process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tra= mpoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b91d40, rbp =3D 0 --= - Tracing command usbus3 pid 28 tid 100051 td 0xffffff0004ee8720 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+= 0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a f= ork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xff= ffff8077b8cd40, rbp =3D 0 --- Tracing command usbus3 pid 27 tid 100050 td 0= xffffff0004ee8ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_w= ait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork= _exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- tra= p 0, rip =3D 0, rsp =3D 0xffffff8077b87d40, rbp =3D 0 --- Tracing command u= sbus3 pid 26 tid 100049 td 0xffffff0004ee9000 sched_switch() at sched_switc= h+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x1= 23 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process(= ) at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at= fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b82d40, rbp= =3D 0 --- Tracing command usbus2 pid 25 tid 100048 td 0xffffff0004ee9390 s= ched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_s= witch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() a= t _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exi= t+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp= =3D 0xffffff8077b7dd40, rbp =3D 0 --- Tracing command usbus2 pid 24 tid 10= 0047 td 0xffffff0004ee9720 sched_switch() at sched_switch+0x190 mi_switch()= at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at= sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0= x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0x= e --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b78d40, rbp =3D 0 --- Tracing = command usbus2 pid 23 tid 100046 td 0xffffff0004ee9ab0 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2= _process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampo= line() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b7= 3d40, rbp =3D 0 --- Tracing command usbus2 pid 22 tid 100045 td 0xffffff000= 15b4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d= sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _= sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at= fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = =3D 0, rsp =3D 0xffffff8077b6ed40, rbp =3D 0 --- Tracing command usbus1 pid= 21 tid 100044 td 0xffffff0004ec3000 sched_switch() at sched_switch+0x190 m= i_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq= _wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2= _process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_tra= mpoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b69d40, rbp =3D 0 --= - Tracing command usbus1 pid 20 tid 100043 td 0xffffff0004ec3390 sched_swit= ch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() a= t sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+= 0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a f= ork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xff= ffff8077b64d40, rbp =3D 0 --- Tracing command usbus1 pid 19 tid 100042 td 0= xffffff0004ec3720 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_w= ait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork= _exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- tra= p 0, rip =3D 0, rsp =3D 0xffffff8077b5fd40, rbp =3D 0 --- Tracing command u= sbus1 pid 18 tid 100041 td 0xffffff0004ec3ab0 sched_switch() at sched_switc= h+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x1= 23 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process(= ) at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampoline() at= fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b5ad40, rbp= =3D 0 --- Tracing command usbus0 pid 17 tid 100040 td 0xffffff0004ec4000 s= ched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_s= witch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() a= t _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at fork_exi= t+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp= =3D 0xffffff8077b55d40, rbp =3D 0 --- Tracing command usbus0 pid 16 tid 10= 0039 td 0xffffff0004ec4390 sched_switch() at sched_switch+0x190 mi_switch()= at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at= sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2_process() at usb2_process+0= x14b fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0x= e --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b50d40, rbp =3D 0 --- Tracing = command usbus0 pid 15 tid 100038 td 0xffffff0004ec4720 sched_switch() at sc= hed_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_s= witch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b usb2= _process() at usb2_process+0x14b fork_exit() at fork_exit+0x12a fork_trampo= line() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8077b4= bd40, rbp =3D 0 --- Tracing command usbus0 pid 14 tid 100037 td 0xffffff000= 4ec4ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d= sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _= sleep() at _sleep+0x34b usb2_process() at usb2_process+0x14b fork_exit() at= fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = =3D 0, rsp =3D 0xffffff8077b46d40, rbp =3D 0 --- Tracing command sctp_itera= tor pid 8 tid 100036 td 0xffffff0004ec6000 sched_switch() at sched_switch+0= x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 = sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b sctp_iterator_th= read() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x12a fork_tra= mpoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff807= 7b41d40, rbp =3D 0 --- Tracing command xpt_thrd pid 7 tid 100020 td 0xfffff= f0001563000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0= x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x= 4d _sleep() at _sleep+0x34b xpt_scanner_thread() at xpt_scanner_thread+0x3a= fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --= - trap 0, rip =3D 0, rsp =3D 0xffffff8000076d40, rbp =3D 0 --- Tracing comm= and system_taskq pid 6 tid 100015 td 0xffffff00014d1720 sched_switch() at s= ched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_= switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17a= taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x12a fork_t= rampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8= 00005dd40, rbp =3D 0 --- Tracing command system_taskq pid 5 tid 100014 td 0= xffffff00014d1ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_sw= itch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_w= ait+0x4d _cv_wait() at _cv_wait+0x17a taskq_thread() at taskq_thread+0x33b = fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ---= trap 0, rip =3D 0, rsp =3D 0xffffff8000058d40, rbp =3D 0 --- Tracing comma= nd yarrow pid 13 tid 100013 td 0xffffff00014d2000 sched_switch() at sched_s= witch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch= +0x123 sleepq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335= random_kthread() at random_kthread+0x1ad fork_exit() at fork_exit+0x12a fo= rk_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfff= fff8000053d40, rbp =3D 0 --- Tracing command g_down pid 4 tid 100011 td 0xf= fffff00014b6390 sched_switch() at sched_switch+0x190 mi_switch() at mi_swit= ch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleep= q_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_down() at g_io_sche= dule_down+0x250 g_down_procbody() at g_down_procbody+0x6f fork_exit() at fo= rk_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D = 0, rsp =3D 0xffffff8000049d40, rbp =3D 0 --- Tracing command g_up pid 3 tid= 100010 td 0xffffff00014b6720 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_timedw= ait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_io_schedule_up() = at g_io_schedule_up+0x154 g_up_procbody() at g_up_procbody+0x6f fork_exit()= at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, ri= p =3D 0, rsp =3D 0xffffff8000044d40, rbp =3D 0 --- Tracing command g_event = pid 2 tid 100009 td 0xffffff00014b6ab0 sched_switch() at sched_switch+0x190= mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 slee= pq_timedwait() at sleepq_timedwait+0x4d _sleep() at _sleep+0x335 g_event_pr= ocbody() at g_event_procbody+0xa1 fork_exit() at fork_exit+0x12a fork_tramp= oline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80000= 3fd40, rbp =3D 0 --- Tracing command intr pid 12 tid 100035 td 0xffffff0001= 563720 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d = ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_tr= ampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80= 77b39d40, rbp =3D 0 --- Tracing command intr pid 12 tid 100034 td 0xffffff0= 001563ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 = tid 100033 td 0xffffff00015b2000 sched_switch() at sched_switch+0x190 mi_sw= itch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() = at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip= =3D 0, rsp =3D 0xffffff8075b6fd40, rbp =3D 0 --- Tracing command intr pid = 12 tid 100032 td 0xffffff00015b2390 fork_trampoline() at fork_trampoline Tr= acing command intr pid 12 tid 100031 td 0xffffff00015b2720 fork_trampoline(= ) at fork_trampoline Tracing command intr pid 12 tid 100030 td 0xffffff0001= 5b2ab0 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d = ithread_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_tr= ampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80= 7566ad40, rbp =3D 0 --- Tracing command intr pid 12 tid 100029 td 0xffffff0= 0015b4000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 = tid 100026 td 0xffffff00014d2720 fork_trampoline() at fork_trampoline Traci= ng command intr pid 12 tid 100021 td 0xffffff0001561ab0 fork_trampoline() a= t fork_trampoline Tracing command intr pid 12 tid 100019 td 0xffffff0001563= 390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d ith= read_loop() at ithread_loop+0x246 fork_exit() at fork_exit+0x12a fork_tramp= oline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff80000= 71d40, rbp =3D 0 --- Tracing command intr pid 12 tid 100018 td 0xffffff0001= 4c7ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid= 100016 td 0xffffff00014d1390 sched_switch() at sched_switch+0x190 mi_switc= h() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit() at = fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = =3D 0, rsp =3D 0xffffff8000062d40, rbp =3D 0 --- Tracing command intr pid 1= 2 tid 100008 td 0xffffff00014c7000 sched_switch() at sched_switch+0x190 mi_= switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_exit(= ) at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, r= ip =3D 0, rsp =3D 0xffffff800003ad40, rbp =3D 0 --- Tracing command intr pi= d 12 tid 100007 td 0xffffff00014c7390 sched_switch() at sched_switch+0x190 = mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork_ex= it() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0= , rip =3D 0, rsp =3D 0xffffff8000035d40, rbp =3D 0 --- Tracing command intr= pid 12 tid 100006 td 0xffffff00014c7720 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d ithread_loop() at ithread_loop+0x246 fork= _exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- tra= p 0, rip =3D 0, rsp =3D 0xffffff8000030d40, rbp =3D 0 --- Tracing command i= ntr pid 12 tid 100005 td 0xffffff00014b4000 fork_trampoline() at fork_tramp= oline Tracing command idle pid 11 tid 100004 td 0xffffff00014b4390 sched_sw= itch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idletd() = at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() at f= ork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8000026d40, rbp = =3D 0 --- Tracing command idle pid 11 tid 100003 td 0xffffff00014b4720 sche= d_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sched_idlet= d() at sched_idletd+0x26d fork_exit() at fork_exit+0x12a fork_trampoline() = at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8000021d40, r= bp =3D 0 --- Tracing command init pid 1 tid 100002 td 0xffffff00014b4ab0 sc= hed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_sw= itch() at sleepq_switch+0x123 sleepq_catch_signals() at sleepq_catch_signal= s+0x24e sleepq_wait_sig() at sleepq_wait_sig+0x16 _sleep() at _sleep+0x2fe = kern_wait() at kern_wait+0x3cc wait4() at wait4+0x35 syscall() at syscall+0= x1dd Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (7, FreeBSD ELF64, w= ait4), rip =3D 0x40c62c, rsp =3D 0x7fffffffe808, rbp =3D 0x401d40 --- Traci= ng command audit pid 10 tid 100001 td 0xffffff00014b6000 sched_switch() at = sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq= _switch+0x123 sleepq_wait() at sleepq_wait+0x4d _cv_wait() at _cv_wait+0x17= a audit_worker() at audit_worker+0x77 fork_exit() at fork_exit+0x12a fork_t= rampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8= 000017d40, rbp =3D 0 --- Tracing command kernel pid 0 tid 100028 td 0xfffff= f00015b4390 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0= x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x= 4d msleep_spin() at msleep_spin+0x209 taskqueue_thread_loop() at taskqueue_= thread_loop+0x5c fork_exit() at fork_exit+0x12a fork_trampoline() at fork_t= rampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff800009ed40, rbp =3D 0 = --- Tracing command kernel pid 0 tid 100027 td 0xffffff00015b4720 sched_swi= tch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() = at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d msleep_spin() at m= sleep_spin+0x209 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork= _exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- tra= p 0, rip =3D 0, rsp =3D 0xffffff8000099d40, rbp =3D 0 --- Tracing command k= ernel pid 0 tid 100025 td 0xffffff00014d2ab0 sched_switch() at sched_switch= +0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x12= 3 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thre= ad_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork= _trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xfffff= f800008fd40, rbp =3D 0 --- Tracing command kernel pid 0 tid 100024 td 0xfff= fff0001561000 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch= +0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+= 0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_l= oop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampolin= e+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff800008ad40, rbp =3D 0 --- Trac= ing command kernel pid 0 tid 100023 td 0xffffff0001561390 sched_switch() at= sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_switch() at sleep= q_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b t= askqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_ex= it+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rs= p =3D 0xffffff8000085d40, rbp =3D 0 --- Tracing command kernel pid 0 tid 10= 0022 td 0xffffff0001561720 sched_switch() at sched_switch+0x190 mi_switch()= at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at= sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_loop() at taskq= ueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_trampoline() at f= ork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff8000080d40, rbp = =3D 0 --- Tracing command kernel pid 0 tid 100017 td 0xffffff00014d1000 sch= ed_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x21d sleepq_swi= tch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at = _sleep+0x34b taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exi= t() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0,= rip =3D 0, rsp =3D 0xffffff8000067d40, rbp =3D 0 --- Tracing command kerne= l pid 0 tid 100012 td 0xffffff00014d2390 sched_switch() at sched_switch+0x1= 90 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sl= eepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x34b taskqueue_thread_l= oop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x12a fork_tra= mpoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff800= 004ed40, rbp =3D 0 --- Tracing command kernel pid 0 tid 100000 td 0xfffffff= f806d8920 sched_switch() at sched_switch+0x190 mi_switch() at mi_switch+0x2= 1d sleepq_switch() at sleepq_switch+0x123 sleepq_timedwait() at sleepq_time= dwait+0x4d _sleep() at _sleep+0x335 scheduler() at scheduler+0x292 mi_start= up() at mi_startup+0x59 btext() at btext+0x2c db> --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:38:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98151065675 for ; Mon, 1 Jun 2009 00:38:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7699E8FC17 for ; Mon, 1 Jun 2009 00:38:38 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so7351964bwz.43 for ; Sun, 31 May 2009 17:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=edN254WDaVSKVqvQPJtfRZkyPElEGheb0uPLRjfY1gI=; b=dqo7NOUmWt22WI6fzkdaxnTOFk6gSKARww2d95VnAe4zd75BYZWvZmsiI3aiTsXIrG YJWQe5/hEbq2z9PFXiLY4cgSS7Bdk/haUG91lqqRBzp3Rh0YPvwm4Vl1Tg6LUFLqGTqA ukgwDeh5EmXZoniftd8Fts17V+mMxJliBAwak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VjeC6KOcF38bKijd4Zm+s5kbpvvz4QxS3pYN1Br7uyJqB7DzqyuVUv3nyoYrV0We6r F7WOKRRe4ggr5H9Q1iva/n6QjfY/sZ67Fp9smB2DyNuBJf08X8xwyrzR5SDzgjfgXxQ2 wIRnKDK/woVZNB5kIUPe+8PXWfjBfBehFfF2Y= MIME-Version: 1.0 Received: by 10.204.62.78 with SMTP id w14mr5191209bkh.13.1243816717309; Sun, 31 May 2009 17:38:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2009 00:38:37 +0000 Message-ID: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> From: "Paul B. Mahol" To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current Subject: Re: installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:38:39 -0000 On 6/1/09, Randy Bush wrote: >> ===> usr.bin/ee (install) >> install -s -o root -g wheel -m 555 ee /usr/bin >> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg >> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg >> gencat:No such file or directory >> *** Error code 1 >> >> Stop in /usr/src/usr.bin/ee. >> *** Error code 1 >> >> Stop in /usr/src/usr.bin. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 > > new cvsup > rm -rf /usr/obj > > no help, repeats You should have gencat allready installed: cd /usr/src/usr.bin/gencat && make install -- Paul From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:44:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11946106566B for ; Mon, 1 Jun 2009 00:44:11 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E595B8FC15 for ; Mon, 1 Jun 2009 00:44:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAvdJ-000EUi-6k; Mon, 01 Jun 2009 00:44:09 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id AC66E1CA68C7; Mon, 1 Jun 2009 09:44:08 +0900 (JST) Date: Mon, 01 Jun 2009 09:44:08 +0900 Message-ID: From: Randy Bush To: Kip Macy In-Reply-To: <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:44:11 -0000 > Are your sources from CVS or svn? cvs > The backtrace indicates that you have code that I backed out a little > over a week ago. i will cvsup again randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:45:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA2B106566B for ; Mon, 1 Jun 2009 00:45:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 917A48FC15 for ; Mon, 1 Jun 2009 00:45:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAvez-000EXZ-At; Mon, 01 Jun 2009 00:45:53 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id CA75A1CA6B21; Mon, 1 Jun 2009 09:45:52 +0900 (JST) Date: Mon, 01 Jun 2009 09:45:52 +0900 Message-ID: From: Randy Bush To: "Paul B. Mahol" In-Reply-To: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current Subject: Re: installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:45:53 -0000 >>> ===> usr.bin/ee (install) >>> install -s -o root -g wheel -m 555 ee /usr/bin >>> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg >>> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg >>> gencat:No such file or directory >>> *** Error code 1 >>> >>> Stop in /usr/src/usr.bin/ee. >>> *** Error code 1 >>> >>> Stop in /usr/src/usr.bin. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >> >> new cvsup >> rm -rf /usr/obj >> >> no help, repeats > > You should have gencat allready installed: > > cd /usr/src/usr.bin/gencat && make install gencat is installed. it is whining that it can not find the file randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 00:47:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C152106566C for ; Mon, 1 Jun 2009 00:47:43 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id EBCCF8FC08 for ; Mon, 1 Jun 2009 00:47:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by ewy8 with SMTP id 8so4039852ewy.43 for ; Sun, 31 May 2009 17:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NRr3gt5fU+c++NdGL71kSB1TJn60bMaNazt/wR5EDYM=; b=XoFDD3XTq1m5ZDwuKmO5A9d6rnoRDebQavyMzX/8oPJ1+vkDkB7ftYFGH6+nVlpRCv rS91xmShzbomi3Vq4rbk9+EBpjYcVg834RpVlMO5wmEZS5v5jdpxrlow23CNncEfP/mb zOtXWu9Zaa1TanrrqaZ8igs+jTsnXmNOu8xpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Twt7FEo0secqlH69/YbwZFOrpJ7HzzbxVl9PtoS27VRcKemKDmtARpypc54tZ2V7g5 RhqcPC9WqdrNPGYmoXUbiOs2PTvSR4iMLej7xx02hL3enqKjq22IYwCfCd4BGaWft3Pq xKHkLfZQHp82LsYHQuXro+T9PrCqKr8RtI6nY= Received: by 10.211.194.4 with SMTP id w4mr1590193ebp.33.1243817262094; Sun, 31 May 2009 17:47:42 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 28sm125327eyg.34.2009.05.31.17.47.40 (version=SSLv3 cipher=RC4-MD5); Sun, 31 May 2009 17:47:41 -0700 (PDT) Message-ID: <4A2325F1.8010300@gmail.com> Date: Mon, 01 Jun 2009 02:50:57 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A1DD57A.7010704@gmail.com> <4A1E9831.4010606@incunabulum.net> <4A1EC8FB.6090206@gmail.com> <4A1FBFF5.6090103@incunabulum.net> <4A20791D.5070209@gmail.com> <4A22E2F1.6070404@incunabulum.net> In-Reply-To: <4A22E2F1.6070404@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: panic: igmp_v3_dispatch_general_query: called when version 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 00:47:43 -0000 Bruce Simpson wrote: > deeptech71@gmail.com wrote: >> Bruce Simpson wrote: >>> I may not get free time to fix this right away, are you able to test a >>> patch when I can make one available? >> >> Sure. > > Thanks. Can you please test this patch and let me know if it works for you? OK, applied, but what now? If you are sure that you have fixed the bug, but just want me to run a "crash test" before commiting, then all I can say is there's nothing wrong yet, I'll keep running the patch until something comes up, like a panic (and report it). Otherwise I can't test wether the patch does avoid the non-reproducable panic. From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 01:13:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CD8106566C for ; Mon, 1 Jun 2009 01:13:42 +0000 (UTC) (envelope-from samuel@boivie.org) Received: from fallback-in1.mxes.net (fallback-out1.mxes.net [216.86.168.190]) by mx1.freebsd.org (Postfix) with ESMTP id 084B08FC15 for ; Mon, 1 Jun 2009 01:13:41 +0000 (UTC) (envelope-from samuel@boivie.org) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by fallback-in1.mxes.net (Postfix) with ESMTP id 3698516467E for ; Sun, 31 May 2009 20:57:50 -0400 (EDT) Received: from wm2.irbs.net (wm2.irbs.net [216.86.168.169]) by smtp.mxes.net (Postfix) with ESMTP id 2A2FB23E3E1 for ; Sun, 31 May 2009 20:57:49 -0400 (EDT) Received: from wmbeta.tuffmail.net (wm2.irbs.net [216.86.168.169]) by wm2.irbs.net (Postfix) with ESMTPA id 033F38579C for ; Sun, 31 May 2009 20:57:48 -0400 (EDT) Received: from 213.89.32.208 by wmbeta.tuffmail.net with HTTP; Mon, 1 Jun 2009 02:57:49 +0200 (CEST) Message-ID: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> Date: Mon, 1 Jun 2009 02:57:49 +0200 (CEST) From: "Samuel Boivie" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 01 Jun 2009 01:53:58 +0000 Subject: Removal of legacy USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 01:13:42 -0000 It seems to me as if ports/x11/kdebase4 and probably friends still depend on the old usb stack, and hence fail to compile now (after the removal on May 27). Is it as easy as fixing the port to point at the new one or are the differences between the stacks still there? Samuel From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 02:04:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38F99106566C for ; Mon, 1 Jun 2009 02:04:24 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id E39668FC08 for ; Mon, 1 Jun 2009 02:04:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so3865807ana.13 for ; Sun, 31 May 2009 19:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ln4WLLXcAtbwpe5EwAK+25yWtWXIxX5aE3EPZ0H+QEM=; b=dYuKp2Zwjs1G3aHvxB2B+qP5kptP6wSM4EZF2AvyUmtYHTWcNNAkAaa7/ZZaj+Vy1c bUvp8GbpGPERsevok8RdXpdf2rdWFBaoZefd7pc9kkcdzZvrTnr1xgilZehpdpsUeDU8 0Kqdi3dbMSURp8ZIkOBI/BQZr7cIqictEofNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dvluBp8NdFAkV7unVOI8qCCoUhuIsipC6k2oNJpW5zgpj/orcrBpewC8WyBp5b6wzP a0j1dM23JjyRmMV9ge3cdM2VB/6Z5lK+6X7rpAL56Fhz1dQQbLfL2iJc5bKD1FRNw2dy d5aT7m3f8fAdgG0ZDzLcrNGxyYFmwLA53zF8w= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.143.17 with SMTP id q17mr6269371and.114.1243821863249; Sun, 31 May 2009 19:04:23 -0700 (PDT) In-Reply-To: References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> Date: Sun, 31 May 2009 19:04:23 -0700 X-Google-Sender-Auth: 9e99f9f3cb3073d0 Message-ID: <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> From: Kip Macy To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current , Peter Wemm Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 02:04:24 -0000 On Sun, May 31, 2009 at 5:44 PM, Randy Bush wrote: >> Are your sources from CVS or svn? > > cvs > >> The backtrace indicates that you have code that I backed out a little >> over a week ago. > > i will cvsup again > That won't help. CVS is missing changes from svn. Peter - What would cause cvs to miss fall out of sync? Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 02:16:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 681DD106564A; Mon, 1 Jun 2009 02:16:23 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3F49F8FC15; Mon, 1 Jun 2009 02:16:23 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MAx4Y-000ElC-Lx; Mon, 01 Jun 2009 02:16:22 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 2D8A91CAE452; Mon, 1 Jun 2009 11:16:22 +0900 (JST) Date: Mon, 01 Jun 2009 11:16:21 +0900 Message-ID: From: Randy Bush To: Kip Macy In-Reply-To: <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> References: <4A221EF2.6010607@egr.msu.edu> <3c1674c90905302312h70e2088cn41c92c8fff61ea92@mail.gmail.com> <3c1674c90905311731m46c77362v1d3997f3647945fb@mail.gmail.com> <3c1674c90905311904t4ea332fen72753e3fc66de910@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current , Peter Wemm Subject: Re: kern/134011: [hang] swap_pager_getswapspace(4): failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 02:16:23 -0000 > CVS is missing changes from svn. oh goodie! and no extra charge! :) i think i will go work on something else for a bit. thanks for the warning. randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 02:17:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CD811065674 for ; Mon, 1 Jun 2009 02:17:02 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id DFA3D8FC24 for ; Mon, 1 Jun 2009 02:17:01 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 90552FF0F; Mon, 1 Jun 2009 14:17:00 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YmXEJcp9XKW; Mon, 1 Jun 2009 14:16:55 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 1 Jun 2009 14:16:55 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A85DB11434; Mon, 1 Jun 2009 14:16:54 +1200 (NZST) Date: Sun, 31 May 2009 19:16:54 -0700 From: Andrew Thompson To: Samuel Boivie Message-ID: <20090601021654.GA99430@citylink.fud.org.nz> References: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28162.213.89.32.208.1243817869.squirrel@wmbeta.tuffmail.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org Subject: Re: Removal of legacy USB stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 02:17:02 -0000 On Mon, Jun 01, 2009 at 02:57:49AM +0200, Samuel Boivie wrote: > It seems to me as if ports/x11/kdebase4 and probably friends still depend > on the old usb stack, and hence fail to compile now (after the removal on > May 27). Is it as easy as fixing the port to point at the new one or are > the differences between the stacks still there? Since Feb 23rd the old usb stack hasnt been compiled in so while kdebase4 continued to compile by using the header files it would not actually be able to talk usb. The best way is to update the port to use libusb. cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 04:23:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 298B3106566B; Mon, 1 Jun 2009 04:23:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id F35008FC19; Mon, 1 Jun 2009 04:23:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n514Mwoj020255; Mon, 1 Jun 2009 00:22:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n514MwKv080786; Mon, 1 Jun 2009 00:22:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 909C77302F; Mon, 1 Jun 2009 00:22:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090601042258.909C77302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 00:22:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 04:23:04 -0000 TB --- 2009-06-01 03:37:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 03:37:32 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-01 03:37:32 - cleaning the object tree TB --- 2009-06-01 03:37:41 - cvsupping the source tree TB --- 2009-06-01 03:37:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-01 03:37:49 - building world TB --- 2009-06-01 03:37:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 03:37:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 03:37:49 - TARGET=ia64 TB --- 2009-06-01 03:37:49 - TARGET_ARCH=ia64 TB --- 2009-06-01 03:37:49 - TZ=UTC TB --- 2009-06-01 03:37:49 - __MAKE_CONF=/dev/null TB --- 2009-06-01 03:37:49 - cd /src TB --- 2009-06-01 03:37:49 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 03:37:50 UTC 2009 >>> 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 [...] ===> lib/bind/bind9 (all) cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind9/ lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token *** Error code 1 Stop in /src/lib/bind/bind9. *** Error code 1 Stop in /src/lib/bind. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 04:22:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 04:22:58 - ERROR: failed to build world TB --- 2009-06-01 04:22:58 - 2173.84 user 195.73 system 2725.93 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 04:39:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34AA1106564A for ; Mon, 1 Jun 2009 04:39:28 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id DF0B38FC1F for ; Mon, 1 Jun 2009 04:39:27 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so3811299yxb.13 for ; Sun, 31 May 2009 21:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ERuocifPTpYqIa+J0s/B5haFN28YrA448+/Yi/s2R2M=; b=d05Z+96WsvPkjg9Is7F4+Wtf7P4R2gw6g7kc1GYWsRDumn4CMe49FvoAIpc25jgFNe B7EqxBTH7/NoF8Mcs1rqhK7dEoVnxoMKKDh6T4TEe8RoB9sYlbHKLkJtffaTHj7kP+FI kkMzXjsUeigP18JY0hNUBh4FtWY9T06l/RYqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=E4ZvRvFsbNqwulvlndLZwxpVl8GbVgfAv+Oej5kmy9XslD6BjqBMVDeqZ5i1hvVT/l BMlQ9YCbMDU9HhQ4O24hIwcj8MY6ynScH0QOMxnwAETcqxc/IvHNMHgs1G4+Rt5Djxgl jaoOkeu6DAcGyaJfWfQE8pJNqzs87Dw77GzZI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.231.4 with SMTP id d4mr6630564anh.24.1243831166970; Sun, 31 May 2009 21:39:26 -0700 (PDT) In-Reply-To: <20090531074907.GA26858@ichotolot.servalan.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> <20090531074907.GA26858@ichotolot.servalan.com> Date: Sun, 31 May 2009 21:39:26 -0700 X-Google-Sender-Auth: 3d19d0b6085a2f2d Message-ID: <3c1674c90905312139p6ad5020dgb82f0740f75fd096@mail.gmail.com> From: Kip Macy To: Richard Todd , Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Bug in recent large_alloc changes to the ZFS zio code? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 04:39:28 -0000 On Sun, May 31, 2009 at 12:49 AM, Richard Todd wrote: > On Sat, May 30, 2009 at 11:54:47PM -0700, Kip Macy wrote: >> http://svn.freebsd.org/changeset/base/192360 >> > > Ah. =A0Hmm. =A0So if I'm reading this right, you already backed out that = change > in the master SVN repo, right? =A0Well, *something* weird's going on, bec= ause > that change never seems to have made it to the CVS version of the repo or= to > the cvsup sites, because I'm not seeing it there; see for yourself at > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/ut= s/common/fs/zfs/ > . =A0The commit log for 192360 never showed up in CVSROOT-src/commitlogs/= sys > either. =A0So it looks like bits are falling on the floor somewhere betwe= en > the SVN and CVS repos. > > Yup. This is causing problems for other ZFS users on head. It looks like if you use ZFS on head you need to use svn. I'm not in a position to fix this issue. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 05:28:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1117910656D8 for ; Mon, 1 Jun 2009 05:28:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id A00F08FC2D for ; Mon, 1 Jun 2009 05:28:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 14818 invoked by uid 399); 1 Jun 2009 05:01:49 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Jun 2009 05:01:49 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A2360BC.8040109@FreeBSD.org> Date: Sun, 31 May 2009 22:01:48 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: FreeBSD Tinderbox References: <20090601042258.909C77302F@freebsd-current.sentex.ca> In-Reply-To: <20090601042258.909C77302F@freebsd-current.sentex.ca> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, ia64@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 05:28:34 -0000 FYI, I'm aware of this issue and I've filed a bug report with the ISC folks. If anyone has a bright idea on how to fix it I'm all ears, but I tried everything I can think of already and no luck so far. Sorry for the inconvenience, Doug FreeBSD Tinderbox wrote: > TB --- 2009-06-01 03:37:32 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-06-01 03:37:32 - starting HEAD tinderbox run for ia64/ia64 > TB --- 2009-06-01 03:37:32 - cleaning the object tree > TB --- 2009-06-01 03:37:41 - cvsupping the source tree > TB --- 2009-06-01 03:37:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile > TB --- 2009-06-01 03:37:49 - building world > TB --- 2009-06-01 03:37:49 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-06-01 03:37:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-06-01 03:37:49 - TARGET=ia64 > TB --- 2009-06-01 03:37:49 - TARGET_ARCH=ia64 > TB --- 2009-06-01 03:37:49 - TZ=UTC > TB --- 2009-06-01 03:37:49 - __MAKE_CONF=/dev/null > TB --- 2009-06-01 03:37:49 - cd /src > TB --- 2009-06-01 03:37:49 - /usr/bin/make -B buildworld >>>> World build started on Mon Jun 1 03:37:50 UTC 2009 >>>> 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 > [...] > ===> lib/bind/bind9 (all) > cc -O2 -pipe -DVERSION='"9.6.1rc1"' -DHAVE_CONFIG_H -D_REENTRANT -D_THREAD_SAFE -DLIBINTERFACE=50 -DLIBREVISION=2 -DLIBAGE=0 -DWANT_IPV6 -DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"' -DNAMED_CONFFILE='"/etc/namedb/named.conf"' -DRNDC_CONFFILE='"/etc/namedb/rndc.conf"' -DRNDC_KEYFILE='"/etc/namedb/rndc.key"' -I/src/lib/bind/bind9/.. -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dst -I/src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include -I/src/lib/bind/bind9/../dns -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccc/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isccfg/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/pthreads/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include -I/src/lib/bind/bind9/../isc -I/src/lib/bind/bind9/../../../contrib/bind 9/ > lib/lwres/unix/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/lwres/include -I/src/lib/bind/bind9/../lwres -I/src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/include -I/src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include -std=gnu99 -c /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c > In file included from /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/include/isc/refcount.h:23, > from /src/lib/bind/bind9/../../../contrib/bind9/lib/dns/include/dns/acl.h:39, > from /src/lib/bind/bind9/../../../contrib/bind9/lib/bind9/check.c:38: > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:38: error: expected ',' or ';' before '{' token > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:64: error: expected ',' or ';' before '{' token > /src/lib/bind/bind9/../../../contrib/bind9/lib/isc/ia64/include/isc/atomic.h:83: error: expected ',' or ';' before '{' token > *** Error code 1 > > Stop in /src/lib/bind/bind9. > *** Error code 1 > > Stop in /src/lib/bind. > *** Error code 1 > > Stop in /src/lib. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-06-01 04:22:58 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-06-01 04:22:58 - ERROR: failed to build world > TB --- 2009-06-01 04:22:58 - 2173.84 user 195.73 system 2725.93 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full > _______________________________________________ > 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" > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 07:20:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 901F51065670 for ; Mon, 1 Jun 2009 07:20:43 +0000 (UTC) (envelope-from zec@freebsd.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 244478FC1C for ; Mon, 1 Jun 2009 07:20:43 +0000 (UTC) (envelope-from zec@freebsd.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 18B2E9B645; Mon, 1 Jun 2009 09:20:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL autolearn=unavailable version=3.1.7 Received: from localhost (imunes.tel.fer.hr [161.53.19.8]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 14F7E9B646; Mon, 1 Jun 2009 09:20:11 +0200 (CEST) From: Marko Zec To: freebsd-current@freebsd.org Date: Mon, 1 Jun 2009 09:20:08 +0200 User-Agent: KMail/1.9.10 References: <200905311205.02507.r.neese@gmail.com> In-Reply-To: <200905311205.02507.r.neese@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906010920.08263.zec@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Richard Neese Subject: Re: making world on 7.2 to update to 8.0-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 07:20:43 -0000 On Sunday 31 May 2009 18:05:02 Richard Neese wrote: > when running make buildworld on 7.2 to update to 8.0 current I get the > fallowing error This is already fixed by r193177, pls. update your sources. Marko > ===> usr.bin/kdump (all) > cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - > I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c > /usr/src/usr.bin/kdump/kdump.c > cc -O2 -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump - > I/usr/src/usr.bin/kdump/../.. -std=gnu99 -fstack-protector -c ioctl.c > ioctl.c: In function 'ioctlname': > ioctl.c:1089: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > ioctl.c:1405: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > ioctl.c:2679: error: invalid application of 'sizeof' to incomplete type > 'struct vi_req' > *** Error code 1 > > Stop in /usr/src/usr.bin/kdump. > *** Error code 1 > > switch-1# uname -a > FreeBSD switch-1.daemonswitch.com 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue > May 12 14:35:01 EDT 2009 > root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER i386 > > Copyright (c) 1992-2009 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 7.2-RELEASE #0: Tue May 12 14:35:01 EDT 2009 > root@switch-1.daemonswitch.com:/usr/obj/usr/src/sys/SERVER > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ (2099.96-MHz 686-class > CPU) > Origin = "AuthenticAMD" Id = 0x60fb1 Stepping = 1 > > Features=0x178bfbffA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > Cores per package: 2 > real memory = 518979584 (494 MB) > avail memory = 498069504 (474 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > > _______________________________________________ > 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 Jun 1 08:30:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96A2106566B; Mon, 1 Jun 2009 08:30:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 53B698FC1C; Mon, 1 Jun 2009 08:30:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=qz79GjZVivWlyQPMeKvaojIkB/R13u+yJ+kV4VUnd5cND2teJeuayMkwjgTgUqsw/Bt1GZkHZmfcBZoQZfpI5L6E11SlZYr2IlXneXd8fluDb3kkueQpEA7vrQ6ajql4w2wvqN+60j/90xwCjtWzD+suPXBQpa8zB8CweiZz4uo=; Received: from shadow.codelabs.ru (shadow.codelabs.ru [144.206.177.8]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MB2gv-0000W9-Vm; Mon, 01 Jun 2009 12:16:22 +0400 Date: Mon, 1 Jun 2009 12:16:18 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <4A2360BC.8040109@FreeBSD.org> Sender: rea-fbsd@codelabs.ru Cc: ia64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 08:30:39 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Doug, good day. Sun, May 31, 2009 at 10:01:48PM -0700, Doug Barton wrote: > FYI, I'm aware of this issue and I've filed a bug report with the ISC > folks. If anyone has a bright idea on how to fix it I'm all ears, but > I tried everything I can think of already and no luck so far. Seems like GCC likes to see __attribute__ stuff only for function prototypes, not for declarations. The attached patch seems to fix the stuff, but I have no ia64 system to test on. Quick test with 'make ISC_ATOMIC_ARCH=ia64' eliminates errors. This is very weird (judging by the GCC's manual) since the simplest C program, ----- int main(void) { return 0; } void foo(void) __attribute__ ((unused)) { return; } ----- but ICC 10.x produces the same error and happily chewes __attribute__ on the function prototype. Anyway, I see no warnings even without '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks like no-op nowadays. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --ikeVEW9yuYc//A+q Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="isc-unused.diff" --- contrib/bind9/lib/isc/ia64/include/isc/atomic.h.orig 2009-06-01 11:47:44.000000000 +0400 +++ contrib/bind9/lib/isc/ia64/include/isc/atomic.h 2009-06-01 12:01:19.000000000 +0400 @@ -30,11 +30,13 @@ * Open issue: can 'fetchadd' make the code faster for some particular values * (e.g., 1 and -1)? */ -static inline isc_int32_t -isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) #ifdef __GNUC__ -__attribute__ ((unused)) +static inline isc_int32_t +isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) __attribute__ ((unused)); #endif + +static inline isc_int32_t +isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) { isc_int32_t prev, swapped; @@ -56,11 +58,13 @@ /* * This routine atomically stores the value 'val' in 'p'. */ -static inline void -isc_atomic_store(isc_int32_t *p, isc_int32_t val) #ifdef __GNUC__ -__attribute__ ((unused)) +static inline void +isc_atomic_store(isc_int32_t *p, isc_int32_t val) __attribute__ ((unused)); #endif + +static inline void +isc_atomic_store(isc_int32_t *p, isc_int32_t val) { __asm__ volatile( "st4.rel %0=%1" @@ -75,11 +79,14 @@ * original value is equal to 'cmpval'. The original value is returned in any * case. */ +#ifdef __GNUC__ static inline isc_int32_t isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) -#ifdef __GNUC__ -__attribute__ ((unused)) +__attribute__ ((unused)); #endif + +static inline isc_int32_t +isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) { isc_int32_t ret; --ikeVEW9yuYc//A+q-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 09:39:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 789951065673 for ; Mon, 1 Jun 2009 09:39:12 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id BE61E8FC1F for ; Mon, 1 Jun 2009 09:39:11 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 Jun 2009 09:12:29 -0000 Received: from p54A3EC88.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.236.136] by mail.gmx.net (mp027) with SMTP; 01 Jun 2009 11:12:29 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19paHwjQONppJZIVeu+qstlvjQ+d6xVVOO8rFiRD5 brwZIYQ2pXN/tj Message-ID: <4A239B7C.8020403@gmx.de> Date: Mon, 01 Jun 2009 11:12:28 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: current@freebsd.org, Doug Barton , ia64@freebsd.org, FreeBSD Tinderbox Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 09:39:13 -0000 Eygene Ryabinkin schrieb: > This is very weird (judging by the GCC's manual) since the simplest C > program, > ----- > int main(void) > { > return 0; > } > > void foo(void) __attribute__ ((unused)) > { > return; > } > ----- > but ICC 10.x produces the same error and happily chewes __attribute__ > on the function prototype. Anyway, I see no warnings even without > '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks > like no-op nowadays. There is no warning about foo() being unused, because it is not static. Christoph From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 10:22:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D65A1065672; Mon, 1 Jun 2009 10:22:46 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id C31798FC08; Mon, 1 Jun 2009 10:22:45 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 2355C4DA4; Mon, 1 Jun 2009 12:22:45 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51AMgf2029775; Mon, 1 Jun 2009 12:22:42 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243851764; bh=kzmCRWvfb94/zkyASaqtfGaTWbfeEAiTahWg8tdp7M8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=wPp2VxMR/9U7xio2htR/GVS5TiBVykuVFmqc5nsyZ/XiWc4OmwA4MKSAYOOIfM8NH bnnl9sChq5nFbRJDEy5+A== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=V0JcCjvLq+VuWUZa2Xs3c1Wo1XzUkmAqmLlSk9h7uydETElWkl8m42MCb3EwMTPam WwyiJhTfRxw0oKn0eg4LA== Message-ID: <4A23ABF2.3070601@restart.be> Date: Mon, 01 Jun 2009 12:22:42 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 10:22:46 -0000 Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error "can't boot 'kernel'" if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/loader from 8.0-CURRENT. Henri From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 10:44:55 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C8FC106566C for ; Mon, 1 Jun 2009 10:44:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 119C98FC0C for ; Mon, 1 Jun 2009 10:44:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 93EAC46B49 for ; Mon, 1 Jun 2009 06:44:54 -0400 (EDT) Date: Mon, 1 Jun 2009 11:44:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 10:44:55 -0000 As a HEADS up to 8-CURRENT followers: I've replaced the NETISR implementation there as part of on-going work to improve network stack parallelism, details below. In practice, most behavior remains identical in the default configuration (direct dispatch, single netisr thread that's not bound to a CPU, etc), but people will want to watch out for problems. Some default queue limits have been raised. More functional changes to take advantage of these features, such as deferred ethernet dispatch and software flow ID generation, will follow as patches, but probably not ship in 8.0 out of the box. Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Mon, 1 Jun 2009 10:41:38 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r193219 - in head/sys: kern net netatalk netinet netinet6 netipsec netipx netnatm sys Author: rwatson Date: Mon Jun 1 10:41:38 2009 New Revision: 193219 URL: http://svn.freebsd.org/changeset/base/193219 Log: Reimplement the netisr framework in order to support parallel netisr threads: - Support up to one netisr thread per CPU, each processings its own workstream, or set of per-protocol queues. Threads may be bound to specific CPUs, or allowed to migrate, based on a global policy. In the future it would be desirable to support topology-centric policies, such as "one netisr per package". - Allow each protocol to advertise an ordering policy, which can currently be one of: NETISR_POLICY_SOURCE: packets must maintain ordering with respect to an implicit or explicit source (such as an interface or socket). NETISR_POLICY_FLOW: make use of mbuf flow identifiers to place work, as well as allowing protocols to provide a flow generation function for mbufs without flow identifers (m2flow). Falls back on NETISR_POLICY_SOURCE if now flow ID is available. NETISR_POLICY_CPU: allow protocols to inspect and assign a CPU for each packet handled by netisr (m2cpuid). - Provide utility functions for querying the number of workstreams being used, as well as a mapping function from workstream to CPU ID, which protocols may use in work placement decisions. - Add explicit interfaces to get and set per-protocol queue limits, and get and clear drop counters, which query data or apply changes across all workstreams. - Add a more extensible netisr registration interface, in which protocols declare 'struct netisr_handler' structures for each registered NETISR_ type. These include name, handler function, optional mbuf to flow ID function, optional mbuf to CPU ID function, queue limit, and ordering policy. Padding is present to allow these to be expanded in the future. If no queue limit is declared, then a default is used. - Queue limits are now per-workstream, and raised from the previous IFQ_MAXLEN default of 50 to 256. - All protocols are updated to use the new registration interface, and with the exception of netnatm, default queue limits. Most protocols register as NETISR_POLICY_SOURCE, except IPv4 and IPv6, which use NETISR_POLICY_FLOW, and will therefore take advantage of driver- generated flow IDs if present. - Formalize a non-packet based interface between interface polling and the netisr, rather than having polling pretend to be two protocols. Provide two explicit hooks in the netisr worker for start and end events for runs: netisr_poll() and netisr_pollmore(), as well as a function, netisr_sched_poll(), to allow the polling code to schedule netisr execution. DEVICE_POLLING still embeds single-netisr assumptions in its implementation, so for now if it is compiled into the kernel, a single and un-bound netisr thread is enforced regardless of tunable configuration. In the default configuration, the new netisr implementation maintains the same basic assumptions as the previous implementation: a single, un-bound worker thread processes all deferred work, and direct dispatch is enabled by default wherever possible. Performance measurement shows a marginal performance improvement over the old implementation due to the use of batched dequeue. An rmlock is used to synchronize use and registration/unregistration using the framework; currently, synchronized use is disabled (replicating current netisr policy) due to a measurable 3%-6% hit in ping-pong micro-benchmarking. It will be enabled once further rmlock optimization has taken place. However, in practice, netisrs are rarely registered or unregistered at runtime. A new man page for netisr will follow, but since one doesn't currently exist, it hasn't been updated. This change is not appropriate for MFC, although the polling shutdown handler should be merged to 7-STABLE. Bump __FreeBSD_version. Reviewed by: bz Modified: head/sys/kern/kern_poll.c head/sys/net/netisr.c head/sys/net/netisr.h head/sys/net/rtsock.c head/sys/netatalk/ddp_usrreq.c head/sys/netinet/if_ether.c head/sys/netinet/igmp.c head/sys/netinet/ip_divert.c head/sys/netinet/ip_input.c head/sys/netinet6/ip6_input.c head/sys/netinet6/vinet6.h head/sys/netipsec/ipsec_input.c head/sys/netipx/ipx_input.c head/sys/netnatm/natm_proto.c head/sys/sys/param.h head/sys/sys/pcpu.h Modified: head/sys/kern/kern_poll.c ============================================================================== --- head/sys/kern/kern_poll.c Mon Jun 1 10:30:52 2009 (r193218) +++ head/sys/kern/kern_poll.c Mon Jun 1 10:41:38 2009 (r193219) @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include /* needed by net/if.h */ #include @@ -48,8 +49,6 @@ __FBSDID("$FreeBSD$"); #include #include -static void netisr_poll(void); /* the two netisr handlers */ -static void netisr_pollmore(void); static int poll_switch(SYSCTL_HANDLER_ARGS); void hardclock_device_poll(void); /* hook from hardclock */ @@ -110,6 +109,10 @@ SYSCTL_NODE(_kern, OID_AUTO, polling, CT SYSCTL_UINT(_kern_polling, OID_AUTO, burst, CTLFLAG_RD, &poll_burst, 0, "Current polling burst size"); +static int netisr_poll_scheduled; +static int netisr_pollmore_scheduled; +static int poll_shutting_down; + static int poll_burst_max_sysctl(SYSCTL_HANDLER_ARGS) { uint32_t val = poll_burst_max; @@ -260,12 +263,19 @@ struct pollrec { static struct pollrec pr[POLL_LIST_LEN]; static void +poll_shutdown(void *arg, int howto) +{ + + poll_shutting_down = 1; +} + +static void init_device_poll(void) { mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); - netisr_register(NETISR_POLL, (netisr_t *)netisr_poll, NULL, 0); - netisr_register(NETISR_POLLMORE, (netisr_t *)netisr_pollmore, NULL, 0); + EVENTHANDLER_REGISTER(shutdown_post_sync, poll_shutdown, NULL, + SHUTDOWN_PRI_LAST); } SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, NULL); @@ -289,7 +299,7 @@ hardclock_device_poll(void) static struct timeval prev_t, t; int delta; - if (poll_handlers == 0) + if (poll_handlers == 0 || poll_shutting_down) return; microuptime(&t); @@ -314,7 +324,9 @@ hardclock_device_poll(void) if (phase != 0) suspect++; phase = 1; - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); phase = 2; } if (pending_polls++ > 0) @@ -365,9 +377,16 @@ netisr_pollmore() int kern_load; mtx_lock(&poll_mtx); + if (!netisr_pollmore_scheduled) { + mtx_unlock(&poll_mtx); + return; + } + netisr_pollmore_scheduled = 0; phase = 5; if (residual_burst > 0) { - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); mtx_unlock(&poll_mtx); /* will run immediately on return, followed by netisrs */ return; @@ -397,23 +416,29 @@ netisr_pollmore() poll_burst -= (poll_burst / 8); if (poll_burst < 1) poll_burst = 1; - schednetisrbits(1 << NETISR_POLL | 1 << NETISR_POLLMORE); + netisr_poll_scheduled = 1; + netisr_pollmore_scheduled = 1; + netisr_sched_poll(); phase = 6; } mtx_unlock(&poll_mtx); } /* - * netisr_poll is scheduled by schednetisr when appropriate, typically once - * per tick. + * netisr_poll is typically scheduled once per tick. */ -static void +void netisr_poll(void) { int i, cycles; enum poll_cmd arg = POLL_ONLY; mtx_lock(&poll_mtx); + if (!netisr_poll_scheduled) { + mtx_unlock(&poll_mtx); + return; + } + netisr_poll_scheduled = 0; phase = 3; if (residual_burst == 0) { /* first call in this tick */ microuptime(&poll_start_t); Modified: head/sys/net/netisr.c ============================================================================== --- head/sys/net/netisr.c Mon Jun 1 10:30:52 2009 (r193218) +++ head/sys/net/netisr.c Mon Jun 1 10:41:38 2009 (r193219) @@ -1,6 +1,5 @@ /*- - * Copyright (c) 2001,2002,2003 Jonathan Lemon - * Copyright (c) 1997, Stefan Esser + * Copyright (c) 2007-2009 Robert N. M. Watson * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -23,230 +22,1103 @@ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * netisr is a packet dispatch service, allowing synchronous (directly + * dispatched) and asynchronous (deferred dispatch) processing of packets by + * registered protocol handlers. Callers pass a protocol identifier and + * packet to netisr, along with a direct dispatch hint, and work will either + * be immediately processed with the registered handler, or passed to a + * kernel software interrupt (SWI) thread for deferred dispatch. Callers + * will generally select one or the other based on: + * + * - Might directly dispatching a netisr handler lead to code reentrance or + * lock recursion, such as entering the socket code from the socket code. + * - Might directly dispatching a netisr handler lead to recursive + * processing, such as when decapsulating several wrapped layers of tunnel + * information (IPSEC within IPSEC within ...). * - * $FreeBSD$ + * Maintaining ordering for protocol streams is a critical design concern. + * Enforcing ordering limits the opportunity for concurrency, but maintains + * the strong ordering requirements found in some protocols, such as TCP. Of + * related concern is CPU affinity--it is desirable to process all data + * associated with a particular stream on the same CPU over time in order to + * avoid acquiring locks associated with the connection on different CPUs, + * keep connection data in one cache, and to generally encourage associated + * user threads to live on the same CPU as the stream. It's also desirable + * to avoid lock migration and contention where locks are associated with + * more than one flow. + * + * netisr supports several policy variations, represented by the + * NETISR_POLICY_* constants, allowing protocols to play a varying role in + * identifying flows, assigning work to CPUs, etc. These are described in + * detail in netisr.h. */ +#include "opt_ddb.h" #include "opt_device_polling.h" #include #include -#include -#include -#include #include #include +#include #include -#include +#include +#include #include -#include -#include +#include +#include +#include +#include #include -#include +#include #include -#include -#include -#include -#include -#include +#ifdef DDB +#include +#endif #include -#include #include #include -volatile unsigned int netisr; /* scheduling bits for network */ +/*- + * Synchronize use and modification of the registered netisr data structures; + * acquire a read lock while modifying the set of registered protocols to + * prevent partially registered or unregistered protocols from being run. + * + * The following data structures and fields are protected by this lock: + * + * - The np array, including all fields of struct netisr_proto. + * - The nws array, including all fields of struct netisr_worker. + * - The nws_array array. + * + * Note: the NETISR_LOCKING define controls whether read locks are acquired + * in packet processing paths requiring netisr registration stability. This + * is disabled by default as it can lead to a measurable performance + * degradation even with rmlocks (3%-6% for loopback ping-pong traffic), and + * because netisr registration and unregistration is extremely rare at + * runtime. If it becomes more common, this decision should be revisited. + * + * XXXRW: rmlocks don't support assertions. + */ +static struct rmlock netisr_rmlock; +#define NETISR_LOCK_INIT() rm_init_flags(&netisr_rmlock, "netisr", \ + RM_NOWITNESS) +#define NETISR_LOCK_ASSERT() +#define NETISR_RLOCK(tracker) rm_rlock(&netisr_rmlock, (tracker)) +#define NETISR_RUNLOCK(tracker) rm_runlock(&netisr_rmlock, (tracker)) +#define NETISR_WLOCK() rm_wlock(&netisr_rmlock) +#define NETISR_WUNLOCK() rm_wunlock(&netisr_rmlock) +/* #define NETISR_LOCKING */ + +SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr"); + +/*- + * Three direct dispatch policies are supported: + * + * - Always defer: all work is scheduled for a netisr, regardless of context. + * (!direct) + * + * - Hybrid: if the executing context allows direct dispatch, and we're + * running on the CPU the work would be done on, then direct dispatch if it + * wouldn't violate ordering constraints on the workstream. + * (direct && !direct_force) + * + * - Always direct: if the executing context allows direct dispatch, always + * direct dispatch. (direct && direct_force) + * + * Notice that changing the global policy could lead to short periods of + * misordered processing, but this is considered acceptable as compared to + * the complexity of enforcing ordering during policy changes. + */ +static int netisr_direct_force = 1; /* Always direct dispatch. */ +TUNABLE_INT("net.isr.direct_force", &netisr_direct_force); +SYSCTL_INT(_net_isr, OID_AUTO, direct_force, CTLFLAG_RW, + &netisr_direct_force, 0, "Force direct dispatch"); + +static int netisr_direct = 1; /* Enable direct dispatch. */ +TUNABLE_INT("net.isr.direct", &netisr_direct); +SYSCTL_INT(_net_isr, OID_AUTO, direct, CTLFLAG_RW, + &netisr_direct, 0, "Enable direct dispatch"); + +/* + * Allow the administrator to limit the number of threads (CPUs) to use for + * netisr. We don't check netisr_maxthreads before creating the thread for + * CPU 0, so in practice we ignore values <= 1. This must be set at boot. + * We will create at most one thread per CPU. + */ +static int netisr_maxthreads = 1; /* Max number of threads. */ +TUNABLE_INT("net.isr.maxthreads", &netisr_maxthreads); +SYSCTL_INT(_net_isr, OID_AUTO, maxthreads, CTLFLAG_RD, + &netisr_maxthreads, 0, + "Use at most this many CPUs for netisr processing"); + +static int netisr_bindthreads = 0; /* Bind threads to CPUs. */ +TUNABLE_INT("net.isr.bindthreads", &netisr_bindthreads); +SYSCTL_INT(_net_isr, OID_AUTO, bindthreads, CTLFLAG_RD, + &netisr_bindthreads, 0, "Bind netisr threads to CPUs."); + +/* + * Limit per-workstream queues to at most net.isr.maxqlimit, both for initial + * configuration and later modification using netisr_setqlimit(). + */ +#define NETISR_DEFAULT_MAXQLIMIT 10240 +static u_int netisr_maxqlimit = NETISR_DEFAULT_MAXQLIMIT; +TUNABLE_INT("net.isr.maxqlimit", &netisr_maxqlimit); +SYSCTL_INT(_net_isr, OID_AUTO, maxqlimit, CTLFLAG_RD, + &netisr_maxqlimit, 0, + "Maximum netisr per-protocol, per-CPU queue depth."); + +/* + * The default per-workstream queue limit for protocols that don't initialize + * the nh_qlimit field of their struct netisr_handler. If this is set above + * netisr_maxqlimit, we truncate it to the maximum during boot. + */ +#define NETISR_DEFAULT_DEFAULTQLIMIT 256 +static u_int netisr_defaultqlimit = NETISR_DEFAULT_DEFAULTQLIMIT; +TUNABLE_INT("net.isr.defaultqlimit", &netisr_defaultqlimit); +SYSCTL_INT(_net_isr, OID_AUTO, defaultqlimit, CTLFLAG_RD, + &netisr_defaultqlimit, 0, + "Default netisr per-protocol, per-CPU queue limit if not set by protocol"); + +/* + * Each protocol is described by a struct netisr_proto, which holds all + * global per-protocol information. This data structure is set up by + * netisr_register(), and derived from the public struct netisr_handler. + */ +struct netisr_proto { + const char *np_name; /* Character string protocol name. */ + netisr_handler_t *np_handler; /* Protocol handler. */ + netisr_m2flow_t *np_m2flow; /* Query flow for untagged packet. */ + netisr_m2cpuid_t *np_m2cpuid; /* Query CPU to process packet on. */ + u_int np_qlimit; /* Maximum per-CPU queue depth. */ + u_int np_policy; /* Work placement policy. */ +}; + +#define NETISR_MAXPROT 32 /* Compile-time limit. */ + +/* + * The np array describes all registered protocols, indexed by protocol + * number. + */ +static struct netisr_proto np[NETISR_MAXPROT]; + +/* + * Protocol-specific work for each workstream is described by struct + * netisr_work. Each work descriptor consists of an mbuf queue and + * statistics. + */ +struct netisr_work { + /* + * Packet queue, linked by m_nextpkt. + */ + struct mbuf *nw_head; + struct mbuf *nw_tail; + u_int nw_len; + u_int nw_qlimit; + u_int nw_watermark; + + /* + * Statistics -- written unlocked, but mostly from curcpu. + */ + u_int64_t nw_dispatched; /* Number of direct dispatches. */ + u_int64_t nw_hybrid_dispatched; /* "" hybrid dispatches. */ + u_int64_t nw_qdrops; /* "" drops. */ + u_int64_t nw_queued; /* "" enqueues. */ + u_int64_t nw_handled; /* "" handled in worker. */ +}; + +/* + * Workstreams hold a set of ordered work across each protocol, and are + * described by netisr_workstream. Each workstream is associated with a + * worker thread, which in turn is pinned to a CPU. Work associated with a + * workstream can be processd in other threads during direct dispatch; + * concurrent processing is prevented by the NWS_RUNNING flag, which + * indicates that a thread is already processing the work queue. + */ +struct netisr_workstream { + struct intr_event *nws_intr_event; /* Handler for stream. */ + void *nws_swi_cookie; /* swi(9) cookie for stream. */ + struct mtx nws_mtx; /* Synchronize work. */ + u_int nws_cpu; /* CPU pinning. */ + u_int nws_flags; /* Wakeup flags. */ + u_int nws_pendingbits; /* Scheduled protocols. */ + + /* + * Each protocol has per-workstream data. + */ + struct netisr_work nws_work[NETISR_MAXPROT]; +} __aligned(CACHE_LINE_SIZE); + +/* + * Per-CPU workstream data, indexed by CPU ID. + */ +static struct netisr_workstream nws[MAXCPU]; + +/* + * Map contiguous values between 0 and nws_count into CPU IDs appropriate for + * indexing the nws[] array. This allows constructions of the form + * nws[nws_array(arbitraryvalue % nws_count)]. + */ +static u_int nws_array[MAXCPU]; + +/* + * Number of registered workstreams. Will be at most the number of running + * CPUs once fully started. + */ +static u_int nws_count; +SYSCTL_INT(_net_isr, OID_AUTO, numthreads, CTLFLAG_RD, + &nws_count, 0, "Number of extant netisr threads."); + +/* + * Per-workstream flags. + */ +#define NWS_RUNNING 0x00000001 /* Currently running in a thread. */ +#define NWS_DISPATCHING 0x00000002 /* Currently being direct-dispatched. */ +#define NWS_SCHEDULED 0x00000004 /* Signal issued. */ + +/* + * Synchronization for each workstream: a mutex protects all mutable fields + * in each stream, including per-protocol state (mbuf queues). The SWI is + * woken up if asynchronous dispatch is required. + */ +#define NWS_LOCK(s) mtx_lock(&(s)->nws_mtx) +#define NWS_LOCK_ASSERT(s) mtx_assert(&(s)->nws_mtx, MA_OWNED) +#define NWS_UNLOCK(s) mtx_unlock(&(s)->nws_mtx) +#define NWS_SIGNAL(s) swi_sched((s)->nws_swi_cookie, 0) -struct netisr { - netisr_t *ni_handler; - struct ifqueue *ni_queue; - int ni_flags; -} netisrs[32]; +/* + * Utility routines for protocols that implement their own mapping of flows + * to CPUs. + */ +u_int +netisr_get_cpucount(void) +{ + + return (nws_count); +} -static void *net_ih; +u_int +netisr_get_cpuid(u_int cpunumber) +{ + + KASSERT(cpunumber < nws_count, ("%s: %u > %u", __func__, cpunumber, + nws_count)); + + return (nws_array[cpunumber]); +} + +/* + * The default implementation of -> CPU ID mapping. + * + * Non-static so that protocols can use it to map their own work to specific + * CPUs in a manner consistent to netisr for affinity purposes. + */ +u_int +netisr_default_flow2cpu(u_int flowid) +{ + return (nws_array[flowid % nws_count]); +} + +/* + * Register a new netisr handler, which requires initializing per-protocol + * fields for each workstream. All netisr work is briefly suspended while + * the protocol is installed. + */ void -legacy_setsoftnet(void) +netisr_register(const struct netisr_handler *nhp) { - swi_sched(net_ih, 0); + struct netisr_work *npwp; + const char *name; + u_int i, proto; + + proto = nhp->nh_proto; + name = nhp->nh_name; + + /* + * Test that the requested registration is valid. + */ + KASSERT(nhp->nh_name != NULL, + ("%s: nh_name NULL for %u", __func__, proto)); + KASSERT(nhp->nh_handler != NULL, + ("%s: nh_handler NULL for %s", __func__, name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_SOURCE || + nhp->nh_policy == NETISR_POLICY_FLOW || + nhp->nh_policy == NETISR_POLICY_CPU, + ("%s: unsupported nh_policy %u for %s", __func__, + nhp->nh_policy, name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_FLOW || + nhp->nh_m2flow == NULL, + ("%s: nh_policy != FLOW but m2flow defined for %s", __func__, + name)); + KASSERT(nhp->nh_policy == NETISR_POLICY_CPU || nhp->nh_m2cpuid == NULL, + ("%s: nh_policy != CPU but m2cpuid defined for %s", __func__, + name)); + KASSERT(nhp->nh_policy != NETISR_POLICY_CPU || nhp->nh_m2cpuid != NULL, + ("%s: nh_policy == CPU but m2cpuid not defined for %s", __func__, + name)); + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u, %s): protocol too big", __func__, proto, name)); + + /* + * Test that no existing registration exists for this protocol. + */ + NETISR_WLOCK(); + KASSERT(np[proto].np_name == NULL, + ("%s(%u, %s): name present", __func__, proto, name)); + KASSERT(np[proto].np_handler == NULL, + ("%s(%u, %s): handler present", __func__, proto, name)); + + np[proto].np_name = name; + np[proto].np_handler = nhp->nh_handler; + np[proto].np_m2flow = nhp->nh_m2flow; + np[proto].np_m2cpuid = nhp->nh_m2cpuid; + if (nhp->nh_qlimit == 0) + np[proto].np_qlimit = netisr_defaultqlimit; + else if (nhp->nh_qlimit > netisr_maxqlimit) { + printf("%s: %s requested queue limit %u capped to " + "net.isr.maxqlimit %u\n", __func__, name, nhp->nh_qlimit, + netisr_maxqlimit); + np[proto].np_qlimit = netisr_maxqlimit; + } else + np[proto].np_qlimit = nhp->nh_qlimit; + np[proto].np_policy = nhp->nh_policy; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + bzero(npwp, sizeof(*npwp)); + npwp->nw_qlimit = np[proto].np_qlimit; + } + NETISR_WUNLOCK(); } +/* + * Clear drop counters across all workstreams for a protocol. + */ void -netisr_register(int num, netisr_t *handler, struct ifqueue *inq, int flags) +netisr_clearqdrops(const struct netisr_handler *nhp) { - - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - KASSERT(flags == 0, ("netisr_register: bad flags 0x%x\n", flags)); - netisrs[num].ni_handler = handler; - netisrs[num].ni_queue = inq; - netisrs[num].ni_flags = flags; + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + npwp->nw_qdrops = 0; + } + NETISR_WUNLOCK(); } +/* + * Query the current drop counters across all workstreams for a protocol. + */ void -netisr_unregister(int num) +netisr_getqdrops(const struct netisr_handler *nhp, u_int64_t *qdropp) { - struct netisr *ni; - - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - ni = &netisrs[num]; - ni->ni_handler = NULL; - if (ni->ni_queue != NULL) - IF_DRAIN(ni->ni_queue); - ni->ni_queue = NULL; + struct netisr_work *npwp; + struct rm_priotracker tracker; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + *qdropp = 0; + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_RLOCK(&tracker); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + *qdropp += npwp->nw_qdrops; + } + NETISR_RUNLOCK(&tracker); } -struct isrstat { - int isrs_count; /* dispatch count */ - int isrs_directed; /* ...directly dispatched */ - int isrs_deferred; /* ...queued instead */ - int isrs_queued; /* intentionally queueued */ - int isrs_drop; /* dropped 'cuz no handler */ - int isrs_swi_count; /* swi_net handlers called */ -}; -static struct isrstat isrstat; +/* + * Query the current queue limit for per-workstream queues for a protocol. + */ +void +netisr_getqlimit(const struct netisr_handler *nhp, u_int *qlimitp) +{ + struct rm_priotracker tracker; +#ifdef INVARIANTS + const char *name; +#endif + u_int proto; -SYSCTL_NODE(_net, OID_AUTO, isr, CTLFLAG_RW, 0, "netisr counters"); + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); -static int netisr_direct = 1; -SYSCTL_INT(_net_isr, OID_AUTO, direct, CTLFLAG_RW, - &netisr_direct, 0, "enable direct dispatch"); -TUNABLE_INT("net.isr.direct", &netisr_direct); + NETISR_RLOCK(&tracker); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + *qlimitp = np[proto].np_qlimit; + NETISR_RUNLOCK(&tracker); +} + +/* + * Update the queue limit across per-workstream queues for a protocol. We + * simply change the limits, and don't drain overflowed packets as they will + * (hopefully) take care of themselves shortly. + */ +int +netisr_setqlimit(const struct netisr_handler *nhp, u_int qlimit) +{ + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + if (qlimit > netisr_maxqlimit) + return (EINVAL); + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + np[proto].np_qlimit = qlimit; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + npwp->nw_qlimit = qlimit; + } + NETISR_WUNLOCK(); + return (0); +} -SYSCTL_INT(_net_isr, OID_AUTO, count, CTLFLAG_RD, - &isrstat.isrs_count, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, directed, CTLFLAG_RD, - &isrstat.isrs_directed, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, deferred, CTLFLAG_RD, - &isrstat.isrs_deferred, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, queued, CTLFLAG_RD, - &isrstat.isrs_queued, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, drop, CTLFLAG_RD, - &isrstat.isrs_drop, 0, ""); -SYSCTL_INT(_net_isr, OID_AUTO, swi_count, CTLFLAG_RD, - &isrstat.isrs_swi_count, 0, ""); - -/* - * Process all packets currently present in a netisr queue. Used to - * drain an existing set of packets waiting for processing when we - * begin direct dispatch, to avoid processing packets out of order. +/* + * Drain all packets currently held in a particular protocol work queue. */ static void -netisr_processqueue(struct netisr *ni) +netisr_drain_proto(struct netisr_work *npwp) { struct mbuf *m; - for (;;) { - IF_DEQUEUE(ni->ni_queue, m); - if (m == NULL) - break; - VNET_ASSERT(m->m_pkthdr.rcvif != NULL); - CURVNET_SET(m->m_pkthdr.rcvif->if_vnet); - ni->ni_handler(m); - CURVNET_RESTORE(); + /* + * We would assert the lock on the workstream but it's not passed in. + */ + while ((m = npwp->nw_head) != NULL) { + npwp->nw_head = m->m_nextpkt; + m->m_nextpkt = NULL; + if (npwp->nw_head == NULL) + npwp->nw_tail = NULL; + npwp->nw_len--; + m_freem(m); } + KASSERT(npwp->nw_tail == NULL, ("%s: tail", __func__)); + KASSERT(npwp->nw_len == 0, ("%s: len", __func__)); } /* - * Call the netisr directly instead of queueing the packet, if possible. + * Remove the registration of a network protocol, which requires clearing + * per-protocol fields across all workstreams, including freeing all mbufs in + * the queues at time of unregister. All work in netisr is briefly suspended + * while this takes place. */ void -netisr_dispatch(int num, struct mbuf *m) +netisr_unregister(const struct netisr_handler *nhp) { - struct netisr *ni; - - isrstat.isrs_count++; /* XXX redundant */ - KASSERT(!(num < 0 || num >= (sizeof(netisrs)/sizeof(*netisrs))), - ("bad isr %d", num)); - ni = &netisrs[num]; - if (ni->ni_queue == NULL) { - isrstat.isrs_drop++; - m_freem(m); - return; + struct netisr_work *npwp; +#ifdef INVARIANTS + const char *name; +#endif + u_int i, proto; + + proto = nhp->nh_proto; +#ifdef INVARIANTS + name = nhp->nh_name; +#endif + KASSERT(proto < NETISR_MAXPROT, + ("%s(%u): protocol too big for %s", __func__, proto, name)); + + NETISR_WLOCK(); + KASSERT(np[proto].np_handler != NULL, + ("%s(%u): protocol not registered for %s", __func__, proto, + name)); + + np[proto].np_name = NULL; + np[proto].np_handler = NULL; + np[proto].np_m2flow = NULL; + np[proto].np_m2cpuid = NULL; + np[proto].np_qlimit = 0; + np[proto].np_policy = 0; + for (i = 0; i < MAXCPU; i++) { + npwp = &nws[i].nws_work[proto]; + netisr_drain_proto(npwp); + bzero(npwp, sizeof(*npwp)); } + NETISR_WUNLOCK(); +} + +/* + * Look up the workstream given a packet and source identifier. Do this by + * checking the protocol's policy, and optionally call out to the protocol + * for assistance if required. + */ +static struct mbuf * +netisr_select_cpuid(struct netisr_proto *npp, uintptr_t source, + struct mbuf *m, u_int *cpuidp) +{ + struct ifnet *ifp; + + NETISR_LOCK_ASSERT(); /* - * Directly dispatch handling of this packet, if permitted by global - * policy. Source ordering is maintained by virtue of callers - * consistently calling one of queued or direct dispatch. + * In the event we have only one worker, shortcut and deliver to it + * without further ado. */ - if (netisr_direct) { - isrstat.isrs_directed++; - ni->ni_handler(m); + if (nws_count == 1) { + *cpuidp = nws_array[0]; + return (m); + } + + /* + * What happens next depends on the policy selected by the protocol. + * If we want to support per-interface policies, we should do that + * here first. + */ + switch (npp->np_policy) { + case NETISR_POLICY_CPU: + return (npp->np_m2cpuid(m, source, cpuidp)); + + case NETISR_POLICY_FLOW: + if (!(m->m_flags & M_FLOWID) && npp->np_m2flow != NULL) { + m = npp->np_m2flow(m, source); + if (m == NULL) + return (NULL); + } + if (m->m_flags & M_FLOWID) { + *cpuidp = + netisr_default_flow2cpu(m->m_pkthdr.flowid); + return (m); + } + /* FALLTHROUGH */ + + case NETISR_POLICY_SOURCE: + ifp = m->m_pkthdr.rcvif; + if (ifp != NULL) + *cpuidp = nws_array[(ifp->if_index + source) % + nws_count]; + else + *cpuidp = nws_array[source % nws_count]; + return (m); + + default: + panic("%s: invalid policy %u for %s", __func__, + npp->np_policy, npp->np_name); + } +} + +/* + * Process packets associated with a workstream and protocol. For reasons of + * fairness, we process up to one complete netisr queue at a time, moving the + * queue to a stack-local queue for processing, but do not loop refreshing + * from the global queue. The caller is responsible for deciding whether to + * loop, and for setting the NWS_RUNNING flag. The passed workstream will be + * locked on entry and relocked before return, but will be released while + * processing. The number of packets processed is returned. + */ +static u_int +netisr_process_workstream_proto(struct netisr_workstream *nwsp, u_int proto) +{ + struct netisr_work local_npw, *npwp; + u_int handled; + struct mbuf *m; + + NETISR_LOCK_ASSERT(); + NWS_LOCK_ASSERT(nwsp); + + KASSERT(nwsp->nws_flags & NWS_RUNNING, + ("%s(%u): not running", __func__, proto)); + KASSERT(proto >= 0 && proto < NETISR_MAXPROT, + ("%s(%u): invalid proto\n", __func__, proto)); + + npwp = &nwsp->nws_work[proto]; + if (npwp->nw_len == 0) + return (0); + + /* + * Move the global work queue to a thread-local work queue. + * + * Notice that this means the effective maximum length of the queue + * is actually twice that of the maximum queue length specified in + * the protocol registration call. + */ + handled = npwp->nw_len; + local_npw = *npwp; + npwp->nw_head = NULL; + npwp->nw_tail = NULL; + npwp->nw_len = 0; + nwsp->nws_pendingbits &= ~(1 << proto); + NWS_UNLOCK(nwsp); + while ((m = local_npw.nw_head) != NULL) { + local_npw.nw_head = m->m_nextpkt; + m->m_nextpkt = NULL; + if (local_npw.nw_head == NULL) + local_npw.nw_tail = NULL; + local_npw.nw_len--; + VNET_ASSERT(m->m_pkthdr.rcvif != NULL); + CURVNET_SET(m->m_pkthdr.rcvif->if_vnet); + np[proto].np_handler(m); + CURVNET_RESTORE(); + } + KASSERT(local_npw.nw_len == 0, + ("%s(%u): len %u", __func__, proto, local_npw.nw_len)); + NWS_LOCK(nwsp); + npwp->nw_handled += handled; + return (handled); +} + +/* + * SWI handler for netisr -- processes prackets in a set of workstreams that + * it owns, woken up by calls to NWS_SIGNAL(). If this workstream is already + * being direct dispatched, go back to sleep and wait for the dispatching + * thread to wake us up again. + */ +static void +swi_net(void *arg) +{ +#ifdef NETISR_LOCKING + struct rm_priotracker tracker; +#endif + struct netisr_workstream *nwsp; + u_int bits, prot; + + nwsp = arg; + +#ifdef DEVICE_POLLING + KASSERT(nws_count == 1, + ("%s: device_polling but nws_count != 1", __func__)); + netisr_poll(); +#endif +#ifdef NETISR_LOCKING + NETISR_RLOCK(&tracker); +#endif + NWS_LOCK(nwsp); + KASSERT(!(nwsp->nws_flags & NWS_RUNNING), ("swi_net: running")); + if (nwsp->nws_flags & NWS_DISPATCHING) + goto out; + nwsp->nws_flags |= NWS_RUNNING; + nwsp->nws_flags &= ~NWS_SCHEDULED; + while ((bits = nwsp->nws_pendingbits) != 0) { + while ((prot = ffs(bits)) != 0) { + prot--; + bits &= ~(1 << prot); + (void)netisr_process_workstream_proto(nwsp, prot); + } + } + nwsp->nws_flags &= ~NWS_RUNNING; +out: + NWS_UNLOCK(nwsp); +#ifdef NETISR_LOCKING + NETISR_RUNLOCK(&tracker); +#endif +#ifdef DEVICE_POLLING + netisr_pollmore(); +#endif +} + +static int +netisr_queue_workstream(struct netisr_workstream *nwsp, u_int proto, + struct netisr_work *npwp, struct mbuf *m, int *dosignalp) +{ + + NWS_LOCK_ASSERT(nwsp); + + *dosignalp = 0; + if (npwp->nw_len < npwp->nw_qlimit) { + m->m_nextpkt = NULL; + if (npwp->nw_head == NULL) { + npwp->nw_head = m; + npwp->nw_tail = m; + } else { + npwp->nw_tail->m_nextpkt = m; + npwp->nw_tail = m; + } + npwp->nw_len++; + if (npwp->nw_len > npwp->nw_watermark) + npwp->nw_watermark = npwp->nw_len; + nwsp->nws_pendingbits |= (1 << proto); + if (!(nwsp->nws_flags & + (NWS_RUNNING | NWS_DISPATCHING | NWS_SCHEDULED))) { + nwsp->nws_flags |= NWS_SCHEDULED; + *dosignalp = 1; /* Defer until unlocked. */ + } *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 11:06:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A721065672; Mon, 1 Jun 2009 11:06:15 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id AE0298FC08; Mon, 1 Jun 2009 11:06:14 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=QPfSHCiBtT33HhK9b9MXWplYCU+5vHAgrSB4a3JD8BZP4q103qdXhaNUwIEkpzt9X0b6xClLynUf8XprCJ5bkPtJcsTT8ppb8qc43nDyLyVzEHua9vkRYKKYJRaYAPmGp74btKLZpWVFRLqfqtDyLawXgzC5CRfoHAs2oPL7bUk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MB5LJ-000HzH-KU; Mon, 01 Jun 2009 15:06:13 +0400 Date: Mon, 1 Jun 2009 15:06:10 +0400 From: Eygene Ryabinkin To: Christoph Mallon Message-ID: References: <20090601042258.909C77302F@freebsd-current.sentex.ca> <4A2360BC.8040109@FreeBSD.org> <4A239B7C.8020403@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A239B7C.8020403@gmx.de> Sender: rea-fbsd@codelabs.ru Cc: FreeBSD Tinderbox , Doug Barton , current@freebsd.org, ia64@freebsd.org Subject: Re: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 11:06:15 -0000 Christoph, good day. Mon, Jun 01, 2009 at 11:12:28AM +0200, Christoph Mallon wrote: > Eygene Ryabinkin schrieb: > > This is very weird (judging by the GCC's manual) since the simplest C > > program, > > ----- > > int main(void) > > { > > return 0; > > } > > > > void foo(void) __attribute__ ((unused)) > > { > > return; > > } > > ----- > > but ICC 10.x produces the same error and happily chewes __attribute__ > > on the function prototype. Anyway, I see no warnings even without > > '((unused)) attribute with -Wall, so '__attribute__ ((unused))' looks > > like no-op nowadays. > > There is no warning about foo() being unused, because it is not static. Yes, you're perfectly right. Thanks for education! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 08:13:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68FA6106566B; Mon, 1 Jun 2009 08:13:08 +0000 (UTC) (envelope-from ohartman@mail.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 E7B8F8FC20; Mon, 1 Jun 2009 08:13:07 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MB2dm-00023H-Vk>; Mon, 01 Jun 2009 10:13:07 +0200 Received: from e178015162.adsl.alicedsl.de ([85.178.15.162] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MB2dm-0002CZ-Sx>; Mon, 01 Jun 2009 10:13:06 +0200 Message-ID: <4A238D95.9020209@mail.zedat.fu-berlin.de> Date: Mon, 01 Jun 2009 10:13:09 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: Attilio Rao References: <4A2120D5.50300@mail.zedat.fu-berlin.de> <3bbf2fe10905300848s6342a7b1l32340baee8e7e8f1@mail.gmail.com> <4A215D7F.7020807@mail.zedat.fu-berlin.de> <3bbf2fe10905300944r96ae931re4475c78d9be3aa8@mail.gmail.com> <3bbf2fe10905300951o3beea201j72b6e6b96f85c05a@mail.gmail.com> In-Reply-To: <3bbf2fe10905300951o3beea201j72b6e6b96f85c05a@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.15.162 X-Mailman-Approved-At: Mon, 01 Jun 2009 11:23:23 +0000 Cc: freebsd-current@freebsd.org Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 08:13:08 -0000 Attilio Rao wrote: > 2009/5/30 Attilio Rao : > >> 2009/5/30 O. Hartmann : >> >>> Attilio Rao wrote: >>> >>>> 2009/5/30 O. Hartmann : >>>> >>>> >>>>> Hello. >>>>> I realized a significant slowdown of FreeBSD 8.0-CURRENT/amd64 on every >>>>> box I run. I have the most recent FreeBSD 8.0-CURRENT/amd64 with custom >>>>> kernel and switched off every debugging. I see a drastic slowdown >>>>> whenever heavy I/O on UFS2 and ZFS partitions is performed and whenever >>>>> some compilation is done (compiling world and kernel). This is horrible >>>>> on a single core Athlon64 CPU with 2GB RAM as well as on a 4 core Q6600 >>>>> with 8GB and a server with 2 x 4-cores and 16GB RAM. >>>>> >>>>> I can not say clearly whether I/O is the bottleneck. Maybe something >>>>> with the memory subsystem, when it comes to compiler runs, when no disk >>>>> I/O is done but the box is still horrible slow. This behaviour occured >>>>> several weeks ago, not being able to specify it more precisely. >>>>> >>>>> AQre there any issues at the moment? >>>>> >>>>> >>>> Your kernel is compiled from which date? >>>> >>>> Thanks, >>>> Attilio >>>> >>>> >>>> >>>> >>> Most recent, say: yesterday! As well as world. >>> >> Can you try to revert only r193011 and see if something changes? >> > > Also, did you compile the single-core athlon64 without the option SMP? > > Thanks, > Attilio > > > Yes, I did of course compile kernel on UP without option SMP and of those with more than on logical core with SMP on. I will try to revert to r193011. Oliver From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 08:30:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC6571065678; Mon, 1 Jun 2009 08:30:22 +0000 (UTC) (envelope-from ohartman@mail.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 47F358FC21; Mon, 1 Jun 2009 08:30:22 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MB2uT-0004Og-BY>; Mon, 01 Jun 2009 10:30:21 +0200 Received: from e178015162.adsl.alicedsl.de ([85.178.15.162] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MB2uT-0002ra-8e>; Mon, 01 Jun 2009 10:30:21 +0200 Message-ID: <4A23919F.8050905@mail.zedat.fu-berlin.de> Date: Mon, 01 Jun 2009 10:30:23 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: Kip Macy References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> In-Reply-To: <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.15.162 X-Mailman-Approved-At: Mon, 01 Jun 2009 11:23:39 +0000 Cc: attilio@freebsd.org, bf , freebsd-current@freebsd.org Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 08:30:23 -0000 Kip Macy wrote: >> I'm running the r193133 amd64 with a custom kernel and all debugging off >> on an AMD Athlon64 3400+ single-core, and I haven't noticed any significant >> slowing, although I haven't been doing any systematic benchmarking. >> >> What would be the penalties of running an SMP -CURRENT kernel on >> single-core hardware with no hyperthreading? Can anyone quantify the >> typical added overhead? Or, counterintuitively, would an SMP kernel >> be better in some ways? >> >> > > He is trying to diagnose if the problem was introduced by enabling > adaptive spinning on sx locks. They're only enabled on SMP kernels. > > Cheers, > Kip > Well, no SMP on UP AMD CPUs without SMT means no usage of the sx locks. As far as I know, the sx locks were introduced a couple of days ago, weren't they? To avoid any kind of misunderstanding, there is no permanent 'slowdown', it occurs especially whenever the system's compiler builds world or a kernel or heavy I/O activities occur. It seems my boxes, especially the UP box, is freezing, no reaction on X11. Well, first time I thought it is related to UP, low memory or especially new drm code used with X11 for acceleration, but I also realized those 'slowdown-incidents' on boxes with multicores, 8 or more GB of RAM and no X11 installed and running. This performance impact in situations whenever building a world is significant. We did not change the compiler, it is still the old gcc 4.2, so I do not expect an impact from new high-memory and cpu-consuming optimization routines. I do not even benchmark my boxes day for day, but I usually do a set of the same work on those boxes used for scientific work, so while building world even on SMP boxes and working after installation with the same software set reveals some weirdness in some points. I thought this is due some use-uninterruptable debugging switches, some wrote the malloc code is about to change and so on so I was wondering if there is something temporarely going on at the moment where some hints could prevent me from building a world within this testing phase. Just speculation. Greetings, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 08:36:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1F7A1065675; Mon, 1 Jun 2009 08:36:50 +0000 (UTC) (envelope-from ohartman@mail.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 AB6F48FC21; Mon, 1 Jun 2009 08:36:50 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MB30j-0005JL-OC>; Mon, 01 Jun 2009 10:36:49 +0200 Received: from e178015162.adsl.alicedsl.de ([85.178.15.162] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MB30j-00036k-LN>; Mon, 01 Jun 2009 10:36:49 +0200 Message-ID: <4A239323.1090707@mail.zedat.fu-berlin.de> Date: Mon, 01 Jun 2009 10:36:51 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: bf References: <15091.46749.qm@web39108.mail.mud.yahoo.com> In-Reply-To: <15091.46749.qm@web39108.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.15.162 X-Mailman-Approved-At: Mon, 01 Jun 2009 11:23:52 +0000 Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Kip Macy Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 08:36:51 -0000 bf wrote: > > --- On Sat, 5/30/09, Kip Macy wrote: > > >> From: Kip Macy >> Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 >> To: "bf" >> Cc: freebsd-current@freebsd.org, attilio@freebsd.org, ohartman@mail.zedat.fu-berlin.de >> Date: Saturday, May 30, 2009, 11:55 PM >> >>> I'm running the r193133 amd64 with a custom kernel and >>> >> all debugging off >> >>> on an AMD Athlon64 3400+ single-core, and I haven't >>> >> noticed any significant >> >>> slowing, although I haven't been doing any systematic >>> >> benchmarking. >> >>> What would be the penalties of running an SMP -CURRENT >>> >> kernel on >> >>> single-core hardware with no hyperthreading? Can >>> >> anyone quantify the >> >>> typical added overhead? Or, counterintuitively, >>> >> would an SMP kernel >> >>> be better in some ways? >>> >>> >> He is trying to diagnose if the problem was introduced by >> enabling >> adaptive spinning on sx locks. They're only enabled on SMP >> kernels. >> >> Cheers, >> Kip >> >> > > So I inferred from his request to have Oliver (the original poster) > revert r193011. But it seems unlikely that this is solely or even mostly > responsible for the slowdown, as Oliver reported that it first began > to occur several weeks ago, and Attilio only committed r193011 on Friday > -- unless Oliver independently added ADAPTIVE_SX to his custom kernel > a few weeks ago. In any event, I'm still interested in any reports of > the relative performance of SMP vs. UP kernels on UP hardware that > anyone is able to share. > > Thanks, > b. > > > > Would the addition of ADAPTIVE_SX to a SMP kernel or kernel of any kind have perfomance issues, also performance gains? From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 11:53:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3CFC106566C for ; Mon, 1 Jun 2009 11:53:50 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A4ED88FC16 for ; Mon, 1 Jun 2009 11:53:50 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 5708E613F for ; Mon, 1 Jun 2009 07:53:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1243857229; bh=iQ5ikaM1lGcEqTRCwKOFDI5wFdbOhD64dOOfQOoESD8=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=k+XZvbsNnkrSNRWyuYdkzOX96BNi2O1I4pOVZ4xpu3rC7h0g6GVtAwMBUbANOIwxp SxY2gDZ5TdKrsBnKRloFK9w7uBuyo41b21VwyS/ltddOQzwRDazDDWb6sP6yekB DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=mlattfjOWAe98S5ouDQdOWl5BrTHf/WspGYk9rnZPAkeplGBGVhAavjR33sxwmZ9B +bDKSicRs1oXtpiMwO3WuGipuATGsVQqYe1kkJR8CODCo5F4+WklpCNsxutAUe2 Message-ID: <4A23C147.2000607@protected-networks.net> Date: Mon, 01 Jun 2009 07:53:43 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.21 (X11/20090404) MIME-Version: 1.0 To: freebsd-current X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: fusefs-kmod now broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 11:53:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Recent changes to VFS appear to have broken the FUSE kernel module :-( cc -O2 -pipe -march=prescott -fno-strict-aliasing -march=prescott - -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I../include -I. -I@ - -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 - --param large-function-growth=1000 -fno-common -mno-align-long-strings - -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 - -mno-sse3 -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 -c fuse_io.c cc1: warnings being treated as errors fuse_io.c: In function 'fuse_write_biobackend': fuse_io.c:752: warning: implicit declaration of function 'vfs_bio_set_validclean' fuse_io.c:752: warning: nested extern declaration of 'vfs_bio_set_validclean' *** Error code 1 Stop in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module. *** Error code 1 Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkojwUcACgkQQv9rrgRC1JK0WwCfaG8Qt74iZ/QQ9x3LSIB0TyLG Zj4AoJRI2UIFhRBZPbOMsaec3CpMgTNj =o2IF -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 12:05:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF7DF1065707; Mon, 1 Jun 2009 12:05:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A07448FC0A; Mon, 1 Jun 2009 12:05:35 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA03413; Mon, 01 Jun 2009 15:05:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A23C409.70704@icyb.net.ua> Date: Mon, 01 Jun 2009 15:05:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Timothy Mukaibo References: <49159824-57EB-4628-9F1C-CE9243465D02@mukaibo.com> <200905271725.44235.jhb@freebsd.org> <849F0899-7AD9-4D7A-B849-D7FB36CE73AE@mukaibo.com> <200905280800.24867.jhb@freebsd.org> <4A1E9B34.3040202@icyb.net.ua> <2492E55D-5C36-4A93-BB69-B1539AAB0087@mukaibo.com> In-Reply-To: <2492E55D-5C36-4A93-BB69-B1539AAB0087@mukaibo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ACPI Panic on Current, AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 12:05:46 -0000 on 30/05/2009 03:44 Timothy Mukaibo said the following: > Hello Andriy, > > timothy@tinkysama:~$ cat /boot/loader.conf > snd_hda_load="YES" > uscanner_load="YES" > > Here's the dmesg: it didn't look like a verbose one... -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 12:26:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56401106566B for ; Mon, 1 Jun 2009 12:26:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 34E2F8FC16 for ; Mon, 1 Jun 2009 12:26:34 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB6b3-000FxV-Ro for current@freebsd.org; Mon, 01 Jun 2009 12:26:34 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 4FE721CE6E60 for ; Mon, 1 Jun 2009 21:26:33 +0900 (JST) Date: Mon, 01 Jun 2009 21:26:32 +0900 Message-ID: From: Randy Bush To: FreeBSD Current User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: segfault in buildworld while creating osreldate.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 12:26:34 -0000 amd64 fresh svn of head made and installed kernel. rebooted. ... ===> gnu/usr.bin/texinfo (installincludes) ===> gnu/usr.bin/texinfo/libtxi (installincludes) ===> gnu/usr.bin/texinfo/makeinfo (installincludes) ===> gnu/usr.bin/texinfo/info (installincludes) ===> gnu/usr.bin/texinfo/infokey (installincludes) ===> gnu/usr.bin/texinfo/install-info (installincludes) ===> gnu/usr.bin/texinfo/texindex (installincludes) ===> gnu/usr.bin/texinfo/doc (installincludes) ===> include (includes) cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh Segmentation fault (core dumped) *** Error code 139 it left no core randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 13:07:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22F9310656B6 for ; Mon, 1 Jun 2009 13:07:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F159D8FC24 for ; Mon, 1 Jun 2009 13:07:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 91C0046B06; Mon, 1 Jun 2009 09:07:54 -0400 (EDT) Date: Mon, 1 Jun 2009 14:07:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randy Bush In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: yakpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 13:07:55 -0000 On Mon, 1 Jun 2009, Randy Bush wrote: >> Is it possible to use options KDB_TRACE and KDB_PANIC to dump a stack trace >> to the serial console to use as a starting point for debugging? > > increase size or weight of clue bat please. > > /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 > > /usr/src/sys/amd64/conf/WORK0: unknown option "KDB_PANIC" *** Error code 1 Probably on myself. What I was actually looking for KDB_TRACE and KDB_UNATTENDED, which should print a stack trace and reboot on panic. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 13:20:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDB1C1065672 for ; Mon, 1 Jun 2009 13:20:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 65BEE8FC20 for ; Mon, 1 Jun 2009 13:20:12 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz9 with SMTP id 9so7639517bwz.43 for ; Mon, 01 Jun 2009 06:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=j7kJuzToF1B0rgnskkVDM3zq+YOYK25mBjZ8KAzwuxA=; b=waC6Gdhr3T4vYBRdA0I1SJL5BDwIpC3JCMztJAtXNzuL6CYq/jBb73K8CDrwwjEGC+ hcYyXtAELyHDuN1xIuanfF8VqeK3/vPdYIgTcO5zUqd+SVu/KnqnC2qE9qs6JJKq0IWB 04ZpjkHzXPZuTiJWg5tMei59RigByABnPTetI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rXTcidsZOvBOXajf4eDQV9hUd6J8U0oaGZfLdUXH6j5lF2ZQpmlGfWygLtaAtPCTOp hJuAn/Tjkpw4RA3tUN64dEXYvoY0606/G5nNRMJIM0pYQKBjekb3+jHgnl59HjWgZeIK Ce5+W57nsxPnxIqU8LOige8euEsYEnOahKOtI= MIME-Version: 1.0 Received: by 10.103.108.18 with SMTP id k18mr3238523mum.40.1243862410551; Mon, 01 Jun 2009 06:20:10 -0700 (PDT) In-Reply-To: <4A23C147.2000607@protected-networks.net> References: <4A23C147.2000607@protected-networks.net> Date: Mon, 1 Jun 2009 17:20:10 +0400 Message-ID: From: pluknet To: Michael Butler Content-Type: multipart/mixed; boundary=0016364167f121636d046b494937 Cc: freebsd-current Subject: Re: fusefs-kmod now broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 13:20:13 -0000 --0016364167f121636d046b494937 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/6/1 Michael Butler : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Recent changes to VFS appear to have broken the FUSE kernel module :-( > > cc -O2 -pipe -march=3Dprescott -fno-strict-aliasing -march=3Dprescott > - -Werror -D_KERNEL -DKLD_MODULE -nostdinc =A0-I../include -I. -I@ > - -I@/contrib/altq -finline-limit=3D8000 --param inline-unit-growth=3D100 > - --param large-function-growth=3D1000 -fno-common =A0-mno-align-long-str= ings > - -mpreferred-stack-boundary=3D2 =A0-mno-mmx -mno-3dnow -mno-sse -mno-sse= 2 > - -mno-sse3 -ffreestanding -fstack-protector -std=3Diso9899:1999 > - -fstack-protector -Wall -Wredundant-decls -Wnested-externs > - -Wstrict-prototypes =A0-Wmissing-prototypes -Wpointer-arith -Winline > - -Wcast-qual =A0-Wundef -Wno-pointer-sign -fformat-extensions -c fuse_io= .c > cc1: warnings being treated as errors > fuse_io.c: In function 'fuse_write_biobackend': > fuse_io.c:752: warning: implicit declaration of function > 'vfs_bio_set_validclean' > fuse_io.c:752: warning: nested extern declaration of > 'vfs_bio_set_validclean' > *** Error code 1 I guess you can safely substitute that with 'vfs_bio_set_valid' and friends= . As at whole AFAICS that's already out of sync with -current VM. --=20 wbr, pluknet --0016364167f121636d046b494937 Content-Type: application/octet-stream; name="fusefs_kmod.diff" Content-Disposition: attachment; filename="fusefs_kmod.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fvf7javc0 ZGlmZiAtdXJwTiBmdXNlZnMta21vZC5vcmlnL2ZpbGVzL3BhdGNoLWZ1c2VfbW9kdWxlX19mdXNl LmggZnVzZWZzLWttb2QvZmlsZXMvcGF0Y2gtZnVzZV9tb2R1bGVfX2Z1c2UuaAotLS0gZnVzZWZz LWttb2Qub3JpZy9maWxlcy9wYXRjaC1mdXNlX21vZHVsZV9fZnVzZS5oCU1vbiBKdW4gIDEgMTY6 NDc6MjQgMjAwOQorKysgZnVzZWZzLWttb2QvZmlsZXMvcGF0Y2gtZnVzZV9tb2R1bGVfX2Z1c2Uu aAlNb24gSnVuICAxIDE3OjE0OjM3IDIwMDkKQEAgLTEsOSArMSwxNyBAQAotLS0tIGZ1c2VfbW9k dWxlL2Z1c2UuaC5vcmlnCTIwMDgtMDItMDUgMDA6MjU6NTcuMDAwMDAwMDAwIC0wNTAwCi0rKysg ZnVzZV9tb2R1bGUvZnVzZS5oCTIwMDktMDUtMTMgMTg6NDA6MTkuMDAwMDAwMDAwIC0wNDAwCi1A QCAtMjUsNiArMjUsMjIgQEAKKy0tLSBmdXNlX21vZHVsZS9mdXNlLmgub3JpZwlUdWUgRmViICA1 IDA4OjI1OjU3IDIwMDgKKysrKyBmdXNlX21vZHVsZS9mdXNlLmgJTW9uIEp1biAgMSAxNjo1MDox OSAyMDA5CitAQCAtMjUsNiArMjUsMzAgQEAKICAjZW5kaWYKICAjZW5kaWYKICAKKysjaWZuZGVm IFVTRV9PTERfVkFMSURDTEVBTl9BUEkKKysjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gODAwMDk2 CisrI2RlZmluZSBVU0VfT0xEX1ZBTElEQ0xFQU5fQVBJIDAKKysjZWxzZQorKyNkZWZpbmUgVVNF X09MRF9WQUxJRENMRUFOX0FQSSAxCisrI2VuZGlmCisrI2VuZGlmCisrCiArI2lmbmRlZiBWRlNP UFNfVEFLRVNfVEhSRUFECiArI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDgwMDA4NwogKyNkZWZp bmUgVkZTT1BTX1RBS0VTX1RIUkVBRCAwCkBAIC0yMywxOCArMzEsMTggQEAKICAjaWZuZGVmIFZP UF9PUEVOX1RBS0VTX0ZQCiAgI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDcwMDA0NAogICNkZWZp bmUgVk9QX09QRU5fVEFLRVNfRlAgMQotQEAgLTQ5LDYgKzY1LDE0IEBACi0gI2VuZGlmCi0gI2Vu ZGlmCi0gCitAQCAtNDYsNiArNzAsMTQgQEAKKyAjZGVmaW5lIFZPUF9VTkxPQ0tfVEFLRVNfVEhS RUFEIDAKKyAjZWxzZQorICNkZWZpbmUgVk9QX1VOTE9DS19UQUtFU19USFJFQUQgMQorKyNlbmRp ZgorKyNlbmRpZgorKwogKyNpZm5kZWYgVk9QX0dFVEFUVFJfVEFLRVNfVEhSRUFECiArI2lmIF9f RnJlZUJTRF92ZXJzaW9uID49IDgwMDA0NgogKyNkZWZpbmUgVk9QX0dFVEFUVFJfVEFLRVNfVEhS RUFEIDAKICsjZWxzZQogKyNkZWZpbmUgVk9QX0dFVEFUVFJfVEFLRVNfVEhSRUFEIDEKLSsjZW5k aWYKLSsjZW5kaWYKLSsKLSAjaWZuZGVmIFVTRV9QUklWSUxFR0VfQVBJCi0gLyoKLSAgKiBfX0Zy ZWVCU0RfdmVyc2lvbiBidW1wIHdhcyBvbWl0dGVkIGZvciBpbnRyb2R1Y3Rpb24gb2YKKyAjZW5k aWYKKyAjZW5kaWYKKyAKZGlmZiAtdXJwTiBmdXNlZnMta21vZC5vcmlnL2ZpbGVzL3BhdGNoLWZ1 c2VfbW9kdWxlX19mdXNlX2lvLmMgZnVzZWZzLWttb2QvZmlsZXMvcGF0Y2gtZnVzZV9tb2R1bGVf X2Z1c2VfaW8uYwotLS0gZnVzZWZzLWttb2Qub3JpZy9maWxlcy9wYXRjaC1mdXNlX21vZHVsZV9f ZnVzZV9pby5jCU1vbiBKdW4gIDEgMTY6NDc6MjQgMjAwOQorKysgZnVzZWZzLWttb2QvZmlsZXMv cGF0Y2gtZnVzZV9tb2R1bGVfX2Z1c2VfaW8uYwlNb24gSnVuICAxIDE3OjE0OjU3IDIwMDkKQEAg LTEsNSArMSw1IEBACi0tLS0gZnVzZV9tb2R1bGUvZnVzZV9pby5jLm9yaWcJMjAwOC0wMi0wNSAw MDoyNTo1Ny4wMDAwMDAwMDAgLTA1MDAKLSsrKyBmdXNlX21vZHVsZS9mdXNlX2lvLmMJMjAwOC0w OS0yNiAxMzoxNTo1Ni4wMDAwMDAwMDAgLTA0MDAKKy0tLSBmdXNlX21vZHVsZS9mdXNlX2lvLmMu b3JpZwlUdWUgRmViICA1IDA4OjI1OjU3IDIwMDgKKysrKyBmdXNlX21vZHVsZS9mdXNlX2lvLmMJ TW9uIEp1biAgMSAxNzoxMzowMSAyMDA5CiBAQCAtMTU3LDcgKzE1NywxMSBAQAogIAkJZ290byBv dXQ7CiAgCkBAIC0xMyw3ICsxMywxOSBAQAogIAkJCWdvdG8gb3V0OwogIAkJdWlvLT51aW9fb2Zm c2V0ID0gdmEudmFfc2l6ZTsKICAJfSBlbHNlIGlmICgoZmxhZ3MgJiBGT0ZfT0ZGU0VUKSA9PSAw KQotQEAgLTgyMyw3ICs4MjcsMTEgQEAKK0BAIC03NDUsNyArNzQ5LDExIEBACisgCQkJCWJwLT5i X2RpcnR5b2ZmID0gb247CisgCQkJCWJwLT5iX2RpcnR5ZW5kID0gb24gKyBuOworIAkJCX0KKysj aWYgVVNFX09MRF9WQUxJRENMRUFOX0FQSQorIAkJCXZmc19iaW9fc2V0X3ZhbGlkY2xlYW4oYnAs IG9uLCBuKTsKKysjZWxzZQorKwkJCXZmc19iaW9fc2V0X3ZhbGlkKGJwLCBvbiwgbik7CisrI2Vu ZGlmCisgCQl9CisgCisgCQlid3JpdGUoYnApOworQEAgLTgyMyw3ICs4MzEsMTEgQEAKICAjaWYg RlVTRUxJQl9DT05GT1JNX0JJT1JFQUQKICAJCXN0cnVjdCB2YXR0ciB2YTsKICAKZGlmZiAtdXJw TiBmdXNlZnMta21vZC5vcmlnL2ZpbGVzL3BhdGNoLWZ1c2VfbW9kdWxlX19mdXNlX3Zub3BzLmMg ZnVzZWZzLWttb2QvZmlsZXMvcGF0Y2gtZnVzZV9tb2R1bGVfX2Z1c2Vfdm5vcHMuYwotLS0gZnVz ZWZzLWttb2Qub3JpZy9maWxlcy9wYXRjaC1mdXNlX21vZHVsZV9fZnVzZV92bm9wcy5jCU1vbiBK dW4gIDEgMTY6NDc6MjQgMjAwOQorKysgZnVzZWZzLWttb2QvZmlsZXMvcGF0Y2gtZnVzZV9tb2R1 bGVfX2Z1c2Vfdm5vcHMuYwlNb24gSnVuICAxIDE3OjE1OjIxIDIwMDkKQEAgLTEsNSArMSw1IEBA Ci0tLS0gZnVzZV9tb2R1bGUvZnVzZV92bm9wcy5jLm9yaWcJMjAwOC0wMi0wNSAwMDoyNTo1Ny4w MDAwMDAwMDAgLTA1MDAKLSsrKyBmdXNlX21vZHVsZS9mdXNlX3Zub3BzLmMJMjAwOC0xMC0yOSAx OToyMTo1MS4wMDAwMDAwMDAgLTA0MDAKKy0tLSBmdXNlL21vZHVsZS9mdXNlX3Zub3BzLmMub3Jp ZwlUdWUgRmViICA1IDA4OjI1OjU3IDIwMDgKKysrKyBmdXNlX21vZHVsZS9mdXNlX3Zub3BzLmMJ TW9uIEp1biAgMSAxNzoxMzowOSAyMDA5CiBAQCAtNzk5LDggKzc5OSwxMSBAQAogIAlzdHJ1Y3Qg dm5vZGUgKnZwID0gYXAtPmFfdnA7CiAgCXN0cnVjdCB2YXR0ciAqdmFwID0gYXAtPmFfdmFwOwpA QCAtNzgsMyArNzgsMTUgQEAKICAJaW50IGVyciA9IDA7CiAgCXN0cnVjdCBmdXNlX2Rpc3BhdGNo ZXIgZmRpOwogIAlzdHJ1Y3QgZnVzZV9zZXRhdHRyX2luICpmc2FpOworQEAgLTM0NTUsNyArMzQ3 OSwxMSBAQAorIAkJCSAqIFJlYWQgb3BlcmF0aW9uIGZpbGxlZCBhIHBhcnRpYWwgcGFnZS4KKyAJ CQkgKi8KKyAJCQltLT52YWxpZCA9IDA7CisrI2lmIFVTRV9PTERfVkFMSURDTEVBTl9BUEkKKyAJ CQl2bV9wYWdlX3NldF92YWxpZGNsZWFuKG0sIDAsIHNpemUgLSB0b2ZmKTsKKysjZWxzZQorKwkJ CXZtX3BhZ2Vfc2V0X3ZhbGlkKG0sIDAsIHNpemUgLSB0b2ZmKTsKKysjZW5kaWYKKyAJCQkvKiBo YW5kbGVkIGJ5IHZtX2ZhdWx0IG5vdwkgICovCisgCQkJLyogdm1fcGFnZV96ZXJvX2ludmFsaWQo bSwgVFJVRSk7ICovCisgCQl9IGVsc2Ugewo= --0016364167f121636d046b494937-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 13:20:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CBEB1065678; Mon, 1 Jun 2009 13:20:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A74808FC20; Mon, 1 Jun 2009 13:20:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA04750; Mon, 01 Jun 2009 16:20:37 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A23D5A4.6020009@icyb.net.ua> Date: Mon, 01 Jun 2009 16:20:36 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: John Baldwin Subject: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 13:20:39 -0000 What about the following patch? I believe that the idea behind fsck_y_enable is to try to make unattended systems with rw filesystems as recoverable as possible at the cost of potential damage to the data. The new "-C" option should not interfere with this goal, but should reduce recovery time, because currently fsck -y checks *all* filesystems from fstab, even those that are ro or clean: -C Check if the “clean†flag is set in the superblock and skip file system checks if file system was properly dismounted and marked clean. diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck index bf51089..c0cb359 100755 --- a/etc/rc.d/fsck +++ b/etc/rc.d/fsck @@ -45,7 +45,7 @@ fsck_start() 8) if checkyesno fsck_y_enable; then echo "File system preen failed, trying fsck -y." - fsck -y + fsck -y -C case $? in 0) ;; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 14:03:26 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51B7F106570A for ; Mon, 1 Jun 2009 14:03:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5BB8FC1A for ; Mon, 1 Jun 2009 14:03:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id DF51846B2E for ; Mon, 1 Jun 2009 10:03:25 -0400 (EDT) Date: Mon, 1 Jun 2009 15:03:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Processes stuck in [vmo_de] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 14:03:26 -0000 Was doing a local build on a VMWare 8.x image today, and ran into this: rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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 -nostdinc -I. -I../../.. -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../dev/ath -I../../../dev/ath/ath_hal -I../../../contrib/ngatm -I../../../dev/twa -I../../../gnu/fs/xfs/FreeBSD -I../../../gnu/fs/xfs/FreeBSD/support -I../../../gnu/fs/xfs -I../../../contrib/opensolaris/compat -I../../../dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k ^Z Suspended robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> bg [1] make depend & robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> fg make depend load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k load: 0.20 cmd: xargs 5100 [piperd] 0.02r 0.00u 0.00s 0% 1592k ^C load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k ^C^C^C load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k load: 0.20 cmd: sh 5099 [vmo_de] 0.02r 0.00u 0.00s 0% 0k ^C^C^C (another pty) robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/sys> ps axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND ... 1001 5038 5037 0 76 0 5592 3012 pause Ss 4 0:00.00 -tcsh (tcsh 1001 5054 5038 0 76 0 8032 6764 wait S+ 4 0:00.00 make depend 1001 5098 5054 0 76 0 3572 1796 wait S+ 4 0:00.00 [sh] 1001 5099 5098 0 76 0 0 8 vmo_de D+ 4 0:00.00 [sh] And unfortunately: robert@cinnamon-freebsd:~/freebsd/svncommit/base/head/sys/i386/compile/GENERIC> su Password: load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k load: 0.20 cmd: csh 5120 [vmo_de] 0.00r 0.00u 0.00s 0% 0k FreeBSD cinnamon-freebsd 8.0-CURRENT FreeBSD 8.0-CURRENT #5 r193116M: Sun May 31 10:14:00 BST 2009 robert@cinnamon-freebsd:/usr/home/robert/freebsd/svncommit/base/projects/pnet/sys/i386/compile/GENERIC i386 This appears to be head from a few days ago, but I don't have a specific source code date. Unfortunately, no BREAK_TO_DEBUGGER, and I can't su to enter via debug.kdb.enter. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 14:29:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8BA0106566C for ; Mon, 1 Jun 2009 14:29:30 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id ADC138FC16 for ; Mon, 1 Jun 2009 14:29:30 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MB8W2-000GHF-Ep for current@freebsd.org; Mon, 01 Jun 2009 14:29:30 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id E71981CF2ACE for ; Mon, 1 Jun 2009 23:29:29 +0900 (JST) Date: Mon, 01 Jun 2009 23:29:29 +0900 Message-ID: From: Randy Bush To: current In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: installworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 14:29:31 -0000 > 8-current a few hours old, i386 > ===> usr.bin/ee (install) > install -s -o root -g wheel -m 555 ee /usr/bin > cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > gencat:No such file or directory > *** Error code 1 another 8-current, and amd64 freshly svn ==> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib ln -fs /lib/libc.so.7 /usr/lib/libc.so install -o root -g wheel -m 444 libc_pic.a /usr/lib gencat be_BY.UTF-8.cat /usr/src/lib/libc/nls/be_BY.UTF-8.msg gencat:No such file or directory *** Error code 1 gencat and the file both exist /usr/src# gencat FOO /usr/src/lib/libc/nls/be_BY.UTF-8.msg /usr/src# ls -l FOO -rw-r--r-- 1 root wheel 7551 Jun 1 14:27 FOO pr filed randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 14:56:48 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 232E71065674; Mon, 1 Jun 2009 14:56:48 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBC5F8FC15; Mon, 1 Jun 2009 14:56:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9675046B49; Mon, 1 Jun 2009 10:56:47 -0400 (EDT) Date: Mon, 1 Jun 2009 15:56:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: jeff@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: attilio@FreeBSD.org, current@FreeBSD.org Subject: Re: scheduler IPIs during shutdown (was: svn commit: r193170 - projects/pnet/sys/kern (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 14:56:48 -0000 On Sun, 31 May 2009, Robert Watson wrote: > - System shutdown kicks off, and CPU 0 starts IPIing CPUs to shut them down, > which apparently can occur while holding the thread lock: Just ran into a very similar issue on another i386 box, this one a VMWare VM -- hand transcribed, I'm afraid: db> bt Tracing pid 1 tid 100002 td 0xc456fd80 kdb_enter() panic() _mtx_lock_spin_failed() _thread_lock_flags() hardclock_cpu() hardclock() lapic_handle_timer() Xtimerint() --- interrupt DELAY() cpu_reset() shutdown_reset() boot() reboot() syscall() Xint0x80_syscall() db> show alllocks Process 1 (init) thread 0xc456fd80 (100002) exclusive sleep mutx Giant (Giant) ... db> trace 100003 <-- idle thread on cpu 1 cpustop_handler() ipi_nmi_handler() trap() calltrap() --- trap 0x13 tdq_move() sched_idletd() fork_exit() fork_trampoline() It looks like (a) we should really be disabling interrupts before the DELAY() so we don't have to deal with hardclock, and (b) perhaps an NMI for cpustop isn't the right thing, since it stops CPUs while they hold spinlocks? Robert N M Watson Computer Laboratory University of Cambridge > > db> trace 100005 > Tracing pid 11 tid 100005 td 0xc4d546c0 > cpustop_handler(2,c4a53b64,c0b70cad,c0d9c680,c4a53ae4,...) at > cpustop_handler+0x32 > ipi_nmi_handler(c0d9c680,c4a53ae4,2,f,c4d52a90,...) at ipi_nmi_handler+0x2f > trap(c4a53b70) at trap+0x2d > calltrap() at calltrap+0x6 > --- trap 0x13, eip = 0xc0887a61, esp = 0xc4a53bb0, ebp = 0xc4a53bdc --- > sched_switch(c4d546c0,0,60c,187,5dd9d2a1,...) at sched_switch+0x401 > mi_switch(60c,0,c0c3d1ae,813,1,...) at mi_switch+0x200 > sched_preempt(c4d546c0,1,c4d54d80,c4a53cb4,c0b5428e,...) at > sched_preempt+0x9f > ipi_bitmap_handler(8,28,28,31,c0d8e500,...) at ipi_bitmap_handler+0x34 > Xipi_intr_bitmap_handler() at Xipi_intr_bitmap_handler+0x2e > --- interrupt, eip = 0xc0856a17, esp = 0xc4a53c8c, ebp = 0xc4a53cb4 --- > _thread_lock_flags(c4d546c0,0,c0c3d1ae,a04,c4d546c0,...) at > _thread_lock_flags+0x177 > sched_idletd(0,c4a53d38,c0c36ad3,335,c4d52a90,...) at sched_idletd+0x251 > fork_exit(c0888510,0,c4a53d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc4a53d70, ebp = 0 --- > > > - hardclock fires on CPU 0 and tries to schedule a SWI -- typically softclock > or netisr, which bumps into the "leaked" thread lock: > > db> bt > Tracing pid 1 tid 100002 td 0xc4d54d80 > kdb_enter(c0c3b5e5,c0c3b5e5,c0c39ccd,c4a49ad0,0,...) at kdb_enter+0x3a > panic(c0c39ccd,c4d546c0,c0d8eb44,c4d546c0,186a5,...) at panic+0x136 > _mtx_lock_spin_failed(1,9,c0c36d52,320,0,...) at _mtx_lock_spin_failed+0x51 > _thread_lock_flags(c4d54240,0,c0c36d52,320,dd313180,...) at > _thread_lock_flags+0x175 > intr_event_schedule_thread(c4a49b58,c4a49b68,c0915dc4,c4d3a180,0,...) at > intr_event_schedule_thread+0xc7 > swi_sched(c4d3a180,0,c4a49b74,c0859a2f,c0d893d4,...) at swi_sched+0x28 > netisr_sched_poll(c0d893d4,c4a49b88,c0824064,0,2,...) at > netisr_sched_poll+0x24 > hardclock_device_poll(0,2) at hardclock_device_poll+0xcf > hardclock(0,c0b74a49,0,27f,5dd9e8a2,...) at hardclock+0x44 > lapic_handle_timer(c4a49bb0) at lapic_handle_timer+0x9f > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip = 0xc0b74a49, esp = 0xc4a49bf0, ebp = 0xc4a49c0c --- > DELAY(f4240,0,c4d40980,c4a49c2c,c08653d3,...) at DELAY+0x89 > cpu_reset(f4240,c4a49c68,c0865eaf,0,0,...) at cpu_reset+0xd5 > shutdown_reset(0,0,c0c3b4a3,1a7,0,...) at shutdown_reset+0x23 > boot(c0d89210,0,c0c3b4a3,ad,c4a49d2c,...) at boot+0x75f > reboot(c4d54d80,c4a49cf8,4,c0c428a4,c0d1dc28,...) at reboot+0x4b > syscall(c4a49d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > Possibly hardclock should simply know not to kick off softclock at that point > in the shutdown (just like I've taught it not to kick off netisr in the > device_polling code in my branch), but more generally, sched_ule probably > needs to not hold the per-cpu runqueue lock, and/or sched_ule needs to not > try to start work on CPUs that aren't running. If the SWI is pinned on or > bound to an already shut down CPU, then we should in fact panic, but > otherwise it seems it should preempt the current thread and run it on the CPU > managing the shutdown. > > Or, we could go with the old-world order view and not allow interrupts to > fire, but I wonder if all our device drivers would be comfortable with that. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > ---------- Forwarded message ---------- > Date: Sun, 31 May 2009 13:52:17 +0000 (UTC) > From: Robert Watson > To: src-committers@freebsd.org, svn-src-projects@freebsd.org > Subject: svn commit: r193170 - projects/pnet/sys/kern > > Author: rwatson > Date: Sun May 31 13:52:17 2009 > New Revision: 193170 > URL: http://svn.freebsd.org/changeset/base/193170 > > Log: > Add a shutdown handler for device polling -- don't issue wakeups to the > netisr once file systems are done syncing, otherwise the scheduler may > generate IPIs to CPUs that have already been shutdown, leading to a > panic. > > As similar panics (spin lock 0xc0d8e500 (sched lock 1) held by > 0xc4d546c0 (tid 100005) too long) have been reported on both 7.x and 8.x > in other code, we might want to think about whether there's some missing > scheduler shutdown logic to handle this case for unpinned/unbound > threads by migrating them to the CPU managing the shutdown and allowing > them to preempt. > > Modified: > projects/pnet/sys/kern/kern_poll.c > > Modified: projects/pnet/sys/kern/kern_poll.c > ============================================================================== > --- projects/pnet/sys/kern/kern_poll.c Sun May 31 12:36:14 2009 > (r193169) > +++ projects/pnet/sys/kern/kern_poll.c Sun May 31 13:52:17 2009 > (r193170) > @@ -36,6 +36,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include /* needed by net/if.h > */ > #include > @@ -110,6 +111,7 @@ SYSCTL_UINT(_kern_polling, OID_AUTO, bur > > static int netisr_poll_scheduled; > static int netisr_pollmore_scheduled; > +static int poll_shutting_down; > > static int poll_burst_max_sysctl(SYSCTL_HANDLER_ARGS) > { > @@ -261,10 +263,19 @@ struct pollrec { > static struct pollrec pr[POLL_LIST_LEN]; > > static void > +poll_shutdown(void *arg, int howto) > +{ > + > + poll_shutting_down = 1; > +} > + > +static void > init_device_poll(void) > { > > mtx_init(&poll_mtx, "polling", NULL, MTX_DEF); > + EVENTHANDLER_REGISTER(shutdown_post_sync, poll_shutdown, NULL, > + SHUTDOWN_PRI_LAST); > } > SYSINIT(device_poll, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, init_device_poll, > NULL); > > @@ -288,7 +299,7 @@ hardclock_device_poll(void) > static struct timeval prev_t, t; > int delta; > > - if (poll_handlers == 0) > + if (poll_handlers == 0 || poll_shutting_down) > return; > > microuptime(&t); > _______________________________________________ > 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 Jun 1 14:58:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ADF2106566B; Mon, 1 Jun 2009 14:58:46 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA548FC16; Mon, 1 Jun 2009 14:58:46 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=HufNFVzxPQeQwH7dsO8okmwCA4JV2hrC/W08qMf5raB7PhsnN5a5xcQj1bR9ZTZqczHFfVHCdIzl6bJkqt6K81eKP1Rl4sjtb58IEP3gxnXwxVuJPP0/DV97qlyz543mIFwBxTSrXc/kIb7r9AQp6VARGQtzSOyH+dWLnSClMUI=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MB8yK-000GLK-6b; Mon, 01 Jun 2009 18:58:44 +0400 Date: Mon, 1 Jun 2009 18:58:41 +0400 From: Eygene Ryabinkin To: Randy Bush Message-ID: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 14:58:46 -0000 Randy, good day. Mon, Jun 01, 2009 at 09:45:52AM +0900, Randy Bush wrote: > >>> =3D=3D=3D> usr.bin/ee (install) > >>> install -s -o root -g wheel -m 555 ee /usr/bin > >>> cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg > >>> gencat en_US.US-ASCII.cat en_US.US-ASCII.msg > >>> gencat:No such file or directory [...] > >=20 > > You should have gencat allready installed: > >=20 > > cd /usr/src/usr.bin/gencat && make install >=20 > gencat is installed. it is whining that it can not find the file May be gencat is installed, but 'make install' could not find it: message "gencat:No such file or directory" comes from make, not =66rom gencat itself. Will you be able to run 'make clean; make; make install' from /usr/src/usr.bin/ee to see if the problem is specific to the 'make installworld' or shows even for manual installation? Thanks! --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:07:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241DB106566B; Mon, 1 Jun 2009 15:07:56 +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 D48528FC15; Mon, 1 Jun 2009 15:07:54 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA06754; Mon, 01 Jun 2009 18:07:52 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A23EEC8.2040208@freebsd.org> Date: Mon, 01 Jun 2009 18:07:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, Henri Hennebert References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> In-Reply-To: <4A1FD687.5070502@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kip Macy Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:07:56 -0000 on 29/05/2009 15:35 Andriy Gapon said the following: > So anyone else feels that this is a bug? > > on 28/05/2009 16:55 Andriy Gapon said the following: >> on 28/05/2009 16:26 Henri Hennebert said the following: >>> (gdb) bt >>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >> I find the above part interesting. >> Could this be because of the following discrepancy: >> >> 1) >> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >> extern void __assert(const char *, const char *, int); >> 2) >> lib/libc/gen/assert.c: >> void >> __assert(func, file, line, failedexpr) >> const char *func, *file; >> int line; >> const char *failedexpr; >> >>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 I propose the following patch for this issue. It fixes mismatch between __assert extern declaration in zfs code and actual signature in libc code. I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that those checks are not needed with compilers that can be used to compile FreeBSD. Besides, both branches of __STDC_VERSION__ check were exactly the same. Henri, if you still experience that crash of zpool command, could you please try the patch and see if you have a nicer assert message and stacktrace now? Sorry, that this is still not a fix for the real issue. diff --git a/cddl/contrib/opensolaris/head/assert.h b/cddl/contrib/opensolaris/head/assert.h index 394820a..c2a4936 100644 --- a/cddl/contrib/opensolaris/head/assert.h +++ b/cddl/contrib/opensolaris/head/assert.h @@ -37,15 +37,7 @@ extern "C" { #endif -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -extern void __assert(const char *, const char *, int); -#else -extern void __assert(const char *, const char *, int); -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -extern void _assert(); -#endif +extern void __assert(const char *, const char *, int, const char *); #ifdef __cplusplus } @@ -68,14 +60,6 @@ extern void _assert(); #else -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #endif /* NDEBUG */ diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h index 7ae7f9d..631e302 100644 --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); #define fm_panic panic /* This definition is copied from assert.h. */ -#if defined(__STDC__) -#if __STDC_VERSION__ - 0 >= 199901L -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#else -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) -#endif /* __STDC_VERSION__ - 0 >= 199901L */ -#else -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) -#endif /* __STDC__ */ - +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) #define VERIFY verify #define ASSERT assert -extern void __assert(const char *, const char *, int); +extern void __assert(const char *, const char *, int, const char *); #ifdef lint #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ #LEFT, #OP, #RIGHT, \ (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ - __assert(__buf, __FILE__, __LINE__); \ + __assert(__func__, __FILE__, __LINE__, __buf); \ } \ _NOTE(CONSTCOND) } while (0) /* END CSTYLED */ -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:17:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B428D1065678; Mon, 1 Jun 2009 15:17:48 +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 B07A68FC1A; Mon, 1 Jun 2009 15:17:47 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07136; Mon, 01 Jun 2009 18:17:46 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A23F119.5050103@freebsd.org> Date: Mon, 01 Jun 2009 18:17:45 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A1FEE04.1060202@freebsd.org> <4A202148.9090108@gmail.com> In-Reply-To: <4A202148.9090108@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ulf Lilleengen Subject: Re: fixing kobj signatures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:17:49 -0000 on 29/05/2009 20:54 Ulf Lilleengen said the following: Andriy Gapon wrote: [...] > The current diff here: > http://people.freebsd.org/~avg/ > > It is quite arbitrarily split into the following files: > kobj-agp.diff > kobj-arm.diff > kobj-linker.diff > kobj-other.diff > kobj-sound.diff I have uploaded updated diffs that account for comments from jhb and lulf. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:22:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE0D81065673 for ; Mon, 1 Jun 2009 15:22:57 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 371158FC15 for ; Mon, 1 Jun 2009 15:22:56 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so7717615bwz.43 for ; Mon, 01 Jun 2009 08:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=41bInsMoqM7+ezbrbQrP5h6CJg4ona7l4OqrDH91rEc=; b=XEpZtbVfdeP+zhknwzLo8BOw/Nmcr0z4a/BAqugT02pggk2pZP1X5xP/v+YXC1KZ9m cKK88Cl0NS7S1O5++Qx2eZMSRQ3Js9cMVbzRofzBaEwjqRw4Zr//YCc/aFHMEnPEMWrJ f0+eG6BMMAygAwmCGIy4wakcCQsjB6NTQunBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QgYG6sgJrcnrZrc7UDJbgCM8Vm9l0B5Oasqc9HevTYOLJysYyWiy3NHk+XBa7hX+NG zOVm82RwVOZoXmfQEhQPX1PoZPsGtTuFUtQL/O5TWETx8ce0d8DCooN0SUDeGHhBMAxi QoYxYqB83IiBUCRVUPoY20OOiTpLVNFemkoMo= MIME-Version: 1.0 Received: by 10.204.54.143 with SMTP id q15mr5765261bkg.148.1243869775323; Mon, 01 Jun 2009 08:22:55 -0700 (PDT) In-Reply-To: <4A23D5A4.6020009@icyb.net.ua> References: <4A23D5A4.6020009@icyb.net.ua> Date: Mon, 1 Jun 2009 15:22:55 +0000 Message-ID: <3a142e750906010822s8538b65kdd529d2267ec7d41@mail.gmail.com> From: "Paul B. Mahol" To: Andriy Gapon Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:22:58 -0000 On 6/1/09, Andriy Gapon wrote: > > What about the following patch? > I believe that the idea behind fsck_y_enable is to try to make unattended > systems > with rw filesystems as recoverable as possible at the cost of potential > damage to > the data. The new "-C" option should not interfere with this goal, but > should > reduce recovery time, because currently fsck -y checks *all* filesystems > from > fstab, even those that are ro or clean: > > -C Check if the =93clean=94 flag is set in the superblock and skip f= ile > system checks if file system was properly dismounted and marked > clean. > > > diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck > index bf51089..c0cb359 100755 > --- a/etc/rc.d/fsck > +++ b/etc/rc.d/fsck > @@ -45,7 +45,7 @@ fsck_start() > 8) > if checkyesno fsck_y_enable; then > echo "File system preen failed, trying fsck -y." > - fsck -y > + fsck -y -C > case $? in > 0) > ;; > > -- > Andriy Gapon > _______________________________________________ > 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= " > +1 --=20 Paul From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:33:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A323106566B; Mon, 1 Jun 2009 15:33:16 +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 516888FC13; Mon, 1 Jun 2009 15:33:15 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07395; Mon, 01 Jun 2009 18:33:13 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A23F4B8.7000002@freebsd.org> Date: Mon, 01 Jun 2009 18:33:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A23D5A4.6020009@icyb.net.ua> In-Reply-To: <4A23D5A4.6020009@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:33:16 -0000 on 01/06/2009 16:20 Andriy Gapon said the following: > What about the following patch? > I believe that the idea behind fsck_y_enable is to try to make unattended systems > with rw filesystems as recoverable as possible at the cost of potential damage to > the data. The new "-C" option should not interfere with this goal, but should > reduce recovery time, because currently fsck -y checks *all* filesystems from > fstab, even those that are ro or clean: > > -C Check if the “clean†flag is set in the superblock and skip file > system checks if file system was properly dismounted and marked > clean. > One potential issue that I've just thought of is that fsck_msdosfs doesn't seem to support this option (even in a dummy way), so it would be a problem for those who have msdos filesystems in fstab and also have fsck_y_enable. > diff --git a/etc/rc.d/fsck b/etc/rc.d/fsck > index bf51089..c0cb359 100755 > --- a/etc/rc.d/fsck > +++ b/etc/rc.d/fsck > @@ -45,7 +45,7 @@ fsck_start() > 8) > if checkyesno fsck_y_enable; then > echo "File system preen failed, trying fsck -y." > - fsck -y > + fsck -y -C > case $? in > 0) > ;; > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:53:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C79C21065696 for ; Mon, 1 Jun 2009 15:53:25 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 096858FC17 for ; Mon, 1 Jun 2009 15:53:24 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=glm44wUnIQYA:10 a=yUlx0E-WNWoA:10 a=8jtV6kty40S9m3uVcjgA:9 a=dd9q3UaPiirgIEU254UadbpfZWEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 504695822; Mon, 01 Jun 2009 17:53:23 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 1 Jun 2009 17:57:31 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906011757.31908.hselasky@c2i.net> Cc: Robert Watson , current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:53:26 -0000 On Monday 01 June 2009, Robert Watson wrote: > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. In practice, most behavior remains identical > in the default configuration (direct dispatch, single netisr thread that's > not bound to a CPU, etc), but people will want to watch out for problems. > Some default queue limits have been raised. > > More functional changes to take advantage of these features, such as > deferred ethernet dispatch and software flow ID generation, will follow as > patches, but probably not ship in 8.0 out of the box. > Hi, Having WITNESS and INVARIANTS in the kernel config I get a panic about a NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 has been properly setup. CPU: 2-HTT Workaround: net.isr.direct=0 net.isr.direct_force=0 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:12:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A10106566C; Mon, 1 Jun 2009 16:12:30 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id BD82F8FC12; Mon, 1 Jun 2009 16:12:29 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id D85754646; Mon, 1 Jun 2009 18:12:28 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n51GCL6G004077; Mon, 1 Jun 2009 18:12:22 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243872748; bh=nJ53m1JzHDZ21Cow2qHSjdl9aZsUVcLmIJ0dd9512L0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Yge48f3PMKBpD6g39Jr7VeCS/veYGRyE0O5FhR2k4SdNnLDRC0AzKq8aMLuwRW8km H2WhQNO+I3x/mwqqTqdwQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=jRJRY/SPh3zmqbx3KUxMWeyyj0XIdpLrVLJmOUYK72fWZNZDEGQauBDfHktrK3OB4 VKNxAgR1iMJ5rsxjMTpIw== Message-ID: <4A23FDE5.1040101@restart.be> Date: Mon, 01 Jun 2009 18:12:21 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Andriy Gapon References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> In-Reply-To: <4A23EEC8.2040208@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Kip Macy Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:12:30 -0000 Andriy Gapon wrote: > on 29/05/2009 15:35 Andriy Gapon said the following: >> So anyone else feels that this is a bug? >> >> on 28/05/2009 16:55 Andriy Gapon said the following: >>> on 28/05/2009 16:26 Henri Hennebert said the following: >>>> (gdb) bt >>>> #0 0x00000008012a6f22 in strlen () from /lib/libc.so.7 >>>> #1 0x00000008012a0feb in open () from /lib/libc.so.7 >>>> #2 0x000000080129ea59 in open () from /lib/libc.so.7 >>>> #3 0x00000008012a1f2e in vfprintf () from /lib/libc.so.7 >>>> #4 0x0000000801291158 in fprintf () from /lib/libc.so.7 >>>> #5 0x0000000801290fb0 in __assert () from /lib/libc.so.7 >>> I find the above part interesting. >>> Could this be because of the following discrepancy: >>> >>> 1) >>> cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h: >>> extern void __assert(const char *, const char *, int); >>> 2) >>> lib/libc/gen/assert.c: >>> void >>> __assert(func, file, line, failedexpr) >>> const char *func, *file; >>> int line; >>> const char *failedexpr; >>> >>>> #6 0x0000000800fef120 in zmutex_destroy () from /lib/libzpool.so.1 >>>> #7 0x000000080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1 >>>> #8 0x0000000801045ffa in dbuf_find () from /lib/libzpool.so.1 >>>> #9 0x0000000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1 >>>> #10 0x0000000801027546 in dsl_pool_open () from /lib/libzpool.so.1 >>>> #11 0x000000080101bcec in spa_create () from /lib/libzpool.so.1 >>>> #12 0x000000080101c820 in spa_tryimport () from /lib/libzpool.so.1 > > I propose the following patch for this issue. > It fixes mismatch between __assert extern declaration in zfs code and actual > signature in libc code. > I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think that > those checks are not needed with compilers that can be used to compile FreeBSD. > Besides, both branches of __STDC_VERSION__ check were exactly the same. > > Henri, > > if you still experience that crash of zpool command, could you please try the > patch and see if you have a nicer assert message and stacktrace now? > Sorry, that this is still not a fix for the real issue. > > diff --git a/cddl/contrib/opensolaris/head/assert.h > b/cddl/contrib/opensolaris/head/assert.h > index 394820a..c2a4936 100644 > --- a/cddl/contrib/opensolaris/head/assert.h > +++ b/cddl/contrib/opensolaris/head/assert.h > @@ -37,15 +37,7 @@ > extern "C" { > #endif > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -extern void __assert(const char *, const char *, int); > -#else > -extern void __assert(const char *, const char *, int); > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -extern void _assert(); > -#endif > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef __cplusplus > } > @@ -68,14 +60,6 @@ extern void _assert(); > > #else > > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define assert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define assert(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > +#define assert(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #endif /* NDEBUG */ > diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > index 7ae7f9d..631e302 100644 > --- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > +++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h > @@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list); > #define fm_panic panic > > /* This definition is copied from assert.h. */ > -#if defined(__STDC__) > -#if __STDC_VERSION__ - 0 >= 199901L > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#else > -#define verify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 0)) > -#endif /* __STDC_VERSION__ - 0 >= 199901L */ > -#else > -#define verify(EX) (void)((EX) || (_assert("EX", __FILE__, __LINE__), 0)) > -#endif /* __STDC__ */ > - > +#define verify(EX) (void)((EX) || (__assert(__func__, __FILE__, __LINE__, #EX), 0)) > > #define VERIFY verify > #define ASSERT assert > > -extern void __assert(const char *, const char *, int); > +extern void __assert(const char *, const char *, int, const char *); > > #ifdef lint > #define VERIFY3_IMPL(x, y, z, t) if (x == z) ((void)0) > @@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int); > (void) snprintf(__buf, 256, "%s %s %s (0x%llx %s 0x%llx)", \ > #LEFT, #OP, #RIGHT, \ > (u_longlong_t)__left, #OP, (u_longlong_t)__right); \ > - __assert(__buf, __FILE__, __LINE__); \ > + __assert(__func__, __FILE__, __LINE__, __buf); \ > } \ > _NOTE(CONSTCOND) } while (0) > /* END CSTYLED */ > > Here is the new bt after the patch [root@avoriaz libzpool]# gdb zdb 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"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100178] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100178)] [New Thread 0x801802240 (LWP 100345)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100346)] [New Thread 0x801802560 (LWP 100347)] [New Thread 0x8018026f0 (LWP 100348)] [New Thread 0x801802880 (LWP 100349)] [New Thread 0x801802a10 (LWP 100350)] [New Thread 0x801802ba0 (LWP 100351)] [New Thread 0x801802d30 (LWP 100352)] [New Thread 0x801802ec0 (LWP 100353)] [New Thread 0x801803050 (LWP 100354)] [New Thread 0x8018031e0 (LWP 100355)] [New Thread 0x801803370 (LWP 100356)] [New Thread 0x801803500 (LWP 100357)] [New Thread 0x801803690 (LWP 100358)] [New Thread 0x801803820 (LWP 100359)] [New Thread 0x8018039b0 (LWP 100360)] [New Thread 0x801803b40 (LWP 100361)] [New Thread 0x801803cd0 (LWP 100362)] [New Thread 0x801803e60 (LWP 100363)] [New Thread 0x801803ff0 (LWP 100364)] [New Thread 0x801804180 (LWP 100365)] [New Thread 0x801804310 (LWP 100366)] [New Thread 0x8018044a0 (LWP 100367)] [New Thread 0x801804630 (LWP 100368)] [New Thread 0x8018047c0 (LWP 100369)] [New Thread 0x801804950 (LWP 100370)] [New Thread 0x801804ae0 (LWP 100371)] Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Program received signal SIGABRT, Aborted. [Switching to Thread 0x8018020b0 (LWP 100178)] 0x000000080121fadc in thr_kill () from /lib/libc.so.7 (gdb) bt #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 #1 0x00000008012af06b in abort () from /lib/libc.so.7 #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c:112 #4 0x0000000801030287 in dsl_dataset_evict (db=Variable "db" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:266 #5 0x0000000801048b61 in dbuf_evict_user (db=0x8018ca960) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:215 #6 0x000000080104a8c3 in dbuf_rele (db=0x8018ca960, tag=Variable "tag" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1739 #7 0x0000000801029276 in dsl_pool_open (spa=0x8018a2000, txg=Variable "txg" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c:139 #8 0x000000080101d503 in spa_load (spa=0x8018a2000, config=Variable "config" is not available. ) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1134 #9 0x000000080101e060 in spa_open_common (pool=0x7fffffffed6e "pool1", spapp=0x7fffffffeb08, tag=0x40b790, config=0x0) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1474 #10 0x0000000000408b41 in ?? () #11 0x00000000004036de in ?? () #12 0x0000000800534000 in ?? () #13 0x0000000000000000 in ?? () #14 0x0000000000000002 in ?? () #15 0x00007fffffffed60 in ?? () #16 0x00007fffffffed6e in ?? () #17 0x0000000000000000 in ?? () #18 0x00007fffffffed74 in ?? () #19 0x00007fffffffed8a in ?? () #20 0x00007fffffffed95 in ?? () #21 0x00007fffffffedaf in ?? () #22 0x00007fffffffedda in ?? () #23 0x00007fffffffedf7 in ?? () #24 0x00007fffffffee0a in ?? () #25 0x00007fffffffee14 in ?? () #26 0x00007fffffffee1f in ?? () #27 0x00007fffffffee2b in ?? () #28 0x00007fffffffee40 in ?? () #29 0x00007fffffffee54 in ?? () #30 0x00007fffffffeeae in ?? () #31 0x00007fffffffeebd in ?? () #32 0x00007fffffffeec9 in ?? () #33 0x00007fffffffeee8 in ?? () #34 0x00007fffffffeef5 in ?? () #35 0x00007fffffffef0a in ?? () #36 0x00007fffffffef1c in ?? () #37 0x00007fffffffef25 in ?? () #38 0x00007fffffffef35 in ?? () #39 0x00007fffffffef3d in ?? () #40 0x00007fffffffef66 in ?? () #41 0x00007fffffffef73 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000000003 in ?? () #44 0x0000000000400040 in ?? () #45 0x0000000000000004 in ?? () #46 0x0000000000000038 in ?? () #47 0x0000000000000005 in ?? () #48 0x0000000000000007 in ?? () #49 0x0000000000000006 in ?? () #50 0x0000000000001000 in ?? () #51 0x0000000000000008 in ?? () #52 0x0000000000000000 in ?? () #53 0x0000000000000009 in ?? () #54 0x0000000000403650 in ?? () #55 0x0000000000000007 in ?? () #56 0x000000080050c000 in ?? () #57 0x0000000000000000 in ?? () ---Type to continue, or q to quit---q Quit (gdb) q The program is running. Exit anyway? (y or n) yes [root@avoriaz libzpool]# Henri From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 15:50:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02C3010657C2 for ; Mon, 1 Jun 2009 15:50:01 +0000 (UTC) (envelope-from bms@incunabulum.com) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C71618FC27 for ; Mon, 1 Jun 2009 15:49:59 +0000 (UTC) (envelope-from bms@incunabulum.com) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 8886B34C17A; Mon, 1 Jun 2009 11:30:44 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Mon, 01 Jun 2009 11:30:44 -0400 X-Sasl-enc: TebyRTTRtuXwYNKVt6Wn6rlpSCRqRbOHhKvEMOCtrs19 1243870243 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 03DD826891; Mon, 1 Jun 2009 11:30:42 -0400 (EDT) Message-ID: <4A23F421.8070809@incunabulum.com> Date: Mon, 01 Jun 2009 16:30:41 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: deeptech71@gmail.com References: <4A1DD57A.7010704@gmail.com> <4A1E9831.4010606@incunabulum.net> <4A1EC8FB.6090206@gmail.com> <4A1FBFF5.6090103@incunabulum.net> <4A20791D.5070209@gmail.com> <4A22E2F1.6070404@incunabulum.net> <4A2325F1.8010300@gmail.com> In-Reply-To: <4A2325F1.8010300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Jun 2009 16:12:39 +0000 Cc: freebsd-current@freebsd.org Subject: Re: panic: igmp_v3_dispatch_general_query: called when version 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 15:50:01 -0000 deeptech71@gmail.com wrote: >> >> Thanks. Can you please test this patch and let me know if it works >> for you? > > OK, applied, but what now? If you are sure that you have fixed the > bug, but just want me to run a "crash test" before commiting, then all > I can say is there's nothing wrong yet, I'll keep running the patch > until something comes up, like a panic (and report it). Otherwise I > can't test wether the patch does avoid the non-reproducable panic. I believe (without reproducing it) that the problem was igmp_v3_cancel_link_timers() not cancelling the v3 link timer in all situations. The panic you saw was due to a v3 timer firing even though the timer should have been cancelled by reception of the v2 query from your university's LAN router. The RFC could be worded better about how the 'Older Querier' timer is heeded -- on re-reading it makes sense not to flap between IGMP versions -- the oldest version in use on the link persists for up to 260s with the default protocol timers, only switching version after the timer expires is best as it provides some built-in hysteresis. It sounds like the fix is OK. Obviously, let me know if you see problems again, I've checked the patch into HEAD now. thanks, BMS From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:23:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DA110656DA; Mon, 1 Jun 2009 16:23:03 +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 355518FC1C; Mon, 1 Jun 2009 16:23:01 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08334; Mon, 01 Jun 2009 19:22:59 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A240063.207@freebsd.org> Date: Mon, 01 Jun 2009 19:22:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> In-Reply-To: <4A23FDE5.1040101@restart.be> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Kip Macy Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:23:04 -0000 on 01/06/2009 19:12 Henri Hennebert said the following: > Andriy Gapon wrote: >> I propose the following patch for this issue. >> It fixes mismatch between __assert extern declaration in zfs code and >> actual >> signature in libc code. >> I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. >> I think that >> those checks are not needed with compilers that can be used to compile >> FreeBSD. >> Besides, both branches of __STDC_VERSION__ check were exactly the same. >> >> Henri, >> >> if you still experience that crash of zpool command, could you please >> try the >> patch and see if you have a nicer assert message and stacktrace now? >> Sorry, that this is still not a fix for the real issue. >> > Here is the new bt after the patch Henri, thank you very much for testing! It look like the patch did its job. P.S. hopefully someone is looking into the cause of the assertion. > Assertion failed: (mp->m_owner == NULL), function zmutex_destroy, file > /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, > line 112. > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x8018020b0 (LWP 100178)] > 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x000000080121fadc in thr_kill () from /lib/libc.so.7 > #1 0x00000008012af06b in abort () from /lib/libc.so.7 > #2 0x0000000801296fe5 in __assert () from /lib/libc.so.7 > #3 0x0000000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:35:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8A61065676 for ; Mon, 1 Jun 2009 16:35:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B41A68FC18 for ; Mon, 1 Jun 2009 16:35:02 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 9922 invoked by uid 399); 1 Jun 2009 16:34:58 -0000 Received: from localhost (HELO ?192.168.0.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Jun 2009 16:34:58 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A240331.1000803@FreeBSD.org> Date: Mon, 01 Jun 2009 09:34:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andriy Gapon References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> In-Reply-To: <4A23F4B8.7000002@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:35:03 -0000 Andriy Gapon wrote: > on 01/06/2009 16:20 Andriy Gapon said the following: >> What about the following patch? >> I believe that the idea behind fsck_y_enable is to try to make unattended systems >> with rw filesystems as recoverable as possible at the cost of potential damage to >> the data. The new "-C" option should not interfere with this goal, but should >> reduce recovery time, because currently fsck -y checks *all* filesystems from >> fstab, even those that are ro or clean: >> >> -C Check if the “clean†flag is set in the superblock and skip file >> system checks if file system was properly dismounted and marked >> clean. >> > > One potential issue that I've just thought of is that fsck_msdosfs doesn't seem to > support this option (even in a dummy way), so it would be a problem for those who > have msdos filesystems in fstab and also have fsck_y_enable. I'm a bit concerned that we keep the current option as it is, but I would support adding an fsck_y_enable_flags option to allow people to pass -C if they are sure it will work in their environment. Doug From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:39:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493AB1065677 for ; Mon, 1 Jun 2009 16:39:02 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 77BB28FC13 for ; Mon, 1 Jun 2009 16:39:01 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm7 with SMTP id 7so1220194fxm.43 for ; Mon, 01 Jun 2009 09:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MWyUI61qrHgw9GClRYm5PZ8lCuRWr/mkA4uBxH+CY3g=; b=XsZSIOi5siqWxLLV4BiqXwtZO2pP/RSev+XF1xbnObIRYzdmW6dbI4I09hV+ObsGLS TU0xQbMGdduu0IxjXviPyn8R7aIK7maDVKJySFIHeG9UdZpbOPR9ExDpSKvHOu4KGyD+ yxLM7gWphOJgr5COzipYy5tshhKm/paiv3Fos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hQuajXNcXdvm/NK4HYHdVPRotO+xQT+uj1izEotH58tHfOLJ/4Kmt/SYWKxhFgMOch yGQJDiAgkbapLSfBrYqX3nty05yXf8vkcBW5rnxfzm+aMeku/Scqo1GXgtRZqMs2zTsm drm+txHnTe1Y+0zNlJd8odtSHCm55jp6H5Zs8= MIME-Version: 1.0 Received: by 10.204.112.11 with SMTP id u11mr5859457bkp.134.1243874340472; Mon, 01 Jun 2009 09:39:00 -0700 (PDT) In-Reply-To: <4A240331.1000803@FreeBSD.org> References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> Date: Mon, 1 Jun 2009 16:39:00 +0000 Message-ID: <3a142e750906010939t710f6abah286c8f23f54747ab@mail.gmail.com> From: "Paul B. Mahol" To: Doug Barton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:39:02 -0000 On 6/1/09, Doug Barton wrote: > Andriy Gapon wrote: >> on 01/06/2009 16:20 Andriy Gapon said the following: >>> What about the following patch? >>> I believe that the idea behind fsck_y_enable is to try to make unattend= ed >>> systems >>> with rw filesystems as recoverable as possible at the cost of potential >>> damage to >>> the data. The new "-C" option should not interfere with this goal, but >>> should >>> reduce recovery time, because currently fsck -y checks *all* filesystem= s >>> from >>> fstab, even those that are ro or clean: >>> >>> -C Check if the =93clean=94 flag is set in the superblock and skip= file >>> system checks if file system was properly dismounted and marked >>> clean. >>> >> >> One potential issue that I've just thought of is that fsck_msdosfs doesn= 't >> seem to >> support this option (even in a dummy way), so it would be a problem for >> those who >> have msdos filesystems in fstab and also have fsck_y_enable. > > I'm a bit concerned that we keep the current option as it is, but I > would support adding an fsck_y_enable_flags option to allow people to > pass -C if they are sure it will work in their environment. IMHO that solution is much better, considering there is "-t" & "-T" flag. --=20 Paul From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:48:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72BD3106566C for ; Mon, 1 Jun 2009 16:48:51 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 38B4A8FC15 for ; Mon, 1 Jun 2009 16:48:50 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n51GmoZ8049713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Jun 2009 09:48:50 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A240672.2050504@errno.com> Date: Mon, 01 Jun 2009 09:48:50 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Subject: HEADS UP: net80211 data structure changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:48:51 -0000 Some public-facing data structures have changed that may affect statistics reported until you recompile programs (like ifconfig). Drivers will likewise need rebuilding. Ideally this stuff would be hidden behind proper KPI's and be transparent to user apps. If someone is interested in working on that please contact me. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:53:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 099761065670; Mon, 1 Jun 2009 16:53:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swipnet.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2FE8FC14; Mon, 1 Jun 2009 16:53:26 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=glm44wUnIQYA:10 a=yUlx0E-WNWoA:10 a=8jtV6kty40S9m3uVcjgA:9 a=dd9q3UaPiirgIEU254UadbpfZWEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 504695822; Mon, 01 Jun 2009 17:53:23 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 1 Jun 2009 17:57:31 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906011757.31908.hselasky@c2i.net> Cc: Robert Watson , current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:53:27 -0000 On Monday 01 June 2009, Robert Watson wrote: > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. In practice, most behavior remains identical > in the default configuration (direct dispatch, single netisr thread that's > not bound to a CPU, etc), but people will want to watch out for problems. > Some default queue limits have been raised. > > More functional changes to take advantage of these features, such as > deferred ethernet dispatch and software flow ID generation, will follow as > patches, but probably not ship in 8.0 out of the box. > Hi, Having WITNESS and INVARIANTS in the kernel config I get a panic about a NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 has been properly setup. CPU: 2-HTT Workaround: net.isr.direct=0 net.isr.direct_force=0 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:56:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F10EA1065689; Mon, 1 Jun 2009 16:56:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CC02C8FC18; Mon, 1 Jun 2009 16:56:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5D57546B2D; Mon, 1 Jun 2009 12:56:46 -0400 (EDT) Date: Mon, 1 Jun 2009 17:56:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200906011757.31908.hselasky@c2i.net> Message-ID: References: <200906011757.31908.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:56:48 -0000 On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT Could you provide the trap information and a backtrace? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 16:56:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F10EA1065689; Mon, 1 Jun 2009 16:56:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CC02C8FC18; Mon, 1 Jun 2009 16:56:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5D57546B2D; Mon, 1 Jun 2009 12:56:46 -0400 (EDT) Date: Mon, 1 Jun 2009 17:56:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200906011757.31908.hselasky@c2i.net> Message-ID: References: <200906011757.31908.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 16:56:48 -0000 On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT Could you provide the trap information and a backtrace? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 17:11:03 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73793106566C for ; Mon, 1 Jun 2009 17:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 5B5A88FC08 for ; Mon, 1 Jun 2009 17:11:03 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 1DF70D1D8A; Mon, 1 Jun 2009 10:11:03 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id D8BFA2D6013; Mon, 1 Jun 2009 10:11:02 -0700 (PDT) Message-ID: <4A240BA6.4010805@elischer.org> Date: Mon, 01 Jun 2009 10:11:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 17:11:03 -0000 Robert Watson wrote: > > As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > implementation there as part of on-going work to improve network stack > parallelism, details below. does this mean you are departing immediately on a 4 week safari with no network? :-) From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 17:35:56 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D12E1065706 for ; Mon, 1 Jun 2009 17:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57ED98FC12 for ; Mon, 1 Jun 2009 17:35:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EC6E746B23; Mon, 1 Jun 2009 13:35:55 -0400 (EDT) Date: Mon, 1 Jun 2009 18:35:55 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4A240BA6.4010805@elischer.org> Message-ID: References: <4A240BA6.4010805@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 17:35:57 -0000 On Mon, 1 Jun 2009, Julian Elischer wrote: > Robert Watson wrote: > >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. > > does this mean you are departing immediately on a 4 week safari with no > network? :-) The great thing about network stack changes is that you can ensure there's no network :-). Robert From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 18:20:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D72C106566C for ; Mon, 1 Jun 2009 18:20:14 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id B4BC78FC14 for ; Mon, 1 Jun 2009 18:20:13 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 8CB8F1CC31; Mon, 1 Jun 2009 20:20:12 +0200 (CEST) Date: Mon, 1 Jun 2009 20:20:12 +0200 From: Michael Moll To: freebsd-current@freebsd.org Message-ID: <20090601182012.GA21543@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 18:20:14 -0000 Hi, I'm getting the following crash on the NFS server with -CURRENT (r193229) as soon as I try to access a file on a ZFS filesystem via NFS: #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0x80562773 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0x8056297e in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0x807b488c in trap_fatal (frame=0xfcc95718, eva=1660) at /usr/src/sys/i386/i386/trap.c:933 #4 0x807b4af0 in trap_pfault (frame=0xfcc95718, usermode=0, eva=1660) at /usr/src/sys/i386/i386/trap.c:846 #5 0x807b5492 in trap (frame=0xfcc95718) at /usr/src/sys/i386/i386/trap.c:528 #6 0x8079ceeb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0x8053d1bd in prison_priv_check (cred=0x85fe7000, priv=334) at /usr/src/sys/kern/kern_jail.c:3315 #8 0x8055631e in priv_check_cred (cred=0x85fe7000, priv=334, flags=0) at /usr/src/sys/kern/kern_priv.c:93 #9 0x8514412c in secpolicy_fs_owner () from /boot/kernel/zfs.ko #10 0x85144657 in secpolicy_vnode_access () from /boot/kernel/zfs.ko #11 0x851bfc5b in zfs_zaccess () from /boot/kernel/zfs.ko #12 0x851bfeeb in zfs_zaccess_rwx () from /boot/kernel/zfs.ko #13 0x851d55a4 in zfs_freebsd_access () from /boot/kernel/zfs.ko #14 0x807bf282 in VOP_ACCESS_APV (vop=0x85238640, a=0xfcc958cc) at vnode_if.c:571 #15 0x806e8057 in nfsrv_access (vp=0x80, accmode=-2062450688, cred=0x85fe7000, rdonly=0, override=0) at vnode_if.h:254 #16 0x806e87f1 in nfsrv3_access (nfsd=0xfcc95a9c, slp=0x0, mrq=0xfcc95a94) at /usr/src/sys/nfsserver/nfs_serv.c:238 #17 0x806f65a5 in nfssvc_program (rqst=0x86080800, xprt=0x85fe9e00) at /usr/src/sys/nfsserver/nfs_srvkrpc.c:410 #18 0x8071658f in svc_run_internal (pool=0x84d9e500, ismaster=1) at /usr/src/sys/rpc/svc.c:883 #19 0x807173fd in svc_run (pool=0x84d9e500) at /usr/src/sys/rpc/svc.c:1223 #20 0x806f5f6d in nfssvc_nfsd (td=Variable "td" is not available. ) at /usr/src/sys/nfsservc.c:199 #22 0x806f8158 in nfssvc (td=0x8549fb40, uap=0xfcc95cf8) at /usr/src/sys/nfs/nfs_nfssvc.c:90 #23 0x807b4e35 in syscall (frame=0xfcc95d38) at /usr/src/sys/i386/i386/trap.c:1073 #24 0x8079cf50 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #25 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Any ideas on this one? -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 18:41:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B2E106570D; Mon, 1 Jun 2009 18:41:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 906978FC1E; Mon, 1 Jun 2009 18:41:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 34C6046B39; Mon, 1 Jun 2009 14:41:46 -0400 (EDT) Date: Mon, 1 Jun 2009 19:41:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200906011757.31908.hselasky@c2i.net> Message-ID: References: <200906011757.31908.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 18:41:47 -0000 On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT This should be fixed in r193243. I made a change shortly before merging that locks the current CPU's workstream before billing packets to it when direct dispatching, and this turns out to be incorrect, as on systems with fewer workers than CPUs, then we lock an uninitialized mutex. Let me know if the above change doesn't fix it. Robert N M Watson Computer Laboratory University of Cambridge > > Workaround: > > net.isr.direct=0 > net.isr.direct_force=0 > > --HPS > From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 18:41:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B2E106570D; Mon, 1 Jun 2009 18:41:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 906978FC1E; Mon, 1 Jun 2009 18:41:46 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 34C6046B39; Mon, 1 Jun 2009 14:41:46 -0400 (EDT) Date: Mon, 1 Jun 2009 19:41:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200906011757.31908.hselasky@c2i.net> Message-ID: References: <200906011757.31908.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 18:41:47 -0000 On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > On Monday 01 June 2009, Robert Watson wrote: >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR >> implementation there as part of on-going work to improve network stack >> parallelism, details below. In practice, most behavior remains identical >> in the default configuration (direct dispatch, single netisr thread that's >> not bound to a CPU, etc), but people will want to watch out for problems. >> Some default queue limits have been raised. >> >> More functional changes to take advantage of these features, such as >> deferred ethernet dispatch and software flow ID generation, will follow as >> patches, but probably not ship in 8.0 out of the box. > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > has been properly setup. CPU: 2-HTT This should be fixed in r193243. I made a change shortly before merging that locks the current CPU's workstream before billing packets to it when direct dispatching, and this turns out to be incorrect, as on systems with fewer workers than CPUs, then we lock an uninitialized mutex. Let me know if the above change doesn't fix it. Robert N M Watson Computer Laboratory University of Cambridge > > Workaround: > > net.isr.direct=0 > net.isr.direct_force=0 > > --HPS > From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 19:19:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 690A4106566B; Mon, 1 Jun 2009 19:19:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2F24A8FC24; Mon, 1 Jun 2009 19:19:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n51JJOhW054462; Mon, 1 Jun 2009 15:19:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n51JJOcr020574; Mon, 1 Jun 2009 15:19:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4E21C7302F; Mon, 1 Jun 2009 15:19:24 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090601191924.4E21C7302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 15:19:24 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:19:28 -0000 TB --- 2009-06-01 17:49:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 17:49:26 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-01 17:49:26 - cleaning the object tree TB --- 2009-06-01 17:50:00 - cvsupping the source tree TB --- 2009-06-01 17:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-01 17:50:11 - building world TB --- 2009-06-01 17:50:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 17:50:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 17:50:11 - TARGET=sun4v TB --- 2009-06-01 17:50:11 - TARGET_ARCH=sparc64 TB --- 2009-06-01 17:50:11 - TZ=UTC TB --- 2009-06-01 17:50:11 - __MAKE_CONF=/dev/null TB --- 2009-06-01 17:50:11 - cd /src TB --- 2009-06-01 17:50:11 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 17:50:14 UTC 2009 >>> 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 Mon Jun 1 19:04:25 UTC 2009 TB --- 2009-06-01 19:04:25 - generating LINT kernel config TB --- 2009-06-01 19:04:25 - cd /src/sys/sun4v/conf TB --- 2009-06-01 19:04:25 - /usr/bin/make -B LINT TB --- 2009-06-01 19:04:25 - building LINT kernel TB --- 2009-06-01 19:04:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 19:04:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 19:04:25 - TARGET=sun4v TB --- 2009-06-01 19:04:25 - TARGET_ARCH=sparc64 TB --- 2009-06-01 19:04:25 - TZ=UTC TB --- 2009-06-01 19:04:25 - __MAKE_CONF=/dev/null TB --- 2009-06-01 19:04:25 - cd /src TB --- 2009-06-01 19:04:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 1 19:04:25 UTC 2009 >>> 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 -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -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 -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/sun4v/sun4v/hcall.S 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 -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/sun4v/sun4v/hviommu.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 -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/sparc64/sparc64/identcpu.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 -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/sparc64/sparc64/in_cksum.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 -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/sun4v/sun4v/intr_machdep.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 -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 19:19:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 19:19:24 - ERROR: failed to build lint kernel TB --- 2009-06-01 19:19:24 - 4649.84 user 424.29 system 5397.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:10:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7F23106566B for ; Mon, 1 Jun 2009 20:10:54 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE268FC16 for ; Mon, 1 Jun 2009 20:10:53 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=glm44wUnIQYA:10 a=yUlx0E-WNWoA:10 a=kd82vJRRX1Oyphn-8z4A:9 a=1pskUioQH6dtMnrVGHYA:7 a=-fwqlh3ONPwQkAsdr79hbHeIMAEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1251419348; Mon, 01 Jun 2009 22:10:52 +0200 From: Hans Petter Selasky To: Robert Watson Date: Mon, 1 Jun 2009 22:15:00 +0200 User-Agent: KMail/1.9.7 References: <200906011757.31908.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906012215.01494.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: New NETISR implementation, but same defaults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:10:55 -0000 On Monday 01 June 2009, Robert Watson wrote: > On Mon, 1 Jun 2009, Hans Petter Selasky wrote: > > On Monday 01 June 2009, Robert Watson wrote: > >> As a HEADS up to 8-CURRENT followers: I've replaced the NETISR > >> implementation there as part of on-going work to improve network stack > >> parallelism, details below. In practice, most behavior remains > >> identical in the default configuration (direct dispatch, single netisr > >> thread that's not bound to a CPU, etc), but people will want to watch > >> out for problems. Some default queue limits have been raised. > >> > >> More functional changes to take advantage of these features, such as > >> deferred ethernet dispatch and software flow ID generation, will follow > >> as patches, but probably not ship in 8.0 out of the box. > > > > Having WITNESS and INVARIANTS in the kernel config I get a panic about a > > NULL mutex when running "dhclient wlan0". Prior to running dhclient wlan0 > > has been properly setup. CPU: 2-HTT > > This should be fixed in r193243. I made a change shortly before merging > that locks the current CPU's workstream before billing packets to it when > direct dispatching, and this turns out to be incorrect, as on systems with > fewer workers than CPUs, then we lock an uninitialized mutex. Let me know > if the above change doesn't fix it. Ok. BTW: I'm booted on a USB harddisk (USB2) and it does not support dump on USB disk yet. I will check if your r193243 does not fix it. Thanks. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:36:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46310106568A; Mon, 1 Jun 2009 20:36:31 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 20B818FC1D; Mon, 1 Jun 2009 20:36:31 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEFA-000H4M-1E; Mon, 01 Jun 2009 20:36:28 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 841E61D14AAE; Tue, 2 Jun 2009 05:36:27 +0900 (JST) Date: Tue, 02 Jun 2009 05:36:27 +0900 Message-ID: From: Randy Bush To: Eygene Ryabinkin In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:36:32 -0000 >> gencat is installed. it is whining that it can not find the file > > May be gencat is installed, but 'make install' could not find it: > message "gencat:No such file or directory" comes from make, not > from gencat itself. > > Will you be able to run 'make clean; make; make install' from > /usr/src/usr.bin/ee to see if the problem is specific to the 'make > installworld' or shows even for manual installation? work0.psg.com:/usr/src# cd /usr/src/usr.bin/ee/ work0.psg.com:/usr/src/usr.bin/ee# make clean rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz work0.psg.com:/usr/src/usr.bin/ee# make make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop whack! now i need to find some place from which i can recover it randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:46:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50331065679; Mon, 1 Jun 2009 20:46:15 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 800298FC18; Mon, 1 Jun 2009 20:46:15 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 528FA1CF77; Mon, 1 Jun 2009 22:46:14 +0200 (CEST) Date: Mon, 1 Jun 2009 22:46:14 +0200 From: Ed Schouten To: Randy Bush Message-ID: <20090601204614.GM48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9uDGw67+9J53IzxX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Eygene Ryabinkin , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:46:16 -0000 --9uDGw67+9J53IzxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Randy Bush wrote: > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop Can you give me the $FreeBSD$ tag of the Makefile? It should be (when using SVN): $FreeBSD: head/usr.bin/ee/Makefile 192914 2009-05-27 17:27:03Z ed $ --=20 Ed Schouten WWW: http://80386.nl/ --9uDGw67+9J53IzxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkokPhYACgkQ52SDGA2eCwUTwQCeKNIF0U80J2p3bWSbfFDDRPJd H10AnA0r0Xa6GRFvwhbrR3OWakM7/dya =nECP -----END PGP SIGNATURE----- --9uDGw67+9J53IzxX-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:49:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 206F4106567E; Mon, 1 Jun 2009 20:49:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id EE52B8FC0C; Mon, 1 Jun 2009 20:49:13 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBERV-000H6h-6z; Mon, 01 Jun 2009 20:49:13 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id ADD191D15E51; Tue, 2 Jun 2009 05:49:12 +0900 (JST) Date: Tue, 02 Jun 2009 05:49:12 +0900 Message-ID: From: Randy Bush To: Eygene Ryabinkin In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:49:14 -0000 >>> gencat is installed. it is whining that it can not find the file >> >> May be gencat is installed, but 'make install' could not find it: >> message "gencat:No such file or directory" comes from make, not >> from gencat itself. >> >> Will you be able to run 'make clean; make; make install' from >> /usr/src/usr.bin/ee to see if the problem is specific to the 'make >> installworld' or shows even for manual installation? > work0.psg.com:/usr/src# cd /usr/src/usr.bin/ee/ > work0.psg.com:/usr/src/usr.bin/ee# make clean > rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz > work0.psg.com:/usr/src/usr.bin/ee# make > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop recovered data ran just make install work0.psg.com:/usr/src/usr.bin/ee# make install install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg install -o root -g wheel -m 444 en_US.US-ASCII.cat /usr/share/nls/en_US.US-ASCII/ee.cat cat /usr/src/usr.bin/ee/nls/fr_FR.ISO8859-1/ee.msg > fr_FR.ISO8859-1.msg gencat fr_FR.ISO8859-1.cat fr_FR.ISO8859-1.msg install -o root -g wheel -m 444 fr_FR.ISO8859-1.cat /usr/share/nls/fr_FR.ISO8859-1/ee.cat cat /usr/src/usr.bin/ee/nls/de_DE.ISO8859-1/ee.msg > de_DE.ISO8859-1.msg gencat de_DE.ISO8859-1.cat de_DE.ISO8859-1.msg install -o root -g wheel -m 444 de_DE.ISO8859-1.cat /usr/share/nls/de_DE.ISO8859-1/ee.cat cat /usr/src/usr.bin/ee/nls/pl_PL.ISO8859-2/ee.msg > pl_PL.ISO8859-2.msg gencat pl_PL.ISO8859-2.cat pl_PL.ISO8859-2.msg install -o root -g wheel -m 444 pl_PL.ISO8859-2.cat /usr/share/nls/pl_PL.ISO8859-2/ee.cat cat /usr/src/usr.bin/ee/nls/uk_UA.KOI8-U/ee.msg > uk_UA.KOI8-U.msg gencat uk_UA.KOI8-U.cat uk_UA.KOI8-U.msg install -o root -g wheel -m 444 uk_UA.KOI8-U.cat /usr/share/nls/uk_UA.KOI8-U/ee.cat cat /usr/src/usr.bin/ee/nls/ru_RU.KOI8-R/ee.msg > ru_RU.KOI8-R.msg gencat ru_RU.KOI8-R.cat ru_RU.KOI8-R.msg install -o root -g wheel -m 444 ru_RU.KOI8-R.cat /usr/share/nls/ru_RU.KOI8-R/ee.cat install -o root -g wheel -m 444 ee.1.gz /usr/share/man/man1 /usr/share/man/man1/ree.1.gz -> /usr/share/man/man1/ee.1.gz /usr/share/man/man1/edit.1.gz -> /usr/share/man/man1/ee.1.gz /usr/bin/ree -> /usr/bin/ee /usr/bin/edit -> /usr/bin/ee /usr/share/nls/en_US.ISO8859-1/ee.cat -> ../en_US.US-ASCII/ee.cat /usr/share/nls/en_US.ISO8859-15/ee.cat -> ../en_US.US-ASCII/ee.cat /usr/share/nls/fr_BE.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_BE.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CA.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CA.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CH.ISO8859-1/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_CH.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/fr_FR.ISO8859-15/ee.cat -> ../fr_FR.ISO8859-1/ee.cat /usr/share/nls/de_AT.ISO8859-1/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_AT.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_CH.ISO8859-1/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_CH.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat /usr/share/nls/de_DE.ISO8859-15/ee.cat -> ../de_DE.ISO8859-1/ee.cat looks successful to me randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:50:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C66221065674; Mon, 1 Jun 2009 20:50:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A5CE98FC1C; Mon, 1 Jun 2009 20:50:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBET3-000H75-Jd; Mon, 01 Jun 2009 20:50:49 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 18A541D160E2; Tue, 2 Jun 2009 05:50:49 +0900 (JST) Date: Tue, 02 Jun 2009 05:50:49 +0900 Message-ID: From: Randy Bush To: Ed Schouten In-Reply-To: <20090601204614.GM48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601204614.GM48776@hoeg.nl> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Eygene Ryabinkin , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:50:59 -0000 >> make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop > Can you give me the $FreeBSD$ tag of the Makefile? It should be (when > using SVN): > $FreeBSD: head/usr.bin/ee/Makefile 192914 2009-05-27 17:27:03Z ed $ # $FreeBSD: src/usr.bin/ee/Makefile,v 1.26 2009/05/27 17:27:03 ed Exp $ From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 20:59:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70884106564A; Mon, 1 Jun 2009 20:59:13 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 31F708FC12; Mon, 1 Jun 2009 20:59:13 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 764461CF77; Mon, 1 Jun 2009 22:59:12 +0200 (CEST) Date: Mon, 1 Jun 2009 22:59:12 +0200 From: Ed Schouten To: Randy Bush Message-ID: <20090601205912.GN48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NiDZvZUadYKQfYjZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Eygene Ryabinkin , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 20:59:13 -0000 --NiDZvZUadYKQfYjZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Randy Bush wrote: > recovered data >=20 > ran just make install >=20 > work0.psg.com:/usr/src/usr.bin/ee# make install > So it's false alarm? Phew. :-) --=20 Ed Schouten WWW: http://80386.nl/ --NiDZvZUadYKQfYjZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkokQSAACgkQ52SDGA2eCwWsJwCfX1eNL7jZQruXLcaqmnZfJiU/ 2RYAnjHzo7x6euQui+h210FeCqLzSyqw =Oegn -----END PGP SIGNATURE----- --NiDZvZUadYKQfYjZ-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 21:15:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E72D1065689; Mon, 1 Jun 2009 21:15:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3268FC17; Mon, 1 Jun 2009 21:15:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBEqY-000H9Q-St; Mon, 01 Jun 2009 21:15:07 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 601C41D1887B; Tue, 2 Jun 2009 06:15:06 +0900 (JST) Date: Tue, 02 Jun 2009 06:15:06 +0900 Message-ID: From: Randy Bush To: Ed Schouten In-Reply-To: <20090601205912.GN48776@hoeg.nl> References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Eygene Ryabinkin , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Jun 2009 21:15:09 -0000 >> ran just make install >> work0.psg.com:/usr/src/usr.bin/ee# make install >> > So it's false alarm? Phew. :-) not false, just different. like what is killing the install? this is on two systems, and i am now afraid of updating anything. randy From owner-freebsd-current@FreeBSD.ORG Mon Jun 1 23:51:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BA63106564A; Mon, 1 Jun 2009 23:51:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F02A28FC0A; Mon, 1 Jun 2009 23:51:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n51NpFMf093916; Mon, 1 Jun 2009 19:51:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n51NpFuG041671; Mon, 1 Jun 2009 19:51:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 673C07302F; Mon, 1 Jun 2009 19:51:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090601235115.673C07302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 19:51:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 23:51:18 -0000 TB --- 2009-06-01 22:18:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-01 22:18:15 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-01 22:18:15 - cleaning the object tree TB --- 2009-06-01 22:18:52 - cvsupping the source tree TB --- 2009-06-01 22:18:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-01 22:19:06 - building world TB --- 2009-06-01 22:19:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 22:19:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 22:19:06 - TARGET=pc98 TB --- 2009-06-01 22:19:06 - TARGET_ARCH=i386 TB --- 2009-06-01 22:19:06 - TZ=UTC TB --- 2009-06-01 22:19:06 - __MAKE_CONF=/dev/null TB --- 2009-06-01 22:19:06 - cd /src TB --- 2009-06-01 22:19:06 - /usr/bin/make -B buildworld >>> World build started on Mon Jun 1 22:19:08 UTC 2009 >>> 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 Mon Jun 1 23:42:40 UTC 2009 TB --- 2009-06-01 23:42:40 - generating LINT kernel config TB --- 2009-06-01 23:42:40 - cd /src/sys/pc98/conf TB --- 2009-06-01 23:42:40 - /usr/bin/make -B LINT TB --- 2009-06-01 23:42:40 - building LINT kernel TB --- 2009-06-01 23:42:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-01 23:42:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-01 23:42:40 - TARGET=pc98 TB --- 2009-06-01 23:42:40 - TARGET_ARCH=i386 TB --- 2009-06-01 23:42:40 - TZ=UTC TB --- 2009-06-01 23:42:40 - __MAKE_CONF=/dev/null TB --- 2009-06-01 23:42:40 - cd /src TB --- 2009-06-01 23:42:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 1 23:42:40 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-01 23:51:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-01 23:51:15 - ERROR: failed to build lint kernel TB --- 2009-06-01 23:51:15 - 4275.75 user 438.17 system 5580.19 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 00:03:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D456D106566C for ; Tue, 2 Jun 2009 00:03:30 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDC48FC14 for ; Tue, 2 Jun 2009 00:03:30 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id A647D14D6004 for ; Tue, 2 Jun 2009 02:03:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k8GOz8nkyQ-Z for ; Tue, 2 Jun 2009 02:03:28 +0200 (CEST) Received: from [192.168.1.105] (catv-80-98-231-64.catv.broadband.hu [80.98.231.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 47B6414D5508 for ; Tue, 2 Jun 2009 02:03:28 +0200 (CEST) Message-ID: <4A246C4D.6080409@FreeBSD.org> Date: Tue, 02 Jun 2009 02:03:25 +0200 From: Gabor Kovesdan User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RFC: Replacing bc/dc to BSDL versions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 00:03:31 -0000 Hello, as you might know, I'm working on a BSDL grep. It isn't totally ready yet, because there are compatibility issues, which I have to resolve. But looking at another BSDL tools, I've found out that OpenBSD has BSDL bc and dc utilities. I've thought of replacing them. I think in the bc/dc case, such a strict GNU compatibility isn't necessary as in the case of grep, so we may replace them in base system. If there's no objection to replacing them, I'll post a patch for review. Cheers, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 02:32:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5AC106564A; Tue, 2 Jun 2009 02:32:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AE20C8FC29; Tue, 2 Jun 2009 02:32:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n522WtdM006411; Mon, 1 Jun 2009 22:32:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n522WtN2075651; Mon, 1 Jun 2009 22:32:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0F3747302F; Mon, 1 Jun 2009 22:32:54 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602023255.0F3747302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 22:32:54 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 02:32:59 -0000 TB --- 2009-06-02 00:58:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 00:58:34 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-02 00:58:34 - cleaning the object tree TB --- 2009-06-02 00:58:57 - cvsupping the source tree TB --- 2009-06-02 00:58:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-02 00:59:11 - building world TB --- 2009-06-02 00:59:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 00:59:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 00:59:11 - TARGET=powerpc TB --- 2009-06-02 00:59:11 - TARGET_ARCH=powerpc TB --- 2009-06-02 00:59:11 - TZ=UTC TB --- 2009-06-02 00:59:11 - __MAKE_CONF=/dev/null TB --- 2009-06-02 00:59:11 - cd /src TB --- 2009-06-02 00:59:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 00:59:13 UTC 2009 >>> 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 Tue Jun 2 02:25:35 UTC 2009 TB --- 2009-06-02 02:25:35 - generating LINT kernel config TB --- 2009-06-02 02:25:35 - cd /src/sys/powerpc/conf TB --- 2009-06-02 02:25:35 - /usr/bin/make -B LINT TB --- 2009-06-02 02:25:35 - building LINT kernel TB --- 2009-06-02 02:25:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 02:25:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 02:25:35 - TARGET=powerpc TB --- 2009-06-02 02:25:35 - TARGET_ARCH=powerpc TB --- 2009-06-02 02:25:35 - TZ=UTC TB --- 2009-06-02 02:25:35 - __MAKE_CONF=/dev/null TB --- 2009-06-02 02:25:35 - cd /src TB --- 2009-06-02 02:25:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 02:25:35 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 02:32:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 02:32:54 - ERROR: failed to build lint kernel TB --- 2009-06-02 02:32:54 - 4436.53 user 413.77 system 5660.60 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 02:51:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB84106566B for ; Tue, 2 Jun 2009 02:51:41 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 177B18FC1B for ; Tue, 2 Jun 2009 02:51:40 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n522pekA083488 for ; Mon, 1 Jun 2009 21:51:40 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=YjEnlC/0yKpO78El2WoH5Hd2Ho7Ee/kelgVWXB/JxfGaspASykdCuMtP/BHSN5rKz BPuPPG+yKfph2qcIQVkl7XGynGUcLAk4vCG+FQZKiBl5BHtmMJi6T+Qz3HgmGXGhnRr Q0oUHKdsroMnGretWVy8sWPOVDO7qkl6snamZO8= Message-ID: <4A2493BC.8020905@jrv.org> Date: Mon, 01 Jun 2009 21:51:40 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: SATA port multipliers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 02:51:41 -0000 With this change (and other previously reported & PR'd patches) SATA port multipliers seem to be working for me, albeit half as fast as expected. The ata_identify() call was commented out in February apparently due to other problems it caused but it appears to be the only thing that scans for drives behind an enclosure. Index: sys/dev/ata/ata-all.c =================================================================== --- sys/dev/ata/ata-all.c (revision 192136) +++ sys/dev/ata/ata-all.c (working copy) @@ -291,7 +291,7 @@ ATA_LOCKING(dev, ATA_LF_UNLOCK); /* Add new children. */ -/* ata_identify(dev); */ + ata_identify(dev); if (bootverbose) device_printf(dev, "reinit done ..\n"); From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 03:09:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 398BD106566C for ; Tue, 2 Jun 2009 03:09:03 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA1E8FC17 for ; Tue, 2 Jun 2009 03:09:02 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n522XIsw083083; Mon, 1 Jun 2009 21:33:18 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=wH4xwykDHrnLMli60QaBAbBmUJbvpODldLT0/8hRLxecIyPj7/euHEjVFVYeneMp0 ER6QQaa+l0rXRiokXd9ExUSUfoNP6Fm4/xhbdZcpi4hpF4vsqVorT4CcoXRPtUAM2zs TkwA8g+Xjh5Sl8cDbOknkhqc1baiYL0jImC2cYo= Message-ID: <4A248F6E.5020701@jrv.org> Date: Mon, 01 Jun 2009 21:33:18 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Thomas Backman References: <4E6E325D-BB18-4478-BCFD-633D6F4CFD88@exscape.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Freddie Cash Subject: Re: ZFS panic under extreme circumstances (2/3 disks corrupted) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 03:09:03 -0000 Thomas Backman wrote: > I have another unfortunate thing to note regarding this: after a > reboot, it's even impossible to tell *which disk* has gone bad, even > if the pool is "uncleared" but otherwise "healed". It simply says that > a device has failed, with no clue as to which one, since they're all > "ONLINE"! Is there anything recorded in the pool history log about this? The pool errlog is documented to be rotated after every scrub. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 03:24:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B495106564A; Tue, 2 Jun 2009 03:24:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0128FC0C; Tue, 2 Jun 2009 03:24:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n523OdY4012052; Mon, 1 Jun 2009 23:24:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n523OdIw078490; Mon, 1 Jun 2009 23:24:39 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A6F8F7302F; Mon, 1 Jun 2009 23:24:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602032439.A6F8F7302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 23:24:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:24:43 -0000 TB --- 2009-06-02 01:53:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 01:53:56 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-02 01:53:56 - cleaning the object tree TB --- 2009-06-02 01:54:26 - cvsupping the source tree TB --- 2009-06-02 01:54:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-02 01:54:38 - building world TB --- 2009-06-02 01:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 01:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 01:54:38 - TARGET=sparc64 TB --- 2009-06-02 01:54:38 - TARGET_ARCH=sparc64 TB --- 2009-06-02 01:54:38 - TZ=UTC TB --- 2009-06-02 01:54:38 - __MAKE_CONF=/dev/null TB --- 2009-06-02 01:54:38 - cd /src TB --- 2009-06-02 01:54:38 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 01:54:39 UTC 2009 >>> 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 Tue Jun 2 03:16:26 UTC 2009 TB --- 2009-06-02 03:16:26 - generating LINT kernel config TB --- 2009-06-02 03:16:26 - cd /src/sys/sparc64/conf TB --- 2009-06-02 03:16:26 - /usr/bin/make -B LINT TB --- 2009-06-02 03:16:26 - building LINT kernel TB --- 2009-06-02 03:16:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 03:16:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 03:16:26 - TARGET=sparc64 TB --- 2009-06-02 03:16:26 - TARGET_ARCH=sparc64 TB --- 2009-06-02 03:16:26 - TZ=UTC TB --- 2009-06-02 03:16:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 03:16:26 - cd /src TB --- 2009-06-02 03:16:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 03:16:26 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 03:24:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 03:24:39 - ERROR: failed to build lint kernel TB --- 2009-06-02 03:24:39 - 4214.37 user 413.52 system 5443.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 03:59:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59CE4106564A; Tue, 2 Jun 2009 03:59:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 19F698FC1B; Tue, 2 Jun 2009 03:59:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n523xJ5G017670; Mon, 1 Jun 2009 23:59:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n523xJnr050659; Mon, 1 Jun 2009 23:59:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5E0687302F; Mon, 1 Jun 2009 23:59:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602035919.5E0687302F@freebsd-current.sentex.ca> Date: Mon, 1 Jun 2009 23:59:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 03:59:23 -0000 TB --- 2009-06-02 02:32:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 02:32:55 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 02:32:55 - cleaning the object tree TB --- 2009-06-02 02:33:34 - cvsupping the source tree TB --- 2009-06-02 02:33:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 02:33:44 - building world TB --- 2009-06-02 02:33:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 02:33:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 02:33:44 - TARGET=sun4v TB --- 2009-06-02 02:33:44 - TARGET_ARCH=sparc64 TB --- 2009-06-02 02:33:44 - TZ=UTC TB --- 2009-06-02 02:33:44 - __MAKE_CONF=/dev/null TB --- 2009-06-02 02:33:44 - cd /src TB --- 2009-06-02 02:33:44 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 02:33:45 UTC 2009 >>> 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 Tue Jun 2 03:52:26 UTC 2009 TB --- 2009-06-02 03:52:26 - generating LINT kernel config TB --- 2009-06-02 03:52:26 - cd /src/sys/sun4v/conf TB --- 2009-06-02 03:52:26 - /usr/bin/make -B LINT TB --- 2009-06-02 03:52:26 - building LINT kernel TB --- 2009-06-02 03:52:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 03:52:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 03:52:26 - TARGET=sun4v TB --- 2009-06-02 03:52:26 - TARGET_ARCH=sparc64 TB --- 2009-06-02 03:52:26 - TZ=UTC TB --- 2009-06-02 03:52:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 03:52:26 - cd /src TB --- 2009-06-02 03:52:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 03:52:26 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 03:59:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 03:59:19 - ERROR: failed to build lint kernel TB --- 2009-06-02 03:59:19 - 4193.07 user 412.66 system 5184.16 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 04:20:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DA811065670 for ; Tue, 2 Jun 2009 04:20:30 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id E98738FC1C for ; Tue, 2 Jun 2009 04:20:29 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: by qyk3 with SMTP id 3so11746527qyk.3 for ; Mon, 01 Jun 2009 21:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:from:to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=5ICQL9rNkjHOegSvxTvd/SARm79szdo3prDq5bVID+8=; b=wSuNT+UxYsKJ9SjN07VsAdgcyNFlfP1j40khZ9+bO4Bi/mjx3kO41X4xKOVkOLCfgq uHimEfcUfUjN05hfyWOSuSgUTEc+XkUeRq/3HTmZXla+7WlDj0dq//ceShfDP5uFEPIr Idh1QcbchhuHJvfaQCAKzlH3KhYiqz2411omQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:from:to:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=WvOD7dUQxB+MSWl7ifbzbZZ1BHC8jPwqlAM49JFPQ7iEUG94jWP/XnwCESONqzAZ+s WSeqwbH3ahN62CTukLn4W4lgTmdsjhqTuZN3IBoxFe7tdsZ31AvWlVr+RjGFvNe/XVa2 B42WSCa+iZwJEW1B2S7J7b+zThsZM6ieEivDs= Received: by 10.224.61.14 with SMTP id r14mr6392690qah.253.1243914616408; Mon, 01 Jun 2009 20:50:16 -0700 (PDT) Received: from ?192.168.10.84? (59-125-13-44.HINET-IP.hinet.net [59.125.13.44]) by mx.google.com with ESMTPS id 7sm524440qwb.6.2009.06.01.20.50.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 20:50:15 -0700 (PDT) Sender: "Eric L. Chen" From: "Eric L. Chen" To: freebsd-current@freebsd.org Content-Type: text/plain Date: Tue, 02 Jun 2009 11:50:11 +0800 Message-Id: <1243914611.52975.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.27.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Cannot add wlan to lagg automatically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 04:20:30 -0000 Hi, I just upgraded my laptop from 7-STABLE to 8-CURRENT for a couple days, I use lagg to connect ethernet and wireless lan. before upgrade it works fine. /etc/rc.conf : cloned_interfaces="bridge0 lagg0" ifconfig_bridge0="up" autobridge_interfaces="bridge0" autobridge_bridge0="lagg0 tap0 tap1" ifconfig_bfe0="ether 00:0b:6b:4f:28:b8 up" # Need use WLAN MAC for WPA ifconfig_wlan0="up WPA" ifconfig_lagg0="up laggproto failover laggport bfe0 laggport ath0 DHCP" --- While booted interface lagg0 have two member: bfe0 and ath0 After upgraded: cloned_interfaces="bridge0 lagg0" ifconfig_bridge0="up" autobridge_interfaces="bridge0" autobridge_bridge0="lagg0 tap0 tap1" ifconfig_bfe0="ether 00:0b:6b:4f:28:b8 up" # Need use WLAN MAC for WPA wlans_ath0="wlan0" ifconfig_wlan0="up WPA" ifconfig_lagg0="up laggproto failover laggport bfe0 laggport wlan0 DHCP" --- While booted interface lagg0 have only one member: bfe0. I need add wlan0 by hand every boot. Does settings changed in CURRENT? /Eric From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 05:39:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCEAF106566C for ; Tue, 2 Jun 2009 05:39:49 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 488578FC0A for ; Tue, 2 Jun 2009 05:39:48 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 244595651; Tue, 02 Jun 2009 08:39:46 +0300 Message-ID: <4A24BB1F.5060403@FreeBSD.org> Date: Tue, 02 Jun 2009 08:39:43 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "James R. Van Artsdalen" , current@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: SATA port multipliers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 05:39:50 -0000 James R. Van Artsdalen wrote: > With this change (and other previously reported & PR'd patches) SATA > port multipliers seem to be working for me, albeit half as fast as expected. > > The ata_identify() call was commented out in February apparently due to > other problems it caused but it appears to be the only thing that scans > for drives behind an enclosure. > > Index: sys/dev/ata/ata-all.c > =================================================================== > --- sys/dev/ata/ata-all.c (revision 192136) > +++ sys/dev/ata/ata-all.c (working copy) > @@ -291,7 +291,7 @@ > ATA_LOCKING(dev, ATA_LF_UNLOCK); > > /* Add new children. */ > -/* ata_identify(dev); */ > + ata_identify(dev); > > if (bootverbose) > device_printf(dev, "reinit done ..\n"); ata_identify() also called in channel attach routine and it is enough to process port multipliers, same as usual drives. Calling it on reinit() would be good to be able to find new devices, but in current state it causes deadlock in some error conditions. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 05:49:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 733341065672 for ; Tue, 2 Jun 2009 05:49:20 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB588FC20 for ; Tue, 2 Jun 2009 05:49:20 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so4249717ywe.13 for ; Mon, 01 Jun 2009 22:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Ei+33f5SdXz8y1xT+tWQDFOgulVTimweXCW/2fHBtTg=; b=qqwI56Yttalf1bHFjl+NUXJJEZX0iSF9JS+W33WzK6LYVTopLHLQAnhqNmRnBVSRUQ zWMJULdClyICMhDZcVhduKnkV41Au0SJnpiN4KOKYDKDDcr1WY9hrqK1mzl4TB0wlPF+ /BGPhBChCGB/UEUTndZm77dV1XPiVJHSNwhKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ws70is2P0KMmxpXruyfRnQcJlg8pH2sgv5nqVZ7CGtm7yTmS+BNIee2OQryXnjdj02 K0P0I/E4eDoFfaNzUPeWRRW9MVy80UxtTQDVNgAW+sM2WScYa4vcZJ8ajxQ1KBGLvIcA aEFUB0RG9G0UVp4LOKIWxwDfhhC2PEFV0NlUE= MIME-Version: 1.0 Received: by 10.231.35.66 with SMTP id o2mr1838040ibd.42.1243919884172; Mon, 01 Jun 2009 22:18:04 -0700 (PDT) Date: Mon, 1 Jun 2009 22:18:04 -0700 Message-ID: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> From: "Sean P. Dew" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: BTX/AMD64/E820 FreeBSD 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 05:49:20 -0000 I am trying to run FreeBSD on a hypervisor (custom written). The hypervisor steals some memory for itself and wants to hide it from FreeBSD so that the OS does not read or write to that memory. The hypervisor hooks the real mode IDT for INT15 and checks for E820 and SMAP in the correct registers, and returns the modified SMAP to the OS. The problem I am facing is when the kernel invokes getmemsize (sys_amd64:01104), it looks for the SMAP loaded by the BTX loader. In GetBiosMEM where it is actually loaded, the BTX loader is invoked which invokes the INT15 handler using a RET instead of an INT15. Is there someway to totally bypass the BTX loade or change that behavior using some #define in the kernel to make it use int15? Thanks From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 06:06:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FB51065674; Tue, 2 Jun 2009 06:06:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 7F22A8FC27; Tue, 2 Jun 2009 06:06:39 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from localhost.my.domain (ppp-93-104-38-67.dynamic.mnet-online.de [93.104.38.67]) by dd12710.kasserver.com (Postfix) with ESMTP id 07C2B184F106A; Tue, 2 Jun 2009 08:06:38 +0200 (CEST) Received: (from guru@localhost) by localhost.my.domain (8.14.3/8.14.3/Submit) id n5266dEU002312; Tue, 2 Jun 2009 08:06:39 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Jun 2009 08:06:39 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Message-ID: <20090602060639.GA2260@current.Sisis.de> References: <20090514084617.GA3459@rebelion.Sisis.de> <200905141651.35948.shoesoft@gmx.net> <20090515125250.GA11380@rebelion.Sisis.de> <1242397462.1755.89.camel@balrog.2hip.net> <20090516060753.GA5319@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090516060753.GA5319@rebelion.Sisis.de> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: Stefan Ehmann , Robert Noland Subject: Re: Dell M4400 && Xorg-vesa && 1920x1200 res? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 06:06:40 -0000 El día Saturday, May 16, 2009 a las 08:07:53AM +0200, Matthias Apitz escribió: > El día Friday, May 15, 2009 a las 09:24:22AM -0500, Robert Noland escribió: > > > > Yes, this worked; but it was terrible slow on window movements; > > > I've got a small fix for the driver x11-drivers/xf86-video-nv and the > > > card is now working as it should with the 'nv' module. > > > > What patch? If it needs review and committing upstream, please send it > > to me... > > > > robert. > > The mentioned patch is now available in src/nv_driver.c > > > Thanks for testing this! I'll update the driver with the device names > > for the IDs in the 0x065x range tomorrow when it's not 2 am. ;) > > You'll be able to point to the patch at [1] then. If you need it > > soon, I can push an official release so you don't have to ship a > > patched driver. > > http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/commit/?id=c8d6f7aa7c99a1b71289f8e8e07becc10f61f379 > The final word on this is that the original driver from Nvidia works as well; the drivers are at http://www.nvidia.com/object/unix.html and its latest version is 180.60. The actual version does not compile on CURRENT. One must disable the check for this version in the source NVIDIA-FreeBSD-x86-180.60/src/nv-freebsd.h: /* #if __FreeBSD_version >= 800000 #error This driver does not support FreeBSD 8.x/-CURRENT! #endif */ then it compiles and installs fine. There is as well a problem on laptops with huge amount of memory (mine has 4 GByte) which seems to be a known issue in http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 and hardlocks the system on start of X. One needs a setting in /boot/loader.conf of machdep.disable_mtrrs=1 with this all is fine and X comes up as it should. As well the nvidia-settings tool must be compiled directly from the source because the one in the ports has some library conflict. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 06:58:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F8E81065670; Tue, 2 Jun 2009 06:58:48 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B0D9C8FC15; Tue, 2 Jun 2009 06:58:47 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=PFnILKYWRVkgumty4iCnQgHXX9gwLSFXg8hrKbQJ6OkMLznbwlzKFyBL4YyPSKIwXY5raiwc0NRIyzuH2qUMnGzAO6FImoCWQaqiR1QXhDL1v53G2hqbiy7oqXBNZPtsgcLZsaok2B5ODzABMiBmQ1XQ/lqjqVQBi90CsFJqaF4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MBNxN-000B5S-Lx; Tue, 02 Jun 2009 10:58:45 +0400 Date: Tue, 2 Jun 2009 10:58:43 +0400 From: Eygene Ryabinkin To: Randy Bush Message-ID: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Ed Schouten , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 06:58:48 -0000 Randy, Tue, Jun 02, 2009 at 06:15:06AM +0900, Randy Bush wrote: > >> ran just make install > >> work0.psg.com:/usr/src/usr.bin/ee# make install > >> > > So it's false alarm? Phew. :-) > > not false, just different. like what is killing the install? Install is killed by the fact that there's no gencat ;)) From your original report, ----- 8-current a few hours old, i386 ===> usr.bin/ee (install) install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg gencat:No such file or directory *** Error code 1 ----- I see that even on this machine ee's build wasn't successful: 'install' phase should be making .msg files -- they are to be built at the 'build' phase. Next, when you succeeded to build ee: ----- > work0.psg.com:/usr/src/usr.bin/ee# make clean > rm -f ee ee.o en_US.US-ASCII.msg fr_FR.ISO8859-1.msg de_DE.ISO8859-1.msg pl_PL.ISO8859-2.msg uk_UA.KOI8-U.msg ru_RU.KOI8-R.msg en_US.US-ASCII.cat fr_FR.ISO8859-1.cat de_DE.ISO8859-1.cat pl_PL.ISO8859-2.cat uk_UA.KOI8-U.cat ru_RU.KOI8-R.cat ee.1.gz ee.1.cat.gz > work0.psg.com:/usr/src/usr.bin/ee# make > make: don't know how to make /usr/src/usr.bin/ee/ee.c. Stop recovered data ran just make install work0.psg.com:/usr/src/usr.bin/ee# make install install -s -o root -g wheel -m 555 ee /usr/bin cat /usr/src/usr.bin/ee/../../contrib/ee/ee.msg > en_US.US-ASCII.msg gencat en_US.US-ASCII.cat en_US.US-ASCII.msg ----- Do you really just run 'make install' after 'make clean' and failed 'make'? Or you took some additional steps? In any case, bare 'make install' just used bsd.*.mk files from /usr/share/mk. Now you need to repeat 'make buildworld'/'make installworld'. If you're up to it, please, do (on the system where build by-hand was successful) ----- make buildworld 2>&1 | tee build.log make installworld 2>&1 | tee install.log ----- and show the contents build.log and install.log. > this is on two systems, and i am now afraid of updating anything. If you hadn't touched your other machine on which ee install was failing too, please, do the following: ----- cat /usr/src/usr.bin/ee/Makefile ls -la /usr/src/usr.bin/ee ls -la /usr/obj/usr/src/usr.bin/ee ls -la /usr/src/contrib/ee ls -la /usr/src/usr/share/mk grep -r '$FreeBSD' /usr/src/share/mk ----- and show the results. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 07:26:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18DB4106566B; Tue, 2 Jun 2009 07:26:54 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id A0AB48FC0A; Tue, 2 Jun 2009 07:26:53 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by gxk7 with SMTP id 7so863534gxk.19 for ; Tue, 02 Jun 2009 00:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Pfad8qyzJgbYnkCuQteUdggTkrkUS8onhpQuiLLgSEY=; b=mIId7sVCQKVpbkrGPA2hRNBUAkbVtTzDYa1ANFsHfmXB618Wwr7kC1Y6YjKhWZAoTb IFN5WDyTX2wgV8f+wQoeJwC4/Sqn5TrQiVmX/udGpG9jEljJp+a8O/CIircif5F9sOA9 69pgggPK+abJ9x6JVwssqemZ0IMqHJLRusWz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=jB8BeBFVyyHoifVCNsUihMSh9v6lB6eLqHN0UssyiVvI8jiI2en+pvR+xQoZlew/qu U45pyPQB5+qSJN0hdU8H6uNQYJfmvFAla2ExItGqSX7x2RYr4pQkIzc8+hUo1tGVAETv MjJBzO8IAZqiK7j7b7MS5sLHbxyCFRj3LcDP0= MIME-Version: 1.0 Received: by 10.150.202.11 with SMTP id z11mr13645296ybf.0.1243927613138; Tue, 02 Jun 2009 00:26:53 -0700 (PDT) Date: Tue, 2 Jun 2009 09:26:53 +0200 Message-ID: <90a5caac0906020026t67d7d9ej225565b42898a4b7@mail.gmail.com> From: Lucius Windschuh To: Pawel Jakub Dawidek , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: mksnap_ffs segfaults (was: Re: svn commit: r193051 - head/sbin/mksnap_ffs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 07:26:54 -0000 2009/5/29 Pawel Jakub Dawidek : > Author: pjd > Date: Fri May 29 19:18:41 2009 > New Revision: 193051 > URL: http://svn.freebsd.org/changeset/base/193051 Hi Pawel. You forgot to initialize iov and iovlen. This makes mksnap_ffs crash on the first build_iovec() with malloc() debugging enabled. Index: src/sbin/mksnap_ffs/mksnap_ffs.c =================================================================== --- src/sbin/mksnap_ffs/mksnap_ffs.c (revision 193301) +++ src/sbin/mksnap_ffs/mksnap_ffs.c (working copy) @@ -66,8 +66,8 @@ struct statfs stfsbuf; struct group *grp; struct stat stbuf; - struct iovec *iov; - int fd, iovlen; + struct iovec *iov = NULL; + int fd, iovlen = 0; if (argc == 2) snapname = argv[1]; Lucius From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 08:01:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23A8C1065676 for ; Tue, 2 Jun 2009 08:01:30 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D04108FC12 for ; Tue, 2 Jun 2009 08:01:29 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:37391 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MBOw0-0007eS-5m; Tue, 02 Jun 2009 10:01:26 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 33C055ECA9; Tue, 2 Jun 2009 10:01:21 +0200 (CEST) Message-Id: <4EE92FAD-528E-4154-B608-D822720EAB26@exscape.org> From: Thomas Backman To: James R. Van Artsdalen In-Reply-To: <4A248F6E.5020701@jrv.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 10:01:19 +0200 References: <4E6E325D-BB18-4478-BCFD-633D6F4CFD88@exscape.org> <4A248F6E.5020701@jrv.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MBOw0-0007eS-5m. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MBOw0-0007eS-5m 8247eb4a6d043bd3bcb4605b676e2f4c Cc: FreeBSD Current Subject: Re: ZFS panic under extreme circumstances (2/3 disks corrupted) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 08:01:30 -0000 On Jun 2, 2009, at 04:33 AM, James R. Van Artsdalen wrote: > Thomas Backman wrote: >> I have another unfortunate thing to note regarding this: after a >> reboot, it's even impossible to tell *which disk* has gone bad, even >> if the pool is "uncleared" but otherwise "healed". It simply says >> that >> a device has failed, with no clue as to which one, since they're all >> "ONLINE"! > > Is there anything recorded in the pool history log about this? > > The pool errlog is documented to be rotated after every scrub. I don't think so, and can't check (the "disks" are long gone from the VM), other than this message that I posted earlier in the thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/007259.html Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 08:24:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BACC31065677; Tue, 2 Jun 2009 08:24:24 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7824A8FC13; Tue, 2 Jun 2009 08:24:23 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id 032FE5CD3; Tue, 2 Jun 2009 09:23:54 +0100 (BST) Message-Id: From: Doug Rabson To: Henri Hennebert In-Reply-To: <4A23ABF2.3070601@restart.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 09:23:52 +0100 References: <4A23ABF2.3070601@restart.be> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 08:24:25 -0000 On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > Hello, > > During my tests (succesful) to directly boot from ZFS (with zfsboot > and gptzfsboot) I encounter the error "can't boot 'kernel'" if too > many devices/pools are connected to the machine. In my case: > > 2 SAS disks with 2 pools > 2 SATA disks with 2 pools > 1 USB key with one pool > > `heap` command: > > Active Allocations: 171/173 > 536576 bytes reserved 527800 bytes allocated > > `ls` command: > > open '/' failed: too many open files > > If I reboot without the USB key all is OK. > > If I reboot from the USB key after disconnecting 2 disks all is OK. > > By the way, the /boot/loader in 7.2-STABLE don't work, complains > about forth not found. > > The previous tests were made with 7.2-STABLE (May 31) with /boot/ > loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 08:34:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF9341065674; Tue, 2 Jun 2009 08:34:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 649178FC08; Tue, 2 Jun 2009 08:34:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n528Ycbt033641; Tue, 2 Jun 2009 04:34:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n528YbVY048066; Tue, 2 Jun 2009 04:34:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4245F7302F; Tue, 2 Jun 2009 04:34:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602083437.4245F7302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 04:34:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 08:34:41 -0000 TB --- 2009-06-02 06:58:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 06:58:49 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-02 06:58:49 - cleaning the object tree TB --- 2009-06-02 06:59:15 - cvsupping the source tree TB --- 2009-06-02 06:59:16 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-02 06:59:23 - building world TB --- 2009-06-02 06:59:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 06:59:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 06:59:23 - TARGET=pc98 TB --- 2009-06-02 06:59:23 - TARGET_ARCH=i386 TB --- 2009-06-02 06:59:23 - TZ=UTC TB --- 2009-06-02 06:59:23 - __MAKE_CONF=/dev/null TB --- 2009-06-02 06:59:23 - cd /src TB --- 2009-06-02 06:59:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 06:59:24 UTC 2009 >>> 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 Tue Jun 2 08:26:26 UTC 2009 TB --- 2009-06-02 08:26:26 - generating LINT kernel config TB --- 2009-06-02 08:26:26 - cd /src/sys/pc98/conf TB --- 2009-06-02 08:26:26 - /usr/bin/make -B LINT TB --- 2009-06-02 08:26:26 - building LINT kernel TB --- 2009-06-02 08:26:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 08:26:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 08:26:26 - TARGET=pc98 TB --- 2009-06-02 08:26:26 - TARGET_ARCH=i386 TB --- 2009-06-02 08:26:26 - TZ=UTC TB --- 2009-06-02 08:26:26 - __MAKE_CONF=/dev/null TB --- 2009-06-02 08:26:26 - cd /src TB --- 2009-06-02 08:26:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 08:26:27 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 08:34:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 08:34:36 - ERROR: failed to build lint kernel TB --- 2009-06-02 08:34:36 - 4281.13 user 440.21 system 5747.23 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 09:51:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FB28106566C for ; Tue, 2 Jun 2009 09:51:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id AE78D8FC20 for ; Tue, 2 Jun 2009 09:51:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n529nBRP050185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 11:49:13 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A24F596.1010706@omnilan.de> Date: Tue, 02 Jun 2009 11:49:10 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <4A12CBE9.5010206@omnilan.de> <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> In-Reply-To: <9LNvWOs6KnRm5ARvil0CjUiak0c@cgr/Aoyjz11KtFDB23HMnFSn04s> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27C0AE39C7E52FDF04FA50F8" Cc: freebsd-current@freebsd.org Subject: HAL is blokcing growisofs [Was: Re: Various problems, atapi, acpi (S3), cpufreq (est)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 09:51:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27C0AE39C7E52FDF04FA50F8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Eygene Ryabinkin schrieb am 20.05.2009 11:28 (localtime): =2E.. >> Using `growisofs -dvd-compat -speed=3D8 -Z /dev/cd1=3D/udfimage.iso` f= reezes=20 >> the system. First it seems nothing happens but after some minutes the = >> system is completely unresponsive, even mouse doesn't move any more.=20 >> Here's some output I got at this event: >> ... >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - PREVENT_ALLOW taskqueue timeout - completing request=20 >> directly >> acd1: WARNING - PREVENT_ALLOW freeing taskqueue zombie request >> acd1: WARNING - TEST_UNIT_READY taskqueue timeout - completing request= =20 >> directly >> acd1: WARNING - TEST_UNIT_READY freeing taskqueue zombie request >> acd1: WARNING - READ_TOC taskqueue timeout - completing request direct= ly >> acd1: WARNING - READ_TOC freeing taskqueue zombie reques >=20 > Could you try to add atapicam(4) device into your kernel and use > /dev/cdX instead of /dev/acdX for burning? I don't believe that this > will help you, given the messages you're receiving, but you can at leas= t > give a shot for SCSI emulation on ATAPI devices. Accidentally I found out that growisofs works perfectly without HAL. As soon as hal is running I see the above error messages and no dvd=20 burning is possible. Also USB-Flash-Disks don't work with -current and hal (everything=20 compiled 2 days ago). As soon as I plug in the UFD all=20 "hald-addon-storage: /dev/da1" (from fixed internal card reader) vanish=20 and I can't use Thunars volume-mount feature. Should I open a ports/PR? Or is it likle to be a problem in -current? Thanks, -Harry --------------enig27C0AE39C7E52FDF04FA50F8 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.11 (FreeBSD) iEYEARECAAYFAkok9ZcACgkQLDqVQ9VXb8hwtgCbB/wG/gqDAaFFcbzFntcgP2VT zsYAn2/mY4X9OLnWT5JID4B/kXj9iZe7 =YmcD -----END PGP SIGNATURE----- --------------enig27C0AE39C7E52FDF04FA50F8-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 10:31:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 614B11065672; Tue, 2 Jun 2009 10:31:14 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id E31C08FC17; Tue, 2 Jun 2009 10:31:13 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id F2C104E79; Tue, 2 Jun 2009 12:31:12 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n52AV9Fw024619; Tue, 2 Jun 2009 12:31:10 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1243938672; bh=zJaiGhDEaUyTO2eTkdbEZtUFw90XV05BJ3f/PRZVlQQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EASE1eGqYPXDOeno0kwO98xe6dGXP+Q1qdPV4nuZ8APUYuRihks8XdbNjqe16O8Km EwiPLvc+8Wb+STe4u5KjQ== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=vwA6yqNp9ytl34WLyxCWmZgwLPTDA/1KgfbRt8k1hYn2CLrDdqb0t8VRQHgEwGCKU sQjT0xfsZ0vvWcnORENMg== Message-ID: <4A24FF6E.7020209@restart.be> Date: Tue, 02 Jun 2009 12:31:10 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.21 (X11/20090412) MIME-Version: 1.0 To: Doug Rabson References: <4A23ABF2.3070601@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: /boot/loader can't load kernel if too many pool/devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 10:31:14 -0000 Doug Rabson wrote: > > On 1 Jun 2009, at 11:22, Henri Hennebert wrote: > >> Hello, >> >> During my tests (succesful) to directly boot from ZFS (with zfsboot >> and gptzfsboot) I encounter the error "can't boot 'kernel'" if too >> many devices/pools are connected to the machine. In my case: >> >> 2 SAS disks with 2 pools >> 2 SATA disks with 2 pools >> 1 USB key with one pool >> >> `heap` command: >> >> Active Allocations: 171/173 >> 536576 bytes reserved 527800 bytes allocated >> >> `ls` command: >> >> open '/' failed: too many open files >> >> If I reboot without the USB key all is OK. >> >> If I reboot from the USB key after disconnecting 2 disks all is OK. >> >> By the way, the /boot/loader in 7.2-STABLE don't work, complains about >> forth not found. >> >> The previous tests were made with 7.2-STABLE (May 31) with >> /boot/loader from 8.0-CURRENT. > > I recently increased the number of file descriptors available for > /boot/loader. Could you rebuild and try again please. Make sure you > rebuild libstand.a as well as /boot/loader. > OK - I can boot with the USB key and 4 disks Thanks Henri From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 10:38:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F54106564A for ; Tue, 2 Jun 2009 10:38:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A8D488FC12 for ; Tue, 2 Jun 2009 10:38:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA25602; Tue, 02 Jun 2009 13:38:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A25011D.5080603@icyb.net.ua> Date: Tue, 02 Jun 2009 13:38:21 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Michael Moll References: <20090601182012.GA21543@darkthrone.kvedulv.de> In-Reply-To: <20090601182012.GA21543@darkthrone.kvedulv.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 10:38:26 -0000 on 01/06/2009 21:20 Michael Moll said the following: > Hi, > > I'm getting the following crash on the NFS server with -CURRENT (r193229) > as soon as I try to access a file on a ZFS filesystem via NFS: [backtrace snipped] > Any ideas on this one? Could you please share panic message/header in addition to the backtrace? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 10:54:51 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F7891065672 for ; Tue, 2 Jun 2009 10:54:51 +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 DF5A78FC1D for ; Tue, 2 Jun 2009 10:54:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1MBRdp-0002Dn-VC>; Tue, 02 Jun 2009 12:54:50 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1MBRdp-0005x7-Ts>; Tue, 02 Jun 2009 12:54:49 +0200 Message-ID: <4A2504AA.1020406@zedat.fu-berlin.de> Date: Tue, 02 Jun 2009 10:53:30 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090417) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 10:54:51 -0000 Hello, since today I get this error when trying to mount a NFS filesystem from NFS server: [udp] foo:/home: RPCPROG_MNT: RPC: Timed out Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from today's buildworld/make kernel. nfsd is up and running and worked that way days before. I saw commitments of new NFSv4 code, are these causing this issue? Is 8.0 supposed to be offering nfsv4-server capabilities which I need to switch on anyway? I also tried mount -t newnfs on that NFS filesystem but without any success. Is this a fault of mine or are temporarely not-working-condition? I tried both ZFS and UFS2 NFS exports to get mounted, both are unwilling to mount with the above showed error. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 11:09:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C9581065670 for ; Tue, 2 Jun 2009 11:09:54 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id C44368FC1B for ; Tue, 2 Jun 2009 11:09:53 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id 81F281CC58; Tue, 2 Jun 2009 13:09:52 +0200 (CEST) Date: Tue, 2 Jun 2009 13:09:52 +0200 From: Michael Moll To: Andriy Gapon Message-ID: <20090602110952.GB67463@darkthrone.kvedulv.de> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <4A25011D.5080603@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A25011D.5080603@icyb.net.ua> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 11:09:54 -0000 Hi Andriy, On Tue, Jun 02, 2009 at 01:38:21PM +0300, Andriy Gapon wrote: > Could you please share panic message/header in addition to the backtrace? Oops, sorry... Here we go: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x67c fault code = supervisor read, page not present instruction pointer = 0x20:0x8053d1bd stack pointer = 0x28:0xfcc95758 frame pointer = 0x28:0xfcc95764 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 731 (nfsd: master) trap number = 12 panic: page fault Uptime: 15m2s Physical memory: 1974 MB Dumping 99 MB: 84 68 52 36 20 4 Best Regards -- Michael Moll From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 06:50:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 199A81065670 for ; Tue, 2 Jun 2009 06:50:14 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id CE9D78FC19 for ; Tue, 2 Jun 2009 06:50:13 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: by gxk7 with SMTP id 7so843072gxk.19 for ; Mon, 01 Jun 2009 23:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=dJiFAoIY1B4vD2foQ2WNd9iDm9dK7xBG4ZYIHh/PFpU=; b=fqhMfi/2ivnnkAENiHMMr+6wBe7vDCWKIithXEbU83DAiGKJ5uWQ6Q7irLWVEaNB47 LN3V/pUCVwdCpcwMiLiD4cHxc0TMMosDenFg2HJ0d8hXe9PiUGy59WD516mP9mY2+o2d fQ7A01m5hvOuRcJoTDv+6TJNbaXgbxDY2g70w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SYkIzYsveAw7YZKPqtobOpfDVOYS+2jk8EZC3AbSCuFEnF9B4hUJ9FsEFilWzaCT2P s82SuijzYXUXYruM6INUF7+fQjnICrKSRKJ78JhQRtN5BkGpgDrrUgQuIeQuZG5ZelHa bZc08i1jmVJ9hVWu+MzBfrsE5xkOUBnNejFu8= MIME-Version: 1.0 Received: by 10.231.14.3 with SMTP id e3mr1870560iba.13.1243925412894; Mon, 01 Jun 2009 23:50:12 -0700 (PDT) Date: Mon, 1 Jun 2009 23:50:12 -0700 Message-ID: <45d874490906012350u11026416tf94f3cc44def2f37@mail.gmail.com> From: "Sean P. Dew" To: freebsd-current@freebsd.org X-Mailman-Approved-At: Tue, 02 Jun 2009 11:13:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VMX in kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 06:50:14 -0000 Is there any header file/example code for making VMX calls from the FreeBSD kernel? Does the compiler support any directives? Thanks From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 11:16:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01AB106566B; Tue, 2 Jun 2009 11:16:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 800AD8FC08; Tue, 2 Jun 2009 11:16:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n52BGXnO044831; Tue, 2 Jun 2009 07:16:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n52BGXnj073418; Tue, 2 Jun 2009 07:16:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A9B467302F; Tue, 2 Jun 2009 07:16:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602111633.A9B467302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 07:16:33 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 11:16:37 -0000 TB --- 2009-06-02 09:41:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 09:41:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-02 09:41:54 - cleaning the object tree TB --- 2009-06-02 09:42:13 - cvsupping the source tree TB --- 2009-06-02 09:42:13 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-02 09:42:22 - building world TB --- 2009-06-02 09:42:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 09:42:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 09:42:22 - TARGET=powerpc TB --- 2009-06-02 09:42:22 - TARGET_ARCH=powerpc TB --- 2009-06-02 09:42:22 - TZ=UTC TB --- 2009-06-02 09:42:22 - __MAKE_CONF=/dev/null TB --- 2009-06-02 09:42:22 - cd /src TB --- 2009-06-02 09:42:22 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 09:42:24 UTC 2009 >>> 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 Tue Jun 2 11:09:09 UTC 2009 TB --- 2009-06-02 11:09:09 - generating LINT kernel config TB --- 2009-06-02 11:09:09 - cd /src/sys/powerpc/conf TB --- 2009-06-02 11:09:09 - /usr/bin/make -B LINT TB --- 2009-06-02 11:09:09 - building LINT kernel TB --- 2009-06-02 11:09:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:09:09 - TARGET=powerpc TB --- 2009-06-02 11:09:09 - TARGET_ARCH=powerpc TB --- 2009-06-02 11:09:09 - TZ=UTC TB --- 2009-06-02 11:09:09 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:09:09 - cd /src TB --- 2009-06-02 11:09:09 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 11:09:09 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 11:16:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 11:16:33 - ERROR: failed to build lint kernel TB --- 2009-06-02 11:16:33 - 4435.65 user 412.15 system 5678.98 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 11:31:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B9C5106567D; Tue, 2 Jun 2009 11:31:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BF5F58FC0A; Tue, 2 Jun 2009 11:31:41 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBSDI-000JWj-4g; Tue, 02 Jun 2009 11:31:28 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 97E9E1D67820; Tue, 2 Jun 2009 20:31:27 +0900 (JST) Date: Tue, 02 Jun 2009 20:31:27 +0900 Message-ID: From: Randy Bush To: Eygene Ryabinkin In-Reply-To: References: <3a142e750905311738t38b1721s31f029be72465f99@mail.gmail.com> <20090601205912.GN48776@hoeg.nl> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Ed Schouten , current , bug-followup@freebsd.org Subject: Re: misc/135156: 8-current installworld - gencat:No such file or directory [WAS: Re: installworld failure] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 11:31:42 -0000 exec summary: i may be out of the hole >>>> ran just make install >>>> work0.psg.com:/usr/src/usr.bin/ee# make install >>>> >>> So it's false alarm? Phew. :-) >> >> not false, just different. like what is killing the install? > > Install is killed by the fact that there's no gencat ;)) i figured i was in some version skew trap. so i started from again i svn sources and place same source tree on machine rip and work0. i make kernel on work0 and reboot log at http://archive.psg.com/2009.06.02/kernel.log.gz kernel conf at http://archive.psg.com/2009.06.02/WORK0 on work0, i make buildworld, which fails ===> gnu/usr.bin/texinfo/infokey (installincludes) ===> gnu/usr.bin/texinfo/install-info (installincludes) ===> gnu/usr.bin/texinfo/texindex (installincludes) ===> gnu/usr.bin/texinfo/doc (installincludes) ===> include (includes) cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh Segmentation fault (core dumped) *** Error code 139 log at http://archive.psg.com/2009.06.02/buildworld-work0.log.gz on rip, i make buildworld, log at http://archive.psg.com/2009.06.02/buildworld-rip.log.gz i rm -rf work0:/usr/obj i tar /usr/obj from rip to work0 on work0, i run make installworld which seems to ends bit unexpectedly, with a bunch of stuff after the usual makewhatis etc. cd /usr/src/usr.bin/ldd; PROG=ldd32 MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 VERSION="FreeBSD 8.0-CURRENT amd64 800096" MACHINE=i386 MACHINE_ARCH=i386 PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/tmp/install.7UCUwZK0 CC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" CXX="c++ -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" OB JC="cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/usr/src/lib32/usr/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32" LD="ld -m elf_i386_fbsd -Y P,/usr/obj/usr/src/lib32/usr/lib32" AS="as --32" LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install install -s -o root -g wheel -m 555 ldd32 /usr/bin log at http://archive.psg.com/2009.06.02/installworld-work0.log.gz reboot asterisk starts mysql starts dhcpd starts ejabberd gets a core in beam httpd cores portupgrade -fav dies a horrible death cd /usr/ports/lang/ruby18 && make && make deinstall && make reinstall cd /usr/ports/ports-mgmt/portupgrade-devel && make && make deinstall && make reinstall portupgrade -fRv apache* i porupgrade apache and erlang and ejabberd and they work i think i may be out of the hole. randy From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 12:06:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C15861065689; Tue, 2 Jun 2009 12:06:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3EA8FC1A; Tue, 2 Jun 2009 12:06:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n52C6CxC002721; Tue, 2 Jun 2009 08:06:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n52C6CVp091621; Tue, 2 Jun 2009 08:06:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 37D267302F; Tue, 2 Jun 2009 08:06:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602120612.37D267302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 08:06:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:06:18 -0000 TB --- 2009-06-02 10:35:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 10:35:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-02 10:35:20 - cleaning the object tree TB --- 2009-06-02 10:35:45 - cvsupping the source tree TB --- 2009-06-02 10:35:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-02 10:35:56 - building world TB --- 2009-06-02 10:35:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 10:35:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 10:35:56 - TARGET=sparc64 TB --- 2009-06-02 10:35:56 - TARGET_ARCH=sparc64 TB --- 2009-06-02 10:35:56 - TZ=UTC TB --- 2009-06-02 10:35:56 - __MAKE_CONF=/dev/null TB --- 2009-06-02 10:35:56 - cd /src TB --- 2009-06-02 10:35:56 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 10:35:58 UTC 2009 >>> 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 Tue Jun 2 11:57:50 UTC 2009 TB --- 2009-06-02 11:57:50 - generating LINT kernel config TB --- 2009-06-02 11:57:50 - cd /src/sys/sparc64/conf TB --- 2009-06-02 11:57:50 - /usr/bin/make -B LINT TB --- 2009-06-02 11:57:50 - building LINT kernel TB --- 2009-06-02 11:57:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:57:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:57:50 - TARGET=sparc64 TB --- 2009-06-02 11:57:50 - TARGET_ARCH=sparc64 TB --- 2009-06-02 11:57:50 - TZ=UTC TB --- 2009-06-02 11:57:50 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:57:50 - cd /src TB --- 2009-06-02 11:57:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 11:57:51 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 12:06:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 12:06:12 - ERROR: failed to build lint kernel TB --- 2009-06-02 12:06:12 - 4208.81 user 415.77 system 5451.59 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 12:12:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2DD106567E for ; Tue, 2 Jun 2009 12:12:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCEE8FC1F for ; Tue, 2 Jun 2009 12:12:39 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from outgoing.leidinger.net (pD9E2E94E.dip.t-dialin.net [217.226.233.78]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id D4323844F47; Tue, 2 Jun 2009 14:12:37 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id A76A0296122; Tue, 2 Jun 2009 14:12:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1243944752; bh=2ItUlgunTvfx0Rcl3DHYDb4RUVxQjp1tFWa+V96vLmM=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QigG8zGfKnPbREnLCyZSrCNf10pO4gYWAbgheN1xlsH7FlObiaZGjZfj6HTXSUOZV khAw867q53fr1Fji2idn3A08FDJgUVnIalWuLS3X5jeMzMa889+hwTQl3uS+berDkl XMYokFoQqA9aDFE3u3OJ5c5E1HVsi0TqeeOmG1k3AsPqT1JyD4JvxtgagEpgH3Nwj3 kmdwkAj/JWlThupAP9S4V/cpLm3Qo+n5+gDHYolpwIazsMTvSQ9uk4/Sm6gYdKSFO1 hRm2kD0QdVES5V3TeaM5y3wgDyg680IB0VabfJB71Q13vI0ZKYawK1J78zEdFrQIuc h8gbmULt80ykg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n52CCWxW005755; Tue, 2 Jun 2009 14:12:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Jun 2009 14:12:31 +0200 Message-ID: <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Tue, 02 Jun 2009 14:12:31 +0200 From: Alexander Leidinger To: Doug Barton References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> In-Reply-To: <4A240331.1000803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 Cc: freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 12:12:42 -0000 Quoting Doug Barton (from Mon, 01 Jun 2009 =20 09:34:57 -0700): > Andriy Gapon wrote: >> on 01/06/2009 16:20 Andriy Gapon said the following: >>> What about the following patch? >>> I believe that the idea behind fsck_y_enable is to try to make =20 >>> unattended systems >>> with rw filesystems as recoverable as possible at the cost of =20 >>> potential damage to >>> the data. The new "-C" option should not interfere with this goal, =20 >>> but should >>> reduce recovery time, because currently fsck -y checks *all* =20 >>> filesystems from >>> fstab, even those that are ro or clean: >>> >>> -C Check if the =E2=80=9Cclean=E2=80=9D flag is set in the superblo= ck and skip file >>> system checks if file system was properly dismounted and marked >>> clean. >>> >> >> One potential issue that I've just thought of is that fsck_msdosfs =20 >> doesn't seem to >> support this option (even in a dummy way), so it would be a problem =20 >> for those who >> have msdos filesystems in fstab and also have fsck_y_enable. > > I'm a bit concerned that we keep the current option as it is, but I > would support adding an fsck_y_enable_flags option to allow people to > pass -C if they are sure it will work in their environment. What about _flags and also adding a NOP for -C in fsck_msdosfs? Bye, Alexander. --=20 Another dream that failed. There's nothing sadder. =09=09-- Kirk, "This side of Paradise", stardate 3417.3 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 12:42:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38577106567A; Tue, 2 Jun 2009 12:42:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id EE50A8FC1A; Tue, 2 Jun 2009 12:42:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n52CgeoT056230; Tue, 2 Jun 2009 08:42:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n52CgdMY070291; Tue, 2 Jun 2009 08:42:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E79987302F; Tue, 2 Jun 2009 08:42:39 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602124239.E79987302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 08:42:39 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:42:44 -0000 TB --- 2009-06-02 11:16:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 11:16:33 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 11:16:33 - cleaning the object tree TB --- 2009-06-02 11:17:18 - cvsupping the source tree TB --- 2009-06-02 11:17:18 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 11:17:24 - building world TB --- 2009-06-02 11:17:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 11:17:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 11:17:24 - TARGET=sun4v TB --- 2009-06-02 11:17:24 - TARGET_ARCH=sparc64 TB --- 2009-06-02 11:17:24 - TZ=UTC TB --- 2009-06-02 11:17:24 - __MAKE_CONF=/dev/null TB --- 2009-06-02 11:17:24 - cd /src TB --- 2009-06-02 11:17:24 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 11:17:29 UTC 2009 >>> 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 Tue Jun 2 12:35:43 UTC 2009 TB --- 2009-06-02 12:35:43 - generating LINT kernel config TB --- 2009-06-02 12:35:43 - cd /src/sys/sun4v/conf TB --- 2009-06-02 12:35:43 - /usr/bin/make -B LINT TB --- 2009-06-02 12:35:43 - building LINT kernel TB --- 2009-06-02 12:35:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 12:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 12:35:43 - TARGET=sun4v TB --- 2009-06-02 12:35:43 - TARGET_ARCH=sparc64 TB --- 2009-06-02 12:35:43 - TZ=UTC TB --- 2009-06-02 12:35:43 - __MAKE_CONF=/dev/null TB --- 2009-06-02 12:35:43 - cd /src TB --- 2009-06-02 12:35:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 12:35:43 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 12:42:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 12:42:39 - ERROR: failed to build lint kernel TB --- 2009-06-02 12:42:39 - 4191.83 user 410.93 system 5165.93 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 12:48:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D7D8106566C; Tue, 2 Jun 2009 12:48:28 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 28FCE8FC17; Tue, 2 Jun 2009 12:48:28 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=OuBKs5jxhh2cLEEBBkkH7c7sn1rf5o/xuFXyhQWLmrQ7cbfQf+77qNzTAzUcYmXqT7yoa4hR7zKQEB6nqwikkxOOxxRHZD9rfCGx8CBmHguVtvJ9Q38lVn1OpN4dsXfJxIQz/3uorfLFoWnZ+d7ut+SFwEL+oPVyN+IzQU/f8D4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MBTPn-000KyA-7X; Tue, 02 Jun 2009 16:48:27 +0400 Date: Tue, 2 Jun 2009 16:48:24 +0400 From: Eygene Ryabinkin To: FreeBSD Tinderbox Message-ID: References: <20090602120612.37D267302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fmvA4kSBHQVZhkR6" Content-Disposition: inline In-Reply-To: <20090602120612.37D267302F@freebsd-current.sentex.ca> Sender: rea-fbsd@codelabs.ru Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:48:28 -0000 --fmvA4kSBHQVZhkR6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Tue, Jun 02, 2009 at 08:06:12AM -0400, FreeBSD Tinderbox wrote: > /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) > /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' > cc1: warnings being treated as errors > /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' > /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' > /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) > /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' > /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' > *** Error code 1 Perhaps the attached patch will fix the stuff? For enabled ACPI (__HAVE_ACPI) machine/stdarg.h is brought by contrib/dev/acpica/acpi.h, but seems like sparc64 nave no ACPI. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --fmvA4kSBHQVZhkR6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index 5055762..63d9cee 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -51,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #if defined(__i386__) || defined(__amd64__) #include --fmvA4kSBHQVZhkR6-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 13:41:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906B11065677; Tue, 2 Jun 2009 13:41:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE6D8FC27; Tue, 2 Jun 2009 13:41:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1203946B38; Tue, 2 Jun 2009 09:41:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 09D978A02B; Tue, 2 Jun 2009 09:41:21 -0400 (EDT) From: John Baldwin To: rea-fbsd@codelabs.ru Date: Tue, 2 Jun 2009 09:19:40 -0400 User-Agent: KMail/1.9.7 References: <20090602120612.37D267302F@freebsd-current.sentex.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906020919.41339.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 02 Jun 2009 09:41:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: sparc64@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 13:41:25 -0000 On Tuesday 02 June 2009 8:48:24 am Eygene Ryabinkin wrote: > Tue, Jun 02, 2009 at 08:06:12AM -0400, FreeBSD Tinderbox wrote: > > /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) > > /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' > > cc1: warnings being treated as errors > > /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' > > /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' > > /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) > > /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' > > /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' > > *** Error code 1 > > Perhaps the attached patch will fix the stuff? For enabled ACPI > (__HAVE_ACPI) machine/stdarg.h is brought by contrib/dev/acpica/acpi.h, > but seems like sparc64 nave no ACPI. I had already committed this, but thanks for the hint on why it compiled on amd64. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 13:41:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85D99106564A for ; Tue, 2 Jun 2009 13:41:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5993F8FC12 for ; Tue, 2 Jun 2009 13:41:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 11D2146B39; Tue, 2 Jun 2009 09:41:26 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id F0A428A02C; Tue, 2 Jun 2009 09:41:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 2 Jun 2009 09:25:26 -0400 User-Agent: KMail/1.9.7 References: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> In-Reply-To: <45d874490906012218y16834cc4va32f6e25b0ab8374@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906020925.26738.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 02 Jun 2009 09:41:22 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "Sean P. Dew" Subject: Re: BTX/AMD64/E820 FreeBSD 7.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 13:41:26 -0000 On Tuesday 02 June 2009 1:18:04 am Sean P. Dew wrote: > I am trying to run FreeBSD on a hypervisor (custom written). The hypervisor > steals some memory for itself and wants to hide it from FreeBSD so that the > OS does not read or write to that memory. The hypervisor hooks the real mode > IDT for INT15 and checks for E820 and SMAP in the correct registers, and > returns the modified SMAP to the OS. The problem I am facing is when the > kernel invokes getmemsize (sys_amd64:01104), it looks for the SMAP loaded by > the BTX loader. In GetBiosMEM where it is actually loaded, the BTX loader is > invoked which invokes the INT15 handler using a RET instead of an INT15. Is > there someway to totally bypass the BTX loade or change that behavior using > some #define in the kernel to make it use int15? No. Assuming you have hooked the real mode entry point in the IDT table, that is the address that BTX is going to jump to. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 14:06:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765CD1065674; Tue, 2 Jun 2009 14:06: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 1E5C68FC15; Tue, 2 Jun 2009 14:06:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00321; Tue, 02 Jun 2009 17:06:19 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A2531DA.2070608@freebsd.org> Date: Tue, 02 Jun 2009 17:06:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert , Kip Macy References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> In-Reply-To: <4A240063.207@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 14:06:24 -0000 on 01/06/2009 19:22 Andriy Gapon said the following: > Henri, > > thank you very much for testing! > It look like the patch did its job. > > P.S. hopefully someone is looking into the cause of the assertion. I think I cracked it. This is where ds->ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x0000000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x0000000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x0000000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x00000008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(&ds->ds_lock)) (gdb) list 259 if (ds->ds_dir) 260 dsl_dir_close(ds->ds_dir, ds); 261 262 ASSERT(!list_link_active(&ds->ds_synced_link)); 263 264 if (mutex_owned(&ds->ds_lock)) 265 mutex_exit(&ds->ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 14:14:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E03B3106564A; Tue, 2 Jun 2009 14:14:20 +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 86F708FC15; Tue, 2 Jun 2009 14:14:19 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00512; Tue, 02 Jun 2009 17:14:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A2533B8.8040007@freebsd.org> Date: Tue, 02 Jun 2009 17:14:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Henri Hennebert , Kip Macy References: <3c1674c90905201643m540c8b1v8a8bd88f071c233d@mail.gmail.com> <4A1D0F2B.4030006@restart.be> <3c1674c90905280052q281f6172j2409fe2d64db6914@mail.gmail.com> <4A1E90F7.2000000@restart.be> <4A1E97D8.4080901@icyb.net.ua> <4A1FD687.5070502@freebsd.org> <4A23EEC8.2040208@freebsd.org> <4A23FDE5.1040101@restart.be> <4A240063.207@freebsd.org> <4A2531DA.2070608@freebsd.org> In-Reply-To: <4A2531DA.2070608@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: libzpool assert vs libc assert X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 14:14:21 -0000 on 02/06/2009 17:06 Andriy Gapon said the following: > So I am quite sure that mutex_owned should be defined as follows: > #define mutex_owned(l) pthread_mutex_isowned_np((l)->m_lock) Actually: #define mutex_owned(l) pthread_mutex_isowned_np(&(l)->m_lock) And on dangers of ignored compiler warnings: /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type This is during libzpool compilation. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 14:34:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3CCA106566B for ; Tue, 2 Jun 2009 14:34:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 97B0B8FC17 for ; Tue, 2 Jun 2009 14:34:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL/UJEqDaFvG/2dsb2JhbADQJ4QLBQ X-IronPort-AV: E=Sophos;i="4.41,291,1241409600"; d="scan'208";a="37204588" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 10:34:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 350FC210109; Tue, 2 Jun 2009 10:34:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWtY1HQLqk-E; Tue, 2 Jun 2009 10:34:20 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 61F862100FB; Tue, 2 Jun 2009 10:34:20 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52EZWL08409; Tue, 2 Jun 2009 10:35:32 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 10:35:32 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 14:34:23 -0000 On Tue, 2 Jun 2009, O. Hartmann wrote: > Hello, > since today I get this error when trying to mount a NFS filesystem from NFS > server: > > [udp] foo:/home: RPCPROG_MNT: RPC: Timed out > > Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from > today's buildworld/make kernel. > > nfsd is up and running and worked that way days before. > > I saw commitments of new NFSv4 code, are these causing this issue? Is 8.0 > supposed to be offering nfsv4-server capabilities which I need to switch on > anyway? > By default, everything should work just like before, using the vanilla NFS server, etc. The message indicates that mountd wasn't responding. So, first off, check that it is running. I did integrate some changes into mountd for the new experimental nfs subsystem, but those should only be invoked if "-e" was provided on its command line. I'll go through the changes I made to mountd.c again, but it has been working ok for me. > I also tried mount -t newnfs on that NFS filesystem but without any success. > Is this a fault of mine or are temporarely not-working-condition? > Using "mount -t newnfs" uses the experimental nfs client instead of the regular one, but they should both work. The problem seems to be an unresponsive mountd. Let us know if you find out anything more about it, rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 15:14:45 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E82061065675 for ; Tue, 2 Jun 2009 15:14:45 +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 704FC8FC08 for ; Tue, 2 Jun 2009 15:14:45 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MBVhM-0002z5-GX>; Tue, 02 Jun 2009 17:14:44 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MBVhM-0005yq-FE>; Tue, 02 Jun 2009 17:14:44 +0200 Message-ID: <4A254194.7080807@zedat.fu-berlin.de> Date: Tue, 02 Jun 2009 15:13:24 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.21 (X11/20090417) MIME-Version: 1.0 To: Rick Macklem References: <4A2504AA.1020406@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: freebsd-current@FreeBSD.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 15:14:46 -0000 Rick Macklem wrote: > > > On Tue, 2 Jun 2009, O. Hartmann wrote: > >> Hello, >> since today I get this error when trying to mount a NFS filesystem >> from NFS server: >> >> [udp] foo:/home: RPCPROG_MNT: RPC: Timed out >> >> Both boxes, cleint and server, are most recent FreeBSD >> 8.0-CURRENT/amd64 from today's buildworld/make kernel. >> >> nfsd is up and running and worked that way days before. >> >> I saw commitments of new NFSv4 code, are these causing this issue? Is >> 8.0 supposed to be offering nfsv4-server capabilities which I need to >> switch on anyway? >> > By default, everything should work just like before, using the vanilla NFS > server, etc. The message indicates that mountd wasn't responding. So, > first off, check that it is running. > > I did integrate some changes into mountd for the new experimental nfs > subsystem, but those should only be invoked if "-e" was provided on its > command line. > > I'll go through the changes I made to mountd.c again, but it has been > working ok for me. > >> I also tried mount -t newnfs on that NFS filesystem but without any >> success. Is this a fault of mine or are temporarely >> not-working-condition? >> > Using "mount -t newnfs" uses the experimental nfs client instead of the > regular one, but they should both work. The problem seems to be an > unresponsive mountd. > > Let us know if you find out anything more about it, rick > _______________________________________________ > 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" Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I do not know why udp is invoked automatically by now. But for short, we always did NFS mounts over tcp AND udp, so for tcp it worked again! Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 15:42:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CC111065672 for ; Tue, 2 Jun 2009 15:42:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0F578FC19 for ; Tue, 2 Jun 2009 15:41:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGPlJEqDaFvL/2dsb2JhbADQSIQLBQ X-IronPort-AV: E=Sophos;i="4.41,291,1241409600"; d="scan'208";a="35138822" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 11:41:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id D8FF88D4084; Tue, 2 Jun 2009 11:41:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGr0Mtd1bxPm; Tue, 2 Jun 2009 11:41:58 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 0BB348D4072; Tue, 2 Jun 2009 11:41:58 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52FhAR18473; Tue, 2 Jun 2009 11:43:10 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 11:43:10 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 15:42:00 -0000 On Tue, 2 Jun 2009, O. Hartmann wrote: > Hello, > since today I get this error when trying to mount a NFS filesystem from NFS > server: > > [udp] foo:/home: RPCPROG_MNT: RPC: Timed out > > Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from > today's buildworld/make kernel. > What's the expression you guys use? "The pointy hat points at me." It looks like I broke parsing of /etc/exports for the case where there are continuation lines (I didn't have any of those in my test examples, but do now;-). Sorry about that. I'll be looking it over more carefully, but I'll bet that the following patch fixes the problem (and I'm guessing you do have contnuation lines in your /etc/exports?). Please try this patch and see if it helps, rick --- test patch for mountd.c --- --- mountd.c.sav 2009-06-02 11:28:19.000000000 -0400 +++ mountd.c 2009-06-02 11:36:53.000000000 -0400 @@ -1191,12 +1191,12 @@ got_nondir = 0; opt_flags = 0; ep = (struct exportlist *)NULL; - dirp = NULL; /* * Handle the V4 root dir. */ if (*cp == 'V' && *(cp + 1) == '4' && *(cp + 2) == ':') { + dirp = NULL; /* * V4: just indicates that it is the v4 root point, * so skip over that and set v4root_phase. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 15:52:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76641106566B for ; Tue, 2 Jun 2009 15:52:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2662E8FC19 for ; Tue, 2 Jun 2009 15:52:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIHnJEqDaFvK/2dsb2JhbADQSoQLBQ X-IronPort-AV: E=Sophos;i="4.41,291,1241409600"; d="scan'208";a="37213868" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 11:52:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 6A926109C25E; Tue, 2 Jun 2009 11:52:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTVNsFmzoi19; Tue, 2 Jun 2009 11:52:25 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id E549F109C257; Tue, 2 Jun 2009 11:52:24 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52Frbs20046; Tue, 2 Jun 2009 11:53:37 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 11:53:37 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "O. Hartmann" In-Reply-To: <4A254194.7080807@zedat.fu-berlin.de> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 15:52:26 -0000 On Tue, 2 Jun 2009, O. Hartmann wrote: > > Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I > do not know why udp is invoked automatically by now. > > But for short, we always did NFS mounts over tcp AND udp, so for tcp it > worked again! > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is required, but you'd only get that if you had used "-o nfsv4" in your mount). I'll take another look at mount_nfs.c too (already caught a problem I introduced in mountd.c). Maybe I unintentionally changed one of the defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.) For udp to work, nfsd must have the "-u" argument. That might be why it wouldn't work? (Still doesn't explain why the default was udp and not tcp.) Anyhow, thanks for doing the testing and I'll email again if I find that I've screwed up the defaults for mount_nfs too. (Is that a "big pointy hat"?:-) rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 16:13:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E673B106564A for ; Tue, 2 Jun 2009 16:13:46 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7053E8FC17 for ; Tue, 2 Jun 2009 16:13:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 244688970; Tue, 02 Jun 2009 19:13:41 +0300 Message-ID: <4A254FB5.3030504@FreeBSD.org> Date: Tue, 02 Jun 2009 19:13:41 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: freebsd-arch@freebsd.org, FreeBSD-Current X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 16:13:47 -0000 Hi. After replying to several similar questions about my ATA plans last time, I have decided to announce things I am working on now together with Scott Long. While learning FreeBSD ATA implementation, I have found, that it has numerous deep problems, from quite fuzzy APIs to different issues in device detection and error recovery. Also, as soon as this infrastructure was written many years ago, it has completely no support for any kind of command queuing, which is normal for the most of modern drives and controllers. Fixing all of this require many significant changes. Also, you may know, that SAS controllers and expanders allow attaching SATA devices and port multipliers to them, by transporting ATA commands over SCSI (SAS) bus. ATAPI, same time, is the way to transport SCSI commands over ATA interface. So deep technologies interoperation pushes us to have similarly integrated infrastructures on software level. We are already have atapicam driver which is used to give CAM SCSI infrastructure access to ATAPI devices by translating drivers API and SCSI bus emulation. But it works only one way and also not perfect. Looking to all of this, I have decided to join Scott, to reanimate his project of making CAM a system's universal infrastructure for both SCSI and ATA. This project is not about some kind of SCSI-to-ATA translation, used by some OS, like OpenBSD. It is about extending CAM, to equally support both SCSI and ATA worlds natively and integrate them as tight as possible. This project is going to have several main steps: - separate SCSI command set and SCSI bus management code from abstract CAM code and create abstract transport API (this step is mostly done now by Scott), - implement ATA command set device drivers, ATA bus management code and ATA host controller drivers (this step is now in progress by me), - update CAM to use newbus, to make it's components interoperation more transparent and formalized (this is now in planning and preparation stage), - when mentioned above finished, port the rest of existing ATA controller drivers one by one to the new world order. Our code now lives in PERFORCE in scottl-camlock project branch. It is in early development, but we already have there working CAM driver for AHCI controller with command queuing and basic NCQ support, simple SATA bus management code and ATA disk driver. I am able now to boot my system and work from SATA drive on AHCI controller, using ATA disk driver, having command queuing and NCQ enabled, read and write disks with SATA ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only with CAM, without using any part of ATA infrastructure. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 16:30:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49BA71065674 for ; Tue, 2 Jun 2009 16:30:07 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outX.internet-mail-service.net (outx.internet-mail-service.net [216.240.47.247]) by mx1.freebsd.org (Postfix) with ESMTP id 31A228FC16 for ; Tue, 2 Jun 2009 16:30:06 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9909822C3; Tue, 2 Jun 2009 09:30:06 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4C5132D6012; Tue, 2 Jun 2009 09:30:06 -0700 (PDT) Message-ID: <4A25538E.5020302@elischer.org> Date: Tue, 02 Jun 2009 09:30:06 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexander Motin References: <4A254FB5.3030504@FreeBSD.org> In-Reply-To: <4A254FB5.3030504@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 16:30:07 -0000 Alexander Motin wrote: > Hi. > > After replying to several similar questions about my ATA plans last > time, I have decided to announce things I am working on now together > with Scott Long. > I can't imagine a team I'd rather have doing it. great news From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 17:21:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 011F41065672 for ; Tue, 2 Jun 2009 17:21:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 837CF8FC16 for ; Tue, 2 Jun 2009 17:21:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 827 invoked by uid 399); 2 Jun 2009 17:21:20 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 17:21:20 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A255F8E.70604@FreeBSD.org> Date: Tue, 02 Jun 2009 10:21:18 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alexander Leidinger References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> In-Reply-To: <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Andriy Gapon Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 17:21:23 -0000 Alexander Leidinger wrote: > What about _flags and also adding a NOP for -C in fsck_msdosfs? Sounds great, I look forward to reviewing your patch. :) Doug From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 17:31:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5B0106575E; Tue, 2 Jun 2009 17:31:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A3A828FC1F; Tue, 2 Jun 2009 17:31:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n52HVLut022347; Tue, 2 Jun 2009 13:31:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n52HVL5M014928; Tue, 2 Jun 2009 13:31:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D455B7302F; Tue, 2 Jun 2009 13:31:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602173120.D455B7302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 13:31:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:31:27 -0000 TB --- 2009-06-02 15:58:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 15:58:59 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-02 15:58:59 - cleaning the object tree TB --- 2009-06-02 15:59:24 - cvsupping the source tree TB --- 2009-06-02 15:59:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-02 15:59:31 - building world TB --- 2009-06-02 15:59:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 15:59:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 15:59:31 - TARGET=pc98 TB --- 2009-06-02 15:59:31 - TARGET_ARCH=i386 TB --- 2009-06-02 15:59:31 - TZ=UTC TB --- 2009-06-02 15:59:31 - __MAKE_CONF=/dev/null TB --- 2009-06-02 15:59:31 - cd /src TB --- 2009-06-02 15:59:31 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 15:59:33 UTC 2009 >>> 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 Tue Jun 2 17:23:04 UTC 2009 TB --- 2009-06-02 17:23:04 - generating LINT kernel config TB --- 2009-06-02 17:23:04 - cd /src/sys/pc98/conf TB --- 2009-06-02 17:23:04 - /usr/bin/make -B LINT TB --- 2009-06-02 17:23:04 - building LINT kernel TB --- 2009-06-02 17:23:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 17:23:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 17:23:04 - TARGET=pc98 TB --- 2009-06-02 17:23:04 - TARGET_ARCH=i386 TB --- 2009-06-02 17:23:04 - TZ=UTC TB --- 2009-06-02 17:23:04 - __MAKE_CONF=/dev/null TB --- 2009-06-02 17:23:04 - cd /src TB --- 2009-06-02 17:23:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 17:23:04 UTC 2009 >>> 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 [...] /src/sys/dev/pci/pci.c:320: error: for each function it appears in.) /src/sys/dev/pci/pci.c:320: error: expected ';' before 'ap' cc1: warnings being treated as errors /src/sys/dev/pci/pci.c:325: warning: implicit declaration of function 'va_start' /src/sys/dev/pci/pci.c:325: warning: nested extern declaration of 'va_start' /src/sys/dev/pci/pci.c:325: error: 'ap' undeclared (first use in this function) /src/sys/dev/pci/pci.c:327: warning: implicit declaration of function 'va_end' /src/sys/dev/pci/pci.c:327: warning: nested extern declaration of 'va_end' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 17:31:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 17:31:20 - ERROR: failed to build lint kernel TB --- 2009-06-02 17:31:20 - 4277.17 user 437.55 system 5540.73 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 17:55:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAFDC1065677 for ; Tue, 2 Jun 2009 17:55:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7808FC1A for ; Tue, 2 Jun 2009 17:55:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30767 invoked by uid 399); 2 Jun 2009 17:55:43 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 17:55:43 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A25679E.5060305@FreeBSD.org> Date: Tue, 02 Jun 2009 10:55:42 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gabor Kovesdan References: <4A246C4D.6080409@FreeBSD.org> In-Reply-To: <4A246C4D.6080409@FreeBSD.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: RFC: Replacing bc/dc to BSDL versions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 17:55:46 -0000 Gabor Kovesdan wrote: > Hello, > > as you might know, I'm working on a BSDL grep. It isn't totally ready > yet, because there are compatibility issues, which I have to resolve. > But looking at another BSDL tools, I've found out that OpenBSD has BSDL > bc and dc utilities. I've thought of replacing them. I think in the > bc/dc case, such a strict GNU compatibility isn't necessary as in the > case of grep, so we may replace them in base system. If there's no > objection to replacing them, I'll post a patch for review. No objection, just a head's up that mergemaster uses bc so please be sure to test that as part of your process. Doug From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 18:27:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D74710656B0 for ; Tue, 2 Jun 2009 18:27:13 +0000 (UTC) (envelope-from lapo@lapo.it) Received: from mail.lapo.it (motoko.lapo.it [88.198.0.105]) by mx1.freebsd.org (Postfix) with ESMTP id BDC2C8FC24 for ; Tue, 2 Jun 2009 18:27:12 +0000 (UTC) (envelope-from lapo@lapo.it) Received: (qmail 97108 invoked by uid 89); 2 Jun 2009 17:59:10 -0000 Received: from unknown (HELO cyberlife.home.lapo.it) (lapo@lapo.it@78.134.17.225) by 0 with ESMTPA; 2 Jun 2009 17:59:10 -0000 Message-ID: <4A256867.8050808@lapo.it> Date: Tue, 02 Jun 2009 19:59:03 +0200 From: Lapo Luchini User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Tim Kientzle References: <49D8D03B.8090302@arcor.de> <3a142e750904050919l1388b559t9bbd751546e239e7@mail.gmail.com> <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> In-Reply-To: <49DFBAEF.1080904@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=C8F252FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, Alex Dupre Subject: Re: xorg loops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 18:27:14 -0000 Tim Kientzle wrote: > AllowEmptyInput hald Result > off enabled Mouse/keyboard delays/jerkiness > off disabled Works > on (default) enabled Works > on (default) disabled No mouse/keyboard Tim, I had your same symptoms (as far as "delays/jerkiness" can go): when using the USB external mouse and leaving it in *some* positions, the whole system was paused until I move the mouse even a little bit, at that point all "missing events" (i.e. all keypresses that didn't produce any output, or also all screen updates) are shown in fast-forward (e.g. the Firefox spinner of a loading tab was stopped until the mouse moved, and made the 3 missing turns rapidly, then all to normal). When the mouse was left in other positions, no problem was shown. After Googling your message I commented-out the AllowEmptyInput line in my xorg.conf and now both internal touchpad and external mouse work perfectly and don't "halt the event queue" (or what it was) anymore. I still wonder the reason behind this behavior but as long as it's working, I won't complain. -- Lapo Luchini - http://lapo.it/ “Beware of bugs in the above code; I have only proved it correct, not tried it.†(Donald Knuth, 1977-03-22) From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 18:40:38 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0185E106568B for ; Tue, 2 Jun 2009 18:40:38 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE548FC14 for ; Tue, 2 Jun 2009 18:40:37 +0000 (UTC) (envelope-from antab@valka.is) Received: from [192.168.1.127] (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n52IOhQw042573; Tue, 2 Jun 2009 20:24:43 +0200 (CEST) (envelope-from antab@valka.is) Message-Id: From: Arnar Mar Sig To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 20:24:43 +0200 References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 18:40:38 -0000 On Jun 2, 2009, at 5:53 PM, Rick Macklem wrote: > On Tue, 2 Jun 2009, O. Hartmann wrote: > >> >> Mounting via '-o nfsv3,tcp' in addition, everthing works all right >> again. I do not know why udp is invoked automatically by now. >> >> But for short, we always did NFS mounts over tcp AND udp, so for >> tcp it worked again! >> > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is > required, but you'd only get that if you had used "-o nfsv4" in your > mount). > > I'll take another look at mount_nfs.c too (already caught a problem I > introduced in mountd.c). Maybe I unintentionally changed one of the > defaults. (I think the default is supposed to be nfsv3,tcp but I'll > look.) > > For udp to work, nfsd must have the "-u" argument. That might be why > it > wouldn't work? (Still doesn't explain why the default was udp and not > tcp.) > > Anyhow, thanks for doing the testing and I'll email again if I find > that I've screwed up the defaults for mount_nfs too. (Is that a > "big pointy hat"?:-) I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD on May 31. I can see MNT RPC packet coming from the avr32 board and running mountd -d shows "mountd: mount successful" when the packet is received but no answer is transmitted, rpc is sent with udp. I can mount the same export from my osx workstation when using tcp. Arnar Mar Sig From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 19:09:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84741106564A; Tue, 2 Jun 2009 19:09:27 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from dd12710.kasserver.com (dd12710.kasserver.com [85.13.134.233]) by mx1.freebsd.org (Postfix) with ESMTP id 67C298FC0A; Tue, 2 Jun 2009 19:09:26 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from localhost.my.domain (ppp-88-217-53-175.dynamic.mnet-online.de [88.217.53.175]) by dd12710.kasserver.com (Postfix) with ESMTP id 982A1184F1059; Tue, 2 Jun 2009 21:09:28 +0200 (CEST) Received: (from guru@localhost) by localhost.my.domain (8.14.3/8.14.3/Submit) id n52J9NjI003536; Tue, 2 Jun 2009 21:09:23 +0200 (CEST) (envelope-from guru@unixarea.de) X-Authentication-Warning: localhost.my.domain: guru set sender to guru@unixarea.de using -f Date: Tue, 2 Jun 2009 21:09:23 +0200 From: Matthias Apitz To: Lapo Luchini Message-ID: <20090602190923.GA3492@current.Sisis.de> References: <1238957462.1829.8.camel@balrog.2hip.net> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <4A256867.8050808@lapo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A256867.8050808@lapo.it> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-CURRENT (i386) Cc: Tim Kientzle , Alex Dupre , freebsd-current@freebsd.org Subject: Re: xorg loops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:09:27 -0000 El día Tuesday, June 02, 2009 a las 07:59:03PM +0200, Lapo Luchini escribió: > Tim Kientzle wrote: > > AllowEmptyInput hald Result > > off enabled Mouse/keyboard delays/jerkiness > > off disabled Works > > on (default) enabled Works > > on (default) disabled No mouse/keyboard > > Tim, I had your same symptoms (as far as "delays/jerkiness" can go): > when using the USB external mouse and leaving it in *some* positions, > the whole system was paused until I move the mouse even a little bit, at > that point all "missing events" (i.e. all keypresses that didn't produce > any output, or also all screen updates) are shown in fast-forward (e.g. > the Firefox spinner of a loading tab was stopped until the mouse moved, > and made the 3 missing turns rapidly, then all to normal). When the > mouse was left in other positions, no problem was shown. > > After Googling your message I commented-out the AllowEmptyInput line in > my xorg.conf and now both internal touchpad and external mouse work > perfectly and don't "halt the event queue" (or what it was) anymore. > > I still wonder the reason behind this behavior but as long as it's > working, I won't complain. I have a *similar* problem; see my posting in -current with Subject: 'problem with mouse when hald is running': when hald is enabled certain events, for example the ButtonReleaseEvent of a mouse click, is delayed until you move the mouse pointer a bit; until now I have AllowEmptyInput set to 'false' and hald disabled, and it works; matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 19:12:15 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33C8A1065808 for ; Tue, 2 Jun 2009 19:12:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EC91B8FC24 for ; Tue, 2 Jun 2009 19:12:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A7FCE46B2C for ; Tue, 2 Jun 2009 15:12:14 -0400 (EDT) Date: Tue, 2 Jun 2009 20:12:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: MAC enabled by default (was: svn commit: r193334 - in head/sys: amd64/conf i386/conf ia64/conf pc98/conf powerpc/conf sparc64/conf sun4v/conf (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 19:12:15 -0000 As an FYI to -CURRENT users: I've enabled "options MAC" in the GENERIC kernel in order to allow MAC users to enable security policy modules without a kernel recompile. By default, it shouldn't change the behavior of the system, and should have negligible performance impact. However, if you run into problems, please let me know -- hopefully we'll have lots of time before 8.0 to shake them out. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ---------- Forwarded message ---------- Date: Tue, 2 Jun 2009 18:31:08 +0000 (UTC) From: Robert Watson To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r193334 - in head/sys: amd64/conf i386/conf ia64/conf pc98/conf powerpc/conf sparc64/conf sun4v/conf Author: rwatson Date: Tue Jun 2 18:31:08 2009 New Revision: 193334 URL: http://svn.freebsd.org/changeset/base/193334 Log: Remove MAC kernel config files and add "options MAC" to GENERIC, with the goal of shipping 8.0 with MAC support in the default kernel. No policies will be compiled in or enabled by default, but it will now be possible to load them at boot or runtime without a kernel recompile. While the framework is not believed to impose measurable overhead when no policies are loaded (a result of optimization over the past few months in HEAD), we'll continue to benchmark and optimize as the release approaches. Please keep an eye out for performance or functionality regressions that could be a result of this change. Approved by: re (kensmith) Obtained from: TrustedBSD Project Deleted: head/sys/amd64/conf/MAC head/sys/i386/conf/MAC head/sys/ia64/conf/MAC head/sys/pc98/conf/MAC head/sys/powerpc/conf/MAC head/sys/sparc64/conf/MAC head/sys/sun4v/conf/MAC Modified: head/sys/amd64/conf/GENERIC head/sys/i386/conf/GENERIC head/sys/ia64/conf/GENERIC head/sys/pc98/conf/GENERIC head/sys/powerpc/conf/GENERIC head/sys/sparc64/conf/GENERIC head/sys/sun4v/conf/GENERIC Modified: head/sys/amd64/conf/GENERIC ============================================================================== --- head/sys/amd64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/amd64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -70,6 +70,7 @@ options KBD_INSTALL_CDEV # install a CD options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework #options KDTRACE_FRAME # Ensure frames are compiled in #options KDTRACE_HOOKS # Kernel DTrace hooks Modified: head/sys/i386/conf/GENERIC ============================================================================== --- head/sys/i386/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/i386/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -71,6 +71,7 @@ options KBD_INSTALL_CDEV # install a CD options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework #options KDTRACE_HOOKS # Kernel DTrace hooks # Debugging for use in -current Modified: head/sys/ia64/conf/GENERIC ============================================================================== --- head/sys/ia64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/ia64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -40,6 +40,7 @@ options INVARIANTS # Enable calls of ex options INVARIANT_SUPPORT # required by INVARIANTS options KDB # Enable kernel debugger support options KTRACE # ktrace(1) syscall trace support +options MAC # TrustedBSD MAC Framework options MD_ROOT # MD usable as root device options MSDOSFS # MSDOS Filesystem options NFSCLIENT # Network Filesystem Client Modified: head/sys/pc98/conf/GENERIC ============================================================================== --- head/sys/pc98/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/pc98/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -73,6 +73,7 @@ options _KPOSIX_PRIORITY_SCHEDULING # P options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. Modified: head/sys/powerpc/conf/GENERIC ============================================================================== --- head/sys/powerpc/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/powerpc/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -64,6 +64,7 @@ options SYSVSEM #SYSV-style semaphore options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB #Enable the kernel debugger Modified: head/sys/sparc64/conf/GENERIC ============================================================================== --- head/sys/sparc64/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/sparc64/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -65,6 +65,7 @@ options SYSVSEM # SYSV-style semaphor options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. Modified: head/sys/sun4v/conf/GENERIC ============================================================================== --- head/sys/sun4v/conf/GENERIC Tue Jun 2 18:30:09 2009 (r193333) +++ head/sys/sun4v/conf/GENERIC Tue Jun 2 18:31:08 2009 (r193334) @@ -66,6 +66,7 @@ options AHC_REG_PRETTY_PRINT # Print re options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing +options MAC # TrustedBSD MAC Framework # Debugging for use in -current options KDB # Enable kernel debugger support. From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 19:20:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED04106564A for ; Tue, 2 Jun 2009 19:20:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B511B8FC1A for ; Tue, 2 Jun 2009 19:20:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15110 invoked by uid 399); 2 Jun 2009 19:20:35 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 19:20:35 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A257B82.1000701@FreeBSD.org> Date: Tue, 02 Jun 2009 12:20:34 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 19:20:42 -0000 Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 19:35:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0F111065670 for ; Tue, 2 Jun 2009 19:35:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE058FC15 for ; Tue, 2 Jun 2009 19:35:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHccJUqDaFvK/2dsb2JhbADPfoQLBQ X-IronPort-AV: E=Sophos;i="4.41,292,1241409600"; d="scan'208";a="35165876" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 15:35:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id A8465109C25E; Tue, 2 Jun 2009 15:35:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OneC0NTWf14H; Tue, 2 Jun 2009 15:35:20 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 636B9109C257; Tue, 2 Jun 2009 15:35:19 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52JaUN24459; Tue, 2 Jun 2009 15:36:30 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 15:36:30 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Arnar Mar Sig In-Reply-To: Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 19:35:33 -0000 On Tue, 2 Jun 2009, Arnar Mar Sig wrote: > > > I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD > on May 31. > > I can see MNT RPC packet coming from the avr32 board and running mountd -d > shows "mountd: mount successful" when the packet is received but no answer is > transmitted, rpc is sent with udp. > I can mount the same export from my osx workstation when using tcp. > Ok, I've poked at it a little more and the case that seems to be broken is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.) I haven't yet figured out why that case is broken, but I'll keep fiddling with it. (For me the getaddrinfo() fails for this case.) If you are not using the "-h" option on nfsd and udp isn't working, I haven't got an explanation, because it seems to work for me? rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 19:57:06 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9A2C1065679 for ; Tue, 2 Jun 2009 19:57:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0AA48FC19 for ; Tue, 2 Jun 2009 19:57:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 76E3846B23; Tue, 2 Jun 2009 15:57:06 -0400 (EDT) Date: Tue, 2 Jun 2009 20:57:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rick Macklem In-Reply-To: Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 19:57:07 -0000 On Tue, 2 Jun 2009, Rick Macklem wrote: >> Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I >> do not know why udp is invoked automatically by now. >> >> But for short, we always did NFS mounts over tcp AND udp, so for tcp it >> worked again! >> > Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is > required, but you'd only get that if you had used "-o nfsv4" in your mount). > > I'll take another look at mount_nfs.c too (already caught a problem I > introduced in mountd.c). Maybe I unintentionally changed one of the > defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.) I'm running into a similar-sounding but odd problem on a diskless NFS client test box running 8.0, but talking to a server running 7.0: cheetah# mount -o rw -u / [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to send If I do a fresh file system mount it works fine: cheetah# mount 192.168.5.1:/zoo /zoo cheetah# mount 192.168.5.1:/zoo/cheetah on / (nfs, read-only) devfs on /dev (devfs, local) /dev/md0 on /var (ufs, local) /dev/md1 on /tmp (ufs, local) 192.168.5.1:/zoo on /zoo (nfs) This is with an approximately 26 May userspace. Robert N M Watson Computer Laboratory University of Cambridge > > For udp to work, nfsd must have the "-u" argument. That might be why it > wouldn't work? (Still doesn't explain why the default was udp and not > tcp.) > > Anyhow, thanks for doing the testing and I'll email again if I find > that I've screwed up the defaults for mount_nfs too. (Is that a > "big pointy hat"?:-) > > rick > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 15:54:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33361065678 for ; Tue, 2 Jun 2009 15:54:54 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFBF8FC32 for ; Tue, 2 Jun 2009 15:54:53 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 244687062; Tue, 02 Jun 2009 18:54:46 +0300 Message-ID: <4A254B45.8050800@mavhome.dp.ua> Date: Tue, 02 Jun 2009 18:54:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: freebsd-arch@freebsd.org, FreeBSD-Current Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2009 20:34:06 +0000 Cc: Subject: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 15:54:55 -0000 Hi. After replying to several similar questions about my ATA plans last time, I have decided to announce things I am working on now together with Scott Long. While learning FreeBSD ATA implementation, I have found, that it has numerous deep problems, from quite fuzzy APIs to different issues in device detection and error recovery. Also, as soon as this infrastructure was written many years ago, it has completely no support for any kind of command queuing, which is normal for the most of modern drives and controllers. Fixing all of this require many significant changes. Also, you may know, that SAS controllers and expanders allow attaching SATA devices and port multipliers to them, by transporting ATA commands over SCSI (SAS) bus. ATAPI, same time, is the way to transport SCSI commands over ATA interface. So deep technologies interoperation pushes us to have similarly integrated infrastructures on software level. We are already have atapicam driver which is used to give CAM SCSI infrastructure access to ATAPI devices by translating drivers API and SCSI bus emulation. But it works only one way and also not perfect. Looking to all of this, I have decided to join Scott, to reanimate his project of making CAM a system's universal infrastructure for both SCSI and ATA. This project is not about some kind of SCSI-to-ATA translation, used by some OS, like OpenBSD. It is about extending CAM, to equally support both SCSI and ATA worlds natively and integrate them as tight as possible. This project is going to have several main steps: - separate SCSI command set and SCSI bus management code from abstract CAM code and create abstract transport API (this step is mostly done now by Scott), - implement ATA command set device drivers, ATA bus management code and ATA host controller drivers (this step is now in progress by me), - update CAM to use newbus, to make it's components interoperation more transparent and formalized (this is now in planning and preparation stage), - when mentioned above finished, port the rest of existing ATA controller drivers one by one to the new world order. Our code now lives in PERFORCE in scottl-camlock project branch. It is in early development, but we already have there working CAM driver for AHCI controller with command queuing and basic NCQ support, simple SATA bus management code and ATA disk driver. I am able now to boot my system and work from SATA drive on AHCI controller, using ATA disk driver, having command queuing and NCQ enabled, read and write disks with SATA ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only with CAM, without using any part of ATA infrastructure. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 20:49:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFF79106568E for ; Tue, 2 Jun 2009 20:49:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 89D508FC2B for ; Tue, 2 Jun 2009 20:49:06 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 30078 invoked by uid 399); 2 Jun 2009 20:48:57 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Jun 2009 20:48:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A259039.8040001@FreeBSD.org> Date: Tue, 02 Jun 2009 13:48:57 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ruben van Staveren References: <4A257B82.1000701@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 20:49:07 -0000 Ruben van Staveren wrote: > Being a bit of my own devils advocate here, network_interfaces="AUTO" is > already true for ipv6. FYI, ipv6_network_interfaces exists for this purpose. Thanks for your post, it's good information to add to the pile. Doug From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 20:30:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 695DA106566B; Tue, 2 Jun 2009 20:30:51 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id ED6558FC18; Tue, 2 Jun 2009 20:30:50 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from [192.168.1.22] (helium.xs4all.nl [194.109.251.55]) (authenticated bits=0) by erg.verweg.com (8.14.3/8.14.3) with ESMTP id n52KUlcx068558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Jun 2009 20:30:47 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host helium.xs4all.nl [194.109.251.55] claimed to be [192.168.1.22] Message-Id: From: Ruben van Staveren To: Doug Barton In-Reply-To: <4A257B82.1000701@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 22:30:46 +0200 References: <4A257B82.1000701@FreeBSD.org> X-Mailer: Apple Mail (2.935.3) X-Spam-Status: No, score=3.3 required=5.0 tests=DATE_IN_FUTURE_12_24 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Virus-Scanned: ClamAV 0.94.2/9414/Tue Jun 2 11:11:57 2009 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (erg.verweg.com [94.142.245.8]); Tue, 02 Jun 2009 20:30:49 +0000 (UTC) X-Mailman-Approved-At: Tue, 02 Jun 2009 20:49:42 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 20:30:52 -0000 On 2 Jun 2009, at 21:20, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I removed > that warning in HEAD Sunday, and there is no a discussion about > whether or not it should be put back, and whether or not there is any > need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1="down" and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces="AUTO" is already true for ipv6. with network_interfaces="bge0 lo0" network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. you want to have a system where one still can control which interfaces are explicitly configured or skipped, with no side effects of default actions > > > Thanks, > > Doug > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > Regards, Ruben From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 21:03:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA30A1065673 for ; Tue, 2 Jun 2009 21:03:52 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 262AB8FC12 for ; Tue, 2 Jun 2009 21:03:51 +0000 (UTC) (envelope-from antab@valka.is) Received: from dumb.farm.antab.is (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n52L3oSH033837; Tue, 2 Jun 2009 23:03:50 +0200 (CEST) (envelope-from antab@valka.is) Message-Id: <63C3AB3D-5500-4693-BAD6-AE760F623B96@valka.is> From: Arnar Mar Sig To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 23:03:50 +0200 References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 21:03:52 -0000 On Jun 2, 2009, at 9:36 PM, Rick Macklem wrote: > > > On Tue, 2 Jun 2009, Arnar Mar Sig wrote: > >> >> >> I'm having troubles with nfsroot on avr32 after updating my dev box >> to HEAD on May 31. >> >> I can see MNT RPC packet coming from the avr32 board and running >> mountd -d shows "mountd: mount successful" when the packet is >> received but no answer is transmitted, rpc is sent with udp. >> I can mount the same export from my osx workstation when using tcp. >> > Ok, I've poked at it a little more and the case that seems to be > broken > is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or > with "-h 131.104.49.243" it seems to work. (This affects udp but not > tcp.) > > I haven't yet figured out why that case is broken, but I'll keep > fiddling > with it. (For me the getaddrinfo() fails for this case.) > > If you are not using the "-h" option on nfsd and udp isn't working, I > haven't got an explanation, because it seems to work for me? > > rick > I'm using the default "-u -t -n 4". I rebuilt everything with checkout from today and tested with osx and linux clients. both show the same results, viewing traffic with wireshark shows no response packet sent when using udp. osx: dumb:~ antab$ mount_nfs -o udp 192.168.1.254:/home/antab/avr32-root test/ mount_nfs: bad MNT RPC: RPC: Timed out\n mount_nfs: bad MNT RPC: RPC: Timed out\n mount_nfs: can't access /home/antab/avr32-root: Permission denied dumb:~ antab$ mount_nfs -o tcp 192.168.1.254:/home/antab/avr32-root test/ dumb:~ antab$ umount test/ Bad MNT RPC: RPC: Timed out (osx seems to always send the UMNT rpc with udp) linux: antab@thordis:~$ sudo mount -t nfs -o udp 192.168.1.254:/home/antab/ avr32-root test/ mount.nfs: mount system call failed antab@thordis:~$ sudo mount -t nfs -o tcp 192.168.1.254:/home/antab/ avr32-root test/ antab@thordis:~$ umount test/ Arnar Mar Sig From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 21:05:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D08810656EA for ; Tue, 2 Jun 2009 21:05:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0A8308FC26 for ; Tue, 2 Jun 2009 21:05:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFMxJUqDaFvI/2dsb2JhbADPVIQLBQ X-IronPort-AV: E=Sophos;i="4.41,293,1241409600"; d="scan'208";a="37246802" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 17:05:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 5DA69940062; Tue, 2 Jun 2009 17:05:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmjyEJ2Ra6wW; Tue, 2 Jun 2009 17:05:16 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 148039400AA; Tue, 2 Jun 2009 17:05:16 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52L6RL08376; Tue, 2 Jun 2009 17:06:27 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 17:06:27 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Arnar Mar Sig In-Reply-To: Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 21:05:19 -0000 On Tue, 2 Jun 2009, Rick Macklem wrote: >> >> >> I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD >> on May 31. >> >> I can see MNT RPC packet coming from the avr32 board and running mountd -d >> shows "mountd: mount successful" when the packet is received but no answer >> is transmitted, rpc is sent with udp. >> I can mount the same export from my osx workstation when using tcp. >> > Ok, I've poked at it a little more and the case that seems to be broken > is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or > with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.) > > I haven't yet figured out why that case is broken, but I'll keep fiddling > with it. (For me the getaddrinfo() fails for this case.) > > If you are not using the "-h" option on nfsd and udp isn't working, I > haven't got an explanation, because it seems to work for me? > I typed the above (and the bit about /etc/exports continuation lines) before I had poked around with it enough. The continuation lines seem to work and the "-h nfs-server.cis.uoguelph.ca" message logged is just because I'm using ipv4 only. I seem to get udp mounts to work fine, but... I've seen what Robert mentioned. I had just assumed it was some weirdness in my local lan. I've found that, if you "ping " before doing the mount, it seems to always work. (I usually see it when mounting a Solaris10 client to the FreeBSD8 server and it eventually times out and retries successfully. I normally use tcp mounts, so I didn't "connect" that with this problem.) So, maybe it's some network interaction issue and not an obvious goof up by me w.r.t. changes in the utilities? (The changes I did shouldn't have had anything to do with the mount protocol code in them.) rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 21:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDD681065673; Tue, 2 Jun 2009 21:31:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 62F0F8FC0A; Tue, 2 Jun 2009 21:31:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC83JUqDaFvJ/2dsb2JhbADPaoQLBQ X-IronPort-AV: E=Sophos;i="4.41,293,1241409600"; d="scan'208";a="37248877" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Jun 2009 17:31:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 828F2FB8042; Tue, 2 Jun 2009 17:31:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHqJDX4QXbgr; Tue, 2 Jun 2009 17:31:17 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id BB9CAFB801F; Tue, 2 Jun 2009 17:31:17 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n52LWTl12240; Tue, 2 Jun 2009 17:32:29 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 2 Jun 2009 17:32:29 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, "O. Hartmann" Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 21:31:20 -0000 On Tue, 2 Jun 2009, Robert Watson wrote: > > I'm running into a similar-sounding but odd problem on a diskless NFS client > test box running 8.0, but talking to a server running 7.0: > > cheetah# mount -o rw -u / > [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable > to send > > If I do a fresh file system mount it works fine: > I just saw one almost the same as this. When I did an nfsv3,tcp mount I got a similar message, but it was for the NFS NULL RPC. I left it and after a while it retried and succeeded. I tried rebooting the client and server a couple of times, but wasn't able to get it to happen again. So, I wonder if what the others were seeing was something similar? rick (ps: I'm running a current kernel and nfs related utilities, but really old Feb. userland for the rest.) From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:00:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F284106571D for ; Tue, 2 Jun 2009 22:00:56 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id C3BD78FC2E for ; Tue, 2 Jun 2009 22:00:55 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 02 Jun 2009 18:00:55 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.5-GA) with ESMTP id PYC58560; Tue, 2 Jun 2009 18:00:54 -0400 (EDT) Received: from 209-6-22-188.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 02 Jun 2009 18:00:54 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18981.41237.246524.796@jerusalem.litteratus.org> Date: Tue, 2 Jun 2009 18:00:53 -0400 To: Ruben van Staveren In-Reply-To: References: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:00:57 -0000 Ruben van Staveren writes: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I removed > > that warning in HEAD Sunday, and there is no a discussion about > > whether or not it should be put back, and whether or not there is any > > need for the user to specify the list of network interfaces at all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. What he said. In my case complicated by the fact the interfaces in question do some wierd-ass initialization (which is legacy from like sometime in 5.x and might be unnecessary ... but it took a long time to get working and isn't broke). Robert Huff From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:06:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C02010656B5; Tue, 2 Jun 2009 22:06:13 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01F0E8FC15; Tue, 2 Jun 2009 22:06:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52M6Odo018821; Tue, 2 Jun 2009 17:06:24 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52M6OeV018820; Tue, 2 Jun 2009 17:06:24 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:06:24 -0500 From: Brooks Davis To: David Kelly Message-ID: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hxkXGo8AKqTJ+9QI" Content-Disposition: inline In-Reply-To: <20090602205125.GA75470@Grumpy.DynDNS.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:06:24 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, Ruben van Staveren , freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:06:14 -0000 --hxkXGo8AKqTJ+9QI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote: > On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > >=20 > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > >=20 > > >Up till Sunday in 8-current, and for a long time in general > > >network.subr (part of the rc.d system) has emitted a warning that > > >values of network_interfaces other than AUTO are deprecated. I > > >removed that warning in HEAD Sunday, and there is no a discussion > > >about whether or not it should be put back, and whether or not there > > >is any need for the user to specify the list of network interfaces at > > >all. > >=20 > > Well, I do. > >=20 > > I only want to configure only the interfaces that are connected and > > that I know about. especially in combination with IPv6 there is a nit > > that you'll get autoconfiguration for all interfaces unless they are > > all explicitly configured. >=20 > And while I'm not currently using anything other than AUTO I would think > there is a security ramification if someone were to plug in to a > supposedly unused port, then reboot the machine to prompt AUTO to > configure their interface. >=20 > Its not just a security thing, its an "idiot-proof" thing. If someone is > moving machines around I don't want them to come up and partially work > if the wires are plugged into the wrong holes. Would rather it be > completely broken. >=20 > I think its good that there is an AUTO *option*. Is also OK that it be > the default. I don't think mandatory AUTO is good, if I want a port > disabled then I want it to stay disabled. To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. For the system to do something with an interface the following must be true: - It makes it in to the list of interfaces somehow (either by adding it to network_interfaces or leaving network_interfaces alone) - It actually exists or is create early in the process via cloned_interfaces, gif_interfaces, etc - The ifconfig_ variable is set (I think i can be "", but "up" is always a good choice if you just want a stub. - The ifconfig_ variable must not contain the NOAUTO keyword. If all of those things are true, the interface will be configured at startup or on insert. Otherwise, it won't be. -- Brooks [0] This is at least true in the IPv4 case, the IPv6 case really needs work. I thought someone had patches to bring the IPv6 support up to par with the IPv4 case, but they haven't been committed yet. --hxkXGo8AKqTJ+9QI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaJfXY6L6fI4GtQRAsTIAJ44ujZ0IyN+UOFfrEYO+fOuoPJU/QCfUQ9L QDD118Wna7ApeNBlsLL0pcE= =56aR -----END PGP SIGNATURE----- --hxkXGo8AKqTJ+9QI-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:09:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20DF510656A8; Tue, 2 Jun 2009 22:09:22 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 843BC8FC23; Tue, 2 Jun 2009 22:09:21 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52M9X5G018858; Tue, 2 Jun 2009 17:09:33 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52M9XvM018857; Tue, 2 Jun 2009 17:09:33 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:09:33 -0500 From: Brooks Davis To: Ruben van Staveren Message-ID: <20090602220933.GE15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q8BnQc91gJZX4vDc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:09:33 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:09:23 -0000 --Q8BnQc91gJZX4vDc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: >=20 > On 2 Jun 2009, at 21:20, Doug Barton wrote: >=20 >> Up till Sunday in 8-current, and for a long time in general >> network.subr (part of the rc.d system) has emitted a warning that >> values of network_interfaces other than AUTO are deprecated. I removed >> that warning in HEAD Sunday, and there is no a discussion about >> whether or not it should be put back, and whether or not there is any >> need for the user to specify the list of network interfaces at all. >=20 > Well, I do. >=20 > I only want to configure only the interfaces that are connected and that = I=20 > know about. especially in combination with IPv6 there is a nit that you'l= l=20 > get autoconfiguration for all interfaces unless they are all explicitly= =20 > configured. See my other post on why this is a needless worry for the IPv4 case. > e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a=20 > ipv6_ifconfig_bge1=3D"down" and nail network_interfaces to bge0 bge1 lo0 = only=20 > I'll get autoconfiguration of v6 where I don't want it to be. >=20 >=20 > Being a bit of my own devils advocate here, network_interfaces=3D"AUTO" i= s=20 > already true for ipv6. with network_interfaces=3D"bge0 lo0" network.subr= =20 > nevertheless sees bge1, and no configuration and takes the responsibility= =20 > of starting ipv6 autoconfiguration for it. The IPv6 case is clearly a bug. We should really consolidate the two cases and I think there are patches to do so if someone wants to setup up and help get them in. -- Brooks --Q8BnQc91gJZX4vDc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaMbXY6L6fI4GtQRApXSAJ409BZvxW77XiaT8jHFpTh5YJgHEQCg2AiK y4z8ZdrHH5k//BBnWsrv4mc= =lupY -----END PGP SIGNATURE----- --Q8BnQc91gJZX4vDc-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:20:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53BC8106566B; Tue, 2 Jun 2009 22:20:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 307CF8FC1B; Tue, 2 Jun 2009 22:20:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBcLq-000KsI-DR; Tue, 02 Jun 2009 22:20:58 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id DD2A41DA5B0B; Wed, 3 Jun 2009 07:20:57 +0900 (JST) Date: Wed, 03 Jun 2009 07:20:57 +0900 Message-ID: From: Randy Bush To: Ruben van Staveren In-Reply-To: References: <4A257B82.1000701@FreeBSD.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:20:59 -0000 > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. bingo! From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:22:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC1C106564A; Tue, 2 Jun 2009 22:22:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3BB968FC1D; Tue, 2 Jun 2009 22:22:35 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MBcNO-000KsQ-Ng; Tue, 02 Jun 2009 22:22:34 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 1E09C1DA5DA1; Wed, 3 Jun 2009 07:22:34 +0900 (JST) Date: Wed, 03 Jun 2009 07:22:34 +0900 Message-ID: From: Randy Bush To: Brooks Davis In-Reply-To: <20090602220624.GD15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: David Kelly , Doug Barton , freebsd-stable@freebsd.org, Ruben van Staveren , freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:22:35 -0000 > To repeat what I wrote earlier today on another list there's no need > to worry about hot plugged or newly added interfaces getting magically > configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? randy From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:24:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF792106568B; Tue, 2 Jun 2009 22:24:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3278FC2C; Tue, 2 Jun 2009 22:24:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n52MOjC2077840; Tue, 2 Jun 2009 18:24:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n52MOjBh088332; Tue, 2 Jun 2009 18:24:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2F6017302F; Tue, 2 Jun 2009 18:24:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Date: Tue, 2 Jun 2009 18:24:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 22:24:48 -0000 TB --- 2009-06-02 20:49:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-02 20:49:59 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-02 20:49:59 - cleaning the object tree TB --- 2009-06-02 20:50:33 - cvsupping the source tree TB --- 2009-06-02 20:50:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-02 20:50:43 - building world TB --- 2009-06-02 20:50:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 20:50:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 20:50:43 - TARGET=sun4v TB --- 2009-06-02 20:50:43 - TARGET_ARCH=sparc64 TB --- 2009-06-02 20:50:43 - TZ=UTC TB --- 2009-06-02 20:50:43 - __MAKE_CONF=/dev/null TB --- 2009-06-02 20:50:43 - cd /src TB --- 2009-06-02 20:50:43 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 2 20:50:45 UTC 2009 >>> 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 Tue Jun 2 22:09:39 UTC 2009 TB --- 2009-06-02 22:09:39 - generating LINT kernel config TB --- 2009-06-02 22:09:39 - cd /src/sys/sun4v/conf TB --- 2009-06-02 22:09:39 - /usr/bin/make -B LINT TB --- 2009-06-02 22:09:39 - building LINT kernel TB --- 2009-06-02 22:09:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-02 22:09:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-02 22:09:39 - TARGET=sun4v TB --- 2009-06-02 22:09:39 - TARGET_ARCH=sparc64 TB --- 2009-06-02 22:09:39 - TZ=UTC TB --- 2009-06-02 22:09:39 - __MAKE_CONF=/dev/null TB --- 2009-06-02 22:09:39 - cd /src TB --- 2009-06-02 22:09:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 2 22:09:39 UTC 2009 >>> 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 -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -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 -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/sun4v/sun4v/hcall.S 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 -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/sun4v/sun4v/hviommu.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 -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/sparc64/sparc64/identcpu.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 -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/sparc64/sparc64/in_cksum.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 -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/sun4v/sun4v/intr_machdep.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 -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-02 22:24:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-02 22:24:45 - ERROR: failed to build lint kernel TB --- 2009-06-02 22:24:45 - 4661.38 user 422.42 system 5685.48 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 22:48:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B0CB10656FB; Tue, 2 Jun 2009 22:48:41 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id BDC038FC15; Tue, 2 Jun 2009 22:48:40 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n52MmqQp019195; Tue, 2 Jun 2009 17:48:52 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n52MmqUL019194; Tue, 2 Jun 2009 17:48:52 -0500 (CDT) (envelope-from brooks) Date: Tue, 2 Jun 2009 17:48:52 -0500 From: Brooks Davis To: Randy Bush Message-ID: <20090602224852.GF15552@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602205125.GA75470@Grumpy.DynDNS.org> <20090602220624.GD15552@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TU+u6i6jrDPzmlWF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Jun 2009 17:48:52 -0500 (CDT) Cc: David Kelly , Doug Barton , freebsd-stable@freebsd.org, Ruben van Staveren , freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 22:48:42 -0000 --TU+u6i6jrDPzmlWF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote: > > To repeat what I wrote earlier today on another list there's no need > > to worry about hot plugged or newly added interfaces getting magically > > configured to do dhcp or anything else[0]. >=20 > such as detected by services such as bind/unbound? The rc system will do nothing with interfaces that don't pass the tests I enumerated so if you don't have an ifconfig_ interface there won't be any difference no matter how you set network_interfaces. I'd be rather supprised if bind did anything with interaces that weren't configured with an address (or even up in the case of correctly funtioning drivers). -- Brooks --TU+u6i6jrDPzmlWF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJaxTXY6L6fI4GtQRAgh6AJ9zQvOVNC5NIoQAvjfljCTRAjF4+QCbBiCZ UuhCwCv4FQm3vK9Nvh7CqDY= =+BW4 -----END PGP SIGNATURE----- --TU+u6i6jrDPzmlWF-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 23:26:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F2E910656AA; Tue, 2 Jun 2009 23:26:35 +0000 (UTC) (envelope-from erik@barragry.com) Received: from cork.barragry.com (cork.barragry.com [72.232.202.93]) by mx1.freebsd.org (Postfix) with ESMTP id 5241E8FC0C; Tue, 2 Jun 2009 23:26:35 +0000 (UTC) (envelope-from erik@barragry.com) Received: by cork.barragry.com (Postfix, from userid 1006) id 1F57E1D8012; Tue, 2 Jun 2009 18:06:48 -0500 (CDT) Date: Tue, 2 Jun 2009 18:06:48 -0500 From: Erik Osterholm To: Doug Barton Message-ID: <20090602230648.GB88740@barragry.com> References: <4A257B82.1000701@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A257B82.1000701@FreeBSD.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 23:26:36 -0000 On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > Up till Sunday in 8-current, and for a long time in general > network.subr (part of the rc.d system) has emitted a warning that > values of network_interfaces other than AUTO are deprecated. I > removed that warning in HEAD Sunday, and there is no a discussion > about whether or not it should be put back, and whether or not there > is any need for the user to specify the list of network interfaces > at all. > > If you use a value of network_interfaces other than AUTO please > speak up so that we can make an intelligent decision about this > issue. > > Thanks, > > Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik From owner-freebsd-current@FreeBSD.ORG Tue Jun 2 21:19:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B62351065673 for ; Tue, 2 Jun 2009 21:19:27 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by mx1.freebsd.org (Postfix) with ESMTP id 66E568FC1D for ; Tue, 2 Jun 2009 21:19:26 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: (qmail 20006 invoked by uid 0); 2 Jun 2009 20:51:25 -0000 Received: from unknown (HELO Grumpy.DynDNS.org) (24.42.224.110) by smtp7.knology.net with SMTP; 2 Jun 2009 20:51:25 -0000 Received: by Grumpy.DynDNS.org (Postfix, from userid 928) id 38EEA2841F; Tue, 2 Jun 2009 15:51:25 -0500 (CDT) Date: Tue, 2 Jun 2009 15:51:25 -0500 From: David Kelly To: Ruben van Staveren Message-ID: <20090602205125.GA75470@Grumpy.DynDNS.org> References: <4A257B82.1000701@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Wed, 03 Jun 2009 01:41:04 +0000 Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Jun 2009 21:19:28 -0000 On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: > > On 2 Jun 2009, at 21:20, Doug Barton wrote: > > >Up till Sunday in 8-current, and for a long time in general > >network.subr (part of the rc.d system) has emitted a warning that > >values of network_interfaces other than AUTO are deprecated. I > >removed that warning in HEAD Sunday, and there is no a discussion > >about whether or not it should be put back, and whether or not there > >is any need for the user to specify the list of network interfaces at > >all. > > Well, I do. > > I only want to configure only the interfaces that are connected and > that I know about. especially in combination with IPv6 there is a nit > that you'll get autoconfiguration for all interfaces unless they are > all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an "idiot-proof" thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. A quick glance of my 7.2-STABLE machine only found network_interfaces used in /etc/defaults/rc.conf. ipv6_network_interfaces is used in many places. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 03:18:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F920106564A for ; Wed, 3 Jun 2009 03:18:49 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from mail.jeamland.net (rafe.jeamland.net [203.20.99.33]) by mx1.freebsd.org (Postfix) with ESMTP id B140C8FC19 for ; Wed, 3 Jun 2009 03:18:48 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from mail.jeamland.net (localhost [127.0.0.1]) by mail.jeamland.net (Postfix) with ESMTP id 489C71CD7F for ; Wed, 3 Jun 2009 13:03:16 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rafe.jeamland.net X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [10.1.7.168] (ppp154-45.static.internode.on.net [150.101.154.45]) by mail.jeamland.net (Postfix) with ESMTPSA id C1CEF1CD7D for ; Wed, 3 Jun 2009 13:03:15 +1000 (EST) Message-Id: From: Benno Rice To: current@freebsd.org Content-Type: multipart/mixed; boundary=Apple-Mail-4--596983795 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 13:03:08 +1000 X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: ClamAV using ClamSMTP at rafe.jeamland.net Cc: Subject: CFR: sanity checking arguments to kldload(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 03:18:49 -0000 --Apple-Mail-4--596983795 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The attached patch performs some sanity checking on arguments passed to kldload(8). Specifically, if an argument looks like a filename but lacks a path (eg, 'xfs.ko' as opposed to 'xfs' or './xfs.ko') it checks to see if a file with that name is in the current directory. If it is, it checks the current module path to see if a file with that name also exists there (possibly in an earlier entry if the current directory is in the module path), if so it warns the user that that module will be loaded and not the one in the current directory. If not, it tells the user how to use a path to load the module. A -q option is added to quieten the output if desired. Sample output: # sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # pwd /boot/kernel # kldload xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # cd /boot/modules # pwd /boot/modules # ls xfs.ko* xfs.ko.symbols* # kldload xfs.ko kldload: xfs.ko will be loaded from /boot/kernel, not the current directory kldload: to load from the current directory use ./xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # kldload -q xfs.ko # kldstat Id Refs Address Size Name 1 3 0xc0400000 cc016c kernel 2 1 0xc3a09000 b0000 xfs.ko # kldunload xfs # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # cd fnord # pwd /boot/modules/fnord # ls ibcs2.ko* ibcs2.ko.symbols* # ls /boot/kernel/ibcs2.ko ls: /boot/kernel/ibcs2.ko: No such file or directory # ls /boot/modules/ibcs2.ko ls: /boot/modules/ibcs2.ko: No such file or directory # kldload ibcs2.ko kldload: ibcs2.ko is not in the module path kldload: to load from the current directory use ./ibcs2.ko # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # kldload -q ibcs2.ko # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel # kldload ./ibcs2.ko # kldstat Id Refs Address Size Name 1 6 0xc0400000 cc016c kernel 2 1 0xc3a09000 b000 ibcs2.ko # kldunload ibcs2 # kldstat Id Refs Address Size Name 1 1 0xc0400000 cc016c kernel --Apple-Mail-4--596983795 Content-Disposition: attachment; filename=kldload.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="kldload.diff" Content-Transfer-Encoding: 7bit Index: sbin/kldload/kldload.c =================================================================== --- sbin/kldload/kldload.c (revision 193292) +++ sbin/kldload/kldload.c (working copy) @@ -30,10 +30,103 @@ #include #include #include +#include #include #include #include +#include +#include +#include +#define PATHCTL "kern.module_path" + +/* + * Check to see if the requested module is specified as a filename with no + * path. If so and if a file by the same name exists in the module path, + * warn the user that the module in the path will be used in preference. + */ +static int +path_check(const char *kldname, int quiet) +{ + int mib[5], found; + size_t miblen, pathlen; + char kldpath[MAXPATHLEN]; + char *path, *tmppath, *element; + struct stat sb; + dev_t dev; + ino_t ino; + + if (strchr(kldname, '/') != NULL) { + return (0); + } + if (strstr(kldname, ".ko") == NULL) { + return (0); + } + if (stat(kldname, &sb) != 0) { + return (0); + } + + found = 0; + dev = sb.st_dev; + ino = sb.st_ino; + + miblen = sizeof(mib) / sizeof(mib[0]); + if (sysctlnametomib(PATHCTL, mib, &miblen) != 0) { + err(1, "sysctlnametomib(%s)", PATHCTL); + } + if (sysctl(mib, miblen, NULL, &pathlen, NULL, 0) == -1) { + err(1, "getting path: sysctl(%s) - size only", PATHCTL); + } + path = malloc(pathlen + 1); + if (path == NULL) { + err(1, "allocating %lu bytes for the path", + (unsigned long)pathlen + 1); + } + if (sysctl(mib, miblen, path, &pathlen, NULL, 0) == -1) { + err(1, "getting path: sysctl(%s)", PATHCTL); + } + tmppath = path; + + while ((element = strsep(&tmppath, ";")) != NULL) { + strlcpy(kldpath, element, MAXPATHLEN); + if (kldpath[strlen(kldpath) - 1] != '/') { + strlcat(kldpath, "/", MAXPATHLEN); + } + strlcat(kldpath, kldname, MAXPATHLEN); + + if (stat(kldpath, &sb) == -1) { + continue; + } + + found = 1; + + if (sb.st_dev != dev || sb.st_ino != ino) { + if (!quiet) { + warnx("%s will be loaded from %s, not the " + "current directory", kldname, element); + warnx("to load from the current directory use " + "./%s", kldname); + } + break; + } else if (sb.st_dev == dev && sb.st_ino == ino) { + return (0); + } + } + + free(path); + + if (!found) { + if (!quiet) { + warnx("%s is not in the module path", kldname); + warnx("to load from the current directory use ./%s", + kldname); + } + return (-1); + } + + return (0); +} + static void usage(void) { @@ -48,14 +141,21 @@ int errors; int fileid; int verbose; + int quiet; errors = 0; verbose = 0; - - while ((c = getopt(argc, argv, "v")) != -1) + quiet = 0; + + while ((c = getopt(argc, argv, "qv")) != -1) switch (c) { + case 'q': + quiet = 1; + verbose = 0; + break; case 'v': verbose = 1; + quiet = 0; break; default: usage(); @@ -67,13 +167,17 @@ usage(); while (argc-- != 0) { - fileid = kldload(argv[0]); - if (fileid < 0) { - warn("can't load %s", argv[0]); - errors++; - } else - if (verbose) - printf("Loaded %s, id=%d\n", argv[0], fileid); + if (path_check(argv[0], quiet) == 0) { + fileid = kldload(argv[0]); + if (fileid < 0) { + warn("can't load %s", argv[0]); + errors++; + } else + if (verbose) + printf("Loaded %s, id=%d\n", argv[0], fileid); + } else { + errors++; + } argv++; } --Apple-Mail-4--596983795 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -- Benno Rice benno@jeamland.net --Apple-Mail-4--596983795-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 05:08:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBF61106566B for ; Wed, 3 Jun 2009 05:08:14 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from mail.jeamland.net (rafe.jeamland.net [203.20.99.33]) by mx1.freebsd.org (Postfix) with ESMTP id 698498FC14 for ; Wed, 3 Jun 2009 05:08:14 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from mail.jeamland.net (localhost [127.0.0.1]) by mail.jeamland.net (Postfix) with ESMTP id 5D2721CD0B for ; Wed, 3 Jun 2009 15:08:12 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on rafe.jeamland.net X-Spam-Level: X-Spam-Status: No, score=-6.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [10.1.7.168] (ppp154-45.static.internode.on.net [150.101.154.45]) by mail.jeamland.net (Postfix) with ESMTPSA id D7B541CCF3 for ; Wed, 3 Jun 2009 15:08:11 +1000 (EST) Message-Id: From: Benno Rice To: current@freebsd.org In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-5--589487971 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 15:08:04 +1000 References: X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: ClamAV using ClamSMTP at rafe.jeamland.net Cc: Subject: Re: CFR: sanity checking arguments to kldload(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 05:08:15 -0000 --Apple-Mail-5--589487971 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 03/06/2009, at 1:03 PM, Benno Rice wrote: > The attached patch performs some sanity checking on arguments passed > to kldload(8). Specifically, if an argument looks like a filename > but lacks a path (eg, 'xfs.ko' as opposed to 'xfs' or './xfs.ko') it > checks to see if a file with that name is in the current directory. > If it is, it checks the current module path to see if a file with > that name also exists there (possibly in an earlier entry if the > current directory is in the module path), if so it warns the user > that that module will be loaded and not the one in the current > directory. If not, it tells the user how to use a path to load the > module. > > A -q option is added to quieten the output if desired. I've had some feedback that the instructions on how to load the module from the current directory should instead be in the manual page. I've done this and added extra verbiage to point out the potential source of confusion wherein bare filenames (eg. foo.ko as opposed to ./foo.ko) will only ever be loaded from the module path. Further comments appreciated. --Apple-Mail-5--589487971 Content-Disposition: attachment; filename=kldload-2.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="kldload-2.diff" Content-Transfer-Encoding: 7bit Index: sbin/kldload/kldload.8 =================================================================== --- sbin/kldload/kldload.8 (revision 193292) +++ sbin/kldload/kldload.8 (working copy) @@ -50,10 +50,22 @@ .Nm . It does not hurt to specify it though. .Pp +If a bare filename is requested it will only be loaded if it is found within +the module path as defined by the sysctl +.Va kern.module_path . +To load a module from the current directory it must be specified as a full or +relative path. +The +.Nm +utility will warn if a module is requested as a bare filename and is present +in the current directory. +.Pp The following option is available: .Bl -tag -width indent .It Fl v Be more verbose. +.It Fl q +Silence any extraneous warnings. .El .Sh FILES .Bl -tag -width /boot/kernel -compact @@ -64,6 +76,26 @@ .El .Sh EXIT STATUS .Ex -std +.Sh EXAMPLES +To load by module name: +.Bd -literal -offset indent +\*[Gt] kldload foo +.Ed +.Pp +To load by file name within the module path: +.Bd -literal -offset indent +\*[Gt] kldload foo.ko +.Ed +.Pp +To load by relative path: +.Bd -literal -offset indent +\*[Gt] kldload ./foo.ko +.Ed +.Pp +To load by full path: +.Bd -literal -offset indent +\*[Gt] kldload /boot/kernel/foo.ko +.Ed .Sh AUTOMATICALLY LOADING MODULES Some modules (pf, ipfw, ipf, etc.) may be automatically loaded at boot time when the corresponding Index: sbin/kldload/kldload.c =================================================================== --- sbin/kldload/kldload.c (revision 193292) +++ sbin/kldload/kldload.c (working copy) @@ -30,10 +30,99 @@ #include #include #include +#include #include #include #include +#include +#include +#include +#define PATHCTL "kern.module_path" + +/* + * Check to see if the requested module is specified as a filename with no + * path. If so and if a file by the same name exists in the module path, + * warn the user that the module in the path will be used in preference. + */ +static int +path_check(const char *kldname, int quiet) +{ + int mib[5], found; + size_t miblen, pathlen; + char kldpath[MAXPATHLEN]; + char *path, *tmppath, *element; + struct stat sb; + dev_t dev; + ino_t ino; + + if (strchr(kldname, '/') != NULL) { + return (0); + } + if (strstr(kldname, ".ko") == NULL) { + return (0); + } + if (stat(kldname, &sb) != 0) { + return (0); + } + + found = 0; + dev = sb.st_dev; + ino = sb.st_ino; + + miblen = sizeof(mib) / sizeof(mib[0]); + if (sysctlnametomib(PATHCTL, mib, &miblen) != 0) { + err(1, "sysctlnametomib(%s)", PATHCTL); + } + if (sysctl(mib, miblen, NULL, &pathlen, NULL, 0) == -1) { + err(1, "getting path: sysctl(%s) - size only", PATHCTL); + } + path = malloc(pathlen + 1); + if (path == NULL) { + err(1, "allocating %lu bytes for the path", + (unsigned long)pathlen + 1); + } + if (sysctl(mib, miblen, path, &pathlen, NULL, 0) == -1) { + err(1, "getting path: sysctl(%s)", PATHCTL); + } + tmppath = path; + + while ((element = strsep(&tmppath, ";")) != NULL) { + strlcpy(kldpath, element, MAXPATHLEN); + if (kldpath[strlen(kldpath) - 1] != '/') { + strlcat(kldpath, "/", MAXPATHLEN); + } + strlcat(kldpath, kldname, MAXPATHLEN); + + if (stat(kldpath, &sb) == -1) { + continue; + } + + found = 1; + + if (sb.st_dev != dev || sb.st_ino != ino) { + if (!quiet) { + warnx("%s will be loaded from %s, not the " + "current directory", kldname, element); + } + break; + } else if (sb.st_dev == dev && sb.st_ino == ino) { + return (0); + } + } + + free(path); + + if (!found) { + if (!quiet) { + warnx("%s is not in the module path", kldname); + } + return (-1); + } + + return (0); +} + static void usage(void) { @@ -48,14 +137,21 @@ int errors; int fileid; int verbose; + int quiet; errors = 0; verbose = 0; - - while ((c = getopt(argc, argv, "v")) != -1) + quiet = 0; + + while ((c = getopt(argc, argv, "qv")) != -1) switch (c) { + case 'q': + quiet = 1; + verbose = 0; + break; case 'v': verbose = 1; + quiet = 0; break; default: usage(); @@ -67,13 +163,17 @@ usage(); while (argc-- != 0) { - fileid = kldload(argv[0]); - if (fileid < 0) { - warn("can't load %s", argv[0]); - errors++; - } else - if (verbose) - printf("Loaded %s, id=%d\n", argv[0], fileid); + if (path_check(argv[0], quiet) == 0) { + fileid = kldload(argv[0]); + if (fileid < 0) { + warn("can't load %s", argv[0]); + errors++; + } else + if (verbose) + printf("Loaded %s, id=%d\n", argv[0], fileid); + } else { + errors++; + } argv++; } --Apple-Mail-5--589487971 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -- Benno Rice benno@jeamland.net --Apple-Mail-5--589487971-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 05:25:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51F141065675; Wed, 3 Jun 2009 05:25:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id EEB328FC17; Wed, 3 Jun 2009 05:25:42 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=otFgK3cEVSZeeEBNSf6F+DZDeDDExRbQo+AU+ObSAHTBlEdaaeffViZ8pMagBhb5zXY1ioiuMVxY7s2qnCxIcK328H1gj5DhKSEBWlT+CjH7pHCZRiY4MSEhecq32GHlD2gzgZXO5eU6w2s5L17EbAM6tVMqbzwZUH+Nx/YnE2U=; Received: from phoenix.codelabs.ru (ppp91-78-250-129.pppoe.mtu-net.ru [91.78.250.129]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MBiyr-000K3z-RD; Wed, 03 Jun 2009 09:25:42 +0400 Date: Wed, 3 Jun 2009 09:25:38 +0400 From: Eygene Ryabinkin To: FreeBSD Tinderbox Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090602222445.2F6017302F@freebsd-current.sentex.ca> Sender: rea-fbsd@codelabs.ru Cc: marius@freebsd.org, kmacy@freebsd.org, rwatson@freebsd.org, current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 05:25:43 -0000 Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > 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 -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/sun4v/sun4v/machdep.c > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > *** Error code 1 > > Stop in /obj/sun4v/src/sys/LINT. This seems to be related to the recent NETISR changes, namely, the addition of the pc_netisr member to the struct pcpu: http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u I am not sure how large (void *) is on sun4v, but it seems to me that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h should be compensated for this change. Something like ----- #ifdef KTR #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) #else #define PCPU_MD_FIELDS_PAD 3 #endif ----- though I am not very sure about KTR's case. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 06:16:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00B6106564A; Wed, 3 Jun 2009 06:16:52 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD9F8FC1A; Wed, 3 Jun 2009 06:16:52 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id B716571EF71; Wed, 3 Jun 2009 02:16:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id endGKbhHtCR1; Wed, 3 Jun 2009 02:16:51 -0400 (EDT) Received: from localhost (daemon.egr.msu.edu [35.9.44.65]) by mx.egr.msu.edu (Postfix) with ESMTP id 7076A71ECE8; Wed, 3 Jun 2009 02:16:51 -0400 (EDT) Received: by localhost (Postfix, from userid 21281) id 34EBF991; Wed, 3 Jun 2009 02:16:51 -0400 (EDT) Date: Wed, 3 Jun 2009 02:16:51 -0400 From: Adam McDougall To: Martin Wilke Message-ID: <20090603061650.GC1122@egr.msu.edu> References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1AC253.6010306@egr.msu.edu> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Paul Wootton Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 06:16:53 -0000 I figured it out. I needed "options COMPAT_IA32" in my kernel config. On Mon, May 25, 2009 at 12:07:47PM -0400, Adam McDougall wrote: > Hi, > When compiling I get the following error > > kBuild: Installing tstUtf8 => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 > > kBuild: Installing tstUuid => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid > > kBuild: Installing tstVMStructGC => > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC > > kBuild: Generating tstVMStructSize - > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: > 1: Syntax error: "(" unexpected > kmk[2]: *** > [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > Error 2 > kmk[2]: *** Deleting file > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > > kmk[2]: *** Waiting for unfinished jobs.... > awk -f /usr/src/sys/conf/kmod_syms.awk > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > | xargs -J% objcopy % > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > awk: can't open file > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > source line number 10 > kmk[2]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: Entering directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > Stop in /root/vBox/virtualbox. > demophon# > > > demophon# uname -a > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 > 09:04:17 UTC 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > Any ideas? > > Cheers > Paul > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > I am getting this error too from the latest test port on amd64 7-stable and 8-current: kBuild: Installing tstVMStructGC => /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC kBuild: Generating tstVMStructSize - /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: 1: Syntax error: "(" unexpected kmk[2]: *** [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] Error 2 kmk[2]: *** Deleting file `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' kmk[2]: *** Waiting for unfinished jobs.... kmk[2]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: Entering directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk[2]: *** Exiting with status 2 kmk[1]: *** [pass_binaries_this] Error 2 kmk[1]: Leaving directory `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' kmk: *** [pass_binaries_order] Error 2 *** Error code 2 The OS builds are 1-3 days old (full kernel + world) and ports were up to date. Help? Thanks. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 07:09:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5CE106566B; Wed, 3 Jun 2009 07:09:06 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3748FC08; Wed, 3 Jun 2009 07:09:05 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm7 with SMTP id 7so2428578fxm.43 for ; Wed, 03 Jun 2009 00:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=D8OuQ/JwmHxxbx7eQtrwpSfTgxezyLwPFAeaJH4+uvg=; b=J66c+6/7+nrxbrslFcOTkn4EQfRrx9bVScDoHUZP7hKnA2UgjTJAFPt/0LdMZqEXKg ioq4UoqBalBh4BtKwp1XunMFaKtwLH+C/txc9ygdJfLRWZ24E8GMM5frPFZC9fFOmECr Mc4vCKBWIMeogRWMQX91GVPj10wkWBV/ic6Yo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gjrJ1O01HQkwyGXAQvNgxvYLYVSsF2qQwTayWc35KfMomWWjMbHxvduiKtGpEqUjJ6 tQdl1BSDkB4XG8tG9yYxi0Y0wsSmugAFy3hU8zpxZAxx+/iEO9bl1mp8Kpy+vOBPzPxc yiT+cSRvrTxlC0N3Z1ySLZXhbl/vQGMkbRag4= MIME-Version: 1.0 Received: by 10.103.181.20 with SMTP id i20mr332743mup.62.1244012944330; Wed, 03 Jun 2009 00:09:04 -0700 (PDT) In-Reply-To: <4A256867.8050808@lapo.it> References: <49D8D03B.8090302@arcor.de> <49D90363.6010602@arcor.de> <1238959921.1829.10.camel@balrog.2hip.net> <49DB573C.3020703@FreeBSD.org> <1239129677.1947.14.camel@balrog.2hip.net> <49DC5066.1010607@FreeBSD.org> <1239176118.1954.11.camel@balrog.2hip.net> <49DF49AD.30701@FreeBSD.org> <49DFBAEF.1080904@freebsd.org> <4A256867.8050808@lapo.it> Date: Wed, 3 Jun 2009 11:09:04 +0400 Message-ID: From: pluknet To: Lapo Luchini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , Alex Dupre , freebsd-current@freebsd.org Subject: Re: xorg loops X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 07:09:06 -0000 2009/6/2 Lapo Luchini : > Tim Kientzle wrote: >> AllowEmptyInput hald Result >> off enabled Mouse/keyboard delays/jerkiness >> off disabled Works >> on (default) enabled Works >> on (default) disabled No mouse/keyboard > > Tim, I had your same symptoms (as far as "delays/jerkiness" can go): > when using the USB external mouse and leaving it in *some* positions, > the whole system was paused until I move the mouse even a little bit, at > that point all "missing events" (i.e. all keypresses that didn't produce > any output, or also all screen updates) are shown in fast-forward (e.g. > the Firefox spinner of a loading tab was stopped until the mouse moved, > and made the 3 missing turns rapidly, then all to normal). When the > mouse was left in other positions, no problem was shown. > > After Googling your message I commented-out the AllowEmptyInput line in > my xorg.conf and now both internal touchpad and external mouse work > perfectly and don't "halt the event queue" (or what it was) anymore. > > I still wonder the reason behind this behavior but as long as it's > working, I won't complain. +1 That's exactly what helps me with this problem. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 07:19:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED98F106564A for ; Wed, 3 Jun 2009 07:19:14 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id BEC0E8FC1A for ; Wed, 3 Jun 2009 07:19:14 +0000 (UTC) (envelope-from lihong.chen@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so2907095waf.27 for ; Wed, 03 Jun 2009 00:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:from:to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=wwEi6BPYXn76p87M6/PysD7O6oK/z7x6ZKSRupKdr4k=; b=kxtuVRDBkCsGqiDgzcuXyrxREnzXZ+uVfGAzekHT7oJsuaxYL9YaM7uNTvNwSbARFi emWw1bQi0oKjk8uQaCWUoDSgCVVwE2EXKkUUJUtB6e8YLDhmbYcC8Q23CoKP2DmIX3xT 6SudN4jQqgAQpiqhvZF5IutY6jKe10DhxKd5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:from:to:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=k5k0MqpsKbJqZ6aPqotC+XcsquxkkI+KCVZoM9zA3o3LYhxscipjuR5EvzM9RVS1UC TYtbN8ScZbo5zcMfp3TIW8z4PMjMbdd6msDaltqCOTvGpVns4YvY4XiJUj50Ms4fLeWt 6UdjnaPOMd0+hyNrF5igR1kL/sUG4K6rmLUzw= Received: by 10.114.235.16 with SMTP id i16mr1029470wah.164.1244013554454; Wed, 03 Jun 2009 00:19:14 -0700 (PDT) Received: from ?192.168.10.114? (59-125-13-44.HINET-IP.hinet.net [59.125.13.44]) by mx.google.com with ESMTPS id l38sm8535442waf.38.2009.06.03.00.19.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Jun 2009 00:19:13 -0700 (PDT) Sender: "Eric L. Chen" From: "Eric L. Chen" To: FreeBSD Current Content-Type: text/plain Date: Wed, 03 Jun 2009 15:19:05 +0800 Message-Id: <1244013545.2189.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.27.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Cannot run iperf with Atheros AR9160 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 07:19:15 -0000 Hi I have an Atheros AR9160 miniPCI board, installed in my Centrino laptop (but the laptop has only two antenna). When I run iperf (from ports benchmarks/iperf) to test 11n, the test cannot done. Console log says bb hang, but I can ping peer node without problems. I think AR9160 driver cannot work in heavy traffic loading. ~> uname -a FreeBSD lihong-nb 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Tue Jun 2 21:24:53 CST 2009 root@lihong-nb:/usr/obj/usr/src/sys/LIHONG-NB i386 dmesg: ath0: mem 0xc8200000-0xc820ffff irq 17 at device 3.0 on pci6 ath0: [ITHREAD] ath0: AR9160 mac 64.1 RF5133 phy 11.0 .... ath0: bb hang detected (0x80), reseting wlan0: link state changed to DOWN bfe0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x80), reseting ath0: bb hang detected (0x80) wlan0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x80), reseting wlan0: link state changed to DOWN lagg0: link state changed to DOWN wlan0: link state changed to UP lagg0: link state changed to UP ath0: bb hang detected (0x1), reseting ath0: bb hang detected (0x1) ath0: bb hang detected (0x1) iperf: ~> iperf -i 1 -t 10 -c 192.168.10.1 ------------------------------------------------------------ Client connecting to 192.168.10.1, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.10.114 port 60096 connected with 192.168.10.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 952 KBytes 7.80 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 1.0- 2.0 sec 712 KBytes 5.83 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 2.0- 3.0 sec 504 KBytes 4.13 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 3.0- 4.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 11.0-12.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 12.0-13.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 13.0-14.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 14.0-15.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 15.0-16.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 17.0-18.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 19.0-20.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 20.0-21.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 21.0-22.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 22.0-23.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 23.0-24.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 24.0-25.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 25.0-26.0 sec 0.00 Bytes 0.00 bits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-26.1 sec 2.12 MBytes 683 Kbits/sec From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 07:52:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4AB5106566C for ; Wed, 3 Jun 2009 07:52:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 38B958FC0C for ; Wed, 3 Jun 2009 07:52:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n537q5pN006926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Jun 2009 17:52:06 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n537q5YL028065 for ; Wed, 3 Jun 2009 17:52:05 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n537q5K3028064 for freebsd-current@freebsd.org; Wed, 3 Jun 2009 17:52:05 +1000 (EST) (envelope-from peter) Date: Wed, 3 Jun 2009 17:52:05 +1000 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20090603075205.GB27800@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Hard hang with u3g and -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 07:52:09 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have a Huawei E169 3G modem which I'm using with the u3g driver on -current/i386 from about 4 weeks ago on my Aspire One (dual-core N270). If I access the stats port (/dev/cuaD0.2) then the system will randomly hang. The problem seems to occur more frequently when I'm using X but I've also seen it (once) when I was using a VTY. I'm not using hald. There doesn't seem to be a problem if I don't access /dev/cuaD0.2. When the system hangs, the 3G modem hangs up (though this may be the keepalive timer expiring at the remote end) and there's no response to the keyboard (Ctrl-Alt-Del and Ctrl-Alt-Fn from X; Ctrl-Alt-Esc and Alt-Fn from VTY; CapsLock, NumLock in either mode). The kernel still responds to pings over ethernet and I can change brightness via the keyboard so SMM is still working. Has anyone else seen anything like this? Can anyone suggest a way to track this down? I can't get to DDB, there's no serial, firewire, PCcard or similar I/O. --=20 Peter Jeremy --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkomK6UACgkQ/opHv/APuIfvZACfRUs3Y2gv5CyMNdhxz0gqG7G2 a30An3QRSs/+ZQaazSEBCyW1WZoJUtcw =CR1N -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 08:43:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C906110656CA; Wed, 3 Jun 2009 08:43:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 945698FC21; Wed, 3 Jun 2009 08:43:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n538hCnX037358; Wed, 3 Jun 2009 04:43:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n538hCl8038753; Wed, 3 Jun 2009 04:43:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 346F47302F; Wed, 3 Jun 2009 04:43:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090603084312.346F47302F@freebsd-current.sentex.ca> Date: Wed, 3 Jun 2009 04:43:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:43:15 -0000 TB --- 2009-06-03 07:11:10 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-03 07:11:10 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-03 07:11:10 - cleaning the object tree TB --- 2009-06-03 07:12:01 - cvsupping the source tree TB --- 2009-06-03 07:12:01 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-03 07:12:15 - building world TB --- 2009-06-03 07:12:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 07:12:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 07:12:15 - TARGET=sun4v TB --- 2009-06-03 07:12:15 - TARGET_ARCH=sparc64 TB --- 2009-06-03 07:12:15 - TZ=UTC TB --- 2009-06-03 07:12:15 - __MAKE_CONF=/dev/null TB --- 2009-06-03 07:12:15 - cd /src TB --- 2009-06-03 07:12:15 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 3 07:12:17 UTC 2009 >>> 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 Wed Jun 3 08:28:10 UTC 2009 TB --- 2009-06-03 08:28:10 - generating LINT kernel config TB --- 2009-06-03 08:28:10 - cd /src/sys/sun4v/conf TB --- 2009-06-03 08:28:10 - /usr/bin/make -B LINT TB --- 2009-06-03 08:28:10 - building LINT kernel TB --- 2009-06-03 08:28:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 08:28:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 08:28:10 - TARGET=sun4v TB --- 2009-06-03 08:28:10 - TARGET_ARCH=sparc64 TB --- 2009-06-03 08:28:10 - TZ=UTC TB --- 2009-06-03 08:28:10 - __MAKE_CONF=/dev/null TB --- 2009-06-03 08:28:10 - cd /src TB --- 2009-06-03 08:28:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 3 08:28:10 UTC 2009 >>> 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 -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -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 -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/sun4v/sun4v/hcall.S 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 -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/sun4v/sun4v/hviommu.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 -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/sparc64/sparc64/identcpu.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 -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/sparc64/sparc64/in_cksum.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 -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/sun4v/sun4v/intr_machdep.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 -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-03 08:43:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-03 08:43:12 - ERROR: failed to build lint kernel TB --- 2009-06-03 08:43:12 - 4650.09 user 424.72 system 5521.49 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 09:13:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 066521065673; Wed, 3 Jun 2009 09:13:56 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDF88FC20; Wed, 3 Jun 2009 09:13:55 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] ([192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n539Dnnp089217; Wed, 3 Jun 2009 10:13:49 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A263ECD.2070704@fletchermoorland.co.uk> Date: Wed, 03 Jun 2009 10:13:49 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: Adam McDougall References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> <20090603061650.GC1122@egr.msu.edu> In-Reply-To: <20090603061650.GC1122@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 09:13:56 -0000 That makes perfect sense. On my machine, I commented out 32bit compatibility as I figured I would not need it. This is the first time it has caught me out... Adam McDougall wrote: > I figured it out. I needed "options COMPAT_IA32" > in my kernel config. > > On Mon, May 25, 2009 at 12:07:47PM -0400, Adam McDougall wrote: > > > Hi, > > When compiling I get the following error > > > > kBuild: Installing tstUtf8 => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUtf8 > > > > kBuild: Installing tstUuid => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/testcase/tstUuid > > > > kBuild: Installing tstVMStructGC => > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC > > > > kBuild: Generating tstVMStructSize - > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > > > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/bin/tstVMStructGC: > > 1: Syntax error: "(" unexpected > > kmk[2]: *** > > [/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > > Error 2 > > kmk[2]: *** Deleting file > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > > > > kmk[2]: *** Waiting for unfinished jobs.... > > awk -f /usr/src/sys/conf/kmod_syms.awk > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > | xargs -J% objcopy % > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/out/freebsd.amd64/release/obj/vboxdrv/vboxdrv.ko > > > > awk: can't open file > > /root/vBox/virtualbox/work/virtualbox-2.2.2r19673/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.def > > > > source line number 10 > > kmk[2]: Leaving directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk[2]: Entering directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk[2]: *** Exiting with status 2 > > kmk[1]: *** [pass_binaries_this] Error 2 > > kmk[1]: Leaving directory > > `/root/vBox/virtualbox/work/virtualbox-2.2.2r19673' > > kmk: *** [pass_binaries_order] Error 2 > > *** Error code 2 > > > > Stop in /root/vBox/virtualbox. > > demophon# > > > > > > demophon# uname -a > > FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #10: Wed May 6 > > 09:04:17 UTC 2009 paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64 > > > > Any ideas? > > > > Cheers > > Paul > > _______________________________________________ > > freebsd-ports@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > > I am getting this error too from the latest test port on amd64 7-stable > and 8-current: > > kBuild: Installing tstVMStructGC => > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC > kBuild: Generating tstVMStructSize - > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h > /usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/bin/tstVMStructGC: > 1: Syntax error: "(" unexpected > kmk[2]: *** > [/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h] > Error 2 > kmk[2]: *** Deleting file > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852/out/freebsd.amd64/release/obj/VMM/tstVMStructGC.h' > kmk[2]: *** Waiting for unfinished jobs.... > kmk[2]: Leaving directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk[2]: Entering directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk[2]: *** Exiting with status 2 > kmk[1]: *** [pass_binaries_this] Error 2 > kmk[1]: Leaving directory > `/usr/home/mcdouga9/virtualbox/work/virtualbox-2.2.2r19852' > kmk: *** [pass_binaries_order] Error 2 > *** Error code 2 > > > The OS builds are 1-3 days old (full kernel + world) and ports were up > to date. Help? Thanks. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 09:33:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 754A31065672; Wed, 3 Jun 2009 09:33:08 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id DE48B8FC1C; Wed, 3 Jun 2009 09:33:07 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.2/8.14.2) with ESMTP id n539X4c6089795; Wed, 3 Jun 2009 10:33:05 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A264350.2000908@fletchermoorland.co.uk> Date: Wed, 03 Jun 2009 10:33:04 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: Doug Rabson References: <4A1D5E7B.4030605@fletchermoorland.co.uk> <4A1D9AC6.2020603@fletchermoorland.co.uk> <13C11BDA-1354-4108-B087-09956C2A8F63@rabson.org> <4A2018EE.5020204@fletchermoorland.co.uk> <9476D694-4825-4DDD-80AE-B34B367A85B4@rabson.org> In-Reply-To: <9476D694-4825-4DDD-80AE-B34B367A85B4@rabson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 Cc: dfr@freebsd.org, freebsd-current@freebsd.org Subject: Re: Booting from ZFS RaidZ X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 09:33:08 -0000 Doug Rabson wrote: > > On 29 May 2009, at 18:18, Paul Wootton wrote: > >> Doug Rabson wrote: >>> >>> On 27 May 2009, at 20:55, Paul Wootton wrote: >>> >>>> Doug Rabson wrote: >>>>> >>>>> On 27 May 2009, at 16:38, Paul Wootton wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> With the recent changes allowing RaidZ boot, I thought I would >>>>>> finally drop my mirror pack and go RaidZ. >>>>>> >>>>>> The only problem I now have is >>>>>> demophon# zpool set bootfs=DemoPool/root DemoPool >>>>>> cannot set property for 'DemoPool': operation not supported on >>>>>> this type of pool >>>>>> >>>>>> Is this still a work in progress, or do I have something a-miss? >>>>>> >>>>>> I am using current as of today >>>>>> "demophon# uname -a >>>>>> FreeBSD demophon 8.0-CURRENT FreeBSD 8.0-CURRENT #17: Wed May 27 >>>>>> 13:18:06 BST 2009 >>>>>> paul@demophon:/usr/obj/usr/src/sys/DEMOPHON amd64" >>>>> >>>>> This is a limitation which I will remove as soon as I have a >>>>> little time to work on it. Basically, Solaris can only boot from >>>>> simple structures such as mirrors and collections of mirrors. The >>>>> code enforces this by stopping you from setting the bootfs >>>>> property if the pool configuration is too complex for the Solaris >>>>> boot code. I will simply remove this limitation for FreeBSD since >>>>> we can now boot from any pool configuration. >>>>> >>>>> In the meantime, you can still boot if you put your root >>>>> filesystem files in the root of the pool. Not ideal I know but >>>>> I'll try to fix it properly soon. >>>>> >>>> >>>> This does seem to work correctly for me as I get a BTX crash (see >>>> below) >>>> >>>> Verifying DMI Poll Data ............. >>>> \ >>>> FreeBSD/i386 boot >>>> Default:DemoPool:/boot/kernel/kernel >>>> boot: >>>> | >>>> int=00000000 err=00000000 elf=00010083 eip=00192adf >>>> eax=00192e02a ebx=df5610ed ecx=d485b986 edx=00000000 >>>> esi=00000040 edi=000935d0 ebp=0009339c esp=00000000 >>>> cs=0008 ds=0010 es=0010 fs-0010 gs=0010 ss=0010 >>>> cs:eip=c5 e4 00 66 0f 73 dc 02-ff e4 b8 8d 8d bc f2 2a >>>> e9 ba e6 f4 2a 8a d8 24-df 86 c4 be 00 2b e9 8b >>>> ss:esp=16 e8 00 f0 16 e8 00 f0-c3 e2 00 f0 16 e8 00 f0 >>>> 16 e8 00 f0 54 ff 00 f0-b8 6e 00 f0 16 e8 00 f0 >>>> BTX halted >>> >>> How frustrating. Can you give me some idea on your ZFS pool >>> configuration. Also, if you can dig out the symbol table for >>> /boot/loader (it should be lurking somewhere in your /usr/obj tree >>> as loader.sym), it would be interesting to see where it crashed >>> (i.e. whats the closest symbol to the value of EIP above). >>> >>> _______________________________________________ >>> 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" >>> >> Erm, Opps.... Im an idiot.... >> I went back over my steps and realised the I had forgotten to do a >> "make distrib-dirs" and "make distribution" >> Now it boots the kernel but I can not get it to mount the root filing >> system. >> I have got a few more thinks to try before I throw my hands in the >> air, but unfortunately that will not be until after the weekend (the >> BSD is my main PC at work) > > What do you have in /etc/fstab for the root filesystem? I'm not > exactly sure if the root mounting code can cope with mounting the root > of the pool as root filesystem. You might try the attached patch which > should allow setting bootfs on raidz pools to something more useful > than the root. > > > _______________________________________________ > 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 only have my swaps in the fstab file. This is the same as what i did for for my single and mirror setup. In /boot/loader.conf I specified "vfs.root.mountfrom=zfs:DemoPool/root" The kernel loads and then fails just before switching to user land with an error saying trying to mount root from zfs:DemoPool/root and failed. It then asks for user intervention and specify where to load root filing system from. Pressing ? lists all my drives and ufs slices, but not any zfs partitions. zfsroot is an ex-mirror setup, only running on one drive now. This boots fine and all is happy - again, nothing really in fstab but vfs.root.mountfrom=zfs:zfsroot/root in /boot/loader.conf During all the tests, I was swapping the mountpoints so not to cause conflicts with each other... As an experiment, I bootup from the raidz pool but changed to vfs.root.mountfrom=zfs:zfsroot/root The kernel loaded but as before, bombed out asking for user intervention for where to find root. Then is tried bootinng from the zfsroot single disk pool and set vfs.root.mountfrom=zfs:DemoPool/root. This booted up correctly and the machine was happy, although it meant that I had to use a none raidz drive to bootstrap - not really what I was looking for. I have bootfs=DemoPool/root on DemoPool. Any ideas? Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 09:54:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CA51065678; Wed, 3 Jun 2009 09:54:35 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9C25B8FC1B; Wed, 3 Jun 2009 09:54:34 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=CeONk6T3gWwMvRUQZ9MNgIeeyWfoQz+0AqRe3TgcTHHbK3kbevFembeXcdBjRemZ1lL2BmlMShOi9q8zH8ZDcptjSlR77LrV2j7VpuxmgnLahFcd7Kr1BjvCD0vr3BKMyvOQAFvj4IQKs1TZWsTP1wwpSckRueQ2ihDgMpcKQGc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MBnB2-000Lfc-SZ; Wed, 03 Jun 2009 13:54:33 +0400 Date: Wed, 3 Jun 2009 13:54:30 +0400 From: Eygene Ryabinkin To: FreeBSD Tinderbox Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1X+6QtwRodzgDPAC" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: marius@freebsd.org, sparc64@freebsd.org, rwatson@freebsd.org, kmacy@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 09:54:36 -0000 --1X+6QtwRodzgDPAC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Wed, Jun 03, 2009 at 09:25:38AM +0400, Eygene Ryabinkin wrote: > Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > > 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 -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/sun4v/sun4v/machdep.c > > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > > *** Error code 1 > > > > Stop in /obj/sun4v/src/sys/LINT. > > This seems to be related to the recent NETISR changes, namely, the > addition of the pc_netisr member to the struct pcpu: > http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u > > I am not sure how large (void *) is on sun4v, but it seems to me > that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h ^^^^^^^^^^^^ Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > should be compensated for this change. Something like > ----- > #ifdef KTR > #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) > #else > #define PCPU_MD_FIELDS_PAD 3 > #endif > ----- > though I am not very sure about KTR's case. KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just now we won't be able to reach this with the current definition for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative and that's bad. The attached patch should fix this (although I have no sun4v to test on, so take it with a grain of salt). By the way, having looked at sys/sys/pcpu.h, I see that there are parts of 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am missing something? Thanks. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --1X+6QtwRodzgDPAC Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/sys/sun4v/include/pcpu.h b/sys/sun4v/include/pcpu.h index 434f1cd..12eddf2 100644 --- a/sys/sun4v/include/pcpu.h +++ b/sys/sun4v/include/pcpu.h @@ -38,11 +38,20 @@ struct pmap; -#ifdef KTR -#define PCPU_MD_FIELDS_PAD (4 - (PCPU_NAME_LEN + 7) / 8) -#else -#define PCPU_MD_FIELDS_PAD 4 -#endif +/* Alignment requirements for 'struct pcpu', must be power of two. */ +#define PCPU_ALIGN (1<<6) +/* Bytes per one pad entry */ +#define PCPU_BPP 8 +/* Maximal size of padding */ +#define PCPU_MAXPAD (PCPU_ALIGN / PCPU_BPP) + +#if defined(KTR) +#define _KTR_PAD (PCPU_MAXPAD - ((PCPU_NAME_LEN + PCPU_BPP - 1)/PCPU_BPP) % PCPU_MAXPAD) +#else /* defined(KTR) */ +#define _KTR_PAD 0 +#endif /* defined(KTR) */ + +#define PCPU_MD_FIELDS_PAD ((3 + _KTR_PAD) % PCPU_MAXPAD) /* * Inside the kernel, the globally reserved register g7 is used to --1X+6QtwRodzgDPAC-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 10:15:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 993C91065672; Wed, 3 Jun 2009 10:15:59 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 29BBB8FC0C; Wed, 3 Jun 2009 10:15:59 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=dADtYcmglARoP51HU6R6t4BA2pNhAp65i8B60iB2z4ghl8hs7WvWA0v3T/JKVXNFrVyiYbHoHAsp3DKlauxd1U5yywS4NpMX2upMosCMKfhPZPk7qSidwSEK5wiilWie6we/vszs1h2jfyUms57SE/MViwLKGkILvXqRr4vGpBk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MBnVl-000NsR-T1; Wed, 03 Jun 2009 14:15:57 +0400 Date: Wed, 3 Jun 2009 14:15:55 +0400 From: Eygene Ryabinkin To: FreeBSD Tinderbox Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EE8jvUPYYQjJtG7J" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: current@freebsd.org, marius@freebsd.org, rwatson@freebsd.org, kmacy@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:16:00 -0000 --EE8jvUPYYQjJtG7J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > Just now we won't be able to reach this with the current definition > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > become negative and that's bad. And while I am here: definition for PCPU_NAME_LEN seems to be wrong. It is intended to fit ("CPU %d", cpuid) where cpuid <= MAXCPU. If this is correct, then (sys/sys/pcpu.h, line 57) 1. sizeof(__XSTRING(MAXCPU) + 1) is a typo: typeof(__XSTRING(...) + 1) is 'char *', so sizeof() will return the size of the pointer, not the size of the string contents. The proper expression should be 'sizeof(__XSTRING(MAXCPU)) + 1'. 2. one should not add one, but substract it: sizeof() accounts for the trailing '\0' and we have two sizeof's, so the size of one '\0' should be substracted -- this will give the maximal string buffer length for CPU with its number, no less, no more. Does the attached patch looks sane? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --EE8jvUPYYQjJtG7J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p1 diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 63c3fa3..98705eb 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -54,7 +54,7 @@ struct rm_queue { struct rm_queue* volatile rmq_prev; }; -#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU) + 1)) +#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU)) - 1) /* --EE8jvUPYYQjJtG7J-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 11:57:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D81BC1065670 for ; Wed, 3 Jun 2009 11:57:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 7C6878FC0C for ; Wed, 3 Jun 2009 11:57:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MBp5x-000GpA-Sx; Wed, 03 Jun 2009 14:57:26 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n53BvMgS057457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 14:57:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n53BvMK3043518; Wed, 3 Jun 2009 14:57:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n53BvM6R043517; Wed, 3 Jun 2009 14:57:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jun 2009 14:57:22 +0300 From: Kostik Belousov To: Peter Jeremy Message-ID: <20090603115722.GJ1927@deviant.kiev.zoral.com.ua> References: <20090603075205.GB27800@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gGwQG2l7+sHH0Akr" Content-Disposition: inline In-Reply-To: <20090603075205.GB27800@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MBp5x-000GpA-Sx 3898c292b1bf8261f268e988aeb16c04 X-Terabit: YES Cc: freebsd-current@freebsd.org Subject: Re: Hard hang with u3g and -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 11:57:28 -0000 --gGwQG2l7+sHH0Akr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 05:52:05PM +1000, Peter Jeremy wrote: > I have a Huawei E169 3G modem which I'm using with the u3g driver on > -current/i386 from about 4 weeks ago on my Aspire One (dual-core > N270). If I access the stats port (/dev/cuaD0.2) then the system will > randomly hang. The problem seems to occur more frequently when I'm > using X but I've also seen it (once) when I was using a VTY. I'm not > using hald. There doesn't seem to be a problem if I don't access > /dev/cuaD0.2. >=20 > When the system hangs, the 3G modem hangs up (though this may be the > keepalive timer expiring at the remote end) and there's no response to > the keyboard (Ctrl-Alt-Del and Ctrl-Alt-Fn from X; Ctrl-Alt-Esc and > Alt-Fn from VTY; CapsLock, NumLock in either mode). The kernel still > responds to pings over ethernet and I can change brightness via the > keyboard so SMM is still working. >=20 > Has anyone else seen anything like this? >=20 > Can anyone suggest a way to track this down? I can't get to DDB, there's > no serial, firewire, PCcard or similar I/O. I am not volunteering to do the debugging. I am only to suggest how to grab the debugging information for this case, that looks like a deadlock. Since parts of the network stack are functional, add ddb script to dump neccessary information, and trigger it by receiving some specially formatted ping packet. I higly suspect that you need at least backtraces of all threads and information on held locks. --gGwQG2l7+sHH0Akr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkomZSEACgkQC3+MBN1Mb4gOWwCg0DDkktqVt3i2wZMzAc539ZOe BVkAoLvMI0gja6Wb0rQLvzPKlHH2vtW1 =Ri/u -----END PGP SIGNATURE----- --gGwQG2l7+sHH0Akr-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 12:13:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E4191065675 for ; Wed, 3 Jun 2009 12:13:16 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0910E8FC16 for ; Wed, 3 Jun 2009 12:13:15 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MBpLI-0004QC-E9; Wed, 03 Jun 2009 16:13:16 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id CC7A2B878; Wed, 3 Jun 2009 16:13:07 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id BBCF1108839; Wed, 3 Jun 2009 16:13:07 +0400 (MSD) Date: Wed, 3 Jun 2009 16:13:07 +0400 From: Dmitry Marakasov To: Michael Moll Message-ID: <20090603121307.GA15659@hades.panopticon> References: <20090601182012.GA21543@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090601182012.GA21543@darkthrone.kvedulv.de> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 12:13:16 -0000 * Michael Moll (kvedulv@kvedulv.de) wrote: Very same panic here. Also, for some reason writing dumps to disk don't work, it either stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum value it managed to write is ~800MB), or just freezes with buffer-related message (may try to reproduct panic to get it). That's -current from today, 8GB physmem, 10GB swap, disk plain 200GB ATA with bsdlabel. There are also 6 SATA disks with ZFS. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 14:13:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B0F41065675; Wed, 3 Jun 2009 14:13:13 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FBED8FC16; Wed, 3 Jun 2009 14:13:12 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n53EDMp8029429; Wed, 3 Jun 2009 09:13:22 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n53EDLLc029428; Wed, 3 Jun 2009 09:13:21 -0500 (CDT) (envelope-from brooks) Date: Wed, 3 Jun 2009 09:13:21 -0500 From: Brooks Davis To: Erik Osterholm Message-ID: <20090603141321.GC28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OBd5C1Lgu00Gd/Tn" Content-Disposition: inline In-Reply-To: <20090602230648.GB88740@barragry.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 03 Jun 2009 09:13:22 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 14:13:13 -0000 --OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > Up till Sunday in 8-current, and for a long time in general > > network.subr (part of the rc.d system) has emitted a warning that > > values of network_interfaces other than AUTO are deprecated. I > > removed that warning in HEAD Sunday, and there is no a discussion > > about whether or not it should be put back, and whether or not there > > is any need for the user to specify the list of network interfaces > > at all. > >=20 > > If you use a value of network_interfaces other than AUTO please > > speak up so that we can make an intelligent decision about this > > issue. > >=20 > > Thanks, > >=20 > > Doug >=20 > I'll have to preface this by disclosing that I have not been running > -current, nor following any changes to the RC system. >=20 > In 7.1, if you compile a custom kernel and comment out an interface > (such that it is compiled as a module), one way to ensure that the > module is loaded is to explicitly list it in network_interfaces. If > -current works the same way, then users will be required to modify > /boot/loader.conf in order to load the module. Could there could be > possible side-effects to this change, since the loading of the module > happens at a different time? Do you actually do this? > At best, users doing things the 'network_interfaces' way may be in for > a surprise when the update (remotely), and this may be worthy of a > note in UPDATING. >=20 > If this has changed in 7.2 or -current, then I apologize for the > noise! The deprecation is a change relative to 7.0, but was in 7.1. -- Brooks --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJoUBXY6L6fI4GtQRAsgqAKCzq55ZffxXXs0D1DTb8XcF7IOMhgCfR2CK anLA01POzE4Uw0+wr2EVJHI= =HEew -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 15:28:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BEB1065670 for ; Wed, 3 Jun 2009 15:28:11 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 928F08FC1E for ; Wed, 3 Jun 2009 15:28:11 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id AA0935C39; Wed, 3 Jun 2009 11:28:10 -0400 (EDT) Date: Wed, 3 Jun 2009 11:28:10 -0400 From: Wesley Shields To: Dmitry Marakasov Message-ID: <20090603152810.GA21014@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603121307.GA15659@hades.panopticon> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Moll , freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 15:28:12 -0000 On Wed, Jun 03, 2009 at 04:13:07PM +0400, Dmitry Marakasov wrote: > * Michael Moll (kvedulv@kvedulv.de) wrote: > > Very same panic here. > > Also, for some reason writing dumps to disk don't work, it either > stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum > value it managed to write is ~800MB), or just freezes with > buffer-related message (may try to reproduct panic to get it). I'm seeing the same thing but I got a useful vmcore and crash.txt out of it. I can put them online if anyone wants to see them. -- WXS From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 15:51:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE61D106564A for ; Wed, 3 Jun 2009 15:51:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 630998FC0A for ; Wed, 3 Jun 2009 15:51:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8GADw5JkqDaFvJ/2dsb2JhbACOKgHEYIQLBQ X-IronPort-AV: E=Sophos;i="4.41,299,1241409600"; d="scan'208";a="35254276" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 03 Jun 2009 11:51:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id E47E5FB8063 for ; Wed, 3 Jun 2009 11:51:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjZRvI7wcAWW for ; Wed, 3 Jun 2009 11:51:49 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id A8F29FB8042 for ; Wed, 3 Jun 2009 11:51:49 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n53Fr3K29743 for ; Wed, 3 Jun 2009 11:53:03 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 3 Jun 2009 11:53:03 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: NFS mounts default to a mix of udp and tcp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 15:51:52 -0000 Although it doesn't explain the problem with nfs mounts over udp where the mountd doesn't seem to reply, this might explain some of the confusion. Near the beginning of mount_nfs.c, "nfsproto" is initialized to IPPROTO_UDP and, as such, by default, the mount protocol and NFS Null RPC is done over "udp". However, the -current kernel code in sys/nfsclient/nfs_vfsops.c and the system call done by mount_nfs.c defaults to "tcp". Therefore, unless "udp" or "tcp" is explicitly specified as mount_nfs options, it uses "udp" for the mount protocol and Null RPC, then switches to "tcp" from there on. This wasn't something I changed, so I think it has been this way since the nmount() syscall was introduced. Seems like the default should be all "tcp" or all "udp". Which do you think it should be? rick ps: This would explain a case where a server only supports udp and the mount didn't explicitly specify "udp", but it doesn't explain why mounts seem to be intermittently failing. From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 14:48:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F8DB106567B; Wed, 3 Jun 2009 14:48:28 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [IPv6:2a02:898:96::5e8e:f508]) by mx1.freebsd.org (Postfix) with ESMTP id B823E8FC28; Wed, 3 Jun 2009 14:48:27 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from guest-17.ripe.net (guest-17.ripe.net [193.0.2.17]) (authenticated bits=0) by erg.verweg.com (8.14.3/8.14.3) with ESMTP id n53EmJNo040445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Jun 2009 14:48:24 GMT (envelope-from ruben@verweg.com) Message-Id: From: Ruben van Staveren To: FreeBSD Mailing List , freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 16:48:04 +0200 X-Mailer: Apple Mail (2.935.3) X-Spam-Status: No, score=3.1 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=3.2.5 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on erg.verweg.com X-Virus-Scanned: ClamAV 0.94.2/9418/Wed Jun 3 12:18:15 2009 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (erg.verweg.com [94.142.245.8]); Wed, 03 Jun 2009 14:48:26 +0000 (UTC) X-Mailman-Approved-At: Wed, 03 Jun 2009 15:54:14 +0000 Cc: Subject: On the topic of network_interfaces, optional full automatic renaming of interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 14:48:28 -0000 Hi lists, Now the topic of network_interfaces has been mentioned, and the freeze for 8-stable is near I wonder if there is enough interest in the following feature to be included: http://ruben.is.verweg.com/stuff/freebsd/ifrename/ There is some dust there in that directory (It works, but is nowhere finished yet), but basically this early rc.d script takes the functionality of ifconfig_XXX_name a step further and enables optional automatic renaming of all ethernet capable interfaces, and enumerate them in the order probed by the kernel. A possible usage scenario is where you do massive imaging of a freebsd installation in where you don't know beforehand it will end up on hardware that has Broadcom or Intel NICs but it is for certain the cable will be connected to the first interface available and the same interface name can be referenced throughout all configuration files that need it (pf.conf, rc.conf(.local), /etc/rc.conf.d/network ) An other application usage is nailing down interface names using ethernet address, either because of correcting "mistakes" in the hardware (e.g. some Dell PowerEdges have the port labelled first to be probed as second and vice versa) or the necessity to only allow that interface to exist if it's MAC is the one that was configured (because of switch port ACL's) Regards, Ruben From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 16:02:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380111065672 for ; Wed, 3 Jun 2009 16:02:41 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id E6AC98FC21 for ; Wed, 3 Jun 2009 16:02:40 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n53G2cFb068083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 09:02:39 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A269E9E.1070304@freebsd.org> Date: Wed, 03 Jun 2009 09:02:38 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: "Eric L. Chen" References: <1244013545.2189.8.camel@localhost> In-Reply-To: <1244013545.2189.8.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: FreeBSD Current Subject: Re: Cannot run iperf with Atheros AR9160 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 16:02:41 -0000 There are chip bugs Atheros won't disclose the WAR for so the driver is hobbled. In my testing the hangs were recovered w/ minimal impact. You will need to scrape the necessary crap from the linux driver to find what is amiss. Sam Eric L. Chen wrote: > Hi > I have an Atheros AR9160 miniPCI board, installed in my Centrino laptop > (but the laptop has only two antenna). > When I run iperf (from ports benchmarks/iperf) to test 11n, the test > cannot done. Console log says bb hang, but I can ping peer node without > problems. > I think AR9160 driver cannot work in heavy traffic loading. > ~> uname -a > FreeBSD lihong-nb 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Tue Jun 2 > 21:24:53 CST 2009 root@lihong-nb:/usr/obj/usr/src/sys/LIHONG-NB > i386 > > dmesg: > ath0: mem 0xc8200000-0xc820ffff irq 17 at device 3.0 on > pci6 > ath0: [ITHREAD] > ath0: AR9160 mac 64.1 RF5133 phy 11.0 > .... > ath0: bb hang detected (0x80), reseting > wlan0: link state changed to DOWN > bfe0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x80), reseting > ath0: bb hang detected (0x80) > wlan0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x80), reseting > wlan0: link state changed to DOWN > lagg0: link state changed to DOWN > wlan0: link state changed to UP > lagg0: link state changed to UP > ath0: bb hang detected (0x1), reseting > ath0: bb hang detected (0x1) > ath0: bb hang detected (0x1) > > iperf: > ~> iperf -i 1 -t 10 -c 192.168.10.1 > ------------------------------------------------------------ > Client connecting to 192.168.10.1, TCP port 5001 > TCP window size: 32.5 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.10.114 port 60096 connected with 192.168.10.1 port > 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 1.0 sec 952 KBytes 7.80 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 1.0- 2.0 sec 712 KBytes 5.83 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 2.0- 3.0 sec 504 KBytes 4.13 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 3.0- 4.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 4.0- 5.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 5.0- 6.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 6.0- 7.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 7.0- 8.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 8.0- 9.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 9.0-10.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 10.0-11.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 11.0-12.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 12.0-13.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 13.0-14.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 14.0-15.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 15.0-16.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 16.0-17.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 17.0-18.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 18.0-19.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 19.0-20.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 20.0-21.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 21.0-22.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 22.0-23.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 23.0-24.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 24.0-25.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 25.0-26.0 sec 0.00 Bytes 0.00 bits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-26.1 sec 2.12 MBytes 683 Kbits/sec > > > _______________________________________________ > 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 Wed Jun 3 16:04:20 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704D21065672 for ; Wed, 3 Jun 2009 16:04:20 +0000 (UTC) (envelope-from antab@valka.is) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by mx1.freebsd.org (Postfix) with ESMTP id 050C78FC16 for ; Wed, 3 Jun 2009 16:04:19 +0000 (UTC) (envelope-from antab@valka.is) Received: from [192.168.1.127] (farm.antab.is [80.101.60.195]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id n53G4BQC033048; Wed, 3 Jun 2009 18:04:14 +0200 (CEST) (envelope-from antab@valka.is) Message-Id: <7846B8AD-A336-4BEB-B749-CD023DF13A9F@valka.is> From: Arnar Mar Sig To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 3 Jun 2009 18:04:11 +0200 References: <4A2504AA.1020406@zedat.fu-berlin.de> <4A254194.7080807@zedat.fu-berlin.de> X-Mailer: Apple Mail (2.935.3) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: "O. Hartmann" , freebsd-current@FreeBSD.org, Robert Watson Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 16:04:21 -0000 On Jun 2, 2009, at 11:32 PM, Rick Macklem wrote: > > > On Tue, 2 Jun 2009, Robert Watson wrote: > >> >> I'm running into a similar-sounding but odd problem on a diskless >> NFS client test box running 8.0, but talking to a server running 7.0: >> >> cheetah# mount -o rw -u / >> [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - >> RPC: Unable to send >> >> If I do a fresh file system mount it works fine: >> > I just saw one almost the same as this. When I did an nfsv3,tcp > mount I > got a similar message, but it was for the NFS NULL RPC. > > I left it and after a while it retried and succeeded. > > I tried rebooting the client and server a couple of times, but wasn't > able to get it to happen again. > > So, I wonder if what the others were seeing was something similar? > rick > (ps: I'm running a current kernel and nfs related utilities, but > really > old Feb. userland for the rest.) I'm able to use udp mounts again after reverting to r192672. I also tried r192927 and it did not work. I did complete world when updating. Arnar Mar Sig From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 16:09:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27AD31065673 for ; Wed, 3 Jun 2009 16:09:46 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id EBCCF8FC08 for ; Wed, 3 Jun 2009 16:09:45 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id 8270F5C37; Wed, 3 Jun 2009 12:09:45 -0400 (EDT) Date: Wed, 3 Jun 2009 12:09:45 -0400 From: Wesley Shields To: Dmitry Marakasov , bz@FreeBSD.org, jamie@FreeBSD.org Message-ID: <20090603160945.GC21014@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603152810.GA21014@atarininja.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Moll , freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 16:09:46 -0000 On Wed, Jun 03, 2009 at 11:28:10AM -0400, Wesley Shields wrote: > On Wed, Jun 03, 2009 at 04:13:07PM +0400, Dmitry Marakasov wrote: > > * Michael Moll (kvedulv@kvedulv.de) wrote: > > > > Very same panic here. > > > > Also, for some reason writing dumps to disk don't work, it either > > stops after writing some megabytes in `Dumping 1554 MB: ...' (maximum > > value it managed to write is ~800MB), or just freezes with > > buffer-related message (may try to reproduct panic to get it). > > I'm seeing the same thing but I got a useful vmcore and crash.txt out of > it. I can put them online if anyone wants to see them. [ The panic message and backtrace from ddb is at http://people.freebsd.org/~wxs/crash.txt ] (kgdb) frame 12 #12 0xffffffff80572e7f in prison_priv_check (cred=0xffffff00168f5900, priv=334) at /usr/home/wxs/freebsd/src/head/sys/kern/kern_jail.c:3315 3315 switch (priv) { (kgdb) p priv $6 = 334 334 is PRIV_VFS_MOUNT_OWNER sys/kern/kern_jail.c: 3451 case PRIV_VFS_MOUNT_OWNER: 3452 if (cred->cr_prison->pr_allow & PR_ALLOW_MOUNT) 3453 return (0); 3454 else 3455 return (EPERM); (kgdb) p/x *cred $7 = {cr_ref = 0x1, cr_uid = 0x0, cr_ruid = 0x0, cr_svuid = 0x0, cr_ngroups = 0x1, cr_groups = {0x0 }, cr_rgid = 0x0, cr_svgid = 0x0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_vimage = 0x0, cr_flags = 0x0, cr_pspare = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 0x0, ai_mask = {am_success = 0x0, am_failure = 0x0}, ai_termid = {at_port = 0x0, at_type = 0x0, at_addr = {0x0, 0x0, 0x0, 0x0}}, ai_asid = 0x0, ai_flags = 0x0}} (kgdb) cred->cr_prison is null? It is my understanding that when not jailed cred->cr_prison should be &prison0 with the new hierarchical jails. The fact that it is null is causing prison_priv_check to enter the switch statement, leading to the crash. I'm not sure why cred->cr_prison is null in this case. -- WXS From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 16:36:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACD1F106564A; Wed, 3 Jun 2009 16:36:55 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from mail.bestunion.it (mail.bestunion.it [85.18.201.87]) by mx1.freebsd.org (Postfix) with ESMTP id 387648FC0A; Wed, 3 Jun 2009 16:36:54 +0000 (UTC) (envelope-from aturetta@commit.it) Received: from [192.168.33.30] (nbcommit.home.commit.it [192.168.33.30] (may be forged)) (authenticated bits=0) by mail.bestunion.it (8.14.3/8.14.3) with ESMTP id n53GIEg3056886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jun 2009 18:18:15 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <4A26A239.5050608@commit.it> Date: Wed, 03 Jun 2009 18:18:01 +0200 From: Angelo Turetta User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Doug Barton References: <4A257B82.1000701@FreeBSD.org> In-Reply-To: <4A257B82.1000701@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.1 at mail.bestunion.it X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 16:36:56 -0000 Doug Barton wrote: > If you use a value of network_interfaces other than AUTO please speak > up so that we can make an intelligent decision about this issue. Maybe I am wrong, setting network_interfaces is the way I found I had to use to be able to rename cloned interfaces. eg: network_interfaces="lo0 em0 dmz" ifconfig_em0="up" cloned_interfaces="vlan0" ifconfig_vlan0_name="dmz" ifconfig_dmz="192.168.34.129/24 vlan 2 vlandev em0" I seem to remember I had to put that 'dmz' in network_interfaces, to make everything happy at boot. I can do more tests if needed. Ciao, Angelo. From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 17:20:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81CA21065677; Wed, 3 Jun 2009 17:20:41 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDCE8FC08; Wed, 3 Jun 2009 17:20:40 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MBu8o-0008JV-UY; Wed, 03 Jun 2009 21:20:43 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 69D95B878; Wed, 3 Jun 2009 21:20:33 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 62E94108839; Wed, 3 Jun 2009 21:20:33 +0400 (MSD) Date: Wed, 3 Jun 2009 21:20:33 +0400 From: Dmitry Marakasov To: Wesley Shields Message-ID: <20090603172033.GC27282@hades.panopticon> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090603160945.GC21014@atarininja.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Moll , bz@FreeBSD.org, jamie@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 17:20:42 -0000 * Wesley Shields (wxs@FreeBSD.org) wrote: Well, cred->cr_prison was the only thing to panic on in prison_priv_check, so that was obvious without the backtrace. I'll try to addd checking for null pointer here for now (as I'm more concerned in bringing my NAS back up). However, inability to dump properly still worries me. With this bug the box will not even reboot on panic :/ Switching to textdumps may be a temporary solution though. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 17:40:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8E0106566C; Wed, 3 Jun 2009 17:40:24 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.60.158]) by mx1.freebsd.org (Postfix) with ESMTP id 66B978FC08; Wed, 3 Jun 2009 17:40:24 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: by syn.atarininja.org (Postfix, from userid 1001) id BD0D85C37; Wed, 3 Jun 2009 13:40:23 -0400 (EDT) Date: Wed, 3 Jun 2009 13:40:23 -0400 From: Wesley Shields To: Dmitry Marakasov Message-ID: <20090603174023.GA23095@atarininja.org> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603172033.GC27282@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603172033.GC27282@hades.panopticon> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Moll , bz@FreeBSD.org, jamie@FreeBSD.org, freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 17:40:24 -0000 On Wed, Jun 03, 2009 at 09:20:33PM +0400, Dmitry Marakasov wrote: > * Wesley Shields (wxs@FreeBSD.org) wrote: > > Well, cred->cr_prison was the only thing to panic on in prison_priv_check, > so that was obvious without the backtrace. I'll try to addd checking > for null pointer here for now (as I'm more concerned in bringing > my NAS back up). Adding a check for null to jailed() in kern_jail.c will most likely work around the problem, but I was under the impression that cred->cr_prison should be &prison0 and never null with the new way of doing things. I'd still like to know why cr_prison is null. Of course, I have no idea what the implications of a null check in jailed() will be outside of this one scenario. -- WXS From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 18:59:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A29E51065686; Wed, 3 Jun 2009 18:59:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2848FC1A; Wed, 3 Jun 2009 18:59:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n53IxOvq035427; Wed, 3 Jun 2009 14:59:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n53IxOPA044377; Wed, 3 Jun 2009 14:59:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B5CF17302F; Wed, 3 Jun 2009 14:59:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090603185920.B5CF17302F@freebsd-current.sentex.ca> Date: Wed, 3 Jun 2009 14:59:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:59:32 -0000 TB --- 2009-06-03 17:29:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-03 17:29:44 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-06-03 17:29:45 - cleaning the object tree TB --- 2009-06-03 17:30:14 - cvsupping the source tree TB --- 2009-06-03 17:30:14 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-06-03 17:30:22 - building world TB --- 2009-06-03 17:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 17:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 17:30:22 - TARGET=sun4v TB --- 2009-06-03 17:30:22 - TARGET_ARCH=sparc64 TB --- 2009-06-03 17:30:22 - TZ=UTC TB --- 2009-06-03 17:30:22 - __MAKE_CONF=/dev/null TB --- 2009-06-03 17:30:22 - cd /src TB --- 2009-06-03 17:30:22 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 3 17:30:23 UTC 2009 >>> 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 Wed Jun 3 18:44:17 UTC 2009 TB --- 2009-06-03 18:44:17 - generating LINT kernel config TB --- 2009-06-03 18:44:17 - cd /src/sys/sun4v/conf TB --- 2009-06-03 18:44:17 - /usr/bin/make -B LINT TB --- 2009-06-03 18:44:18 - building LINT kernel TB --- 2009-06-03 18:44:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-03 18:44:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-03 18:44:18 - TARGET=sun4v TB --- 2009-06-03 18:44:18 - TARGET_ARCH=sparc64 TB --- 2009-06-03 18:44:18 - TZ=UTC TB --- 2009-06-03 18:44:18 - __MAKE_CONF=/dev/null TB --- 2009-06-03 18:44:18 - cd /src TB --- 2009-06-03 18:44:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jun 3 18:44:18 UTC 2009 >>> 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 -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/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -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 -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/sun4v/sun4v/hcall.S 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 -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/sun4v/sun4v/hviommu.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 -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/sparc64/sparc64/identcpu.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 -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/sparc64/sparc64/in_cksum.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 -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/sun4v/sun4v/intr_machdep.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 -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/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-03 18:59:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-03 18:59:20 - ERROR: failed to build lint kernel TB --- 2009-06-03 18:59:20 - 4644.33 user 426.38 system 5375.64 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:00:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EABC6106564A; Wed, 3 Jun 2009 20:00:17 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5C06B8FC18; Wed, 3 Jun 2009 20:00:13 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n53K0DXQ043438; Wed, 3 Jun 2009 22:00:13 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n53K0DTo043437; Wed, 3 Jun 2009 22:00:13 +0200 (CEST) (envelope-from marius) Date: Wed, 3 Jun 2009 22:00:13 +0200 From: Marius Strobl To: Eygene Ryabinkin , jeff@freebsd.org Message-ID: <20090603200013.GB43137@alchemy.franken.de> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> 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@freebsd.org, kmacy@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:00:18 -0000 On Wed, Jun 03, 2009 at 02:15:55PM +0400, Eygene Ryabinkin wrote: > Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > > Just now we won't be able to reach this with the current definition > > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > > become negative and that's bad. > > And while I am here: definition for PCPU_NAME_LEN seems to be wrong. > It is intended to fit ("CPU %d", cpuid) where cpuid <= MAXCPU. If this > is correct, then (sys/sys/pcpu.h, line 57) > > 1. sizeof(__XSTRING(MAXCPU) + 1) is a typo: typeof(__XSTRING(...) + 1) > is 'char *', so sizeof() will return the size of the pointer, not > the size of the string contents. The proper expression should be > 'sizeof(__XSTRING(MAXCPU)) + 1'. > > 2. one should not add one, but substract it: sizeof() accounts for the > trailing '\0' and we have two sizeof's, so the size of one '\0' > should be substracted -- this will give the maximal string buffer > length for CPU with its number, no less, no more. > > Does the attached patch looks sane? > diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h > index 63c3fa3..98705eb 100644 > --- a/sys/sys/pcpu.h > +++ b/sys/sys/pcpu.h > @@ -54,7 +54,7 @@ struct rm_queue { > struct rm_queue* volatile rmq_prev; > }; > > -#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU) + 1)) > +#define PCPU_NAME_LEN (sizeof("CPU ") + sizeof(__XSTRING(MAXCPU)) - 1) > > > /* This looks correct to me. Jeff? Marius From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:01:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 588221065677; Wed, 3 Jun 2009 20:01:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6778FC08; Wed, 3 Jun 2009 20:01:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C80F641C758; Wed, 3 Jun 2009 21:45:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id O7ufZ4IE71FI; Wed, 3 Jun 2009 21:45:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 639F941C757; Wed, 3 Jun 2009 21:45:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4CEB44448E6; Wed, 3 Jun 2009 19:42:24 +0000 (UTC) Date: Wed, 3 Jun 2009 19:42:23 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Wesley Shields In-Reply-To: <20090603160945.GC21014@atarininja.org> Message-ID: <20090603184215.L12292@maildrop.int.zabbadoz.net> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Michael Moll , dfr@freebsd.org, Dmitry Marakasov , Jamie Gritton , freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:01:09 -0000 On Wed, 3 Jun 2009, Wesley Shields wrote: Hi, >>>>... > [ The panic message and backtrace from ddb is at > http://people.freebsd.org/~wxs/crash.txt ] > ... > cred->cr_prison is null? It is my understanding that when not jailed > cred->cr_prison should be &prison0 with the new hierarchical jails. The > fact that it is null is causing prison_priv_check to enter the switch > statement, leading to the crash. > > I'm not sure why cred->cr_prison is null in this case. The question here is not if cred->cr_prison can be null but where is the cred coming from? If you look at init_main.c around lines 440 - 457 you'll find prison0 being further initialized (cpuset) and p_ucred->cr_prison being set to &prsion0. And a bit further down in l470 td_ucred is initialized from that. cr_prison should thus always be setup. What you are looking at above looks like a crget() with only cr_ngroups updated. [removing a lot more text as I was going on debugging in a very small window] I would start looking at svc_getcred() and blame at least the AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:05:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5398C10656D7; Wed, 3 Jun 2009 20:05:09 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id B5EA48FC1B; Wed, 3 Jun 2009 20:05:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n53K50Cm079776; Wed, 3 Jun 2009 15:05:00 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n53K4x93079775; Wed, 3 Jun 2009 15:04:59 -0500 (CDT) (envelope-from brooks) Date: Wed, 3 Jun 2009 15:04:59 -0500 From: Brooks Davis To: Angelo Turetta Message-ID: <20090603200459.GG28486@lor.one-eyed-alien.net> References: <4A257B82.1000701@FreeBSD.org> <4A26A239.5050608@commit.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gvF4niNJ+uBMJnEh" Content-Disposition: inline In-Reply-To: <4A26A239.5050608@commit.it> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Wed, 03 Jun 2009 15:05:00 -0500 (CDT) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:05:10 -0000 --gvF4niNJ+uBMJnEh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 06:18:01PM +0200, Angelo Turetta wrote: > Doug Barton wrote: >> If you use a value of network_interfaces other than AUTO please speak >> up so that we can make an intelligent decision about this issue. >=20 > Maybe I am wrong, setting network_interfaces is the way I found I had to= =20 > use to be able to rename cloned interfaces. >=20 > eg: >=20 > network_interfaces=3D"lo0 em0 dmz" > ifconfig_em0=3D"up" > cloned_interfaces=3D"vlan0" >=20 > ifconfig_vlan0_name=3D"dmz" > ifconfig_dmz=3D"192.168.34.129/24 vlan 2 vlandev em0" >=20 > I seem to remember I had to put that 'dmz' in network_interfaces, to make= =20 > everything happy at boot. I can do more tests if needed. Hmm, there might be a bug related to cloned interfaces and renaming. That should be easy to fix. -- Brooks --gvF4niNJ+uBMJnEh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKJtdrXY6L6fI4GtQRAg2OAJ9Vm/SWtVbWsvK9T00xfd1+8WrmAACglhIi rcFHXO28RxL5F1XHew+EPxw= =R/2Z -----END PGP SIGNATURE----- --gvF4niNJ+uBMJnEh-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:05:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597B61065786; Wed, 3 Jun 2009 20:05:47 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id C1EB98FC0A; Wed, 3 Jun 2009 20:05:46 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n53JisHU043301; Wed, 3 Jun 2009 21:44:54 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n53JirEU043300; Wed, 3 Jun 2009 21:44:53 +0200 (CEST) (envelope-from marius) Date: Wed, 3 Jun 2009 21:44:53 +0200 From: Marius Strobl To: Eygene Ryabinkin Message-ID: <20090603194453.GA43137@alchemy.franken.de> References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> 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@freebsd.org, sparc64@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , kmacy@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:05:48 -0000 On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > Wed, Jun 03, 2009 at 09:25:38AM +0400, Eygene Ryabinkin wrote: > > Tue, Jun 02, 2009 at 06:24:45PM -0400, FreeBSD Tinderbox wrote: > > > 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 -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/sun4v/sun4v/machdep.c > > > /src/sys/sun4v/sun4v/machdep.c:192: error: size of array '__assert192' is negative > > > *** Error code 1 > > > > > > Stop in /obj/sun4v/src/sys/LINT. > > > > This seems to be related to the recent NETISR changes, namely, the > > addition of the pc_netisr member to the struct pcpu: > > http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u > > > > I am not sure how large (void *) is on sun4v, but it seems to me > > that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > > > should be compensated for this change. Something like > > ----- > > #ifdef KTR > > #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) > > #else > > #define PCPU_MD_FIELDS_PAD 3 > > #endif > > ----- > > though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > Just now we won't be able to reach this with the current definition > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > become negative and that's bad. If it actually becomes negative the build should break again, which IMO is sufficient protection. > > The attached patch should fix this (although I have no sun4v to test > on, so take it with a grain of salt). I think this is overengineered, especially if not also adjusting the padding for other macros which may change the size of both MD and MI parts of struct pcpu. > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > missing something? > It's just not taken into account but AFAICT also dead code. Marius From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:06:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1F610656C9; Wed, 3 Jun 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 22A4F8FC0A; Wed, 3 Jun 2009 20:06:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B368F46B4C; Wed, 3 Jun 2009 16:06:05 -0400 (EDT) Date: Wed, 3 Jun 2009 21:06:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eygene Ryabinkin In-Reply-To: Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, marius@freebsd.org, sparc64@freebsd.org, FreeBSD Tinderbox , kmacy@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:06:08 -0000 On Wed, 3 Jun 2009, Eygene Ryabinkin wrote: >> This seems to be related to the recent NETISR changes, namely, the >> addition of the pc_netisr member to the struct pcpu: >> http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u >> >> I am not sure how large (void *) is on sun4v, but it seems to me >> that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > >> should be compensated for this change. Something like >> ----- >> #ifdef KTR >> #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) >> #else >> #define PCPU_MD_FIELDS_PAD 3 >> #endif >> ----- >> though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just > now we won't be able to reach this with the current definition for > PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative > and that's bad. > > The attached patch should fix this (although I have no sun4v to test on, so > take it with a grain of salt). > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts of > 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never > compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU > constant for sun4v (inexisting or defined everytime) or I am missing > something? Is there a reason not just to use __aligned(64) or the like on the first entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes from causing similar discomfort for the MD pcpu parts? Also, do we know why these alignment/sizing requirements exist for struct pcpu on sun4v but not other platforms? If this is about packing pcpu structures into properly aligned cache lines, again __aligned() might be the right approach to take... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:19:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81940106567A; Wed, 3 Jun 2009 20:19:33 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 133E88FC1A; Wed, 3 Jun 2009 20:19:32 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n53KJViI024035; Thu, 4 Jun 2009 00:19:31 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 4 Jun 2009 00:19:31 +0400 (MSD) From: Dmitry Morozovsky To: Doug Barton In-Reply-To: <4A255F8E.70604@FreeBSD.org> Message-ID: References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-834018739-765552451-1244060366=:1171" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Thu, 04 Jun 2009 00:19:31 +0400 (MSD) Cc: Alexander Leidinger , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:19:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---834018739-765552451-1244060366=:1171 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: On Tue, 2 Jun 2009, Doug Barton wrote: DB> Alexander Leidinger wrote: DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? DB> DB> Sounds great, I look forward to reviewing your patch. :) What do you think about attached one? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ ---834018739-765552451-1244060366=:1171 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=fsck_y_flags.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=fsck_y_flags.patch SW5kZXg6IGV0Yy9kZWZhdWx0cy9yYy5jb25mDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvZXRjL2RlZmF1bHRz L3JjLmNvbmYsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjM1Nw0KZGlmZiAt dSAtcjEuMzU3IHJjLmNvbmYNCi0tLSBldGMvZGVmYXVsdHMvcmMuY29uZgky IEp1biAyMDA5IDIyOjE1OjQ3IC0wMDAwCTEuMzU3DQorKysgZXRjL2RlZmF1 bHRzL3JjLmNvbmYJMyBKdW4gMjAwOSAyMDoxODoxNSAtMDAwMA0KQEAgLTgz LDYgKzgzLDcgQEANCiANCiByb290X3J3X21vdW50PSJZRVMiCSMgU2V0IHRv IE5PIHRvIGluaGliaXQgcmVtb3VudGluZyByb290IHJlYWQtd3JpdGUuDQog ZnNja195X2VuYWJsZT0iTk8iCSMgU2V0IHRvIFlFUyB0byBkbyBmc2NrIC15 IGlmIHRoZSBpbml0aWFsIHByZWVuIGZhaWxzLg0KK2ZzY2tfeV9mbGFncz0i IgkJIyBBZGRpdGlvbmFsIGZsYWdzIGZvciBmc2NrIC15DQogYmFja2dyb3Vu ZF9mc2NrPSJZRVMiCSMgQXR0ZW1wdCB0byBydW4gZnNjayBpbiB0aGUgYmFj a2dyb3VuZCB3aGVyZSBwb3NzaWJsZS4NCiBiYWNrZ3JvdW5kX2ZzY2tfZGVs YXk9IjYwIiAjIFRpbWUgdG8gd2FpdCAoc2Vjb25kcykgYmVmb3JlIHN0YXJ0 aW5nIHRoZSBmc2NrLg0KIG5ldGZzX3R5cGVzPSJuZnM6TkZTIG5mczQ6TkZT NCBzbWJmczpTTUIgcG9ydGFsZnM6UE9SVEFMIG53ZnM6TldGUyIgIyBOZXQg ZmlsZXN5c3RlbXMuDQpJbmRleDogZXRjL3JjLmQvZnNjaw0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL2V0Yy9y Yy5kL2ZzY2ssdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEzDQpkaWZmIC11 IC1yMS4xMyBmc2NrDQotLS0gZXRjL3JjLmQvZnNjawkyMyBKdW4gMjAwOCAw NDo0Njo1NCAtMDAwMAkxLjEzDQorKysgZXRjL3JjLmQvZnNjawkzIEp1biAy MDA5IDIwOjE4OjE1IC0wMDAwDQpAQCAtNDQsOCArNDQsOCBAQA0KIAkJCTs7 DQogCQk4KQ0KIAkJCWlmIGNoZWNreWVzbm8gZnNja195X2VuYWJsZTsgdGhl bg0KLQkJCQllY2hvICJGaWxlIHN5c3RlbSBwcmVlbiBmYWlsZWQsIHRyeWlu ZyBmc2NrIC15LiINCi0JCQkJZnNjayAteQ0KKwkJCQllY2hvICJGaWxlIHN5 c3RlbSBwcmVlbiBmYWlsZWQsIHRyeWluZyBmc2NrIC15ICR7ZnNja195X2Zs YWdzfSINCisJCQkJZnNjayAteSAke2ZzY2tfeV9mbGFnc30NCiAJCQkJY2Fz ZSAkPyBpbg0KIAkJCQkwKQ0KIAkJCQkJOzsNCkluZGV4OiBzYmluL2ZzY2tf bXNkb3Nmcy9tYWluLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBm aWxlOiAvaG9tZS9uY3ZzL3NyYy9zYmluL2ZzY2tfbXNkb3Nmcy9tYWluLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjE1DQpkaWZmIC11IC1yMS4xNSBt YWluLmMNCi0tLSBzYmluL2ZzY2tfbXNkb3Nmcy9tYWluLmMJMTAgRmViIDIw MDUgMDk6Mzk6NTEgLTAwMDAJMS4xNQ0KKysrIHNiaW4vZnNja19tc2Rvc2Zz L21haW4uYwkzIEp1biAyMDA5IDIwOjE4OjE1IC0wMDAwDQpAQCAtNzQsOCAr NzQsMTAgQEANCiAJaW50IGNoOw0KIA0KIAlza2lwY2xlYW4gPSAxOw0KLQl3 aGlsZSAoKGNoID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJmRm5weSIpKSAhPSAt MSkgew0KKwl3aGlsZSAoKGNoID0gZ2V0b3B0KGFyZ2MsIGFyZ3YsICJDZkZu cHkiKSkgIT0gLTEpIHsNCiAJCXN3aXRjaCAoY2gpIHsNCisJCWNhc2UgJ0Mn OiAvKiBmb3IgZnNja19mZnMgY29tcGF0aWJpbGl0eSAqLw0KKwkJCWJyZWFr Ow0KIAkJY2FzZSAnZic6DQogCQkJc2tpcGNsZWFuID0gMDsNCiAJCQlicmVh azsNCkluZGV4OiBzYmluL2ZzY2tfbXNkb3Nmcy9mc2NrX21zZG9zZnMuOA0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3NiaW4vZnNja19tc2Rvc2ZzL2ZzY2tfbXNkb3Nmcy44LHYNCnJldHJp ZXZpbmcgcmV2aXNpb24gMS4xNQ0KZGlmZiAtdSAtcjEuMTUgZnNja19tc2Rv c2ZzLjgNCi0tLSBzYmluL2ZzY2tfbXNkb3Nmcy9mc2NrX21zZG9zZnMuOAkx MCBGZWIgMjAwNSAwOTozOTo1MSAtMDAwMAkxLjE1DQorKysgc2Jpbi9mc2Nr X21zZG9zZnMvZnNja19tc2Rvc2ZzLjgJMyBKdW4gMjAwOSAyMDoxODoxNSAt MDAwMA0KQEAgLTMyLDcgKzMyLDcgQEANCiAuXCINCiAuXCIgJEZyZWVCU0Q6 IHNyYy9zYmluL2ZzY2tfbXNkb3Nmcy9mc2NrX21zZG9zZnMuOCx2IDEuMTUg MjAwNS8wMi8xMCAwOTozOTo1MSBydSBFeHAgJA0KIC5cIg0KLS5EZCBBdWd1 c3QgMTMsIDE5OTUNCisuRGQgSnVuZSA0LCAyMDA5DQogLkR0IEZTQ0tfTVNE T1NGUyA4DQogLk9zDQogLlNoIE5BTUUNCkBAIC00MSwxMCArNDEsMTAgQEAN CiAuU2ggU1lOT1BTSVMNCiAuTm0NCiAuRmwgcA0KLS5PcCBGbCBmDQorLk9w IEZsIENmDQogLkFyIGZpbGVzeXN0ZW0gLi4uDQogLk5tDQotLk9wIEZsIG55 DQorLk9wIEZsIENueQ0KIC5BciBmaWxlc3lzdGVtIC4uLg0KIC5TaCBERVND UklQVElPTg0KIFRoZQ0KQEAgLTgwLDYgKzgwLDEwIEBADQogLlBwDQogVGhl IG9wdGlvbnMgYXJlIGFzIGZvbGxvd3M6DQogLkJsIC10YWcgLXdpZHRoIGlu ZGVudA0KKy5JdCBGbCBDDQorQ29tcGF0aWJpbGl0eSB3aXRoIHRoZSBjb3Jy ZXNwb25kaW5nDQorLlhyIGZzY2sgOA0KK29wdGlvbiAoc2tpcCBjaGVjayBp ZiBjbGVhbiksIGRlZmluZWQgdG8gbm8tb3AuDQogLkl0IEZsIEYNCiBDb21w YXRpYmlsaXR5IHdpdGggdGhlIHdyYXBwZXINCiAuWHIgZnNjayA4DQo= ---834018739-765552451-1244060366=:1171-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 20:37:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBC21065687; Wed, 3 Jun 2009 20:37:37 +0000 (UTC) (envelope-from erik@barragry.com) Received: from cork.barragry.com (cork.barragry.com [72.232.202.93]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1EF8FC12; Wed, 3 Jun 2009 20:37:36 +0000 (UTC) (envelope-from erik@barragry.com) Received: by cork.barragry.com (Postfix, from userid 1006) id BC33C1D8012; Wed, 3 Jun 2009 15:37:36 -0500 (CDT) Date: Wed, 3 Jun 2009 15:37:36 -0500 From: Erik Osterholm To: Brooks Davis Message-ID: <20090603203736.GA23840@barragry.com> References: <4A257B82.1000701@FreeBSD.org> <20090602230648.GB88740@barragry.com> <20090603141321.GC28486@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603141321.GC28486@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Do you use a value other than AUTO for network_interfaces? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 20:37:37 -0000 On Wed, Jun 03, 2009 at 09:13:21AM -0500, Brooks Davis wrote: > On Tue, Jun 02, 2009 at 06:06:48PM -0500, Erik Osterholm wrote: > > On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: > > > Up till Sunday in 8-current, and for a long time in general > > > network.subr (part of the rc.d system) has emitted a warning > > > that values of network_interfaces other than AUTO are > > > deprecated. I removed that warning in HEAD Sunday, and there is > > > no a discussion about whether or not it should be put back, and > > > whether or not there is any need for the user to specify the > > > list of network interfaces at all. > > > > > > If you use a value of network_interfaces other than AUTO please > > > speak up so that we can make an intelligent decision about this > > > issue. > > > > > > Thanks, > > > > > > Doug > > > > I'll have to preface this by disclosing that I have not been > > running -current, nor following any changes to the RC system. > > > > In 7.1, if you compile a custom kernel and comment out an > > interface (such that it is compiled as a module), one way to > > ensure that the module is loaded is to explicitly list it in > > network_interfaces. If -current works the same way, then users > > will be required to modify /boot/loader.conf in order to load the > > module. Could there could be possible side-effects to this > > change, since the loading of the module happens at a different > > time? > > Do you actually do this? We do use modules for a number of machines instead of leaving the NIC driver compiled into the kernel. I think that the impetus for doing this involved a driver bug back in 6.1 which crashed the machine if it passed too much traffic. The thinking was that for future bugs, it would be easier and faster to ship off the kernel module, unload the old one, load the new one, and reconfigure the interface than to ship over a whole new kernel and reboot. We also used to have a couple of machines for which the vendor supplied NIC kernel modules, but I don't think that they're in use anymore. And yes, the machines use network_interfaces to load the modules, though I'm not arrogant enough to assume that this is the best way. Maybe it is worth considering changing ifconfig_$DRIVER to load the driver? Erik From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 23:14:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C593106567B; Wed, 3 Jun 2009 23:14:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 1E8838FC08; Wed, 3 Jun 2009 23:14:40 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [172.24.105.139] (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KKO00BF3R8F1J70@asmtp011.mac.com>; Wed, 03 Jun 2009 16:14:40 -0700 (PDT) Message-id: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> From: Marcel Moolenaar To: Robert Watson In-reply-to: Date: Wed, 03 Jun 2009 16:14:38 -0700 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> X-Mailer: Apple Mail (2.935.3) Cc: kmacy@freebsd.org, marius@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, Eygene Ryabinkin , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 23:14:40 -0000 On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > Is there a reason not just to use __aligned(64) or the like on the > first entry of the MD PCPU structure for sun4v to avoid future MI > pcpu changes from causing similar discomfort for the MD pcpu parts? > Also, do we know why these alignment/sizing requirements exist for > struct pcpu on sun4v but not other platforms? If this is about > packing pcpu structures into properly aligned cache lines, again > __aligned() might be the right approach to take... Adding __aligned(xx) doesn't make it aligned. For example, malloc(3) only aligns at 16-byte boundaries, so any user-space structure that has __aligned(x>16) must manually make sure that this is actually the case by over-allocating and then adjusting the pointer to an x>16 aligned address. Likewise for the kernel, though it's easier in the kernel to get something that's page-aligned... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 23:35:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60FFC106564A; Wed, 3 Jun 2009 23:35:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 374218FC15; Wed, 3 Jun 2009 23:35:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CE13046B2C; Wed, 3 Jun 2009 19:35:36 -0400 (EDT) Date: Thu, 4 Jun 2009 00:35:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marcel Moolenaar In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: kmacy@freebsd.org, marius@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, Eygene Ryabinkin , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 23:35:38 -0000 On Wed, 3 Jun 2009, Marcel Moolenaar wrote: >> Is there a reason not just to use __aligned(64) or the like on the first >> entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes >> from causing similar discomfort for the MD pcpu parts? Also, do we know >> why these alignment/sizing requirements exist for struct pcpu on sun4v but >> not other platforms? If this is about packing pcpu structures into >> properly aligned cache lines, again __aligned() might be the right approach >> to take... > > Adding __aligned(xx) doesn't make it aligned. For example, malloc(3) only > aligns at 16-byte boundaries, so any user-space structure that has > __aligned(x>16) must manually make sure that this is actually the case by > over-allocating and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel to get something > that's page-aligned... FYI, I wan't sure if that was the problem that caused the alignment code in this case. However, I agree that malloc(9)'s lack of alignment support is a problem, and one that should be pretty easy to resolve by simply putting a bit of over-allocation code in malloc(9), and adding a malloc_aligned(9) variation, or perhaps just an M_CACHEALIGN flag. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jun 3 23:52:35 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB41F1065673 for ; Wed, 3 Jun 2009 23:52:35 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 75F348FC16 for ; Wed, 3 Jun 2009 23:52:33 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MC0G0-0005lg-OS; Thu, 04 Jun 2009 03:52:32 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 5241CB878; Thu, 4 Jun 2009 03:52:27 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 44E54108839; Thu, 4 Jun 2009 03:52:27 +0400 (MSD) Date: Thu, 4 Jun 2009 03:52:27 +0400 From: Dmitry Marakasov To: "O. Hartmann" Message-ID: <20090603235227.GB15659@hades.panopticon> References: <4A2504AA.1020406@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4A2504AA.1020406@zedat.fu-berlin.de> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@FreeBSD.org Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Jun 2009 23:52:36 -0000 * O. Hartmann (ohartman@zedat.fu-berlin.de) wrote: Just my 2 cents: the same behaviour, and while mount -o tcp succeeds, umounting behaves strangely: if I umount nfs filesystem, umount process hangs for some time, then exits with `umount: hive: RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually umounted immediately after umount is called. This all also breaks amd severely (however it already haven't been working on current for a long time for me). -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 00:24:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31281065673; Thu, 4 Jun 2009 00:24:19 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC948FC0A; Thu, 4 Jun 2009 00:24:19 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:34483 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC0kj-000IEc-Bx; Wed, 03 Jun 2009 19:24:18 -0500 Date: Wed, 3 Jun 2009 19:24:04 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: kmacy@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Score: -2.3 (--) X-LERCTR-Spam-Score: -2.3 (--) X-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.3/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: freebsd-current@freebsd.org Subject: ZFS / arc_max X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 00:24:20 -0000 After Peter Wemm's post yesterday that he fixed some of the SVN->CVS breakage, I pulled a new csup of -CURRENT today. I recompiled everything, and installed it. It appears that something(tm) changed with regards to the vfs.zfs.arc_max tuneable, and this number looks more reasonable than "all of memory": vfs.zfs.arc_max: 4484431872 This is with 16G real in the box. I've removed my setting of this to 8G (as it seems to be ignored anyway). We'll see how the next few days goes. (BTW, on the older kernel, setting vfs.zfs.arc_max to 8G allowed the machine to stay up and do full backups, etc). Please let me know of anything else you need. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 01:07:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC58106564A for ; Thu, 4 Jun 2009 01:07:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2A3298FC1D for ; Thu, 4 Jun 2009 01:07:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MC1QT-0006dk-BE for freebsd-current@FreeBSD.org; Thu, 04 Jun 2009 05:07:25 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id E90A0B878 for ; Thu, 4 Jun 2009 05:07:19 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id E3C93108839; Thu, 4 Jun 2009 05:07:19 +0400 (MSD) Date: Thu, 4 Jun 2009 05:07:19 +0400 From: Dmitry Marakasov To: freebsd-current@FreeBSD.org Message-ID: <20090604010719.GC15659@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: libarchive extattr i386/amd64 syscall issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 01:07:26 -0000 Hi! The problem: on recent current, 32bit bsdtar won't write archives when running under 64bit kernel, dying with exit code 140 and `Bad system call' message. I've ran into that using i386 tinderbox jail on amd64 host. The problem actually happens in libarchive: --- lib/libarchive/archive_read_disk_entry_from_file.c --- 484 if (!a->follow_symlinks) 485 list_size = extattr_list_link(path, namespace, NULL, 0); // <-- HERE 486 else 487 list_size = extattr_list_file(path, namespace, NULL, 0); --- lib/libarchive/archive_read_disk_entry_from_file.c --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 02:06:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37DA106566B for ; Thu, 4 Jun 2009 02:06:28 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2FA8FC13 for ; Thu, 4 Jun 2009 02:06:27 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MC2Lb-0007H4-L2 for freebsd-current@FreeBSD.org; Thu, 04 Jun 2009 06:06:27 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id CA613B878 for ; Thu, 4 Jun 2009 06:06:22 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id C3C4B108839; Thu, 4 Jun 2009 06:06:22 +0400 (MSD) Date: Thu, 4 Jun 2009 06:06:22 +0400 From: Dmitry Marakasov To: freebsd-current@FreeBSD.org Message-ID: <20090604020622.GA19897@hades.panopticon> References: <20090604010719.GC15659@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090604010719.GC15659@hades.panopticon> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: libarchive extattr i386/amd64 syscall issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 02:06:29 -0000 * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: For ones experiencing the same problem, this patch worked for me. It disables extattr support in libarchive, but tar now works. --- libarchive.patch begins here --- --- src/lib/libarchive/config_freebsd.h.orig 2009-06-04 05:03:22.000000000 +0400 +++ src/lib/libarchive/config_freebsd.h 2009-06-04 05:03:41.000000000 +0400 @@ -34,8 +34,8 @@ #define HAVE_ACL_SET_FD_NP 1 #define HAVE_ACL_SET_FILE 1 #define HAVE_ACL_USER 1 -#define HAVE_EXTATTR_GET_FILE 1 -#define HAVE_EXTATTR_LIST_FILE 1 +#define HAVE_EXTATTR_GET_FILE 0 +#define HAVE_EXTATTR_LIST_FILE 0 #define HAVE_EXTATTR_SET_FD 1 #define HAVE_EXTATTR_SET_FILE 1 #define HAVE_SYS_ACL_H 1 --- libarchive.patch ends here --- -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 03:26:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA9C1065670; Thu, 4 Jun 2009 03:26:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 119BE8FC15; Thu, 4 Jun 2009 03:26:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=kmbRGkKw9GitWXfA3Z7SogtG+eNtymOIW8v3Oow0N7GISobsQhJbjNdHQaZ/2UXzGHWnwhTMMjAUtpk2ztKC0hZnz+HGoOJyd0WhjdTJfNPtZqd2PeCjiuQ/3T+zh0klpWeEPe3f2jHAEy21smZhUvDEF0pcNTNexQBicF0PQVo=; Received: from phoenix.codelabs.ru (ppp85-141-161-25.pppoe.mtu-net.ru [85.141.161.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MC3au-0000Ch-Rq; Thu, 04 Jun 2009 07:26:21 +0400 Date: Thu, 4 Jun 2009 07:26:17 +0400 From: Eygene Ryabinkin To: Marius Strobl Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090603194453.GA43137@alchemy.franken.de> Sender: rea-fbsd@codelabs.ru Cc: kmacy@freebsd.org, sparc64@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , khb@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 03:26:23 -0000 Marius, good day. First, thanks for committing the fix. Wed, Jun 03, 2009 at 09:44:53PM +0200, Marius Strobl wrote: > On Wed, Jun 03, 2009 at 01:54:30PM +0400, Eygene Ryabinkin wrote: > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. > > Just now we won't be able to reach this with the current definition > > for PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can > > become negative and that's bad. > > If it actually becomes negative the build should break again, > which IMO is sufficient protection. Yes, "protection" is here. But it will break the build again and that's a bit uncomfortable. > > The attached patch should fix this (although I have no sun4v to test > > on, so take it with a grain of salt). > > I think this is overengineered, especially if not also > adjusting the padding for other macros which may change the > size of both MD and MI parts of struct pcpu. Hmm, don't fully understand about "other macros". Could you, please, provide an example? > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > missing something? > > It's just not taken into account but AFAICT also dead code. Yes, seems like so. John, may be we can eliminate the only reference to KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be unused (grep'ped -CURRENT sources). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 04:08:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDD6A106566B for ; Thu, 4 Jun 2009 04:08:05 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE74B8FC15 for ; Thu, 4 Jun 2009 04:08:04 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (adsl-67-114-117.shv.bellsouth.net [98.67.114.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id D8C468ACED0C for ; Wed, 3 Jun 2009 23:08:02 -0500 (CDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id n54480vZ002123 for ; Wed, 3 Jun 2009 23:08:00 -0500 (CDT) (envelope-from morganw@chemikals.org) Date: Wed, 3 Jun 2009 23:08:00 -0500 (CDT) From: Wes Morgan To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Panic in kern_jail prison_priv_check() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 04:08:06 -0000 I'm getting a reproducible panic trying to access an nfs-exported zfs filesystem with a kernel from a few hours ago, as well as one from over the weekend. Filesystem mounts ok, but accessing it causes an immediate panic. Looks like possibly a problem between zfs and the new jail code. Neither of the zfs functions involved have been changed in a way that would appear to affect this, though. Could be wrong! It may not be pertinent but I do have vfs.usermount enabled. The value for "priv" in prison_priv_check() is 334, PRIV_VFS_MOUNT_OWNER. The contents of the "credentials" is: $6 = {cr_ref = 1, cr_uid = 4294967294, cr_ruid = 0, cr_svuid = 0, cr_ngroups = 1, cr_groups = {4294967294, 0, 2, 3, 4, 5, 6, 20, 25, 26, 31, 0, 0, 0, 0, 0}, cr_rgid = 0, cr_svgid = 0, cr_uidinfo = 0x0, cr_ruidinfo = 0x0, cr_prison = 0x0, cr_vimage = 0x0, cr_flags = 0, cr_pspare = {0x0, 0x0}, cr_label = 0x0, cr_audit = {ai_auid = 0, ai_mask = {am_success = 0, am_failure = 0}, ai_termid = {at_port = 0, at_type = 0, at_addr = {0, 0, 0, 0}}, ai_asid = 0, ai_flags = 0}} Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x6dc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803109e1 stack pointer = 0x28:0xffffff80c58de5a0 frame pointer = 0x28:0xffffff0006248a00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1186 (nfsd: service) trap number = 12 panic: page fault cpuid = 2 Syncing disks, vnodes remaining...0 All buffers synced. Uptime: 1m23s Physical memory: 8181 MB Dumping 1662 MB:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 (kgdb) #0 doadump () at pcpu.h:223 #1 0x0000000000000000 in ?? () #2 0xffffffff803335fd in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:420 #3 0xffffffff803338ed in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #4 0xffffffff804fdd68 in trap_fatal (frame=0xffffff80c58de4f0, eva=1756) at /usr/src/sys/amd64/amd64/trap.c:852 #5 0xffffffff804fdfcf in trap_pfault (frame=0xffffff80c58de4f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:768 #6 0xffffffff804fe917 in trap (frame=0xffffff80c58de4f0) at /usr/src/sys/amd64/amd64/trap.c:494 #7 0xffffffff804da7e3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff803109e1 in prison_priv_check (cred=0xffffff0006248a00, priv=334) at /usr/src/sys/kern/kern_jail.c:3315 #9 0xffffffff80329380 in priv_check_cred (cred=0xffffff0006248a00, priv=334, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/kern_priv.c:93 #10 0xffffffff808bf92e in secpolicy_vnode_access (cred=0xffffff0006248a00, vp=0xffffff0006a1d760, owner=Variable "owner" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_policy.c:125 #11 0xffffffff809207f7 in zfs_zaccess (zp=0xffffff0006a1e758, mode=Variable "mode" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_acl.c:2435 #12 0xffffffff8093244e in zfs_freebsd_access (ap=Variable "ap" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1067 #13 0xffffffff805203d2 in VOP_ACCESS_APV (vop=Variable "vop" is not available. ) at vnode_if.c:571 #14 0xffffffff804495c2 in nfsrv_access (vp=0xffffff0006a1d760, accmode=128, cred=0xffffff0006248a00, rdonly=Variable "rdonly" is not available. ) at vnode_if.h:254 #15 0xffffffff80449c86 in nfsrv3_access (nfsd=0xffffff80c58dea10, slp=Variable "slp" is not available. ) at /usr/src/sys/nfsserver/nfs_serv.c:238 #16 0xffffffff8045618b in nfssvc_program (rqst=0xffffff000a366000, xprt=Variable "xprt" is not available. ) at /usr/src/sys/nfsserver/nfs_srvkrpc.c:410 #17 0xffffffff8047292a in svc_run_internal (pool=0xffffff00060eda00, ismaster=0) at /usr/src/sys/rpc/svc.c:883 #18 0xffffffff80472a9d in svc_thread_start (arg=Variable "arg" is not available. ) at /usr/src/sys/rpc/svc.c:1188 #19 0xffffffff8030d347 in fork_exit ( callout=0xffffffff80472a8f , arg=0xffffff00060eda00, frame=0xffffff80c58dec90) at /usr/src/sys/kern/kern_fork.c:829 #20 0xffffffff804dabee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 Copyright (c) 1992-2009 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 8.0-CURRENT #6: Wed Jun 3 19:46:36 CDT 2009 root@volatile:/usr/obj/usr/src/sys/VOLATILE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.68-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8287219712 (7903 MB) ACPI APIC Table: <090308 APIC1358> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard cryptosoft0: on motherboard acpi0: <090308 XSDT1358> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci7: on pcib1 mpt0: port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff,0xfbfe0000-0xfbfeffff irq 16 at device 0.0 on pci7 mpt0: [ITHREAD] mpt0: MPI Version=1.5.19.0 pcib2: irq 16 at device 28.0 on pci0 pci4: on pcib2 pcib3: at device 0.0 on pci4 pci6: on pcib3 mpt1: port 0xd800-0xd8ff mem 0xfbbfc000-0xfbbfffff,0xfbbe0000-0xfbbeffff irq 18 at device 6.0 on pci6 mpt1: [ITHREAD] mpt1: MPI Version=1.5.16.0 mpt1: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt1: 0 Active Volumes (2 Max) mpt1: 0 Hidden Drive Members (14 Max) Ambiguous scbus configuration for mpt1 bus 1, cannot wire down. The kernel config entry for scbus1 should specify a controller bus. Scbus will be assigned dynamically. pcib4: mem 0xfb7ffc00-0xfb7ffc7f irq 16 at device 0.1 on pci4 pci5: on pcib4 pcib5: irq 16 at device 28.4 on pci0 pci3: on pcib5 bge0: mem 0xfb6f0000-0xfb6fffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:22:15:56:bb:1e bge0: [ITHREAD] pcib6: irq 17 at device 28.5 on pci0 pci2: on pcib6 bge1: mem 0xfb5f0000-0xfb5fffff irq 17 at device 0.0 on pci2 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:22:15:56:ba:24 bge1: [ITHREAD] uhci0: port 0xac00-0xac1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f00 usbus0: on uhci0 uhci1: port 0xb000-0xb01f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f00 usbus1: on uhci1 uhci2: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f00 usbus2: on uhci2 ehci0: mem 0xfb3ff800-0xfb3ffbff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib7: at device 30.0 on pci0 pci1: on pcib7 vgapci0: port 0xcc00-0xcc7f mem 0xf8000000-0xf9ffffff,0xfb4c0000-0xfb4fffff at device 3.0 on pci1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xfb3ffc00-0xfb3fffff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI v1.10 controller with 4 3Gbps ports, PM not supported ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 91, should be 90 [20070320] coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ad0: 152627MB at ata0-master UDMA100 ZFS filesystem version 13 ZFS storage pool version 13 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 acd0: DVDR at ata2-master SATA150 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers da1: Command Queueing Enabled da1: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da2 at mpt0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 300.000MB/s transfers da2: Command Queueing Enabled da2: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C) da3 at mpt0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 300.000MB/s transfers da3: Command Queueing Enabled da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da4 at mpt0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 300.000MB/s transfers da4: Command Queueing Enabled da4: 286188MB (586114704 512 byte sectors: 255H 63S/T 36483C) da6 at mpt0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 300.000MB/s transfers da6: Command Queueing Enabled da6: 286188MB (586114704 512 byte sectors: 255H 63S/T 36483C) da7 at mpt0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device da7: 300.000MB/s transfers da7: Command Queueing Enabled da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da8 at mpt1 bus 0 target 0 lun 0 da8: Fixed Direct Access SCSI-5 device da8: 300.000MB/s transfers da8: Command Queueing Enabled da8: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da9 at mpt1 bus 0 target 1 lun 0 da9: Fixed Direct Access SCSI-5 device da9: 300.000MB/s transfers da9: Command Queueing Enabled da9: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da10 at mpt1 bus 0 target 2 lun 0 da10: Fixed Direct Access SCSI-5 device da10: 300.000MB/s transfers da10: Command Queueing Enabled da10: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da11 at mpt1 bus 0 target 3 lun 0 da11: Fixed Direct Access SCSI-5 device da11: 300.000MB/s transfers da11: Command Queueing Enabled da11: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da12 at mpt1 bus 0 target 4 lun 0 da12: Fixed Direct Access SCSI-5 device da12: 300.000MB/s transfers da12: Command Queueing Enabled da12: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da13 at mpt1 bus 0 target 5 lun 0 da13: Fixed Direct Access SCSI-5 device da13: 300.000MB/s transfers da13: Command Queueing Enabled da13: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da14 at mpt1 bus 0 target 6 lun 0 da14: Fixed Direct Access SCSI-5 device da14: 300.000MB/s transfers da14: Command Queueing Enabled da14: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) da15 at mpt1 bus 0 target 7 lun 0 da15: Fixed Direct Access SCSI-5 device da15: 300.000MB/s transfers da15: Command Queueing Enabled da15: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! uhub3: 6 ports with 6 removable, self powered ugen0.2: at usbus0 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present GEOM: da7: partition 1 does not start on a track boundary. GEOM: da7: partition 1 does not end on a track boundary. Trying to mount root from zfs:root Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x6dc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803109e1 stack pointer = 0x28:0xffffff80c58de5a0 frame pointer = 0x28:0xffffff0006248a00 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1186 (nfsd: service) trap number = 12 panic: page fault cpuid = 2 Syncing disks, vnodes remaining...0 All buffers synced. Uptime: 1m23s Physical memory: 8181 MB Dumping 1662 MB:0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1647 1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 04:43:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44220106566B for ; Thu, 4 Jun 2009 04:43:39 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id E7BA78FC1F for ; Thu, 4 Jun 2009 04:43:38 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n544hTm7037155; Wed, 3 Jun 2009 21:43:29 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id jd2zbjwpn3san6n9p3jg2t6wi6; Wed, 03 Jun 2009 21:43:28 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A2750F0.3070106@freebsd.org> Date: Wed, 03 Jun 2009 21:43:28 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Dmitry Marakasov References: <20090604010719.GC15659@hades.panopticon> In-Reply-To: <20090604010719.GC15659@hades.panopticon> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 04:43:39 -0000 Dmitry Marakasov wrote: > > The problem: on recent current, 32bit bsdtar won't write archives when > running under 64bit kernel, dying with exit code 140 and `Bad system call' > message. I've ran into that using i386 tinderbox jail on amd64 host. > The problem actually happens in libarchive: > > --- lib/libarchive/archive_read_disk_entry_from_file.c --- > 484 if (!a->follow_symlinks) > 485 list_size = extattr_list_link(path, namespace, NULL, 0); // <-- HERE > 486 else > 487 list_size = extattr_list_file(path, namespace, NULL, 0); > --- lib/libarchive/archive_read_disk_entry_from_file.c --- Yes, it looks like only about half of the extattr calls are actually connected in the freebsd32 compatibility layer. (see below) According to SVN history, peter@ reserved these slots back in December 2003 but no one ever went back and connected them up. I don't know if there was a reason for not connecting them or if simply no one remembered to do so. I would guess the latter; the ones that are connected were all implemented before mid-2002. I don't see any obvious reason these should not just work. If you're feeling adventurous, you could try copying the data from /usr/src/kern/syscalls.master and see what happens. I don't have a 64-bit system handy here or I would try this myself. You can test by going to /usr/src/lib/libarchive/test and running "make check". That will build and run the libarchive test suite, which does exercise the extended attribute support. (Of course, you should revert your change first so that the extended attribute support is actually compiled.) Let me know if you find anything, Tim $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int cmd, \ 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 07:07:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7FEA1065672; Thu, 4 Jun 2009 07:07:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6381D8FC0C; Thu, 4 Jun 2009 07:07:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BADBF1900F; Thu, 4 Jun 2009 07:07:04 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,RDNS_DYNAMIC autolearn=no version=3.2.5 Received: from tau.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 4 Jun 2009 07:07:04 +0000 (GMT) Date: Thu, 4 Jun 2009 08:07:06 +0100 From: Bruce Cran To: "M. Vale" Message-ID: <20090604080706.56fbd83c@tau.draftnet> In-Reply-To: <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.1; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: reebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 07:07:09 -0000 On Wed, 27 May 2009 17:09:30 +0100 "M. Vale" wrote: > Hi, maybe i've come a bit latter and miss something, but I'm trying > to build virtual box in FreeBSD 7.1p5 (64bits) and whem making > kbuild it stops with this error: > [...] > > /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: > *** target file `virtualbox' has both : and :: entries. > Stop . > kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' > gmake: *** > [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build] > Error 2 > ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk > *** Error code 2 > > Stop in /usr/ports/devel/kBuild. > " I'm running 8-CURRENT from about a week ago and I see a different failure when building devel/kBuild - but only when run from portmaster; it succeeds when I run "make" in /usr/ports/devel/kBuild Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/utils.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/strverscmp.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/obstack.c kBuild: Compiling kmk_sed - /home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/src/sed/lib/getline.c kmk: *** No rule to make target `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild-0.1.5.p1/out/freebsd.amd64/release/obj/kUtil/kUtil.a', needed by `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild-0.1.5.p1/out/freebsd.amd64/release/obj/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kmk/kmk'. Stop. kmk: *** Waiting for unfinished jobs.... kmk: Leaving directory `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' kmk: Entering directory `/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' kmk: *** Exiting with status 2 gmake: *** [/home/brucec/tmp/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/bootstrap/ts-stage2-build] Error 2 ./kBuild/env.sh: info: rc=2: gmake -f bootstrap.gmk *** Error code 2 Stop in /usr/ports/devel/kBuild. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 07:26:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEC80106566B for ; Thu, 4 Jun 2009 07:26:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BE63E8FC1B for ; Thu, 4 Jun 2009 07:26:09 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MC7Kz-000PRd-Ay for current@freebsd.org; Thu, 04 Jun 2009 07:26:09 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id C7C221E5C36C for ; Thu, 4 Jun 2009 16:26:08 +0900 (JST) Date: Thu, 04 Jun 2009 16:26:08 +0900 Message-ID: From: Randy Bush To: FreeBSD Current In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Re: yakpf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 07:26:10 -0000 > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff8047c1da > stack pointer = 0x28:0xffffff807a156630 > frame pointer = 0x28:0xffffff807a1566f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1385 (nfcapd) > trap number = 12 > panic: page fault > cpuid = 0 i have not seen this again since a recent svn and total rebuild. this message is an attempt to provoke the $dieties into causing it. randy From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 07:35:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 641F8106564A; Thu, 4 Jun 2009 07:35:02 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id D00CF8FC14; Thu, 4 Jun 2009 07:35:01 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id 54FF75DB5; Thu, 4 Jun 2009 08:34:30 +0100 (BST) Message-Id: <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> From: Doug Rabson To: "Bjoern A. Zeeb" In-Reply-To: <20090603184215.L12292@maildrop.int.zabbadoz.net> Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 08:34:30 +0100 References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: dfr@freebsd.org, freebsd-current@freebsd.org, Michael Moll , Wesley Shields , Dmitry Marakasov , Jamie Gritton Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 07:35:02 -0000 On 3 Jun 2009, at 20:42, Bjoern A. Zeeb wrote: > On Wed, 3 Jun 2009, Wesley Shields wrote: > > Hi, > >>>>> ... > >> [ The panic message and backtrace from ddb is at >> http://people.freebsd.org/~wxs/crash.txt ] >> > ... >> cred->cr_prison is null? It is my understanding that when not jailed >> cred->cr_prison should be &prison0 with the new hierarchical jails. >> The >> fact that it is null is causing prison_priv_check to enter the switch >> statement, leading to the crash. >> >> I'm not sure why cred->cr_prison is null in this case. > > The question here is not if cred->cr_prison can be null but where is > the cred coming from? > > If you look at init_main.c around lines 440 - 457 you'll find prison0 > being further initialized (cpuset) and p_ucred->cr_prison being set to > &prsion0. And a bit further down in l470 td_ucred is initialized from > that. cr_prison should thus always be setup. > > What you are looking at above looks like a crget() with only > cr_ngroups updated. > > [removing a lot more text as I was going on debugging in a very small > window] > > I would start looking at svc_getcred() and blame at least the > AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. > I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. The NFS server is creating a ucred which describes the privileges to be given to the remote user. What is the correct way to do this and where can I read the documentation? From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 09:38:32 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956541065675; Thu, 4 Jun 2009 09:38:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 36EEF8FC26; Thu, 4 Jun 2009 09:38:32 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 578AA1D183; Thu, 4 Jun 2009 11:38:31 +0200 (CEST) Date: Thu, 4 Jun 2009 11:38:31 +0200 From: Ed Schouten To: hackers@FreeBSD.org Message-ID: <20090604093831.GE48776@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OxpcHoRZqvs6WvX3" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@FreeBSD.org Subject: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 09:38:33 -0000 --OxpcHoRZqvs6WvX3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Good news everyone! As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch into SVN. Tuesday I finally had some time to do it, so here's the result: http://svn.freebsd.org/viewvc/base/projects/clangbsd/ You can now build your very own version of FreeBSD with Clang installed as /usr/bin/cc as follows: - Check out the clangbsd branch from our SVN repository: svn co svn://svn.freebsd.org/base/projects/clangbsd - Put this in /etc/src.conf: WITH_CLANG=3D WITH_CLANG_IS_CC=3D NO_WERROR=3D WERROR=3D - Just run `make buildworld' and `make installworld'. You probably don't want to install it on top of your running system. I strongly advise you to create a separate jail to do all your testing with. When using a jail, you probably want to add NO_FSCHG=3D to /etc/src.conf as well to keep `make installworld' happy. So far we've only done testing on amd64 and i386. A lot of ports are probably still broken. Caveat emptor. Beware of dog. Slippery when wet. --=20 Ed Schouten WWW: http://80386.nl/ --OxpcHoRZqvs6WvX3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkonlhcACgkQ52SDGA2eCwUf9gCfbBh/V2IuYpAD/VW4n2Mq8i1W Br0AnA6RAhNwu5AvoiL2tOrf0aP/Mb13 =RIvU -----END PGP SIGNATURE----- --OxpcHoRZqvs6WvX3-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 10:28:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75EA106566C; Thu, 4 Jun 2009 10:28:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7C24E8FC15; Thu, 4 Jun 2009 10:28:33 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 327E546B29; Thu, 4 Jun 2009 06:28:33 -0400 (EDT) Date: Thu, 4 Jun 2009 11:28:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Rabson In-Reply-To: <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> Message-ID: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, Dmitry Marakasov , freebsd-current@freebsd.org, Michael Moll , Wesley Shields , "Bjoern A. Zeeb" , Jamie Gritton Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 10:28:34 -0000 On Thu, 4 Jun 2009, Doug Rabson wrote: >> I would start looking at svc_getcred() and blame at least the AUTH_UNIX >> case; end of rpc/svc_auth.c. This looks like a big NO-NO. I am pretty >> sure I'd also want to audit svc_rpc_gss(), just in case. > > The NFS server is creating a ucred which describes the privileges to be > given to the remote user. What is the correct way to do this and where can I > read the documentation? In practice, all credentials in the system are (often quite indirectly) derived from one of two root credentials, those belong to swapper and init. Typical practice, on initializing a kernel service, is to take an additional reference on the credential that configured the service and derive future credentials from it. I think this is what the old NFS code did, presumably either directly borrowing a proc 0 credential, or from the syscall turning on the NFS server. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 10:51:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A35E10656D8; Thu, 4 Jun 2009 10:51:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C6BDD8FC18; Thu, 4 Jun 2009 10:51:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 68AD546B29; Thu, 4 Jun 2009 06:51:30 -0400 (EDT) Date: Thu, 4 Jun 2009 11:51:30 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Doug Rabson In-Reply-To: Message-ID: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org, Michael Moll , Wesley Shields , "Bjoern A. Zeeb" , Dmitry Marakasov , Jamie Gritton Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 10:51:37 -0000 On Thu, 4 Jun 2009, Robert Watson wrote: >> The NFS server is creating a ucred which describes the privileges to be >> given to the remote user. What is the correct way to do this and where can >> I read the documentation? > > In practice, all credentials in the system are (often quite indirectly) > derived from one of two root credentials, those belong to swapper and init. > Typical practice, on initializing a kernel service, is to take an additional > reference on the credential that configured the service and derive future > credentials from it. I think this is what the old NFS code did, presumably > either directly borrowing a proc 0 credential, or from the syscall turning > on the NFS server. Thinking more formally about this, I guess the question is whether or not the NFS server should really be a "third" credential root. If so, we should provide a more formal mechanism for it to be set up so that it carries the proper extended credential state, such as Jail state, MAC state, audit stat, etc. Notice that similar code for proc0 and proc1 has explicit hooks for that: 452 /* Create credentials. */ 453 p->p_ucred = crget(); 454 p->p_ucred->cr_ngroups = 1; /* group 0 */ 455 p->p_ucred->cr_uidinfo = uifind(0); 456 p->p_ucred->cr_ruidinfo = uifind(0); 457 p->p_ucred->cr_prison = &prison0; 458 #ifdef VIMAGE 459 KASSERT(LIST_FIRST(&vimage_head) != NULL, ("vimage_head empty")); 460 P_TO_VIMAGE(p) = LIST_FIRST(&vimage_head); /* set ucred->cr_vimage */ 461 refcount_acquire(&P_TO_VIMAGE(p)->vi_ucredrefc); 462 LIST_FIRST(&vprocg_head)->nprocs++; 463 #endif 464 #ifdef AUDIT 465 audit_cred_kproc0(p->p_ucred); 466 #endif 467 #ifdef MAC 468 mac_cred_create_swapper(p->p_ucred); 469 #endif And for proc 1: 742 newcred = crget(); 743 PROC_LOCK(initproc); 744 initproc->p_flag |= P_SYSTEM | P_INMEM; 745 oldcred = initproc->p_ucred; 746 crcopy(newcred, oldcred); 747 #ifdef MAC 748 mac_cred_create_init(newcred); 749 #endif 750 #ifdef AUDIT 751 audit_cred_proc1(newcred); 752 #endif 753 initproc->p_ucred = newcred; Possibly we should actually add MAC and audit functions along similar lines, and initialize cr_prison to &prison0 for the NFS creds? On the other hand, if they may be used for network I/O, perhaps cr_prison and the others should be initialized based on the context in which nfsd is started, so that it takes on those security attributes. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 08:28:58 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB24F106566B for ; Thu, 4 Jun 2009 08:28:58 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from camp.isletech.net (camp.isletech.net [64.235.98.67]) by mx1.freebsd.org (Postfix) with ESMTP id C32178FC13 for ; Thu, 4 Jun 2009 08:28:58 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from home.isletech.net ([206.248.171.193]:59744 helo=mac.home.isletech.net) by camp.isletech.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MBCPn-0005l5-J2 for current@FreeBSD.org; Mon, 01 Jun 2009 14:39:19 -0400 Message-Id: From: Daryl Richards To: current@FreeBSD.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) X-Priority: 3 (Normal) Date: Mon, 1 Jun 2009 14:36:01 -0400 References: <1009314136.20090531173617@serebryakov.spb.ru> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Thu, 04 Jun 2009 11:14:00 +0000 Cc: Subject: Re: AOE on FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 08:28:59 -0000 I would be interested in this. On 31-May-09, at 1:22 PM, Stacey Son wrote: > Hi, > > I did some work on the AoE initiator years ago. I also created a > patch for one of the user level targets (see http://people.freebsd.org/~sson/aoe/vblade-freebsd.patch) > . If there is enough interest I could dust off this code and get > in ready to commit. I would estimate about two weeks given what I > have on my plate currently and what I believe needs to be rewritten > in the initiator. Is there a good amount of interest for this? > > Best Regards, > > -stacey. > > > On May 31, 2009, at 8:36 AM, Lev Serebryakov wrote: > >> Hello, Current. >> >> Information about AOE (ATA Over Ethernet) on FreeBSD >> (http://support.coraid.com/support/freebsd/) is outdated. >> Any news? Maybe, native (not third-party) client & target in >> pipeline? >> >> -- >> // Black Lion AKA Lev Serebryakov >> >> _______________________________________________ >> 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-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 Thu Jun 4 11:16:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C41106566B; Thu, 4 Jun 2009 11:16:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9EB8FC0A; Thu, 4 Jun 2009 11:16:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54BGIhY061791; Thu, 4 Jun 2009 07:16:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n54BGIT2039177; Thu, 4 Jun 2009 07:16:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1AB9C7302F; Thu, 4 Jun 2009 07:16:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090604111618.1AB9C7302F@freebsd-current.sentex.ca> Date: Thu, 4 Jun 2009 07:16:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 11:16:21 -0000 TB --- 2009-06-04 09:05:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 09:05:31 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-04 09:05:31 - cleaning the object tree TB --- 2009-06-04 09:06:11 - cvsupping the source tree TB --- 2009-06-04 09:06:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-04 09:06:18 - building world TB --- 2009-06-04 09:06:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 09:06:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 09:06:18 - TARGET=ia64 TB --- 2009-06-04 09:06:18 - TARGET_ARCH=ia64 TB --- 2009-06-04 09:06:18 - TZ=UTC TB --- 2009-06-04 09:06:18 - __MAKE_CONF=/dev/null TB --- 2009-06-04 09:06:18 - cd /src TB --- 2009-06-04 09:06:18 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 09:06:22 UTC 2009 >>> 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 Thu Jun 4 10:56:12 UTC 2009 TB --- 2009-06-04 10:56:12 - generating LINT kernel config TB --- 2009-06-04 10:56:12 - cd /src/sys/ia64/conf TB --- 2009-06-04 10:56:12 - /usr/bin/make -B LINT TB --- 2009-06-04 10:56:12 - building LINT kernel TB --- 2009-06-04 10:56:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 10:56:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 10:56:12 - TARGET=ia64 TB --- 2009-06-04 10:56:12 - TARGET_ARCH=ia64 TB --- 2009-06-04 10:56:12 - TZ=UTC TB --- 2009-06-04 10:56:12 - __MAKE_CONF=/dev/null TB --- 2009-06-04 10:56:12 - cd /src TB --- 2009-06-04 10:56:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 10:56:12 UTC 2009 >>> 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 -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/nfsserver/nfs_srvsubs.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 -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/nfsserver/nfs_syscalls.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 -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/nfs/nfs_nfssvc.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 -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/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 11:16:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 11:16:17 - ERROR: failed to build lint kernel TB --- 2009-06-04 11:16:17 - 6418.38 user 459.55 system 7846.24 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 11:34:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 164D11065672 for ; Thu, 4 Jun 2009 11:34:41 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id C366F8FC19 for ; Thu, 4 Jun 2009 11:34:40 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id A7D5B9CB12F; Thu, 4 Jun 2009 13:18:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdLZsOlsyqUb; Thu, 4 Jun 2009 13:18:06 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id F2FF49CB256; Thu, 4 Jun 2009 13:18:01 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n54BI1r5091561; Thu, 4 Jun 2009 13:18:01 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 4 Jun 2009 13:18:01 +0200 From: Roman Divacky To: Ed Schouten Message-ID: <20090604111801.GA91410@freebsd.org> References: <20090604093831.GE48776@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20090604093831.GE48776@hoeg.nl> User-Agent: Mutt/1.4.2.3i Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 11:34:41 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 04, 2009 at 11:38:31AM +0200, Ed Schouten wrote: > Good news everyone! >=20 > As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch > into SVN. Tuesday I finally had some time to do it, so here's the > result: >=20 > http://svn.freebsd.org/viewvc/base/projects/clangbsd/ >=20 > You can now build your very own version of FreeBSD with Clang installed > as /usr/bin/cc as follows: >=20 > - Check out the clangbsd branch from our SVN repository: > svn co svn://svn.freebsd.org/base/projects/clangbsd >=20 > - Put this in /etc/src.conf: > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > NO_WERROR=3D > WERROR=3D >=20 > - Just run `make buildworld' and `make installworld'. it should be able to compile a bootable kernel on amd64/i386 as well.. so feel free to test that too :) --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkonrWkACgkQLVEj6D3CBEx9CQCePnPDveSWHA7JFJ66Iq3mi7jM 9twAn3/40NADwqPoZGwze+rW392O3D9v =OdiB -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:14:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2FB61065670; Thu, 4 Jun 2009 12:14:05 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 20A8A8FC18; Thu, 4 Jun 2009 12:14:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n54CE3t0099490; Thu, 4 Jun 2009 16:14:03 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Thu, 4 Jun 2009 16:14:03 +0400 (MSD) From: Dmitry Morozovsky To: "Andrew D. Boyd" In-Reply-To: <4A27B51B.8090504@gmail.com> Message-ID: References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> <4A27B51B.8090504@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Thu, 04 Jun 2009 16:14:03 +0400 (MSD) Cc: Alexander Leidinger , Doug Barton , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:14:05 -0000 On Thu, 4 Jun 2009, Andrew D. Boyd wrote: ADB> If you have a look at -F flag case in fsck_msdosfs/main.c it does not ADB> display -F in usage() nor in the man page. Well, man page *do* have a reference to -F option, though not in synopsis. I'm not sure was it intentional or not. ADB> ADB> Perhaps following that might be the way to go? ADB> ADB> Dmitry Morozovsky wrote: ADB> > On Tue, 2 Jun 2009, Doug Barton wrote: ADB> > ADB> > DB> Alexander Leidinger wrote: ADB> > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? ADB> > DB> ADB> > DB> Sounds great, I look forward to reviewing your patch. :) ADB> > ADB> > What do you think about attached one? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:22:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 468141065670; Thu, 4 Jun 2009 12:22:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14E088FC08; Thu, 4 Jun 2009 12:22:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B955846B38; Thu, 4 Jun 2009 08:22:20 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8E0C58A02D; Thu, 4 Jun 2009 08:22:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, rea-fbsd@codelabs.ru Date: Thu, 4 Jun 2009 08:02:25 -0400 User-Agent: KMail/1.9.7 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906040802.27057.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Jun 2009 08:22:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kmacy@freebsd.org, khb@freebsd.org, Marius Strobl , rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:22:22 -0000 On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > > missing something? > > > > It's just not taken into account but AFAICT also dead code. > > Yes, seems like so. John, may be we can eliminate the only reference to > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > unused (grep'ped -CURRENT sources). Yes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:22:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 468141065670; Thu, 4 Jun 2009 12:22:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 14E088FC08; Thu, 4 Jun 2009 12:22:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B955846B38; Thu, 4 Jun 2009 08:22:20 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8E0C58A02D; Thu, 4 Jun 2009 08:22:19 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, rea-fbsd@codelabs.ru Date: Thu, 4 Jun 2009 08:02:25 -0400 User-Agent: KMail/1.9.7 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906040802.27057.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Jun 2009 08:22:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kmacy@freebsd.org, khb@freebsd.org, Marius Strobl , rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:22:22 -0000 On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts > > > of 'struct pcpu' that depend on the KTR_PERCPU being defined and they > > > are never compensated with padding in PCPU_MD_FIELDS for sun4v. Is > > > KTR_PERCPU constant for sun4v (inexisting or defined everytime) or I am > > > missing something? > > > > It's just not taken into account but AFAICT also dead code. > > Yes, seems like so. John, may be we can eliminate the only reference to > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > unused (grep'ped -CURRENT sources). Yes. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:22:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E02C6106564A; Thu, 4 Jun 2009 12:22:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE03D8FC12; Thu, 4 Jun 2009 12:22:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6185A46B06; Thu, 4 Jun 2009 08:22:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 424528A02E; Thu, 4 Jun 2009 08:22:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 4 Jun 2009 08:16:50 -0400 User-Agent: KMail/1.9.7 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906040816.51244.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Jun 2009 08:22:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kmacy@freebsd.org, marius@freebsd.org, Marcel Moolenaar , Robert Watson , FreeBSD Tinderbox , sparc64@freebsd.org, Eygene Ryabinkin , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:22:23 -0000 On Wednesday 03 June 2009 7:14:38 pm Marcel Moolenaar wrote: > > On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > > > Is there a reason not just to use __aligned(64) or the like on the > > first entry of the MD PCPU structure for sun4v to avoid future MI > > pcpu changes from causing similar discomfort for the MD pcpu parts? > > Also, do we know why these alignment/sizing requirements exist for > > struct pcpu on sun4v but not other platforms? If this is about > > packing pcpu structures into properly aligned cache lines, again > > __aligned() might be the right approach to take... > > Adding __aligned(xx) doesn't make it aligned. For example, > malloc(3) only aligns at 16-byte boundaries, so any > user-space structure that has __aligned(x>16) must manually > make sure that this is actually the case by over-allocating > and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel > to get something that's page-aligned... > FYI, Yes, but struct pcpu is a bit special I think. The MD code is responsible for allocating it (and in at least some cases it just allocates a complete page). As long as sun4v allocates struct pcpu on a 64 byte boundary, simply throwing __aligned() in will fix it. Also, since the existing code is just computing explicit padding space, it is already assuming the alignment of struct pcpu. It is simply implementing __aligned() in a harder-to-maintain way. It also doesn't make any sense the way it is doing it now since it is simply adding padding to the end of the structure. Perhaps it is attempting to round up the size of the entire structure? If so, that can easily be fixed in the MD code that allocates the structures by doing 'roundup(sizeof(struct pcpu), N)' when allocating the structure. The comments in pcpu.h seem to imply that it wants a section of the fields in the middle to be aligned to a certain boundary in which case I think the proper solution is to stick an __aligned() on the first such member and then to allocate the structures on a suitable alignment when allocating PCPU structures in the MD code. Presumably it would need the special work when allocating these structures even with the current hard-to-maintain padding hack. Again, that hack is no better than __aligned(), just a much bigger pain to maintain AFAICT. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:22:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E02C6106564A; Thu, 4 Jun 2009 12:22:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE03D8FC12; Thu, 4 Jun 2009 12:22:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6185A46B06; Thu, 4 Jun 2009 08:22:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 424528A02E; Thu, 4 Jun 2009 08:22:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 4 Jun 2009 08:16:50 -0400 User-Agent: KMail/1.9.7 References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> In-Reply-To: <15550775-6B8A-414E-A579-8B518D62E06E@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906040816.51244.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Jun 2009 08:22:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kmacy@freebsd.org, marius@freebsd.org, Marcel Moolenaar , Robert Watson , FreeBSD Tinderbox , sparc64@freebsd.org, Eygene Ryabinkin , current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:22:23 -0000 On Wednesday 03 June 2009 7:14:38 pm Marcel Moolenaar wrote: > > On Jun 3, 2009, at 1:06 PM, Robert Watson wrote: > > > > Is there a reason not just to use __aligned(64) or the like on the > > first entry of the MD PCPU structure for sun4v to avoid future MI > > pcpu changes from causing similar discomfort for the MD pcpu parts? > > Also, do we know why these alignment/sizing requirements exist for > > struct pcpu on sun4v but not other platforms? If this is about > > packing pcpu structures into properly aligned cache lines, again > > __aligned() might be the right approach to take... > > Adding __aligned(xx) doesn't make it aligned. For example, > malloc(3) only aligns at 16-byte boundaries, so any > user-space structure that has __aligned(x>16) must manually > make sure that this is actually the case by over-allocating > and then adjusting the pointer to an x>16 aligned address. > Likewise for the kernel, though it's easier in the kernel > to get something that's page-aligned... > FYI, Yes, but struct pcpu is a bit special I think. The MD code is responsible for allocating it (and in at least some cases it just allocates a complete page). As long as sun4v allocates struct pcpu on a 64 byte boundary, simply throwing __aligned() in will fix it. Also, since the existing code is just computing explicit padding space, it is already assuming the alignment of struct pcpu. It is simply implementing __aligned() in a harder-to-maintain way. It also doesn't make any sense the way it is doing it now since it is simply adding padding to the end of the structure. Perhaps it is attempting to round up the size of the entire structure? If so, that can easily be fixed in the MD code that allocates the structures by doing 'roundup(sizeof(struct pcpu), N)' when allocating the structure. The comments in pcpu.h seem to imply that it wants a section of the fields in the middle to be aligned to a certain boundary in which case I think the proper solution is to stick an __aligned() on the first such member and then to allocate the structures on a suitable alignment when allocating PCPU structures in the MD code. Presumably it would need the special work when allocating these structures even with the current hard-to-maintain padding hack. Again, that hack is no better than __aligned(), just a much bigger pain to maintain AFAICT. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:23:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED03D106566C; Thu, 4 Jun 2009 12:23:42 +0000 (UTC) (envelope-from decado@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id AAA538FC1B; Thu, 4 Jun 2009 12:23:42 +0000 (UTC) (envelope-from decado@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so185297waf.27 for ; Thu, 04 Jun 2009 05:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=duxelCDEUOzvOz9YxeDE7qeMQ0pILfdYG5JFovUjKUE=; b=TW+JNl80k+WmD+6USDzJa/BNlYz4AGbdHaZPMUhidSCFsVtHRUQ90dnT5cx1EeX+Gu d+WUjUI1GtkhPS2fAk8bV4jJxVhUBvC2jHnJCXz82Odk3yB/IkEzjkC5tbZYUDJAZZZu un96FUUSSU/v+jDMrAlSEYRyAWRpzu6XZqi6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=St1JVu+E/lDyKl+lGmp4gBitWcpxaoJ752mhITMU+ugFKzU5IO4kZ+CNadsD4ymGnL bh8qPG6kHYc/K4Zfhq4d2QmSUcQed2koyjmsEvUenF4ket2apEcsjliDbqy9IvctHq7q hCL6eB687VSBPhIOy/00vUL/42UAnORak7PtU= Received: by 10.115.60.1 with SMTP id n1mr3326732wak.113.1244116273522; Thu, 04 Jun 2009 04:51:13 -0700 (PDT) Received: from ?192.168.1.200? (ppp118-208-211-160.lns10.mel6.internode.on.net [118.208.211.160]) by mx.google.com with ESMTPS id n30sm11031651wag.41.2009.06.04.04.51.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 04:51:12 -0700 (PDT) Message-ID: <4A27B51B.8090504@gmail.com> Date: Thu, 04 Jun 2009 21:50:51 +1000 From: "Andrew D. Boyd" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Doug Barton , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:23:43 -0000 If you have a look at -F flag case in fsck_msdosfs/main.c it does not display -F in usage() nor in the man page. Perhaps following that might be the way to go? Dmitry Morozovsky wrote: > On Tue, 2 Jun 2009, Doug Barton wrote: > > DB> Alexander Leidinger wrote: > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? > DB> > DB> Sounds great, I look forward to reviewing your patch. :) > > What do you think about attached one? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Jun 4 12:35:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFA101065670; Thu, 4 Jun 2009 12:35:20 +0000 (UTC) (envelope-from decado@gmail.com) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by mx1.freebsd.org (Postfix) with ESMTP id ACE678FC21; Thu, 4 Jun 2009 12:35:20 +0000 (UTC) (envelope-from decado@gmail.com) Received: by pzk33 with SMTP id 33so702066pzk.3 for ; Thu, 04 Jun 2009 05:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zj0jaXxzAXE40JxhipOrguixLiUJRsUfoXqM2LIZuIU=; b=Vgb9vLK7OxhQXAi9cMUhDsLyABNZlDIzeRNxRv2cmj9wHgzYwO8PeVKOFCKiHrRmuM BH6cQ2pUScaNOxMHKdznkqA3xrwomFMGop5jJlG0+xsyVzrOSh7dZxU9AqHJfUfAb/Pd KMcWk8wkZx1bWmitcXlFY6/ieyDyWZ6o6wN48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=df/GkqGMDrNBDrY51FNUSzTYm5OY7lEcCkh4ejwMGGHWZOZf8HMfIH2xF5hNuWzq2z XOVNwHs1FDrlAmvHdvbAOQ/keo6qOjZufPc6wNK+5/kDI8PnS1hfVrR3fDefxyPvX/Iw Aa9Qll0V01NWq+PjmIqVTcCWYRuAqMScrNvjg= Received: by 10.114.46.6 with SMTP id t6mr2393874wat.25.1244118920258; Thu, 04 Jun 2009 05:35:20 -0700 (PDT) Received: from ?192.168.1.200? (ppp118-208-211-160.lns10.mel6.internode.on.net [118.208.211.160]) by mx.google.com with ESMTPS id k37sm2562725waf.42.2009.06.04.05.35.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 05:35:19 -0700 (PDT) Message-ID: <4A27BF71.4030807@gmail.com> Date: Thu, 04 Jun 2009 22:34:57 +1000 From: "Andrew D. Boyd" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4A23D5A4.6020009@icyb.net.ua> <4A23F4B8.7000002@freebsd.org> <4A240331.1000803@FreeBSD.org> <20090602141231.67987dnz529yuqgw@webmail.leidinger.net> <4A255F8E.70604@FreeBSD.org> <4A27B51B.8090504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , Doug Barton , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: fsck_y_enable: use -C X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:35:21 -0000 Ah my mistake. Probably best to go with what your patch. I'm thinking it is intentional so that the man page matches up with the usage. This patch would be helpful for me thanks for your work. Dmitry Morozovsky wrote: > On Thu, 4 Jun 2009, Andrew D. Boyd wrote: > > ADB> If you have a look at -F flag case in fsck_msdosfs/main.c it does not > ADB> display -F in usage() nor in the man page. > > Well, man page *do* have a reference to -F option, though not in synopsis. > I'm not sure was it intentional or not. > > ADB> > ADB> Perhaps following that might be the way to go? > ADB> > ADB> Dmitry Morozovsky wrote: > ADB> > On Tue, 2 Jun 2009, Doug Barton wrote: > ADB> > > ADB> > DB> Alexander Leidinger wrote: > ADB> > DB> > What about _flags and also adding a NOP for -C in fsck_msdosfs? > ADB> > DB> > ADB> > DB> Sounds great, I look forward to reviewing your patch. :) > ADB> > > ADB> > What do you think about attached one? > From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:36:00 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB5CA1065675; Thu, 4 Jun 2009 12:35:59 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mx2.itu.dk (mx2.itu.dk [130.226.142.29]) by mx1.freebsd.org (Postfix) with ESMTP id 74AD88FC24; Thu, 4 Jun 2009 12:35:59 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by mx2.itu.dk (Postfix) with ESMTP id 657F3F48072; Thu, 4 Jun 2009 14:35:57 +0200 (CEST) Message-Id: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> From: Erik Cederstrand To: Ed Schouten In-Reply-To: <20090604093831.GE48776@hoeg.nl> Content-Type: multipart/signed; boundary=Apple-Mail-338--476216020; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 14:35:56 +0200 References: <20090604093831.GE48776@hoeg.nl> X-Mailer: Apple Mail (2.935.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:36:00 -0000 --Apple-Mail-338--476216020 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Den 04/06/2009 kl. 11.38 skrev Ed Schouten: > You can now build your very own version of FreeBSD with Clang > installed > as /usr/bin/cc as follows: Thanks for your hard work, Ed. This is great news! You might want to mention that a few parts are still GCC-compiled due to bugs in Clang ( see http://wiki.freebsd.org/ BuildingFreeBSDWithClang). Also, it's very encouraging that the ports run you did with Erwin (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005274.html ) compiles over 7000 ports with Clang. I've asked in the Clang list, but I'd like an opinion from FreeBSD folks, too: Clang supports LTO (http://llvm.org/docs/LinkTimeOptimization.html ), which has a potential for performance improvements. It doesn't work on FreeBSD because the linker we have (in binutils) doesn't know about the libLTO that LLVM provides. There's a new linker from GNU called Gold, but as far as I know it's GPLv3 licensed and therefore undesirable at least to have in base. LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html ) but "it doesn't interact correctly with conventional nm/ar/etc" (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html ). There's the ELF toolchain project (elftoolchain.sourceforge.net/) but a BSD-licensed ld hasn't been developed yet. What would be the best way to get LTO to work on FreeBSD? Thanks, Erik --Apple-Mail-338--476216020-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:39:04 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF010106566B; Thu, 4 Jun 2009 12:39:04 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8868D8FC1A; Thu, 4 Jun 2009 12:39:03 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 8E0E69CB102; Thu, 4 Jun 2009 14:38:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79yz6aMeQbnk; Thu, 4 Jun 2009 14:38:02 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 4687E9CB1C3; Thu, 4 Jun 2009 14:38:02 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n54Cc1C7035166; Thu, 4 Jun 2009 14:38:01 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 4 Jun 2009 14:38:01 +0200 From: Roman Divacky To: Erik Cederstrand Message-ID: <20090604123801.GA34971@freebsd.org> References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 12:39:05 -0000 On Thu, Jun 04, 2009 at 02:35:56PM +0200, Erik Cederstrand wrote: > Den 04/06/2009 kl. 11.38 skrev Ed Schouten: > > >You can now build your very own version of FreeBSD with Clang > >installed > >as /usr/bin/cc as follows: > > Thanks for your hard work, Ed. This is great news! > > You might want to mention that a few parts are still GCC-compiled due > to bugs in Clang ( see http://wiki.freebsd.org/ > BuildingFreeBSDWithClang). Also, it's very encouraging that the ports > run you did with Erwin > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005274.html ) > compiles over 7000 ports with Clang. > > I've asked in the Clang list, but I'd like an opinion from FreeBSD > folks, too: Clang supports LTO > (http://llvm.org/docs/LinkTimeOptimization.html ), which has a potential > for performance improvements. It doesn't work on FreeBSD because the > linker we have (in binutils) doesn't know about the libLTO that LLVM > provides. There's a new linker from GNU called Gold, but as far as I know > it's GPLv3 licensed and therefore undesirable at least to have in base. > LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html ) but "it doesn't > interact correctly with conventional nm/ar/etc" > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html ). > There's the ELF toolchain project (elftoolchain.sourceforge.net/) but a > BSD-licensed ld hasn't been developed yet. > > What would be the best way to get LTO to work on FreeBSD? you could use llvm-ld (see the wiki for instructions how to do it). there's also some effort to make gnu ld usable with llvm LTO and I guess the patch could be backported to our ld. I guess From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 12:57:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 876301065674; Thu, 4 Jun 2009 12:57:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 45C648FC15; Thu, 4 Jun 2009 12:57:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54CvJDt076984; Thu, 4 Jun 2009 08:57:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54CvJx2010154; Thu, 4 Jun 2009 08:57:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 750EB7302F; Thu, 4 Jun 2009 08:57:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090604125719.750EB7302F@freebsd-current.sentex.ca> Date: Thu, 4 Jun 2009 08:57:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 12:57:23 -0000 TB --- 2009-06-04 11:16:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 11:16:18 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-06-04 11:16:18 - cleaning the object tree TB --- 2009-06-04 11:16:50 - cvsupping the source tree TB --- 2009-06-04 11:16:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-06-04 11:16:58 - building world TB --- 2009-06-04 11:16:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 11:16:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 11:16:58 - TARGET=powerpc TB --- 2009-06-04 11:16:58 - TARGET_ARCH=powerpc TB --- 2009-06-04 11:16:58 - TZ=UTC TB --- 2009-06-04 11:16:58 - __MAKE_CONF=/dev/null TB --- 2009-06-04 11:16:58 - cd /src TB --- 2009-06-04 11:16:58 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 11:17:00 UTC 2009 >>> 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 Thu Jun 4 12:42:28 UTC 2009 TB --- 2009-06-04 12:42:28 - generating LINT kernel config TB --- 2009-06-04 12:42:28 - cd /src/sys/powerpc/conf TB --- 2009-06-04 12:42:28 - /usr/bin/make -B LINT TB --- 2009-06-04 12:42:28 - building LINT kernel TB --- 2009-06-04 12:42:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 12:42:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 12:42:28 - TARGET=powerpc TB --- 2009-06-04 12:42:28 - TARGET_ARCH=powerpc TB --- 2009-06-04 12:42:28 - TZ=UTC TB --- 2009-06-04 12:42:28 - __MAKE_CONF=/dev/null TB --- 2009-06-04 12:42:28 - cd /src TB --- 2009-06-04 12:42:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 12:42:29 UTC 2009 >>> 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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_srvsubs.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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfsserver/nfs_syscalls.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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nfs/nfs_nfssvc.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 -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 12:57:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 12:57:19 - ERROR: failed to build lint kernel TB --- 2009-06-04 12:57:19 - 4819.95 user 432.15 system 6060.87 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 13:17:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21A651065677; Thu, 4 Jun 2009 13:17:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D50788FC0A; Thu, 4 Jun 2009 13:17:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54DHl3W085324; Thu, 4 Jun 2009 09:17:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54DHlEA029387; Thu, 4 Jun 2009 09:17:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 900E17302F; Thu, 4 Jun 2009 09:17:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090604131747.900E17302F@freebsd-current.sentex.ca> Date: Thu, 4 Jun 2009 09:17:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 13:17:50 -0000 TB --- 2009-06-04 11:40:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 11:40:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-06-04 11:40:30 - cleaning the object tree TB --- 2009-06-04 11:41:00 - cvsupping the source tree TB --- 2009-06-04 11:41:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-06-04 11:41:07 - building world TB --- 2009-06-04 11:41:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 11:41:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 11:41:07 - TARGET=sparc64 TB --- 2009-06-04 11:41:07 - TARGET_ARCH=sparc64 TB --- 2009-06-04 11:41:07 - TZ=UTC TB --- 2009-06-04 11:41:07 - __MAKE_CONF=/dev/null TB --- 2009-06-04 11:41:07 - cd /src TB --- 2009-06-04 11:41:07 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 11:41:08 UTC 2009 >>> 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 Thu Jun 4 13:02:39 UTC 2009 TB --- 2009-06-04 13:02:39 - generating LINT kernel config TB --- 2009-06-04 13:02:39 - cd /src/sys/sparc64/conf TB --- 2009-06-04 13:02:39 - /usr/bin/make -B LINT TB --- 2009-06-04 13:02:39 - building LINT kernel TB --- 2009-06-04 13:02:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 13:02:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 13:02:39 - TARGET=sparc64 TB --- 2009-06-04 13:02:39 - TARGET_ARCH=sparc64 TB --- 2009-06-04 13:02:39 - TZ=UTC TB --- 2009-06-04 13:02:39 - __MAKE_CONF=/dev/null TB --- 2009-06-04 13:02:39 - cd /src TB --- 2009-06-04 13:02:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jun 4 13:02:39 UTC 2009 >>> 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 -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/nfsserver/nfs_srvsubs.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 -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/nfsserver/nfs_syscalls.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 -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/nfs/nfs_nfssvc.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 -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/nlm/nlm_advlock.c /src/sys/nlm/nlm_advlock.c: In function 'nlm_record_lock': /src/sys/nlm/nlm_advlock.c:719: error: 'errno' undeclared (first use in this function) /src/sys/nlm/nlm_advlock.c:719: error: (Each undeclared identifier is reported only once /src/sys/nlm/nlm_advlock.c:719: error: for each function it appears in.) *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 13:17:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 13:17:47 - ERROR: failed to build lint kernel TB --- 2009-06-04 13:17:47 - 4601.70 user 428.40 system 5837.15 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 13:54:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929DC106566C; Thu, 4 Jun 2009 13:54:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 320EC8FC12; Thu, 4 Jun 2009 13:54:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MCDOR-000Esm-RS; Thu, 04 Jun 2009 16:54:07 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n54Ds357055302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 16:54:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n54Ds21P049332; Thu, 4 Jun 2009 16:54:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n54Ds2U4049331; Thu, 4 Jun 2009 16:54:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 4 Jun 2009 16:54:02 +0300 From: Kostik Belousov To: Tim Kientzle Message-ID: <20090604135402.GT1927@deviant.kiev.zoral.com.ua> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nPfW/i9ThgtiBSRK" Content-Disposition: inline In-Reply-To: <4A2750F0.3070106@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MCDOR-000Esm-RS 49e042737cda8595c139efc8a9452abf X-Terabit: YES Cc: Dmitry Marakasov , freebsd-current@freebsd.org Subject: Re: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 13:54:10 -0000 --nPfW/i9ThgtiBSRK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > Dmitry Marakasov wrote: > > > >The problem: on recent current, 32bit bsdtar won't write archives when > >running under 64bit kernel, dying with exit code 140 and `Bad system cal= l' > >message. I've ran into that using i386 tinderbox jail on amd64 host. > >The problem actually happens in libarchive: > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > 484 if (!a->follow_symlinks) > > 485 list_size =3D extattr_list_link(path,=20 > > namespace, NULL, 0); // <-- HERE > > 486 else > > 487 list_size =3D extattr_list_file(path,=20 > > namespace, NULL, 0); > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- >=20 > Yes, it looks like only about half of the extattr calls are > actually connected in the freebsd32 compatibility layer. (see below) > According to SVN history, peter@ reserved these slots back > in December 2003 but no one ever went back and connected > them up. I don't know if there was a reason for not > connecting them or if simply no one remembered to do so. > I would guess the latter; the ones that are connected > were all implemented before mid-2002. >=20 > I don't see any obvious reason these should not just > work. If you're feeling adventurous, you could try > copying the data from /usr/src/kern/syscalls.master > and see what happens. I don't have a 64-bit system > handy here or I would try this myself. >=20 > You can test by going to /usr/src/lib/libarchive/test and > running "make check". That will build and run the libarchive > test suite, which does exercise the extended attribute support. > (Of course, you should revert your change first so that the > extended attribute support is actually compiled.) >=20 > Let me know if you find anything, >=20 > Tim >=20 >=20 > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int=20 > cmd, \ > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link The size_t arguments need translation. Please try the patch below. diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 9301b8d..e8526de 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -2719,6 +2719,73 @@ freebsd32_nmount(struct thread *td, return error; } =20 +int +freebsd32_extattr_set_link(struct thread *td, + struct freebsd32_extattr_set_link_args *uap) +{ + struct extattr_set_link_args ap; + + ap.path =3D uap->path; + ap.attrnamespace =3D uap->attrnamespace; + ap.attrname =3D uap->attrname; + ap.data =3D uap->data; + ap.nbytes =3D uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_set_link(td, &ap)); +} + +int +freebsd32_extattr_get_link(struct thread *td, + struct freebsd32_extattr_get_link_args *uap) +{ + struct extattr_get_link_args ap; + + ap.path =3D uap->path; + ap.attrnamespace =3D uap->attrnamespace; + ap.attrname =3D uap->attrname; + ap.data =3D uap->data; + ap.nbytes =3D uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_get_link(td, &ap)); +} + +int +freebsd32_extattr_list_fd(struct thread *td, + struct freebsd32_extattr_list_fd_args *uap) +{ + struct extattr_list_fd_args ap; + + ap.fd =3D uap->fd; + ap.attrnamespace =3D uap->attrnamespace; + ap.data =3D uap->data; + ap.nbytes =3D uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_fd(td, &ap)); +} + +int +freebsd32_extattr_list_file(struct thread *td, + struct freebsd32_extattr_list_file_args *uap) +{ + struct extattr_list_file_args ap; + + ap.path =3D uap->path; + ap.attrnamespace =3D uap->attrnamespace; + ap.data =3D uap->data; + ap.nbytes =3D uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_file(td, &ap)); +} + +int +freebsd32_extattr_list_link(struct thread *td, + struct freebsd32_extattr_list_link_args *uap) +{ + struct extattr_list_link_args ap; + + ap.path =3D uap->path; + ap.attrnamespace =3D uap->attrnamespace; + ap.data =3D uap->data; + ap.nbytes =3D uap->nbyteslo | ((size_t)uap->nbyteshi << 32); + return (extattr_list_link(td, &ap)); +} + #if 0 int freebsd32_xxx(struct thread *td, struct freebsd32_xxx_args *uap) diff --git a/sys/compat/freebsd32/freebsd32_proto.h b/sys/compat/freebsd32/= freebsd32_proto.h index 5a12c5d..4365322 100644 --- a/sys/compat/freebsd32/freebsd32_proto.h +++ b/sys/compat/freebsd32/freebsd32_proto.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #ifndef _FREEBSD32_SYSPROTO_H_ @@ -317,6 +317,22 @@ struct freebsd32_sendfile_args { char sbytes_l_[PADL_(off_t *)]; off_t * sbytes; char sbytes_r_[PADR_(off_= t *)]; char flags_l_[PADL_(int)]; int flags; char flags_r_[PADR_(int)]; }; +struct freebsd32_extattr_set_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(= const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_= r_[PADR_(int)]; + char attrname_l_[PADL_(const char *)]; const char * attrname; char attrna= me_r_[PADR_(const char *)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[= PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[= PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_get_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(= const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_= r_[PADR_(int)]; + char attrname_l_[PADL_(const char *)]; const char * attrname; char attrna= me_r_[PADR_(const char *)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[= PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[= PADR_(u_int32_t)]; +}; struct freebsd32_sigaction_args { char sig_l_[PADL_(int)]; int sig; char sig_r_[PADR_(int)]; char act_l_[PADL_(struct sigaction32 *)]; struct sigaction32 * act; char = act_r_[PADR_(struct sigaction32 *)]; @@ -341,6 +357,27 @@ struct freebsd32_umtx_lock_args { struct freebsd32_umtx_unlock_args { char umtx_l_[PADL_(struct umtx *)]; struct umtx * umtx; char umtx_r_[PADR= _(struct umtx *)]; }; +struct freebsd32_extattr_list_fd_args { + char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_= r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[= PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[= PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_list_file_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(= const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_= r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[= PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[= PADR_(u_int32_t)]; +}; +struct freebsd32_extattr_list_link_args { + char path_l_[PADL_(const char *)]; const char * path; char path_r_[PADR_(= const char *)]; + char attrnamespace_l_[PADL_(int)]; int attrnamespace; char attrnamespace_= r_[PADR_(int)]; + char data_l_[PADL_(void *)]; void * data; char data_r_[PADR_(void *)]; + char nbyteslo_l_[PADL_(u_int32_t)]; u_int32_t nbyteslo; char nbyteslo_r_[= PADR_(u_int32_t)]; + char nbyteshi_l_[PADL_(u_int32_t)]; u_int32_t nbyteshi; char nbyteshi_r_[= PADR_(u_int32_t)]; +}; struct freebsd32_thr_suspend_args { char timeout_l_[PADL_(const struct timespec32 *)]; const struct timespec3= 2 * timeout; char timeout_r_[PADR_(const struct timespec32 *)]; }; @@ -510,6 +547,8 @@ int freebsd32_aio_waitcomplete(struct thread *, struct = freebsd32_aio_waitcomplet int freebsd32_kevent(struct thread *, struct freebsd32_kevent_args *); int freebsd32_nmount(struct thread *, struct freebsd32_nmount_args *); int freebsd32_sendfile(struct thread *, struct freebsd32_sendfile_args *); +int freebsd32_extattr_set_link(struct thread *, struct freebsd32_extattr_s= et_link_args *); +int freebsd32_extattr_get_link(struct thread *, struct freebsd32_extattr_g= et_link_args *); int freebsd32_sigaction(struct thread *, struct freebsd32_sigaction_args *= ); int freebsd32_sigreturn(struct thread *, struct freebsd32_sigreturn_args *= ); int freebsd32_getcontext(struct thread *, struct freebsd32_getcontext_args= *); @@ -517,6 +556,9 @@ int freebsd32_setcontext(struct thread *, struct freebs= d32_setcontext_args *); int freebsd32_swapcontext(struct thread *, struct freebsd32_swapcontext_ar= gs *); int freebsd32_umtx_lock(struct thread *, struct freebsd32_umtx_lock_args *= ); int freebsd32_umtx_unlock(struct thread *, struct freebsd32_umtx_unlock_ar= gs *); +int freebsd32_extattr_list_fd(struct thread *, struct freebsd32_extattr_li= st_fd_args *); +int freebsd32_extattr_list_file(struct thread *, struct freebsd32_extattr_= list_file_args *); +int freebsd32_extattr_list_link(struct thread *, struct freebsd32_extattr_= list_link_args *); int freebsd32_thr_suspend(struct thread *, struct freebsd32_thr_suspend_ar= gs *); int freebsd32_umtx_op(struct thread *, struct freebsd32_umtx_op_args *); int freebsd32_thr_new(struct thread *, struct freebsd32_thr_new_args *); @@ -739,6 +781,8 @@ int freebsd6_freebsd32_ftruncate(struct thread *, struc= t freebsd6_freebsd32_ftru #define FREEBSD32_SYS_AUE_freebsd32_kevent AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_nmount AUE_NMOUNT #define FREEBSD32_SYS_AUE_freebsd32_sendfile AUE_SENDFILE +#define FREEBSD32_SYS_AUE_freebsd32_extattr_set_link AUE_EXTATTR_SET_LINK +#define FREEBSD32_SYS_AUE_freebsd32_extattr_get_link AUE_EXTATTR_GET_LINK #define FREEBSD32_SYS_AUE_freebsd32_sigaction AUE_SIGACTION #define FREEBSD32_SYS_AUE_freebsd32_sigreturn AUE_SIGRETURN #define FREEBSD32_SYS_AUE_freebsd32_getcontext AUE_NULL @@ -746,6 +790,9 @@ int freebsd6_freebsd32_ftruncate(struct thread *, struc= t freebsd6_freebsd32_ftru #define FREEBSD32_SYS_AUE_freebsd32_swapcontext AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_lock AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_unlock AUE_NULL +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_fd AUE_EXTATTR_LIST_FD +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_file AUE_EXTATTR_LIST_FILE +#define FREEBSD32_SYS_AUE_freebsd32_extattr_list_link AUE_EXTATTR_LIST_LINK #define FREEBSD32_SYS_AUE_freebsd32_thr_suspend AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_umtx_op AUE_NULL #define FREEBSD32_SYS_AUE_freebsd32_thr_new AUE_NULL diff --git a/sys/compat/freebsd32/freebsd32_syscall.h b/sys/compat/freebsd3= 2/freebsd32_syscall.h index 73fc7b3..c320178 100644 --- a/sys/compat/freebsd32/freebsd32_syscall.h +++ b/sys/compat/freebsd32/freebsd32_syscall.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #define FREEBSD32_SYS_syscall 0 @@ -303,6 +303,9 @@ #define FREEBSD32_SYS_statfs 396 #define FREEBSD32_SYS_fstatfs 397 #define FREEBSD32_SYS_fhstatfs 398 +#define FREEBSD32_SYS_freebsd32_extattr_set_link 412 +#define FREEBSD32_SYS_freebsd32_extattr_get_link 413 +#define FREEBSD32_SYS_extattr_delete_link 414 #define FREEBSD32_SYS_freebsd32_sigaction 416 #define FREEBSD32_SYS_freebsd32_sigreturn 417 #define FREEBSD32_SYS_freebsd32_getcontext 421 @@ -315,6 +318,9 @@ #define FREEBSD32_SYS_freebsd32_umtx_lock 434 #define FREEBSD32_SYS_freebsd32_umtx_unlock 435 #define FREEBSD32_SYS_jail_attach 436 +#define FREEBSD32_SYS_freebsd32_extattr_list_fd 437 +#define FREEBSD32_SYS_freebsd32_extattr_list_file 438 +#define FREEBSD32_SYS_freebsd32_extattr_list_link 439 #define FREEBSD32_SYS_freebsd32_thr_suspend 442 #define FREEBSD32_SYS_thr_wake 443 #define FREEBSD32_SYS_kldunloadf 444 diff --git a/sys/compat/freebsd32/freebsd32_syscalls.c b/sys/compat/freebsd= 32/freebsd32_syscalls.c index c31d080..ed0d24f 100644 --- a/sys/compat/freebsd32/freebsd32_syscalls.c +++ b/sys/compat/freebsd32/freebsd32_syscalls.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 const char *freebsd32_syscallnames[] =3D { @@ -419,9 +419,9 @@ const char *freebsd32_syscallnames[] =3D { "#409", /* 409 =3D __mac_get_pid */ "#410", /* 410 =3D __mac_get_link */ "#411", /* 411 =3D __mac_set_link */ - "#412", /* 412 =3D extattr_set_link */ - "#413", /* 413 =3D extattr_get_link */ - "#414", /* 414 =3D extattr_delete_link */ + "freebsd32_extattr_set_link", /* 412 =3D freebsd32_extattr_set_link */ + "freebsd32_extattr_get_link", /* 413 =3D freebsd32_extattr_get_link */ + "extattr_delete_link", /* 414 =3D extattr_delete_link */ "#415", /* 415 =3D __mac_execve */ "freebsd32_sigaction", /* 416 =3D freebsd32_sigaction */ "freebsd32_sigreturn", /* 417 =3D freebsd32_sigreturn */ @@ -444,9 +444,9 @@ const char *freebsd32_syscallnames[] =3D { "freebsd32_umtx_lock", /* 434 =3D freebsd32_umtx_lock */ "freebsd32_umtx_unlock", /* 435 =3D freebsd32_umtx_unlock */ "jail_attach", /* 436 =3D jail_attach */ - "#437", /* 437 =3D extattr_list_fd */ - "#438", /* 438 =3D extattr_list_file */ - "#439", /* 439 =3D extattr_list_link */ + "freebsd32_extattr_list_fd", /* 437 =3D freebsd32_extattr_list_fd */ + "freebsd32_extattr_list_file", /* 438 =3D freebsd32_extattr_list_file */ + "freebsd32_extattr_list_link", /* 439 =3D freebsd32_extattr_list_link */ "#440", /* 440 =3D kse_switchin */ "#441", /* 441 =3D ksem_timedwait */ "freebsd32_thr_suspend", /* 442 =3D freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/freebsd32_sysent.c b/sys/compat/freebsd32= /freebsd32_sysent.c index a44eb58..6e3a787 100644 --- a/sys/compat/freebsd32/freebsd32_sysent.c +++ b/sys/compat/freebsd32/freebsd32_sysent.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #include "opt_compat.h" @@ -450,9 +450,9 @@ struct sysent freebsd32_sysent[] =3D { { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 409 =3D __mac_ge= t_pid */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 410 =3D __mac_ge= t_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 411 =3D __mac_se= t_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 412 =3D extattr_= set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 413 =3D extattr_= get_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 414 =3D extattr_= delete_link */ + { AS(freebsd32_extattr_set_link_args), (sy_call_t *)freebsd32_extattr_set= _link, AUE_EXTATTR_SET_LINK, NULL, 0, 0, 0 }, /* 412 =3D freebsd32_extattr_= set_link */ + { AS(freebsd32_extattr_get_link_args), (sy_call_t *)freebsd32_extattr_get= _link, AUE_EXTATTR_GET_LINK, NULL, 0, 0, 0 }, /* 413 =3D freebsd32_extattr_= get_link */ + { AS(extattr_delete_link_args), (sy_call_t *)extattr_delete_link, AUE_EXT= ATTR_DELETE_LINK, NULL, 0, 0, 0 }, /* 414 =3D extattr_delete_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 415 =3D __mac_ex= ecve */ { AS(freebsd32_sigaction_args), (sy_call_t *)freebsd32_sigaction, AUE_SIG= ACTION, NULL, 0, 0, 0 }, /* 416 =3D freebsd32_sigaction */ { AS(freebsd32_sigreturn_args), (sy_call_t *)freebsd32_sigreturn, AUE_SIG= RETURN, NULL, 0, 0, 0 }, /* 417 =3D freebsd32_sigreturn */ @@ -475,9 +475,9 @@ struct sysent freebsd32_sysent[] =3D { { AS(freebsd32_umtx_lock_args), (sy_call_t *)freebsd32_umtx_lock, AUE_NUL= L, NULL, 0, 0, 0 }, /* 434 =3D freebsd32_umtx_lock */ { AS(freebsd32_umtx_unlock_args), (sy_call_t *)freebsd32_umtx_unlock, AUE= _NULL, NULL, 0, 0, 0 }, /* 435 =3D freebsd32_umtx_unlock */ { AS(jail_attach_args), (sy_call_t *)jail_attach, AUE_NULL, NULL, 0, 0, 0= }, /* 436 =3D jail_attach */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 437 =3D extattr_= list_fd */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 438 =3D extattr_= list_file */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 439 =3D extattr_= list_link */ + { AS(freebsd32_extattr_list_fd_args), (sy_call_t *)freebsd32_extattr_list= _fd, AUE_EXTATTR_LIST_FD, NULL, 0, 0, 0 }, /* 437 =3D freebsd32_extattr_lis= t_fd */ + { AS(freebsd32_extattr_list_file_args), (sy_call_t *)freebsd32_extattr_li= st_file, AUE_EXTATTR_LIST_FILE, NULL, 0, 0, 0 }, /* 438 =3D freebsd32_extat= tr_list_file */ + { AS(freebsd32_extattr_list_link_args), (sy_call_t *)freebsd32_extattr_li= st_link, AUE_EXTATTR_LIST_LINK, NULL, 0, 0, 0 }, /* 439 =3D freebsd32_extat= tr_list_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 440 =3D kse_swit= chin */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 441 =3D ksem_tim= edwait */ { AS(freebsd32_thr_suspend_args), (sy_call_t *)freebsd32_thr_suspend, AUE= _NULL, NULL, 0, 0, 0 }, /* 442 =3D freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/sy= scalls.master index 50e30ad..234f3f1 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -708,9 +708,17 @@ 409 AUE_NULL UNIMPL __mac_get_pid 410 AUE_NULL UNIMPL __mac_get_link 411 AUE_NULL UNIMPL __mac_set_link -412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link -413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link -414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link +412 AUE_EXTATTR_SET_LINK STD { int freebsd32_extattr_set_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +413 AUE_EXTATTR_GET_LINK STD { ssize_t freebsd32_extattr_get_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +414 AUE_EXTATTR_DELETE_LINK NOPROTO { int extattr_delete_link( \ + const char *path, int attrnamespace, \ + const char *attrname); } 415 AUE_NULL UNIMPL __mac_execve 416 AUE_SIGACTION STD { int freebsd32_sigaction(int sig, \ struct sigaction32 *act, \ @@ -741,9 +749,17 @@ 434 AUE_NULL STD { int freebsd32_umtx_lock(struct umtx *umtx); } 435 AUE_NULL STD { int freebsd32_umtx_unlock(struct umtx *umtx); } 436 AUE_NULL NOPROTO { int jail_attach(int jid); } -437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd -438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file -439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link +437 AUE_EXTATTR_LIST_FD STD { ssize_t freebsd32_extattr_list_fd( \ + int fd, int attrnamespace, void *data, \ + u_int32_t nbyteslo, u_int32_t nbyteshi); } +438 AUE_EXTATTR_LIST_FILE STD { ssize_t freebsd32_extattr_list_file( \ + const char *path, int attrnamespace, \ + void *data, u_int32_t nbyteslo, \ + u_int32_t nbyteshi); } +439 AUE_EXTATTR_LIST_LINK STD { ssize_t freebsd32_extattr_list_link( \ + const char *path, int attrnamespace, \ + void *data, u_int32_t nbyteslo, \ + u_int32_t nbyteshi); } 440 AUE_NULL UNIMPL kse_switchin 441 AUE_NULL UNIMPL ksem_timedwait 442 AUE_NULL STD { int freebsd32_thr_suspend( \ --nPfW/i9ThgtiBSRK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkon0foACgkQC3+MBN1Mb4hVhQCfXojwvanA/IIk120Bi6wXn0It LoUAoIhirb246xrZ2lWZB4JNcfV1VtV9 =6J/V -----END PGP SIGNATURE----- --nPfW/i9ThgtiBSRK-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 15:46:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED34106564A; Thu, 4 Jun 2009 15:46:59 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by mx1.freebsd.org (Postfix) with ESMTP id 11D278FC32; Thu, 4 Jun 2009 15:46:58 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by fxm7 with SMTP id 7so455380fxm.43 for ; Thu, 04 Jun 2009 08:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.247.14 with SMTP id z14mr1472259mur.70.1244128777953; Thu, 04 Jun 2009 08:19:37 -0700 (PDT) In-Reply-To: <20090604093831.GE48776@hoeg.nl> References: <20090604093831.GE48776@hoeg.nl> Date: Thu, 4 Jun 2009 17:19:37 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 15:47:00 -0000 Thanks to the team for this! On Thu, Jun 4, 2009 at 11:38, Ed Schouten wrote: > Good news everyone! > > As I mentioned at BSDCan, I was going to import my FreeBSD+Clang branch > into SVN. Tuesday I finally had some time to do it, so here's the > result: > > =A0 =A0 =A0 =A0http://svn.freebsd.org/viewvc/base/projects/clangbsd/ > > You can now build your very own version of FreeBSD with Clang installed > as /usr/bin/cc as follows: > > - Check out the clangbsd branch from our SVN repository: > =A0svn co svn://svn.freebsd.org/base/projects/clangbsd If one has a (recent) head checkout one can also use the faster and lighter svn switch svn://svn.freebsd.org/base/projects/clangbsd in the head working directory (less traffic for the server too). From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 15:54:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97053106564A; Thu, 4 Jun 2009 15:54:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C88028FC29; Thu, 4 Jun 2009 15:54:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALuKJ0qDaFvK/2dsb2JhbADRNIQMBQ X-IronPort-AV: E=Sophos;i="4.41,306,1241409600"; d="scan'208";a="35407895" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Jun 2009 11:54:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 5F26B109C257; Thu, 4 Jun 2009 11:54:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X2fe+j8qnm2; Thu, 4 Jun 2009 11:54:13 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id DE61D109C24A; Thu, 4 Jun 2009 11:54:12 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n54FtSB03365; Thu, 4 Jun 2009 11:55:28 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 4 Jun 2009 11:55:28 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@FreeBSD.org, Dmitry Marakasov , Michael Moll , Wesley Shields , "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, Jamie Gritton Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 15:54:17 -0000 On Thu, 4 Jun 2009, Robert Watson wrote: [good stuff snipped] > > Possibly we should actually add MAC and audit functions along similar lines, > and initialize cr_prison to &prison0 for the NFS creds? On the other hand, > if they may be used for network I/O, perhaps cr_prison and the others should > be initialized based on the context in which nfsd is started, so that it > takes on those security attributes. > The experimental server crdup()'s the credentials that nfsd has, but I have no idea if that's the correct thing to do? (and I've never done ZFS, so I don't know if that fixes the crashes, either). rick From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 16:06:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347411065672 for ; Thu, 4 Jun 2009 16:06:56 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0882F8FC19 for ; Thu, 4 Jun 2009 16:06:55 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n54G6UHx044763; Thu, 4 Jun 2009 09:06:30 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 9m2am8yks75j4wvpewrwbp5g5s; Thu, 04 Jun 2009 09:06:29 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A27F105.4040109@freebsd.org> Date: Thu, 04 Jun 2009 09:06:29 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Erik Cederstrand References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> In-Reply-To: <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , hackers@freebsd.org, current@freebsd.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 16:06:56 -0000 Erik Cederstrand wrote: > > LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but "it > doesn't interact correctly with conventional nm/ar/etc" > (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html). In what way does it not interact correctly? Kai Wang wrote a new libarchive-based ar/nm that's in -CURRENT; we could possibly augment those to work with llvm-ld or modify llvm-ld to work with them, depending on the nature of the disagreement. Tim From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 18:35:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0585C1065748; Thu, 4 Jun 2009 18:35:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4AD588FC08; Thu, 4 Jun 2009 18:35:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADywJ0qDaFvK/2dsb2JhbADQCYQLBQ X-IronPort-AV: E=Sophos;i="4.41,306,1241409600"; d="scan'208";a="35430450" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 04 Jun 2009 14:35:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 807CC109C257; Thu, 4 Jun 2009 14:35:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt-wKmJUmJVY; Thu, 4 Jun 2009 14:35:05 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id F2859109C24A; Thu, 4 Jun 2009 14:35:04 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n54IaKG26764; Thu, 4 Jun 2009 14:36:21 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 4 Jun 2009 14:36:20 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Bjoern A. Zeeb" In-Reply-To: <20090603184215.L12292@maildrop.int.zabbadoz.net> Message-ID: References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@FreeBSD.org, Dmitry Marakasov , Michael Moll , Wesley Shields , freebsd-current@FreeBSD.org, Jamie Gritton Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 18:35:07 -0000 On Wed, 3 Jun 2009, Bjoern A. Zeeb wrote: > > I would start looking at svc_getcred() and blame at least the > AUTH_UNIX case; end of rpc/svc_auth.c. This looks like a big NO-NO. > I am pretty sure I'd also want to audit svc_rpc_gss(), just in case. > Oh, just to clarify. Earlier to-day I mentioned that the experimental server used crdup() of the nfsd's cred. That is only for certain state recovery cases where it needs a credential to play with. Normally it uses whatever the sys/rpc layer has provided it, as above. Again, I have no idea if using crdup() is correct? rick From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 19:07:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E35F1065670; Thu, 4 Jun 2009 19:07:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 12B788FC20; Thu, 4 Jun 2009 19:07:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n54J7axn032580; Thu, 4 Jun 2009 15:07:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54J7aVp024495; Thu, 4 Jun 2009 15:07:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 050767302F; Thu, 4 Jun 2009 15:07:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090604190736.050767302F@freebsd-current.sentex.ca> Date: Thu, 4 Jun 2009 15:07:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:07:43 -0000 TB --- 2009-06-04 17:58:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 17:58:52 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-06-04 17:58:52 - cleaning the object tree TB --- 2009-06-04 17:59:23 - cvsupping the source tree TB --- 2009-06-04 17:59:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-06-04 17:59:31 - building world TB --- 2009-06-04 17:59:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 17:59:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 17:59:31 - TARGET=pc98 TB --- 2009-06-04 17:59:31 - TARGET_ARCH=i386 TB --- 2009-06-04 17:59:31 - TZ=UTC TB --- 2009-06-04 17:59:31 - __MAKE_CONF=/dev/null TB --- 2009-06-04 17:59:31 - cd /src TB --- 2009-06-04 17:59:31 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 17:59:33 UTC 2009 >>> 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 [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -fstack-protector -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c /src/sbin/ifconfig/ifieee80211.c: In function 'iename': /src/sbin/ifconfig/ifieee80211.c:2891: error: 'IEEE80211_ELEMID_CHANSWITCHANN' undeclared (first use in this function) /src/sbin/ifconfig/ifieee80211.c:2891: error: (Each undeclared identifier is reported only once /src/sbin/ifconfig/ifieee80211.c:2891: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 19:07:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 19:07:35 - ERROR: failed to build world TB --- 2009-06-04 19:07:35 - 3154.11 user 326.84 system 4123.12 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 20:01:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626AA1065673; Thu, 4 Jun 2009 20:01:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 04D898FC1C; Thu, 4 Jun 2009 20:01:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n54K1jro060961; Thu, 4 Jun 2009 16:01:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n54K1jAd035073; Thu, 4 Jun 2009 16:01:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EAF4C7302F; Thu, 4 Jun 2009 16:01:44 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090604200144.EAF4C7302F@freebsd-current.sentex.ca> Date: Thu, 4 Jun 2009 16:01:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:01:49 -0000 TB --- 2009-06-04 18:37:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-04 18:37:57 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-06-04 18:37:57 - cleaning the object tree TB --- 2009-06-04 18:38:22 - cvsupping the source tree TB --- 2009-06-04 18:38:22 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-06-04 18:38:35 - building world TB --- 2009-06-04 18:38:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-04 18:38:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-04 18:38:35 - TARGET=ia64 TB --- 2009-06-04 18:38:35 - TARGET_ARCH=ia64 TB --- 2009-06-04 18:38:35 - TZ=UTC TB --- 2009-06-04 18:38:35 - __MAKE_CONF=/dev/null TB --- 2009-06-04 18:38:35 - cd /src TB --- 2009-06-04 18:38:35 - /usr/bin/make -B buildworld >>> World build started on Thu Jun 4 18:38:36 UTC 2009 >>> 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 [...] cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifmedia.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifvlan.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifgre.c cc -O2 -pipe -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wnested-externs -DRESCUE -std=gnu99 -Wno-pointer-sign -c /src/sbin/ifconfig/ifieee80211.c /src/sbin/ifconfig/ifieee80211.c: In function 'iename': /src/sbin/ifconfig/ifieee80211.c:2891: error: 'IEEE80211_ELEMID_CHANSWITCHANN' undeclared (first use in this function) /src/sbin/ifconfig/ifieee80211.c:2891: error: (Each undeclared identifier is reported only once /src/sbin/ifconfig/ifieee80211.c:2891: error: for each function it appears in.) *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-04 20:01:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-04 20:01:44 - ERROR: failed to build world TB --- 2009-06-04 20:01:44 - 4064.43 user 327.82 system 5027.53 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 20:25:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D2E106564A for ; Thu, 4 Jun 2009 20:25:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id A9CBE8FC0C for ; Thu, 4 Jun 2009 20:25:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 02D5941C72F; Thu, 4 Jun 2009 22:25:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id P-Q6jWdXmGal; Thu, 4 Jun 2009 22:25:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 8F89B41C729; Thu, 4 Jun 2009 22:25:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 4F51B4448E6; Thu, 4 Jun 2009 20:24:49 +0000 (UTC) Date: Thu, 4 Jun 2009 20:24:49 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: <20090604201810.K12292@maildrop.int.zabbadoz.net> References: <20090601182012.GA21543@darkthrone.kvedulv.de> <20090603121307.GA15659@hades.panopticon> <20090603152810.GA21014@atarininja.org> <20090603160945.GC21014@atarininja.org> <20090603184215.L12292@maildrop.int.zabbadoz.net> <942C18EE-0453-4568-B835-8379966F0B8A@rabson.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dfr@freebsd.org, freebsd-current@freebsd.org Subject: Re: Kernel panic when accessing ZFS-Filesystem via NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 20:25:07 -0000 On Thu, 4 Jun 2009, Robert Watson wrote: Hi, > Thinking more formally about this, I guess the question is whether or not the > NFS server should really be a "third" credential root. If so, we should I am not sure that would be a good idea or if it will actually be needed. I'd like to avoid adding more cases of this, especially outside init_main.c nfs server to my understanding is in no way special; nfs client would be as it can be used for the root fs. I wonder if the nfs server should use the credentials from the `prison' that triggered things off and that would be serving the data; that would probably also solve a few virtual network stack cases that are still left on my todo list. Unfortunately I'll still need stom time and probably a pencil to inhale the `new' way NFS works. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 21:42:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B011065670; Thu, 4 Jun 2009 21:42:37 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by mx1.freebsd.org (Postfix) with ESMTP id 15BF28FC18; Thu, 4 Jun 2009 21:42:36 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by fxm7 with SMTP id 7so685927fxm.43 for ; Thu, 04 Jun 2009 14:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:mime-version:message-id:content-type :content-transfer-encoding; bh=w1XxrWFfKQt8EEojcG9gvcuDTuWrbfM9Evso/ZwoBfU=; b=fPKI+EhrCpPFI04MYhIZsJpLlH3aRj5xcnArgyXrH4NKGbs5jTwZPWF3sdPNcds7CO v19hqd7rRAHo+oXxAYpRBRzUN40+eAzw/yMQEuK3vdgQiWM4hABQxJTRrUWRFJbiHRGQ s8cMswx4YqcplmlBU/lXcBBzJFcvbVHb+RDKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:mime-version :message-id:content-type:content-transfer-encoding; b=uHmPRyCArabvNb+wZCvSQ1BlpWTBbdGq+AFk5kk4Y2+VmbxHzJBn3Ks3CdiLPzkCix 0Hk/n89UKsJnVzmlpfI7/KhAAziR4yPztIHw6Wqh9UHy55lBp2GpqIQsLFc4URVQEOd+ 4MtVuFCQ+qfAvUcHlZUKjW30z24hzSuBmtMkQ= Received: by 10.86.68.1 with SMTP id q1mr3131689fga.10.1244150448819; Thu, 04 Jun 2009 14:20:48 -0700 (PDT) Received: from dragonmini.dg ([196.34.241.123]) by mx.google.com with ESMTPS id 12sm252077fgg.15.2009.06.04.14.20.34 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 14:20:48 -0700 (PDT) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Thu, 4 Jun 2009 23:21:38 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200906042321.44624.naylor.b.david@gmail.com> Content-Type: multipart/signed; boundary="nextPart4770535.LtA2o8KX1g"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 04 Jun 2009 21:57:48 +0000 Cc: kib@freebsd.org Subject: __getcwd panics [lock held] (r193174, r193186) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 21:42:37 -0000 --nextPart4770535.LtA2o8KX1g Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, A recent change (r193174, r193186) in vfs_cache has been causing __getcwd t= o=20 panic the system. The panic appears to trigger when I try install lang/ezm= 3=20 (with other things also happening). =2D- hand copied --- System call _getcwd returning with the following locks held: shared rw Name Cache (Name Cache) r =3D 0 (0xc0eced7c) locked=20 @ /usr/src/sys/kern/vfs_cache.c:1104 panic: witness_warn =2D-- above reproducible --- cpuid =3D 2 KDB: enter: panic [thread pid 23322 tid 100190 ] Stopped at kdb_enter+0x3a: movl $0, kdb_why db> cont Uptime 20m35s Physical memory: 3055 MB Dumping 271 MB: 256 240 224panic: bufwrite: buffer is not busy??? cpuid =3D 0 KDB: enter: panic [thread pid 25 tid 100055 ] Stopped at kdb_enter+0x3a: movl $0, kdb_why db> cont Uptime: 20m36s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs =2D-- systems hangs here, does nothing else --- =2D-- hard reset --- I reverst the change (and r193175) and the panic 'disappeared'. =20 Willing to test patches. =20 Regards, David --nextPart4770535.LtA2o8KX1g Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkooOugACgkQUaaFgP9pFrKvzQCaAxe+CLCNABQSEzgnBOZTJjWD p/kAn1vEc4RuK9W8Twya9Dv94ce5mgrY =KxKp -----END PGP SIGNATURE----- --nextPart4770535.LtA2o8KX1g-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 4 22:11:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9DC106564A; Thu, 4 Jun 2009 22:11:27 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 245898FC12; Thu, 4 Jun 2009 22:11:27 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n54MC1qR033427; Thu, 4 Jun 2009 18:12:01 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: David Naylor In-Reply-To: <200906042321.44624.naylor.b.david@gmail.com> References: <200906042321.44624.naylor.b.david@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LuskzQxLg+UT4IMVva/F" Organization: MarcusCom, Inc. Date: Thu, 04 Jun 2009 18:11:27 -0400 Message-Id: <1244153487.19104.16.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: __getcwd panics [lock held] (r193174, r193186) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Jun 2009 22:11:27 -0000 --=-LuskzQxLg+UT4IMVva/F Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-06-04 at 23:21 +0200, David Naylor wrote: > Hi, >=20 > A recent change (r193174, r193186) in vfs_cache has been causing __getcwd= to=20 > panic the system. The panic appears to trigger when I try install lang/e= zm3=20 > (with other things also happening). Can you try this patch: http://people.freebsd.org/~marcus/vfs_cache.c.diff Joe >=20 > -- hand copied --- >=20 > System call _getcwd returning with the following locks held: > shared rw Name Cache (Name Cache) r =3D 0 (0xc0eced7c) locked=20 > @ /usr/src/sys/kern/vfs_cache.c:1104 > panic: witness_warn >=20 > --- above reproducible --- >=20 > cpuid =3D 2 > KDB: enter: panic > [thread pid 23322 tid 100190 ] > Stopped at kdb_enter+0x3a: movl $0, kdb_why > db> cont > Uptime 20m35s > Physical memory: 3055 MB > Dumping 271 MB: 256 240 224panic: bufwrite: buffer is not busy??? > cpuid =3D 0 > KDB: enter: panic > [thread pid 25 tid 100055 ] > Stopped at kdb_enter+0x3a: movl $0, kdb_why > db> cont > Uptime: 20m36s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Stopping other CPUs >=20 > --- systems hangs here, does nothing else --- > --- hard reset --- >=20 > I reverst the change (and r193175) and the panic 'disappeared'. =20 >=20 > Willing to test patches. =20 >=20 > Regards, >=20 > David --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-LuskzQxLg+UT4IMVva/F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkooRo4ACgkQb2iPiv4Uz4cVcgCfZdoIvmgO2pyuC5sMDCwFyMnz We8Anj2pVYCEoAbV2gxpkI93iNzcYD3K =Z18v -----END PGP SIGNATURE----- --=-LuskzQxLg+UT4IMVva/F-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 01:53:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7168106566C; Fri, 5 Jun 2009 01:53:26 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 487988FC14; Fri, 5 Jun 2009 01:53:25 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MCOcW-0002BB-V8; Fri, 05 Jun 2009 05:53:25 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id A4D97B860; Fri, 5 Jun 2009 05:53:16 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id D5E81108839; Fri, 5 Jun 2009 05:53:17 +0400 (MSD) Date: Fri, 5 Jun 2009 05:53:17 +0400 From: Dmitry Marakasov To: freebsd-current@FreeBSD.org Message-ID: <20090605015317.GA23952@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-fs@FreeBSD.org Subject: [ZFS] still kmem_too_small on recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 01:53:27 -0000 Hi! Just got a kmem_too_small panic on yesterday's current after writing 30GB disk image via NFS. This is amd64 system, with 8GB mem and those tunables: vm.kmem_size_max="2G" vm.kmem_size="2G" vfs.zfs.arc_max="1G" ZFS is 6x1TB raidz2. I have a coredump of it, so just ask if you need additional details. --- #0 doadump () at pcpu.h:223 #1 0xffffffff8054bec6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xffffffff8054c356 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xffffffff806ed86e in kmem_malloc (map=0xffffff00010000e0, size=131072, flags=2) at /usr/src/sys/vm/vm_kern.c:304 #4 0xffffffff806e5e75 in uma_large_malloc (size=131072, wait=2) at /usr/src/sys/vm/uma_core.c:3001 #5 0xffffffff8053b271 in malloc (size=131072, mtp=0xffffffff80e1a1e0, flags=2) at /usr/src/sys/kern/kern_malloc.c:391 #6 0xffffffff80d90ca6 in vdev_queue_io_to_issue (vq=0xffffff00065bf420, pending_limit=Variable "pending_limit" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:227 #7 0xffffffff80d90e1c in vdev_queue_io_done (zio=0xffffff018e1995a0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c:313 #8 0xffffffff80da2370 in zio_vdev_io_done (zio=0xffffff013bc26870) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:1845 #9 0xffffffff80da0a10 in zio_execute (zio=0xffffff013bc26870) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c:996 #10 0xffffffff80d49f1c in taskq_thread (arg=Variable "arg" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/os/taskq.c:854 #11 0xffffffff80525fad in fork_exit (callout=0xffffffff80d49d48 , arg=0xffffff000188fd80, frame=0xffffff80c516cc90) at /usr/src/sys/kern/kern_fork.c:829 #12 0xffffffff8076d56e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 --- I've monitored kstat.zfs.misc.arcstats.size, top and vmstat during it, and here are the observations: - normal copying process uses ~1GB arc (sysctl) and ~1GB wired (top), which I assume includes arc. - actual disk writes are not continuous, ZFS writes data in >512MB packs. - usually those writes are pretty uniform (a write in ~10 seconds, while thoughput is 50MB/s, array can handle 400MB/s writes), but sometimes the write is either larger, or the disks can't keep up, or both - those moments are visible as much higher CPU load for 3-5 seconds, wired kicks up to 1700 mb and more, and arc decreases to ~800MB. I assume the latter is recently committed VM backpressure, and the former means panic if it rolls over kmem_max. Seems so, as I've just got another panic. Just curious, what uses that much memory in those moments? Here are last contents of ssh consoles: --- kstat.zfs.misc.arcstats.size: 804244704 kstat.zfs.misc.arcstats.size: 804244704 kstat.zfs.misc.arcstats.size: 804244704 --- procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad8 ad10 in sy cs us sy id 0 0 0 1017M 5348M 308 0 0 0 253 0 0 0 12 411 655 0 0 100 0 0 0 1017M 5348M 241 0 0 0 257 0 0 0 18 381 748 0 0 100 0 0 0 1017M 5348M 308 0 0 0 253 0 0 0 16 411 645 0 0 100 --- last pid: 7620; load averages: 1.91, 1.80, 1.42 up 0+00:48:56 05:44:11 83 processes: 1 running, 82 sleeping CPU: 0.2% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.8% idle Mem: 149M Active, 60M Inact, 2317M Wired, 1292K Cache, 821M Buf, 5347M Free Swap: 10G Total, 10G Free --- Will give it another go with 512MB arc and 4GB kmem. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 06:30:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C8A1065670; Fri, 5 Jun 2009 06:30:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3018FC13; Fri, 5 Jun 2009 06:30:01 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Vm+WuY32gQFKLlEXyE+/Q31WPGDthy7bBNNIujOVB9S+qVBFgC003PGibGB6G4CcHCI0v2Z5a4/6fhYBVaFf8LViM1ssbwwUOU2Wh3EWd+Xf9WO9xQwpfU3sxOIpRjAS8JIz9hHTpCuKQ7/BK+J8tXsYJxHinEM/9hR1BqzNdR4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MCSwC-000BEk-2y; Fri, 05 Jun 2009 10:30:00 +0400 Date: Fri, 5 Jun 2009 10:29:56 +0400 From: Eygene Ryabinkin To: John Baldwin Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> <200906040802.27057.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Er1qpsOqk0l6oMce" Content-Disposition: inline In-Reply-To: <200906040802.27057.jhb@freebsd.org> Sender: rea-fbsd@codelabs.ru Cc: kmacy@freebsd.org, Marius Strobl , freebsd-current@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 06:30:03 -0000 --Er1qpsOqk0l6oMce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > Yes, seems like so. John, may be we can eliminate the only reference to > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > unused (grep'ped -CURRENT sources). > > Yes. Fine. Then the attached patch should remove the stuff. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --Er1qpsOqk0l6oMce Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU.patch" Content-Transfer-Encoding: quoted-printable =46rom fdb33fbebb9470529fd7dea56905f0454ac53905 Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Fri, 5 Jun 2009 10:25:52 +0400 Subject: [PATCH] pcpu.h: eliminate dead code with KTR_PERCPU As per words of John Baldwin, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007749.html and as discovered by grep'ping -CURRENT sources, KTR_PERCPU is not used anywhere and there is no intention to support it. Signed-off-by: Eygene Ryabinkin --- sys/sys/pcpu.h | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 98705eb..500657e 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -76,10 +76,6 @@ struct pcpu { cpumask_t pc_other_cpus; /* Mask of all other cpus */ SLIST_ENTRY(pcpu) pc_allcpu; struct lock_list_entry *pc_spinlocks; -#ifdef KTR_PERCPU - int pc_ktr_idx; /* Index into trace table */ - char *pc_ktr_buf; -#endif #ifdef KTR char pc_name[PCPU_NAME_LEN]; /* String name for KTR. */ #endif --=20 1.6.3.1 --Er1qpsOqk0l6oMce-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 06:30:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C8A1065670; Fri, 5 Jun 2009 06:30:02 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3018FC13; Fri, 5 Jun 2009 06:30:01 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Vm+WuY32gQFKLlEXyE+/Q31WPGDthy7bBNNIujOVB9S+qVBFgC003PGibGB6G4CcHCI0v2Z5a4/6fhYBVaFf8LViM1ssbwwUOU2Wh3EWd+Xf9WO9xQwpfU3sxOIpRjAS8JIz9hHTpCuKQ7/BK+J8tXsYJxHinEM/9hR1BqzNdR4=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MCSwC-000BEk-2y; Fri, 05 Jun 2009 10:30:00 +0400 Date: Fri, 5 Jun 2009 10:29:56 +0400 From: Eygene Ryabinkin To: John Baldwin Message-ID: References: <20090602222445.2F6017302F@freebsd-current.sentex.ca> <20090603194453.GA43137@alchemy.franken.de> <200906040802.27057.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Er1qpsOqk0l6oMce" Content-Disposition: inline In-Reply-To: <200906040802.27057.jhb@freebsd.org> Sender: rea-fbsd@codelabs.ru Cc: kmacy@freebsd.org, Marius Strobl , freebsd-current@freebsd.org, rwatson@freebsd.org, FreeBSD Tinderbox , sparc64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 06:30:03 -0000 --Er1qpsOqk0l6oMce Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Thu, Jun 04, 2009 at 08:02:25AM -0400, John Baldwin wrote: > On Wednesday 03 June 2009 11:26:17 pm Eygene Ryabinkin wrote: > > Yes, seems like so. John, may be we can eliminate the only reference to > > KTR_PERCPU from sys/sys/pcpu.h? Both 'struct pcpu' fields seem to be > > unused (grep'ped -CURRENT sources). > > Yes. Fine. Then the attached patch should remove the stuff. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --Er1qpsOqk0l6oMce Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-pcpu.h-eliminate-dead-code-with-KTR_PERCPU.patch" Content-Transfer-Encoding: quoted-printable =46rom fdb33fbebb9470529fd7dea56905f0454ac53905 Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Fri, 5 Jun 2009 10:25:52 +0400 Subject: [PATCH] pcpu.h: eliminate dead code with KTR_PERCPU As per words of John Baldwin, http://lists.freebsd.org/pipermail/freebsd-current/2009-June/007749.html and as discovered by grep'ping -CURRENT sources, KTR_PERCPU is not used anywhere and there is no intention to support it. Signed-off-by: Eygene Ryabinkin --- sys/sys/pcpu.h | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/sys/sys/pcpu.h b/sys/sys/pcpu.h index 98705eb..500657e 100644 --- a/sys/sys/pcpu.h +++ b/sys/sys/pcpu.h @@ -76,10 +76,6 @@ struct pcpu { cpumask_t pc_other_cpus; /* Mask of all other cpus */ SLIST_ENTRY(pcpu) pc_allcpu; struct lock_list_entry *pc_spinlocks; -#ifdef KTR_PERCPU - int pc_ktr_idx; /* Index into trace table */ - char *pc_ktr_buf; -#endif #ifdef KTR char pc_name[PCPU_NAME_LEN]; /* String name for KTR. */ #endif --=20 1.6.3.1 --Er1qpsOqk0l6oMce-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 07:14:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E2CC106564A; Fri, 5 Jun 2009 07:14:20 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id D2B428FC18; Fri, 5 Jun 2009 07:14:19 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55740Wp071766; Fri, 5 Jun 2009 00:04:00 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n5573x5Q071765; Fri, 5 Jun 2009 00:03:59 -0700 (PDT) Date: Fri, 5 Jun 2009 00:03:59 -0700 (PDT) From: Matthew Dillon Message-Id: <200906050703.n5573x5Q071765@apollo.backplane.com> To: Alexander Motin References: <4A254B45.8050800@mavhome.dp.ua> Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 07:14:21 -0000 :Hi. : :After replying to several similar questions about my ATA plans last :time, I have decided to announce things I am working on now together :with Scott Long. : :While learning FreeBSD ATA implementation, I have found, that it has :numerous deep problems, from quite fuzzy APIs to different issues in :device detection and error recovery. Also, as soon as this :infrastructure was written many years ago, it has completely no support :for any kind of command queuing, which is normal for the most of modern :drives and controllers. Fixing all of this require many significant changes. : :Also, you may know, that SAS controllers and expanders allow attaching :SATA devices and port multipliers to them, by transporting ATA commands :... :project of making CAM a system's universal infrastructure for both SCSI :and ATA. This project is not about some kind of SCSI-to-ATA translation, :used by some OS, like OpenBSD. It is about extending CAM, to equally :support both SCSI and ATA worlds natively and integrate them as tight as :possible. : :... :Our code now lives in PERFORCE in scottl-camlock project branch. It is :in early development, but we already have there working CAM driver for :AHCI controller with command queuing and basic NCQ support, simple SATA :bus management code and ATA disk driver. I am able now to boot my system :and work from SATA drive on AHCI controller, using ATA disk driver, :having command queuing and NCQ enabled, read and write disks with SATA :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only :with CAM, without using any part of ATA infrastructure. : :-- :Alexander Motin The biggest issue with AHCI (and ATA) interfacing is that AHCI devices attach either as DISK or ATAPI. A device which attaches as a DISK does not typically support ATAPI commands (though it would be an interesting experiment to see if some did). This means that no matter what you do a SCSI<->ATA translation layer needs to do some significant fake-ups for DISK attachments, similar to what OpenBSD does in their SCSI<->ATA layer. ATA DISK attachments simply do not support enough of the SCSI command set for direct integration into CAM (IMHO). The second biggest issue is that it is really unclear to me how the hell one probes an ATAPI device for NCQ support. The OpenBSD driver only uses AHCI-NCQ for DISK attachments, where the NCQ support is returned in the IDENTIFY command. I'm sure there must be a way to probe an ATAPI device for NCQ support but I don't know what it is. I don't think it is possible to get much cleaner then OpenBSD's AHCI driver (/usr/src/sys/dev/pci/ahci.c in OpenBSD). There is also a DragonFly port of the OpenBSD AHCI driver (/usr/src/sys/dev/disk/ahci in DragonFly) which you may want to look at. You are already familiar with OpenBSD's SCSI<->ATA layer (in /us/src/sys/dev/ata in OpenBSD). The DragonFly port of the OpenBSD driver will be done in about a week, and maybe a bit longer for the port-multiplier additions. It essentially works now. I'm still working on hot-plug support (the OpenBSD driver doesn't have it), some error reporting / SENSE issues, and CAM bus rescan. The DFly port is a closer match to FreeBSD since we use busdma and CAM. There are some API differences but far fewer verses the OpenBSD driver. It sounds like your own AHCI driver is well underway, though. Going with a separate AHCI-only driver and then just using the ATA driver to pick-up non-AHCI ATA ports is probably the correct way to go. That is what we intend to do. It's really amazing how *CLEAN* an AHCI-only driver is without all that old ATA hardware interfaces to deal with. The entire DragonFly driver is only 3700 lines of code. -- A couple of notes on the OpenBSD AHCI driver. OpenBSD only allocates a 24-entry PRDT (DMA chain) table per tag per port. The PRDT table can be up to 65535 entries and should be large enough to at least handle MAXPHYS transfers (56 entries would do the job). Their ATAPI implementation does not appear to do compatibility translations for INQUIRY, READ_6, or WRITE_6 (the DragonFly version does). OpenBSD's port reset code also doesn't work perfectly, something I will be fixing for hot plug support in the DragonFly port over the next week. The OpenBSD driver does not have port multiplier support but adding it to the DFly driver will be pretty easy... I just need some hardware to test it with (it's on the way). Unfortunately the AHCI-1.0 specfication says it cannot be used for high-performance multi-disk I/O because all parallel commands in operation are only allowed to go to a single target at a time. i.e. you can't mix parallel commands to different targets on the same port. That's a serious problem. (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything about that?). It is unclear to me from reading the specification as to whether AHCI-NCQ is supported for SATA ATAPI attachments. If anyone has an answer to that I'm looking for a way to probe the device's max-commands for ATAPI. for DISKs the IDENTIFY command has the necessary feature bits and information. I'm sure the host controller supports it natively but the real question is how to probe the capability on the attached device and whether the device(s) support it. Ultimately the best way to expand-out an AHCI interface is with SCSI pass-through over ATAPI, assuming NCQ can be supported somehow. The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0 spec). It is a bit annoying, actually, I wouldn't have though that Intel would have made such a basic mistake. All they had to do was implement 4 bits in the FIS and the problem would have been solved. Instead they have routing bits in a port register. Sigh. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 07:45:46 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB43D106566C; Fri, 5 Jun 2009 07:45:46 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mx2.itu.dk (mx2.itu.dk [130.226.142.29]) by mx1.freebsd.org (Postfix) with ESMTP id 44D8A8FC16; Fri, 5 Jun 2009 07:45:46 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by mx2.itu.dk (Postfix) with ESMTP id 447C8F48073; Fri, 5 Jun 2009 09:45:45 +0200 (CEST) Message-Id: From: Erik Cederstrand To: Roman Divacky In-Reply-To: <20090604123801.GA34971@freebsd.org> Content-Type: multipart/signed; boundary=Apple-Mail-443--407227785; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 09:45:44 +0200 References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> <20090604123801.GA34971@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ed Schouten , hackers@FreeBSD.org, current@FreeBSD.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 07:45:47 -0000 --Apple-Mail-443--407227785 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Roman Den 04/06/2009 kl. 14.38 skrev Roman Divacky: > > you could use llvm-ld (see the wiki for instructions how to do it). > there's also some > effort to make gnu ld usable with llvm LTO and I guess the patch > could be backported > to our ld. I guess As I understand the reply from Eli Friedman[1] this is not possible without at least some hacking. The LTO work in GNU ld[2] is under GPLv3[3], as is gold[4], which makes backporting patches a sticky issue. Erik [1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html [2] http://gcc.gnu.org/wiki/LinkTimeOptimization [3] http://gcc.gnu.org/svn/gcc/branches/lto/lto-plugin/lto-plugin.c [4] http://sourceware.org/cgi-bin/cvsweb.cgi/src/gold/gold.cc?rev=1.63&content-type=text/x-cvsweb-markup&cvsroot=src --Apple-Mail-443--407227785-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 09:06:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C4941065670; Fri, 5 Jun 2009 09:06:36 +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 C790E8FC0A; Fri, 5 Jun 2009 09:06:35 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n558mrNE090296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Jun 2009 10:48:53 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n558mgx4099829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 10:48:42 +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 n558mgAE015688; Fri, 5 Jun 2009 10:48:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n558mfpY015687; Fri, 5 Jun 2009 10:48:41 +0200 (CEST) (envelope-from ticso) Date: Fri, 5 Jun 2009 10:48:41 +0200 From: Bernd Walter To: Daniel Eischen Message-ID: <20090605084841.GR12403@cicely7.cicely.de> References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <200905301610.45520.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Harald Schmalzbauer , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: USB (internally fixed) card reader questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 05 Jun 2009 09:06:36 -0000 On Sat, May 30, 2009 at 10:25:02AM -0400, Daniel Eischen wrote: > On Sat, 30 May 2009, Daniel Eischen wrote: > > >On Sat, 30 May 2009, Hans Petter Selasky wrote: > > > >>On Saturday 30 May 2009, Daniel Eischen wrote: > >>>On Sat, 30 May 2009, Hans Petter Selasky wrote: > >> > >>>It is not just USB flash cards. I have similar problem with > >>>external USB disk drives. See earlier (unanswered) posting: > >>> > >>> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006964.html > >>> > >>>And usbconfig(8) could be a little more helpful (the commands > >>>could use a description for what they do). > >> > >>I'm not sure who is at fault, USB or hald. It looks to me like hald does > >>not > >>detect that the flash card is plugged in during startup, and does not > >>mount > >>it. > > > >Is hald needed for this? I am not currently running X because > >it doesn't work any longer with my Intel 945GM chipset. > > > >I will try removing hald from the equation. > > Hmm, how about that! Removing hald (and dbus) solved the > problem. I can attach and detach the external drive without > any problems. It is just guessing, but maybe hald keeps the device opened, so GEOM never retastes the drive. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 09:32:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36CC91065673; Fri, 5 Jun 2009 09:32:39 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 252CC8FC1F; Fri, 5 Jun 2009 09:32:37 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id n559AhMi014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 13:10:44 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MCVRj-0000tx-KO; Fri, 05 Jun 2009 13:10:43 +0400 From: Vladimir Grebenschikov To: current Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Fri, 05 Jun 2009 13:10:43 +0400 Message-Id: <1244193043.2310.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: emulation@freebsd.org Subject: recent 8-current panics if load device modules from userspace under vmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:32:40 -0000 Hi intsmb0: port 0x1040-0x104f at device 7.3 on pci0 panic: resource_list_alloc: resource entry is busy If load modules from startup scripts it panics with such message. (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc0557413 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc055764d in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc057d176 in resource_list_alloc (rl=0xc38b2304, bus=0xc38f2c00, child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at /usr/src/sys/kern/subr_bus.c:2836 #4 0xc04d6f47 in pci_alloc_resource (dev=0xc38f2c00, child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at /usr/src/sys/dev/pci/pci.c:3599 #5 0xc057d08c in bus_alloc_resource (dev=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) at bus_if.h:263 #6 0xc0639a3d in intsmb_attach (dev=0xc38f2e00) at bus.h:379 #7 0xc057bdff in device_attach (dev=0xc38f2e00) at device_if.h:178 #8 0xc057cd6c in device_probe_and_attach (dev=0xc38f2e00) at /usr/src/sys/kern/subr_bus.c:2473 #9 0xc04d63e5 in pci_driver_added (dev=0xc38f2c00, driver=0xc4053440) at /usr/src/sys/dev/pci/pci.c:2833 #10 0xc057a1a8 in devclass_driver_added (dc=0xc3840e00, driver=0xc4053440) at bus_if.h:183 #11 0xc057ab49 in devclass_add_driver (dc=0xc3840e00, driver=0xc4053440) at /usr/src/sys/kern/subr_bus.c:942 #12 0xc057b9b9 in driver_module_handler (mod=0xc3bafe40, what=0, arg=0xc40534fc) at /usr/src/sys/kern/subr_bus.c:3952 #13 0xc05480f5 in module_register_init (arg=0xc40534e4) at /usr/src/sys/kern/kern_module.c:124 #14 0xc05407bd in linker_load_module (kldname=Variable "kldname" is not available.) at /usr/src/sys/kern/kern_linker.c:234 #15 0xc0540cdc in kern_kldload (td=0xc3a4caf0, file=0xc3924000 "if_le", fileid=0xc3742c70) at /usr/src/sys/kern/kern_linker.c:1022 #16 0xc0540db4 in kldload (td=0xc3a4caf0, uap=0xc3742cf8) at /usr/src/sys/kern/kern_linker.c:1050 #17 0xc06c9157 in syscall (frame=0xc3742d38) at /usr/src/sys/i386/i386/trap.c:1073 #18 0xc06af7b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #19 0x00000033 in ?? () (kgdb) If I add same modules into loader.conf everything goes as expected. Modules tried: if_le, snd_es137x. It worked before right, for sure. I have vmware-specific script to boot my notebook under vmware time-to-time: $ cat /usr/local/etc/rc.d/011.vmware-setup.sh #!/bin/sh if /usr/local/sbin/vmware-checkvm > /dev/null; then echo "vmware configuration" ln -sf /etc/X11/xorg.conf.vmware /etc/X11/xorg.conf kldstat -q -m if_le || kldload if_le kldstat -q -m snd_es137x || kldload snd_es137x # start in-vm mouse /usr/sbin/moused -p /dev/psm0 -t auto & else echo "native configuration" ln -sf /etc/X11/xorg.conf.vbook /etc/X11/xorg.conf fi -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 11:18:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA038106564A for ; Fri, 5 Jun 2009 11:18:28 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 79BB78FC0C for ; Fri, 5 Jun 2009 11:18:28 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so181405fga.12 for ; Fri, 05 Jun 2009 04:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=v8mJVPAKP7nY3tIma7lSJY4tHIuiFzqNAwh5ZS4O3es=; b=V2M/SvegmJ0ARtKmH0eeVhP7hY53vFZwNl3vdLKEahBUNpsM2G6295L8L4C5sHB/Cp ivaM4s9iAXnLu2+cLeOgSAeODmYiIZeTWN1j0/ACs17gQIW19ZZDgjT6IBEslkRYuPLE SXeQ3jsOaBMskTG1wWtTEkg+rkoxveQ9iCKng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TRmt6tlYS402NcZ6Qii7NYd+uNB11vpFdbUwYUfYn9n6JROa7+wp8bEu5XPE2q5R0/ D8ESMPHWTsftYcrcJ8ECqhCoIrgdKRSfyoEtbxGkijaWZOG/Vlm1cDnOJxbq+ly4oLkD l/HuTpASOww6zT/r0ftGEki/Jmd+1R5dfiuEY= MIME-Version: 1.0 Received: by 10.86.58.1 with SMTP id g1mr3724892fga.54.1244199505967; Fri, 05 Jun 2009 03:58:25 -0700 (PDT) In-Reply-To: <1230326101.16303.1243663430565.JavaMail.apache@mail52.abv.bg> References: <1230326101.16303.1243663430565.JavaMail.apache@mail52.abv.bg> Date: Fri, 5 Jun 2009 12:58:25 +0200 Message-ID: From: Jacques Fourie To: Mario Pavlov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 11:18:29 -0000 > Hi, > I've tried http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz out... > =A0- it compiles fine (except for the iso I had to download manually) > =A0- it panics when I try to load the kernel module, first I tried to loa= d it with X running and the second time I tried to load it without X runnin= g, please find attached the output. > > about my machine: > $ uname -a > FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #7: Thu May 28 01= :24:11 EEST 2009 =A0 =A0 mgp@mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE = =A0amd64 > > and also ports updated from 28th of May > > regards, > mgp > _______________________________________________ > 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= " > The following patch fixes this issue for me. --- semevent-r0drv-freebsd.c.old 2009-06-05 12:48:55.841136475 +0200 +++ semevent-r0drv-freebsd.c 2009-06-05 12:15:08.610705499 +0200 @@ -181,7 +181,7 @@ rc =3D tsleep(pEventInt, /* block id */ fInterruptible ? PZERO | PCATCH : PZERO, "iprtev", - tvtohz(&tv)); + cMillies =3D=3D RT_INDEFINITE_WAIT ? 0 : tvtohz(&tv)); mtx_lock_spin(&pEventInt->Mtx); Regards, Jacques From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 09:25:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C591065672; Fri, 5 Jun 2009 09:25:21 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2F28FC18; Fri, 5 Jun 2009 09:25:20 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ewy8 with SMTP id 8so1822299ewy.43 for ; Fri, 05 Jun 2009 02:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:message-id :content-type:content-transfer-encoding; bh=y934mKSpgRJkBvE+xmTjev/4gnri8CLg7j1hkN4iSZ8=; b=RDZEfW4/vWqFWjELxJJ6oNSUxjUIG6/WJEsfmA8RaRUKtWhPkEyqcQ609/o80cZPRc oSM3lvNgUI4e0FnIV/xzkuOU/PaMks0CbCFXT93hrfZ3VKNvf8MDwQBHZzhECii8X87H 44baVTRJh06H44J69zEOVUyeEMaXOzVaN4EVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:message-id:content-type :content-transfer-encoding; b=HZAtCYxyREB8lfPY21inKZv9z4W5kVarNL9zFLL80IpSZAZY7q3mkPnxMqc2Px8FwC a9VLBGjQyHsReC+GQ6+VsqGuTQ/8VARKWEe78YtyPR4q4uMxuNTwEmR2op1R28ab9nEF OdrXpSTwtOhEqSOKMOv1ZR5JEEV2Bi2M5Fsjk= Received: by 10.216.18.195 with SMTP id l45mr1131990wel.59.1244193919811; Fri, 05 Jun 2009 02:25:19 -0700 (PDT) Received: from dragonmini.dg ([196.34.241.123]) by mx.google.com with ESMTPS id p37sm9295847gvf.27.2009.06.05.02.25.13 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 02:25:18 -0700 (PDT) From: David Naylor Organization: Private To: Joe Marcus Clarke Date: Fri, 5 Jun 2009 11:26:19 +0200 User-Agent: KMail/1.9.10 References: <200906042321.44624.naylor.b.david@gmail.com> <1244153487.19104.16.camel@shumai.marcuscom.com> In-Reply-To: <1244153487.19104.16.camel@shumai.marcuscom.com> MIME-Version: 1.0 Message-Id: <200906051126.22143.naylor.b.david@gmail.com> Content-Type: multipart/signed; boundary="nextPart3336970.3pCnyPnvOr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 05 Jun 2009 11:22:08 +0000 Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: __getcwd panics [lock held] (r193174, r193186) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 09:25:22 -0000 --nextPart3336970.3pCnyPnvOr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 05 June 2009 00:11:27 Joe Marcus Clarke wrote: > On Thu, 2009-06-04 at 23:21 +0200, David Naylor wrote: > > Hi, > > > > A recent change (r193174, r193186) in vfs_cache has been causing __getc= wd > > to panic the system. The panic appears to trigger when I try install > > lang/ezm3 (with other things also happening). > > Can you try this patch: > > http://people.freebsd.org/~marcus/vfs_cache.c.diff Patch works. After an hour system still running (normally triggered at=20 ~20mins). =20 Thanks --nextPart3336970.3pCnyPnvOr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkoo5L4ACgkQUaaFgP9pFrIsXwCgi22zAeFEKb1UW+uhAM8VANuI M8gAn2RPKo37lyMQkIC7QuBd8WVShp/m =PR0H -----END PGP SIGNATURE----- --nextPart3336970.3pCnyPnvOr-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 11:42:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD57F10656C1; Fri, 5 Jun 2009 11:42:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 432118FC13; Fri, 5 Jun 2009 11:42:24 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n55BVNvl031966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 13:31:23 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A290203.3070903@omnilan.de> Date: Fri, 05 Jun 2009 13:31:15 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Stacey Son References: <1009314136.20090531173617@serebryakov.spb.ru> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1057187BD6DB27E280B30724" Cc: lev@freebsd.org, current@freebsd.org Subject: Re: AOE on FreeBSD? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 11:42:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1057187BD6DB27E280B30724 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stacey Son schrieb am 31.05.2009 19:22 (localtime): =2E.. > commit. I would estimate about two weeks given what I have on my=20 > plate currently and what I believe needs to be rewritten in the=20 > initiator. Is there a good amount of interest for this? I'd be very interested too, depending on the transfer rates we can expect= =2E If I need a core2-duo CPU to get 50mByte/sec through a em<->em system=20 it's not very interesting. If I can sturate the GbE Link with a 233MHz=20 GEODE and em, it's _very_ interesting. Any experiences what to expect? Thanks, -Harry --------------enig1057187BD6DB27E280B30724 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.11 (FreeBSD) iEYEARECAAYFAkopAgoACgkQLDqVQ9VXb8ionACfeIDc0OQVoTtXoiRpq3yQ4dG7 qncAoK0yxGhB8bW60wpseCupyFXtvFZv =nyyQ -----END PGP SIGNATURE----- --------------enig1057187BD6DB27E280B30724-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 13:09:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96162106566B for ; Fri, 5 Jun 2009 13:09:42 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 52D0A8FC15 for ; Fri, 5 Jun 2009 13:09:42 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35779 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MCZAj-0001wl-5u for freebsd-current@freebsd.org; Fri, 05 Jun 2009 15:09:27 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 23C19335DA for ; Fri, 5 Jun 2009 15:09:24 +0200 (CEST) Message-Id: <1F0CF2D2-D53D-4C3D-9936-8F429525D89F@exscape.org> From: Thomas Backman To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 15:09:21 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MCZAj-0001wl-5u. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MCZAj-0001wl-5u 4a3db4a7bf358e32072bee33106a9a77 Subject: ZFS send/recv and overwriting of existing mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 13:09:42 -0000 Hey all, I was wondering if there could (should?) be some kind of protection of over-mounting/shadowing (whatever the term is; overriding an existing mount) in ZFS. Take this as an example (from my memory, as the shell history is gone due to the forceful shutdown): zfs create tank/test zfs snapshot tank/root@now zfs send -R tank/root@now | zfs recv -vf tank/test ... bam, you now have two filesystems mounted on /, an empty /dev directory unless you double-mount devfs as well, etc. Reboot, and the same thing happens - it mounts root from /boot/ loader.conf, then rc.conf executes and mounts the tank/test root copy over /, again hiding /dev and making your system non-bootable. The only solution I've found so far is to reboot to livefs and destroy the copy... Ugh. I was just gonna test to see if send -R worked on vanilla sources now (I've had to use a patch previously), which it did, but I didn't expect it to override my root! (Single-user might have worked, now that I think about it; still, that too requires downtime to fix something that shouldn't really happen.) I guess you COULD file this under the "feature, not a bug" section, but in cases like this, I'd say "bug". Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 13:55:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1174106567B; Fri, 5 Jun 2009 13:55:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3C78FC19; Fri, 5 Jun 2009 13:55:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0787946B29; Fri, 5 Jun 2009 09:55:09 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CC6178A040; Fri, 5 Jun 2009 09:55:07 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 5 Jun 2009 09:45:51 -0400 User-Agent: KMail/1.9.7 References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> In-Reply-To: <20090604135402.GT1927@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906050945.52511.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Jun 2009 09:55:07 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , Tim Kientzle , Dmitry Marakasov Subject: Re: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 13:55:10 -0000 On Thursday 04 June 2009 9:54:02 am Kostik Belousov wrote: > On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > > Dmitry Marakasov wrote: > > > > > >The problem: on recent current, 32bit bsdtar won't write archives when > > >running under 64bit kernel, dying with exit code 140 and `Bad system call' > > >message. I've ran into that using i386 tinderbox jail on amd64 host. > > >The problem actually happens in libarchive: > > > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > 484 if (!a->follow_symlinks) > > > 485 list_size = extattr_list_link(path, > > > namespace, NULL, 0); // <-- HERE > > > 486 else > > > 487 list_size = extattr_list_file(path, > > > namespace, NULL, 0); > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > > Yes, it looks like only about half of the extattr calls are > > actually connected in the freebsd32 compatibility layer. (see below) > > According to SVN history, peter@ reserved these slots back > > in December 2003 but no one ever went back and connected > > them up. I don't know if there was a reason for not > > connecting them or if simply no one remembered to do so. > > I would guess the latter; the ones that are connected > > were all implemented before mid-2002. > > > > I don't see any obvious reason these should not just > > work. If you're feeling adventurous, you could try > > copying the data from /usr/src/kern/syscalls.master > > and see what happens. I don't have a 64-bit system > > handy here or I would try this myself. > > > > You can test by going to /usr/src/lib/libarchive/test and > > running "make check". That will build and run the libarchive > > test suite, which does exercise the extended attribute support. > > (Of course, you should revert your change first so that the > > extended attribute support is actually compiled.) > > > > Let me know if you find anything, > > > > Tim > > > > > > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, int > > cmd, \ > > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int fd, \ > > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int fd, \ > > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link > > The size_t arguments need translation. Please try the patch below. Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need this sort of fixup. See 'read' and 'write' which just use the native versions for example. I don't think these calls need any sort of wrapper but the native versions should just work. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 13:55:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07D8D106566B; Fri, 5 Jun 2009 13:55:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CF2F28FC1C; Fri, 5 Jun 2009 13:55:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 842AD46B03; Fri, 5 Jun 2009 09:55:10 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 684B18A066; Fri, 5 Jun 2009 09:55:09 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org, vova@fbsd.ru Date: Fri, 5 Jun 2009 09:55:02 -0400 User-Agent: KMail/1.9.7 References: <1244193043.2310.11.camel@localhost> In-Reply-To: <1244193043.2310.11.camel@localhost> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200906050955.02428.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Jun 2009 09:55:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: emulation@freebsd.org Subject: Re: recent 8-current panics if load device modules from userspace under vmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 13:55:13 -0000 On Friday 05 June 2009 5:10:43 am Vladimir Grebenschikov wrote: > Hi > > intsmb0: port 0x1040-0x104f at device 7.3 on pci0 > panic: resource_list_alloc: resource entry is busy > > If load modules from startup scripts it panics with such message. > > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc0557413 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 > #2 0xc055764d in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:576 > #3 0xc057d176 in resource_list_alloc (rl=0xc38b2304, bus=0xc38f2c00, > child=0xc38f2e00, type=4, rid=0xc3742934, start=0, end=4294967295, > count=1, flags=2) at /usr/src/sys/kern/subr_bus.c:2836 > #4 0xc04d6f47 in pci_alloc_resource (dev=0xc38f2c00, child=0xc38f2e00, > type=4, rid=0xc3742934, start=0, end=4294967295, count=1, flags=2) > at /usr/src/sys/dev/pci/pci.c:3599 > #5 0xc057d08c in bus_alloc_resource (dev=0xc38f2e00, type=4, rid=0xc3742934, > start=0, end=4294967295, count=1, flags=2) at bus_if.h:263 > #6 0xc0639a3d in intsmb_attach (dev=0xc38f2e00) at bus.h:379 > #7 0xc057bdff in device_attach (dev=0xc38f2e00) at device_if.h:178 > #8 0xc057cd6c in device_probe_and_attach (dev=0xc38f2e00) > at /usr/src/sys/kern/subr_bus.c:2473 > #9 0xc04d63e5 in pci_driver_added (dev=0xc38f2c00, driver=0xc4053440) > at /usr/src/sys/dev/pci/pci.c:2833 > #10 0xc057a1a8 in devclass_driver_added (dc=0xc3840e00, driver=0xc4053440) > at bus_if.h:183 > #11 0xc057ab49 in devclass_add_driver (dc=0xc3840e00, driver=0xc4053440) > at /usr/src/sys/kern/subr_bus.c:942 > #12 0xc057b9b9 in driver_module_handler (mod=0xc3bafe40, what=0, > arg=0xc40534fc) at /usr/src/sys/kern/subr_bus.c:3952 > #13 0xc05480f5 in module_register_init (arg=0xc40534e4) > at /usr/src/sys/kern/kern_module.c:124 > #14 0xc05407bd in linker_load_module (kldname=Variable "kldname" is not available.) > at /usr/src/sys/kern/kern_linker.c:234 > #15 0xc0540cdc in kern_kldload (td=0xc3a4caf0, file=0xc3924000 "if_le", > fileid=0xc3742c70) at /usr/src/sys/kern/kern_linker.c:1022 > #16 0xc0540db4 in kldload (td=0xc3a4caf0, uap=0xc3742cf8) > at /usr/src/sys/kern/kern_linker.c:1050 > #17 0xc06c9157 in syscall (frame=0xc3742d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #18 0xc06af7b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #19 0x00000033 in ?? () > (kgdb) > > If I add same modules into loader.conf everything goes as expected. > Modules tried: if_le, snd_es137x. Can you get devinfo -r output for 1) prior to loading the module that causes a panic and 2) when you load the modules from the loader. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 14:02:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE84110656DE for ; Fri, 5 Jun 2009 14:02:11 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 751C88FC1E for ; Fri, 5 Jun 2009 14:02:11 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MCZzo-000393-RJ; Fri, 05 Jun 2009 18:02:12 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 4CF73B866; Fri, 5 Jun 2009 18:02:05 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 4C498108839; Fri, 5 Jun 2009 18:02:05 +0400 (MSD) Date: Fri, 5 Jun 2009 18:02:05 +0400 From: Dmitry Marakasov To: John Baldwin Message-ID: <20090605140205.GB18653@hades.panopticon> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> <200906050945.52511.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <200906050945.52511.jhb@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Kostik Belousov , Tim Kientzle , freebsd-current@freebsd.org Subject: Re: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 14:02:12 -0000 * John Baldwin (jhb@freebsd.org) wrote: > Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need this > sort of fixup. See 'read' and 'write' which just use the native versions for > example. I don't think these calls need any sort of wrapper but the native > versions should just work. I'll try to build a jail to test it in the weekend. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 14:18:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65EB8106566B; Fri, 5 Jun 2009 14:18:12 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id E335B8FC1A; Fri, 5 Jun 2009 14:18:11 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:53893 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MCaEu-0001sa-3f; Fri, 05 Jun 2009 16:17:50 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 096EC122AC9; Fri, 5 Jun 2009 16:17:47 +0200 (CEST) Message-Id: <3AB9BCA0-DCEA-4E64-A01D-8BA9B75C3ECD@exscape.org> From: Thomas Backman To: Kip Macy In-Reply-To: <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 16:17:44 +0200 References: <20090518145614.GF82547@egr.msu.edu> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MCaEu-0001sa-3f. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MCaEu-0001sa-3f d1726a8252c16b192e1f5c4615331e96 Cc: FreeBSD Current Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 14:18:12 -0000 On May 21, 2009, at 08:31 PM, Kip Macy wrote: >> Hey, I (not the OP) am still having trouble with this. The panics >> appear to >> be gone since I set arc_min to 30M and arc_max to 100M, though (2GB >> RAM). >> I get/got them during a full zfs send -R | zfs recv -Fvd of a >> ~3.3GB pool. >> The only modification I've done to the source tree is the >> libzfs_sendrecv >> patch here: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html > > > I'll apply the patch this weekend. > > If I get time I'll also try to reproduce your panic. > > > Thanks, > Kip Two weekends later and still the same deal with send | recv. ;) Just worried that this'll make it into 8.0-RELEASE, that's all. That would be bad. The patch linked above seems to solve the problem for me, anyway. I just tried a fresh build (sources from June 5th at 10AM CEST), without the patch, and I got the same core dump on zfs recv, with a SIGSEGV in strcmp(). (See the linked thread.) Applied the patch, rebuild libzfs, rebooted, and it works again. It seems something along the lines of zfs snapshot -r tank@initial-snapshot zfs send -R tank@initial-snapshot | zfs recv -vFd slave and then zfs snapshot -r tank@testsnap # some other, unrelated snapshot in between may or may not be needed to crash, I'm not sure zfs snapshot -r tank@second-snapshot zfs send -R -I initial-snapshot tank@second-snapshot | zfs recv -Fvd slave causes the core dump. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 14:41:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A65EF106564A; Fri, 5 Jun 2009 14:41:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 07C688FC0C; Fri, 5 Jun 2009 14:40:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MCabH-000JWI-Um; Fri, 05 Jun 2009 17:40:56 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n55EeqpA062888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2009 17:40:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n55EeqaR034602; Fri, 5 Jun 2009 17:40:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n55EeqSY034601; Fri, 5 Jun 2009 17:40:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Jun 2009 17:40:52 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20090605144052.GE1927@deviant.kiev.zoral.com.ua> References: <20090604010719.GC15659@hades.panopticon> <4A2750F0.3070106@freebsd.org> <20090604135402.GT1927@deviant.kiev.zoral.com.ua> <200906050945.52511.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ho6OhzAHcBHHvqkB" Content-Disposition: inline In-Reply-To: <200906050945.52511.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MCabH-000JWI-Um cff0728845bb8f30b7d7a4a51d90f61e X-Terabit: YES Cc: Tim Kientzle , freebsd-current@freebsd.org, Dmitry Marakasov Subject: Re: Missing extattr syscalls on compat32 (was Re: libarchive extattr i386/amd64 syscall issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 14:41:04 -0000 --ho6OhzAHcBHHvqkB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 05, 2009 at 09:45:51AM -0400, John Baldwin wrote: > On Thursday 04 June 2009 9:54:02 am Kostik Belousov wrote: > > On Wed, Jun 03, 2009 at 09:43:28PM -0700, Tim Kientzle wrote: > > > Dmitry Marakasov wrote: > > > > > > > >The problem: on recent current, 32bit bsdtar won't write archives wh= en > > > >running under 64bit kernel, dying with exit code 140 and `Bad system= =20 > call' > > > >message. I've ran into that using i386 tinderbox jail on amd64 host. > > > >The problem actually happens in libarchive: > > > > > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > > > 484 if (!a->follow_symlinks) > > > > 485 list_size =3D extattr_list_link(path,=20 > > > > namespace, NULL, 0); // <-- HERE > > > > 486 else > > > > 487 list_size =3D extattr_list_file(path,=20 > > > > namespace, NULL, 0); > > > >--- lib/libarchive/archive_read_disk_entry_from_file.c --- > > >=20 > > > Yes, it looks like only about half of the extattr calls are > > > actually connected in the freebsd32 compatibility layer. (see below) > > > According to SVN history, peter@ reserved these slots back > > > in December 2003 but no one ever went back and connected > > > them up. I don't know if there was a reason for not > > > connecting them or if simply no one remembered to do so. > > > I would guess the latter; the ones that are connected > > > were all implemented before mid-2002. > > >=20 > > > I don't see any obvious reason these should not just > > > work. If you're feeling adventurous, you could try > > > copying the data from /usr/src/kern/syscalls.master > > > and see what happens. I don't have a 64-bit system > > > handy here or I would try this myself. > > >=20 > > > You can test by going to /usr/src/lib/libarchive/test and > > > running "make check". That will build and run the libarchive > > > test suite, which does exercise the extended attribute support. > > > (Of course, you should revert your change first so that the > > > extended attribute support is actually compiled.) > > >=20 > > > Let me know if you find anything, > > >=20 > > > Tim > > >=20 > > >=20 > > > $ grep extattr /usr/src/sys/compat/freebsd32/syscalls.master > > > 355 AUE_EXTATTRCTL NOPROTO { int extattrctl(const char *path, in= t=20 > > > cmd, \ > > > 356 AUE_EXTATTR_SET_FILE NOPROTO { int extattr_set_file( \ > > > 357 AUE_EXTATTR_GET_FILE NOPROTO { ssize_t extattr_get_file( \ > > > 358 AUE_EXTATTR_DELETE_FILE NOPROTO { int extattr_delete_file( \ > > > 371 AUE_EXTATTR_SET_FD NOPROTO { int extattr_set_fd(int fd, \ > > > 372 AUE_EXTATTR_GET_FD NOPROTO { ssize_t extattr_get_fd(int = fd, \ > > > 373 AUE_EXTATTR_DELETE_FD NOPROTO { int extattr_delete_fd(int f= d, \ > > > 412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link > > > 413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link > > > 414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link > > > 437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd > > > 438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file > > > 439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link > >=20 > > The size_t arguments need translation. Please try the patch below. >=20 > Err, size_t is 32-bit for freebsd32. Only 64-bit types like off_t need t= his=20 > sort of fixup. See 'read' and 'write' which just use the native versions= for=20 > example. I don't think these calls need any sort of wrapper but the nati= ve=20 > versions should just work. Yes, I obvioulsy confused it with off_t. diff --git a/sys/compat/freebsd32/freebsd32_proto.h b/sys/compat/freebsd32/= freebsd32_proto.h index 5a12c5d..587fdc4 100644 --- a/sys/compat/freebsd32/freebsd32_proto.h +++ b/sys/compat/freebsd32/freebsd32_proto.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #ifndef _FREEBSD32_SYSPROTO_H_ diff --git a/sys/compat/freebsd32/freebsd32_syscall.h b/sys/compat/freebsd3= 2/freebsd32_syscall.h index 73fc7b3..43a68b3 100644 --- a/sys/compat/freebsd32/freebsd32_syscall.h +++ b/sys/compat/freebsd32/freebsd32_syscall.h @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #define FREEBSD32_SYS_syscall 0 @@ -303,6 +303,9 @@ #define FREEBSD32_SYS_statfs 396 #define FREEBSD32_SYS_fstatfs 397 #define FREEBSD32_SYS_fhstatfs 398 +#define FREEBSD32_SYS_extattr_set_link 412 +#define FREEBSD32_SYS_extattr_get_link 413 +#define FREEBSD32_SYS_extattr_delete_link 414 #define FREEBSD32_SYS_freebsd32_sigaction 416 #define FREEBSD32_SYS_freebsd32_sigreturn 417 #define FREEBSD32_SYS_freebsd32_getcontext 421 @@ -315,6 +318,9 @@ #define FREEBSD32_SYS_freebsd32_umtx_lock 434 #define FREEBSD32_SYS_freebsd32_umtx_unlock 435 #define FREEBSD32_SYS_jail_attach 436 +#define FREEBSD32_SYS_extattr_list_fd 437 +#define FREEBSD32_SYS_extattr_list_file 438 +#define FREEBSD32_SYS_extattr_list_link 439 #define FREEBSD32_SYS_freebsd32_thr_suspend 442 #define FREEBSD32_SYS_thr_wake 443 #define FREEBSD32_SYS_kldunloadf 444 diff --git a/sys/compat/freebsd32/freebsd32_syscalls.c b/sys/compat/freebsd= 32/freebsd32_syscalls.c index c31d080..a69d907 100644 --- a/sys/compat/freebsd32/freebsd32_syscalls.c +++ b/sys/compat/freebsd32/freebsd32_syscalls.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 const char *freebsd32_syscallnames[] =3D { @@ -419,9 +419,9 @@ const char *freebsd32_syscallnames[] =3D { "#409", /* 409 =3D __mac_get_pid */ "#410", /* 410 =3D __mac_get_link */ "#411", /* 411 =3D __mac_set_link */ - "#412", /* 412 =3D extattr_set_link */ - "#413", /* 413 =3D extattr_get_link */ - "#414", /* 414 =3D extattr_delete_link */ + "extattr_set_link", /* 412 =3D extattr_set_link */ + "extattr_get_link", /* 413 =3D extattr_get_link */ + "extattr_delete_link", /* 414 =3D extattr_delete_link */ "#415", /* 415 =3D __mac_execve */ "freebsd32_sigaction", /* 416 =3D freebsd32_sigaction */ "freebsd32_sigreturn", /* 417 =3D freebsd32_sigreturn */ @@ -444,9 +444,9 @@ const char *freebsd32_syscallnames[] =3D { "freebsd32_umtx_lock", /* 434 =3D freebsd32_umtx_lock */ "freebsd32_umtx_unlock", /* 435 =3D freebsd32_umtx_unlock */ "jail_attach", /* 436 =3D jail_attach */ - "#437", /* 437 =3D extattr_list_fd */ - "#438", /* 438 =3D extattr_list_file */ - "#439", /* 439 =3D extattr_list_link */ + "extattr_list_fd", /* 437 =3D extattr_list_fd */ + "extattr_list_file", /* 438 =3D extattr_list_file */ + "extattr_list_link", /* 439 =3D extattr_list_link */ "#440", /* 440 =3D kse_switchin */ "#441", /* 441 =3D ksem_timedwait */ "freebsd32_thr_suspend", /* 442 =3D freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/freebsd32_sysent.c b/sys/compat/freebsd32= /freebsd32_sysent.c index a44eb58..5d64fca 100644 --- a/sys/compat/freebsd32/freebsd32_sysent.c +++ b/sys/compat/freebsd32/freebsd32_sysent.c @@ -3,7 +3,7 @@ * * DO NOT EDIT-- this file is automatically generated. * $FreeBSD$ - * created from FreeBSD: head/sys/compat/freebsd32/syscalls.master 191673 = 2009-04-29 21:14:15Z jamie=20 + * created from FreeBSD */ =20 #include "opt_compat.h" @@ -450,9 +450,9 @@ struct sysent freebsd32_sysent[] =3D { { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 409 =3D __mac_ge= t_pid */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 410 =3D __mac_ge= t_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 411 =3D __mac_se= t_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 412 =3D extattr_= set_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 413 =3D extattr_= get_link */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 414 =3D extattr_= delete_link */ + { AS(extattr_set_link_args), (sy_call_t *)extattr_set_link, AUE_EXTATTR_S= ET_LINK, NULL, 0, 0, 0 }, /* 412 =3D extattr_set_link */ + { AS(extattr_get_link_args), (sy_call_t *)extattr_get_link, AUE_EXTATTR_G= ET_LINK, NULL, 0, 0, 0 }, /* 413 =3D extattr_get_link */ + { AS(extattr_delete_link_args), (sy_call_t *)extattr_delete_link, AUE_EXT= ATTR_DELETE_LINK, NULL, 0, 0, 0 }, /* 414 =3D extattr_delete_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 415 =3D __mac_ex= ecve */ { AS(freebsd32_sigaction_args), (sy_call_t *)freebsd32_sigaction, AUE_SIG= ACTION, NULL, 0, 0, 0 }, /* 416 =3D freebsd32_sigaction */ { AS(freebsd32_sigreturn_args), (sy_call_t *)freebsd32_sigreturn, AUE_SIG= RETURN, NULL, 0, 0, 0 }, /* 417 =3D freebsd32_sigreturn */ @@ -475,9 +475,9 @@ struct sysent freebsd32_sysent[] =3D { { AS(freebsd32_umtx_lock_args), (sy_call_t *)freebsd32_umtx_lock, AUE_NUL= L, NULL, 0, 0, 0 }, /* 434 =3D freebsd32_umtx_lock */ { AS(freebsd32_umtx_unlock_args), (sy_call_t *)freebsd32_umtx_unlock, AUE= _NULL, NULL, 0, 0, 0 }, /* 435 =3D freebsd32_umtx_unlock */ { AS(jail_attach_args), (sy_call_t *)jail_attach, AUE_NULL, NULL, 0, 0, 0= }, /* 436 =3D jail_attach */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 437 =3D extattr_= list_fd */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 438 =3D extattr_= list_file */ - { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 439 =3D extattr_= list_link */ + { AS(extattr_list_fd_args), (sy_call_t *)extattr_list_fd, AUE_EXTATTR_LIS= T_FD, NULL, 0, 0, 0 }, /* 437 =3D extattr_list_fd */ + { AS(extattr_list_file_args), (sy_call_t *)extattr_list_file, AUE_EXTATTR= _LIST_FILE, NULL, 0, 0, 0 }, /* 438 =3D extattr_list_file */ + { AS(extattr_list_link_args), (sy_call_t *)extattr_list_link, AUE_EXTATTR= _LIST_LINK, NULL, 0, 0, 0 }, /* 439 =3D extattr_list_link */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 440 =3D kse_swit= chin */ { 0, (sy_call_t *)nosys, AUE_NULL, NULL, 0, 0, 0 }, /* 441 =3D ksem_tim= edwait */ { AS(freebsd32_thr_suspend_args), (sy_call_t *)freebsd32_thr_suspend, AUE= _NULL, NULL, 0, 0, 0 }, /* 442 =3D freebsd32_thr_suspend */ diff --git a/sys/compat/freebsd32/syscalls.master b/sys/compat/freebsd32/sy= scalls.master index 50e30ad..7da270b 100644 --- a/sys/compat/freebsd32/syscalls.master +++ b/sys/compat/freebsd32/syscalls.master @@ -708,9 +708,17 @@ 409 AUE_NULL UNIMPL __mac_get_pid 410 AUE_NULL UNIMPL __mac_get_link 411 AUE_NULL UNIMPL __mac_set_link -412 AUE_EXTATTR_SET_LINK UNIMPL extattr_set_link -413 AUE_EXTATTR_GET_LINK UNIMPL extattr_get_link -414 AUE_EXTATTR_DELETE_LINK UNIMPL extattr_delete_link +412 AUE_EXTATTR_SET_LINK NOPROTO { int extattr_set_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + size_t nbytes); } +413 AUE_EXTATTR_GET_LINK NOPROTO { ssize_t extattr_get_link( \ + const char *path, int attrnamespace, \ + const char *attrname, void *data, \ + size_t nbytes); } +414 AUE_EXTATTR_DELETE_LINK NOPROTO { int extattr_delete_link( \ + const char *path, int attrnamespace, \ + const char *attrname); } 415 AUE_NULL UNIMPL __mac_execve 416 AUE_SIGACTION STD { int freebsd32_sigaction(int sig, \ struct sigaction32 *act, \ @@ -741,9 +749,15 @@ 434 AUE_NULL STD { int freebsd32_umtx_lock(struct umtx *umtx); } 435 AUE_NULL STD { int freebsd32_umtx_unlock(struct umtx *umtx); } 436 AUE_NULL NOPROTO { int jail_attach(int jid); } -437 AUE_EXTATTR_LIST_FD UNIMPL extattr_list_fd -438 AUE_EXTATTR_LIST_FILE UNIMPL extattr_list_file -439 AUE_EXTATTR_LIST_LINK UNIMPL extattr_list_link +437 AUE_EXTATTR_LIST_FD NOPROTO { ssize_t extattr_list_fd(int fd, \ + int attrnamespace, void *data, \ + size_t nbytes); } +438 AUE_EXTATTR_LIST_FILE NOPROTO { ssize_t extattr_list_file( \ + const char *path, int attrnamespace, \ + void *data, size_t nbytes); } +439 AUE_EXTATTR_LIST_LINK NOPROTO { ssize_t extattr_list_link( \ + const char *path, int attrnamespace, \ + void *data, size_t nbytes); } 440 AUE_NULL UNIMPL kse_switchin 441 AUE_NULL UNIMPL ksem_timedwait 442 AUE_NULL STD { int freebsd32_thr_suspend( \ --ho6OhzAHcBHHvqkB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkopLnMACgkQC3+MBN1Mb4gC4gCfWmW/mWIMgfojzWfKWFwiegu/ ykIAoLgoTY2XWEyVlcB9Fgt0B1bFu/3o =yw/z -----END PGP SIGNATURE----- --ho6OhzAHcBHHvqkB-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 15:15:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01238106566C for ; Fri, 5 Jun 2009 15:15:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A70278FC19 for ; Fri, 5 Jun 2009 15:15:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABHUKEqDaFvH/2dsb2JhbADRZoQKBQ X-IronPort-AV: E=Sophos;i="4.41,312,1241409600"; d="scan'208";a="35542796" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Jun 2009 11:15:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 78BC31084170; Fri, 5 Jun 2009 11:15:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZwAMCmKgZcp; Fri, 5 Jun 2009 11:15:51 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id A3FB61084141; Fri, 5 Jun 2009 11:15:51 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n55FHAu25550; Fri, 5 Jun 2009 11:17:10 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 5 Jun 2009 11:17:10 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Dmitry Marakasov In-Reply-To: <20090603235227.GB15659@hades.panopticon> Message-ID: References: <4A2504AA.1020406@zedat.fu-berlin.de> <20090603235227.GB15659@hades.panopticon> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org, "O. Hartmann" , Arnar Mar Sig Subject: Re: RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to mount NFS file system after make world X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 15:15:54 -0000 On Thu, 4 Jun 2009, Dmitry Marakasov wrote: > * O. Hartmann (ohartman@zedat.fu-berlin.de) wrote: > > Just my 2 cents: the same behaviour, and while mount -o tcp succeeds, > umounting behaves strangely: if I umount nfs filesystem, umount > process hangs for some time, then exits with `umount: hive: > RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually > umounted immediately after umount is called. This all also breaks > amd severely (however it already haven't been working on current > for a long time for me). > That would be consistent with the problem being udp specific. An NFS server for v2,3 (NFSv4 is a different story) is "stateless" and doesn't know what mounted on it. All the "umount" does is tell the server's mountd daemon it has unmounted, so the server's mountd can maintain a table of mounts that can be queried via "showmount". The -current umount.c always does this via "udp", so it would fail. The only effect is that "showmount" might reply bogus info. It seems that the problem is specific to "udp" and some arches. (I can't reproduce it on i386 and at least one person sees it on amd64.) Maybe people who see the problem can post to the -current list, noting what arch they are using and network config (running virtualized, what net hardware, multiple net interfaces, etc). Hopefully there is some commonality among them? Thanks in advance for any help tracking this down, rick From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 15:42:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96961065677 for ; Fri, 5 Jun 2009 15:42:51 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5B33E8FC41 for ; Fri, 5 Jun 2009 15:42:49 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n55FghWK014539; Fri, 5 Jun 2009 11:42:44 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 05 Jun 2009 11:42:44 -0400 (EDT) Date: Fri, 5 Jun 2009 11:42:43 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: ticso@cicely.de In-Reply-To: <20090605084841.GR12403@cicely7.cicely.de> Message-ID: References: <4A20F485.2030803@omnilan.de> <200905301203.20769.hselasky@c2i.net> <200905301610.45520.hselasky@c2i.net> <20090605084841.GR12403@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Harald Schmalzbauer , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: USB (internally fixed) card reader questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:42:52 -0000 On Fri, 5 Jun 2009, Bernd Walter wrote: > On Sat, May 30, 2009 at 10:25:02AM -0400, Daniel Eischen wrote: >> On Sat, 30 May 2009, Daniel Eischen wrote: >> >>> On Sat, 30 May 2009, Hans Petter Selasky wrote: >>> >>>> On Saturday 30 May 2009, Daniel Eischen wrote: >>>>> On Sat, 30 May 2009, Hans Petter Selasky wrote: >>>> >>>>> It is not just USB flash cards. I have similar problem with >>>>> external USB disk drives. See earlier (unanswered) posting: >>>>> >>>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006964.html >>>>> >>>>> And usbconfig(8) could be a little more helpful (the commands >>>>> could use a description for what they do). >>>> >>>> I'm not sure who is at fault, USB or hald. It looks to me like hald does >>>> not >>>> detect that the flash card is plugged in during startup, and does not >>>> mount >>>> it. >>> >>> Is hald needed for this? I am not currently running X because >>> it doesn't work any longer with my Intel 945GM chipset. >>> >>> I will try removing hald from the equation. >> >> Hmm, how about that! Removing hald (and dbus) solved the >> problem. I can attach and detach the external drive without >> any problems. > > It is just guessing, but maybe hald keeps the device opened, so GEOM > never retastes the drive. I don't know, but I was able to "dd if=/dev/da0 of=/tmp/da0.bb count=1" from a good and bad attachment. When the problem occurs, it seems like the data read by dd is skewed off by 12 bytes. The first 12 bytes are 0, followed by the same data (from byte 0) as the dd from the good attachment. [deischen@rigel ~]$ od -x da0.mbr.noworky 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0000 0000 0000 0000 31fc 8ec0 8ec0 8ed8 0000040 bcd0 7c00 e689 00bf b906 0100 a5f3 fd89 0000060 08b1 abf3 45fe e9f2 8a00 46f6 20bb 0875 ... 0000720 02b1 8f80 00b6 0100 0001 fe06 043f 003f 0000740 0000 3986 0001 0000 0501 fe07 ffff 39c5 0000760 0001 f44f 01ba 0080 ffc1 fea5 ffff 2e14 [deischen@rigel ~]$ od -x da0.mbr.worky 0000000 31fc 8ec0 8ec0 8ed8 bcd0 7c00 e689 00bf 0000020 b906 0100 a5f3 fd89 08b1 abf3 45fe e9f2 0000040 8a00 46f6 20bb 0875 d284 0778 4e80 40bb 0000060 568a 88ba 0056 fae8 5200 c2bb 3107 88d2 ... 0000720 0501 fe07 ffff 39c5 0001 f44f 01ba 0080 0000740 ffc1 fea5 ffff 2e14 01bc 7275 0513 0000 0000760 0000 0000 0000 0000 0000 0000 0000 aa55 There are other side-effects from hald also. Trying to use camcontrol rescan, reset, and disconnecting/reconnecting the drive eventually leads to a hung system necessitating a reboot. Without hald, it seems I can connect/disconnect the drive as many times as I want. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 16:01:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B47106566B; Fri, 5 Jun 2009 16:01:02 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 35CC68FC12; Fri, 5 Jun 2009 16:01:02 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55G11dq075737; Fri, 5 Jun 2009 09:01:01 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n55G10Mi075734; Fri, 5 Jun 2009 09:01:00 -0700 (PDT) Date: Fri, 5 Jun 2009 09:01:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200906051601.n55G10Mi075734@apollo.backplane.com> To: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> Cc: Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 16:01:02 -0000 More on the port multiplier spec. It turns out that the port-multiplier port selector is in the command table, so it is per command-tag. There is confusion in the spec though: section 9.1: In this mode of operation, a communication path is opened between the HBA and a device through the Port Multiplier. Since Port Multipliers are meant to be simple, the burden of making a connection is on the AHCI software, to ensure that multiple commands are not outstanding to different devices behind the Port Multiplier. section 9.1.2: "Since queued commands result in two different operations (command issue, clear of BSY, then data transfer), if commands were sent to different ports, the Port Multiplier may issue FISes back to the HBA in an interleaved manner from different ports. This will break an HBA that only supports command-based switching. Therefore, when executing native command queueing commands, system software must only add commands to the command list that target a single port behind the Port Multiplier, wait for the commands to finish (PxSACT bits all cleared), then add commands for a different port. Additionally, the tags used must match the command slot entries." -- It's unclear to me what this means. Can we use NCQ to queue multiple commands to multiple ports behind a single port multiplier in parallel or can't we? It's very confusing. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 16:34:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4A521065672; Fri, 5 Jun 2009 16:34:20 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7CD8D8FC1E; Fri, 5 Jun 2009 16:34:20 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 05 Jun 2009 12:23:55 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.10.5-GA) with ESMTP id KXJ65074; Fri, 5 Jun 2009 12:23:54 -0400 (EDT) X-Auth-ID: gcorcoran Received: from 216-164-180-100.c3-0.tlg-ubr8.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([216.164.180.100]) by smtp01.lnh.mail.rcn.net with ESMTP; 05 Jun 2009 12:23:54 -0400 Message-ID: <4A294AD1.6040809@rcn.com> Date: Fri, 05 Jun 2009 12:41:53 -0400 From: Gary Corcoran User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> In-Reply-To: <200906051601.n55G10Mi075734@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 16:34:21 -0000 Matthew Dillon wrote: > More on the port multiplier spec. It turns out that the port-multiplier > port selector is in the command table, so it is per command-tag. There > is confusion in the spec though: > > section 9.1: > > In this mode of operation, a communication path is opened between the > HBA and a device through the Port Multiplier. Since Port Multipliers are > meant to be simple, the burden of making a connection is on the AHCI > software, to ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier. > > section 9.1.2: > > "Since queued commands result in two different operations (command issue, > clear of BSY, then data transfer), if commands were sent to different > ports, the Port Multiplier may issue FISes back to the HBA in > an interleaved manner from different ports. This will break an HBA that > only supports command-based switching. Therefore, when executing native > command queueing commands, system software must only add commands > to the command list that target a single port behind the Port Multiplier, > wait for the commands to finish (PxSACT bits all cleared), then add > commands for a different port. Additionally, the tags used > must match the command slot entries." > > -- > > It's unclear to me what this means. Can we use NCQ to queue multiple > commands to multiple ports behind a single port multiplier in parallel > or can't we? It's very confusing. As I read the above, this: > ensure that multiple commands are not outstanding to > different devices behind the Port Multiplier combined with this: > system software must only add commands > to the command list that target a *single port* behind the Port Multiplier, > *wait for the commands to finish* suggests strongly that you many not send multiple commands out to a single port multiplier. However, I agree that it's not crystal clear, and may not be what was intended. Gary From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 17:05:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD69A1065673; Fri, 5 Jun 2009 17:05:43 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1DEB48FC26; Fri, 5 Jun 2009 17:05:42 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245042541; Fri, 05 Jun 2009 20:05:39 +0300 Message-ID: <4A29505E.6070902@FreeBSD.org> Date: Fri, 05 Jun 2009 20:05:34 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Gary Corcoran References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> <4A294AD1.6040809@rcn.com> In-Reply-To: <4A294AD1.6040809@rcn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 17:05:44 -0000 Gary Corcoran wrote: > suggests strongly that you many not send multiple commands out to a single > port multiplier. However, I agree that it's not crystal clear, and may not > be what was intended. AHCI rev. 1.3: 9.3 FIS-based Switching FIS-based switching requires the HBA to keep track of additional device specific context within each HBA port. The HBA must be able to issue commands to a device while there are still commands outstanding to other devices that are connected to the same host port through the Port Multiplier. The HBA must be able to switch DMA context on the fly; e.g. a Data FIS is received from target X, followed by a Data FIS from target X+1. 9.3.1.1.1 Enable When FIS-based switching is enabled, the hardware shall maintain a distinct BSY/DRQ bit for up to 16 devices. These bits are distinguished in the state machine as the pBsy and pDrq arrays. Hardware shall fetch commands in such a way as to try to ensure commands are issued to all devices that have BSY/DRQ cleared to ‘0’ and have commands in the command list. Instances of the BSY/DRQ bits are updated based on the Port Multiplier port field in Device to Host FISes. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 17:28:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E6A2106566B; Fri, 5 Jun 2009 17:28:16 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 447A98FC0C; Fri, 5 Jun 2009 17:28:16 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55HSFpa076645; Fri, 5 Jun 2009 10:28:15 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n55HSFf0076644; Fri, 5 Jun 2009 10:28:15 -0700 (PDT) Date: Fri, 5 Jun 2009 10:28:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200906051728.n55HSFf0076644@apollo.backplane.com> To: Alexander Motin References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A294DC3.5010008@mavhome.dp.ua> Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 17:28:16 -0000 :Latest AHCI specifications define feature named FIS Based Switching. It :allows controller independently track state of every device beyond port :multiplier. It should be quite easy to use it, but actually none of my :controllers have that capability. Damn. The FBSS capability bit is not set on my (AMD) MCP77 based AHCI SATA controller. That sucks. ahci0: ... ahci0: AHCI 1.2 capabilities 0xe3229f05, 6 port Do you know of any host controllers which support FBS ? Any of the Intel parts or machines per-chance? :As I have said, without controller FIS Based Switching capability it is :impossible. FBS defines separate memory areas for controller, to track :there state of each drive behind PM. Without it, only one drive can be :active at a time, as controller will not be able to track when each :drive is able to receive next command.. Now it makes sense... the 1.0 spec only had one RFIS per port. With only one RFIS area per port it is impossible to track multiple ports behind the PM simultaniously. The 1.3 specification (along with FBSS being set) has 16 RFIS areas per port, plus BSY bits for each, thus fixing the problem. This is really annoying. It effectively serializes access to multiple disks behind a port multiplier on non-FBSS controllers. That makes non-FBSS port-multiplied disk enclosures almost worthless from a performance standpoint. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 17:33:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DAC4106564A for ; Fri, 5 Jun 2009 17:33:01 +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 BB3888FC0C for ; Fri, 5 Jun 2009 17:33:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n55HWsYH006880; Fri, 5 Jun 2009 11:32:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A2956C6.5070902@samsco.org> Date: Fri, 05 Jun 2009 11:32:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 17:33:01 -0000 Matthew Dillon wrote: > :Hi. > : > :After replying to several similar questions about my ATA plans last > :time, I have decided to announce things I am working on now together > :with Scott Long. > : > :While learning FreeBSD ATA implementation, I have found, that it has > :numerous deep problems, from quite fuzzy APIs to different issues in > :device detection and error recovery. Also, as soon as this > :infrastructure was written many years ago, it has completely no support > :for any kind of command queuing, which is normal for the most of modern > :drives and controllers. Fixing all of this require many significant changes. > : > :Also, you may know, that SAS controllers and expanders allow attaching > :SATA devices and port multipliers to them, by transporting ATA commands > :... > :project of making CAM a system's universal infrastructure for both SCSI > :and ATA. This project is not about some kind of SCSI-to-ATA translation, > :used by some OS, like OpenBSD. It is about extending CAM, to equally > :support both SCSI and ATA worlds natively and integrate them as tight as > :possible. > : > :... > :Our code now lives in PERFORCE in scottl-camlock project branch. It is > :in early development, but we already have there working CAM driver for > :AHCI controller with command queuing and basic NCQ support, simple SATA > :bus management code and ATA disk driver. I am able now to boot my system > :and work from SATA drive on AHCI controller, using ATA disk driver, > :having command queuing and NCQ enabled, read and write disks with SATA > :ATAPI DVD-RW drive, using native SCSI CD driver. And all of that only > :with CAM, without using any part of ATA infrastructure. > : > :-- > :Alexander Motin > > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). CAM is being expanded to be a framework for scheduling, recovery, and topology management, agnostic to the transport and protocol being used. SPI and SCSI are being separated into transport and protocol modules, and Alexander has been amazing and kind enough to start a SATA transport and ATA protocol module. Unlike Linux, OpenBSD, or anything else out there, this is not a tacked-on library for speaking SCSI/SPI at the top level and then translating it to something else at a lower level. This is about speaking native SBP/RBP/ATA at the periph level and native SPI/PATA/SATA/FCAL/SMP/USB at the transport level. So, before you continue to cast ignorant doubts on our approach and hawk your incomplete wares, please at least look at what is being done on our end, and make an attempt to ask some reasonable questions. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 18:59:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B8C24106566B; Fri, 5 Jun 2009 18:59:13 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@freebsd.org Date: Fri, 5 Jun 2009 14:59:03 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200906051459.05242.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: [HEADSUP] ACPICA 20090521 imported on head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 18:59:18 -0000 I just committed ACPICA 20090521 on head. If you experience any regression after the commit, please let me know. Note it is little different from my usual patchsets, i.e., it does not include any enhancements. When everything is settled, I am going to commit the remaining patches as well. Cheers, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 19:17:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A70DC106566C; Fri, 5 Jun 2009 19:17:39 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1258FC1D; Fri, 5 Jun 2009 19:17:39 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55JHcHQ077307; Fri, 5 Jun 2009 12:17:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n55JHcLO077306; Fri, 5 Jun 2009 12:17:38 -0700 (PDT) Date: Fri, 5 Jun 2009 12:17:38 -0700 (PDT) From: Matthew Dillon Message-Id: <200906051917.n55JHcLO077306@apollo.backplane.com> To: Scott Long References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 19:17:40 -0000 :CAM is being expanded to be a framework for scheduling, recovery, and :topology management, agnostic to the transport and protocol being used. :SPI and SCSI are being separated into transport and protocol modules, :and Alexander has been amazing and kind enough to start a SATA transport :and ATA protocol module. Unlike Linux, OpenBSD, or anything else out :there, this is not a tacked-on library for speaking SCSI/SPI at the top :level and then translating it to something else at a lower level. This :is about speaking native SBP/RBP/ATA at the periph level and native :SPI/PATA/SATA/FCAL/SMP/USB at the transport level. : :So, before you continue to cast ignorant doubts on our approach and hawk :your incomplete wares, please at least look at what is being done on our :end, and make an attempt to ask some reasonable questions. : :Scott Huh. Get up on the wrong side of the bed, Scott? Just remember who started making the shit comments this time. I have no interest with what FreeBSD is doing with CAM. My only interest vis-a-vie this thread are the AHCI driver efforts by the various BSDs, including ours. In particular, my interest is in NCQ, hot-plug support, and port multiplier support, as these three items can put SATA/AHCI on-par with dedicated SCSI controllers (at least once AHCI hardware revs past the original spec). It is something very important to all Open-Source OS projects as it consolidates the storage device driver spec and removes a huge thorn in the sides of all the projects with regards to the forward-support of new hardware. -- IMHO the only SCSI command non-SCSI devices have to fake-up is IDENTIFY. Everything else is a straight translation, and an easy one at that. Even SENSE doesn't need to be faked-up all that much, one just sets an AUTOSENSE flag bit and include the sense in the CCB. So interfacing to CAM is not really a big deal. The SCSI command set is the only cross-device portable command set that exists today, after all. The only problem I have with the original CAM is that it didn't use a dedicated thread for bus-reset/probe/scan/identify/attachment and detachment. That's the only reason the original API was such a bitch to deal with by device drivers. Fixing that fixes all the device interaction issues for attachment/detachment. The API doesn't actually change, but the recursive nature of the direct calls goes away and greatly simplifies device drivers. That's the only thing I see wrong with CAM, frankly. So I applaud your efforts on cleaning up the attach/detach stuff in FreeBSD, but it isn't my focus in this thread and not something I'm interested in doing for the DragonFly project, beyond what I mentioned above. Your comments are improper. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 19:27:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1A421065675; Fri, 5 Jun 2009 19:27:18 +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 93FB88FC0C; Fri, 5 Jun 2009 19:27:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n55JR4ss007355; Fri, 5 Jun 2009 13:27:04 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A297187.2090701@samsco.org> Date: Fri, 05 Jun 2009 13:27:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Julian Elischer References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> In-Reply-To: <4A29694B.2090606@elischer.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexander Motin , FreeBSD Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 19:27:19 -0000 Julian Elischer wrote: > Scott Long wrote: > >> >> So, before you continue to cast ignorant doubts on our approach and hawk >> your incomplete wares, please at least look at what is being done on our >> end, and make an attempt to ask some reasonable questions. >> > > I think that was a little of an over-reaction, and uncalled for.. > Matt's tone was very friendly. > > Every one of Matt's emails follow this formula: 1. I don't know how FOO works, but how you're doing it is wrong 2. Here's how I think FOO should work 3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. 1 and 2 are ignorant and worthless in a technical conversation, and 3 is off topic for FreeBSD mailing lists. So yes, I'm calling him out. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 19:28:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270D510656BE; Fri, 5 Jun 2009 19:28:36 +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 F0F488FC19; Fri, 5 Jun 2009 19:28:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n55JSSIZ007369; Fri, 5 Jun 2009 13:28:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A2971DC.9060608@samsco.org> Date: Fri, 05 Jun 2009 13:28:28 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <200906051917.n55JHcLO077306@apollo.backplane.com> In-Reply-To: <200906051917.n55JHcLO077306@apollo.backplane.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 19:28:38 -0000 Matthew Dillon wrote: > :CAM is being expanded to be a framework for scheduling, recovery, and > :topology management, agnostic to the transport and protocol being used. > :SPI and SCSI are being separated into transport and protocol modules, > :and Alexander has been amazing and kind enough to start a SATA transport > :and ATA protocol module. Unlike Linux, OpenBSD, or anything else out > :there, this is not a tacked-on library for speaking SCSI/SPI at the top > :level and then translating it to something else at a lower level. This > :is about speaking native SBP/RBP/ATA at the periph level and native > :SPI/PATA/SATA/FCAL/SMP/USB at the transport level. > : > :So, before you continue to cast ignorant doubts on our approach and hawk > :your incomplete wares, please at least look at what is being done on our > :end, and make an attempt to ask some reasonable questions. > : > :Scott > > Huh. Get up on the wrong side of the bed, Scott? Just remember who > started making the shit comments this time. > > I have no interest with what FreeBSD is doing with CAM. If you have no interest with what FreeBSD is doing with CAM, then your discussion is off topic for this thread and this mailing list. Please take it somewhere more appropriate. Scott From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 19:48:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCD17106564A; Fri, 5 Jun 2009 19:48:45 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 682278FC1B; Fri, 5 Jun 2009 19:48:45 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n55JmhWk077811; Fri, 5 Jun 2009 12:48:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n55Jmh8X077810; Fri, 5 Jun 2009 12:48:43 -0700 (PDT) Date: Fri, 5 Jun 2009 12:48:43 -0700 (PDT) From: Matthew Dillon Message-Id: <200906051948.n55Jmh8X077810@apollo.backplane.com> To: Scott Long References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> <4A297187.2090701@samsco.org> Cc: Alexander Motin , FreeBSD Current , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 19:48:46 -0000 :Every one of Matt's emails follow this formula: : :1. I don't know how FOO works, but how you're doing it is wrong :2. Here's how I think FOO should work :3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. : :1 and 2 are ignorant and worthless in a technical conversation, and 3 is :off topic for FreeBSD mailing lists. So yes, I'm calling him out. : :Scott Well, so far about the only one talking shit here is you, Scott. Insofar as 3. goes, I already provided references to that code, because the purpose is to share code. I wonder if you even bothered to look at it. Judging from your comments, I guess not. It isn't quite in the decrepit shape you make it out to be. I mean, come on, not even the ATA driver has hot-plug support (not without crashing, anyhow), and I would not characterize IT as being decrepit! It was simply a code reference, along with OpenBSD's code reference. For anyone writing a driver having multiple code references is always beneficial, it saves a lot of time and puts things in context. After all, OpenBSD's and Linux's AHCI driver is what really opened up the space for the rest of us. OpenBSD saved me at least 100 man-hours of work and Alex just now saved me another 8 or 9 at the cost of a 5 minute email. That seems to be a good use of the mailing lists in my view. I'm not above asking other driver writers for information that I do not have complete knowledge of. I learned a lot from Alexander Motin's posting with regards to port multipliers, enough that I am now quite comfortable in my ability to add the feature in my own work. Clearly I am not totally deficient in my knowledege since I actually did port the OpenBSD driver to DragonFly. As far as I can tell, I haven't said anything about anyone doing it wrong, certainly not with the tone your extremely jaded portrayal seems to be applying to my posting. I have my opinion and you have yours, but that's all it is... an opinion. My opinion is that the only portable device I/O command set available in the world today is the SCSI command set. There is no ulterior motive, it's just an opinion. I guess it is in the eye of the beholder. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 22:36:26 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B4F11065696; Fri, 5 Jun 2009 22:36:26 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D99A78FC0C; Fri, 5 Jun 2009 22:36:24 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n55Maatm042314; Fri, 5 Jun 2009 17:36:36 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n55MaaFr042313; Fri, 5 Jun 2009 17:36:36 -0500 (CDT) (envelope-from brooks) Date: Fri, 5 Jun 2009 17:36:36 -0500 From: Brooks Davis To: arch@freebsd.org, current@freebsd.org Message-ID: <20090605223636.GA24364@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Fri, 05 Jun 2009 17:36:36 -0500 (CDT) Cc: Subject: RFT: Allow large values of NGROUPS_MAX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 22:36:27 -0000 --i9LlY+UWpKt15+FH Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been working on fixing the limit of 15 groups per user. This has primarily consisted of merging a patch from Isilon Systems which breaks the group array out of struct ucred and stores in in malloc'd storage. I've attached a patch which includes that change and increases the value of NGROUPS_MAX to 32767. It also changes references to cr_groups[0] to use the cr_gid macro and introduces a new crsetgroups() function for use by random bits of code that fill in credentials (usually partial ones) Additionally, a number of arrays that used to be of length NGROUPS have been changed to use XU_NGROUPS (from xucred) or their own definition which is 16 to avoid excessive bloat. Most of these should probably be change to use dynamic allocation. In general, when something could not take more groups, I have chosen to truncate the list rather than fail. This may raise issues with negative permissions, but complete failure is likely to cause problems for more people. If it's a major issue this can be made tunable. As I mentioned above, many thing should be redone to support dynamic allocation, but all the RPC related things can not. I'd like people to test and review this patch with the aim of getting it and some of the other work I've been doing in subversion in to 8.0. You can find all of it at http://svn.freebsd.org/base/projects/ngroups. Before any merge a couple decisions need to be made: - How large should NGROUPS_MAX be? Linux uses 65536 and we could extend things to support that, but it's probably unnecessary. =20 - Should we make any attempt to support old binaries when there are more than 16 groups? The POSIX getgroups/setgroups APIs did not anticipate this change and thus either will fail outright. We can't fix setgroups, but we might want to make an optional accommodation for getgroups to allow for truncated returns to old code. -- Brooks --sdtB3X0nJg68CQEu Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ngroups-nosysconf.diff" Content-Transfer-Encoding: quoted-printable diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/lib/libc/rpc/netname.c ngroups/lib/libc/= rpc/netname.c --- /usr/src/lib/libc/rpc/netname.c 2009-01-22 10:05:44.000000000 -0600 +++ ngroups/lib/libc/rpc/netname.c 2009-05-14 01:48:22.000000000 -0500 @@ -61,9 +61,6 @@ #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 256 #endif -#ifndef NGROUPS -#define NGROUPS 16 -#endif =20 #define TYPE_BIT(type) (sizeof (type) * CHAR_BIT) =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/lib/libc/rpc/netnamer.c ngroups/lib/libc= /rpc/netnamer.c --- /usr/src/lib/libc/rpc/netnamer.c 2009-01-22 10:05:44.000000000 -0600 +++ ngroups/lib/libc/rpc/netnamer.c 2009-05-13 22:51:38.000000000 -0500 @@ -66,10 +66,6 @@ static int getnetid( char *, char * ); static int _getgroups( char *, gid_t * ); =20 -#ifndef NGROUPS -#define NGROUPS 16 -#endif - /* * Convert network-name into unix credential */ @@ -104,7 +100,7 @@ return (0); } *gidp =3D (gid_t) atol(p); - for (gidlen =3D 0; gidlen < NGROUPS; gidlen++) { + for (gidlen =3D 0; gidlen < NGRPS; gidlen++) { p =3D strsep(&res, "\n,"); if (p =3D=3D NULL) break; @@ -157,7 +153,7 @@ static int _getgroups(uname, groups) char *uname; - gid_t groups[NGROUPS]; + gid_t groups[NGRPS]; { gid_t ngroups =3D 0; struct group *grp; @@ -169,7 +165,7 @@ while ((grp =3D getgrent())) { for (i =3D 0; grp->gr_mem[i]; i++) if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups =3D=3D NGROUPS) { + if (ngroups =3D=3D NGRPS) { #ifdef DEBUG fprintf(stderr, "initgroups: %s is in too many groups\n", uname); diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/contrib/pf/net/pf.c ngroups/sys/cont= rib/pf/net/pf.c --- /usr/src/sys/contrib/pf/net/pf.c 2009-06-05 15:33:53.000000000 -0500 +++ ngroups/sys/contrib/pf/net/pf.c 2009-06-05 16:02:32.000000000 -0500 @@ -2945,7 +2945,7 @@ if (inp_arg !=3D NULL) { INP_LOCK_ASSERT(inp_arg); pd->lookup.uid =3D inp_arg->inp_cred->cr_uid; - pd->lookup.gid =3D inp_arg->inp_cred->cr_groups[0]; + pd->lookup.gid =3D inp_arg->inp_cred->cr_gid; return (1); } #endif @@ -3043,7 +3043,7 @@ } #ifdef __FreeBSD__ pd->lookup.uid =3D inp->inp_cred->cr_uid; - pd->lookup.gid =3D inp->inp_cred->cr_groups[0]; + pd->lookup.gid =3D inp->inp_cred->cr_gid; INP_INFO_RUNLOCK(pi); #else pd->lookup.uid =3D inp->inp_socket->so_euid; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/nfs/nfs_commonport.c ngroups/sys/= fs/nfs/nfs_commonport.c --- /usr/src/sys/fs/nfs/nfs_commonport.c 2009-05-29 12:48:03.000000000 -0500 +++ ngroups/sys/fs/nfs/nfs_commonport.c 2009-06-05 15:33:54.000000000 -0500 @@ -220,14 +220,9 @@ void newnfs_copycred(struct nfscred *nfscr, struct ucred *cr) { - int ngroups, i; =20 cr->cr_uid =3D nfscr->nfsc_uid; - ngroups =3D (nfscr->nfsc_ngroups < NGROUPS) ? - nfscr->nfsc_ngroups : NGROUPS; - for (i =3D 0; i < ngroups; i++) - cr->cr_groups[i] =3D nfscr->nfsc_groups[i]; - cr->cr_ngroups =3D ngroups; + crsetgroups(cr, nfscr->nfsc_ngroups, nfscr->nfsc_groups); } =20 /* @@ -295,15 +290,13 @@ =20 /* * Set the credentials to refer to root. - * If only the various BSDen could agree on whether cr_gid is a separate - * field or cr_groups[0]... */ void newnfs_setroot(struct ucred *cred) { =20 cred->cr_uid =3D 0; - cred->cr_groups[0] =3D 0; + cred->cr_gid =3D 0; cred->cr_ngroups =3D 1; } =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/nfsclient/nfs_clport.c ngroups/sy= s/fs/nfsclient/nfs_clport.c --- /usr/src/sys/fs/nfsclient/nfs_clport.c 2009-05-29 12:48:03.000000000 -0= 500 +++ ngroups/sys/fs/nfsclient/nfs_clport.c 2009-06-05 15:33:54.000000000 -05= 00 @@ -976,14 +976,12 @@ void newnfs_copyincred(struct ucred *cr, struct nfscred *nfscr) { - int ngroups, i; + int i; =20 nfscr->nfsc_uid =3D cr->cr_uid; - ngroups =3D (cr->cr_ngroups > NGROUPS) ? NGROUPS : - cr->cr_ngroups; - for (i =3D 0; i < ngroups; i++) + nfscr->nfsc_ngroups =3D MIN(cr->cr_ngroups, XU_NGROUPS); + for (i =3D 0; i < nfscr->nfsc_ngroups; i++) nfscr->nfsc_groups[i] =3D cr->cr_groups[i]; - nfscr->nfsc_ngroups =3D ngroups; } =20 =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/nfsserver/nfs_nfsdport.c ngroups/= sys/fs/nfsserver/nfs_nfsdport.c --- /usr/src/sys/fs/nfsserver/nfs_nfsdport.c 2009-06-05 15:33:50.000000000 = -0500 +++ ngroups/sys/fs/nfsserver/nfs_nfsdport.c 2009-06-05 16:02:29.000000000 -= 0500 @@ -2360,7 +2360,6 @@ nfsd_excred(struct nfsrv_descript *nd, struct nfsexstuff *exp, struct ucred *credanon) { - int i; int error =3D 0; =20 /* @@ -2403,9 +2402,8 @@ (nd->nd_flag & ND_AUTHNONE))) { nd->nd_cred->cr_uid =3D credanon->cr_uid; nd->nd_cred->cr_gid =3D credanon->cr_gid; - for (i =3D 0; i < credanon->cr_ngroups && i < NGROUPS; i++) - nd->nd_cred->cr_groups[i] =3D credanon->cr_groups[i]; - nd->nd_cred->cr_ngroups =3D i; + crsetgroups(nd->nd_cred, credanon->cr_ngroups, + credanon->cr_groups); } return (0); } diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c ngroups= /sys/fs/nfsserver/nfs_nfsdstate.c --- /usr/src/sys/fs/nfsserver/nfs_nfsdstate.c 2009-05-29 12:48:03.000000000= -0500 +++ ngroups/sys/fs/nfsserver/nfs_nfsdstate.c 2009-06-05 15:33:54.000000000 = -0500 @@ -3577,7 +3577,6 @@ nd->nd_repstat =3D 0; cred->cr_uid =3D clp->lc_uid; cred->cr_gid =3D clp->lc_gid; - cred->cr_groups[0] =3D clp->lc_gid; callback =3D clp->lc_callback; NFSUNLOCKSTATE(); cred->cr_ngroups =3D 1; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/portalfs/portal.h ngroups/sys/fs/= portalfs/portal.h --- /usr/src/sys/fs/portalfs/portal.h 2009-01-22 10:06:01.000000000 -0600 +++ ngroups/sys/fs/portalfs/portal.h 2009-06-05 15:33:54.000000000 -0500 @@ -43,7 +43,7 @@ int pcr_flag; /* File open mode */ uid_t pcr_uid; /* From ucred */ short pcr_ngroups; /* From ucred */ - gid_t pcr_groups[NGROUPS]; /* From ucred */ + gid_t pcr_groups[XU_NGROUPS]; /* From ucred */ }; =20 #ifdef _KERNEL diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/portalfs/portal_vnops.c ngroups/s= ys/fs/portalfs/portal_vnops.c --- /usr/src/sys/fs/portalfs/portal_vnops.c 2009-01-22 10:06:01.000000000 -= 0600 +++ ngroups/sys/fs/portalfs/portal_vnops.c 2009-06-05 15:33:54.000000000 -0= 500 @@ -311,8 +311,9 @@ =20 pcred.pcr_flag =3D ap->a_mode; pcred.pcr_uid =3D ap->a_cred->cr_uid; - pcred.pcr_ngroups =3D ap->a_cred->cr_ngroups; - bcopy(ap->a_cred->cr_groups, pcred.pcr_groups, NGROUPS * sizeof(gid_t)); + pcred.pcr_ngroups =3D MIN(ap->a_cred->cr_ngroups, XU_NGROUPS); + bcopy(ap->a_cred->cr_groups, pcred.pcr_groups, + pcred.pcr_ngroups * sizeof(gid_t)); aiov[0].iov_base =3D (caddr_t) &pcred; aiov[0].iov_len =3D sizeof(pcred); aiov[1].iov_base =3D pt->pt_arg; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/fs/unionfs/union_vnops.c ngroups/sys= /fs/unionfs/union_vnops.c --- /usr/src/sys/fs/unionfs/union_vnops.c 2009-04-12 15:26:52.000000000 -05= 00 +++ ngroups/sys/fs/unionfs/union_vnops.c 2009-06-05 15:33:54.000000000 -0500 @@ -638,7 +638,6 @@ uid_t uid; /* upper side vnode's uid */ gid_t gid; /* upper side vnode's gid */ u_short vmode; /* upper side vnode's mode */ - gid_t *gp; u_short mask; =20 mask =3D 0; @@ -659,17 +658,14 @@ =20 /* check group */ count =3D 0; - gp =3D cred->cr_groups; - for (; count < cred->cr_ngroups; count++, gp++) { - if (gid =3D=3D *gp) { - if (accmode & VEXEC) - mask |=3D S_IXGRP; - if (accmode & VREAD) - mask |=3D S_IRGRP; - if (accmode & VWRITE) - mask |=3D S_IWGRP; - return ((vmode & mask) =3D=3D mask ? 0 : EACCES); - } + if (groupmember(gid, cred)) { + if (accmode & VEXEC) + mask |=3D S_IXGRP; + if (accmode & VREAD) + mask |=3D S_IRGRP; + if (accmode & VWRITE) + mask |=3D S_IWGRP; + return ((vmode & mask) =3D=3D mask ? 0 : EACCES); } =20 /* check other */ diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/gnu/fs/xfs/FreeBSD/xfs_compat.h ngro= ups/sys/gnu/fs/xfs/FreeBSD/xfs_compat.h --- /usr/src/sys/gnu/fs/xfs/FreeBSD/xfs_compat.h 2009-02-28 13:28:12.000000= 000 -0600 +++ ngroups/sys/gnu/fs/xfs/FreeBSD/xfs_compat.h 2009-06-05 15:33:54.0000000= 00 -0500 @@ -163,7 +163,7 @@ * Cedentials manipulation. */ #define current_fsuid(credp) (credp)->cr_uid -#define current_fsgid(credp) (credp)->cr_groups[0] +#define current_fsgid(credp) (credp)->cr_gid =20 #define PAGE_CACHE_SIZE PAGE_SIZE =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/gnu/fs/xfs/xfs_inode.c ngroups/sys/g= nu/fs/xfs/xfs_inode.c --- /usr/src/sys/gnu/fs/xfs/xfs_inode.c 2009-01-21 12:45:49.000000000 -0600 +++ ngroups/sys/gnu/fs/xfs/xfs_inode.c 2009-06-05 15:33:54.000000000 -0500 @@ -1124,7 +1124,7 @@ ip->i_d.di_nlink =3D nlink; ASSERT(ip->i_d.di_nlink =3D=3D nlink); ip->i_d.di_uid =3D curthread->td_ucred->cr_uid; - ip->i_d.di_gid =3D curthread->td_ucred->cr_groups[0]; + ip->i_d.di_gid =3D curthread->td_ucred->cr_gid; ip->i_d.di_projid =3D prid; memset(&(ip->i_d.di_pad[0]), 0, sizeof(ip->i_d.di_pad)); =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/gnu/fs/xfs/xfs_vnodeops.c ngroups/sy= s/gnu/fs/xfs/xfs_vnodeops.c --- /usr/src/sys/gnu/fs/xfs/xfs_vnodeops.c 2009-01-21 12:45:49.000000000 -0= 600 +++ ngroups/sys/gnu/fs/xfs/xfs_vnodeops.c 2009-06-05 15:33:54.000000000 -05= 00 @@ -3379,7 +3379,7 @@ */ error =3D XFS_QM_DQVOPALLOC(mp, dp, current->td_ucred->cr_uid, - current->td_ucred->cr_groups[0], + current->td_ucred->cr_gid, prid, XFS_QMOPT_QUOTALL | XFS_QMOPT_INHERIT, &udqp, &gdqp); if (error) Only in /usr/src/sys/i386/ibcs2: ibcs2_misc.c.orig Only in /usr/src/sys/kern: kern_exec.c.orig Only in /usr/src/sys/kern: kern_proc.c.orig diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/kern/kern_prot.c ngroups/sys/kern/ke= rn_prot.c --- /usr/src/sys/kern/kern_prot.c 2009-06-05 15:33:50.000000000 -0500 +++ ngroups/sys/kern/kern_prot.c 2009-06-05 16:02:28.000000000 -0500 @@ -82,6 +82,9 @@ =20 SYSCTL_NODE(_security, OID_AUTO, bsd, CTLFLAG_RW, 0, "BSD security policy"= ); =20 +static __inline void crsetgroups_locked(struct ucred *cr, int ngrp, + gid_t *groups); + #ifndef _SYS_SYSPROTO_H_ struct getpid_args { int dummy; @@ -243,16 +246,11 @@ =20 td->td_retval[0] =3D td->td_ucred->cr_rgid; #if defined(COMPAT_43) - td->td_retval[1] =3D td->td_ucred->cr_groups[0]; + td->td_retval[1] =3D td->td_ucred->cr_gid; #endif return (0); } =20 -/* - * Get effective group ID. The "egid" is groups[0], and could be obtained - * via getgroups. This syscall exists because it is somewhat painful to do - * correctly in a library function. - */ #ifndef _SYS_SYSPROTO_H_ struct getegid_args { int dummy; @@ -263,7 +261,7 @@ getegid(struct thread *td, struct getegid_args *uap) { =20 - td->td_retval[0] =3D td->td_ucred->cr_groups[0]; + td->td_retval[0] =3D td->td_ucred->cr_gid; return (0); } =20 @@ -679,7 +677,7 @@ gid !=3D oldcred->cr_svgid && /* allow setgid(saved gid) */ #endif #ifdef POSIX_APPENDIX_B_4_2_2 /* Use BSD-compat clause from B.4.2.2 */ - gid !=3D oldcred->cr_groups[0] && /* allow setgid(getegid()) */ + gid !=3D oldcred->cr_gid && /* allow setgid(getegid()) */ #endif (error =3D priv_check_cred(oldcred, PRIV_CRED_SETGID, 0)) !=3D 0) goto fail; @@ -691,7 +689,7 @@ */ if ( #ifdef POSIX_APPENDIX_B_4_2_2 /* use the clause from B.4.2.2 */ - gid =3D=3D oldcred->cr_groups[0] || + gid =3D=3D oldcred->cr_gid || #endif /* We are using privs. */ priv_check_cred(oldcred, PRIV_CRED_SETGID, 0) =3D=3D 0) @@ -720,7 +718,7 @@ * In all cases permitted cases, we are changing the egid. * Copy credentials so other references do not see our changes. */ - if (oldcred->cr_groups[0] !=3D gid) { + if (oldcred->cr_gid !=3D gid) { change_egid(newcred, gid); setsugid(p); } @@ -766,7 +764,7 @@ (error =3D priv_check_cred(oldcred, PRIV_CRED_SETEGID, 0)) !=3D 0) goto fail; =20 - if (oldcred->cr_groups[0] !=3D egid) { + if (oldcred->cr_gid !=3D egid) { change_egid(newcred, egid); setsugid(p); } @@ -811,7 +809,6 @@ { struct proc *p =3D td->td_proc; struct ucred *newcred, *oldcred; - int newgroups; int error; =20 if (ngrp > NGROUPS) @@ -820,16 +817,7 @@ newcred =3D crget(); crextend(newcred, ngrp); PROC_LOCK(p); - oldcred =3D p->p_ucred; - newgroups =3D MAX(oldcred->cr_agroups, ngrp); - while (newcred->cr_agroups < newgroups) { - PROC_UNLOCK(p); - crextend(newcred, newgroups); - PROC_LOCK(p); - oldcred =3D p->p_ucred; - newgroups =3D MAX(oldcred->cr_agroups, ngrp); - } - + oldcred =3D crcopysafe(p, newcred); =20 #ifdef MAC error =3D mac_cred_check_setgroups(oldcred, ngrp, groups); @@ -841,7 +829,6 @@ if (error) goto fail; =20 - crcopy(newcred, oldcred); if (ngrp < 1) { /* * setgroups(0, NULL) is a legitimate way of clearing the @@ -851,8 +838,7 @@ */ newcred->cr_ngroups =3D 1; } else { - bcopy(groups, newcred->cr_groups, ngrp * sizeof(gid_t)); - newcred->cr_ngroups =3D ngrp; + crsetgroups_locked(newcred, ngrp, groups); } setsugid(p); p->p_ucred =3D newcred; @@ -964,12 +950,12 @@ =20 if (((rgid !=3D (gid_t)-1 && rgid !=3D oldcred->cr_rgid && rgid !=3D oldcred->cr_svgid) || - (egid !=3D (gid_t)-1 && egid !=3D oldcred->cr_groups[0] && + (egid !=3D (gid_t)-1 && egid !=3D oldcred->cr_gid && egid !=3D oldcred->cr_rgid && egid !=3D oldcred->cr_svgid)) && (error =3D priv_check_cred(oldcred, PRIV_CRED_SETREGID, 0)) !=3D 0) goto fail; =20 - if (egid !=3D (gid_t)-1 && oldcred->cr_groups[0] !=3D egid) { + if (egid !=3D (gid_t)-1 && oldcred->cr_gid !=3D egid) { change_egid(newcred, egid); setsugid(p); } @@ -977,9 +963,9 @@ change_rgid(newcred, rgid); setsugid(p); } - if ((rgid !=3D (gid_t)-1 || newcred->cr_groups[0] !=3D newcred->cr_rgid) = && - newcred->cr_svgid !=3D newcred->cr_groups[0]) { - change_svgid(newcred, newcred->cr_groups[0]); + if ((rgid !=3D (gid_t)-1 || newcred->cr_gid !=3D newcred->cr_rgid) && + newcred->cr_svgid !=3D newcred->cr_gid) { + change_svgid(newcred, newcred->cr_gid); setsugid(p); } p->p_ucred =3D newcred; @@ -1110,17 +1096,17 @@ =20 if (((rgid !=3D (gid_t)-1 && rgid !=3D oldcred->cr_rgid && rgid !=3D oldcred->cr_svgid && - rgid !=3D oldcred->cr_groups[0]) || + rgid !=3D oldcred->cr_gid) || (egid !=3D (gid_t)-1 && egid !=3D oldcred->cr_rgid && egid !=3D oldcred->cr_svgid && - egid !=3D oldcred->cr_groups[0]) || + egid !=3D oldcred->cr_gid) || (sgid !=3D (gid_t)-1 && sgid !=3D oldcred->cr_rgid && sgid !=3D oldcred->cr_svgid && - sgid !=3D oldcred->cr_groups[0])) && + sgid !=3D oldcred->cr_gid)) && (error =3D priv_check_cred(oldcred, PRIV_CRED_SETRESGID, 0)) !=3D 0) goto fail; =20 - if (egid !=3D (gid_t)-1 && oldcred->cr_groups[0] !=3D egid) { + if (egid !=3D (gid_t)-1 && oldcred->cr_gid !=3D egid) { change_egid(newcred, egid); setsugid(p); } @@ -1189,8 +1175,8 @@ error1 =3D copyout(&cred->cr_rgid, uap->rgid, sizeof(cred->cr_rgid)); if (uap->egid) - error2 =3D copyout(&cred->cr_groups[0], - uap->egid, sizeof(cred->cr_groups[0])); + error2 =3D copyout(&cred->cr_gid, + uap->egid, sizeof(cred->cr_gid)); if (uap->sgid) error3 =3D copyout(&cred->cr_svgid, uap->sgid, sizeof(cred->cr_svgid)); @@ -1911,7 +1897,7 @@ ngroups =3D min(cr->cr_ngroups, XU_NGROUPS); xcr->cr_ngroups =3D ngroups; bcopy(cr->cr_groups, xcr->cr_groups, - ngroups * sizeof(cr->cr_groups[0])); + ngroups * sizeof(*cr->cr_groups)); } =20 /* @@ -1969,6 +1955,8 @@ /* * We extend by 2 each time since we're using a power of two * allocator. + * XXX: it probably makes more sense to right-size the + * allocation if we need more than a page. */ if (cr->cr_agroups) cnt =3D cr->cr_agroups * 2; @@ -1987,6 +1975,36 @@ } =20 /* + * Copy groups in to a credential, preserving any necessicary invariants + * (i.e. sorting in the future). crextend() must have been called + * before hand to ensure sufficient space is available. If=20 + */ +static inline void +crsetgroups_locked(struct ucred *cr, int ngrp, gid_t *groups) +{ +=09 + KASSERT(cr->cr_agroups >=3D ngrp, ("cr_ngroups is too small")); + + bcopy(groups, cr->cr_groups, ngrp * sizeof(gid_t)); + cr->cr_ngroups =3D ngrp; +} + +/* + * Copy groups in to a credential after expanding it if required. + * Truncate the list to NGROUPS if it is too large. + */ +void +crsetgroups(struct ucred *cr, int ngrp, gid_t *groups) +{ + + if (ngrp > NGROUPS) + ngrp =3D NGROUPS; + + crextend(cr, ngrp); + crsetgroups_locked(cr, ngrp, groups); +} + +/* * Get login name, if available. */ #ifndef _SYS_SYSPROTO_H_ @@ -2083,7 +2101,7 @@ change_egid(struct ucred *newcred, gid_t egid) { =20 - newcred->cr_groups[0] =3D egid; + newcred->cr_gid =3D egid; } =20 /*- Only in /usr/src/sys/kern: kern_prot.c.orig diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/kern/vfs_export.c ngroups/sys/kern/v= fs_export.c --- /usr/src/sys/kern/vfs_export.c 2009-05-29 12:48:02.000000000 -0500 +++ ngroups/sys/kern/vfs_export.c 2009-06-05 15:33:54.000000000 -0500 @@ -120,9 +120,8 @@ np->netc_exflags =3D argp->ex_flags; np->netc_anon =3D crget(); np->netc_anon->cr_uid =3D argp->ex_anon.cr_uid; - np->netc_anon->cr_ngroups =3D argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon->cr_groups, - sizeof(np->netc_anon->cr_groups)); + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, + argp->ex_anon.cr_groups); np->netc_numsecflavors =3D argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); @@ -205,9 +204,8 @@ np->netc_exflags =3D argp->ex_flags; np->netc_anon =3D crget(); np->netc_anon->cr_uid =3D argp->ex_anon.cr_uid; - np->netc_anon->cr_ngroups =3D argp->ex_anon.cr_ngroups; - bcopy(argp->ex_anon.cr_groups, np->netc_anon->cr_groups, - sizeof(np->netc_anon->cr_groups)); + crsetgroups(np->netc_anon, argp->ex_anon.cr_ngroups, + np->netc_anon->cr_groups); np->netc_numsecflavors =3D argp->ex_numsecflavors; bcopy(argp->ex_secflavors, np->netc_secflavors, sizeof(np->netc_secflavors)); diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/kern/vfs_syscalls.c ngroups/sys/kern= /vfs_syscalls.c --- /usr/src/sys/kern/vfs_syscalls.c 2009-06-05 15:33:50.000000000 -0500 +++ ngroups/sys/kern/vfs_syscalls.c 2009-06-05 16:02:28.000000000 -0500 @@ -2128,7 +2128,7 @@ cred =3D td->td_ucred; tmpcred =3D crdup(cred); tmpcred->cr_uid =3D cred->cr_ruid; - tmpcred->cr_groups[0] =3D cred->cr_rgid; + tmpcred->cr_gid =3D cred->cr_rgid; td->td_ucred =3D tmpcred; } else cred =3D tmpcred =3D td->td_ucred; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/netinet/ipfw/ip_fw2.c ngroups/sys/ne= tinet/ipfw/ip_fw2.c --- /usr/src/sys/netinet/ipfw/ip_fw2.c 2009-06-05 15:33:50.000000000 -0500 +++ ngroups/sys/netinet/ipfw/ip_fw2.c 2009-06-05 16:02:28.000000000 -0500 @@ -139,8 +139,9 @@ * the user specified UID/GID based constraints in * a firewall rule. */ +#define FW_NGROUPS 16 struct ip_fw_ugid { - gid_t fw_groups[NGROUPS]; + gid_t fw_groups[FW_NGROUPS]; /* XXX: should be dynamic */ int fw_ngroups; uid_t fw_uid; int fw_prid; @@ -2016,8 +2017,8 @@ cr =3D inp->inp_cred; ugp->fw_prid =3D jailed(cr) ? cr->cr_prison->pr_id : -1; ugp->fw_uid =3D cr->cr_uid; - ugp->fw_ngroups =3D cr->cr_ngroups; - bcopy(cr->cr_groups, ugp->fw_groups, sizeof(ugp->fw_groups)); + ugp->fw_ngroups =3D MIN(cr->cr_ngroups, FW_NGROUPS); + bcopy(cr->cr_groups, ugp->fw_groups, sizeof(gid_t) * ugp->fw_ngroups); } =20 static int diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/netncp/ncp_conn.c ngroups/sys/netncp= /ncp_conn.c --- /usr/src/sys/netncp/ncp_conn.c 2009-01-22 10:06:17.000000000 -0600 +++ ngroups/sys/netncp/ncp_conn.c 2009-06-05 15:33:54.000000000 -0500 @@ -249,7 +249,7 @@ ncp->connid =3D 0xFFFF; ncp->li =3D *cap; ncp->nc_group =3D (cap->group !=3D NCP_DEFAULT_GROUP) ? - cap->group : cred->cr_groups[0]; + cap->group : cred->cr_gid; =20 if (cap->retry_count =3D=3D 0) ncp->li.retry_count =3D NCP_RETRY_COUNT; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/netsmb/smb_conn.c ngroups/sys/netsmb= /smb_conn.c --- /usr/src/sys/netsmb/smb_conn.c 2009-01-22 10:06:17.000000000 -0600 +++ ngroups/sys/netsmb/smb_conn.c 2009-06-05 15:33:54.000000000 -0500 @@ -416,7 +416,7 @@ if (uid =3D=3D SMBM_ANY_OWNER) uid =3D realuid; if (gid =3D=3D SMBM_ANY_GROUP) - gid =3D cred->cr_groups[0]; + gid =3D cred->cr_gid; vcp->vc_uid =3D uid; vcp->vc_grp =3D gid; =20 @@ -714,7 +714,7 @@ if (uid =3D=3D SMBM_ANY_OWNER) uid =3D realuid; if (gid =3D=3D SMBM_ANY_GROUP) - gid =3D cred->cr_groups[0]; + gid =3D cred->cr_gid; ssp =3D smb_zmalloc(sizeof(*ssp), M_SMBCONN, M_WAITOK); smb_co_init(SSTOCP(ssp), SMBL_SHARE, "smbss ilock", "smbss"); ssp->obj.co_free =3D smb_share_free; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/nfsclient/nfs_subs.c ngroups/sys/nfs= client/nfs_subs.c --- /usr/src/sys/nfsclient/nfs_subs.c 2009-05-29 12:48:02.000000000 -0500 +++ ngroups/sys/nfsclient/nfs_subs.c 2009-06-05 15:33:54.000000000 -0500 @@ -253,7 +253,7 @@ *tl++ =3D 0; /* stamp ?? */ *tl++ =3D 0; /* NULL hostname */ *tl++ =3D txdr_unsigned(cr->cr_uid); - *tl++ =3D txdr_unsigned(cr->cr_groups[0]); + *tl++ =3D txdr_unsigned(cr->cr_gid); grpsiz =3D (auth_len >> 2) - 5; *tl++ =3D txdr_unsigned(grpsiz); for (i =3D 1; i <=3D grpsiz; i++) diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/nfsserver/nfs_srvsock.c ngroups/sys/= nfsserver/nfs_srvsock.c --- /usr/src/sys/nfsserver/nfs_srvsock.c 2009-06-05 15:33:51.000000000 -0500 +++ ngroups/sys/nfsserver/nfs_srvsock.c 2009-06-05 16:02:29.000000000 -0500 @@ -358,7 +358,7 @@ tl =3D nfsm_dissect_nonblock(u_int32_t *, 3 * NFSX_UNSIGNED); nd->nd_cr->cr_uid =3D nd->nd_cr->cr_ruid =3D nd->nd_cr->cr_svuid =3D fxdr_unsigned(uid_t, *tl++); - nd->nd_cr->cr_groups[0] =3D nd->nd_cr->cr_rgid =3D + nd->nd_cr->cr_gid =3D nd->nd_cr->cr_rgid =3D nd->nd_cr->cr_svgid =3D fxdr_unsigned(gid_t, *tl++); #ifdef MAC mac_cred_associate_nfsd(nd->nd_cr); @@ -374,7 +374,7 @@ nd->nd_cr->cr_groups[i] =3D fxdr_unsigned(gid_t, *tl++); else tl++; - nd->nd_cr->cr_ngroups =3D (len >=3D XU_NGROUPS) ? XU_NGROUPS : (len + 1); + nd->nd_cr->cr_ngroups =3D MIN(XU_NGROUPS, len + 1); if (nd->nd_cr->cr_ngroups > 1) nfsrvw_sort(nd->nd_cr->cr_groups, nd->nd_cr->cr_ngroups); len =3D fxdr_unsigned(int, *++tl); Only in /usr/src/sys/nfsserver: nfs_srvsock.c.orig diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/nfsserver/nfs_srvsubs.c ngroups/sys/= nfsserver/nfs_srvsubs.c --- /usr/src/sys/nfsserver/nfs_srvsubs.c 2009-05-29 12:48:04.000000000 -0500 +++ ngroups/sys/nfsserver/nfs_srvsubs.c 2009-06-05 15:33:54.000000000 -0500 @@ -1181,9 +1181,7 @@ cred =3D nfsd->nd_cr; if (cred->cr_uid =3D=3D 0 || (exflags & MNT_EXPORTANON)) { cred->cr_uid =3D credanon->cr_uid; - for (i =3D 0; i < credanon->cr_ngroups && i < NGROUPS; i++) - cred->cr_groups[i] =3D credanon->cr_groups[i]; - cred->cr_ngroups =3D i; + crsetgroups(cred, credanon->cr_ngroups, credanon->cr_groups); } if (exflags & MNT_EXRDONLY) *rdonlyp =3D 1; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/rpc/authunix_prot.c ngroups/sys/rpc/= authunix_prot.c --- /usr/src/sys/rpc/authunix_prot.c 2009-06-05 15:33:49.000000000 -0500 +++ ngroups/sys/rpc/authunix_prot.c 2009-06-05 16:02:28.000000000 -0500 @@ -98,7 +98,7 @@ =20 if (!xdr_uint32_t(xdrs, &cred->cr_uid)) return (FALSE); - if (!xdr_uint32_t(xdrs, &cred->cr_groups[0])) + if (!xdr_uint32_t(xdrs, &cred->cr_gid)) return (FALSE); =20 if (xdrs->x_op =3D=3D XDR_ENCODE) { diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c ngro= ups/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c --- /usr/src/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 2009-01-22 10:05:57.000000= 000 -0600 +++ ngroups/sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 2009-06-05 15:33:54.0000000= 00 -0500 @@ -447,11 +447,7 @@ cr =3D client->cl_cred =3D crget(); cr->cr_uid =3D cr->cr_ruid =3D cr->cr_svuid =3D uc->uid; cr->cr_rgid =3D cr->cr_svgid =3D uc->gid; - cr->cr_ngroups =3D uc->gidlen; - if (cr->cr_ngroups > NGROUPS) - cr->cr_ngroups =3D NGROUPS; - for (i =3D 0; i < cr->cr_ngroups; i++) - cr->cr_groups[i] =3D uc->gidlist[i]; + crsetgroups(cr, uc->gidlen, uc->gidlist); *crp =3D crhold(cr); =20 return (TRUE); diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/rpc/svc_auth.c ngroups/sys/rpc/svc_a= uth.c --- /usr/src/sys/rpc/svc_auth.c 2009-01-22 10:05:57.000000000 -0600 +++ ngroups/sys/rpc/svc_auth.c 2009-06-05 15:33:54.000000000 -0500 @@ -165,7 +165,7 @@ svc_getcred(struct svc_req *rqst, struct ucred **crp, int *flavorp) { struct ucred *cr =3D NULL; - int flavor, i; + int flavor; struct xucred *xcr; =20 flavor =3D rqst->rq_cred.oa_flavor; @@ -177,10 +177,8 @@ xcr =3D (struct xucred *) rqst->rq_clntcred; cr =3D crget(); cr->cr_uid =3D cr->cr_ruid =3D cr->cr_svuid =3D xcr->cr_uid; - cr->cr_ngroups =3D xcr->cr_ngroups; - for (i =3D 0; i < xcr->cr_ngroups; i++) - cr->cr_groups[i] =3D xcr->cr_groups[i]; - cr->cr_rgid =3D cr->cr_svgid =3D cr->cr_groups[0]; + crsetgroups(cr, xcr->cr_ngroups, xcr->cr_groups); + cr->cr_rgid =3D cr->cr_svgid =3D cr->cr_gid; *crp =3D cr; return (TRUE); =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/rpc/svc_auth_unix.c ngroups/sys/rpc/= svc_auth_unix.c --- /usr/src/sys/rpc/svc_auth_unix.c 2009-01-22 10:05:57.000000000 -0600 +++ ngroups/sys/rpc/svc_auth_unix.c 2009-06-05 15:33:54.000000000 -0500 @@ -88,20 +88,20 @@ str_len =3D RNDUP(str_len); buf +=3D str_len / sizeof (int32_t); xcr->cr_uid =3D IXDR_GET_UINT32(buf); - xcr->cr_groups[0] =3D IXDR_GET_UINT32(buf); + xcr->cr_gid =3D IXDR_GET_UINT32(buf); gid_len =3D (size_t)IXDR_GET_UINT32(buf); if (gid_len > NGRPS) { stat =3D AUTH_BADCRED; goto done; } for (i =3D 0; i < gid_len; i++) { - if (i + 1 < NGROUPS) + if (i + 1 < XU_NGROUPS) xcr->cr_groups[i + 1] =3D IXDR_GET_INT32(buf); else buf++; } - if (gid_len + 1 > NGROUPS) - xcr->cr_ngroups =3D NGROUPS; + if (gid_len + 1 > XU_NGROUPS) + xcr->cr_ngroups =3D XU_NGROUPS; else xcr->cr_ngroups =3D gid_len + 1; =20 diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/security/audit/audit.c ngroups/sys/s= ecurity/audit/audit.c --- /usr/src/sys/security/audit/audit.c 2009-04-24 10:41:08.000000000 -0500 +++ ngroups/sys/security/audit/audit.c 2009-06-05 15:33:54.000000000 -0500 @@ -224,7 +224,7 @@ cru2x(cred, &ar->k_ar.ar_subj_cred); ar->k_ar.ar_subj_ruid =3D cred->cr_ruid; ar->k_ar.ar_subj_rgid =3D cred->cr_rgid; - ar->k_ar.ar_subj_egid =3D cred->cr_groups[0]; + ar->k_ar.ar_subj_egid =3D cred->cr_gid; ar->k_ar.ar_subj_auid =3D cred->cr_audit.ai_auid; ar->k_ar.ar_subj_asid =3D cred->cr_audit.ai_asid; ar->k_ar.ar_subj_pid =3D td->td_proc->p_pid; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/security/audit/audit_arg.c ngroups/s= ys/security/audit/audit_arg.c --- /usr/src/sys/security/audit/audit_arg.c 2009-01-22 10:06:21.000000000 -= 0600 +++ ngroups/sys/security/audit/audit_arg.c 2009-06-05 15:33:54.000000000 -0= 500 @@ -369,7 +369,7 @@ cred =3D p->p_ucred; ar->k_ar.ar_arg_auid =3D cred->cr_audit.ai_auid; ar->k_ar.ar_arg_euid =3D cred->cr_uid; - ar->k_ar.ar_arg_egid =3D cred->cr_groups[0]; + ar->k_ar.ar_arg_egid =3D cred->cr_gid; ar->k_ar.ar_arg_ruid =3D cred->cr_ruid; ar->k_ar.ar_arg_rgid =3D cred->cr_rgid; ar->k_ar.ar_arg_asid =3D cred->cr_audit.ai_asid; diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/sys/syslimits.h ngroups/sys/sys/sysl= imits.h --- /usr/src/sys/sys/syslimits.h 2009-01-22 10:06:22.000000000 -0600 +++ ngroups/sys/sys/syslimits.h 2009-06-05 15:34:15.000000000 -0500 @@ -54,7 +54,7 @@ #define MAX_CANON 255 /* max bytes in term canon input line */ #define MAX_INPUT 255 /* max bytes in terminal input */ #define NAME_MAX 255 /* max bytes in a file name */ -#define NGROUPS_MAX 16 /* max supplemental group id's */ +#define NGROUPS_MAX 32767 /* max supplemental group id's */ #ifndef OPEN_MAX #define OPEN_MAX 64 /* max open files per process */ #endif diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/sys/ucred.h ngroups/sys/sys/ucred.h --- /usr/src/sys/sys/ucred.h 2009-06-05 15:33:54.000000000 -0500 +++ ngroups/sys/sys/ucred.h 2009-06-05 16:02:34.000000000 -0500 @@ -48,7 +48,7 @@ uid_t cr_uid; /* effective user id */ uid_t cr_ruid; /* real user id */ uid_t cr_svuid; /* saved user id */ - short cr_ngroups; /* number of groups */ + int cr_ngroups; /* number of groups */ gid_t cr_rgid; /* real group id */ gid_t cr_svgid; /* saved group id */ struct uidinfo *cr_uidinfo; /* per euid resource consumption */ @@ -61,7 +61,7 @@ struct label *cr_label; /* MAC label */ struct auditinfo_addr cr_audit; /* Audit properties. */ gid_t *cr_groups; /* groups */ - short cr_agroups; /* Available groups */ + int cr_agroups; /* Available groups */ }; #define NOCRED ((struct ucred *)0) /* no credential available */ #define FSCRED ((struct ucred *)-1) /* filesystem credential */ @@ -77,11 +77,9 @@ uid_t cr_uid; /* effective user id */ short cr_ngroups; /* number of groups */ gid_t cr_groups[XU_NGROUPS]; /* groups */ + void *_cr_unused1; /* compatibility with old ucred */ }; -#define XUCRED_VERSION 2 - -#define XUCRED_SIZE(n) \ - (sizeof(struct xucred) + (MAX((n)-XU_NGROUPS, 0) * sizeof(gid_t))) +#define XUCRED_VERSION 0 =20 /* This can be used for both ucred and xucred structures. */ #define cr_gid cr_groups[0] @@ -97,7 +95,7 @@ void change_svgid(struct ucred *newcred, gid_t svgid); void change_svuid(struct ucred *newcred, uid_t svuid); void crcopy(struct ucred *dest, struct ucred *src); -struct ucred *crcopysafe(struct proc *, struct ucred *); +struct ucred *crcopysafe(struct proc *p, struct ucred *cr); struct ucred *crdup(struct ucred *cr); void cred_update_thread(struct thread *td); void crfree(struct ucred *cr); @@ -106,6 +104,7 @@ int crshared(struct ucred *cr); void cru2x(struct ucred *cr, struct xucred *xcr); void crextend(struct ucred *cr, int n); +void crsetgroups(struct ucred *cr, int n, gid_t *groups); int groupmember(gid_t gid, struct ucred *cred); #endif /* _KERNEL */ =20 Only in /usr/src/sys/sys: ucred.h.orig Only in /usr/src/sys/sys: user.h.diff Only in /usr/src/sys/sys: user.h.orig Only in /usr/src/sys/sys: user.h.rej.orig diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/sys/ufs/ufs/ufs_vnops.c ngroups/sys/ufs/= ufs/ufs_vnops.c --- /usr/src/sys/ufs/ufs/ufs_vnops.c 2009-06-05 15:33:49.000000000 -0500 +++ ngroups/sys/ufs/ufs/ufs_vnops.c 2009-06-05 16:02:28.000000000 -0500 @@ -1475,7 +1475,7 @@ refcount_init(&ucred.cr_ref, 1); ucred.cr_uid =3D ip->i_uid; ucred.cr_ngroups =3D 1; - ucred.cr_groups[0] =3D dp->i_gid; + ucred.cr_gid =3D dp->i_gid; ucp =3D &ucred; } #endif @@ -2266,6 +2266,7 @@ { #ifdef QUOTA struct ucred ucred, *ucp; + gid_t ucred_group; ucp =3D cnp->cn_cred; #endif /* @@ -2292,7 +2293,8 @@ refcount_init(&ucred.cr_ref, 1); ucred.cr_uid =3D ip->i_uid; ucred.cr_ngroups =3D 1; - ucred.cr_groups[0] =3D pdir->i_gid; + ucred.cr_groups =3D &ucred_group; + ucred.cr_gid =3D pdir->i_gid; ucp =3D &ucred; #endif } else { diff -ru --exclude=3D'.glimpse*' --exclude=3D.svn --exclude=3Dcompile --ign= ore-matching=3D'$FreeBSD' /usr/src/usr.sbin/mountd/mountd.c ngroups/usr.sbi= n/mountd/mountd.c --- /usr/src/usr.sbin/mountd/mountd.c 2009-05-29 12:47:59.000000000 -0500 +++ ngroups/usr.sbin/mountd/mountd.c 2009-05-28 17:11:49.000000000 -0500 @@ -174,7 +174,7 @@ int do_mount(struct exportlist *, struct grouplist *, int, struct xucred *, char *, int, struct statfs *); int do_opt(char **, char **, struct exportlist *, struct grouplist *, - int *, int *, struct xucred **); + int *, int *, struct xucred *); struct exportlist *ex_search(fsid_t *); struct exportlist *get_exp(void); void free_dir(struct dirlist *); @@ -196,7 +196,7 @@ void mntsrv(struct svc_req *, SVCXPRT *); void nextfield(char **, char **); void out_of_mem(void); -void parsecred(char *, struct xucred **); +void parsecred(char *, struct xucred *); int put_exlist(struct dirlist *, XDR *, struct dirlist *, int *, int); void *sa_rawaddr(struct sockaddr *sa, int *nbytes); int sacmp(struct sockaddr *sa1, struct sockaddr *sa2, @@ -221,6 +221,7 @@ (uid_t)-2, 1, { (gid_t)-2 }, + NULL }; int force_v2 =3D 0; int resvport_only =3D 1; @@ -1167,7 +1168,7 @@ struct exportlist **epp; struct dirlist *dirhead; struct statfs fsb; - struct xucred *anon; + struct xucred anon; char *cp, *endcp, *dirp, *hst, *usr, *dom, savedc; int len, has_host, exflags, got_nondir, dirplen, netgrp; =20 @@ -1185,7 +1186,7 @@ * Set defaults. */ has_host =3D FALSE; - anon =3D &def_anon; + anon =3D def_anon; exflags =3D MNT_EXPORTED; got_nondir =3D 0; opt_flags =3D 0; @@ -1403,7 +1404,7 @@ */ grp =3D tgrp; do { - if (do_mount(ep, grp, exflags, anon, dirp, dirplen, + if (do_mount(ep, grp, exflags, &anon, dirp, dirplen, &fsb)) { getexp_err(ep, tgrp); goto nextline; @@ -1956,7 +1957,7 @@ struct grouplist *grp; int *has_hostp; int *exflagsp; - struct xucred **cr; + struct xucred *cr; { char *cpoptarg, *cpoptend; char *cp, *endcp, *cpopt, savedc, savedc2; @@ -2420,33 +2421,6 @@ return (ret); } =20 -static void -xcr_grow(struct xucred **cr, int *cr_ngroups, int desired_groups) -{ - struct xucred *in =3D *cr, *out; - int n; - - if (in && *cr_ngroups > desired_groups) - return; - - n =3D MAX(XU_NGROUPS, *cr_ngroups); - while (n < desired_groups) - n *=3D 2; - - out =3D malloc(XUCRED_SIZE(n)); - if (out =3D=3D NULL) - out_of_mem(); - - if (in) { - memcpy(out, in, XUCRED_SIZE(*cr_ngroups)); - if (in !=3D &def_anon) - free(in); - } - - *cr =3D out; - *cr_ngroups =3D n; -} - /* * Translate a net address. * @@ -2654,20 +2628,18 @@ * Parse a description of a credential. */ void -parsecred(namelist, cr_out) +parsecred(namelist, cr) char *namelist; - struct xucred **cr_out; + struct xucred *cr; { char *name; + int cnt; char *names; struct passwd *pw; struct group *gr; + gid_t groups[NGRPS + 1]; int ngroups; - struct xucred *cr =3D NULL; - int cr_ngroups =3D 0; - int error; =20 - xcr_grow(&cr, &cr_ngroups, 0); cr->cr_version =3D XUCRED_VERSION; /* * Set up the unprivileged user. @@ -2690,20 +2662,20 @@ if (names =3D=3D NULL) { if (pw =3D=3D NULL) { syslog(LOG_ERR, "unknown user: %s", name); - goto out; + return; } cr->cr_uid =3D pw->pw_uid; - for (;;) { - ngroups =3D cr_ngroups; - error =3D getgrouplist(pw->pw_name, pw->pw_gid, - cr->cr_groups, &ngroups); - if (!error) - break; - xcr_grow(&cr, &cr_ngroups, ngroups); - } - cr->cr_ngroups =3D ngroups; - - goto out; + ngroups =3D NGRPS + 1; + if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups)) + syslog(LOG_ERR, "too many groups"); + /* + * Compress out duplicate. + */ + cr->cr_ngroups =3D ngroups - 1; + cr->cr_groups[0] =3D groups[0]; + for (cnt =3D 2; cnt < ngroups; cnt++) + cr->cr_groups[cnt - 1] =3D groups[cnt]; + return; } /* * Explicit credential specified as a colon separated list: @@ -2715,11 +2687,10 @@ cr->cr_uid =3D atoi(name); else { syslog(LOG_ERR, "unknown user: %s", name); - goto out; + return; } cr->cr_ngroups =3D 0; - while (names !=3D NULL && *names !=3D '\0') { - xcr_grow(&cr, &cr_ngroups, cr->cr_ngroups + 1); + while (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups < NGRPS) { name =3D strsep(&names, ":"); if (isdigit(*name) || *name =3D=3D '-') { cr->cr_groups[cr->cr_ngroups++] =3D atoi(name); @@ -2731,9 +2702,8 @@ cr->cr_groups[cr->cr_ngroups++] =3D gr->gr_gid; } } - - out: - *cr_out =3D cr; + if (names !=3D NULL && *names !=3D '\0' && cr->cr_ngroups =3D=3D NGRPS) + syslog(LOG_ERR, "too many groups"); } =20 #define STRSIZ (RPCMNT_NAMELEN+RPCMNT_PATHLEN+50) --sdtB3X0nJg68CQEu-- --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKKZ3zXY6L6fI4GtQRAmZIAJ9vmvoOMbiS30WRBzsHqpjAx+fdMQCg21bB l7/uY3WXqja2MHK21xWk4a4= =acSA -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 01:47:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F0FC106566B for ; Sat, 6 Jun 2009 01:47:48 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 456C48FC08 for ; Sat, 6 Jun 2009 01:47:48 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 112EC6D418 for ; Sat, 6 Jun 2009 03:31:23 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9559F844CC; Sat, 6 Jun 2009 03:32:02 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: current@freebsd.org Date: Sat, 06 Jun 2009 03:32:01 +0200 Message-ID: <86skief8q6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: LOR between NFS and syncer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 01:47:48 -0000 Anyone seen this one before? NFS+ZFS server, diskless NFS client. Both run head. On the client: lock order reversal: 1st 0xc301c164 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 2nd 0xc322c058 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c07477c6,c2bbfa18,c05921c5,c058310b,c074a615,...) at = db_trace_self_wrapper+0x26 kdb_backtrace(c058310b,c074a615,c2cb0828,c2cb0688,c2bbfa74,...) at kdb_back= trace+0x29 _witness_debugger(c074a615,c322c058,c0759e62,c2cb0688,c0750f5e,...) at _wit= ness_debugger+0x25 witness_checkorder(c322c058,9,c0750f5e,823,0,...) at witness_checkorder+0x8= 39 __lockmgr_args(c322c058,80500,c322c074,0,0,...) at __lockmgr_args+0x797 vop_stdlock(c2bbfb88,c2bbfb70,c0591f6b,c0750f5e,c073ced7,...) at vop_stdloc= k+0x62 VOP_LOCK1_APV(c079d720,c2bbfb88,c0750f5e,c07b5100,c322c000,...) at VOP_LOCK= 1_APV+0xf3 _vn_lock(c322c000,80500,c0750f5e,823,df,...) at _vn_lock+0x5e vget(c322c000,80500,c2f1f480,c6e,c2f35c94,...) at vget+0xb9 vfs_msync(c2f35c94,2,c0750f5e,d67,c2f35c94,...) at vfs_msync+0xe7 sync_fsync(c2bbfc7c,c301c10c,80400,c0750f5e,69d,...) at sync_fsync+0x17b VOP_FSYNC_APV(c07975c0,c2bbfc7c,c0750f5e,69d,c2f1f480,...) at VOP_FSYNC_APV= +0xda sync_vnode(c093d8f0,c093d8dc,3e8,6cc,4e20,...) at sync_vnode+0x168 sched_sync(0,c2bbfd38,c073fcec,334,c2ceea90,...) at sched_sync+0x273 fork_exit(c05d8570,0,c2bbfd38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc2bbfd70, ebp =3D 0 --- DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 01:47:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D303C1065731; Sat, 6 Jun 2009 01:47:57 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 048F38FC08; Sat, 6 Jun 2009 01:47:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n561lmGX014794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 11:47:48 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n561llld004385; Sat, 6 Jun 2009 11:47:47 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n561ljFw004384; Sat, 6 Jun 2009 11:47:45 +1000 (EST) (envelope-from peter) Date: Sat, 6 Jun 2009 11:47:45 +1000 From: Peter Jeremy To: Scott Long Message-ID: <20090606014745.GC9161@server.vk2pj.dyndns.org> References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <4A2956C6.5070902@samsco.org> <4A29694B.2090606@elischer.org> <4A297187.2090701@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qbvjkv9qwOGw/5Fx" Content-Disposition: inline In-Reply-To: <4A297187.2090701@samsco.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Alexander Motin , FreeBSD Current , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 01:47:58 -0000 --Qbvjkv9qwOGw/5Fx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jun-05 13:27:03 -0600, Scott Long wrote: >Every one of Matt's emails follow this formula: > >1. I don't know how FOO works, but how you're doing it is wrong >2. Here's how I think FOO should work >3. I'm going to work on FOO in DragonFlyBSD and have it done in a week. > >1 and 2 are ignorant and worthless in a technical conversation, and 3 is= =20 >off topic for FreeBSD mailing lists. So yes, I'm calling him out. Well, I have seen little evidence of 1. 2 _can_ be relevant in an architectural discussion. 3 may or may not be relevant - it depends whether FreeBSD can make use of the work or not. I agree with Julian that you are being unnecessarily provocative. IMHO, Matt has made a positive contribution to this thread. Rather than quoting him out of context, how about you take a chill pill and consider what benefits FreeBSD can gain by reusing work done by other free Unices. --=20 Peter Jeremy --Qbvjkv9qwOGw/5Fx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkopysEACgkQ/opHv/APuIcfMgCfQtuur3fxxWJA5Y/e5TUkr5JV CBMAoITs7gvN+hV225NiNxgtdqa+dE7W =X5V5 -----END PGP SIGNATURE----- --Qbvjkv9qwOGw/5Fx-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 02:45:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D678B106566B for ; Sat, 6 Jun 2009 02:45:56 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9528FC0A for ; Sat, 6 Jun 2009 02:45:56 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: by fxm7 with SMTP id 7so1464217fxm.43 for ; Fri, 05 Jun 2009 19:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:subject:message-id :mime-version:content-type:content-disposition:user-agent; bh=wAIpJ+MZZhUSsJqN9MZESzB9Aa5TqJrunj5X7ItD5e4=; b=T6XdwjK4+slJAi5KwS6PwA8flTb4a/pvb5QXbqK+2tXhh+EtBTZ+PxMfh1x94dwpLq +O3aBftg2/l0YeOwcPaaZygY0W9ZHU/eQajcNop61pZQ0sVxWBsgxhyFKcDiGVK8tpqH NzAuB+eNJH/Aza0Ez8rz227wsoHoD2eR9Fbo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id :mime-version:content-type:content-disposition:user-agent; b=hUvIF4ZvzfFBTwphr5yRNtPlmZ1ocn5oLXbavevRksWNQPPcA63x0W5e7LkY3sjgI0 Dm4MU/uLK0nqbBZ7suAsPn84fEol3FdMiGsZfY1LLEgARtM5e0X/RsxC+Qx+HA1VZIyr TqFuv6KvcmnUeaISGTRQgSpGJfX5szuMQtFbw= Received: by 10.204.116.8 with SMTP id k8mr3814255bkq.117.1244254731284; Fri, 05 Jun 2009 19:18:51 -0700 (PDT) Received: from darklight.homeunix.org ([85.175.193.190]) by mx.google.com with ESMTPS id e17sm538863fke.48.2009.06.05.19.18.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 19:18:50 -0700 (PDT) Received: from darklight.homeunix.org (darklight.homeunix.org [127.0.0.1]) by darklight.homeunix.org (8.14.3/8.14.3) with ESMTP id n562IZPZ001150 for ; Sat, 6 Jun 2009 06:18:36 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.homeunix.org (8.14.3/8.14.3/Submit) id n562IZPu001149 for freebsd-current@freebsd.org; Sat, 6 Jun 2009 06:18:35 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.homeunix.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 6 Jun 2009 06:18:35 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20090606021835.GC1077@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: loader panics with 2 GPT partitioned drives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 02:45:57 -0000 Hi, I'm getting the following "panic" from loader when trying to attach another GPT partitioned drive. loader is built using LOADER_ZFS_SUPPORT. BTX Loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive C: is disk0 BIOS drive D: is disk1 panic:free: guard1 fail @ 0x7fd4b3f4 from /usr/src/sys/boot/i386/libi386/biosdisk.c:1048 ad4: => 34 488397101 ad4 GPT (233G) 34 128 1 freebsd-boot (64K) 162 16777216 2 freebsd-swap (8.0G) 16777378 471619757 3 freebsd-zfs (225G) ad10: empty disk, `gpart create -s GPT ad10` Yuri From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 03:02:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD50B106564A; Sat, 6 Jun 2009 03:02:16 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by mx1.freebsd.org (Postfix) with ESMTP id 70A7C8FC08; Sat, 6 Jun 2009 03:02:16 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: by pzk33 with SMTP id 33so1781624pzk.3 for ; Fri, 05 Jun 2009 20:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:to:cc :subject:from:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=0DGeYHBbCTdFSCTOpiLVURtKHZZ5eZUsM4yTLcsT2zA=; b=cY4hKZk3LF0Li0YB5s7G1rxHF943dvbewYsuOF1fyJ5f9/TtTBXuBCLTYnEv56qrsJ nz3Ib+8oMaXJp4ErPB9SISFOqNFWkVT2YKmsv44Q6zpJqdU+zg14VzJCfZZ5jCw7PzjS ikl+slA1/FJAQ3OThKKiEKcvHdA1ItXIuAYNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:to:cc:subject:from:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=Ry1no9p67TxnSOcAUTpb/UFGsKfzoWqPye6UV/+B/neHZFy4NmJFNO0GNjFM0+JvXX bf5qrwmzEFq5UZ2WiKHDfPRkpnop9+2AiVnaCZYaoJPoNCPSMOE7e4ceNNB6kI94iWee huXnnY0GLZcvc2O2TVBkGkSxhNhMOKI0qSR68= Received: by 10.143.41.5 with SMTP id t5mr1622571wfj.134.1244257335928; Fri, 05 Jun 2009 20:02:15 -0700 (PDT) Received: from localhost (rikad42.riken.jp [134.160.214.42]) by mx.google.com with ESMTPS id 22sm2246016wfg.27.2009.06.05.20.02.12 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 20:02:14 -0700 (PDT) Sender: Maho NAKATA Date: Sat, 06 Jun 2009 12:00:01 +0900 (JST) Message-Id: <20090606.120001.68053946.chat95@mac.com> To: miwi@FreeBSD.org From: Maho NAKATA In-Reply-To: <20090527134343.GB1104@bsdcrew.de> References: <20090527134343.GB1104@bsdcrew.de> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun__6_12_00_01_2009_679)--" Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 03:02:17 -0000 ----Security_Multipart(Sat_Jun__6_12_00_01_2009_679)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I did a benchmark with Virtualbox: My environment: * Core 2 Quad, Q6600@3GHz * Windows XP SP3@host SP2@VBOX with GuestAddon * http://crystalmark.info/software/CrystalMark/ CrystalMark 2004R3 * Sapphire X1650 * VBOX is running on FBSD7.2-REL/amd64 using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz * Running with fullscreen mode 1280x1024 32bit Here is the result ----------------------------------------- host(4CPU) host(1CPU) vbox(1CPU) Mark 173047 90925 86496 ALU 50985 13493 13060 FPU 63746 15126 15323 MEM 21822 25582 16516 HDD 9336 9331 30600(*) GDI 15153 15195 5127 D2D 5997 5998 5108 OGL 6200 6200 762 ----------------------------------------- (*)somehow lot faster I don't know how to use two CPUs, even changing setting doesn't change. Usually I cannot usually launch VirtualBox even by root. A workaround is that invoking and killing VirtualBox many times for me. After some tries I can launch... thanks From: Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 Date: Wed, 27 May 2009 15:43:43 +0200 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Howdy, > > First of all sorry for all unanswered mails, I got a stupid flu, > but now i feel better... ok now back to vbox, time for a new call > for testing :-) > > Following was added/fixed: > > - - ACPI Support was added > - - hostDVD support was added > - - Fix startup on HEAD > - - Plist problem under AMD64 was fixed > - - Qt4 Frontend is now Optional > - - Desktop file was added > - - Xorg dependencies was fixed > - - Guest additions was added (thx to Maho NAKATA ) > > Open task: > We have got 2 patches for nls support and the request > to make dbus and pulseaudio optional. These both will > be added with the next run. > > We'd like to say many many thanks for all your feedback. > > http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz > > Happy Testing :-) > > > > - -- > > +-----------------------+-------------------------------+ > | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | > | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | > +-----------------------+-------------------------------+ > | Mess with the Best, Die like the Rest! | > +-----------------------+-------------------------------+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAkodQ48ACgkQdLJIhLHm/OmjfQCfR6Zczz0XcZZpAYie64D2G0Ti > wwQAn2r0W/12iidjOfgvX05QPNQX1oUc > =b8tt > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > ----Security_Multipart(Sat_Jun__6_12_00_01_2009_679)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkop27EACgkQpcQqaPiEzfnsoQCgrHkEbRFw5AcM8QL0iR1uttie gm4AnjFEeOTexD/TC3tDzlDnUqgSnUvV =roNZ -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun__6_12_00_01_2009_679)---- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 03:53:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 610D21065673 for ; Sat, 6 Jun 2009 03:53:15 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 395AF8FC15 for ; Sat, 6 Jun 2009 03:53:15 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 8A77271F43D; Fri, 5 Jun 2009 23:53:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrqBF1eT0xVk; Fri, 5 Jun 2009 23:53:14 -0400 (EDT) Received: from [35.9.33.66] (unknown [35.9.33.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 0D4FC71F43C; Fri, 5 Jun 2009 23:53:13 -0400 (EDT) Message-ID: <4A29E825.3010100@egr.msu.edu> Date: Fri, 05 Jun 2009 23:53:09 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: current@freebsd.org, dfr@rabson.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Possible to boot using gptzfsboot and a 'raid 10' in ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 03:53:15 -0000 Should it be possible to boot from zpool consisting of a striped set of mirrors using gptzfsboot? Using a FreeBSD 7.2 post-v13 ZFS cd or the 200905 8.0 snapshot, neither let me set the bootfs zpool property to a pool that is a 8 disk mirror. If I manage to get zpool to let me set it, will gptzfsboot work with it anyway? Knowing that gptzfsboot can boot from a single disk, mirror, raidz, and raidz2, it didn't enter my mind that a raid10 might not work until I just tried it tonight. Thanks for input. Also thanks for the existing code! From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 05:46:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29852106564A for ; Sat, 6 Jun 2009 05:46:08 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id 00E578FC1B for ; Sat, 6 Jun 2009 05:46:07 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 1F94E71F2D4; Sat, 6 Jun 2009 01:46:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJV3AKHy6Xsv; Sat, 6 Jun 2009 01:46:06 -0400 (EDT) Received: from [35.9.33.66] (unknown [35.9.33.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id D85C471F2D1; Sat, 6 Jun 2009 01:46:06 -0400 (EDT) Message-ID: <4A2A029E.50407@egr.msu.edu> Date: Sat, 06 Jun 2009 01:46:06 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: current@freebsd.org, dfr@rabson.org References: <4A29E825.3010100@egr.msu.edu> In-Reply-To: <4A29E825.3010100@egr.msu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Possible to boot using gptzfsboot and a 'raid 10' in ZFS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 05:46:08 -0000 Adam McDougall wrote: > Should it be possible to boot from zpool consisting of a striped set > of mirrors using gptzfsboot? Using a FreeBSD 7.2 post-v13 ZFS cd or > the 200905 8.0 snapshot, neither let me set the bootfs zpool property > to a pool that is a 8 disk mirror. If I manage to get zpool to let me > set it, will gptzfsboot work with it anyway? Knowing that gptzfsboot > can boot from a single disk, mirror, raidz, and raidz2, it didn't > enter my mind that a raid10 might not work until I just tried it > tonight. Thanks for input. Also thanks for the existing code! > _______________________________________________ > 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" > Oops sorry, the answer is probably in this mail below, I didn't realize it was so recent. I'm not in a rush since most of my systems will be a standard mirror which I already know works. Date: 05/27/09 From: Doug Rabson ... This is a limitation which I will remove as soon as I have a little time to work on it. ... I will simply remove this limitation for FreeBSD since we can now boot from any pool configuration. From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 06:44:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AB361065670 for ; Sat, 6 Jun 2009 06:44:34 +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 18B318FC17 for ; Sat, 6 Jun 2009 06:44:33 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n566iO5b036061; Sat, 6 Jun 2009 00:44:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A2A1048.5090101@samsco.org> Date: Sat, 06 Jun 2009 00:44:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Maho NAKATA References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> In-Reply-To: <20090606.120001.68053946.chat95@mac.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, miwi@freebsd.org Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 06:44:34 -0000 Maho NAKATA wrote: > I did a benchmark with Virtualbox: > > My environment: > * Core 2 Quad, Q6600@3GHz > * Windows XP SP3@host SP2@VBOX with GuestAddon > * http://crystalmark.info/software/CrystalMark/ > CrystalMark 2004R3 > * Sapphire X1650 > * VBOX is running on FBSD7.2-REL/amd64 > using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz > * Running with fullscreen mode 1280x1024 32bit > Here is the result > ----------------------------------------- > host(4CPU) host(1CPU) vbox(1CPU) > Mark 173047 90925 86496 > ALU 50985 13493 13060 > FPU 63746 15126 15323 > MEM 21822 25582 16516 > HDD 9336 9331 30600(*) > GDI 15153 15195 5127 > D2D 5997 5998 5108 > OGL 6200 6200 762 > ----------------------------------------- > (*)somehow lot faster > > I don't know how to use two CPUs, even changing setting > doesn't change. > > Usually I cannot usually launch VirtualBox even by root. > A workaround is that invoking and killing VirtualBox > many times for me. After some tries I can launch... > > thanks > I take it that you're running freebsd on the "bare metal" in your 4CPU and 1CPU tests, and running WinXP on the bare metal in the vbox test? If so, are you using ATA disks and the ATA driver for all instances of FreeBSD? If so, then the lack of NCQ in the FreeBSD ATA driver would explain the HDD test result. I see similar results with VMWare. Scott From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 07:39:08 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9992106564A; Sat, 6 Jun 2009 07:39:08 +0000 (UTC) (envelope-from yamagi@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5788FC14; Sat, 6 Jun 2009 07:39:08 +0000 (UTC) (envelope-from yamagi@yamagi.org) Received: from localhost (unknown [10.0.0.3]) by mail.yamagi.org (Postfix) with ESMTP id 5AA0A1083DE3; Sat, 6 Jun 2009 09:20:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at yamagi.org Received: from mail.yamagi.org ([10.0.0.3]) by localhost (mail.yamagi.org [10.0.0.3]) (amavisd-new, port 10024) with LMTP id br7Od+9rHjG2; Sat, 6 Jun 2009 09:20:43 +0200 (CEST) Received: from screw.home.yamagi.org (f054145095.adsl.alicedsl.de [78.54.145.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id AF8571083DE4; Sat, 6 Jun 2009 09:20:43 +0200 (CEST) Received: from screw.home.yamagi.org (localhost [127.0.0.1]) by screw.home.yamagi.org (8.14.3/8.14.3) with ESMTP id n567KgGL001700; Sat, 6 Jun 2009 09:20:42 +0200 (CEST) (envelope-from yamagi@screw.home.yamagi.org) Received: (from yamagi@localhost) by screw.home.yamagi.org (8.14.3/8.14.3/Submit) id n567KgId001699; Sat, 6 Jun 2009 09:20:42 +0200 (CEST) (envelope-from yamagi) Date: Sat, 6 Jun 2009 09:20:42 +0200 From: Yamagi Burmeister To: Maho NAKATA Message-ID: <20090606072041.GC1581@yamagi.org> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20090606.120001.68053946.chat95@mac.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 07:39:09 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, > Usually I cannot usually launch VirtualBox even by root. > A workaround is that invoking and killing VirtualBox > many times for me. After some tries I can launch... maybe this workaround helps (as user, not as root): 1. Launch VirtualBox. 2. If it fails open top(1) 3. In top(1) you should see 2(!) processes "VirtualBox" 4. Kill one of them 5. The other one should start This works for me in 9 out of 10 times and is much more comfortable than killing and restarting the whole programm many times. --=20 Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoqGMgACgkQWTjlg++8y8tMXQCeKHj5q8fATkYOUpT/ls73VUJF ANoAoL+CdKk5fQO0F07UXGMxoAafJhKu =MjZy -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 09:14:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 215DE1065676; Sat, 6 Jun 2009 09:14:04 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by mx1.freebsd.org (Postfix) with ESMTP id D08F58FC0A; Sat, 6 Jun 2009 09:14:03 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: by pzk33 with SMTP id 33so1876653pzk.3 for ; Sat, 06 Jun 2009 02:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:to:cc :subject:from:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=HWFIB+50Vw0kjYSYeTjPpjrWn7rBr0HIMb9HanON41Y=; b=qiVMnsasbcVmn1K38wK6dz1//a6Qn6S3wBmgNrasJ2HDN+oPHXcoAQAI8kXQzPlXnq rsLzmE3h5Erhl/xC3iIZyey1Y7gHZbQj0FLzImWGau7Lbet9G2+PQ/BUkDo7RG1GlcBi qPpC+aZQbrziBFZwmqlRqUrqPXR4KGte1z034= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:to:cc:subject:from:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=HK4RgcEdnooSt77ehiQTp02kAZY/ymnZY3WBabzJNaFVtsEKKvAHyLWgIYMQDWMAew jBLs1VFB+ZBu9ZJF54LKcupDt0s9LbFPaxO6byIzgH7D0nJi79gwIYPcXl/8GDWd7hEm SJG68tkr8uX94QV15A82yg7YC63Gxutk2AV0o= Received: by 10.143.4.11 with SMTP id g11mr1637573wfi.340.1244279643586; Sat, 06 Jun 2009 02:14:03 -0700 (PDT) Received: from localhost (rikad42.riken.jp [134.160.214.42]) by mx.google.com with ESMTPS id 30sm2859893wfd.1.2009.06.06.02.14.01 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Jun 2009 02:14:02 -0700 (PDT) Sender: Maho NAKATA Date: Sat, 06 Jun 2009 18:11:44 +0900 (JST) Message-Id: <20090606.181144.193792508.chat95@mac.com> To: lists@yamagi.org From: Maho NAKATA In-Reply-To: <20090606072041.GC1581@yamagi.org> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <20090606072041.GC1581@yamagi.org> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun__6_18_11_44_2009_720)--" Content-Transfer-Encoding: 7bit Cc: ports@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Two VirtualBox processes and do not launch VirtualBox: kill one of them. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 09:14:04 -0000 ----Security_Multipart(Sat_Jun__6_18_11_44_2009_720)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Yamagi Burmeister Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 09:20:42 +0200 > Hello, > >> Usually I cannot usually launch VirtualBox even by root. >> A workaround is that invoking and killing VirtualBox >> many times for me. After some tries I can launch... > > maybe this workaround helps (as user, not as root): > 1. Launch VirtualBox. > 2. If it fails open top(1) > 3. In top(1) you should see 2(!) processes "VirtualBox" > 4. Kill one of them > 5. The other one should start > This works for me in 9 out of 10 times and is much more comfortable > than killing and restarting the whole programm many times. Hi Yamagi-san, This workaround works well for me. Many thanks!! Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt ----Security_Multipart(Sat_Jun__6_18_11_44_2009_720)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoqMtMACgkQpcQqaPiEzfnrFQCdGJawvupcWuyKWfzV2qUVbDel JqsAoIU59BPD1U11gGC49z9mWTpKJp0u =tctN -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun__6_18_11_44_2009_720)---- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 09:15:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 003DB1065672; Sat, 6 Jun 2009 09:15:17 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id A9E048FC15; Sat, 6 Jun 2009 09:15:17 +0000 (UTC) (envelope-from maho.nakata@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so799344wfg.7 for ; Sat, 06 Jun 2009 02:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:message-id:to:cc :subject:from:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=5wzLb/E3IzExudPenmjrJhd0QrHBDS6gCQr3ebEX82c=; b=AwGSsnPpJkbrywAX+oWGYZ1j3aCWavz+3fv97ZS7M5W8uo/F2UEZm2ToQO4BsuIwaF ZMxhZHiLzg9/vvqLZBb2VcV2ae99BPoSEYOT0FXGFIgqrn1kUE3PSIMASn66gR0x9eCS wMN2M4n9ExcWzrwZuC4wuMs9YbcEQCxMfKw8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:message-id:to:cc:subject:from:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=b5RYy8K4sQCd41rhpOby30Ac2u/3fRl+UUuFwiLZYlFQu82DyapWYx+Iv0Z4QTyAhc yznGCZnL2wV5RhNY/gIqlSmLsyARfwBgjqCc2A+am5BS0MnZU1AJj9ZPkorrvt2/mKw+ 5bQpijJlrlDfbTEj9Wsf5jyF51ELpRdI+MId4= Received: by 10.142.57.19 with SMTP id f19mr1595254wfa.80.1244279716876; Sat, 06 Jun 2009 02:15:16 -0700 (PDT) Received: from localhost (rikad42.riken.jp [134.160.214.42]) by mx.google.com with ESMTPS id 9sm2844245wfc.16.2009.06.06.02.15.14 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Jun 2009 02:15:15 -0700 (PDT) Sender: Maho NAKATA Date: Sat, 06 Jun 2009 18:13:02 +0900 (JST) Message-Id: <20090606.181302.112520754.chat95@mac.com> To: scottl@samsco.org From: Maho NAKATA In-Reply-To: <4A2A1048.5090101@samsco.org> References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <4A2A1048.5090101@samsco.org> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Jun__6_18_13_02_2009_790)--" Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, miwi@freebsd.org Subject: Re: Benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 09:15:18 -0000 ----Security_Multipart(Sat_Jun__6_18_13_02_2009_790)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Scott Long Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for FreeBSD! take 4] Date: Sat, 06 Jun 2009 00:44:24 -0600 > Maho NAKATA wrote: >> I did a benchmark with Virtualbox: >> My environment: >> * Core 2 Quad, Q6600@3GHz >> * Windows XP SP3@host SP2@VBOX with GuestAddon >> * http://crystalmark.info/software/CrystalMark/ >> CrystalMark 2004R3 >> * Sapphire X1650 >> * VBOX is running on FBSD7.2-REL/amd64 >> using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz >> * Running with fullscreen mode 1280x1024 32bit >> Here is the result >> ----------------------------------------- >> host(4CPU) host(1CPU) vbox(1CPU) >> Mark 173047 90925 86496 >> ALU 50985 13493 13060 >> FPU 63746 15126 15323 >> MEM 21822 25582 16516 >> HDD 9336 9331 30600(*) >> GDI 15153 15195 5127 >> D2D 5997 5998 5108 >> OGL 6200 6200 762 >> ----------------------------------------- >> (*)somehow lot faster >> I don't know how to use two CPUs, even changing setting >> doesn't change. >> Usually I cannot usually launch VirtualBox even by root. >> A workaround is that invoking and killing VirtualBox >> many times for me. After some tries I can launch... >> thanks >> > > I take it that you're running freebsd on the "bare metal" in your 4CPU > and 1CPU tests, and running WinXP on the bare metal in the vbox test? yes. > If so, are you using ATA disks and the ATA driver for all instances I use SATA for host machine and ATA as VirtualBox machine. > of FreeBSD? If so, then the lack of NCQ in the FreeBSD ATA driver > would > explain the HDD test result. I see similar results with VMWare. Ok, I see Thanks for your clarification. Best, -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt ----Security_Multipart(Sat_Jun__6_18_13_02_2009_790)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkoqMx8ACgkQpcQqaPiEzfkrOgCgoX2M0uFQT2mEjlEXripJL0ag EZYAn2nm+TJ6g6DOYfuvZ5OdfW+4BVm/ =Qw5Z -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Jun__6_18_13_02_2009_790)---- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 09:36:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 548E41065672 for ; Sat, 6 Jun 2009 09:36:42 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by mx1.freebsd.org (Postfix) with ESMTP id E914E8FC0A for ; Sat, 6 Jun 2009 09:36:41 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm10 with SMTP id 10so27416fxm.43 for ; Sat, 06 Jun 2009 02:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.72.129 with SMTP id m1mr4152708bkj.61.1244280999284; Sat, 06 Jun 2009 02:36:39 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Jun 2009 11:36:39 +0200 Message-ID: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> From: Olivier SMEDTS To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 09:36:42 -0000 2009/5/4 Eygene Ryabinkin : > Good day. > > Recently I had filed a PR, > =A0http://www.freebsd.org/cgi/query-pr.cgi?pr=3D134192 > that should heal the situation when estX isn't attached properly > on the half of processor cores (the odd ones). =A0I am seeing this > only on Asus MBs, but this could show up on other hardware as well. > > If anyone sees such symptoms, I encourage them to test the patch. > The patch itself contained in the PR, but for ease I had put it > there, > =A0http://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.d= iff > and will sync PR's one and this one in the case of any changes. Hello, Your patch was working great on my Asus P5Q3. But the problem has been solved more permanently on -CURRENT with the import of ACPICA 20090521 (r193529-193531). Thanks ! > -- > Eygene > =A0_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___ =A0 =A0 =A0 _.--. =A0 # > =A0\`.|\..----...-'` =A0 `-._.-'_.-'` =A0 # =A0Remember that it is hard > =A0/ =A0' ` =A0 =A0 =A0 =A0 , =A0 =A0 =A0 __.--' =A0 =A0 =A0# =A0to read = the on-line manual > =A0)/' _/ =A0 =A0 \ =A0 `-_, =A0 / =A0 =A0 =A0 =A0 =A0 =A0# =A0while sing= le-stepping the kernel. > =A0`-'" `"\_ =A0,_.-;_.-\_ ', =A0fsc/as =A0 # > =A0 =A0 _.-'_./ =A0 {_.' =A0 ; / =A0 =A0 =A0 =A0 =A0 # =A0 =A0-- FreeBSD = Developers handbook > =A0 =A0{_.-``-' =A0 =A0 =A0 =A0 {_/ =A0 =A0 =A0 =A0 =A0 =A0# > _______________________________________________ > 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 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 09:41:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D71D106566B for ; Sat, 6 Jun 2009 09:41:01 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.99]) by mx1.freebsd.org (Postfix) with ESMTP id 615688FC0A for ; Sat, 6 Jun 2009 09:41:00 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail51.abv.bg (mail51.ni.bg [192.168.151.12]) by smtp-out.abv.bg (Postfix) with ESMTP id 7199E14EBA2; Sat, 6 Jun 2009 12:40:34 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=LG8hI0rl2UlcbjjsEpwoOB7iN22JP2lc2+eX0yq1cW+xnrVfiaxXimnt17prp2Nx4 OX2OCQc2ROy08UVBomnMH6qTy+07WYzYE/q1TYUAbErHtJtoYwRnLsvn+ZXRH1/+a5c +uiGd7rP/HlxtdpTY6uEIpt8vF/mKI3uTlegudc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1244281234; bh=3HsgXucuAVHokO2A/GQBTX8Mx+R3t7LTLkZFSDhufeg=; h=Date:From:To:Cc:Message-ID:Subject:MIME-Version:Content-Type: DKIM; b=CjH9hjNNe7weRt1Xm609t36yFjvQ9TQi4NkIEh5wP4JxeNB6wzvvOzxxSx T07z6YZY2YvpCo67XQV66YPuE1Tq+80L9MbsygiIr8NsyCi/GYv9a0g2MpmthqFC/5T rLXHqOP2oYGZ4bL+b57AxCMmisWxQ7dwX03gpgdoT+VciQ= Received: from mail51.abv.bg (mail51.abv.bg [127.0.0.1]) by mail51.abv.bg (Postfix) with ESMTP id 43C0812DF2A; Sat, 6 Jun 2009 12:40:58 +0300 (EEST) Date: Sat, 6 Jun 2009 12:40:58 +0300 (EEST) From: Mario Pavlov To: Jacques Fourie Message-ID: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_142656_2142404530.1244281258271" X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: freebsd-current@freebsd.org Subject: Re: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 09:41:01 -0000 ------=_Part_142656_2142404530.1244281258271 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi, thanks a lot for that fix it worked for me, please find attached the patch file, slightly modified so it can be successfully applied the good news is that when I loaded the module it didn't panic, I was even able to run VirtualBox ...I created a virtual machine for windows xp and started the installation...but the virtual machine crashes after the windows installer loads all drivers and tries to start the actual installation and I can see this at the bottom of the vbox log ========================================================================================================================== 00:00:57.770 !!Assertion Failed!! 00:00:57.770 Expression: u64Now <= pNext->u64Expire 00:00:57.770 Location : /usr/ports/emulators/virtualbox/work/virtualbox-2.2.2r19980/src/VBox/VMM/TM.cpp(1899) void tmR3TimerQueueRunVirtualSync(VM*) ========================================================================================================================== and this is what I see in /var/log/messages ========================================================================================================================== Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: pszName=vboxdrv0 ppDev=0xffffff807742f628 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: pszName=vboxdrv0 iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: clone_create -> 1; iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDClone: Created *ppDev=0xffffff003235b400 iUnit=0 si_drv1=0 si_drv2=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDOpen: fOpen=0x3 iUnit=0 Jun 6 11:39:14 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005682 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / -37 ulCmd=20005697 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568a Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:16 home last message repeated 4 times Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005697 Jun 6 11:39:16 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=20005686 Jun 6 11:39:17 home kernel: VBoxDrvFreeBSDIOCtlSlow: returns 0 / 0 ulCmd=2000568e Jun 6 11:39:17 home last message repeated 5 times Jun 6 11:39:17 home kernel: HWACCMR0InitVM: ffffff80776bf000 Jun 6 11:40:11 home kernel: pid 18802 (VirtualBox), uid 0: exited on signal 5 (core dumped) Jun 6 11:40:11 home kernel: VBoxDrvFreeBSDClose: fFile=0x3 iUnit=0 pSession=0xffffff000890e010 Jun 6 11:40:11 home kernel: HWACCMR0TermVM: ffffff80776bf000 ========================================================================================================================== Has someone successfully installed windows xp on VirtualBox ? regards, mgp P.S. it would be great if I could install windows so I could finally play StarCraft! :) >> Hi, >> I've tried http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz out... >>  - it compiles fine (except for the iso I had to download manually) >>  - it panics when I try to load the kernel module, first I tried to load it with X running and the second time I tried to load it without X running, please find attached the output. >> >> about my machine: >> $ uname -a >> FreeBSD home.mydomain.org 7.2-STABLE FreeBSD 7.2-STABLE #7: Thu May 28 01:24:11 EEST 2009     mgp@mydomain.org:/usr/obj/usr/src/sys/Ss-STABLE  amd64 >> >> and also ports updated from 28th of May >> >> regards, >> mgp >> _______________________________________________ >> 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" >> > >The following patch fixes this issue for me. > >--- semevent-r0drv-freebsd.c.old 2009-06-05 12:48:55.841136475 +0200 >+++ semevent-r0drv-freebsd.c 2009-06-05 12:15:08.610705499 +0200 >@@ -181,7 +181,7 @@ > rc = tsleep(pEventInt, /* block id */ > fInterruptible ? PZERO | PCATCH : PZERO, > "iprtev", >- tvtohz(&tv)); >+ cMillies == RT_INDEFINITE_WAIT ? 0 : tvtohz(&tv)); > mtx_lock_spin(&pEventInt->Mtx); > >Regards, >Jacques > ------=_Part_142656_2142404530.1244281258271 Content-Type: application/octet-stream; name=patch-src-VBox-Runtime-r0drv-freebsd-semevent-r0drv-freebsd.c Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=patch-src-VBox-Runtime-r0drv-freebsd-semevent-r0drv-freebsd.c --- src/VBox/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c.old 2009-06-06 10:49:28.000000000 +0300 +++ src/VBox/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c 2009-06-06 10:50:18.000000000 +0300 @@ -181,7 +181,7 @@ rc = tsleep(pEventInt, /* block id */ fInterruptible ? PZERO | PCATCH : PZERO, "iprtev", - tvtohz(&tv)); + cMillies == RT_INDEFINITE_WAIT ? 0 : tvtohz(&tv)); mtx_lock_spin(&pEventInt->Mtx); switch (rc) ------=_Part_142656_2142404530.1244281258271-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 09:42:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2745B106568A for ; Sat, 6 Jun 2009 09:42:47 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id D5CAD8FC12 for ; Sat, 6 Jun 2009 09:42:46 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:33585 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MCsQD-00043x-5p; Sat, 06 Jun 2009 11:42:43 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 28BB05E949; Sat, 6 Jun 2009 11:42:41 +0200 (CEST) Message-Id: <83893B64-0AA4-4705-99F1-19D8F1D1C0DF@exscape.org> From: Thomas Backman To: Maho NAKATA In-Reply-To: <20090606.181302.112520754.chat95@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 6 Jun 2009 11:42:37 +0200 References: <20090527134343.GB1104@bsdcrew.de> <20090606.120001.68053946.chat95@mac.com> <4A2A1048.5090101@samsco.org> <20090606.181302.112520754.chat95@mac.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MCsQD-00043x-5p. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MCsQD-00043x-5p 00cc4c92a8bfdac642246618f7abb607 Cc: FreeBSD Current Subject: Re: Benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 09:42:47 -0000 On Jun 6, 2009, at 11:13 AM, Maho NAKATA wrote: > From: Scott Long > Subject: Re: Benchmark [Re: [Call For Testing] VirtualBox for > FreeBSD! take 4] > Date: Sat, 06 Jun 2009 00:44:24 -0600 > >> Maho NAKATA wrote: >>> I did a benchmark with Virtualbox: >>> My environment: >>> * Core 2 Quad, Q6600@3GHz >>> * Windows XP SP3@host SP2@VBOX with GuestAddon >>> * http://crystalmark.info/software/CrystalMark/ >>> CrystalMark 2004R3 >>> * Sapphire X1650 >>> * VBOX is running on FBSD7.2-REL/amd64 >>> using http://people.freebsd.org/~miwi/vbox/virtualbox_5.tgz >>> * Running with fullscreen mode 1280x1024 32bit >>> Here is the result >>> ----------------------------------------- >>> host(4CPU) host(1CPU) vbox(1CPU) >>> [...] >>> HDD 9336 9331 30600(*) >>> ----------------------------------------- >>> (*)somehow lot faster >>> I don't know how to use two CPUs, even changing setting >>> doesn't change. >>> Usually I cannot usually launch VirtualBox even by root. >>> A workaround is that invoking and killing VirtualBox >>> many times for me. After some tries I can launch... >>> thanks >>> I've seen similar crazy results in VMware Fusion. I reckon it has something to do with sparse disks *in my case*, at least. I ran HD Tune in a Windows VM, and got ~600MB/s out of a 5400rpm laptop hard drive. Natively, I get about 35MB/s, go figure. :) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 11:52:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60AAD1065670 for ; Sat, 6 Jun 2009 11:52:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 05E658FC19 for ; Sat, 6 Jun 2009 11:52:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1MCuRK-000JbO-1i; Sat, 06 Jun 2009 14:51:58 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n56BptNG039578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 14:51:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n56BptXF063251; Sat, 6 Jun 2009 14:51:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n56Bpsui063250; Sat, 6 Jun 2009 14:51:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Jun 2009 14:51:54 +0300 From: Kostik Belousov To: Dag-Erling Sm??rgrav Message-ID: <20090606115154.GI1927@deviant.kiev.zoral.com.ua> References: <86skief8q6.fsf@ds4.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ICd5mx19QJ1U62fT" Content-Disposition: inline In-Reply-To: <86skief8q6.fsf@ds4.des.no> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1MCuRK-000JbO-1i dc7330e68de121614c8c4e866b43936f X-Terabit: YES Cc: current@freebsd.org Subject: Re: LOR between NFS and syncer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 11:52:01 -0000 --ICd5mx19QJ1U62fT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 06, 2009 at 03:32:01AM +0200, Dag-Erling Sm??rgrav wrote: > Anyone seen this one before? >=20 > NFS+ZFS server, diskless NFS client. Both run head. On the client: >=20 > lock order reversal: > 1st 0xc301c164 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 > 2nd 0xc322c058 nfs (nfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper(c07477c6,c2bbfa18,c05921c5,c058310b,c074a615,...) a= t db_trace_self_wrapper+0x26 > kdb_backtrace(c058310b,c074a615,c2cb0828,c2cb0688,c2bbfa74,...) at kdb_ba= cktrace+0x29 > _witness_debugger(c074a615,c322c058,c0759e62,c2cb0688,c0750f5e,...) at _w= itness_debugger+0x25 > witness_checkorder(c322c058,9,c0750f5e,823,0,...) at witness_checkorder+0= x839 > __lockmgr_args(c322c058,80500,c322c074,0,0,...) at __lockmgr_args+0x797 > vop_stdlock(c2bbfb88,c2bbfb70,c0591f6b,c0750f5e,c073ced7,...) at vop_stdl= ock+0x62 > VOP_LOCK1_APV(c079d720,c2bbfb88,c0750f5e,c07b5100,c322c000,...) at VOP_LO= CK1_APV+0xf3 > _vn_lock(c322c000,80500,c0750f5e,823,df,...) at _vn_lock+0x5e > vget(c322c000,80500,c2f1f480,c6e,c2f35c94,...) at vget+0xb9 > vfs_msync(c2f35c94,2,c0750f5e,d67,c2f35c94,...) at vfs_msync+0xe7 > sync_fsync(c2bbfc7c,c301c10c,80400,c0750f5e,69d,...) at sync_fsync+0x17b > VOP_FSYNC_APV(c07975c0,c2bbfc7c,c0750f5e,69d,c2f1f480,...) at VOP_FSYNC_A= PV+0xda > sync_vnode(c093d8f0,c093d8dc,3e8,6cc,4e20,...) at sync_vnode+0x168 > sched_sync(0,c2bbfd38,c073fcec,334,c2ceea90,...) at sched_sync+0x273 > fork_exit(c05d8570,0,c2bbfd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip =3D 0, esp =3D 0xc2bbfd70, ebp =3D 0 --- We lock the covered vnode when doing mount or unmount for the non-root filesystem. Since witness works by recording order by lock name, we get the order of mounted on -> mounted from vnode type. Thus, any interleave in the mount type would give us a LOR. The vnode list for the mount point also includes syncer vnode, that has a special fsync vop. Usual order is syncer vnode lock -> vnode lock for the real vnodes. But, when filesystem is unmounted, we get the order covered vnode -> any filesystem vnode during sync before unmount. This one gives the LOR you reported, assuming you unmounted nfs share mounted on the top of nfs share. I think both issues cannot result in a deadlock. --ICd5mx19QJ1U62fT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoqWFoACgkQC3+MBN1Mb4hdjwCg2Mxfb84KWnmM2IBKoSv2hJBm ZV8An1kEadbLUXxSBAiO+pgAbCLHDzDy =K9Yo -----END PGP SIGNATURE----- --ICd5mx19QJ1U62fT-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 12:44:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B799106564A for ; Sat, 6 Jun 2009 12:44:25 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id BCD068FC16 for ; Sat, 6 Jun 2009 12:44:24 +0000 (UTC) (envelope-from villa.alberto@gmail.com) Received: by fg-out-1718.google.com with SMTP id e12so410404fga.12 for ; Sat, 06 Jun 2009 05:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=4tW1Ty4uPpUJoTJ05gtESQhnIX4uyMaHainDk6EuYak=; b=AfzaCd7wbfi6PObFT47ePHU5twnVc5bx9b304xiI5IsBxkUx1du6dlQg1uMwJWZ3jW /I931cc6KH32G59+IvOTKf5eE9mUmVct159C5Cwsvocz8R4vqdkbmBkClTs80EaVimFh m8/c9628/MQcnmbNUsH0lOCWenrsLYRhfc72w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id; b=asJdZQpaxcyrLISoEPIkagI9C+Nr/S69FdjsBJO41FwEav+rFSzmkeHDOUuM+EqSQP epzDjfGNRVQ1R6uHVbJgKn1orNLZlCKzGDe1zilwwQuBtmStv+mv7m2UARgRsihHP9od TDeWXWA1golIJmH5Uha0BQRmw0lOY890xNVSM= Received: by 10.86.86.10 with SMTP id j10mr4963091fgb.37.1244292263766; Sat, 06 Jun 2009 05:44:23 -0700 (PDT) Received: from echo.hoth (host57-203-dynamic.4-87-r.retail.telecomitalia.it [87.4.203.57]) by mx.google.com with ESMTPS id 4sm2233668fgg.23.2009.06.06.05.44.22 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Jun 2009 05:44:22 -0700 (PDT) From: Alberto Villa To: freebsd-current@freebsd.org Date: Sat, 6 Jun 2009 14:44:20 +0200 User-Agent: KMail/1.11.3 (FreeBSD/7.2-STABLE; KDE/4.2.3; i386; ; ) References: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> In-Reply-To: <567878105.142658.1244281258275.JavaMail.apache@mail51.abv.bg> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906061444.21080.villa.alberto@gmail.com> Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 12:44:25 -0000 On Saturday 06 June 2009 11:40:58 Mario Pavlov wrote: > Has someone successfully installed windows xp on VirtualBox ? i have, on i386 with 7.2-stable, and it's perfect and incredibly fast! -- Alberto Villa From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 13:05:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65F0B106564A for ; Sat, 6 Jun 2009 13:05:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1A90B8FC15 for ; Sat, 6 Jun 2009 13:05:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=PSrUKuUVUidrxCEHK0WrEQpJA86b30G/cUtf05W8MV21nIgr/JjO1FNqGxsSoJY9e25TjNwtPgUKIs0b9dni/GYZdVkQIJcXa06+/hNjP10GfpSrvEJ9pVgiENbf9znY75NmSOvOIbXAafTb88KdMj65rHE3wzztuybkDlTZJv4=; Received: from amnesiac.at.no.dns (ppp91-78-251-37.pppoe.mtu-net.ru [91.78.251.37]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MCva7-000Ags-0E; Sat, 06 Jun 2009 17:05:07 +0400 Date: Sat, 6 Jun 2009 17:05:08 +0400 From: Eygene Ryabinkin To: Olivier SMEDTS Message-ID: References: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <367b2c980906060236y1e77e1b3t432ab066e08dc7a6@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org Subject: Re: Patch for "device_attach: estX attach returned 6" on half of the cores X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 13:05:09 -0000 Olivier, good day. Sat, Jun 06, 2009 at 11:36:39AM +0200, Olivier SMEDTS wrote: > 2009/5/4 Eygene Ryabinkin : > > If anyone sees such symptoms, I encourage them to test the patch. > > The patch itself contained in the PR, but for ease I had put it > > there, > > šhttp://codelabs.ru/fbsd/patches/acpi/attach-children-without-aliases.diff > > and will sync PR's one and this one in the case of any changes. > > Your patch was working great on my Asus P5Q3. But the problem has been > solved more permanently on -CURRENT with the import of ACPICA 20090521 > (r193529-193531). Yes, I already know it, thanks for mentioning this to the list. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 15:11:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 414B3106567C for ; Sat, 6 Jun 2009 15:11:49 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 04D268FC20 for ; Sat, 6 Jun 2009 15:11:48 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1F1556D41C; Sat, 6 Jun 2009 17:11:48 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9E976844E4; Sat, 6 Jun 2009 17:12:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Kostik Belousov References: <86skief8q6.fsf@ds4.des.no> <20090606115154.GI1927@deviant.kiev.zoral.com.ua> Date: Sat, 06 Jun 2009 17:12:27 +0200 In-Reply-To: <20090606115154.GI1927@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Sat, 6 Jun 2009 14:51:54 +0300") Message-ID: <86ab4lflb8.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: LOR between NFS and syncer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 15:11:49 -0000 Kostik Belousov writes: > The vnode list for the mount point also includes syncer vnode, that > has a special fsync vop. Usual order is syncer vnode lock -> vnode > lock for the real vnodes. But, when filesystem is unmounted, we get > the order covered vnode -> any filesystem vnode during sync before > unmount. This one gives the LOR you reported, assuming you unmounted > nfs share mounted on the top of nfs share. No, the LOR occurred during boot. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 15:33:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5011B106566C; Sat, 6 Jun 2009 15:33:12 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id CFBAF8FC12; Sat, 6 Jun 2009 15:33:11 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1206792ywe.13 for ; Sat, 06 Jun 2009 08:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=qAXiqC+K6FYZsugtjKoYhWOSMBo3lfNDZHcr1ln8rUY=; b=GEr1d4eYVLcjN/ukOs7Oo8xt3rkXiKfyOSDB8lpNttEE+nCUkKUqOrKlCUiMR9Mced sppGCQnTYnPiKS+0/e6QUEpi18+aSuD0QhooYIyaM5Si4WpUsD1yGXBnXErvVfMqFIQ4 92378KMWChaKdDMSJrVOXNF+VZRrtxSZc1fLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kHBlgmwkrbTK74mjZqdb97IH+6KwhjTV5P7ScyfuqPfF1hsvlw3Sd5Ry5Npkix184s K6YXHIcMwIRie6yMJJPZpivS1v04MQdb/bMwwkWxN8mb1qM+QqCRDfCdd3PK4A0BBlL0 CYCnoaMfiKFi9Bi/TtMIOFr+siVXo8gYVlKLI= MIME-Version: 1.0 Received: by 10.100.8.4 with SMTP id 4mr4891474anh.146.1244300527122; Sat, 06 Jun 2009 08:02:07 -0700 (PDT) In-Reply-To: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> References: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> From: matt donovan Date: Sat, 6 Jun 2009 11:01:47 -0400 Message-ID: <28283d910906060801p1e1941b5pcf0bc2ea122a6255@mail.gmail.com> To: dan hirsch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, miwi@freebsd.org Subject: Re: what does this mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 15:33:12 -0000 On Sat, Jun 6, 2009 at 10:03 AM, dan hirsch wrote: > 1. > > Running the csup(1)< > http://www.freebsd.org/cgi/man.cgi?query=csup&sektion=1>command > later will download and apply all the recent changes to your Ports > Collection, except actually rebuilding the ports for your own system. > > > > -- > regards, > Dan Hirsch > Linked-In: http://www.linkedin.com/in/danhirsch1 > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > exactly as it states it will update your port tree but will not rebuild and install ports that need updating. From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 15:33:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3768B106564A for ; Sat, 6 Jun 2009 15:33:16 +0000 (UTC) (envelope-from francklarchange@free.fr) Received: from kollok.org (kollok.org [213.251.185.185]) by mx1.freebsd.org (Postfix) with ESMTP id 02A248FC08 for ; Sat, 6 Jun 2009 15:33:15 +0000 (UTC) (envelope-from francklarchange@free.fr) Received: from [10.7.0.7] (kjade [10.7.0.7]) by kollok.org (Postfix) with ESMTP id 3154B161C for ; Sat, 6 Jun 2009 17:13:30 +0200 (CEST) Message-ID: <4A2A878D.30203@free.fr> Date: Sat, 06 Jun 2009 16:13:17 +0100 From: Franck Royer User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Attansic L1e Gigabit Ethernet driver support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: francklarchange@free.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 15:33:16 -0000 Hi, I have an Acer Aspire 6930 and I'm using the freebsd 8.0-CURRENT branch (the 2009-05) on amd64. As said in the topic, I have a network card Attansic L1e Gigabit Ethernet which is not recognize by the GENERIC kernel and current age/ale drivers. I'd like to know what is the current solution to make it works because I saw different solutions. I'll probably try this one : http://daemonforums.org/showthread.php?t=2244 (patching the ale driver, but for now I'm waiting for the end of the download of my freebsd dvd cause of course I need the kernel sources to compile it). I can give my dmesg messages but it's not obvious (cause I doing a zfs only installation, it is why I took the current, and my other installed system is a ubuntu without zfs support :/). Cheers, Franck From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 16:37:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD50C1065680; Sat, 6 Jun 2009 16:37:30 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from smtp-out.abv.bg (smtp-out.abv.bg [194.153.145.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6CEDD8FC18; Sat, 6 Jun 2009 16:37:30 +0000 (UTC) (envelope-from freebsd@abv.bg) Received: from mail52.abv.bg (mail52.ni.bg [192.168.151.19]) by smtp-out.abv.bg (Postfix) with ESMTP id C764D87C1C; Sat, 6 Jun 2009 19:37:41 +0300 (EEST) DomainKey-Signature: a=rsa-sha1; s=smtp-out; d=abv.bg; c=simple; q=dns; b=Ss01X2TrIfVxQKsWLmrCftBtQHUhFTWq85YXrIVOZ0vRNk5zxh9fq/1OvIZWgM6gp kz83pGvEMwR94e8oPC/bxdWiZEBRtq3H/vqcSa2yHLsNsiZUw0gPWoFBAFpyNrvV5UG gJl6sk3cNqOsQm8Rfd6MLX2oWRhuBpqA/7uEwKU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out; t=1244306261; bh=bDDg1ladHJsmRP/Rwv7tSrXSuDvKC0tMvm/lcuc8H9g=; h=Date:From:To:Cc:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:DKIM; b=lkj3BxAy9Kw28ABrhpWARNBOOOnoNyKdk+3+eGBabUJskUp4+x2uCvovZh2vBH6/s PpLXObO0r2WZ0sOU4NAkZ08r4guN5mWS6XB8fLMIkZOMclH0lcglFbMmyzDBOU6PFS RIYbALDP8cq9il8na3TjUnoBGijtpgsx3q4p6tfI= Received: from mail52.abv.bg (mail52.abv.bg [127.0.0.1]) by mail52.abv.bg (Postfix) with ESMTP id C56FF1ACA64; Sat, 6 Jun 2009 19:37:27 +0300 (EEST) Date: Sat, 6 Jun 2009 19:37:27 +0300 (EEST) From: Mario Pavlov To: Wampir Message-ID: <1823042729.128315.1244306247806.JavaMail.apache@mail52.abv.bg> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-Mailer: AbvMail 1.0 X-Originating-IP: 78.128.21.208 Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ACPI problem with new acer aspire 6930G X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 16:37:31 -0000 Hi, this is a known issue there is an open PR about it: http://www.freebsd.org/cgi/query-pr.cgi?pr=135070 regards, Mario >Hi. >I have a problem with ale support on 7.2-RELEASE and 8.0-CURRENT. >I get on dmesg: > >ale0: irq 17 at device 0.0 on pci9 >ale0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >ale0: cannot allocate memory resources. >device_attach: ale0 attach returned 6 > >When i boot freebsd in safe mode ale starts correctly (but gets no >link), but i get all the time: >"interrupt storm detected on "irq10:"; throttling interrupt source" errors. > >Can anyone help solve the issue? >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 17:52:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED7F106566B for ; Sat, 6 Jun 2009 17:52:18 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: from mail-bw0-f214.google.com (mail-bw0-f214.google.com [209.85.218.214]) by mx1.freebsd.org (Postfix) with ESMTP id EA4048FC0A for ; Sat, 6 Jun 2009 17:52:17 +0000 (UTC) (envelope-from yuri.pankov@gmail.com) Received: by bwz10 with SMTP id 10so90722bwz.43 for ; Sat, 06 Jun 2009 10:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FToe4Wa3lzUqS3gncRmtZMQAbPJL3tBoztClSJ5P1Vs=; b=fsArY8wMNHV1/Wckmw/L8oqSxdW2qsDCgJEloKwVLWUXwxEYYnMoCLeIALiKd2aVRH 1hXVwXFog5VxkdDt3x1cFVTs72mGnv2GTj/IfUdt5EhzMwRRF73pa2VdyuTRvuwDNu8U KNUvbvgxqFMUXxSFNkOHuU0gw8VyKEHJTHVPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:date:from:to:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=xTv9s62+QRyF7QlTAjcadsY8LQT5DShlxM22ozhQzabOfz3GsYA6JdJjgR78EQFnMS k49tXJO3KWFahjugKhTnO5cBHDyFBsP8QP2Zpoms0jjlxH9ifNA8joJQ5+mj/JSp3r+6 wOpRzA00RknTiXm3CSCAekeN7TnYnm5ESS0N8= Received: by 10.204.60.72 with SMTP id o8mr4575487bkh.184.1244310736800; Sat, 06 Jun 2009 10:52:16 -0700 (PDT) Received: from darklight.homeunix.org ([85.175.193.190]) by mx.google.com with ESMTPS id z15sm1393308fkz.4.2009.06.06.10.52.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Jun 2009 10:52:16 -0700 (PDT) Received: from darklight.homeunix.org (darklight.homeunix.org [127.0.0.1]) by darklight.homeunix.org (8.14.3/8.14.3) with ESMTP id n56HpwEp086627 for ; Sat, 6 Jun 2009 21:51:59 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) Received: (from yuri@localhost) by darklight.homeunix.org (8.14.3/8.14.3/Submit) id n56HpwSS086626 for freebsd-current@freebsd.org; Sat, 6 Jun 2009 21:51:58 +0400 (MSD) (envelope-from yuri.pankov@gmail.com) X-Authentication-Warning: darklight.homeunix.org: yuri set sender to yuri.pankov@gmail.com using -f Date: Sat, 6 Jun 2009 21:51:58 +0400 From: Yuri Pankov To: freebsd-current@freebsd.org Message-ID: <20090606175158.GA1080@darklight.homeunix.org> References: <20090606021835.GC1077@darklight.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20090606021835.GC1077@darklight.homeunix.org> User-Agent: Mutt/1.5.19 (2009-01-05) Subject: Re: loader panics with 2 GPT partitioned drives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 17:52:18 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 06, 2009 at 06:18:35AM +0400, Yuri Pankov wrote: > Hi, > > I'm getting the following "panic" from loader when trying to attach > another GPT partitioned drive. loader is built using LOADER_ZFS_SUPPORT. > > BTX Loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS drive D: is disk1 > > panic:free: guard1 fail @ 0x7fd4b3f4 from > /usr/src/sys/boot/i386/libi386/biosdisk.c:1048 > > > ad4: > => 34 488397101 ad4 GPT (233G) > 34 128 1 freebsd-boot (64K) > 162 16777216 2 freebsd-swap (8.0G) > 16777378 471619757 3 freebsd-zfs (225G) > > ad10: > empty disk, `gpart create -s GPT ad10` > > > > Yuri Looks like there are no checks in loader with GPT support if there are no partitions defined (very rare case, but still.. :-). Attached patch fixes booting with GPT disk without partitions (for me). Yuri --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="biosdisk.c.diff" Index: biosdisk.c =================================================================== --- biosdisk.c (revision 193589) +++ biosdisk.c (working copy) @@ -990,7 +990,8 @@ out: if (error) { - free(od->od_partitions); + if (od->od_nparts > 0) + free(od->od_partitions); od->od_flags &= ~BD_GPTOK; } return (error); @@ -1044,7 +1045,7 @@ delay(3000000); #endif #ifdef LOADER_GPT_SUPPORT - if (od->od_flags & BD_GPTOK) + if (od->od_flags & BD_GPTOK && od->od_nparts > 0) free(od->od_partitions); #endif free(od); --2fHTh5uZTiUOsy+g-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 19:28:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 958951065674; Sat, 6 Jun 2009 19:28:01 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mx2.itu.dk (mx2.itu.dk [130.226.142.29]) by mx1.freebsd.org (Postfix) with ESMTP id 259CE8FC12; Sat, 6 Jun 2009 19:28:01 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by mx2.itu.dk (Postfix) with ESMTP id 4247DF48072; Sat, 6 Jun 2009 21:27:59 +0200 (CEST) Message-Id: <686A733E-2F33-4C40-A516-7D3A8E5E431E@cederstrand.dk> From: Erik Cederstrand To: Tim Kientzle In-Reply-To: <4A27F105.4040109@freebsd.org> Content-Type: multipart/signed; boundary=Apple-Mail-28--278694535; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 6 Jun 2009 21:27:57 +0200 References: <20090604093831.GE48776@hoeg.nl> <31BD4D08-6558-46FF-9B93-CF8249AAC461@cederstrand.dk> <4A27F105.4040109@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ed Schouten , hackers@freebsd.org, current@freebsd.org Subject: Re: Clang: now available from a SVN server near you! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 19:28:02 -0000 --Apple-Mail-28--278694535 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Den 04/06/2009 kl. 18.06 skrev Tim Kientzle: > Erik Cederstrand wrote: >> LLVM provides a linker (http://llvm.org/cmds/llvm-ld.html) but "it >> doesn't interact correctly with conventional nm/ar/etc" (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005296.html >> ). > > In what way does it not interact correctly? There was not much more help to get from the Clang list, unfortunately. The code lives at http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-ld/ and looks very well-documented and structured. Unfortunately, it is a bit over my head to see what needs to be fixed and actually fix it. Thanks, Erik --Apple-Mail-28--278694535-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 16:54:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4055D106566B; Fri, 5 Jun 2009 16:54:36 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 664A48FC13; Fri, 5 Jun 2009 16:54:34 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245042141; Fri, 05 Jun 2009 19:54:31 +0300 Message-ID: <4A294DC3.5010008@mavhome.dp.ua> Date: Fri, 05 Jun 2009 19:54:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> In-Reply-To: <200906050703.n5573x5Q071765@apollo.backplane.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 06 Jun 2009 21:20:28 +0000 Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 16:54:36 -0000 Hi. Matthew Dillon wrote: > The biggest issue with AHCI (and ATA) interfacing is that AHCI devices > attach either as DISK or ATAPI. A device which attaches as a DISK > does not typically support ATAPI commands (though it would be an > interesting experiment to see if some did). This means that no matter > what you do a SCSI<->ATA translation layer needs to do some significant > fake-ups for DISK attachments, similar to what OpenBSD does in their > SCSI<->ATA layer. ATA DISK attachments simply do not support enough > of the SCSI command set for direct integration into CAM (IMHO). I think ATAPI disk device is theoretically possible, but I believe it does not exist in practice, as industry do not need it. It will become SCSI disk opponent from commands PoV, but with all ATA interface ugly growth problems. And I am not sure that it will have more benefits then contras comparing to SCSI or plain ATA. When I was talking about common CAM layer, I was directly speaking that there will be _no_command_translation_ for ATA disks! There will be separate native ATA disk driver withing CAM infrastructure. > The second biggest issue is that it is really unclear to me how the > hell one probes an ATAPI device for NCQ support. The OpenBSD driver > only uses AHCI-NCQ for DISK attachments, where the NCQ support is > returned in the IDENTIFY command. I'm sure there must be a way to > probe an ATAPI device for NCQ support but I don't know what it is. I have never seen opposite, and I believe that NCQ is just not implemented for ATAPI devices. NCQ requires different ATA commands usage for ATA disk drives and that makes drive to behave very different on FIS level. NCQ uses First Party DMA and special command completion FISes, that IMHO just not implemented for ATA PACKET command. > The OpenBSD driver does not have port multiplier support but adding > it to the DFly driver will be pretty easy... I just need some hardware > to test it with (it's on the way). Unfortunately the AHCI-1.0 > specfication says it cannot be used for high-performance multi-disk > I/O because all parallel commands in operation are only allowed to go > to a single target at a time. i.e. you can't mix parallel commands > to different targets on the same port. That's a serious problem. > > (Does anyone know if the AHCI-1.1 or 1.2 specifications do anything > about that?). Latest AHCI specifications define feature named FIS Based Switching. It allows controller independently track state of every device beyond port multiplier. It should be quite easy to use it, but actually none of my controllers have that capability. > It is unclear to me from reading the specification as to whether > AHCI-NCQ is supported for SATA ATAPI attachments. If anyone has an > answer to that I'm looking for a way to probe the device's > max-commands for ATAPI. for DISKs the IDENTIFY command has the > necessary feature bits and information. I'm sure the host controller > supports it natively but the real question is how to probe > the capability on the attached device and whether the device(s) > support it. ATAPI devices have their own equivalent of ATA IDENTIFY command. > Ultimately the best way to expand-out an AHCI interface is with > SCSI pass-through over ATAPI, assuming NCQ can be supported somehow. > The port-multiplier spec is badly broken (at least in Intel's AHCI-1.0 > spec). It is a bit annoying, actually, I wouldn't have though that > Intel would have made such a basic mistake. All they had to do was > implement 4 bits in the FIS and the problem would have been solved. > Instead they have routing bits in a port register. Sigh. Latest AHCI specifications are definitely better, but now we have a lot of hardware conforming early 1.0 and 1.1 revisions. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 16:58:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57CD71065705; Fri, 5 Jun 2009 16:58:32 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8AC8FC0A; Fri, 5 Jun 2009 16:58:31 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245042309; Fri, 05 Jun 2009 19:58:28 +0300 Message-ID: <4A294EAF.3080706@mavhome.dp.ua> Date: Fri, 05 Jun 2009 19:58:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Matthew Dillon References: <4A254B45.8050800@mavhome.dp.ua> <200906050703.n5573x5Q071765@apollo.backplane.com> <200906051601.n55G10Mi075734@apollo.backplane.com> In-Reply-To: <200906051601.n55G10Mi075734@apollo.backplane.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 06 Jun 2009 21:20:38 +0000 Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Jun 2009 16:58:33 -0000 Matthew Dillon wrote: > It's unclear to me what this means. Can we use NCQ to queue multiple > commands to multiple ports behind a single port multiplier in parallel > or can't we? It's very confusing. As I have said, without controller FIS Based Switching capability it is impossible. FBS defines separate memory areas for controller, to track there state of each drive behind PM. Without it, only one drive can be active at a time, as controller will not be able to track when each drive is able to receive next command.. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 12:48:16 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4640106566B for ; Sat, 6 Jun 2009 12:48:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7058FC14 for ; Sat, 6 Jun 2009 12:48:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n56AW1i2026352 for ; Sat, 6 Jun 2009 20:32:01 +1000 Received: from c122-106-151-9.carlnfd1.nsw.optusnet.com.au (c122-106-151-9.carlnfd1.nsw.optusnet.com.au [122.106.151.9]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n56AVpUM016853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 20:31:53 +1000 Date: Sat, 6 Jun 2009 20:31:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Brooks Davis In-Reply-To: <20090605223636.GA24364@lor.one-eyed-alien.net> Message-ID: <20090606184344.N16744@delplex.bde.org> References: <20090605223636.GA24364@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 06 Jun 2009 21:21:38 +0000 Cc: arch@FreeBSD.org, current@FreeBSD.org Subject: Re: RFT: Allow large values of NGROUPS_MAX X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 12:48:16 -0000 On Fri, 5 Jun 2009, Brooks Davis wrote: > I've been working on fixing the limit of 15 groups per user. This has > primarily consisted of merging a patch from Isilon Systems which breaks > the group array out of struct ucred and stores in in malloc'd storage. > > I've attached a patch which includes that change and increases the value > of NGROUPS_MAX to 32767. It also changes references to cr_groups[0] to > use the cr_gid macro ... I don't like this macro. At least the implementation should keep using the unobfuscated reference. kern_prot.c consistently didn't use the obfuscation except once in a comment. > Before any merge a couple decisions need to be made: > > - How large should NGROUPS_MAX be? Linux uses 65536 and we could > extend things to support that, but it's probably unnecessary. 32767 seems excessive too. Hopefully NGROUPS[_MAX] is used only in broken unconverted applications so a large value rarely wastes space. > - Should we make any attempt to support old binaries when there > are more than 16 groups? There is no way to support broken old binaries. They will have a limit of 16. > The POSIX getgroups/setgroups APIs did not > anticipate this change and thus either will fail outright. No, as you explained in previous mail, POSIX anticipated this perfectly unusably by making NGROUPS_MAX a Runtime Increasable Value despite it being constant. This puts the burden of not failing on applications. Only broken apps that don't do any of dynamic allocation using sysconf(_SC_NGROUPS_MAX), or dynamic allocation using getgroups(0, ...), or dynamic allocation after failing using getgroups(old_NGROUPS_MAX, ...) will fail outright. > We can't > fix setgroups, but we might want to make an optional accommodation for > getgroups to allow for truncated returns to old code. If done unconditionally, this would break the unbroken apps that do dynamic allocation after failing using getgroups(old_NGROUPS_MAX, ...). These apps depend on getgroups() failing with the Standard and documented errno EINVAL when the `gidsetlen' parameter is too small. Maybe some per-app or per-environment branding could be used to configure not generating an error. You would apply it only where security is not very important. getgrouplist(3) guarantees filling of the array when the array is too small. getgroups(2) doesn't guarantee anything, and in fact doesn't fill the array. It wouldn't hurt to fill it. % ... % diff -ru --exclude='.glimpse*' --exclude=.svn --exclude=compile --ignore-matching='$FreeBSD' /usr/src/sys/kern/kern_prot.c ngroups/sys/kern/kern_prot.c % --- /usr/src/sys/kern/kern_prot.c 2009-06-05 15:33:50.000000000 -0500 % +++ ngroups/sys/kern/kern_prot.c 2009-06-05 16:02:28.000000000 -0500 % @@ -243,16 +246,11 @@ % % td->td_retval[0] = td->td_ucred->cr_rgid; % #if defined(COMPAT_43) % - td->td_retval[1] = td->td_ucred->cr_groups[0]; % + td->td_retval[1] = td->td_ucred->cr_gid; % #endif % return (0); % } % % -/* % - * Get effective group ID. The "egid" is groups[0], and could be obtained % - * via getgroups. This syscall exists because it is somewhat painful to do % - * correctly in a library function. % - */ % #ifndef _SYS_SYSPROTO_H_ % struct getegid_args { % int dummy; This comment still seems to apply. I wonder if you noticed and/or fixed the related off-by-1 errors in getgroups() and {NGROUPS_MAX}: POSIX.1-2001-draft7 says: % 16834 IDs of the calling process. It is implementation-defined whether getgroups( ) also returns the % 16835 effective group ID in the grouplist array. FreeBSD does return the egid in the array, always as the first element. Neither of these details is documented in getgroups.2 or setgroups.2. Even the implementation doesn't seem to understand this where it is most important -- the implementation of setgroups() seems to be missing some of the things done by setegid(). getgrouplist(3) has explicit support for the egid being in both the initial and final lists (or missing in the initial list?). % ... % 16841 If the effective group ID of the process is returned with the supplementary group IDs, the value % 16842 returned shall always be greater than or equal to one and less than or equal to the value of % 16843 {NGROUPS_MAX}+1. This and probably other things indicate that _supplementary_ actually means supplementary -- it doesn't count the egid. But in FreeBSD, the egid is counted. This gives 2 off-by-1 errors that partially compensate for each other: - NGROUPS_MAX is 15, not 16, since it is impossible to have 16 _supplementary_ groups in cr_groups[0..15] after using cr_groups[0] for the egid - getgroups() cannot return {NGROUPS_MAX}+1 as is needed for it to return the egid plus {NGROUPS_MAX} supplementary groups - getgroups() does return {NGROUPS_MAX}+1 once {NGROUPS_MAX} is corrected. Some userland code depends on these bugs -- the static array size should be NGROUPS_MAX + 1, but it is typically plain NGROUPS. OTOH, libc/gen/initgroups.c uses NGROUPS + 1 and getgrouplist() followed by setgroups(). I think getgrouplist() can produce the extra 1 and then setgroups() and thus initgroups() will fail. I thought again about making cr_gid separate from the array, so that it can be named cr_gid without obfuscation. This wouldn't be good since it would complicate more than the copyin/out in get/setgroups() -- there are a few temporary gid arrays, and some iterations over the arrays that want to see the egid. Bruce From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 14:29:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05A8106564A; Sat, 6 Jun 2009 14:29:13 +0000 (UTC) (envelope-from hirsh.dan@gmail.com) Received: from mail-ew0-f212.google.com (mail-ew0-f212.google.com [209.85.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 0892B8FC1B; Sat, 6 Jun 2009 14:29:12 +0000 (UTC) (envelope-from hirsh.dan@gmail.com) Received: by ewy8 with SMTP id 8so2862455ewy.43 for ; Sat, 06 Jun 2009 07:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=a9TWnvHqldEGPL7ON1PkrPR7HNnrBSkqVq9mSsQykY4=; b=qHKbDqEXHkMgf7hBIliPxskgXhEfD5OdY0ZuGbmsD7BhqFiv7IC+2e69ayfAkczGuJ mLgOSmu631/vn4HKrxExOHiUwJhWSZACuyRf3Z6aNopCeD+Pm83az88toBY8tBipo5os rHDIeUSM9UT1zOCXNAE73jYxmXc4n+jNrBdeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ko2Y5SJY2QCTG+VkJkqHZ0hM7z3TWIqRK0ekrDIw+8zYG2wHJgukKuE4QpBp4zWbNl 7hKQ2hwo7x3azf/3c4aJGGZek9Ml0FuxBFLDdNYyJuoIYs3gauOy8m60iXq986oygNFL UvaW9+1Hei948vV3a94va9u6dr5TpBeW0qMAQ= MIME-Version: 1.0 Received: by 10.216.70.143 with SMTP id p15mr1625792wed.115.1244297005867; Sat, 06 Jun 2009 07:03:25 -0700 (PDT) Date: Sat, 6 Jun 2009 17:03:25 +0300 Message-ID: <4d3011fa0906060703s1dbfdaebg7df73203a3a43e58@mail.gmail.com> From: dan hirsch To: ports@freebsd.org, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, miwi@freebsd.org X-Mailman-Approved-At: Sat, 06 Jun 2009 21:23:05 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: what does this mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 14:29:14 -0000 1. Running the csup(1)command later will download and apply all the recent changes to your Ports Collection, except actually rebuilding the ports for your own system. -- regards, Dan Hirsch Linked-In: http://www.linkedin.com/in/danhirsch1 From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 16:43:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EBB11065689 for ; Sat, 6 Jun 2009 16:43:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBCF8FC13 for ; Sat, 6 Jun 2009 16:43:24 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id DCF4A1E00196; Sat, 6 Jun 2009 18:27:59 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n56GMago050840; Sat, 6 Jun 2009 18:22:36 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n56GManE050839; Sat, 6 Jun 2009 18:22:36 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 6 Jun 2009 18:22:35 +0200 To: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20090606162235.GA49444@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Mailman-Approved-At: Sat, 06 Jun 2009 21:27:57 +0000 Cc: Subject: flash10 vs f10; em(4) now broken in -current in qemu/vbox X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 16:43:25 -0000 Hi! I just made a new vbox/qemu -current guest to look at flash10 vs f10 (I made a raw image using qemu-img and gave that to vbox as per this description, http://www.virtualbox.org/manual/UserManual.html#rawdisk so that I can also mount it from the host using mdconfig and boot it in qemu too), and noticed em(4) in both vbox and qemu now report `Invalid MAC address' and consequently don't attach: vbox: em0: port 0xd010-0xd017 mem 0xf0000 000-0xf001ffff irq 19 at device 3.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf0000000 em0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd010 em0: Invalid MAC address device_attach: em0 attach returned 5 qemu: em0: port 0xc040-0xc07f mem 0xf2020 000-0xf203ffff irq 11 at device 3.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2020000 em0: Reserved 0x40 bytes for rid 0x14 type 4 at 0xc040 em0: Invalid MAC address device_attach: em0 attach returned 5 I had to switch to PCnet-PCI II in vbox and model=pcnet in qemu, both driven by le(4) in the guest. Btw, PCnet-FAST III in vbox also doesn't work (driven by pcn(4)), it fails to dhcp, but that breakage also exists in 7.2 so its much older. head snapshot where em(4) works: 8.0-HEAD-20090403-JPSNAP head snapshot where em(4) is broken: 8.0-HEAD-20090605-JPSNAP Anyway, on to www/linux-f8-flashplugin10 with OVERRIDE_LINUX_BASE_PORT and OVERRIDE_LINUX_NONBASE_PORTS both f10: I got that going after removing libidn from the port's USE_LINUX_APPS (its part of linux_base-f10) and installing two new dependencies of f10's libcurl: libldap-2.4.so.2 in openldap-2.4.12-1.fc10.i386.rpm and libsasl2.so.2 in cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm (so we'll need two new ports for these), and then finally to get libflashsupport working too (i.e., audio) I had to ln -s libssl.so.7 /compat/linux/lib/libssl.so.6 - so we probably need a new linux-f10-flashsupport too if we want to avoid that symlink. Oh and btw I got a weird audio issue in vbox also: most of the times audio plays too fast and sounds ugly (using snd_ich; this stays until guest reboot), but I also had the guest boot a few times with proper audio... Cheers, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 22:36:46 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A4FE106564A; Sat, 6 Jun 2009 22:36:45 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4978FC15; Sat, 6 Jun 2009 22:36:43 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz7 with SMTP id 7so81611bwz.43 for ; Sat, 06 Jun 2009 15:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=d/E8WvwGaesrv01cjJ0WI7VTqVUYmOlWrVXS3cN9dAg=; b=lP/w0b13LHLDhD7cohYKq3PpJ0VV0hq/GbIp8YOgdCvfs+4ToqiYYMlvYIFB2Wb1dU LWl2vZl4SEULfk4+YBZnqM6VtqqVEGbkLk0v4698ZVp8K2CZSRBFuE8MPdNf/cqCxzHo 2h2o1aksXFZoXGfqk88NCXsHpI/hFALmasNBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=FpgdjhNqX6Cza9cjlgqNq+1m0LbwxI7Wh+h720cEPoVdcIXdqWDv1nOB6OuK2UyIS6 uPF34DzT2XdovdABvBD6OIB+ragrWkRlAQchgfhIXjV6GxuuEuq9/zJ9VtjTEC+MYF+x CNRnHDrmAmcbzP8vldxaFMUfBdIrUYqDyCUx0= MIME-Version: 1.0 Received: by 10.204.64.67 with SMTP id d3mr4769749bki.142.1244327803021; Sat, 06 Jun 2009 15:36:43 -0700 (PDT) In-Reply-To: <4A263ECD.2070704@fletchermoorland.co.uk> References: <20090514191237.GD70242@bsdcrew.de> <20090515101253.GH71804@bsdcrew.de> <4A0D7574.3050801@fletchermoorland.co.uk> <4A1AC253.6010306@egr.msu.edu> <20090603061650.GC1122@egr.msu.edu> <4A263ECD.2070704@fletchermoorland.co.uk> Date: Sat, 6 Jun 2009 18:36:42 -0400 Message-ID: <4ad871310906061536y55382376x6a73e7ad88ee3b8f@mail.gmail.com> From: Glen Barber To: ports@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Call For Testing] VirtualBox for FreeBSD! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 22:36:46 -0000 Good evening everyone. Earlier today, I finished a VBox build on a fresh system. After the build succeeded, I 'kldload /boot/modules/vboxdrv.ko' which caused a panic. The machine runs a GENERIC kernel with KDB and KDB_UNATTENDED added -- no other changes. -- The machine -- FreeBSD orion 7.2-STABLE FreeBSD 7.2-STABLE #1 r193481: Sat Jun 6 10:22:25 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION i386 -- Snippet from 'dmesg' -- FreeBSD 7.2-STABLE #0 r193481: Fri Jun 5 01:55:06 EDT 2009 root@orion:/usr/obj/usr/src/sys/ORION Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz (2217.69-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 2128793600 (2030 MB) avail memory = 2073436160 (1977 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 -- The panic -- orion# kgdb kernel.debug /var/crash/vmcore.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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: !!Assertion Failed!! Expression: cMillies != RT_INDEFINITE_WAIT Location : /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/ src/VBox/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c(212) rtSemEventWait Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xc5e180be stack pointer = 0x28:0xe7a73c08 frame pointer = 0x28:0xe7a73c34 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 1838 (TIMER) trap number = 3 panic: breakpoint instruction fault cpuid = 1 Uptime: 6h58m4s Physical memory: 2017 MB Dumping 180 MB: 165 149 133 117 101 85 69 53 37 21 5 Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kerne l/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/ac pi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc07e45a7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07e48b2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae6d83 in trap_fatal (frame=0xe7a73bc8, eva=0) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae7bdc in trap (frame=0xe7a73bc8) at /usr/src/sys/i386/i386/trap.c:726 #5 0xc0acc05b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #6 0xc5e180be in rtSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295, fInterruptible=false) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:212 #7 0xc5e181b0 in RTSemEventWait (EventSem=0xc5d2a110, cMillies=4294967295) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/semevent-r0drv-freebsd.c:240 #8 0xc5e157f1 in rtTimerThread (Thread=0xc5d2b990, pvUser=0xc5d2be90) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/generic/timer-generic.cpp:238 #9 0xc5e1a6c0 in rtThreadMain (pThread=0xc5d2b990, NativeThread=3316025600, pszThreadName=0xc5d2b9d0 "TIMER") at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/common/misc/thread.cpp:635 #10 0xc5e26ee7 in rtThreadNativeMain (pvThreadInt=0xc5d2b990) at /usr/home/gbarber/virtualbox/virtualbox/work/virtualbox-2.2.2r19980/src/V Box/Runtime/r0drv/freebsd/thread2-r0drv-freebsd.c:112 ---Type to continue, or q to quit--- #11 0xc07bdbc9 in fork_exit (callout=0xc5e26ec0 , arg=0xc5d2b990, frame=0xe7a73d38) at /usr/src/sys/kern/kern_fork.c:811 #12 0xc0acc0d0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) Any thoughts? If needed, I will test patches. -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 22:43:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8170106566B for ; Sat, 6 Jun 2009 22:43:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 965328FC19 for ; Sat, 6 Jun 2009 22:43:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 56B996995B; Sat, 6 Jun 2009 22:43:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n56MheMO006658; Sat, 6 Jun 2009 22:43:40 GMT (envelope-from phk@critter.freebsd.dk) To: Alexander Motin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 05 Jun 2009 19:54:27 +0300." <4A294DC3.5010008@mavhome.dp.ua> Date: Sat, 06 Jun 2009 22:43:40 +0000 Message-ID: <6657.1244328220@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 22:43:28 -0000 In message <4A294DC3.5010008@mavhome.dp.ua>, Alexander Motin writes: >I think ATAPI disk device is theoretically possible, but I believe it >does not exist in practice, as industry do not need it. Maxtor ZIP ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 23:15:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73BE1065672; Sat, 6 Jun 2009 23:15:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id EC8B68FC23; Sat, 6 Jun 2009 23:15:12 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 245100807; Sun, 07 Jun 2009 02:15:09 +0300 Message-ID: <4A2AF876.1030103@FreeBSD.org> Date: Sun, 07 Jun 2009 02:15:02 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Poul-Henning Kamp References: <6657.1244328220@critter.freebsd.dk> In-Reply-To: <6657.1244328220@critter.freebsd.dk> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 23:15:14 -0000 Poul-Henning Kamp wrote: > In message <4A294DC3.5010008@mavhome.dp.ua>, Alexander Motin writes: >> I think ATAPI disk device is theoretically possible, but I believe it >> does not exist in practice, as industry do not need it. > > Maxtor ZIP ? May be, never had an ATA version. But it is more FDD, then HDD. Also it existed in Parallel Port and SCSI versions, so it could be done in ATAPI way just for unification. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jun 6 23:33:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9319106564A; Sat, 6 Jun 2009 23:33:19 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id D96D38FC12; Sat, 6 Jun 2009 23:33:17 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n56NXHeZ090342; Sat, 6 Jun 2009 16:33:17 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n56NXH6a090341; Sat, 6 Jun 2009 16:33:17 -0700 (PDT) Date: Sat, 6 Jun 2009 16:33:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200906062333.n56NXH6a090341@apollo.backplane.com> To: Alexander Motin References: <6657.1244328220@critter.freebsd.dk> <4A2AF876.1030103@FreeBSD.org> Cc: FreeBSD-Current , freebsd-arch@FreeBSD.org Subject: Re: WIP: ATA to CAM integration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 06 Jun 2009 23:33:20 -0000 I found the ATAPI_C_ATAPI_IDENTIFY command that was mentioned and it works fine, returning the same sort of information for ATAPI attachments that ATA_C_IDENTIFY returns for DISK attachments. That takes care of the queue length negotiation by the device. However, there is no fis->command that I can find that would allow NCQ to operate in ATAPI mode. In ATAPI mode fis->command is typically set to ATA_C_PACKET. In DISK mode fis->command is set to ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA (the first-person DMA mode used by AHCI's NCQ). So unless the *_FPDMA FIS commands work for an ATAPI attached device, we are S.O.L. Section 5.6.4.1: The ATA/ATAPI-7 queued feature set is not supported by AHCI (including READ QUEUED (EXT), WRITE QUEUED (EXT), and SERVICE commands). Queued operations are supported in AHCI using the READ FPDMA QUEUED and WRITE FPDMA QUEUED commands when the HBA and device support native command queueing. It is unclear whether an ATAPI device would accept a non-packet command, aka ATA_C_READ_FPDMA or ATA_C_WRITE_FPDMA, instead of ATA_C_PACKET. ATAPI devices do support the ATAPI_C_ATAPI_IDENTIFY command, which is non-packet command, so maybe its possible. If it is possible it would only work for READ and WRITE commands, since those are the only commands the FPDMA modes can be used for. The AHCI spec doesn't explicitly say that the FPDMA commands would not work for an ATAPI attached device, so there's hope. What we need is a SATA ATAPI device which says it supports NCQ + has a queue length > 1 to test with. -Matt Matthew Dillon