From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 00:04:37 2010 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 969F1106566B for ; Sun, 10 Jan 2010 00:04:37 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51805.mail.re2.yahoo.com (web51805.mail.re2.yahoo.com [206.190.38.236]) by mx1.freebsd.org (Postfix) with SMTP id 3CE228FC08 for ; Sun, 10 Jan 2010 00:04:36 +0000 (UTC) Received: (qmail 4456 invoked by uid 60001); 10 Jan 2010 00:04:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1263081874; bh=jI9i63cD8koqROwuffCoACU+1QCLndaSOoLOWUL0NMA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Cz98/mlojEoWULRv219yUWUdpDtxi1QlPZThkM9g7xoY+di8E92kZJwIpU53d1BfSlDidDmxYc3TZkQu0CALTlYcdkSJGJPzMakrEG9JYMGlbE2vwhDIP9D+stmy9tQODVEPaa+4OMs22arwySPLzNSh0bnn7PfZLa4iCCHL++g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yP67vF1ioE5udmSAVTVMZzx+m7Y61L6/J1ga+ulX9qP/sBQ2ftyI+oJHV84Na2e9M0umBB9i036GJaMcEkr8+e1LpzKHnkHcqjAoAqnCJajzqnKKYAHyWO29x8CdNixfJR4amZ6fpQztT94Xs+VtK1dj24W9ohk2hDXa8S2ydbE=; Message-ID: <191118.3035.qm@web51805.mail.re2.yahoo.com> X-YMail-OSG: xKA8m9sVM1mlWg00CWXRt4TETQ2P4lcEjZTTV1UkcMuQiv.3AlyzKc7byBB3pvWpZJIFyUxa.p8FpFO1wb0KCuYdca35atetyKuP7Fm070pmgNBs4oRlWFUZPgcrZqJ3K2LmJeUNf8aCF7kULdeSRRE9MtLNEf1vgxyQl10ZKlJSz4Yo9aqf_.JpsnVnwyJVIIs.ZKoOEfUMm8PGKePdMfYqphdlkUlfMr96KXqXR6T73hYlV92lghNsjv0MzkUVIHO4aSILL7Xo.FMk2Ld_RsnsJMS8ymAmtW760DxaUhJUGvLJLkZi8qT0Dm3lhcaoBuhT5QgBR6Q5KOaO1pcubLwTcnagnY4ksAPbK8NrMdyP4wkq.io1y.oSDBQZoc.UQnMjmybN9n1jwS27HZpPRZ0fNEoz2ktAqQ33AGEzsgoYAuXLZR1NPfVkuk9.11NPuAZOSdO6UmI6aZ8Now85nEbp10dFLWgB1_vF6bMbXBzyB4ia8m5D30qwpT9z2t_IjB6Q4EPx9yXcIA_2oZJPr2bH4Khwns7KNXL7Su1xY5VWnf5Qcx8E10ITOuezr4gkloY3vfR1wcbK4VSwc33bPpxtasvt_iePzIgWIomgaQW_J__Kyh7dTHiJqxk- Received: from [75.158.17.63] by web51805.mail.re2.yahoo.com via HTTP; Sat, 09 Jan 2010 16:04:34 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 Date: Sat, 9 Jan 2010 16:04:34 -0800 (PST) From: PseudoCylon To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Calling for testers if_run rt3572 support 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, 10 Jan 2010 00:04:37 -0000 Hello,=0A=0AI have added support for Ralink RT3572 to if_run. The driver ca= n be downloaded from=0Ahttp://forums.freebsd.org/showpost.php?s=3Dedf3f3360= fa9264c6cb40fef9ab98fab&p=3D44110&postcount=3D1=0A=0AKnown device with that= chip is Linksys WUSB600N ver.2. (Ver. 1, already supported, has plain rec= tangular shape, ver.2 has wedge like shape.)=0A=0AIt's been downloaded 10+ = times, and only complain I have received is about debug flag in Makefile. S= o, I optimistically assume it is working. But, user discretion is advised.= =0A=0AOtherwise, the driver now supports h/w encryption.=0A=0AHappy new yea= r.=0A=0AAkinori=0A=0A=0A=0A __________________________________________= ________________________=0AThe new Internet Explorer=AE 8 - Faster, safer, = easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yah= oo.com/ca/internetexplorer/ From owner-freebsd-current@FreeBSD.ORG Sat Jan 9 16:04:12 2010 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 6742D106566C for ; Sat, 9 Jan 2010 16:04:12 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 4AAD28FC0A for ; Sat, 9 Jan 2010 16:04:12 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id ACE978C340; Sat, 9 Jan 2010 10:04:11 -0600 (CST) Date: Sat, 9 Jan 2010 10:04:11 -0600 From: Mark Linimon To: current@freebsd.org Message-ID: <20100109160411.GA16856@lonesome.com> References: <20100109153123.GD52442@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100109153123.GD52442@acme.spoerlein.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Sun, 10 Jan 2010 00:30:57 +0000 Cc: Mark Linimon Subject: Re: Clang Static Analyzer runs on the FreeBSD source 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: Sat, 09 Jan 2010 16:04:12 -0000 On Sat, Jan 09, 2010 at 04:31:23PM +0100, Ulrich Spörlein wrote: > PS: what happened to the Coverity runs on FreeBSD? The machine that it runs on needs maintenance (again). I'm simply too swamped to take on the task, myself. mcl From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 05:41:29 2010 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 D6C4C106566B; Sun, 10 Jan 2010 05:41:29 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id A3C658FC15; Sun, 10 Jan 2010 05:41:29 +0000 (UTC) Received: by pwi15 with SMTP id 15so891986pwi.3 for ; Sat, 09 Jan 2010 21:41:21 -0800 (PST) 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=bFRoPIFhxtuf8DaqWfOMxrOGAP4y118kq87RB2z8n2A=; b=cNja2aAgdIMlidLGALwH3U8iKcrTbMqGfceNwlyEJ4W0LePtUdM555tvyBHugjiTKK MiXqQliWrpPpnUotGTz4g2Moq7SEi4nSRmBOLhhUq4FiCP1ivjW63xyCe4H3wpgxyC+p ztYqqp1dvHStBQRGtg6Z1DVpw/bkM86w+3a34= 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=lhvUa+o4dlHhEmv1AzTjQt5OFKjlyGKegvOAVFj4n8KTCI3ECwxHz0Q83IeI9+Ni+g x1W5zCxXSdEMOu8jgQEZ2orwIrTBP1hpZ6Q5ltZqCod5dKHbu+lMP1aRTnD5Q0RmhrqK n6iq7HlZSCQ80ZSTOkUZ+YOBufFFObr9q11Z8= MIME-Version: 1.0 Received: by 10.114.45.10 with SMTP id s10mr20096792was.76.1263102081216; Sat, 09 Jan 2010 21:41:21 -0800 (PST) In-Reply-To: <20100107040600.GN1491@weongyo> References: <20091223035331.GA1293@weongyo> <426bed111001021900i4ed55836u456a12f6c578df72@mail.gmail.com> <20100107025727.GJ1491@weongyo> <426bed111001061938j70d2846bk19375f6369c2c102@mail.gmail.com> <20100107040600.GN1491@weongyo> Date: Sun, 10 Jan 2010 18:41:21 +1300 Message-ID: <426bed111001092141w3bdff099y635532961436fcf9@mail.gmail.com> From: Rohit Grover To: Weongyo Jeong , Rohit Grover , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver 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, 10 Jan 2010 05:41:29 -0000 Hi, > Please try attached patch in bwn_probe() and show me dmesg output. =A0If > bwn(4) doesn't print anything that means ssb(4) works incorrectly. =A0But > there are some outputs and bwn(4) doesn't be attached then your device > revision isn't supported. > After applying your patch, I get the following upon loading if_bwn: bwn0: vendor 0x4243 cid 0x812 rev 12 Therefore, I should infer that the device revision isn't supported? Do you know when this device might be supported? regards, Rohit. From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 06:16:19 2010 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 A52631065670 for ; Sun, 10 Jan 2010 06:16:19 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 526F48FC14 for ; Sun, 10 Jan 2010 06:16:19 +0000 (UTC) Received: by qyk4 with SMTP id 4so8973460qyk.7 for ; Sat, 09 Jan 2010 22:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=2hJsCtPQ3Eks+M+mQ1JnPccAYypL/mqLCM+z+FLCLbg=; b=SH+pqp43N3J1xuVuiv3pDhU3/4YDOzspq9HsAVuddBof4uicI9BkYXnLa9W0wERVNT 2jZLTEabxkPb0En3fu7/0gdsc8G/VZYKhmfO4GDQFCDtbO1L8mOQrifkVy36zkqwecBy /Vqx89tTxLKOhQhZgk9/4M/MZBV3/h8DKCf64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=cmWpAZI+EGT4UxgdFE0Vt/hs6TI8tFplgzyv1at+YioYD5QaDUWtSa3gabdlAD8XLR 2zyx4BmtYNuCjLjRGgr2Mq6tWaAsx3ppGQ/mNjJx2hT/eEpffQfFc9XlSjMqk/Ik6+4c JzZ3WN2B9loYjjEExznnUYn8Z8FBRLM4LiWzE= Received: by 10.224.113.129 with SMTP id a1mr15597945qaq.325.1263104171156; Sat, 09 Jan 2010 22:16:11 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 23sm21021176qyk.11.2010.01.09.22.16.09 (version=SSLv3 cipher=RC4-MD5); Sat, 09 Jan 2010 22:16:10 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Sat, 9 Jan 2010 22:16:31 -0800 From: Weongyo Jeong Date: Sat, 9 Jan 2010 22:16:31 -0800 To: Rohit Grover Message-ID: <20100110061631.GT1491@weongyo> Mail-Followup-To: Rohit Grover , current@freebsd.org References: <20091223035331.GA1293@weongyo> <426bed111001021900i4ed55836u456a12f6c578df72@mail.gmail.com> <20100107025727.GJ1491@weongyo> <426bed111001061938j70d2846bk19375f6369c2c102@mail.gmail.com> <20100107040600.GN1491@weongyo> <426bed111001092141w3bdff099y635532961436fcf9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426bed111001092141w3bdff099y635532961436fcf9@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2010 06:16:19 -0000 On Sun, Jan 10, 2010 at 06:41:21PM +1300, Rohit Grover wrote: > Hi, > > > Please try attached patch in bwn_probe() and show me dmesg output. ?If > > bwn(4) doesn't print anything that means ssb(4) works incorrectly. ?But > > there are some outputs and bwn(4) doesn't be attached then your device > > revision isn't supported. > > > > > After applying your patch, I get the following upon loading if_bwn: > > bwn0: vendor 0x4243 cid 0x812 rev 12 > > Therefore, I should infer that the device revision isn't supported? Yes it looks your revision isn't supported. > Do you know when this device might be supported? I think it could be supported when bwn(4) supports N PHYs I hope. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 08:16:07 2010 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 E55D81065676 for ; Sun, 10 Jan 2010 08:16:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 76D1F8FC13 for ; Sun, 10 Jan 2010 08:16:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=xXlNdsELG8cA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=_zQkF8jxpSXiDZwJCwgA:9 a=CKwPMOitreYqeTloeZMA:7 a=amI_YXeZLsqBR2EenVFZGudJ2S4A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1344794927; Sun, 10 Jan 2010 09:16:05 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 10 Jan 2010 09:14:44 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <191118.3035.qm@web51805.mail.re2.yahoo.com> In-Reply-To: <191118.3035.qm@web51805.mail.re2.yahoo.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001100914.44534.hselasky@c2i.net> Cc: PseudoCylon Subject: Re: Calling for testers if_run rt3572 support 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, 10 Jan 2010 08:16:08 -0000 On Sunday 10 January 2010 01:04:34 PseudoCylon wrote: > Akinori Hi, I've added your driver to USB P4. Please check that the files are correct. http://p4web.freebsd.org/chv.cgi?CH=172906 http://perforce.freebsd.org/chv.cgi?CH=172906 I see some code which is not correct, which I will fix for you. After that please fetch back the code and integrate. Hope you are willing to maintain this driver. Thanks for your porting effort. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 09:30:22 2010 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 E1ED5106568B; Sun, 10 Jan 2010 09:30:22 +0000 (UTC) (envelope-from rgrover1@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id AF7BB8FC19; Sun, 10 Jan 2010 09:30:22 +0000 (UTC) Received: by pwi15 with SMTP id 15so945135pwi.3 for ; Sun, 10 Jan 2010 01:30:13 -0800 (PST) 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; bh=VtmWd1javHNhhQbmMGofJdeJSOMcp7OelJ86IsEfw4w=; b=W3LSWo7ubAGRsL5/fUWDNprZWMFR3iP9WPBlfFJkMFCzRBe8grAQrJgyBokTYn+UGo 2QP3i/z6tknaYYzZ0tFdR6xsi4h01gqqAG4S8wgKnu7a8MW6VQFYatzbaI8D75P9KKxj CKOMlJbIqCA/Z66gqEObZwBiBb+neWgdUkLj0= 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; b=N+Sd0xwtn3lLNLU3mZ6SV8bo5LK7iV+xHobQ5edYW/Vvke7pHWcMFZOYHaiJN4BOCJ NfjVglZhnSJqONylNsxR4vBDXHImM47fSpP2zyNrIC0UyGF4pdtTeyoAovYx7steca5b eGLwRJ2S92OYVjzmraxBOcBPwPhRqqY1y9uSw= MIME-Version: 1.0 Received: by 10.114.188.13 with SMTP id l13mr12277845waf.107.1263115813606; Sun, 10 Jan 2010 01:30:13 -0800 (PST) In-Reply-To: <20100110061631.GT1491@weongyo> References: <20091223035331.GA1293@weongyo> <426bed111001021900i4ed55836u456a12f6c578df72@mail.gmail.com> <20100107025727.GJ1491@weongyo> <426bed111001061938j70d2846bk19375f6369c2c102@mail.gmail.com> <20100107040600.GN1491@weongyo> <426bed111001092141w3bdff099y635532961436fcf9@mail.gmail.com> <20100110061631.GT1491@weongyo> Date: Sun, 10 Jan 2010 22:30:13 +1300 Message-ID: <426bed111001100130u61bbeb03s242dd012abc76a5@mail.gmail.com> From: Rohit Grover To: Weongyo Jeong , Rohit Grover , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver 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, 10 Jan 2010 09:30:23 -0000 Hi Weongyo, On Sun, Jan 10, 2010 at 7:16 PM, Weongyo Jeong wrote: > On Sun, Jan 10, 2010 at 06:41:21PM +1300, Rohit Grover wrote: >> Hi, >> >> > Please try attached patch in bwn_probe() and show me dmesg output. ?If >> > bwn(4) doesn't print anything that means ssb(4) works incorrectly. ?But >> > there are some outputs and bwn(4) doesn't be attached then your device >> > revision isn't supported. >> > >> >> >> After applying your patch, I get the following upon loading if_bwn: >> >> bwn0: vendor 0x4243 cid 0x812 rev 12 >> >> Therefore, I should infer that the device revision isn't supported? > > Yes it looks your revision isn't supported. > >> Do you know when this device might be supported? > > I think it could be supported when bwn(4) supports N PHYs I hope. Not being able to use the wireless hardware on my current laptop with FreeBSD has caused me inconvenience to the point where I am seriously contemplating the purchase of a new laptop. Is there even a remote possibility that you may be able to estimate when bwn(4) may be able to support such hardware? regards, From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 11:53:53 2010 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 8F67F106566B; Sun, 10 Jan 2010 11:53:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id E4B4A8FC08; Sun, 10 Jan 2010 11:53:52 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=xXlNdsELG8cA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=TI0TRueoZt3fEjAi2gcA:9 a=kl6nCDW7HzNwLMdbmn0A:7 a=5I_oNRgjfD03aypmboCDc8K4eIQA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1327105130; Sun, 10 Jan 2010 12:53:51 +0100 To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org From: Hans Petter Selasky X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' Date: Sun, 10 Jan 2010 12:52:24 +0100 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001101252.24922.hselasky@c2i.net> Cc: PseudoCylon Subject: Re: Calling for testers if_run rt3572 support 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, 10 Jan 2010 11:53:53 -0000 On Sunday 10 January 2010 01:04:34 PseudoCylon wrote: > Akinori Hi, Can you test and verify the following changes to your if_run driver? http://p4web.freebsd.org/chv.cgi?CH=172914 http://perforce.freebsd.org/chv.cgi?CH=172914 And provide patches if something was broken. Please try to resolve the remaining XXX marks. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 13:26:56 2010 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 6AC35106566C for ; Sun, 10 Jan 2010 13:26:56 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from smtp3.apollo.lv (smtp3.apollo.lv [80.232.168.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC9F8FC13 for ; Sun, 10 Jan 2010 13:26:53 +0000 (UTC) Received: from [95.68.120.242] (unknown [95.68.120.242]) by smtp3.apollo.lv (Postfix) with ESMTP id 14D529FDDD for ; Sun, 10 Jan 2010 15:26:50 +0200 (EET) From: Dmitriy Demidov Date: Sun, 10 Jan 2010 15:26:49 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Disposition: inline To: freebsd-current@freebsd.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201001101526.49411.dima_bsd@inbox.lv> X-Brightmail-Tracker: AAAAAA== Subject: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 13:26:56 -0000 Error while building world on today's CURRENT. Patch applied without errors. make buildworld ends with: == mkdep -f .depend -a -DRESCUE /usr/src/sbin/atacontrol/atacontrol.c echo atacontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/atacontrol/atacontrol.c (cd /usr/src/rescue/rescue/../../sbin/badsect && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ badsect.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/badsect/badsect.c echo badsect: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/badsect/badsect.c (cd /usr/src/rescue/rescue/../../sbin/camcontrol && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ camcontrol.o util.o modeedit.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/camcontrol/camcontrol.c /usr/src/sbin/camcontrol/util.c /usr/src/sbin/camcontrol/modeedit.c echo camcontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libcam.a /usr/obj/usr/src/tmp/usr/lib/libsbuf.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/camcontrol.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/util.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/modeedit.c (cd /usr/src/rescue/rescue/../../sbin/ccdconfig && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ ccdconfig.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/ccdconfig/ccdconfig.c echo ccdconfig: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libgeom.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/ccdconfig/ccdconfig.c (cd /usr/src/rescue/rescue/../../sbin/clri && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ clri.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/clri/clri.c echo clri: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/clri/clri.c (cd /usr/src/rescue/rescue/../../sbin/devfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ devfs.o rule.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/devfs/devfs.c /usr/src/sbin/devfs/rule.c echo devfs: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/devfs.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/rule.c (cd /usr/src/rescue/rescue/../../sbin/dmesg && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ dmesg.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dmesg/dmesg.c echo dmesg: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libkvm.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dmesg/dmesg.c (cd /usr/src/rescue/rescue/../../sbin/dump && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ itime.o main.o optr.o dumprmt.o tape.o traverse.o unctime.o cache.o) rm -f .depend mkdep -f .depend -a -DRDUMP -DRESCUE /usr/src/sbin/dump/itime.c /usr/src/sbin/dump/main.c /usr/src/sbin/dump/optr.c /usr/src/sbin/dump/dumprmt.c /usr/src/sbin/dump/tape.c /usr/src/sbin/dump/traverse.c /usr/src/sbin/dump/unctime.c /usr/src/sbin/dump/cache.c echo dump: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/itime.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/main.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/optr.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/dumprmt.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/tape.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/traverse.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/unctime.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/cache.c (cd /usr/src/rescue/rescue/../../sbin/dumpfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ dumpfs.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpfs/dumpfs.c echo dumpfs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dumpfs/dumpfs.c (cd /usr/src/rescue/rescue/../../sbin/dumpon && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ dumpon.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpon/dumpon.c echo dumpon: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dumpon/dumpon.c (cd /usr/src/rescue/rescue/../../sbin/fsck && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ fsck.o fsutil.o preen.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/fsck/fsck.c /usr/src/sbin/fsck/fsutil.c /usr/src/sbin/fsck/preen.c echo fsck: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsck.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsutil.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/preen.c (cd /usr/src/rescue/rescue/../../sbin/fsck_ffs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ dir.o ea.o fsutil.o inode.o main.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o setup.o suj.o utilities.o gjournal.o getmntopts.o) rm -f .depend mkdep -f .depend -a -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -DRESCUE /usr/src/sbin/fsck_ffs/dir.c /usr/src/sbin/fsck_ffs/ea.c /usr/src/sbin/fsck_ffs/fsutil.c /usr/src/sbin/fsck_ffs/inode.c /usr/src/sbin/fsck_ffs/main.c /usr/src/sbin/fsck_ffs/pass1.c /usr/src/sbin/fsck_ffs/pass1b.c /usr/src/sbin/fsck_ffs/pass2.c /usr/src/sbin/fsck_ffs/pass3.c /usr/src/sbin/fsck_ffs/pass4.c /usr/src/sbin/fsck_ffs/pass5.c /usr/src/sbin/fsck_ffs/setup.c /usr/src/sbin/fsck_ffs/suj.c /usr/src/sbin/fsck_ffs/utilities.c /usr/src/sbin/fsck_ffs/gjournal.c /usr/src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/dir.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/ea.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/fsutil.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/inode.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/main.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1b.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass2.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass3.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass4.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass5.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/setup.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c In file included from /usr/src/sbin/fsck_ffs/suj.c:1982: /usr/src/sbin/fsck_ffs/fsck.h:72: error: redefinition of 'union dinode' /usr/src/sbin/fsck_ffs/fsck.h:94: error: redefinition of 'struct inostat' /usr/src/sbin/fsck_ffs/fsck.h:121: error: redefinition of 'struct inostatlist' /usr/src/sbin/fsck_ffs/fsck.h:129: error: redefinition of 'struct bufarea' /usr/src/sbin/fsck_ffs/fsck.h:185: error: nested redefinition of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'DONTKNOW' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'DONTKNOW' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'NOFIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'NOFIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'FIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'FIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'IGNORE' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'IGNORE' was here /usr/src/sbin/fsck_ffs/fsck.h:188: error: redefinition of 'struct inodesc' /usr/src/sbin/fsck_ffs/fsck.h:230: error: redefinition of 'struct dups' /usr/src/sbin/fsck_ffs/fsck.h:240: error: redefinition of 'struct inoinfo' /usr/src/sbin/fsck_ffs/suj.c:1990: error: redefinition of 'struct suj_seg' /usr/src/sbin/fsck_ffs/suj.c:1996: error: redefinition of 'struct suj_rec' /usr/src/sbin/fsck_ffs/suj.c:2000: error: redefinition of 'struct srechd' /usr/src/sbin/fsck_ffs/suj.c:2002: error: redefinition of 'struct suj_ino' /usr/src/sbin/fsck_ffs/suj.c:2012: error: redefinition of 'struct inohd' /usr/src/sbin/fsck_ffs/suj.c:2014: error: redefinition of 'struct suj_blk' /usr/src/sbin/fsck_ffs/suj.c:2019: error: redefinition of 'struct blkhd' /usr/src/sbin/fsck_ffs/suj.c:2021: error: redefinition of 'struct data_blk' /usr/src/sbin/fsck_ffs/suj.c:2028: error: redefinition of 'struct ino_blk' /usr/src/sbin/fsck_ffs/suj.c:2034: error: redefinition of 'struct iblkhd' /usr/src/sbin/fsck_ffs/suj.c:2036: error: redefinition of 'struct suj_cg' /usr/src/sbin/fsck_ffs/suj.c:2048: error: redefinition of 'struct cghd' /usr/src/sbin/fsck_ffs/suj.c:2049: error: redefinition of 'struct dblkhd' /usr/src/sbin/fsck_ffs/suj.c:2051: error: redefinition of 'struct seghd' /usr/src/sbin/fsck_ffs/suj.c:2053: error: redefinition of 'disk' /usr/src/sbin/fsck_ffs/suj.c:119: error: previous definition of 'disk' was here /usr/src/sbin/fsck_ffs/suj.c:2054: error: redefinition of 'fs' /usr/src/sbin/fsck_ffs/suj.c:120: error: previous definition of 'fs' was here /usr/src/sbin/fsck_ffs/suj.c:2064: error: redefinition of typedef 'ino_visitor' /usr/src/sbin/fsck_ffs/suj.c:130: error: previous declaration of 'ino_visitor' was here /usr/src/sbin/fsck_ffs/suj.c:2068: error: redefinition of 'errmalloc' /usr/src/sbin/fsck_ffs/suj.c:134: error: previous definition of 'errmalloc' was here /usr/src/sbin/fsck_ffs/suj.c:2082: error: redefinition of 'opendisk' /usr/src/sbin/fsck_ffs/suj.c:148: error: previous definition of 'opendisk' was here /usr/src/sbin/fsck_ffs/suj.c:2106: error: redefinition of 'closedisk' /usr/src/sbin/fsck_ffs/suj.c:172: error: previous definition of 'closedisk' was here /usr/src/sbin/fsck_ffs/suj.c:2142: error: redefinition of 'cg_lookup' /usr/src/sbin/fsck_ffs/suj.c:208: error: previous definition of 'cg_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2173: error: redefinition of 'ino_lookup' /usr/src/sbin/fsck_ffs/suj.c:239: error: previous definition of 'ino_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2201: error: redefinition of 'blk_lookup' /usr/src/sbin/fsck_ffs/suj.c:267: error: previous definition of 'blk_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2224: error: redefinition of 'dblk_read' /usr/src/sbin/fsck_ffs/suj.c:290: error: previous definition of 'dblk_read' was here /usr/src/sbin/fsck_ffs/suj.c:2257: error: redefinition of 'ino_read' /usr/src/sbin/fsck_ffs/suj.c:323: error: previous definition of 'ino_read' was here /usr/src/sbin/fsck_ffs/suj.c:2291: error: redefinition of 'ino_dirty' /usr/src/sbin/fsck_ffs/suj.c:357: error: previous definition of 'ino_dirty' was here /usr/src/sbin/fsck_ffs/suj.c:2317: error: redefinition of 'iblk_write' /usr/src/sbin/fsck_ffs/suj.c:383: error: previous definition of 'iblk_write' was here /usr/src/sbin/fsck_ffs/suj.c:2331: error: redefinition of 'ino_isfree' /usr/src/sbin/fsck_ffs/suj.c:397: error: previous definition of 'ino_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:2347: error: redefinition of 'blk_overlaps' /usr/src/sbin/fsck_ffs/suj.c:413: error: previous definition of 'blk_overlaps' was here /usr/src/sbin/fsck_ffs/suj.c:2363: error: redefinition of 'blk_equals' /usr/src/sbin/fsck_ffs/suj.c:429: error: previous definition of 'blk_equals' was here /usr/src/sbin/fsck_ffs/suj.c:2376: error: redefinition of 'blk_setmask' /usr/src/sbin/fsck_ffs/suj.c:442: error: previous definition of 'blk_setmask' was here /usr/src/sbin/fsck_ffs/suj.c:2393: error: redefinition of 'blk_isfree' /usr/src/sbin/fsck_ffs/suj.c:459: error: previous definition of 'blk_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:2443: error: redefinition of 'blk_isindir' /usr/src/sbin/fsck_ffs/suj.c:509: error: previous definition of 'blk_isindir' was here /usr/src/sbin/fsck_ffs/suj.c:2465: error: redefinition of 'ino_free' /usr/src/sbin/fsck_ffs/suj.c:531: error: previous definition of 'ino_free' was here /usr/src/sbin/fsck_ffs/suj.c:2502: error: redefinition of 'blk_free' /usr/src/sbin/fsck_ffs/suj.c:568: error: previous definition of 'blk_free' was here /usr/src/sbin/fsck_ffs/suj.c:2546: error: redefinition of 'indir_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:612: error: previous definition of 'indir_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:2597: error: redefinition of 'ino_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:663: error: previous definition of 'ino_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:2654: error: redefinition of 'blk_isat' /usr/src/sbin/fsck_ffs/suj.c:720: error: previous definition of 'blk_isat' was here /usr/src/sbin/fsck_ffs/suj.c:2673: error: redefinition of 'ino_isat' /usr/src/sbin/fsck_ffs/suj.c:739: error: previous definition of 'ino_isat' was here /usr/src/sbin/fsck_ffs/suj.c:2766: error: redefinition of 'indir_visit' /usr/src/sbin/fsck_ffs/suj.c:832: error: previous definition of 'indir_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2827: error: redefinition of 'ino_visit' /usr/src/sbin/fsck_ffs/suj.c:893: error: previous definition of 'ino_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2877: error: redefinition of 'null_visit' /usr/src/sbin/fsck_ffs/suj.c:943: error: previous definition of 'null_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2888: error: redefinition of 'ino_adjblks' /usr/src/sbin/fsck_ffs/suj.c:954: error: previous definition of 'ino_adjblks' was here /usr/src/sbin/fsck_ffs/suj.c:2915: error: redefinition of 'blk_free_visit' /usr/src/sbin/fsck_ffs/suj.c:981: error: previous definition of 'blk_free_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2931: error: redefinition of 'blk_free_lbn' /usr/src/sbin/fsck_ffs/suj.c:997: error: previous definition of 'blk_free_lbn' was here /usr/src/sbin/fsck_ffs/suj.c:2947: error: redefinition of 'ino_free_children' /usr/src/sbin/fsck_ffs/suj.c:1013: error: previous definition of 'ino_free_children' was here /usr/src/sbin/fsck_ffs/suj.c:3019: error: redefinition of 'ino_truncate' /usr/src/sbin/fsck_ffs/suj.c:1085: error: previous definition of 'ino_truncate' was here /usr/src/sbin/fsck_ffs/suj.c:3057: error: redefinition of 'ino_decr' /usr/src/sbin/fsck_ffs/suj.c:1123: error: previous definition of 'ino_decr' was here /usr/src/sbin/fsck_ffs/suj.c:3092: error: redefinition of 'ino_adjust' /usr/src/sbin/fsck_ffs/suj.c:1158: error: previous definition of 'ino_adjust' was here /usr/src/sbin/fsck_ffs/suj.c:3143: error: redefinition of 'ino_check' /usr/src/sbin/fsck_ffs/suj.c:1209: error: previous definition of 'ino_check' was here /usr/src/sbin/fsck_ffs/suj.c:3229: error: redefinition of 'blk_check' /usr/src/sbin/fsck_ffs/suj.c:1295: error: previous definition of 'blk_check' was here /usr/src/sbin/fsck_ffs/suj.c:3287: error: redefinition of 'cg_check' /usr/src/sbin/fsck_ffs/suj.c:1353: error: previous definition of 'cg_check' was here /usr/src/sbin/fsck_ffs/suj.c:3313: error: redefinition of 'cg_write' /usr/src/sbin/fsck_ffs/suj.c:1379: error: previous definition of 'cg_write' was here /usr/src/sbin/fsck_ffs/suj.c:3367: error: redefinition of 'cg_apply' /usr/src/sbin/fsck_ffs/suj.c:1433: error: previous definition of 'cg_apply' was here /usr/src/sbin/fsck_ffs/suj.c:3384: error: redefinition of 'suj_build_ino' /usr/src/sbin/fsck_ffs/suj.c:1450: error: previous definition of 'suj_build_ino' was here /usr/src/sbin/fsck_ffs/suj.c:3420: error: redefinition of 'suj_move_ino' /usr/src/sbin/fsck_ffs/suj.c:1486: error: previous definition of 'suj_move_ino' was here /usr/src/sbin/fsck_ffs/suj.c:3458: error: redefinition of 'suj_build_blk' /usr/src/sbin/fsck_ffs/suj.c:1524: error: previous definition of 'suj_build_blk' was here /usr/src/sbin/fsck_ffs/suj.c:3511: error: redefinition of 'suj_build' /usr/src/sbin/fsck_ffs/suj.c:1577: error: previous definition of 'suj_build' was here /usr/src/sbin/fsck_ffs/suj.c:3551: error: redefinition of 'suj_prune' /usr/src/sbin/fsck_ffs/suj.c:1617: error: previous definition of 'suj_prune' was here /usr/src/sbin/fsck_ffs/suj.c:3612: error: redefinition of 'suj_verifyino' /usr/src/sbin/fsck_ffs/suj.c:1678: error: previous definition of 'suj_verifyino' was here /usr/src/sbin/fsck_ffs/suj.c:3631: error: redefinition of 'struct jblocks' /usr/src/sbin/fsck_ffs/suj.c:3638: error: redefinition of 'struct jextent' /usr/src/sbin/fsck_ffs/suj.c:3647: error: redefinition of 'jblocks_create' /usr/src/sbin/fsck_ffs/suj.c:1713: error: previous definition of 'jblocks_create' was here /usr/src/sbin/fsck_ffs/suj.c:3669: error: redefinition of 'jblocks_next' /usr/src/sbin/fsck_ffs/suj.c:1735: error: previous definition of 'jblocks_next' was here /usr/src/sbin/fsck_ffs/suj.c:3699: error: redefinition of 'jblocks_advance' /usr/src/sbin/fsck_ffs/suj.c:1765: error: previous definition of 'jblocks_advance' was here /usr/src/sbin/fsck_ffs/suj.c:3706: error: redefinition of 'jblocks_destroy' /usr/src/sbin/fsck_ffs/suj.c:1772: error: previous definition of 'jblocks_destroy' was here /usr/src/sbin/fsck_ffs/suj.c:3714: error: redefinition of 'jblocks_add' /usr/src/sbin/fsck_ffs/suj.c:1780: error: previous definition of 'jblocks_add' was here /usr/src/sbin/fsck_ffs/suj.c:3755: error: redefinition of 'suj_add_block' /usr/src/sbin/fsck_ffs/suj.c:1821: error: previous definition of 'suj_add_block' was here /usr/src/sbin/fsck_ffs/suj.c:3762: error: redefinition of 'suj_read' /usr/src/sbin/fsck_ffs/suj.c:1828: error: previous definition of 'suj_read' was here /usr/src/sbin/fsck_ffs/suj.c:3830: error: redefinition of 'suj_check' /usr/src/sbin/fsck_ffs/suj.c:1896: error: previous definition of 'suj_check' was here In file included from /usr/src/sbin/fsck_ffs/suj.c:3916: /usr/src/sbin/fsck_ffs/fsck.h:72: error: redefinition of 'union dinode' /usr/src/sbin/fsck_ffs/fsck.h:94: error: redefinition of 'struct inostat' /usr/src/sbin/fsck_ffs/fsck.h:121: error: redefinition of 'struct inostatlist' /usr/src/sbin/fsck_ffs/fsck.h:129: error: redefinition of 'struct bufarea' /usr/src/sbin/fsck_ffs/fsck.h:185: error: nested redefinition of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'DONTKNOW' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'DONTKNOW' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'NOFIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'NOFIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'FIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'FIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'IGNORE' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'IGNORE' was here /usr/src/sbin/fsck_ffs/fsck.h:188: error: redefinition of 'struct inodesc' /usr/src/sbin/fsck_ffs/fsck.h:230: error: redefinition of 'struct dups' /usr/src/sbin/fsck_ffs/fsck.h:240: error: redefinition of 'struct inoinfo' /usr/src/sbin/fsck_ffs/suj.c:3924: error: redefinition of 'struct suj_seg' /usr/src/sbin/fsck_ffs/suj.c:3930: error: redefinition of 'struct suj_rec' /usr/src/sbin/fsck_ffs/suj.c:3934: error: redefinition of 'struct srechd' /usr/src/sbin/fsck_ffs/suj.c:3936: error: redefinition of 'struct suj_ino' /usr/src/sbin/fsck_ffs/suj.c:3946: error: redefinition of 'struct inohd' /usr/src/sbin/fsck_ffs/suj.c:3948: error: redefinition of 'struct suj_blk' /usr/src/sbin/fsck_ffs/suj.c:3953: error: redefinition of 'struct blkhd' /usr/src/sbin/fsck_ffs/suj.c:3955: error: redefinition of 'struct data_blk' /usr/src/sbin/fsck_ffs/suj.c:3962: error: redefinition of 'struct ino_blk' /usr/src/sbin/fsck_ffs/suj.c:3968: error: redefinition of 'struct iblkhd' /usr/src/sbin/fsck_ffs/suj.c:3970: error: redefinition of 'struct suj_cg' /usr/src/sbin/fsck_ffs/suj.c:3982: error: redefinition of 'struct cghd' /usr/src/sbin/fsck_ffs/suj.c:3983: error: redefinition of 'struct dblkhd' /usr/src/sbin/fsck_ffs/suj.c:3985: error: redefinition of 'struct seghd' /usr/src/sbin/fsck_ffs/suj.c:3987: error: redefinition of 'disk' /usr/src/sbin/fsck_ffs/suj.c:2053: error: previous definition of 'disk' was here /usr/src/sbin/fsck_ffs/suj.c:3988: error: redefinition of 'fs' /usr/src/sbin/fsck_ffs/suj.c:2054: error: previous definition of 'fs' was here /usr/src/sbin/fsck_ffs/suj.c:3998: error: redefinition of typedef 'ino_visitor' /usr/src/sbin/fsck_ffs/suj.c:2064: error: previous declaration of 'ino_visitor' was here /usr/src/sbin/fsck_ffs/suj.c:4002: error: redefinition of 'errmalloc' /usr/src/sbin/fsck_ffs/suj.c:2068: error: previous definition of 'errmalloc' was here /usr/src/sbin/fsck_ffs/suj.c:4016: error: redefinition of 'opendisk' /usr/src/sbin/fsck_ffs/suj.c:2082: error: previous definition of 'opendisk' was here /usr/src/sbin/fsck_ffs/suj.c:4040: error: redefinition of 'closedisk' /usr/src/sbin/fsck_ffs/suj.c:2106: error: previous definition of 'closedisk' was here /usr/src/sbin/fsck_ffs/suj.c:4076: error: redefinition of 'cg_lookup' /usr/src/sbin/fsck_ffs/suj.c:2142: error: previous definition of 'cg_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:4107: error: redefinition of 'ino_lookup' /usr/src/sbin/fsck_ffs/suj.c:2173: error: previous definition of 'ino_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:4135: error: redefinition of 'blk_lookup' /usr/src/sbin/fsck_ffs/suj.c:2201: error: previous definition of 'blk_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:4158: error: redefinition of 'dblk_read' /usr/src/sbin/fsck_ffs/suj.c:2224: error: previous definition of 'dblk_read' was here /usr/src/sbin/fsck_ffs/suj.c:4191: error: redefinition of 'ino_read' /usr/src/sbin/fsck_ffs/suj.c:2257: error: previous definition of 'ino_read' was here /usr/src/sbin/fsck_ffs/suj.c:4225: error: redefinition of 'ino_dirty' /usr/src/sbin/fsck_ffs/suj.c:2291: error: previous definition of 'ino_dirty' was here /usr/src/sbin/fsck_ffs/suj.c:4251: error: redefinition of 'iblk_write' /usr/src/sbin/fsck_ffs/suj.c:2317: error: previous definition of 'iblk_write' was here /usr/src/sbin/fsck_ffs/suj.c:4265: error: redefinition of 'ino_isfree' /usr/src/sbin/fsck_ffs/suj.c:2331: error: previous definition of 'ino_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:4281: error: redefinition of 'blk_overlaps' /usr/src/sbin/fsck_ffs/suj.c:2347: error: previous definition of 'blk_overlaps' was here /usr/src/sbin/fsck_ffs/suj.c:4297: error: redefinition of 'blk_equals' /usr/src/sbin/fsck_ffs/suj.c:2363: error: previous definition of 'blk_equals' was here /usr/src/sbin/fsck_ffs/suj.c:4310: error: redefinition of 'blk_setmask' /usr/src/sbin/fsck_ffs/suj.c:2376: error: previous definition of 'blk_setmask' was here /usr/src/sbin/fsck_ffs/suj.c:4327: error: redefinition of 'blk_isfree' /usr/src/sbin/fsck_ffs/suj.c:2393: error: previous definition of 'blk_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:4377: error: redefinition of 'blk_isindir' /usr/src/sbin/fsck_ffs/suj.c:2443: error: previous definition of 'blk_isindir' was here /usr/src/sbin/fsck_ffs/suj.c:4399: error: redefinition of 'ino_free' /usr/src/sbin/fsck_ffs/suj.c:2465: error: previous definition of 'ino_free' was here /usr/src/sbin/fsck_ffs/suj.c:4436: error: redefinition of 'blk_free' /usr/src/sbin/fsck_ffs/suj.c:2502: error: previous definition of 'blk_free' was here /usr/src/sbin/fsck_ffs/suj.c:4480: error: redefinition of 'indir_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:2546: error: previous definition of 'indir_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:4531: error: redefinition of 'ino_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:2597: error: previous definition of 'ino_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:4588: error: redefinition of 'blk_isat' /usr/src/sbin/fsck_ffs/suj.c:2654: error: previous definition of 'blk_isat' was here /usr/src/sbin/fsck_ffs/suj.c:4607: error: redefinition of 'ino_isat' /usr/src/sbin/fsck_ffs/suj.c:2673: error: previous definition of 'ino_isat' was here /usr/src/sbin/fsck_ffs/suj.c:4700: error: redefinition of 'indir_visit' /usr/src/sbin/fsck_ffs/suj.c:2766: error: previous definition of 'indir_visit' was here /usr/src/sbin/fsck_ffs/suj.c:4761: error: redefinition of 'ino_visit' /usr/src/sbin/fsck_ffs/suj.c:2827: error: previous definition of 'ino_visit' was here /usr/src/sbin/fsck_ffs/suj.c:4811: error: redefinition of 'null_visit' /usr/src/sbin/fsck_ffs/suj.c:2877: error: previous definition of 'null_visit' was here /usr/src/sbin/fsck_ffs/suj.c:4822: error: redefinition of 'ino_adjblks' /usr/src/sbin/fsck_ffs/suj.c:2888: error: previous definition of 'ino_adjblks' was here /usr/src/sbin/fsck_ffs/suj.c:4849: error: redefinition of 'blk_free_visit' /usr/src/sbin/fsck_ffs/suj.c:2915: error: previous definition of 'blk_free_visit' was here /usr/src/sbin/fsck_ffs/suj.c:4865: error: redefinition of 'blk_free_lbn' /usr/src/sbin/fsck_ffs/suj.c:2931: error: previous definition of 'blk_free_lbn' was here /usr/src/sbin/fsck_ffs/suj.c:4881: error: redefinition of 'ino_free_children' /usr/src/sbin/fsck_ffs/suj.c:2947: error: previous definition of 'ino_free_children' was here /usr/src/sbin/fsck_ffs/suj.c:4953: error: redefinition of 'ino_truncate' /usr/src/sbin/fsck_ffs/suj.c:3019: error: previous definition of 'ino_truncate' was here /usr/src/sbin/fsck_ffs/suj.c:4991: error: redefinition of 'ino_decr' /usr/src/sbin/fsck_ffs/suj.c:3057: error: previous definition of 'ino_decr' was here /usr/src/sbin/fsck_ffs/suj.c:5026: error: redefinition of 'ino_adjust' /usr/src/sbin/fsck_ffs/suj.c:3092: error: previous definition of 'ino_adjust' was here /usr/src/sbin/fsck_ffs/suj.c:5077: error: redefinition of 'ino_check' /usr/src/sbin/fsck_ffs/suj.c:3143: error: previous definition of 'ino_check' was here /usr/src/sbin/fsck_ffs/suj.c:5163: error: redefinition of 'blk_check' /usr/src/sbin/fsck_ffs/suj.c:3229: error: previous definition of 'blk_check' was here /usr/src/sbin/fsck_ffs/suj.c:5221: error: redefinition of 'cg_check' /usr/src/sbin/fsck_ffs/suj.c:3287: error: previous definition of 'cg_check' was here /usr/src/sbin/fsck_ffs/suj.c:5247: error: redefinition of 'cg_write' /usr/src/sbin/fsck_ffs/suj.c:3313: error: previous definition of 'cg_write' was here /usr/src/sbin/fsck_ffs/suj.c:5301: error: redefinition of 'cg_apply' /usr/src/sbin/fsck_ffs/suj.c:3367: error: previous definition of 'cg_apply' was here /usr/src/sbin/fsck_ffs/suj.c:5318: error: redefinition of 'suj_build_ino' /usr/src/sbin/fsck_ffs/suj.c:3384: error: previous definition of 'suj_build_ino' was here /usr/src/sbin/fsck_ffs/suj.c:5354: error: redefinition of 'suj_move_ino' /usr/src/sbin/fsck_ffs/suj.c:3420: error: previous definition of 'suj_move_ino' was here /usr/src/sbin/fsck_ffs/suj.c:5392: error: redefinition of 'suj_build_blk' /usr/src/sbin/fsck_ffs/suj.c:3458: error: previous definition of 'suj_build_blk' was here /usr/src/sbin/fsck_ffs/suj.c:5445: error: redefinition of 'suj_build' /usr/src/sbin/fsck_ffs/suj.c:3511: error: previous definition of 'suj_build' was here /usr/src/sbin/fsck_ffs/suj.c:5485: error: redefinition of 'suj_prune' /usr/src/sbin/fsck_ffs/suj.c:3551: error: previous definition of 'suj_prune' was here /usr/src/sbin/fsck_ffs/suj.c:5546: error: redefinition of 'suj_verifyino' /usr/src/sbin/fsck_ffs/suj.c:3612: error: previous definition of 'suj_verifyino' was here /usr/src/sbin/fsck_ffs/suj.c:5565: error: redefinition of 'struct jblocks' /usr/src/sbin/fsck_ffs/suj.c:5572: error: redefinition of 'struct jextent' /usr/src/sbin/fsck_ffs/suj.c:5581: error: redefinition of 'jblocks_create' /usr/src/sbin/fsck_ffs/suj.c:3647: error: previous definition of 'jblocks_create' was here /usr/src/sbin/fsck_ffs/suj.c:5603: error: redefinition of 'jblocks_next' /usr/src/sbin/fsck_ffs/suj.c:3669: error: previous definition of 'jblocks_next' was here /usr/src/sbin/fsck_ffs/suj.c:5633: error: redefinition of 'jblocks_advance' /usr/src/sbin/fsck_ffs/suj.c:3699: error: previous definition of 'jblocks_advance' was here /usr/src/sbin/fsck_ffs/suj.c:5640: error: redefinition of 'jblocks_destroy' /usr/src/sbin/fsck_ffs/suj.c:3706: error: previous definition of 'jblocks_destroy' was here /usr/src/sbin/fsck_ffs/suj.c:5648: error: redefinition of 'jblocks_add' /usr/src/sbin/fsck_ffs/suj.c:3714: error: previous definition of 'jblocks_add' was here /usr/src/sbin/fsck_ffs/suj.c:5689: error: redefinition of 'suj_add_block' /usr/src/sbin/fsck_ffs/suj.c:3755: error: previous definition of 'suj_add_block' was here /usr/src/sbin/fsck_ffs/suj.c:5696: error: redefinition of 'suj_read' /usr/src/sbin/fsck_ffs/suj.c:3762: error: previous definition of 'suj_read' was here /usr/src/sbin/fsck_ffs/suj.c:5764: error: redefinition of 'suj_check' /usr/src/sbin/fsck_ffs/suj.c:1896: error: previous definition of 'suj_check' was here In file included from /usr/src/sbin/fsck_ffs/suj.c:5850: /usr/src/sbin/fsck_ffs/fsck.h:72: error: redefinition of 'union dinode' /usr/src/sbin/fsck_ffs/fsck.h:94: error: redefinition of 'struct inostat' /usr/src/sbin/fsck_ffs/fsck.h:121: error: redefinition of 'struct inostatlist' /usr/src/sbin/fsck_ffs/fsck.h:129: error: redefinition of 'struct bufarea' /usr/src/sbin/fsck_ffs/fsck.h:185: error: nested redefinition of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'DONTKNOW' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'DONTKNOW' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'NOFIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'NOFIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'FIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'FIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'IGNORE' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'IGNORE' was here /usr/src/sbin/fsck_ffs/fsck.h:188: error: redefinition of 'struct inodesc' /usr/src/sbin/fsck_ffs/fsck.h:230: error: redefinition of 'struct dups' /usr/src/sbin/fsck_ffs/fsck.h:240: error: redefinition of 'struct inoinfo' /usr/src/sbin/fsck_ffs/suj.c:5858: error: redefinition of 'struct suj_seg' /usr/src/sbin/fsck_ffs/suj.c:5864: error: redefinition of 'struct suj_rec' /usr/src/sbin/fsck_ffs/suj.c:5868: error: redefinition of 'struct srechd' /usr/src/sbin/fsck_ffs/suj.c:5870: error: redefinition of 'struct suj_ino' /usr/src/sbin/fsck_ffs/suj.c:5880: error: redefinition of 'struct inohd' /usr/src/sbin/fsck_ffs/suj.c:5882: error: redefinition of 'struct suj_blk' /usr/src/sbin/fsck_ffs/suj.c:5887: error: redefinition of 'struct blkhd' /usr/src/sbin/fsck_ffs/suj.c:5889: error: redefinition of 'struct data_blk' /usr/src/sbin/fsck_ffs/suj.c:5896: error: redefinition of 'struct ino_blk' /usr/src/sbin/fsck_ffs/suj.c:5902: error: redefinition of 'struct iblkhd' /usr/src/sbin/fsck_ffs/suj.c:5904: error: redefinition of 'struct suj_cg' /usr/src/sbin/fsck_ffs/suj.c:5916: error: redefinition of 'struct cghd' /usr/src/sbin/fsck_ffs/suj.c:5917: error: redefinition of 'struct dblkhd' /usr/src/sbin/fsck_ffs/suj.c:5919: error: redefinition of 'struct seghd' /usr/src/sbin/fsck_ffs/suj.c:5921: error: redefinition of 'disk' /usr/src/sbin/fsck_ffs/suj.c:3987: error: previous definition of 'disk' was here /usr/src/sbin/fsck_ffs/suj.c:5922: error: redefinition of 'fs' /usr/src/sbin/fsck_ffs/suj.c:3988: error: previous definition of 'fs' was here /usr/src/sbin/fsck_ffs/suj.c:5932: error: redefinition of typedef 'ino_visitor' /usr/src/sbin/fsck_ffs/suj.c:3998: error: previous declaration of 'ino_visitor' was here /usr/src/sbin/fsck_ffs/suj.c:5936: error: redefinition of 'errmalloc' /usr/src/sbin/fsck_ffs/suj.c:4002: error: previous definition of 'errmalloc' was here /usr/src/sbin/fsck_ffs/suj.c:5950: error: redefinition of 'opendisk' /usr/src/sbin/fsck_ffs/suj.c:4016: error: previous definition of 'opendisk' was here /usr/src/sbin/fsck_ffs/suj.c:5974: error: redefinition of 'closedisk' /usr/src/sbin/fsck_ffs/suj.c:4040: error: previous definition of 'closedisk' was here /usr/src/sbin/fsck_ffs/suj.c:6010: error: redefinition of 'cg_lookup' /usr/src/sbin/fsck_ffs/suj.c:4076: error: previous definition of 'cg_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:6041: error: redefinition of 'ino_lookup' /usr/src/sbin/fsck_ffs/suj.c:4107: error: previous definition of 'ino_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:6069: error: redefinition of 'blk_lookup' /usr/src/sbin/fsck_ffs/suj.c:4135: error: previous definition of 'blk_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:6092: error: redefinition of 'dblk_read' /usr/src/sbin/fsck_ffs/suj.c:4158: error: previous definition of 'dblk_read' was here /usr/src/sbin/fsck_ffs/suj.c:6125: error: redefinition of 'ino_read' /usr/src/sbin/fsck_ffs/suj.c:4191: error: previous definition of 'ino_read' was here /usr/src/sbin/fsck_ffs/suj.c:6159: error: redefinition of 'ino_dirty' /usr/src/sbin/fsck_ffs/suj.c:4225: error: previous definition of 'ino_dirty' was here /usr/src/sbin/fsck_ffs/suj.c:6185: error: redefinition of 'iblk_write' /usr/src/sbin/fsck_ffs/suj.c:4251: error: previous definition of 'iblk_write' was here /usr/src/sbin/fsck_ffs/suj.c:6199: error: redefinition of 'ino_isfree' /usr/src/sbin/fsck_ffs/suj.c:4265: error: previous definition of 'ino_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:6215: error: redefinition of 'blk_overlaps' /usr/src/sbin/fsck_ffs/suj.c:4281: error: previous definition of 'blk_overlaps' was here /usr/src/sbin/fsck_ffs/suj.c:6231: error: redefinition of 'blk_equals' /usr/src/sbin/fsck_ffs/suj.c:4297: error: previous definition of 'blk_equals' was here /usr/src/sbin/fsck_ffs/suj.c:6244: error: redefinition of 'blk_setmask' /usr/src/sbin/fsck_ffs/suj.c:4310: error: previous definition of 'blk_setmask' was here /usr/src/sbin/fsck_ffs/suj.c:6261: error: redefinition of 'blk_isfree' /usr/src/sbin/fsck_ffs/suj.c:4327: error: previous definition of 'blk_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:6311: error: redefinition of 'blk_isindir' /usr/src/sbin/fsck_ffs/suj.c:4377: error: previous definition of 'blk_isindir' was here /usr/src/sbin/fsck_ffs/suj.c:6333: error: redefinition of 'ino_free' /usr/src/sbin/fsck_ffs/suj.c:4399: error: previous definition of 'ino_free' was here /usr/src/sbin/fsck_ffs/suj.c:6370: error: redefinition of 'blk_free' /usr/src/sbin/fsck_ffs/suj.c:4436: error: previous definition of 'blk_free' was here /usr/src/sbin/fsck_ffs/suj.c:6414: error: redefinition of 'indir_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:4480: error: previous definition of 'indir_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:6465: error: redefinition of 'ino_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:4531: error: previous definition of 'ino_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:6522: error: redefinition of 'blk_isat' /usr/src/sbin/fsck_ffs/suj.c:4588: error: previous definition of 'blk_isat' was here /usr/src/sbin/fsck_ffs/suj.c:6541: error: redefinition of 'ino_isat' /usr/src/sbin/fsck_ffs/suj.c:4607: error: previous definition of 'ino_isat' was here /usr/src/sbin/fsck_ffs/suj.c:6634: error: redefinition of 'indir_visit' /usr/src/sbin/fsck_ffs/suj.c:4700: error: previous definition of 'indir_visit' was here /usr/src/sbin/fsck_ffs/suj.c:6695: error: redefinition of 'ino_visit' /usr/src/sbin/fsck_ffs/suj.c:4761: error: previous definition of 'ino_visit' was here /usr/src/sbin/fsck_ffs/suj.c:6745: error: redefinition of 'null_visit' /usr/src/sbin/fsck_ffs/suj.c:4811: error: previous definition of 'null_visit' was here /usr/src/sbin/fsck_ffs/suj.c:6756: error: redefinition of 'ino_adjblks' /usr/src/sbin/fsck_ffs/suj.c:4822: error: previous definition of 'ino_adjblks' was here /usr/src/sbin/fsck_ffs/suj.c:6783: error: redefinition of 'blk_free_visit' /usr/src/sbin/fsck_ffs/suj.c:4849: error: previous definition of 'blk_free_visit' was here /usr/src/sbin/fsck_ffs/suj.c:6799: error: redefinition of 'blk_free_lbn' /usr/src/sbin/fsck_ffs/suj.c:4865: error: previous definition of 'blk_free_lbn' was here /usr/src/sbin/fsck_ffs/suj.c:6815: error: redefinition of 'ino_free_children' /usr/src/sbin/fsck_ffs/suj.c:4881: error: previous definition of 'ino_free_children' was here /usr/src/sbin/fsck_ffs/suj.c:6887: error: redefinition of 'ino_truncate' /usr/src/sbin/fsck_ffs/suj.c:4953: error: previous definition of 'ino_truncate' was here /usr/src/sbin/fsck_ffs/suj.c:6925: error: redefinition of 'ino_decr' /usr/src/sbin/fsck_ffs/suj.c:4991: error: previous definition of 'ino_decr' was here /usr/src/sbin/fsck_ffs/suj.c:6960: error: redefinition of 'ino_adjust' /usr/src/sbin/fsck_ffs/suj.c:5026: error: previous definition of 'ino_adjust' was here /usr/src/sbin/fsck_ffs/suj.c:7011: error: redefinition of 'ino_check' /usr/src/sbin/fsck_ffs/suj.c:5077: error: previous definition of 'ino_check' was here /usr/src/sbin/fsck_ffs/suj.c:7097: error: redefinition of 'blk_check' /usr/src/sbin/fsck_ffs/suj.c:5163: error: previous definition of 'blk_check' was here /usr/src/sbin/fsck_ffs/suj.c:7155: error: redefinition of 'cg_check' /usr/src/sbin/fsck_ffs/suj.c:5221: error: previous definition of 'cg_check' was here /usr/src/sbin/fsck_ffs/suj.c:7181: error: redefinition of 'cg_write' /usr/src/sbin/fsck_ffs/suj.c:5247: error: previous definition of 'cg_write' was here /usr/src/sbin/fsck_ffs/suj.c:7235: error: redefinition of 'cg_apply' /usr/src/sbin/fsck_ffs/suj.c:5301: error: previous definition of 'cg_apply' was here /usr/src/sbin/fsck_ffs/suj.c:7252: error: redefinition of 'suj_build_ino' /usr/src/sbin/fsck_ffs/suj.c:5318: error: previous definition of 'suj_build_ino' was here /usr/src/sbin/fsck_ffs/suj.c:7288: error: redefinition of 'suj_move_ino' /usr/src/sbin/fsck_ffs/suj.c:5354: error: previous definition of 'suj_move_ino' was here /usr/src/sbin/fsck_ffs/suj.c:7326: error: redefinition of 'suj_build_blk' /usr/src/sbin/fsck_ffs/suj.c:5392: error: previous definition of 'suj_build_blk' was here /usr/src/sbin/fsck_ffs/suj.c:7379: error: redefinition of 'suj_build' /usr/src/sbin/fsck_ffs/suj.c:5445: error: previous definition of 'suj_build' was here /usr/src/sbin/fsck_ffs/suj.c:7419: error: redefinition of 'suj_prune' /usr/src/sbin/fsck_ffs/suj.c:5485: error: previous definition of 'suj_prune' was here /usr/src/sbin/fsck_ffs/suj.c:7480: error: redefinition of 'suj_verifyino' /usr/src/sbin/fsck_ffs/suj.c:5546: error: previous definition of 'suj_verifyino' was here /usr/src/sbin/fsck_ffs/suj.c:7499: error: redefinition of 'struct jblocks' /usr/src/sbin/fsck_ffs/suj.c:7506: error: redefinition of 'struct jextent' /usr/src/sbin/fsck_ffs/suj.c:7515: error: redefinition of 'jblocks_create' /usr/src/sbin/fsck_ffs/suj.c:5581: error: previous definition of 'jblocks_create' was here /usr/src/sbin/fsck_ffs/suj.c:7537: error: redefinition of 'jblocks_next' /usr/src/sbin/fsck_ffs/suj.c:5603: error: previous definition of 'jblocks_next' was here /usr/src/sbin/fsck_ffs/suj.c:7567: error: redefinition of 'jblocks_advance' /usr/src/sbin/fsck_ffs/suj.c:5633: error: previous definition of 'jblocks_advance' was here /usr/src/sbin/fsck_ffs/suj.c:7574: error: redefinition of 'jblocks_destroy' /usr/src/sbin/fsck_ffs/suj.c:5640: error: previous definition of 'jblocks_destroy' was here /usr/src/sbin/fsck_ffs/suj.c:7582: error: redefinition of 'jblocks_add' /usr/src/sbin/fsck_ffs/suj.c:5648: error: previous definition of 'jblocks_add' was here /usr/src/sbin/fsck_ffs/suj.c:7623: error: redefinition of 'suj_add_block' /usr/src/sbin/fsck_ffs/suj.c:5689: error: previous definition of 'suj_add_block' was here /usr/src/sbin/fsck_ffs/suj.c:7630: error: redefinition of 'suj_read' /usr/src/sbin/fsck_ffs/suj.c:5696: error: previous definition of 'suj_read' was here /usr/src/sbin/fsck_ffs/suj.c:7698: error: redefinition of 'suj_check' /usr/src/sbin/fsck_ffs/suj.c:1896: error: previous definition of 'suj_check' was here *** Error code 1 Stop in /usr/src/sbin/fsck_ffs. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. evo# uname -a FreeBSD evo 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Jan 9 22:31:12 EET 2010 terminus@evo:/usr/obj/usr/src/sys/GENERIC i386 evo# == From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 13:39:01 2010 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 792FE1065676; Sun, 10 Jan 2010 13:39:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6668FC15; Sun, 10 Jan 2010 13:39:00 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=p0TwAfwpPXgA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=OdR5sfXFAAAA:8 a=yii_e_M_R1lv0RMgNxMA:9 a=AKsT8VVSzWy0iFj9e78A:7 a=7n0J_6GuWXPTFV8-VojJBdtb8KAA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 591294738; Sun, 10 Jan 2010 14:38:58 +0100 From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Date: Sun, 10 Jan 2010 14:37:37 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201001101437.37269.hselasky@c2i.net> Cc: Subject: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 10 Jan 2010 13:39:01 -0000 Hi, During the last couple of days I've spent some time to finish my webcam daemon. My webcam daemon is basically an application which consists of userspace Video4Linux USB webcam drivers and some uLinux glue code which links with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which is provided by the video4bsd kernel module. There is full support for mmap/read/write/open/close. poll is not supported. Basic operation and idea: /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the interface for the V4L application. The video4bsd transports all data between these two devices. In the case the V4L application is using mmap, no data is copied due to shared kernel memory buffer! Licensing issues: Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB drivers which are GPL licensed. Some files inside the webcamd remains BSD licensed which allows for building similar BSD licensed daemons. The rest of the code is BSD licensed. Source code: 1) FreeBSD 8-stable 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: http://p4web.freebsd.org/chv.cgi?CH=172876 http://perforce.freebsd.org/chv.cgi?CH=172876 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be checked out in the same folder due to dependencies) svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd make all install kldload video4bsd svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux make fetch make patch make all make install # this will attach to the first detected webcam: ./webcamd # this will try to attach to the given USB unit, interface and V4B unit. ./webcamd -d ugen4.1 -i 0 -v 0 # this will display webcam contents from /dev/video0 by default. ./pwcview/pwcview Feedback and bug reports are welcome. Yes, I am working on getting this into ports! Known issues: 1) If you detach the USB webcam you need to manually restart the webcamd. --HPS Support: I will be available at #bsdusb on efnet during the day. From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 13:49:17 2010 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 BE9CA1065672 for ; Sun, 10 Jan 2010 13:49:17 +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 52D318FC14 for ; Sun, 10 Jan 2010 13:49:16 +0000 (UTC) Received: by bwz5 with SMTP id 5so13205618bwz.3 for ; Sun, 10 Jan 2010 05:49:10 -0800 (PST) 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=fajH+4Jwu3yWyn7BNLPBIarfLWHUdN6lB+fowu9gItk=; b=Gun31OdJJgl4QTorbW0EgFto96PIVgezz2B+Z8KB+cl14pH3XlSuEEABQa3Ff9A8Js GDK3Xi4ie7NxOOS2PoqomNBbLqghXbmAP1gg+kCN8t4LdfvNnopVoDxzie+84CaU37oY g8ECi7tFEALnYXBCS6WxCTlkdsZaAjpq3nWmQ= 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=SL7gqd71vrDNk6YnrAYyFgcnYjp5QxsZjxFBVCMR48htorD9HXm29xbSlt+QIvoMTd k8cDbsEUH3gPoDz9dq0wQSa1t1r2ywgWXERpO5aJo43oMRlSr8udtVcoyU5vDi44BpuK jFMXlb0zO8eXC2ChH16bjnLH827aEauIey5ew= MIME-Version: 1.0 Received: by 10.204.35.79 with SMTP id o15mr2778867bkd.41.1263131350828; Sun, 10 Jan 2010 05:49:10 -0800 (PST) In-Reply-To: <201001101526.49411.dima_bsd@inbox.lv> References: <201001101526.49411.dima_bsd@inbox.lv> Date: Sun, 10 Jan 2010 16:49:10 +0300 Message-ID: From: pluknet To: Dmitriy Demidov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 13:49:17 -0000 2010/1/10 Dmitriy Demidov : > Error while building world on today's CURRENT. > Patch applied without errors. > > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c > In file included from /usr/src/sbin/fsck_ffs/suj.c:1982: > /usr/src/sbin/fsck_ffs/fsck.h:72: error: redefinition of 'union dinode' [...] After looking on line numbers I'd suggest you to check if you've applied the patch two times (so suj.c "duplicates" itself). -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 15:27:43 2010 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 DA588106566B; Sun, 10 Jan 2010 15:27:43 +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 73A9E8FC0A; Sun, 10 Jan 2010 15:27:43 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id o0AFRd7h064668; Sun, 10 Jan 2010 08:27:39 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: Date: Sun, 10 Jan 2010 08:27:39 -0700 Content-Transfer-Encoding: 7bit Message-Id: <83031A5C-87E5-4052-A4C7-6108FD5E2F36@samsco.org> References: <4B4851FE.2020907@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1076) X-Spam-Status: No, score=-13.0 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: FreeBSD-Current List , Jeff Roberson Subject: Re: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 15:27:43 -0000 On Jan 9, 2010, at 3:12 AM, Jeff Roberson wrote: > On Sat, 9 Jan 2010, Alexander Motin wrote: > >> Hi. >> >> Jeff Roberson wrote: >>> I have been augmenting softupdates with a small journal that will be >>> processed in lieu of fsck in the event of a crash. I have written >>> some >>> about this project here: http://jeffr_tech.livejournal.com/ >> >> Sounds cool, but I have one question. Excuse my possible ignorance. >> >> I was looking for BIO_FLUSH consumers and haven't found UFS there. >> Unbacked write caching probably can make SoftUpdates unreliable, >> but it >> is bearable while foreground fsck is used. As I understand, journaled >> recovery is more dependent on data coherency, and so needs either >> unbacked write caching to be disabled, or BIO_FLUSH to be used in >> respective points by FS code. Am I right? So what's about BIO_FLUSH? > > Softupdates definitely relies on proper disk ordering. People who > want reliability in the face of power failure need to buy nice disks > and buy battery backup systems. Many cheap disks lie about flush > and this has bitten ZFS. SU+J will still work with foreground fsck > if you want to be absolutely certain of your data in the event of a > power outage. > > It would be possible to implement a flush barrier in between writing > the journal and permitting the meta-data modifications, and again > after metadata modifications and before journal free. SU+J would be > more tolerant to out of order filesystem operations following the > journal write than vanilla softupdates. However, I'm not sure how > much it will help, and it is not part of my current plans. It is > probably worthwhile to study further. > The write barrier here probably doesn't need to be as heavy-weight as the cache-flush that BIO_FLUSH tries to do. For devices that implement ordered tags (i.e. SCSI and SAS, not SATA), a barrier op would be preferable. This has been the source of recent arguments that I don't want to re-open on this discussion, but please let me know in private if you'd like to discuss it. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 16:27:16 2010 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 444AB1065676 for ; Sun, 10 Jan 2010 16:27:16 +0000 (UTC) (envelope-from dima_bsd@inbox.lv) Received: from mgw1.apollo.lv (mgw1.apollo.lv [80.232.168.216]) by mx1.freebsd.org (Postfix) with ESMTP id C4B348FC17 for ; Sun, 10 Jan 2010 16:27:14 +0000 (UTC) Received: from [95.68.120.242] (unknown [95.68.120.242]) by mgw1.apollo.lv (Postfix) with ESMTP id 42A763DC71E; Sun, 10 Jan 2010 18:27:10 +0200 (EET) From: Dmitriy Demidov To: pluknet Date: Sun, 10 Jan 2010 18:27:09 +0200 User-Agent: KMail/1.9.10 References: <201001101526.49411.dima_bsd@inbox.lv> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001101827.09631.dima_bsd@inbox.lv> X-Brightmail-Tracker: AAAAAA== Cc: freebsd-current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 16:27:16 -0000 On Sunday 10 January 2010, pluknet wrote: > After looking on line numbers I'd suggest you to check > if you've applied the patch two times (so suj.c "duplicates" itself). > Unfortunately - no luck for me... After removing all data from /usr/src + /usr/obj, and csup'ing fresh copy of CURRENT from cvsup.lv.freebsd.org, I still have buildworld erros: == (cd /usr/src/rescue/rescue/../../sbin/atacontrol && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/atacontrol/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/atacontrol/ atacontrol.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/atacontrol/atacontrol.c echo atacontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/atacontrol/atacontrol.c (cd /usr/src/rescue/rescue/../../sbin/badsect && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ badsect.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/badsect/badsect.c echo badsect: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/badsect/badsect.c (cd /usr/src/rescue/rescue/../../sbin/camcontrol && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ camcontrol.o util.o modeedit.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/camcontrol/camcontrol.c /usr/src/sbin/camcontrol/util.c /usr/src/sbin/camcontrol/modeedit.c echo camcontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libcam.a /usr/obj/usr/src/tmp/usr/lib/libsbuf.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/camcontrol.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/util.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/modeedit.c (cd /usr/src/rescue/rescue/../../sbin/ccdconfig && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ ccdconfig.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/ccdconfig/ccdconfig.c echo ccdconfig: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libgeom.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/ccdconfig/ccdconfig.c (cd /usr/src/rescue/rescue/../../sbin/clri && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ clri.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/clri/clri.c echo clri: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/clri/clri.c (cd /usr/src/rescue/rescue/../../sbin/devfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ devfs.o rule.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/devfs/devfs.c /usr/src/sbin/devfs/rule.c echo devfs: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/devfs.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/rule.c (cd /usr/src/rescue/rescue/../../sbin/dmesg && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ dmesg.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dmesg/dmesg.c echo dmesg: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libkvm.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dmesg/dmesg.c (cd /usr/src/rescue/rescue/../../sbin/dump && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ itime.o main.o optr.o dumprmt.o tape.o traverse.o unctime.o cache.o) rm -f .depend mkdep -f .depend -a -DRDUMP -DRESCUE /usr/src/sbin/dump/itime.c /usr/src/sbin/dump/main.c /usr/src/sbin/dump/optr.c /usr/src/sbin/dump/dumprmt.c /usr/src/sbin/dump/tape.c /usr/src/sbin/dump/traverse.c /usr/src/sbin/dump/unctime.c /usr/src/sbin/dump/cache.c echo dump: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/itime.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/main.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/optr.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/dumprmt.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/tape.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/traverse.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/unctime.c cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/cache.c (cd /usr/src/rescue/rescue/../../sbin/dumpfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ dumpfs.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpfs/dumpfs.c echo dumpfs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dumpfs/dumpfs.c (cd /usr/src/rescue/rescue/../../sbin/dumpon && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ dumpon.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpon/dumpon.c echo dumpon: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dumpon/dumpon.c (cd /usr/src/rescue/rescue/../../sbin/fsck && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ fsck.o fsutil.o preen.o) rm -f .depend mkdep -f .depend -a -DRESCUE /usr/src/sbin/fsck/fsck.c /usr/src/sbin/fsck/fsutil.c /usr/src/sbin/fsck/preen.c echo fsck: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsck.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsutil.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/preen.c (cd /usr/src/rescue/rescue/../../sbin/fsck_ffs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ dir.o ea.o fsutil.o inode.o main.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o setup.o suj.o utilities.o gjournal.o getmntopts.o) rm -f .depend mkdep -f .depend -a -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -DRESCUE /usr/src/sbin/fsck_ffs/dir.c /usr/src/sbin/fsck_ffs/ea.c /usr/src/sbin/fsck_ffs/fsutil.c /usr/src/sbin/fsck_ffs/inode.c /usr/src/sbin/fsck_ffs/main.c /usr/src/sbin/fsck_ffs/pass1.c /usr/src/sbin/fsck_ffs/pass1b.c /usr/src/sbin/fsck_ffs/pass2.c /usr/src/sbin/fsck_ffs/pass3.c /usr/src/sbin/fsck_ffs/pass4.c /usr/src/sbin/fsck_ffs/pass5.c /usr/src/sbin/fsck_ffs/setup.c /usr/src/sbin/fsck_ffs/suj.c /usr/src/sbin/fsck_ffs/utilities.c /usr/src/sbin/fsck_ffs/gjournal.c /usr/src/sbin/fsck_ffs/../mount/getmntopts.c echo fsck_ffs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/dir.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/ea.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/fsutil.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/inode.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/main.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1b.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass2.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass3.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass4.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass5.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/setup.c cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c cc1: warnings being treated as errors /usr/src/sbin/fsck_ffs/suj.c:397: warning: 'ino_isfree' defined but not used *** Error code 1 Stop in /usr/src/sbin/fsck_ffs. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. == Here is a log of patching: == Script started on Sun Jan 10 16:21:26 2010 evo# evo# patch < /home/terminus/suj.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/suj.c |=================================================================== |--- sbin/fsck_ffs/suj.c (revision 0) |+++ sbin/fsck_ffs/suj.c (revision 0) -------------------------- (Creating file sbin/fsck_ffs/suj.c...) Patching file sbin/fsck_ffs/suj.c using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/gjournal.c |=================================================================== |--- sbin/fsck_ffs/gjournal.c (revision 201766) |+++ sbin/fsck_ffs/gjournal.c (working copy) -------------------------- Patching file sbin/fsck_ffs/gjournal.c using Plan A... Hunk #1 succeeded at 96. Hunk #2 succeeded at 221. Hunk #3 succeeded at 236. Hunk #4 succeeded at 245. Hunk #5 succeeded at 255. Hunk #6 succeeded at 272. Hunk #7 succeeded at 285. Hunk #8 succeeded at 302. Hunk #9 succeeded at 332. Hunk #10 succeeded at 404. Hunk #11 succeeded at 480. Hunk #12 succeeded at 505. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/main.c |=================================================================== |--- sbin/fsck_ffs/main.c (revision 201766) |+++ sbin/fsck_ffs/main.c (working copy) -------------------------- Patching file sbin/fsck_ffs/main.c using Plan A... Hunk #1 succeeded at 256. Hunk #2 succeeded at 278. Hunk #3 succeeded at 311. Hunk #4 succeeded at 493. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/pass4.c |=================================================================== |--- sbin/fsck_ffs/pass4.c (revision 201766) |+++ sbin/fsck_ffs/pass4.c (working copy) -------------------------- Patching file sbin/fsck_ffs/pass4.c using Plan A... Hunk #1 succeeded at 72. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/pass5.c |=================================================================== |--- sbin/fsck_ffs/pass5.c (revision 201766) |+++ sbin/fsck_ffs/pass5.c (working copy) -------------------------- Patching file sbin/fsck_ffs/pass5.c using Plan A... Hunk #1 succeeded at 45. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/fsck.h |=================================================================== |--- sbin/fsck_ffs/fsck.h (revision 201766) |+++ sbin/fsck_ffs/fsck.h (working copy) -------------------------- Patching file sbin/fsck_ffs/fsck.h using Plan A... Hunk #1 succeeded at 347. Hunk #2 succeeded at 388. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsck_ffs/Makefile |=================================================================== |--- sbin/fsck_ffs/Makefile (revision 201766) |+++ sbin/fsck_ffs/Makefile (working copy) -------------------------- Patching file sbin/fsck_ffs/Makefile using Plan A... Hunk #1 succeeded at 7. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/fsdb/fsdbutil.c |=================================================================== |--- sbin/fsdb/fsdbutil.c (revision 201766) |+++ sbin/fsdb/fsdbutil.c (working copy) -------------------------- Patching file sbin/fsdb/fsdbutil.c using Plan A... Hunk #1 succeeded at 52. Hunk #2 succeeded at 226. Hunk #3 succeeded at 234. Hunk #4 succeeded at 254. Hunk #5 succeeded at 270. Hunk #6 succeeded at 310. Hunk #7 succeeded at 318. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sbin/tunefs/tunefs.c |=================================================================== |--- sbin/tunefs/tunefs.c (revision 201766) |+++ sbin/tunefs/tunefs.c (working copy) -------------------------- Patching file sbin/tunefs/tunefs.c using Plan A... Hunk #1 succeeded at 61. Hunk #2 succeeded at 73. Hunk #3 succeeded at 93. Hunk #4 succeeded at 137. Hunk #5 succeeded at 254. Hunk #6 succeeded at 334. Hunk #7 succeeded at 507. Hunk #8 succeeded at 751. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/inode.c |=================================================================== |--- lib/libufs/inode.c (revision 201766) |+++ lib/libufs/inode.c (working copy) -------------------------- Patching file lib/libufs/inode.c using Plan A... Hunk #1 succeeded at 93. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/cgroup.c |=================================================================== |--- lib/libufs/cgroup.c (revision 201766) |+++ lib/libufs/cgroup.c (working copy) -------------------------- Patching file lib/libufs/cgroup.c using Plan A... Hunk #1 succeeded at 40. Hunk #2 succeeded at 126. Hunk #3 succeeded at 142. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/type.c |=================================================================== |--- lib/libufs/type.c (revision 201766) |+++ lib/libufs/type.c (working copy) -------------------------- Patching file lib/libufs/type.c using Plan A... Hunk #1 succeeded at 66. Hunk #2 succeeded at 160. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/libufs.h |=================================================================== |--- lib/libufs/libufs.h (revision 201766) |+++ lib/libufs/libufs.h (working copy) -------------------------- Patching file lib/libufs/libufs.h using Plan A... Hunk #1 succeeded at 71. Hunk #2 succeeded at 110. Hunk #3 succeeded at 137. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/Makefile |=================================================================== |--- lib/libufs/Makefile (revision 201766) |+++ lib/libufs/Makefile (working copy) -------------------------- Patching file lib/libufs/Makefile using Plan A... Hunk #1 succeeded at 3. Hunk #2 succeeded at 16. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: lib/libufs/sblock.c |=================================================================== |--- lib/libufs/sblock.c (revision 201766) |+++ lib/libufs/sblock.c (working copy) -------------------------- Patching file lib/libufs/sblock.c using Plan A... Hunk #1 succeeded at 40. Hunk #2 succeeded at 50. Hunk #3 succeeded at 90. Hunk #4 succeeded at 125. Hunk #5 succeeded at 140. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ufs/ufs_dirhash.c |=================================================================== |--- sys/ufs/ufs/ufs_dirhash.c (revision 201766) |+++ sys/ufs/ufs/ufs_dirhash.c (working copy) -------------------------- Patching file sys/ufs/ufs/ufs_dirhash.c using Plan A... Hunk #1 succeeded at 68. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ufs/ufs_vnops.c |=================================================================== |--- sys/ufs/ufs/ufs_vnops.c (revision 201766) |+++ sys/ufs/ufs/ufs_vnops.c (working copy) -------------------------- Patching file sys/ufs/ufs/ufs_vnops.c using Plan A... Hunk #1 succeeded at 114. Hunk #2 succeeded at 976. Hunk #3 succeeded at 993. Hunk #4 succeeded at 1006. Hunk #5 succeeded at 1048. Hunk #6 succeeded at 1067. Hunk #7 succeeded at 1111. Hunk #8 succeeded at 1296. Hunk #9 succeeded at 1390. Hunk #10 succeeded at 1401. Hunk #11 succeeded at 1416. Hunk #12 succeeded at 1444. Hunk #13 succeeded at 1741. Hunk #14 succeeded at 1757. Hunk #15 succeeded at 1867. Hunk #16 succeeded at 1883. Hunk #17 succeeded at 1892. Hunk #18 succeeded at 1929. Hunk #19 succeeded at 1959. Hunk #20 succeeded at 2475. Hunk #21 succeeded at 2607. Hunk #22 succeeded at 2671. Hunk #23 succeeded at 2687. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ufs/ufsmount.h |=================================================================== |--- sys/ufs/ufs/ufsmount.h (revision 201766) |+++ sys/ufs/ufs/ufsmount.h (working copy) -------------------------- Patching file sys/ufs/ufs/ufsmount.h using Plan A... Hunk #1 succeeded at 57. Hunk #2 succeeded at 76. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ufs/ufs_lookup.c |=================================================================== |--- sys/ufs/ufs/ufs_lookup.c (revision 201766) |+++ sys/ufs/ufs/ufs_lookup.c (working copy) -------------------------- Patching file sys/ufs/ufs/ufs_lookup.c using Plan A... Hunk #1 succeeded at 77. Hunk #2 succeeded at 186. Hunk #3 succeeded at 521. Hunk #4 succeeded at 545. Hunk #5 succeeded at 552. Hunk #6 succeeded at 568. Hunk #7 succeeded at 609. Hunk #8 succeeded at 645. Hunk #9 succeeded at 678. Hunk #10 succeeded at 822. Hunk #11 succeeded at 900. Hunk #12 succeeded at 988. Hunk #13 succeeded at 1040. Hunk #14 succeeded at 1059. Hunk #15 succeeded at 1101. Hunk #16 succeeded at 1143. Hunk #17 succeeded at 1164. Hunk #18 succeeded at 1210. Hunk #19 succeeded at 1347. Hunk #20 succeeded at 1376. Hunk #21 succeeded at 1394. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ufs/ufs_extern.h |=================================================================== |--- sys/ufs/ufs/ufs_extern.h (revision 201766) |+++ sys/ufs/ufs/ufs_extern.h (working copy) -------------------------- Patching file sys/ufs/ufs/ufs_extern.h using Plan A... Hunk #1 succeeded at 57. Hunk #2 succeeded at 66. Hunk #3 succeeded at 83. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_vfsops.c |=================================================================== |--- sys/ufs/ffs/ffs_vfsops.c (revision 201766) |+++ sys/ufs/ffs/ffs_vfsops.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_vfsops.c using Plan A... Hunk #1 succeeded at 331. Hunk #2 succeeded at 899. Hunk #3 succeeded at 911. Hunk #4 succeeded at 942. Hunk #5 succeeded at 1871. Hunk #6 succeeded at 1911. Hunk #7 succeeded at 1933. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_softdep.c |=================================================================== |--- sys/ufs/ffs/ffs_softdep.c (revision 201766) |+++ sys/ufs/ffs/ffs_softdep.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_softdep.c using Plan A... Hunk #1 succeeded at 62. Hunk #2 succeeded at 131. Hunk #3 succeeded at 406. Hunk #4 succeeded at 423. Hunk #5 succeeded at 488. Hunk #6 succeeded at 499. Hunk #7 succeeded at 518. Hunk #8 succeeded at 544. Hunk #9 succeeded at 715. Hunk #10 succeeded at 854. Hunk #11 succeeded at 877. Hunk #12 succeeded at 932. Hunk #13 succeeded at 1009. Hunk #14 succeeded at 1036. Hunk #15 succeeded at 1054. Hunk #16 succeeded at 1109. Hunk #17 succeeded at 1143. Hunk #18 succeeded at 1205. Hunk #19 succeeded at 1225. Hunk #20 succeeded at 1241. Hunk #21 succeeded at 1252. Hunk #22 succeeded at 1262. Hunk #23 succeeded at 1281. Hunk #24 succeeded at 1299. Hunk #25 succeeded at 1322. Hunk #26 succeeded at 1520. Hunk #27 succeeded at 1543. Hunk #28 succeeded at 1595. Hunk #29 succeeded at 1606. Hunk #30 succeeded at 1636. Hunk #31 succeeded at 1665. Hunk #32 succeeded at 1702. Hunk #33 succeeded at 1711. Hunk #34 succeeded at 1746. Hunk #35 succeeded at 1773. Hunk #36 succeeded at 1803. Hunk #37 succeeded at 1844. Hunk #38 succeeded at 3618. Hunk #39 succeeded at 3652. Hunk #40 succeeded at 3670. Hunk #41 succeeded at 3742. Hunk #42 succeeded at 3813. Hunk #43 succeeded at 3826. Hunk #44 succeeded at 3853. Hunk #45 succeeded at 3902. Hunk #46 succeeded at 3938. Hunk #47 succeeded at 3957. Hunk #48 succeeded at 3966. Hunk #49 succeeded at 3982. Hunk #50 succeeded at 4100. Hunk #51 succeeded at 4133. Hunk #52 succeeded at 4196. Hunk #53 succeeded at 4246. Hunk #54 succeeded at 4288. Hunk #55 succeeded at 4326. Hunk #56 succeeded at 4405. Hunk #57 succeeded at 4466. Hunk #58 succeeded at 4490. Hunk #59 succeeded at 4571. Hunk #60 succeeded at 4579. Hunk #61 succeeded at 4594. Hunk #62 succeeded at 4655. Hunk #63 succeeded at 4694. Hunk #64 succeeded at 4707. Hunk #65 succeeded at 4723. Hunk #66 succeeded at 4758. Hunk #67 succeeded at 4781. Hunk #68 succeeded at 4799. Hunk #69 succeeded at 4824. Hunk #70 succeeded at 4849. Hunk #71 succeeded at 4904. Hunk #72 succeeded at 5065. Hunk #73 succeeded at 5083. Hunk #74 succeeded at 5128. Hunk #75 succeeded at 5139. Hunk #76 succeeded at 5189. Hunk #77 succeeded at 5198. Hunk #78 succeeded at 5209. Hunk #79 succeeded at 5236. Hunk #80 succeeded at 5258. Hunk #81 succeeded at 5387. Hunk #82 succeeded at 5471. Hunk #83 succeeded at 5528. Hunk #84 succeeded at 5544. Hunk #85 succeeded at 5560. Hunk #86 succeeded at 5825. Hunk #87 succeeded at 5842. Hunk #88 succeeded at 5853. Hunk #89 succeeded at 5954. Hunk #90 succeeded at 5964. Hunk #91 succeeded at 6161. Hunk #92 succeeded at 6200. Hunk #93 succeeded at 6275. Hunk #94 succeeded at 6297. Hunk #95 succeeded at 6368. Hunk #96 succeeded at 6396. Hunk #97 succeeded at 6441. Hunk #98 succeeded at 6457. Hunk #99 succeeded at 6490. Hunk #100 succeeded at 6528. Hunk #101 succeeded at 6568. Hunk #102 succeeded at 6611. Hunk #103 succeeded at 6637. Hunk #104 succeeded at 6705. Hunk #105 succeeded at 6735. Hunk #106 succeeded at 6797. Hunk #107 succeeded at 6807. Hunk #108 succeeded at 6869. Hunk #109 succeeded at 6881. Hunk #110 succeeded at 6910. Hunk #111 succeeded at 6981. Hunk #112 succeeded at 6998. Hunk #113 succeeded at 7046. Hunk #114 succeeded at 7082. Hunk #115 succeeded at 7137. Hunk #116 succeeded at 7168. Hunk #117 succeeded at 7186. Hunk #118 succeeded at 7207. Hunk #119 succeeded at 7244. Hunk #120 succeeded at 7291. Hunk #121 succeeded at 7313. Hunk #122 succeeded at 7325. Hunk #123 succeeded at 7358. Hunk #124 succeeded at 7389. Hunk #125 succeeded at 7407. Hunk #126 succeeded at 7778. Hunk #127 succeeded at 7790. Hunk #128 succeeded at 7811. Hunk #129 succeeded at 7820. Hunk #130 succeeded at 7870. Hunk #131 succeeded at 7880. Hunk #132 succeeded at 7940. Hunk #133 succeeded at 7970. Hunk #134 succeeded at 7982. Hunk #135 succeeded at 8097. Hunk #136 succeeded at 8114. Hunk #137 succeeded at 8132. Hunk #138 succeeded at 8142. Hunk #139 succeeded at 8156. Hunk #140 succeeded at 8230. Hunk #141 succeeded at 8272. Hunk #142 succeeded at 8287. Hunk #143 succeeded at 8422. Hunk #144 succeeded at 8640. Hunk #145 succeeded at 8653. Hunk #146 succeeded at 8698. Hunk #147 succeeded at 8735. Hunk #148 succeeded at 8762. Hunk #149 succeeded at 8777. Hunk #150 succeeded at 8817. Hunk #151 succeeded at 8845. Hunk #152 succeeded at 8857. Hunk #153 succeeded at 8881. Hunk #154 succeeded at 8926. Hunk #155 succeeded at 9025. Hunk #156 succeeded at 9061. Hunk #157 succeeded at 9127. Hunk #158 succeeded at 9192. Hunk #159 succeeded at 9216. Hunk #160 succeeded at 9238. Hunk #161 succeeded at 9259. Hunk #162 succeeded at 9306. Hunk #163 succeeded at 9320. Hunk #164 succeeded at 9341. Hunk #165 succeeded at 9365. Hunk #166 succeeded at 9381. Hunk #167 succeeded at 9414. Hunk #168 succeeded at 9518. Hunk #169 succeeded at 9535. Hunk #170 succeeded at 9549. Hunk #171 succeeded at 9605. Hunk #172 succeeded at 9625. Hunk #173 succeeded at 9942. Hunk #174 succeeded at 9950. Hunk #175 succeeded at 9997. Hunk #176 succeeded at 10032. Hunk #177 succeeded at 10053. Hunk #178 succeeded at 10073. Hunk #179 succeeded at 10325. Hunk #180 succeeded at 10377. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_extern.h |=================================================================== |--- sys/ufs/ffs/ffs_extern.h (revision 201766) |+++ sys/ufs/ffs/ffs_extern.h (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_extern.h using Plan A... Hunk #1 succeeded at 56. Hunk #2 succeeded at 110. Hunk #3 succeeded at 119. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_alloc.c |=================================================================== |--- sys/ufs/ffs/ffs_alloc.c (revision 201766) |+++ sys/ufs/ffs/ffs_alloc.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_alloc.c using Plan A... Hunk #1 succeeded at 89. Hunk #2 succeeded at 182. Hunk #3 succeeded at 380. Hunk #4 succeeded at 474. Hunk #5 succeeded at 497. Hunk #6 succeeded at 505. Hunk #7 succeeded at 582. Hunk #8 succeeded at 598. Hunk #9 succeeded at 624. Hunk #10 succeeded at 675. Hunk #11 succeeded at 713. Hunk #12 succeeded at 797. Hunk #13 succeeded at 813. Hunk #14 succeeded at 839. Hunk #15 succeeded at 890. Hunk #16 succeeded at 977. Hunk #17 succeeded at 1286. Hunk #18 succeeded at 1307. Hunk #19 succeeded at 1317. Hunk #20 succeeded at 1328. Hunk #21 succeeded at 1410. Hunk #22 succeeded at 1429. Hunk #23 succeeded at 1462. Hunk #24 succeeded at 1486. Hunk #25 succeeded at 1511. Hunk #26 succeeded at 1533. Hunk #27 succeeded at 1545. Hunk #28 succeeded at 1573. Hunk #29 succeeded at 1611. Hunk #30 succeeded at 1712. Hunk #31 succeeded at 1736. Hunk #32 succeeded at 1844. Hunk #33 succeeded at 1851. Hunk #34 succeeded at 1925. Hunk #35 succeeded at 1965. Hunk #36 succeeded at 1974. Hunk #37 succeeded at 2047. Hunk #38 succeeded at 2056. Hunk #39 succeeded at 2118. Hunk #40 succeeded at 2234. Hunk #41 succeeded at 2431. Hunk #42 succeeded at 2459. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/softdep.h |=================================================================== |--- sys/ufs/ffs/softdep.h (revision 201766) |+++ sys/ufs/ffs/softdep.h (working copy) -------------------------- Patching file sys/ufs/ffs/softdep.h using Plan A... Hunk #1 succeeded at 98. Hunk #2 succeeded at 137. Hunk #3 succeeded at 178. Hunk #4 succeeded at 213. Hunk #5 succeeded at 274. Hunk #6 succeeded at 298. Hunk #7 succeeded at 309. Hunk #8 succeeded at 374. Hunk #9 succeeded at 407. Hunk #10 succeeded at 431. Hunk #11 succeeded at 473. Hunk #12 succeeded at 537. Hunk #13 succeeded at 570. Hunk #14 succeeded at 586. Hunk #15 succeeded at 613. Hunk #16 succeeded at 631. Hunk #17 succeeded at 665. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_subr.c |=================================================================== |--- sys/ufs/ffs/ffs_subr.c (revision 201766) |+++ sys/ufs/ffs/ffs_subr.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_subr.c using Plan A... Hunk #1 succeeded at 37. Hunk #2 succeeded at 222. Hunk #3 succeeded at 282. Hunk #4 succeeded at 314. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_balloc.c |=================================================================== |--- sys/ufs/ffs/ffs_balloc.c (revision 201766) |+++ sys/ufs/ffs/ffs_balloc.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_balloc.c using Plan A... Hunk #1 succeeded at 120. Hunk #2 succeeded at 140. Hunk #3 succeeded at 192. Hunk #4 succeeded at 212. Hunk #5 succeeded at 257. Hunk #6 succeeded at 307. Hunk #7 succeeded at 363. Hunk #8 succeeded at 420. Hunk #9 succeeded at 477. Hunk #10 succeeded at 519. Hunk #11 succeeded at 650. Hunk #12 succeeded at 703. Hunk #13 succeeded at 723. Hunk #14 succeeded at 768. Hunk #15 succeeded at 818. Hunk #16 succeeded at 874. Hunk #17 succeeded at 937. Hunk #18 succeeded at 994. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_inode.c |=================================================================== |--- sys/ufs/ffs/ffs_inode.c (revision 201766) |+++ sys/ufs/ffs/ffs_inode.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_inode.c using Plan A... Hunk #1 succeeded at 232. Hunk #2 succeeded at 336. Hunk #3 succeeded at 447. Hunk #4 succeeded at 466. Hunk #5 succeeded at 499. Hunk #6 succeeded at 641. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/fs.h |=================================================================== |--- sys/ufs/ffs/fs.h (revision 201766) |+++ sys/ufs/ffs/fs.h (working copy) -------------------------- Patching file sys/ufs/ffs/fs.h using Plan A... Hunk #1 succeeded at 337. Hunk #2 succeeded at 414. Hunk #3 succeeded at 604. Hunk #4 succeeded at 640. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/ufs/ffs/ffs_snapshot.c |=================================================================== |--- sys/ufs/ffs/ffs_snapshot.c (revision 201766) |+++ sys/ufs/ffs/ffs_snapshot.c (working copy) -------------------------- Patching file sys/ufs/ffs/ffs_snapshot.c using Plan A... Hunk #1 succeeded at 582. Hunk #2 succeeded at 599. Hunk #3 succeeded at 701. Hunk #4 succeeded at 1221. Hunk #5 succeeded at 1501. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/kern/vfs_bio.c |=================================================================== |--- sys/kern/vfs_bio.c (revision 201766) |+++ sys/kern/vfs_bio.c (working copy) -------------------------- Patching file sys/kern/vfs_bio.c using Plan A... Hunk #1 succeeded at 216. Hunk #2 succeeded at 475. Hunk #3 succeeded at 2136. Hunk #4 succeeded at 2154. Hunk #5 succeeded at 2170. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: sys/sys/buf.h |=================================================================== |--- sys/sys/buf.h (revision 201766) |+++ sys/sys/buf.h (working copy) -------------------------- Patching file sys/sys/buf.h using Plan A... Hunk #1 succeeded at 493. done evo# evo# make buildworld -------------------------------------------------------------- >>> World build started on Sun Jan 10 16:22:14 EET 2010 -------------------------------------------------------------- == From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 16:41:00 2010 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 7398B106568B for ; Sun, 10 Jan 2010 16:41:00 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0B40B8FC16 for ; Sun, 10 Jan 2010 16:40:59 +0000 (UTC) Received: by ewy5 with SMTP id 5so9742914ewy.14 for ; Sun, 10 Jan 2010 08:40:54 -0800 (PST) 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=78OxVKuqAPpPqgZq5DKSFIIiU9b4yX2LVzQv7tG612g=; b=P45TFMFOQ/AhfLSbxb0DEdaaVwUjZuS7deJgFMNNrXzA+SjBpxo0H055uc18lGhc9y DaWndOFFBuMNmmRgbUhe8InQukcFgACudBjZItR2A+1fkRKksOFdga9uNjml8sXlO4ZU uwA3ArMl93U1TXQts5wSbzRpmDYqftNJ+x89I= 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=pOPfQrNirQI97fUWfR9dOuTRngMtzv1WCsO12CisKxM8t+qvpiLGSfFl+bLX4zJs7U UftuDHgLLT3yAC/jB2Y6tGJNdPhJGkDX9rYM8lUOXPe3NCViUMPyzlRi3NYUIGZB49IC 4V7nYLZj8YD+bgi/IxdAIcUTaz0Ak4rkslql0= MIME-Version: 1.0 Received: by 10.213.39.79 with SMTP id f15mr2139166ebe.13.1263141654353; Sun, 10 Jan 2010 08:40:54 -0800 (PST) In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Date: Sun, 10 Jan 2010 17:40:54 +0100 Message-ID: <3a142e751001100840r2f0e4799g601d8a89233e5e4c@mail.gmail.com> From: Paul B Mahol To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current Subject: Re: Final call for testers: TERM=xterm 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, 10 Jan 2010 16:41:00 -0000 On 11/11/09, Ed Schouten wrote: > Hi folks, > > I just committed some patches to SVN that should complete the Xterm- > style terminal emulator support. This means we can just share the same > termcap entry between the console driver and X11 terminal emulators, > which has many advantages, including: > > - The ability to use dtach(1) without problems. > - Support for more advanced (networking) devices with serial > administrative interfaces. > - Better compatibility with other operating systems. > - Reduced bandwidth. > > I'd like to flip the switch one of these days on all platforms, except > i386. On i386 the /etc/ttys file is shared between i386 and pc98. pc98 > will still use its own cons25 emulator instead of the xterm emulator, so > I'll initially convert all the other platforms and deal with i386 (and > hopefully pc98) later. I'll discuss this with nyan@. > > How to test this: > > 1. Make sure you run 9.0-CURRENT SVN r199175 or later. > 2. Run `vidcontrol -T xterm'. > 3. Run `export TERM=xterm'. > > After doing this, you shouldn't notice a lot. Make sure applications > like your shell, your editor, etc. still work as expected. > > Known issues: > > - Right now we only implement the VT220 mouse protocol. This means your > mouse should still work properly, but applications are only capable of > detecting drags/selections after releasing the mouse button. This > could eventually be solved by implementing the Xterm mouse protocol. Mouse positioning works only on ttyv0. > > If no serious problems arise, I'll make Xterm the default on > Friday/Saturday. > > -- > Ed Schouten > WWW: http://80386.nl/ > -- Paul B Mahol From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 16:44:08 2010 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 A11011065694 for ; Sun, 10 Jan 2010 16:44:08 +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 340A58FC1D for ; Sun, 10 Jan 2010 16:44:07 +0000 (UTC) Received: by bwz5 with SMTP id 5so13257288bwz.3 for ; Sun, 10 Jan 2010 08:44:01 -0800 (PST) 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=iymvJQq25RSKAoQLrPvolK3FdcjjBYDsXL3BJspucHw=; b=OObhzJYo47DBFQ/Np20Dof5OSH64+L/rg+cHGZJlcA/MEG2nAHYF+cJC3QHt8DnOmH Y0p663DxFhLvEa1rIiGsF4QIHDrScMg2QhIbXr7U8OAbnaZcKFarR/SFBQNo2cxBAwSV nnDgmFRnR0R4RtTBCd+lxq+jp331LQZWgaHH8= 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=PE+93G7WWEDzN3UarrvFr8LnBNb/+ECQEmi607q/4jwsJRCwkHFyQIo5zLAc+bChvm Ni9kF2b6XzkPe6x3z3fLIpvLmyynRldhHTN+TTepL+2J+pdn6/dFU1mOTnCl2Qgc/ug8 AyfOpIK68Lv78iJMOu3cvNdGszw2QeuuomHEk= MIME-Version: 1.0 Received: by 10.204.10.19 with SMTP id n19mr1398051bkn.19.1263141840747; Sun, 10 Jan 2010 08:44:00 -0800 (PST) In-Reply-To: <201001101827.09631.dima_bsd@inbox.lv> References: <201001101526.49411.dima_bsd@inbox.lv> <201001101827.09631.dima_bsd@inbox.lv> Date: Sun, 10 Jan 2010 19:44:00 +0300 Message-ID: From: pluknet To: Dmitriy Demidov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 16:44:08 -0000 2010/1/10 Dmitriy Demidov : > On Sunday 10 January 2010, pluknet wrote: >> After looking on line numbers I'd suggest you to check >> if you've applied the patch two times (so suj.c "duplicates" itself). >> [...] > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c > cc1: warnings being treated as errors > /usr/src/sbin/fsck_ffs/suj.c:397: warning: 'ino_isfree' defined but not used > *** Error code 1 > You've patched correctly. The problem is in source itself: the ino_isfree() function was used in an earlier patch but #if 0'defed out in the current one. You should comment out ino_isfree() body to silent the compiler and try again. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 17:40:27 2010 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 C76D4106566C; Sun, 10 Jan 2010 17:40:27 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 904FE8FC18; Sun, 10 Jan 2010 17:40:27 +0000 (UTC) Received: by pxi12 with SMTP id 12so14041116pxi.3 for ; Sun, 10 Jan 2010 09:40:18 -0800 (PST) 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=oE3tEuyAQ3cg2Kudc/KIGU4cYqJXAvWSSOXoWMYmQCQ=; b=nkdpuMth5/xjet4626gSJkcBUZcQU1bWPr6gAG5k7TD9gZj1cckhv9RtIh6hPt0L3l yGvfgwnodPCN65wZBI84D7Q36wLh1rRvPGp2roLB+UN3DO4YXcIp6axPcf5TMSxeZoIf 5F+WzhX6OscF8eXIcl7G6Ks7QvJ/I/q9i4q9A= 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=VCkcgEdrLfPOTcLVanhTDTlm6BYFX8CErGW2rLwExd4EbKTEIzGyOBVP6JdvD67tFy BSLWU0JCXpKpkCErVytsmkRx+82VyeBStMascusU6aN31it38McEOOV0wZHs/1MK9ruS 8RFx/72B7n0aCjGwzXuiWwLlpyWEiUmoV3SoQ= MIME-Version: 1.0 Received: by 10.142.121.4 with SMTP id t4mr16742499wfc.256.1263145217561; Sun, 10 Jan 2010 09:40:17 -0800 (PST) In-Reply-To: <201001101437.37269.hselasky@c2i.net> References: <201001101437.37269.hselasky@c2i.net> Date: Sun, 10 Jan 2010 17:40:17 +0000 Message-ID: <179b97fb1001100940o74d5f42arcba36098dd0bdd34@mail.gmail.com> From: Brandon Gooch To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 10 Jan 2010 17:40:28 -0000 On Sun, Jan 10, 2010 at 1:37 PM, Hans Petter Selasky wro= te: > Hi, > > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which = links > with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX w= hich > is provided by the video4bsd kernel module. There is full support for > mmap/read/write/open/close. poll is not supported. > > Basic operation and idea: > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > interface for the V4L application. The video4bsd transports all data betw= een > these two devices. In the case the V4L application is using mmap, no data= is > copied due to shared kernel memory buffer! > > Licensing issues: > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB > drivers which are GPL licensed. Some files inside the webcamd remains BSD > licensed which allows for building similar BSD licensed daemons. > > The rest of the code is BSD licensed. > > Source code: > > 1) FreeBSD 8-stable > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > http://p4web.freebsd.org/chv.cgi?CH=3D172876 > > http://perforce.freebsd.org/chv.cgi?CH=3D172876 > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be che= cked > out in the same folder due to dependencies) > > svn --username anonsvn --password anonsvn \ > =A0 =A0 =A0checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > make all install > kldload video4bsd > > svn --username anonsvn --password anonsvn \ > =A0 =A0 =A0checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > make fetch > make patch > make all > make install > > # this will attach to the first detected webcam: > ./webcamd > > # this will try to attach to the given USB unit, interface and V4B unit. > ./webcamd -d ugen4.1 -i 0 -v 0 > > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > > Feedback and bug reports are welcome. > > Yes, I am working on getting this into ports! > > Known issues: > > 1) If you detach the USB webcam you need to manually restart the webcamd. > > --HPS > > Support: I will be available at #bsdusb on efnet during the day. Seems to work for just a second or two (I see my ugly mug on-screen), and then this: # ./pwcview/pwcview Webcam set to: 320x240 (sif) at 5 fps libv4lconvert: Error decompressing JPEG: fill_nbits error: need 8 more bits libv4l2: error converting / decoding frame data: v4l-convert: error parsing JPEG header: Not a JPG file ? >From another xterm: # ./webcamd -d ugen6.2 -v 0 -i 0 KrefGet: 0x800c90304 =3D 1 KrefGet: 0x800c90304 =3D 2 KrefGet: 0x800c9083c =3D 1 KrefGet: 0x800c9092c =3D 1 Added device 0x800ca4d08 KrefGet: 0x800ca4d0c =3D 1 KrefGet: 0x800ca4d0c =3D 2 size =3D 622592 alloc_nr =3D 0 KrefPut: 0x800ca4d0c =3D 2 >From dmesg: ugen6.2: at usbus6 From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 18:27:22 2010 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 D91331065694; Sun, 10 Jan 2010 18:27:21 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 373EA8FC1C; Sun, 10 Jan 2010 18:27:21 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0AIRDYi072857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 03:27:14 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 11 Jan 2010 03:27:13 +0900 Message-ID: From: Hajimu UMEMOTO To: David Horn In-Reply-To: <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Jan_11_03:27:13_2010-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 11 Jan 2010 03:27:14 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 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: Sun, 10 Jan 2010 18:27:23 -0000 --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >>>>> On Sat, 2 Jan 2010 20:36:45 -0500 >>>>> David Horn said: > dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify t= he default > dhorn2000> rc.firewall flow. > > Here is my proposed patch.  With this patch, 'me' matches to both IPv4 > and IPv6, and 'me4' is added for matching to only IPv4. dhorn2000> The patch for me4/me6 works perfect in my testing to date. I g= uess dhorn2000> we would need to convince a larger audience to get consensus on dhorn2000> changing the behavior for "me" token from just ipv4 to both ipv4= /ipv6, dhorn2000> but I personally think it is the right direction. Thank you for testing. I've added current@ and net@ to Cc:. It makes the IPv4/IPv6 dual stack rule definitely simpler that 'me' matches to both IPv4 and IPv6. I think it is desired feature. However, I'm not sure we actually need 'me4'. So, I split my previous patch into two patches. The 1st patch makes 'me' matches to both IPv4 and IPv6. The 2nd patch adds 'me4'. If there is no objection, I'll commit the 1st patch. If someone want 'me4', I'll commit the 2nd patch. And, the 3rd patch is for rc.firewall. dhorn2000> ipfw(8) man page already shows: dhorn2000> me matches any IP address configured on an interface in the dhorn2000> system. dhorn2000> me6 matches any IPv6 address configured on an interface in dhorn2000> the system. The address list is evaluated = at the time dhorn2000> the packet is analysed. I wish to believe this description about 'me' is correct. But, I'm not sure whether it is a feature or not. It might be that someone forgot to change it at the time when an IPv6 support was added to IPFW. Sincerely, --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-me-unify.diff" Content-Transfer-Encoding: 7bit Index: sys/netinet/ipfw/ip_fw2.c diff -u -p sys/netinet/ipfw/ip_fw2.c.orig sys/netinet/ipfw/ip_fw2.c --- sys/netinet/ipfw/ip_fw2.c.orig 2010-01-05 04:01:22.000000000 +0900 +++ sys/netinet/ipfw/ip_fw2.c 2010-01-08 12:30:31.039834764 +0900 @@ -1390,7 +1390,14 @@ do { \ INADDR_TO_IFP(src_ip, tif); match = (tif != NULL); + break; } + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_SRC_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.src_ip6); +#endif break; case O_IP_DST_SET: @@ -1423,7 +1430,14 @@ do { \ INADDR_TO_IFP(dst_ip, tif); match = (tif != NULL); + break; } + /* FALLTHROUGH */ +#ifdef INET6 + case O_IP6_DST_ME: + match = is_ipv6 && + search_ip6_addr_net(&args->f_id.dst_ip6); +#endif break; case O_IP_SRCPORT: @@ -1691,14 +1705,6 @@ do { \ } break; - case O_IP6_SRC_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.src_ip6); - break; - - case O_IP6_DST_ME: - match= is_ipv6 && search_ip6_addr_net(&args->f_id.dst_ip6); - break; - case O_FLOW6ID: match = is_ipv6 && flow6id_match(args->f_id.flow_id6, --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-me4.diff" Content-Transfer-Encoding: 7bit Index: sbin/ipfw/ipfw.8 diff -u sbin/ipfw/ipfw.8.orig sbin/ipfw/ipfw.8 --- sbin/ipfw/ipfw.8.orig 2009-12-15 18:46:27.000000000 +0900 +++ sbin/ipfw/ipfw.8 2010-01-08 12:33:36.117724529 +0900 @@ -1003,7 +1003,7 @@ its use is discouraged. .It Ar addr : Oo Cm not Oc Bro .Bl -tag -width indent -.Cm any | me | me6 | +.Cm any | me | me4 | me6 | .Cm table Ns Pq Ar number Ns Op , Ns Ar value .Ar | addr-list | addr-set .Brc @@ -1011,6 +1011,8 @@ matches any IP address. .It Cm me matches any IP address configured on an interface in the system. +.It Cm me4 +matches any IPv4 address configured on an interface in the system. .It Cm me6 matches any IPv6 address configured on an interface in the system. The address list is evaluated at the time the packet is Index: sbin/ipfw/ipfw2.c diff -u -p sbin/ipfw/ipfw2.c.orig sbin/ipfw/ipfw2.c --- sbin/ipfw/ipfw2.c.orig 2009-12-15 18:46:27.000000000 +0900 +++ sbin/ipfw/ipfw2.c 2010-01-08 12:33:36.037713520 +0900 @@ -768,6 +768,10 @@ print_ip(ipfw_insn_ip *cmd, char const * printf("me"); return; } + if (cmd->o.opcode == O_IP4_SRC_ME || cmd->o.opcode == O_IP4_DST_ME) { + printf("me4"); + return; + } if (cmd->o.opcode == O_IP_SRC_LOOKUP || cmd->o.opcode == O_IP_DST_LOOKUP) { printf("table(%u", ((ipfw_insn *)cmd)->arg1); @@ -1187,6 +1191,7 @@ show_ipfw(struct ip_fw *rule, int pcwidt case O_IP_SRC_LOOKUP: case O_IP_SRC_MASK: case O_IP_SRC_ME: + case O_IP4_SRC_ME: case O_IP_SRC_SET: show_prerequisites(&flags, HAVE_PROTO, 0); if (!(flags & HAVE_SRCIP)) @@ -1202,6 +1207,7 @@ show_ipfw(struct ip_fw *rule, int pcwidt case O_IP_DST_LOOKUP: case O_IP_DST_MASK: case O_IP_DST_ME: + case O_IP4_DST_ME: case O_IP_DST_SET: show_prerequisites(&flags, HAVE_PROTO|HAVE_SRCIP, 0); if (!(flags & HAVE_DSTIP)) @@ -1972,6 +1978,12 @@ fill_ip(ipfw_insn_ip *cmd, char *av) return; } + if (strcmp(av, "me4") == 0) { + cmd->o.opcode = O_IP4_DST_ME; + cmd->o.len |= F_INSN_SIZE(ipfw_insn); + return; + } + if (strncmp(av, "table(", 6) == 0) { char *p = strchr(av + 6, ','); @@ -2478,6 +2490,8 @@ add_srcip(ipfw_insn *cmd, char *av) cmd->opcode = O_IP_SRC_SET; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ cmd->opcode = O_IP_SRC_LOOKUP; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + cmd->opcode = O_IP4_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_SRC_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2495,6 +2509,8 @@ add_dstip(ipfw_insn *cmd, char *av) ; else if (cmd->opcode == O_IP_DST_LOOKUP) /* table */ ; + else if (cmd->opcode == O_IP4_DST_ME) /* me4 */ + ; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn)) /* me */ cmd->opcode = O_IP_DST_ME; else if (F_LEN(cmd) == F_INSN_SIZE(ipfw_insn_u32)) /* one IP */ @@ -2534,7 +2550,7 @@ add_src(ipfw_insn *cmd, char *av, u_char ret = add_srcip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_srcip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; @@ -2560,7 +2576,7 @@ add_dst(ipfw_insn *cmd, char *av, u_char ret = add_dstip6(cmd, av); /* XXX: should check for IPv4, not !IPv6 */ if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || - !inet_pton(AF_INET6, host, &a))) + strcmp(av, "me4") == 0 || !inet_pton(AF_INET6, host, &a))) ret = add_dstip(cmd, av); if (ret == NULL && strcmp(av, "any") != 0) ret = cmd; Index: sys/netinet/ip_fw.h diff -u sys/netinet/ip_fw.h.orig sys/netinet/ip_fw.h --- sys/netinet/ip_fw.h.orig 2009-12-23 04:01:47.000000000 +0900 +++ sys/netinet/ip_fw.h 2010-01-08 12:33:36.157742465 +0900 @@ -166,6 +166,8 @@ O_ALTQ, /* u32 = altq classif. qid */ O_DIVERTED, /* arg1=bitmap (1:loop, 2:out) */ O_TCPDATALEN, /* arg1 = tcp data len */ + O_IP4_SRC_ME, /* none */ + O_IP4_DST_ME, /* none */ O_IP6_SRC, /* address without mask */ O_IP6_SRC_ME, /* my addresses */ O_IP6_SRC_MASK, /* address with the mask */ Index: sys/netinet/ipfw/ip_fw2.c diff -u -p sys/netinet/ipfw/ip_fw2.c.orig sys/netinet/ipfw/ip_fw2.c --- sys/netinet/ipfw/ip_fw2.c.orig 2010-01-08 12:30:31.039834764 +0900 +++ sys/netinet/ipfw/ip_fw2.c 2010-01-08 12:38:30.778824466 +0900 @@ -1385,6 +1385,7 @@ do { \ break; case O_IP_SRC_ME: + case O_IP4_SRC_ME: if (is_ipv4) { struct ifnet *tif; @@ -1392,6 +1393,8 @@ do { \ match = (tif != NULL); break; } + if (cmd->opcode == O_IP4_SRC_ME) + break; /* FALLTHROUGH */ #ifdef INET6 case O_IP6_SRC_ME: @@ -1425,6 +1428,7 @@ do { \ break; case O_IP_DST_ME: + case O_IP4_DST_ME: if (is_ipv4) { struct ifnet *tif; @@ -1432,6 +1436,8 @@ do { \ match = (tif != NULL); break; } + if (cmd->opcode == O_IP4_DST_ME) + break; /* FALLTHROUGH */ #ifdef INET6 case O_IP6_DST_ME: Index: sys/netinet/ipfw/ip_fw_sockopt.c diff -u -p sys/netinet/ipfw/ip_fw_sockopt.c.orig sys/netinet/ipfw/ip_fw_sockopt.c --- sys/netinet/ipfw/ip_fw_sockopt.c.orig 2010-01-07 19:08:05.000000000 +0900 +++ sys/netinet/ipfw/ip_fw_sockopt.c 2010-01-08 12:33:36.237826387 +0900 @@ -529,6 +529,8 @@ check_ipfw_struct(struct ip_fw *rule, in case O_VERSRCREACH: case O_ANTISPOOF: case O_IPSEC: + case O_IP4_SRC_ME: + case O_IP4_DST_ME: #ifdef INET6 case O_IP6_SRC_ME: case O_IP6_DST_ME: --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="rc.firewall-me-unify.diff" Content-Transfer-Encoding: 7bit Index: etc/defaults/rc.conf diff -u etc/defaults/rc.conf.orig etc/defaults/rc.conf --- etc/defaults/rc.conf.orig 2010-01-02 04:09:40.000000000 +0900 +++ etc/defaults/rc.conf 2010-01-08 18:08:10.227416014 +0900 @@ -143,9 +143,7 @@ firewall_allowservices="" # List of IPs which have access to # $firewall_myservices for "workstation" # firewall. -firewall_trusted="" # List of IPv4s which have full access to this - # host for "workstation" firewall. -firewall_trusted_ipv6="" # List of IPv6s which have full access to this +firewall_trusted="" # List of IPs which have full access to this # host for "workstation" firewall. firewall_logdeny="NO" # Set to YES to log default denied incoming # packets for "workstation" firewall. Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2010-01-08 18:07:55.805178124 +0900 +++ etc/rc.firewall 2010-01-08 18:08:42.558168213 +0900 @@ -212,8 +212,8 @@ ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me if [ -n "$net6" ]; then - ${fwcmd} add pass all from me6 to ${net6} - ${fwcmd} add pass all from ${net6} to me6 + ${fwcmd} add pass all from me to ${net6} + ${fwcmd} add pass all from ${net6} to me fi if [ -n "$net6" ]; then @@ -221,7 +221,7 @@ ${fwcmd} add pass all from fe80::/10 to ff02::/16 ${fwcmd} add pass all from ${net6} to ff02::/16 # Allow DHCPv6 - ${fwcmd} add pass udp from fe80::/10 to me6 546 + ${fwcmd} add pass udp from fe80::/10 to me 546 fi # Allow TCP through if setup succeeded @@ -232,30 +232,18 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup - if [ -n "$net6" ]; then - ${fwcmd} add pass tcp from any to me6 25 setup - fi # Allow setup of outgoing TCP connections only ${fwcmd} add pass tcp from me to any setup - if [ -n "$net6" ]; then - ${fwcmd} add pass tcp from me6 to any setup - fi # Disallow setup of all other TCP connections ${fwcmd} add deny tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state - if [ -n "$net6" ]; then - ${fwcmd} add pass udp from me6 to any 53 keep-state - fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state - if [ -n "$net6" ]; then - ${fwcmd} add pass udp from me6 to any 123 keep-state - fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel @@ -402,25 +390,14 @@ # Allow setup of incoming email ${fwcmd} add pass tcp from any to me 25 setup - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 25 setup - fi # Allow access to our DNS ${fwcmd} add pass tcp from any to me 53 setup ${fwcmd} add pass udp from any to me 53 ${fwcmd} add pass udp from me 53 to any - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 53 setup - ${fwcmd} add pass udp from any to me6 53 - ${fwcmd} add pass udp from me6 53 to any - fi # Allow access to our WWW ${fwcmd} add pass tcp from any to me 80 setup - if [ -n "$inet6" ]; then - ${fwcmd} add pass tcp from any to me6 80 setup - fi # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp @@ -434,15 +411,9 @@ # Allow DNS queries out in the world ${fwcmd} add pass udp from me to any 53 keep-state - if [ -n "$inet6" ]; then - ${fwcmd} add pass udp from me6 to any 53 keep-state - fi # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state - if [ -n "$inet6" ]; then - ${fwcmd} add pass udp from me6 to any 123 keep-state - fi # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel @@ -477,18 +448,13 @@ # For services permitted below. ${fwcmd} add pass tcp from me to any established - if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from me6 to any established - fi # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from me6 to any setup keep-state - ${fwcmd} add pass udp from me6 to any keep-state - ${fwcmd} add pass ipv6-icmp from me6 to any keep-state + ${fwcmd} add pass ipv6-icmp from me to any keep-state fi # Allow DHCP. @@ -496,7 +462,7 @@ ${fwcmd} add pass udp from any 67 to me 68 in ${fwcmd} add pass udp from any 67 to 255.255.255.255 68 in if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass udp from fe80::/10 to me6 546 in + ${fwcmd} add pass udp from fe80::/10 to me 546 in fi # Some servers will ping the IP while trying to decide if it's # still in use. @@ -525,21 +491,15 @@ for i in ${firewall_allowservices} ; do for j in ${firewall_myservices} ; do ${fwcmd} add pass tcp from $i to me $j - if [ $ipv6_available -eq 0 ]; then - ${fwcmd} add pass tcp from $i to me6 $j - fi done done # Allow all connections from trusted IPs. # Playing with the content of firewall_trusted could seriously # degrade the level of protection provided by the firewall. - for i in ${firewall_trusted} ; do + for i in ${firewall_trusted} ${firewall_trusted_ipv6}; do ${fwcmd} add pass ip from $i to me done - for i in ${firewall_trusted_ipv6} ; do - ${fwcmd} add pass all from $i to me6 - done ${fwcmd} add 65000 count ip from any to any --Multipart_Mon_Jan_11_03:27:13_2010-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Jan_11_03:27:13_2010-1-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 18:44:28 2010 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 E31AB106566B; Sun, 10 Jan 2010 18:44:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A1A518FC0C; Sun, 10 Jan 2010 18:44:28 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 42D9B73106; Sun, 10 Jan 2010 19:52:32 +0100 (CET) Date: Sun, 10 Jan 2010 19:52:32 +0100 From: Luigi Rizzo To: Hajimu UMEMOTO Message-ID: <20100110185232.GA27907@onelab2.iet.unipi.it> References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com> <25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com> <25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: Re: Unified rc.firewall ipfw me/me6 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: Sun, 10 Jan 2010 18:44:29 -0000 On Mon, Jan 11, 2010 at 03:27:13AM +0900, Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sat, 2 Jan 2010 20:36:45 -0500 > >>>>> David Horn said: > > > dhorn2000> Yes, "me" matching either ipv4/ipv6 would certainly simplify the default > > dhorn2000> rc.firewall flow. > > > > Here is my proposed patch. ??With this patch, 'me' matches to both IPv4 > > and IPv6, and 'me4' is added for matching to only IPv4. > > dhorn2000> The patch for me4/me6 works perfect in my testing to date. I guess > dhorn2000> we would need to convince a larger audience to get consensus on > dhorn2000> changing the behavior for "me" token from just ipv4 to both ipv4/ipv6, > dhorn2000> but I personally think it is the right direction. > > Thank you for testing. > I've added current@ and net@ to Cc:. > It makes the IPv4/IPv6 dual stack rule definitely simpler that 'me' > matches to both IPv4 and IPv6. I think it is desired feature. > However, I'm not sure we actually need 'me4'. So, I split my previous > patch into two patches. The 1st patch makes 'me' matches to both IPv4 > and IPv6. The 2nd patch adds 'me4'. > If there is no objection, I'll commit the 1st patch. If someone want > 'me4', I'll commit the 2nd patch. We only need one 'me' option that matches v4 and v6, because the other two can be implemented as 'ip4 me' and 'ip6 me' at no extra cost (the code for 'me' only scans the list corresponding to the actual address family of the packet). I would actually vote for removing the 'me6' microinstruction from the kernel, and implement it in /sbin/ipfw by generating 'ip6 me'. Feel free to commit the change yourself. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 19:33:03 2010 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 7FB86106568F; Sun, 10 Jan 2010 19:33:03 +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 7BC818FC16; Sun, 10 Jan 2010 19:33:02 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=OdR5sfXFAAAA:8 a=Qd2203DERVxIISpw-G8A:9 a=QmE9FGGqE5A4QaQAyOwA:7 a=pgQXwYCw-eX86rDFpIob2WWeY64A:4 a=9aOQ2cSd83gA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1333031176; Sun, 10 Jan 2010 20:32:59 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 10 Jan 2010 20:31:37 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <179b97fb1001100940o74d5f42arcba36098dd0bdd34@mail.gmail.com> In-Reply-To: <179b97fb1001100940o74d5f42arcba36098dd0bdd34@mail.gmail.com> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001102031.37846.hselasky@c2i.net> Cc: Brandon Gooch , freebsd-multimedia@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 10 Jan 2010 19:33:03 -0000 On Sunday 10 January 2010 18:40:17 Brandon Gooch wrote: > On Sun, Jan 10, 2010 at 1:37 PM, Hans Petter Selasky wrote: > > Hi, > > > > During the last couple of days I've spent some time to finish my webcam > > daemon. My webcam daemon is basically an application which consists of > > userspace Video4Linux USB webcam drivers and some uLinux glue code which > > links with libc, pthreads and libusb. The webcamd talks to > > /dev/video_daemonX which is provided by the video4bsd kernel module. > > There is full support for mmap/read/write/open/close. poll is not > > supported. > > > > Basic operation and idea: > > > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > > interface for the V4L application. The video4bsd transports all data > > between these two devices. In the case the V4L application is using mmap, > > no data is copied due to shared kernel memory buffer! > > > > Licensing issues: > > > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB > > drivers which are GPL licensed. Some files inside the webcamd remains BSD > > licensed which allows for building similar BSD licensed daemons. > > > > The rest of the code is BSD licensed. > > > > Source code: > > > > 1) FreeBSD 8-stable > > > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > > > http://p4web.freebsd.org/chv.cgi?CH=172876 > > > > http://perforce.freebsd.org/chv.cgi?CH=172876 > > > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be > > checked out in the same folder due to dependencies) > > > > svn --username anonsvn --password anonsvn \ > > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > > > make all install > > kldload video4bsd > > > > svn --username anonsvn --password anonsvn \ > > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > > > make fetch > > make patch > > make all > > make install > > > > # this will attach to the first detected webcam: > > ./webcamd > > > > # this will try to attach to the given USB unit, interface and V4B unit. > > ./webcamd -d ugen4.1 -i 0 -v 0 > > > > # this will display webcam contents from /dev/video0 by default. > > ./pwcview/pwcview > > > > Feedback and bug reports are welcome. > > > > Yes, I am working on getting this into ports! > > > > Known issues: > > > > 1) If you detach the USB webcam you need to manually restart the webcamd. > > > > --HPS > > > > Support: I will be available at #bsdusb on efnet during the day. > > Seems to work for just a second or two (I see my ugly mug on-screen), > and then this: > > # ./pwcview/pwcview > Webcam set to: 320x240 (sif) at 5 fps > libv4lconvert: Error decompressing JPEG: fill_nbits error: need 8 more bits > libv4l2: error converting / decoding frame data: v4l-convert: error > parsing JPEG header: Not a JPG file ? Hi, Maybe this is related to a bug in the recent JPEG library. Try googling. You can also try another mode: webcamd -s vga Or other commands. See webcamd -h . --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 19:36:08 2010 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 9F70F106566B; Sun, 10 Jan 2010 19:36:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id C8DEE8FC0A; Sun, 10 Jan 2010 19:36:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=bHvbTPOMyU9hYO28HoIA:9 a=JZHLitKwCXKyWqNstl2NLEfwOLMA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 592860710; Sun, 10 Jan 2010 20:36:05 +0100 From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org Date: Sun, 10 Jan 2010 20:34:44 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <179b97fb1001100940o74d5f42arcba36098dd0bdd34@mail.gmail.com> <201001102031.37846.hselasky@c2i.net> In-Reply-To: <201001102031.37846.hselasky@c2i.net> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001102034.44191.hselasky@c2i.net> Cc: Brandon Gooch , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 10 Jan 2010 19:36:08 -0000 On Sunday 10 January 2010 20:31:37 Hans Petter Selasky wrote: > > Hi, > > Maybe this is related to a bug in the recent JPEG library. Try googling. > > You can also try another mode: > > webcamd -s vga > > Or other commands. See webcamd -h . s/webcamd/pwcview/ --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 19:40:42 2010 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 CA013106568D; Sun, 10 Jan 2010 19:40:42 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id ABB6F8FC1C; Sun, 10 Jan 2010 19:40:42 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o0AJefGA028050; Sun, 10 Jan 2010 11:40:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Jan 2010 11:40:34 -0800 Message-ID: In-Reply-To: <20100110185232.GA27907@onelab2.iet.unipi.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unified rc.firewall ipfw me/me6 issue Thread-Index: AcqSJSaXOe/YiAX5TAqjTGXen62l7AAB4P+Q References: <25ff90d60912162320y286e37a0ufeb64397716d8c18@mail.gmail.com><25ff90d60912180612y2b1f64fbw34b4d7f648762087@mail.gmail.com><25ff90d61001021736p7b695197q104f4a7769b51b71@mail.gmail.com> <20100110185232.GA27907@onelab2.iet.unipi.it> From: "Li, Qing" To: "Luigi Rizzo" , "Hajimu UMEMOTO" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, David Horn , freebsd-ipfw@freebsd.org Subject: RE: Unified rc.firewall ipfw me/me6 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: Sun, 10 Jan 2010 19:40:42 -0000 >=20 > We only need one 'me' option that matches v4 and v6, because the > other two can be implemented as 'ip4 me' and 'ip6 me' at no extra > cost (the code for 'me' only scans the list corresponding to the > actual address family of the packet). I would actually vote for > removing the 'me6' microinstruction from the kernel, and implement > it in /sbin/ipfw by generating 'ip6 me'. >=20 I agree with Luigi. -- Qing From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 22:03:55 2010 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 40930106566B; Sun, 10 Jan 2010 22:03:55 +0000 (UTC) (envelope-from diego.ochoat@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 750928FC13; Sun, 10 Jan 2010 22:03:54 +0000 (UTC) Received: by fxm10 with SMTP id 10so7289796fxm.14 for ; Sun, 10 Jan 2010 14:03:47 -0800 (PST) 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=vfmy/Br+FSUphIqrJFkHakDVsQOu28siXKtJle/JBL4=; b=QyGdq6xFZly5N9IMMC0qffV+V7upNzmOm1CMi11XK38pfEq0xAKumfncPKf/c0cMHp hnQxgsvUTW379NCRa3xZfYJul+on7oes2Z/ds1AjYwrqZBQ6lIaFA5iv9h0SNOGzlSfT rwlzXvwBF4QPOkWl2G6riM5+hDfeiV/JVTSNc= 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=QwJ1XKqhfBHDrdnPJwbMCjRlQmGjrObxTP0HDJ7Xe5nE/9ogCpb0/oSdpp5kqeZWUs 8/mJcIi+HHsa/92TMZDBWl1SfXmH9LtY+6ku08EzkS+QzxV6RvXywLGZXRSs7snDszIQ 5VdLskvtWCAPc2rI9JoNCB37AZgEOOKIFEibU= MIME-Version: 1.0 Received: by 10.239.159.146 with SMTP id y18mr829029hbc.196.1263159130107; Sun, 10 Jan 2010 13:32:10 -0800 (PST) In-Reply-To: <201001102034.44191.hselasky@c2i.net> References: <201001101437.37269.hselasky@c2i.net> <179b97fb1001100940o74d5f42arcba36098dd0bdd34@mail.gmail.com> <201001102031.37846.hselasky@c2i.net> <201001102034.44191.hselasky@c2i.net> From: Diego Ochoa Tocachi Date: Sun, 10 Jan 2010 16:31:50 -0500 Message-ID: <6951cb851001101331k20b47961ve5b037c44a0ca9d7@mail.gmail.com> To: Hans Petter Selasky X-Mailman-Approved-At: Sun, 10 Jan 2010 22:57:39 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-multimedia@freebsd.org, Brandon Gooch , freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 10 Jan 2010 22:03:55 -0000 2010/1/10 Hans Petter Selasky > On Sunday 10 January 2010 20:31:37 Hans Petter Selasky wrote: > > > > Hi, > > > > Maybe this is related to a bug in the recent JPEG library. Try googling. > > > > You can also try another mode: > > > > webcamd -s vga > > > > Or other commands. See webcamd -h . > > s/webcamd/pwcview/ > > --HPS > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to " > freebsd-multimedia-unsubscribe@freebsd.org" > Hi, I was trying this driver with: my webcam: ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON my system: FreeBSD starkiller 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 When turn on the webcam: Jan 10 16:13:25 starkiller root: Unknown USB device: vendor 0x046d product 0x09b6 bus uhub7 Jan 10 16:13:25 starkiller kernel: ugen7.2: at usbus7 when execute ./webcamd -d ugen7.2 -i 0 -v 0 Jan 10 16:13:29 starkiller root: Unknown USB device: vendor 0x046d product 0x09b6 bus uhub7 Issues: To access /dev/video0 with a no-root user in operator group, I changed permisions: chmod 0660 /dev/video0 manually I can access using pwcview but I cant access from cheese, Do I something to get this? Thanks for this software, good work!!! -- Diego Ochoa - darkbalder Luis Pasteur 2-30 y Copernico Telf: +593 7 4082144 Porta: 090085391 Cuenca - Ecuador From owner-freebsd-current@FreeBSD.ORG Sun Jan 10 23:10:27 2010 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 46B0F1065694 for ; Sun, 10 Jan 2010 23:10:27 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id DDC1F8FC20 for ; Sun, 10 Jan 2010 23:10:26 +0000 (UTC) Received: by gxk10 with SMTP id 10so19937913gxk.3 for ; Sun, 10 Jan 2010 15:10:15 -0800 (PST) Received: by 10.150.21.26 with SMTP id 26mr468447ybu.192.1263165015572; Sun, 10 Jan 2010 15:10:15 -0800 (PST) Received: from ?10.0.1.198? (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 8sm8718579ywg.19.2010.01.10.15.10.11 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Jan 2010 15:10:13 -0800 (PST) Date: Sun, 10 Jan 2010 13:13:08 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Dmitriy Demidov In-Reply-To: <201001101827.09631.dima_bsd@inbox.lv> Message-ID: References: <201001101526.49411.dima_bsd@inbox.lv> <201001101827.09631.dima_bsd@inbox.lv> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pluknet , freebsd-current@freebsd.org Subject: Re: Help test softupdates journaling (SUJ) 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, 10 Jan 2010 23:10:27 -0000 On Sun, 10 Jan 2010, Dmitriy Demidov wrote: > On Sunday 10 January 2010, pluknet wrote: >> After looking on line numbers I'd suggest you to check >> if you've applied the patch two times (so suj.c "duplicates" itself). >> > > Unfortunately - no luck for me... > After removing all data from /usr/src + /usr/obj, and csup'ing fresh copy of CURRENT from cvsup.lv.freebsd.org, I still have buildworld erros: For some reason I see this ino_isfree error but it does not quit the build. You can comment out ino_isfree and it will proceed. I received another email mentioning that dumpfs perhaps doesn't build so buildworld may be a bad idea. Just make fsck_ffs, tunefs, and a kernel and you'll be set. Thanks, Jeff > > > == > (cd /usr/src/rescue/rescue/../../sbin/atacontrol && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/atacontrol/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/atacontrol/ atacontrol.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/atacontrol/atacontrol.c > echo atacontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/atacontrol/atacontrol.c > (cd /usr/src/rescue/rescue/../../sbin/badsect && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/badsect/ badsect.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/badsect/badsect.c > echo badsect: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/badsect/badsect.c > (cd /usr/src/rescue/rescue/../../sbin/camcontrol && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ camcontrol.o util.o modeedit.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/camcontrol/camcontrol.c /usr/src/sbin/camcontrol/util.c /usr/src/sbin/camcontrol/modeedit.c > echo camcontrol: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libcam.a /usr/obj/usr/src/tmp/usr/lib/libsbuf.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/camcontrol.c > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/util.c > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/camcontrol/modeedit.c > (cd /usr/src/rescue/rescue/../../sbin/ccdconfig && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ccdconfig/ ccdconfig.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/ccdconfig/ccdconfig.c > echo ccdconfig: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libgeom.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/ccdconfig/ccdconfig.c > (cd /usr/src/rescue/rescue/../../sbin/clri && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/clri/ clri.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/clri/clri.c > echo clri: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/clri/clri.c > (cd /usr/src/rescue/rescue/../../sbin/devfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/devfs/ devfs.o rule.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/devfs/devfs.c /usr/src/sbin/devfs/rule.c > echo devfs: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/devfs.c > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/sbin/devfs/rule.c > (cd /usr/src/rescue/rescue/../../sbin/dmesg && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dmesg/ dmesg.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/dmesg/dmesg.c > echo dmesg: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libkvm.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dmesg/dmesg.c > (cd /usr/src/rescue/rescue/../../sbin/dump && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dump/ itime.o main.o optr.o dumprmt.o tape.o traverse.o unctime.o cache.o) > rm -f .depend > mkdep -f .depend -a -DRDUMP -DRESCUE /usr/src/sbin/dump/itime.c /usr/src/sbin/dump/main.c /usr/src/sbin/dump/optr.c /usr/src/sbin/dump/dumprmt.c /usr/src/sbin/dump/tape.c /usr/src/sbin/dump/traverse.c /usr/src/sbin/dump/unctime.c /usr/src/sbin/dump/cache.c > echo dump: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/itime.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/main.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/optr.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/dumprmt.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/tape.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/traverse.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/unctime.c > cc -O2 -pipe -DRDUMP -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dump/cache.c > (cd /usr/src/rescue/rescue/../../sbin/dumpfs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpfs/ dumpfs.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpfs/dumpfs.c > echo dumpfs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/dumpfs/dumpfs.c > (cd /usr/src/rescue/rescue/../../sbin/dumpon && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/dumpon/ dumpon.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/dumpon/dumpon.c > echo dumpon: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/sbin/dumpon/dumpon.c > (cd /usr/src/rescue/rescue/../../sbin/fsck && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck/ fsck.o fsutil.o preen.o) > rm -f .depend > mkdep -f .depend -a -DRESCUE /usr/src/sbin/fsck/fsck.c /usr/src/sbin/fsck/fsutil.c /usr/src/sbin/fsck/preen.c > echo fsck: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsck.c > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/fsutil.c > cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck/preen.c > (cd /usr/src/rescue/rescue/../../sbin/fsck_ffs && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fsck_ffs/ dir.o ea.o fsutil.o inode.o main.o pass1.o pass1b.o pass2.o pass3.o pass4.o pass5.o setup.o suj.o utilities.o gjournal.o getmntopts.o) > rm -f .depend > mkdep -f .depend -a -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -DRESCUE /usr/src/sbin/fsck_ffs/dir.c /usr/src/sbin/fsck_ffs/ea.c /usr/src/sbin/fsck_ffs/fsutil.c /usr/src/sbin/fsck_ffs/inode.c /usr/src/sbin/fsck_ffs/main.c /usr/src/sbin/fsck_ffs/pass1.c /usr/src/sbin/fsck_ffs/pass1b.c /usr/src/sbin/fsck_ffs/pass2.c /usr/src/sbin/fsck_ffs/pass3.c /usr/src/sbin/fsck_ffs/pass4.c /usr/src/sbin/fsck_ffs/pass5.c /usr/src/sbin/fsck_ffs/setup.c /usr/src/sbin/fsck_ffs/suj.c /usr/src/sbin/fsck_ffs/utilities.c /usr/src/sbin/fsck_ffs/gjournal.c /usr/src/sbin/fsck_ffs/../mount/getmntopts.c > echo fsck_ffs: /usr/obj/usr/src/tmp/usr/lib/libc.a /usr/obj/usr/src/tmp/usr/lib/libufs.a >> .depend > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/dir.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/ea.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/fsutil.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/inode.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/main.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass1b.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass2.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass3.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass4.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/pass5.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/setup.c > cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c > cc1: warnings being treated as errors > /usr/src/sbin/fsck_ffs/suj.c:397: warning: 'ino_isfree' defined but not used > *** Error code 1 > > Stop in /usr/src/sbin/fsck_ffs. > *** Error code 1 > > Stop in /usr/obj/usr/src/rescue/rescue. > *** Error code 1 > > Stop in /usr/src/rescue/rescue. > *** Error code 1 > > Stop in /usr/src/rescue. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > == > > > > > > Here is a log of patching: > > == > > Script started on Sun Jan 10 16:21:26 2010 > evo# > evo# patch < /home/terminus/suj.diff > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/suj.c > |=================================================================== > |--- sbin/fsck_ffs/suj.c (revision 0) > |+++ sbin/fsck_ffs/suj.c (revision 0) > -------------------------- > (Creating file sbin/fsck_ffs/suj.c...) > Patching file sbin/fsck_ffs/suj.c using Plan A... > Hunk #1 succeeded at 1. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/gjournal.c > |=================================================================== > |--- sbin/fsck_ffs/gjournal.c (revision 201766) > |+++ sbin/fsck_ffs/gjournal.c (working copy) > -------------------------- > Patching file sbin/fsck_ffs/gjournal.c using Plan A... > Hunk #1 succeeded at 96. > Hunk #2 succeeded at 221. > Hunk #3 succeeded at 236. > Hunk #4 succeeded at 245. > Hunk #5 succeeded at 255. > Hunk #6 succeeded at 272. > Hunk #7 succeeded at 285. > Hunk #8 succeeded at 302. > Hunk #9 succeeded at 332. > Hunk #10 succeeded at 404. > Hunk #11 succeeded at 480. > Hunk #12 succeeded at 505. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/main.c > |=================================================================== > |--- sbin/fsck_ffs/main.c (revision 201766) > |+++ sbin/fsck_ffs/main.c (working copy) > -------------------------- > Patching file sbin/fsck_ffs/main.c using Plan A... > Hunk #1 succeeded at 256. > Hunk #2 succeeded at 278. > Hunk #3 succeeded at 311. > Hunk #4 succeeded at 493. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/pass4.c > |=================================================================== > |--- sbin/fsck_ffs/pass4.c (revision 201766) > |+++ sbin/fsck_ffs/pass4.c (working copy) > -------------------------- > Patching file sbin/fsck_ffs/pass4.c using Plan A... > Hunk #1 succeeded at 72. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/pass5.c > |=================================================================== > |--- sbin/fsck_ffs/pass5.c (revision 201766) > |+++ sbin/fsck_ffs/pass5.c (working copy) > -------------------------- > Patching file sbin/fsck_ffs/pass5.c using Plan A... > Hunk #1 succeeded at 45. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/fsck.h > |=================================================================== > |--- sbin/fsck_ffs/fsck.h (revision 201766) > |+++ sbin/fsck_ffs/fsck.h (working copy) > -------------------------- > Patching file sbin/fsck_ffs/fsck.h using Plan A... > Hunk #1 succeeded at 347. > Hunk #2 succeeded at 388. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsck_ffs/Makefile > |=================================================================== > |--- sbin/fsck_ffs/Makefile (revision 201766) > |+++ sbin/fsck_ffs/Makefile (working copy) > -------------------------- > Patching file sbin/fsck_ffs/Makefile using Plan A... > Hunk #1 succeeded at 7. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/fsdb/fsdbutil.c > |=================================================================== > |--- sbin/fsdb/fsdbutil.c (revision 201766) > |+++ sbin/fsdb/fsdbutil.c (working copy) > -------------------------- > Patching file sbin/fsdb/fsdbutil.c using Plan A... > Hunk #1 succeeded at 52. > Hunk #2 succeeded at 226. > Hunk #3 succeeded at 234. > Hunk #4 succeeded at 254. > Hunk #5 succeeded at 270. > Hunk #6 succeeded at 310. > Hunk #7 succeeded at 318. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sbin/tunefs/tunefs.c > |=================================================================== > |--- sbin/tunefs/tunefs.c (revision 201766) > |+++ sbin/tunefs/tunefs.c (working copy) > -------------------------- > Patching file sbin/tunefs/tunefs.c using Plan A... > Hunk #1 succeeded at 61. > Hunk #2 succeeded at 73. > Hunk #3 succeeded at 93. > Hunk #4 succeeded at 137. > Hunk #5 succeeded at 254. > Hunk #6 succeeded at 334. > Hunk #7 succeeded at 507. > Hunk #8 succeeded at 751. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/inode.c > |=================================================================== > |--- lib/libufs/inode.c (revision 201766) > |+++ lib/libufs/inode.c (working copy) > -------------------------- > Patching file lib/libufs/inode.c using Plan A... > Hunk #1 succeeded at 93. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/cgroup.c > |=================================================================== > |--- lib/libufs/cgroup.c (revision 201766) > |+++ lib/libufs/cgroup.c (working copy) > -------------------------- > Patching file lib/libufs/cgroup.c using Plan A... > Hunk #1 succeeded at 40. > Hunk #2 succeeded at 126. > Hunk #3 succeeded at 142. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/type.c > |=================================================================== > |--- lib/libufs/type.c (revision 201766) > |+++ lib/libufs/type.c (working copy) > -------------------------- > Patching file lib/libufs/type.c using Plan A... > Hunk #1 succeeded at 66. > Hunk #2 succeeded at 160. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/libufs.h > |=================================================================== > |--- lib/libufs/libufs.h (revision 201766) > |+++ lib/libufs/libufs.h (working copy) > -------------------------- > Patching file lib/libufs/libufs.h using Plan A... > Hunk #1 succeeded at 71. > Hunk #2 succeeded at 110. > Hunk #3 succeeded at 137. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/Makefile > |=================================================================== > |--- lib/libufs/Makefile (revision 201766) > |+++ lib/libufs/Makefile (working copy) > -------------------------- > Patching file lib/libufs/Makefile using Plan A... > Hunk #1 succeeded at 3. > Hunk #2 succeeded at 16. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: lib/libufs/sblock.c > |=================================================================== > |--- lib/libufs/sblock.c (revision 201766) > |+++ lib/libufs/sblock.c (working copy) > -------------------------- > Patching file lib/libufs/sblock.c using Plan A... > Hunk #1 succeeded at 40. > Hunk #2 succeeded at 50. > Hunk #3 succeeded at 90. > Hunk #4 succeeded at 125. > Hunk #5 succeeded at 140. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ufs/ufs_dirhash.c > |=================================================================== > |--- sys/ufs/ufs/ufs_dirhash.c (revision 201766) > |+++ sys/ufs/ufs/ufs_dirhash.c (working copy) > -------------------------- > Patching file sys/ufs/ufs/ufs_dirhash.c using Plan A... > Hunk #1 succeeded at 68. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ufs/ufs_vnops.c > |=================================================================== > |--- sys/ufs/ufs/ufs_vnops.c (revision 201766) > |+++ sys/ufs/ufs/ufs_vnops.c (working copy) > -------------------------- > Patching file sys/ufs/ufs/ufs_vnops.c using Plan A... > Hunk #1 succeeded at 114. > Hunk #2 succeeded at 976. > Hunk #3 succeeded at 993. > Hunk #4 succeeded at 1006. > Hunk #5 succeeded at 1048. > Hunk #6 succeeded at 1067. > Hunk #7 succeeded at 1111. > Hunk #8 succeeded at 1296. > Hunk #9 succeeded at 1390. > Hunk #10 succeeded at 1401. > Hunk #11 succeeded at 1416. > Hunk #12 succeeded at 1444. > Hunk #13 succeeded at 1741. > Hunk #14 succeeded at 1757. > Hunk #15 succeeded at 1867. > Hunk #16 succeeded at 1883. > Hunk #17 succeeded at 1892. > Hunk #18 succeeded at 1929. > Hunk #19 succeeded at 1959. > Hunk #20 succeeded at 2475. > Hunk #21 succeeded at 2607. > Hunk #22 succeeded at 2671. > Hunk #23 succeeded at 2687. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ufs/ufsmount.h > |=================================================================== > |--- sys/ufs/ufs/ufsmount.h (revision 201766) > |+++ sys/ufs/ufs/ufsmount.h (working copy) > -------------------------- > Patching file sys/ufs/ufs/ufsmount.h using Plan A... > Hunk #1 succeeded at 57. > Hunk #2 succeeded at 76. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ufs/ufs_lookup.c > |=================================================================== > |--- sys/ufs/ufs/ufs_lookup.c (revision 201766) > |+++ sys/ufs/ufs/ufs_lookup.c (working copy) > -------------------------- > Patching file sys/ufs/ufs/ufs_lookup.c using Plan A... > Hunk #1 succeeded at 77. > Hunk #2 succeeded at 186. > Hunk #3 succeeded at 521. > Hunk #4 succeeded at 545. > Hunk #5 succeeded at 552. > Hunk #6 succeeded at 568. > Hunk #7 succeeded at 609. > Hunk #8 succeeded at 645. > Hunk #9 succeeded at 678. > Hunk #10 succeeded at 822. > Hunk #11 succeeded at 900. > Hunk #12 succeeded at 988. > Hunk #13 succeeded at 1040. > Hunk #14 succeeded at 1059. > Hunk #15 succeeded at 1101. > Hunk #16 succeeded at 1143. > Hunk #17 succeeded at 1164. > Hunk #18 succeeded at 1210. > Hunk #19 succeeded at 1347. > Hunk #20 succeeded at 1376. > Hunk #21 succeeded at 1394. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ufs/ufs_extern.h > |=================================================================== > |--- sys/ufs/ufs/ufs_extern.h (revision 201766) > |+++ sys/ufs/ufs/ufs_extern.h (working copy) > -------------------------- > Patching file sys/ufs/ufs/ufs_extern.h using Plan A... > Hunk #1 succeeded at 57. > Hunk #2 succeeded at 66. > Hunk #3 succeeded at 83. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_vfsops.c > |=================================================================== > |--- sys/ufs/ffs/ffs_vfsops.c (revision 201766) > |+++ sys/ufs/ffs/ffs_vfsops.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_vfsops.c using Plan A... > Hunk #1 succeeded at 331. > Hunk #2 succeeded at 899. > Hunk #3 succeeded at 911. > Hunk #4 succeeded at 942. > Hunk #5 succeeded at 1871. > Hunk #6 succeeded at 1911. > Hunk #7 succeeded at 1933. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_softdep.c > |=================================================================== > |--- sys/ufs/ffs/ffs_softdep.c (revision 201766) > |+++ sys/ufs/ffs/ffs_softdep.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_softdep.c using Plan A... > Hunk #1 succeeded at 62. > Hunk #2 succeeded at 131. > Hunk #3 succeeded at 406. > Hunk #4 succeeded at 423. > Hunk #5 succeeded at 488. > Hunk #6 succeeded at 499. > Hunk #7 succeeded at 518. > Hunk #8 succeeded at 544. > Hunk #9 succeeded at 715. > Hunk #10 succeeded at 854. > Hunk #11 succeeded at 877. > Hunk #12 succeeded at 932. > Hunk #13 succeeded at 1009. > Hunk #14 succeeded at 1036. > Hunk #15 succeeded at 1054. > Hunk #16 succeeded at 1109. > Hunk #17 succeeded at 1143. > Hunk #18 succeeded at 1205. > Hunk #19 succeeded at 1225. > Hunk #20 succeeded at 1241. > Hunk #21 succeeded at 1252. > Hunk #22 succeeded at 1262. > Hunk #23 succeeded at 1281. > Hunk #24 succeeded at 1299. > Hunk #25 succeeded at 1322. > Hunk #26 succeeded at 1520. > Hunk #27 succeeded at 1543. > Hunk #28 succeeded at 1595. > Hunk #29 succeeded at 1606. > Hunk #30 succeeded at 1636. > Hunk #31 succeeded at 1665. > Hunk #32 succeeded at 1702. > Hunk #33 succeeded at 1711. > Hunk #34 succeeded at 1746. > Hunk #35 succeeded at 1773. > Hunk #36 succeeded at 1803. > Hunk #37 succeeded at 1844. > Hunk #38 succeeded at 3618. > Hunk #39 succeeded at 3652. > Hunk #40 succeeded at 3670. > Hunk #41 succeeded at 3742. > Hunk #42 succeeded at 3813. > Hunk #43 succeeded at 3826. > Hunk #44 succeeded at 3853. > Hunk #45 succeeded at 3902. > Hunk #46 succeeded at 3938. > Hunk #47 succeeded at 3957. > Hunk #48 succeeded at 3966. > Hunk #49 succeeded at 3982. > Hunk #50 succeeded at 4100. > Hunk #51 succeeded at 4133. > Hunk #52 succeeded at 4196. > Hunk #53 succeeded at 4246. > Hunk #54 succeeded at 4288. > Hunk #55 succeeded at 4326. > Hunk #56 succeeded at 4405. > Hunk #57 succeeded at 4466. > Hunk #58 succeeded at 4490. > Hunk #59 succeeded at 4571. > Hunk #60 succeeded at 4579. > Hunk #61 succeeded at 4594. > Hunk #62 succeeded at 4655. > Hunk #63 succeeded at 4694. > Hunk #64 succeeded at 4707. > Hunk #65 succeeded at 4723. > Hunk #66 succeeded at 4758. > Hunk #67 succeeded at 4781. > Hunk #68 succeeded at 4799. > Hunk #69 succeeded at 4824. > Hunk #70 succeeded at 4849. > Hunk #71 succeeded at 4904. > Hunk #72 succeeded at 5065. > Hunk #73 succeeded at 5083. > Hunk #74 succeeded at 5128. > Hunk #75 succeeded at 5139. > Hunk #76 succeeded at 5189. > Hunk #77 succeeded at 5198. > Hunk #78 succeeded at 5209. > Hunk #79 succeeded at 5236. > Hunk #80 succeeded at 5258. > Hunk #81 succeeded at 5387. > Hunk #82 succeeded at 5471. > Hunk #83 succeeded at 5528. > Hunk #84 succeeded at 5544. > Hunk #85 succeeded at 5560. > Hunk #86 succeeded at 5825. > Hunk #87 succeeded at 5842. > Hunk #88 succeeded at 5853. > Hunk #89 succeeded at 5954. > Hunk #90 succeeded at 5964. > Hunk #91 succeeded at 6161. > Hunk #92 succeeded at 6200. > Hunk #93 succeeded at 6275. > Hunk #94 succeeded at 6297. > Hunk #95 succeeded at 6368. > Hunk #96 succeeded at 6396. > Hunk #97 succeeded at 6441. > Hunk #98 succeeded at 6457. > Hunk #99 succeeded at 6490. > Hunk #100 succeeded at 6528. > Hunk #101 succeeded at 6568. > Hunk #102 succeeded at 6611. > Hunk #103 succeeded at 6637. > Hunk #104 succeeded at 6705. > Hunk #105 succeeded at 6735. > Hunk #106 succeeded at 6797. > Hunk #107 succeeded at 6807. > Hunk #108 succeeded at 6869. > Hunk #109 succeeded at 6881. > Hunk #110 succeeded at 6910. > Hunk #111 succeeded at 6981. > Hunk #112 succeeded at 6998. > Hunk #113 succeeded at 7046. > Hunk #114 succeeded at 7082. > Hunk #115 succeeded at 7137. > Hunk #116 succeeded at 7168. > Hunk #117 succeeded at 7186. > Hunk #118 succeeded at 7207. > Hunk #119 succeeded at 7244. > Hunk #120 succeeded at 7291. > Hunk #121 succeeded at 7313. > Hunk #122 succeeded at 7325. > Hunk #123 succeeded at 7358. > Hunk #124 succeeded at 7389. > Hunk #125 succeeded at 7407. > Hunk #126 succeeded at 7778. > Hunk #127 succeeded at 7790. > Hunk #128 succeeded at 7811. > Hunk #129 succeeded at 7820. > Hunk #130 succeeded at 7870. > Hunk #131 succeeded at 7880. > Hunk #132 succeeded at 7940. > Hunk #133 succeeded at 7970. > Hunk #134 succeeded at 7982. > Hunk #135 succeeded at 8097. > Hunk #136 succeeded at 8114. > Hunk #137 succeeded at 8132. > Hunk #138 succeeded at 8142. > Hunk #139 succeeded at 8156. > Hunk #140 succeeded at 8230. > Hunk #141 succeeded at 8272. > Hunk #142 succeeded at 8287. > Hunk #143 succeeded at 8422. > Hunk #144 succeeded at 8640. > Hunk #145 succeeded at 8653. > Hunk #146 succeeded at 8698. > Hunk #147 succeeded at 8735. > Hunk #148 succeeded at 8762. > Hunk #149 succeeded at 8777. > Hunk #150 succeeded at 8817. > Hunk #151 succeeded at 8845. > Hunk #152 succeeded at 8857. > Hunk #153 succeeded at 8881. > Hunk #154 succeeded at 8926. > Hunk #155 succeeded at 9025. > Hunk #156 succeeded at 9061. > Hunk #157 succeeded at 9127. > Hunk #158 succeeded at 9192. > Hunk #159 succeeded at 9216. > Hunk #160 succeeded at 9238. > Hunk #161 succeeded at 9259. > Hunk #162 succeeded at 9306. > Hunk #163 succeeded at 9320. > Hunk #164 succeeded at 9341. > Hunk #165 succeeded at 9365. > Hunk #166 succeeded at 9381. > Hunk #167 succeeded at 9414. > Hunk #168 succeeded at 9518. > Hunk #169 succeeded at 9535. > Hunk #170 succeeded at 9549. > Hunk #171 succeeded at 9605. > Hunk #172 succeeded at 9625. > Hunk #173 succeeded at 9942. > Hunk #174 succeeded at 9950. > Hunk #175 succeeded at 9997. > Hunk #176 succeeded at 10032. > Hunk #177 succeeded at 10053. > Hunk #178 succeeded at 10073. > Hunk #179 succeeded at 10325. > Hunk #180 succeeded at 10377. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_extern.h > |=================================================================== > |--- sys/ufs/ffs/ffs_extern.h (revision 201766) > |+++ sys/ufs/ffs/ffs_extern.h (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_extern.h using Plan A... > Hunk #1 succeeded at 56. > Hunk #2 succeeded at 110. > Hunk #3 succeeded at 119. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_alloc.c > |=================================================================== > |--- sys/ufs/ffs/ffs_alloc.c (revision 201766) > |+++ sys/ufs/ffs/ffs_alloc.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_alloc.c using Plan A... > Hunk #1 succeeded at 89. > Hunk #2 succeeded at 182. > Hunk #3 succeeded at 380. > Hunk #4 succeeded at 474. > Hunk #5 succeeded at 497. > Hunk #6 succeeded at 505. > Hunk #7 succeeded at 582. > Hunk #8 succeeded at 598. > Hunk #9 succeeded at 624. > Hunk #10 succeeded at 675. > Hunk #11 succeeded at 713. > Hunk #12 succeeded at 797. > Hunk #13 succeeded at 813. > Hunk #14 succeeded at 839. > Hunk #15 succeeded at 890. > Hunk #16 succeeded at 977. > Hunk #17 succeeded at 1286. > Hunk #18 succeeded at 1307. > Hunk #19 succeeded at 1317. > Hunk #20 succeeded at 1328. > Hunk #21 succeeded at 1410. > Hunk #22 succeeded at 1429. > Hunk #23 succeeded at 1462. > Hunk #24 succeeded at 1486. > Hunk #25 succeeded at 1511. > Hunk #26 succeeded at 1533. > Hunk #27 succeeded at 1545. > Hunk #28 succeeded at 1573. > Hunk #29 succeeded at 1611. > Hunk #30 succeeded at 1712. > Hunk #31 succeeded at 1736. > Hunk #32 succeeded at 1844. > Hunk #33 succeeded at 1851. > Hunk #34 succeeded at 1925. > Hunk #35 succeeded at 1965. > Hunk #36 succeeded at 1974. > Hunk #37 succeeded at 2047. > Hunk #38 succeeded at 2056. > Hunk #39 succeeded at 2118. > Hunk #40 succeeded at 2234. > Hunk #41 succeeded at 2431. > Hunk #42 succeeded at 2459. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/softdep.h > |=================================================================== > |--- sys/ufs/ffs/softdep.h (revision 201766) > |+++ sys/ufs/ffs/softdep.h (working copy) > -------------------------- > Patching file sys/ufs/ffs/softdep.h using Plan A... > Hunk #1 succeeded at 98. > Hunk #2 succeeded at 137. > Hunk #3 succeeded at 178. > Hunk #4 succeeded at 213. > Hunk #5 succeeded at 274. > Hunk #6 succeeded at 298. > Hunk #7 succeeded at 309. > Hunk #8 succeeded at 374. > Hunk #9 succeeded at 407. > Hunk #10 succeeded at 431. > Hunk #11 succeeded at 473. > Hunk #12 succeeded at 537. > Hunk #13 succeeded at 570. > Hunk #14 succeeded at 586. > Hunk #15 succeeded at 613. > Hunk #16 succeeded at 631. > Hunk #17 succeeded at 665. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_subr.c > |=================================================================== > |--- sys/ufs/ffs/ffs_subr.c (revision 201766) > |+++ sys/ufs/ffs/ffs_subr.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_subr.c using Plan A... > Hunk #1 succeeded at 37. > Hunk #2 succeeded at 222. > Hunk #3 succeeded at 282. > Hunk #4 succeeded at 314. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_balloc.c > |=================================================================== > |--- sys/ufs/ffs/ffs_balloc.c (revision 201766) > |+++ sys/ufs/ffs/ffs_balloc.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_balloc.c using Plan A... > Hunk #1 succeeded at 120. > Hunk #2 succeeded at 140. > Hunk #3 succeeded at 192. > Hunk #4 succeeded at 212. > Hunk #5 succeeded at 257. > Hunk #6 succeeded at 307. > Hunk #7 succeeded at 363. > Hunk #8 succeeded at 420. > Hunk #9 succeeded at 477. > Hunk #10 succeeded at 519. > Hunk #11 succeeded at 650. > Hunk #12 succeeded at 703. > Hunk #13 succeeded at 723. > Hunk #14 succeeded at 768. > Hunk #15 succeeded at 818. > Hunk #16 succeeded at 874. > Hunk #17 succeeded at 937. > Hunk #18 succeeded at 994. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_inode.c > |=================================================================== > |--- sys/ufs/ffs/ffs_inode.c (revision 201766) > |+++ sys/ufs/ffs/ffs_inode.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_inode.c using Plan A... > Hunk #1 succeeded at 232. > Hunk #2 succeeded at 336. > Hunk #3 succeeded at 447. > Hunk #4 succeeded at 466. > Hunk #5 succeeded at 499. > Hunk #6 succeeded at 641. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/fs.h > |=================================================================== > |--- sys/ufs/ffs/fs.h (revision 201766) > |+++ sys/ufs/ffs/fs.h (working copy) > -------------------------- > Patching file sys/ufs/ffs/fs.h using Plan A... > Hunk #1 succeeded at 337. > Hunk #2 succeeded at 414. > Hunk #3 succeeded at 604. > Hunk #4 succeeded at 640. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/ufs/ffs/ffs_snapshot.c > |=================================================================== > |--- sys/ufs/ffs/ffs_snapshot.c (revision 201766) > |+++ sys/ufs/ffs/ffs_snapshot.c (working copy) > -------------------------- > Patching file sys/ufs/ffs/ffs_snapshot.c using Plan A... > Hunk #1 succeeded at 582. > Hunk #2 succeeded at 599. > Hunk #3 succeeded at 701. > Hunk #4 succeeded at 1221. > Hunk #5 succeeded at 1501. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/kern/vfs_bio.c > |=================================================================== > |--- sys/kern/vfs_bio.c (revision 201766) > |+++ sys/kern/vfs_bio.c (working copy) > -------------------------- > Patching file sys/kern/vfs_bio.c using Plan A... > Hunk #1 succeeded at 216. > Hunk #2 succeeded at 475. > Hunk #3 succeeded at 2136. > Hunk #4 succeeded at 2154. > Hunk #5 succeeded at 2170. > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |Index: sys/sys/buf.h > |=================================================================== > |--- sys/sys/buf.h (revision 201766) > |+++ sys/sys/buf.h (working copy) > -------------------------- > Patching file sys/sys/buf.h using Plan A... > Hunk #1 succeeded at 493. > done > evo# > evo# make buildworld > -------------------------------------------------------------- >>>> World build started on Sun Jan 10 16:22:14 EET 2010 > -------------------------------------------------------------- > > == > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 00:43:12 2010 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 7910D106566B for ; Mon, 11 Jan 2010 00:43:12 +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 48D128FC14 for ; Mon, 11 Jan 2010 00:43:12 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 49180CB2A0 for ; Sun, 10 Jan 2010 19:43:10 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 10 Jan 2010 19:43:10 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=cqG1Jsa2JzaL+lvBiKTQtQ18Whc=; b=Ex5gGjOnoGb13i54g6hhBPaOcLTTPOtqI4BCgdngTDyukc/ewjCmtAhYq5Cv4lG96VAbrI7tqnXri01R2VqiCZuNYf36awoVB2853O0HFl18zKmkiorSSdjEtACLdNNlw4B6RXSnD5qJ8Kx1tA5PI5EapYbzc1B2MCPs7n0X8TY= X-Sasl-enc: AetTWij86X0QZGxsqbcYIx1Kmb9RTUGI+xCzXfVn80fI 1263170588 Received: from [192.168.123.18] (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7C64F4AC4EE for ; Sun, 10 Jan 2010 19:43:08 -0500 (EST) Message-ID: <4B4A741B.6050804@incunabulum.net> Date: Mon, 11 Jan 2010 00:43:07 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> In-Reply-To: <201001101437.37269.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 00:43:12 -0000 I don't have any USB webcams at the moment, but you might want to try these drivers with Spook, a lightweight RTP/RTSP streamer originally for Linux: http://www.freshports.org/multimedia/spook/ Spook can use the V4L 1.x mmap() interface. I tried it with a one of Luigi's ported drivers; it was not always stable, but it was able to stream. It may be a good 'soak test' for the drivers. As far as I know, the V4L2 API isn't in a BSD compatible form yet. This seems to be needed to be able to deal with capture devices which can read compressed frames from the device directly. cheers, Bruce From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 00:56:54 2010 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 EE32B106568F for ; Mon, 11 Jan 2010 00:56:54 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51804.mail.re2.yahoo.com (web51804.mail.re2.yahoo.com [206.190.38.235]) by mx1.freebsd.org (Postfix) with SMTP id 9511D8FC18 for ; Mon, 11 Jan 2010 00:56:54 +0000 (UTC) Received: (qmail 69353 invoked by uid 60001); 11 Jan 2010 00:56:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1263171412; bh=1dM3iDpZvPFE1poC81Vl1yCsa4be35FadBd4xxAtBas=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AsMv8zPx79eW9QTLFeB9v4KNhBtW07bGJb0Jtzr7/2XC0dtbe7eLwS8NT2n787z/23UAjJ68dYm/q1bmVdzuZL1YoFJH5gf92jQwEVT0cfp3LpsnRw9qXTdsDCMIAIx7645C8cLwsUcjTn524TzL3XGLJc59EqOgzkouKhGIq4o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=22jkfEgmQAmaAi5urJg9AjCAsPwAN+7un8ELTr6kqWKg7p3obnC/lRq1o6yaEjFW/ILLOmqsSOO/0vjJDlTzRYnz4sR7mp6znP4ETQVMqm2FBAQb5+9rhd0AY+ndUbVfUd3iNDDBE6U9VEdPP97vcNy1BIBv7FpKz7EWv+/fhAA=; Message-ID: <275073.69087.qm@web51804.mail.re2.yahoo.com> X-YMail-OSG: dytMxRcVM1lK4TFwOBv52bgTtRf3aBGxj_Z49wgdVSwBpkDA0YwvrEF_y.qCl0zKXkmq1gD86slzdH0UDa22z057W5_h11WF_6RbkSAWLU1cNSztsg5qWgWsh8yjxqjMXqZK4j8qnw2D7cwi8MvSy_rh_zwsKuCFeazyaiLjv9uxX0Q5WV0QESTgrqJzvEcNW_HZZTGUjxQS0bFqraK_5DD964sHzHDAR_lB_kpqJcgcNLJvboncHb4lZQTYl5HpzuQTUqYKwu8wR7z8KstvTEQsWcA5JBVuxNsPymRh1IihHai7tQndKgqFKolg.fpOI8TvCVJdDRKaKdrh5kfe6BzcM_JvvWj.eAUmkK3bq.Hq4ITqwRxV1oBwURz8F2p12OtoPxUJeqVdurwj.2RrYJAhG1y.PF9wkIf1l1J8j_V7zdI- Received: from [75.158.17.63] by web51804.mail.re2.yahoo.com via HTTP; Sun, 10 Jan 2010 16:56:52 PST X-Mailer: YahooMailRC/240.3 YahooMailWebService/0.8.100.260964 References: <201001101252.24922.hselasky@c2i.net> Date: Sun, 10 Jan 2010 16:56:52 -0800 (PST) From: PseudoCylon To: Hans Petter Selasky , freebsd-current@freebsd.org, freebsd-usb@freebsd.org In-Reply-To: <201001101252.24922.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Calling for testers if_run rt3572 support 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, 11 Jan 2010 00:56:55 -0000 ----- Original Message ---- > From: Hans Petter Selasky > To: freebsd-current@freebsd.org; freebsd-usb@freebsd.org > Cc: PseudoCylon > Sent: Sun, January 10, 2010 4:52:24 AM > Subject: Re: Calling for testers if_run rt3572 support > > On Sunday 10 January 2010 01:04:34 PseudoCylon wrote: > > Akinori > > Hi, > > Can you test and verify the following changes to your if_run driver? > > http://p4web.freebsd.org/chv.cgi?CH=172914 > > http://perforce.freebsd.org/chv.cgi?CH=172914 > > And provide patches if something was broken. > I have just loaded the driver, and unfortunately something is broken (the device stops responding). I'll send you patches as soon as I find out what's wrong. > Please try to resolve the remaining XXX marks. > I will. And I can maintain my driver. Looking after one driver shouldn't (hope won't) be too hard. > --HPS Thank you for adding my driver to P4. Akinori __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 06:14:58 2010 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 922DB1065694; Mon, 11 Jan 2010 06:14:58 +0000 (UTC) (envelope-from hyama99@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id F28858FC16; Mon, 11 Jan 2010 06:14:57 +0000 (UTC) Received: by fxm10 with SMTP id 10so7449328fxm.14 for ; Sun, 10 Jan 2010 22:14:51 -0800 (PST) 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=sO9GrNvR1Ym2X8gS9rGashq0KNVmmUjFeK3S6fr9rUI=; b=F85aqlZ4SdPp9ZkrEYS753WvjFvH+6OSvvIwTlDTsY6Cba+w6seenbgspkwJIZJDxy 6/s9QGZHpKkB/ZVf7TL0R85MdR83zjNzgJALc6ivch2f/EhlqNTnpxxgTjbtbB+o64SH BsdghLxrFPbIOJiomUUNs8dPAbHvcg8bXMicw= 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=eDSxNtoOA67q/0b6a+MK2dnuSIv2duzI9IIfTxECLwpN1RQIYL6wj79QVH0csrgQnG EOdRzKLYGy8WA/DtyHHwtp3GO2Xf+OxKGf02Vv855bzljzLFEZ5ZL4srYTczoD2nlGJR E7nCOkK8UGk0JIv8D/4MfU6+Rf0TziJtwbDUo= MIME-Version: 1.0 Received: by 10.239.130.30 with SMTP id 30mr850394hbh.130.1263189146544; Sun, 10 Jan 2010 21:52:26 -0800 (PST) In-Reply-To: <4B489753.6090904@FreeBSD.org> References: <4B4225D9.9050504@FreeBSD.org> <4B440D6E.1070809@freebsd.org> <4B487661.2050505@FreeBSD.org> <4B489753.6090904@FreeBSD.org> Date: Mon, 11 Jan 2010 14:52:26 +0900 Message-ID: <90dbee151001102152n23a37c09qda0d96eb12db6893@mail.gmail.com> From: Hideki Yamamoto To: Beat Gaetzi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@freebsd.org, current@freebsd.org Subject: Re: Call for tester: VirtualBox 3.1.2 for FreeBSD (take 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, 11 Jan 2010 06:14:58 -0000 Hi! Thank you for your work. While testing virtualbox-port-r621.tar.gz, I have found several problems. I think all of them are not new problems. I will be very happy if you resolve these problems. 1. Japanese keyboard problem: 1.1 Problem - Under score key does not work in guest FreeBSD-9-Current - No character is input when typing under score key on JP.106 type keyboard. 1.2 Environment - I am using jp.106 layout keyboard. I set keymap=3D"jp.106x" in /etc/rc.conf. On console, Under score key is effective. - Using gnome 2.28 on FreeBSD 9-current. in order to type under score "_", I set a Xmodmap setting in /root/.xinitrc xmodmap -e "keycode 151 =3D backslash underscore kana_RO" This line works well. On gnome-terminal, I can input under score well= . - About virtualbox, host is FreeBSD-9 Current, and Guest is also FreeBS= D -9 Current. - /etc/rc.conf in Guest has the same keymap configuration: kyemap=3D"jp.106x" 1.3 Related information - When searching resemble problems by Google, I have found a Japanese tips to input under score in guest OS on VMware on CentOS 5.2. It sa= ys (1) This problem comes from Host OS, not from Guest OS. (2) On Cent OS(Host OS), you should set the following line in ~/.vmware/preference xkeymap.keycode.211=3D0x073 1.4 Comments on this problem - I wonder if there is information like 1.3 on vmware or not. 2. Setting two CPU problem 2.1 Problem - Hw is Intel Core2 Duo E7200. But on virtualbox configuration menu, I cannot select two CPU. Menu bar cannot move from "1CPU". 2.2 Environment - Guest and Host is also FreeBSD 9-Current. - While compiling something on guest OS, when "system monitor" on gnome is running, we can see two CPU is working well for guest OS application. - Is the problem in 2.1 GUI problem? Best regards, Hideki Yamamoto 2010/1/9 Beat Gaetzi : > Beat Gaetzi wrote: >> Daichi GOTO wrote: >>> Discussion and Issues: >>> =A0 =A0 I cannot get host-guest clipboard share working. Does someone >>> =A0 =A0get it? >> >> No, the clipboard sharing is not working at the moment. > > I just recognized that this is not correct. Clipboard sharing works if > you start "VBoxClient --clipboard" in the guest and copy something with > "Ctrl + C" in the host or the guest. > > Beat > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to "freebsd-emulation-unsubscribe@freebsd.o= rg" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 07:04:18 2010 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 1327F106568D for ; Mon, 11 Jan 2010 07:04:18 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC84B8FC12 for ; Mon, 11 Jan 2010 07:04:17 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.237.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DEC7122E1EB; Mon, 11 Jan 2010 02:04:10 -0500 (EST) Message-ID: <4B4ACD68.5030907@gmail.com> Date: Sun, 10 Jan 2010 23:04:08 -0800 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> In-Reply-To: <20100109013145.GG18529@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem 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, 11 Jan 2010 07:04:18 -0000 Pyun YongHyeon wrote: > On Fri, Jan 08, 2010 at 02:43:02PM -0800, David Ehrmann wrote: > >> It seems to be working, but I'm going to keep testing it before I >> >> proclaim it fixed. Will these changes be in 8.1? >> I spoke too soon. Now an nfs client is having problems. I ran iperf and saw what looks like a decent rx connection, but a tx connection where up to 2% of UDP packets are dropped (see http://pastebin.com/m1c067417 ). If both sides are gigabit connections, I see more like 13%. If I flip client and server sides, the results still show issues with vge tx. I ran iperf like this: iperf -s -u -r and iperf -c 10.0.x.x -u -r. Other machines have problems with the vge interface, but drop no more than a packet between themselves. This doesn't happen with my vr interface. I gave it an IP in a 192.168.x.x subnet and repeated the test. Most of the time, zero packets were dropped. When packets were dropped, it was fewer than 2%. Are there any known bugs that cause UDP tx packet drops on vge? From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 12:58:27 2010 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 A6A981065698; Mon, 11 Jan 2010 12:58:27 +0000 (UTC) (envelope-from avl@logvinov.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 787DD8FC32; Mon, 11 Jan 2010 12:58:27 +0000 (UTC) Received: by pzk40 with SMTP id 40so428244pzk.7 for ; Mon, 11 Jan 2010 04:58:22 -0800 (PST) Received: by 10.143.20.39 with SMTP id x39mr2563200wfi.213.1263213258439; Mon, 11 Jan 2010 04:34:18 -0800 (PST) Received: from incubus.bsd ([124.64.17.196]) by mx.google.com with ESMTPS id 23sm249018pzk.0.2010.01.11.04.34.14 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 04:34:17 -0800 (PST) Message-ID: <4B4B1AEE.6030303@logvinov.com> Date: Mon, 11 Jan 2010 20:34:54 +0800 From: Alexander Logvinov User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.5) Gecko/20091224 Thunderbird/3.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <201001101437.37269.hselasky@c2i.net> In-Reply-To: <201001101437.37269.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 12:58:27 -0000 Hello! On 10.01.2010 21:37 Hans Petter Selasky wrote: > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > Feedback and bug reports are welcome. As you know I get a black window when I test my webcam under skype. Here is skype output after pressing "Test" button: $ skype Starting the process... Skype Xv: Xv ports available: 32 Skype XShm: XShm support enabled Skype Xv: Using Xv port 304 $ xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: "NV17 Video Texture" number of ports: 32 port base: 304 operations supported: PutImage supported visuals: depth 24, visualID 0x21 depth 24, visualID 0x24 depth 24, visualID 0x25 depth 24, visualID 0x26 depth 24, visualID 0x27 depth 24, visualID 0x28 depth 24, visualID 0x29 depth 24, visualID 0x2a depth 24, visualID 0x2b depth 24, visualID 0x2c depth 24, visualID 0x2d depth 24, visualID 0x2e depth 24, visualID 0x2f depth 24, visualID 0x30 depth 24, visualID 0x31 depth 24, visualID 0x32 depth 24, visualID 0x33 depth 24, visualID 0x34 depth 24, visualID 0x35 depth 24, visualID 0x36 depth 24, visualID 0x37 depth 24, visualID 0x38 depth 24, visualID 0x39 depth 24, visualID 0x3a depth 24, visualID 0x3b depth 24, visualID 0x3c depth 24, visualID 0x3d depth 24, visualID 0x3e depth 24, visualID 0x22 depth 24, visualID 0x3f depth 24, visualID 0x40 depth 24, visualID 0x41 depth 24, visualID 0x42 depth 24, visualID 0x43 depth 24, visualID 0x44 depth 24, visualID 0x45 depth 24, visualID 0x46 depth 24, visualID 0x47 depth 24, visualID 0x48 depth 24, visualID 0x49 depth 24, visualID 0x4a depth 24, visualID 0x4b depth 24, visualID 0x4c depth 24, visualID 0x4d depth 24, visualID 0x4e depth 24, visualID 0x4f depth 24, visualID 0x50 depth 24, visualID 0x51 depth 24, visualID 0x52 depth 24, visualID 0x53 depth 24, visualID 0x54 depth 24, visualID 0x55 depth 24, visualID 0x56 depth 24, visualID 0x57 depth 24, visualID 0x58 depth 24, visualID 0x59 number of attributes: 7 "XV_SET_DEFAULTS" (range 0 to 0) client settable attribute "XV_ITURBT_709" (range 0 to 1) client settable attribute client gettable attribute (current value is 0) "XV_SYNC_TO_VBLANK" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2046 x 2046 Number of image formats: 4 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) -- Best regards, Alexander From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 14:10:08 2010 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 7ABCD10656A6; Mon, 11 Jan 2010 14:10:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id A37CA8FC2B; Mon, 11 Jan 2010 14:10:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=X-lO3BfsBrjuG197QLgA:9 a=USP0va0vB4EJfRrJIlYA:7 a=Y4VqhwGM0vQ0CsMkNqlX3hJJ4kwA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1375551729; Mon, 11 Jan 2010 15:10:05 +0100 To: freebsd-current@freebsd.org From: Hans Petter Selasky X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'( =?iso-8859-1?q?=3B=5FIjlA=3A=0A=09hGE=2E=2EEw?=, =?iso-8859-1?q?XAQ*o=23=5C/M=7ESC=3DS1-f9=7BEzRfT=27=7CHhll5Q=5Dha5Bt-s=7Co?= =?iso-8859-1?q?TlKMusi=3A1e=5BwJl=7Dkd=7DGR=0A=09Z0adGx-x=5F0zGbZj=27e?=(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' Date: Mon, 11 Jan 2010 15:08:43 +0100 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001111508.43054.hselasky@c2i.net> Cc: Brandon Gooch , freebsd-multimedia@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 14:10:08 -0000 On Sunday 10 January 2010 18:40:17 Brandon Gooch wrote: > > Seems to work for just a second or two (I see my ugly mug on-screen), > and then this: > > # ./pwcview/pwcview > Webcam set to: 320x240 (sif) at 5 fps > libv4lconvert: Error decompressing JPEG: fill_nbits error: need 8 more bits > libv4l2: error converting / decoding frame data: v4l-convert: error > parsing JPEG header: Not a JPG file ? Hi again, The JPEG library fix is here: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137265 Try to "svn up" and build fresh sources. I've found and fixed some bugs. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 16:23:20 2010 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 71DE4106566C; Mon, 11 Jan 2010 16:23:20 +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 4149F8FC21; Mon, 11 Jan 2010 16:23:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E839D46B49; Mon, 11 Jan 2010 11:23:19 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 32A028A01D; Mon, 11 Jan 2010 11:23:19 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Jan 2010 10:42:19 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091223035331.GA1293@weongyo> <20100110061631.GT1491@weongyo> <426bed111001100130u61bbeb03s242dd012abc76a5@mail.gmail.com> In-Reply-To: <426bed111001100130u61bbeb03s242dd012abc76a5@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001111042.19334.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 11 Jan 2010 11:23:19 -0500 (EST) 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 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Weongyo Jeong , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver 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, 11 Jan 2010 16:23:20 -0000 On Sunday 10 January 2010 4:30:13 am Rohit Grover wrote: > Hi Weongyo, > > On Sun, Jan 10, 2010 at 7:16 PM, Weongyo Jeong wrote: > > On Sun, Jan 10, 2010 at 06:41:21PM +1300, Rohit Grover wrote: > >> Hi, > >> > >> > Please try attached patch in bwn_probe() and show me dmesg output. ?If > >> > bwn(4) doesn't print anything that means ssb(4) works incorrectly. ?But > >> > there are some outputs and bwn(4) doesn't be attached then your device > >> > revision isn't supported. > >> > > >> > >> > >> After applying your patch, I get the following upon loading if_bwn: > >> > >> bwn0: vendor 0x4243 cid 0x812 rev 12 > >> > >> Therefore, I should infer that the device revision isn't supported? > > > > Yes it looks your revision isn't supported. > > > >> Do you know when this device might be supported? > > > > I think it could be supported when bwn(4) supports N PHYs I hope. > > Not being able to use the wireless hardware on my current laptop with > FreeBSD has caused me inconvenience to the point where I am seriously > contemplating the purchase of a new laptop. > Is there even a remote possibility that you may be able to estimate > when bwn(4) may be able to support such hardware? You might try ndis(4). I am using it for my Broadcom wireless card with an N- phy until bwn(4) supports my part natively. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 16:23:20 2010 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 71DE4106566C; Mon, 11 Jan 2010 16:23:20 +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 4149F8FC21; Mon, 11 Jan 2010 16:23:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E839D46B49; Mon, 11 Jan 2010 11:23:19 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 32A028A01D; Mon, 11 Jan 2010 11:23:19 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Jan 2010 10:42:19 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <20091223035331.GA1293@weongyo> <20100110061631.GT1491@weongyo> <426bed111001100130u61bbeb03s242dd012abc76a5@mail.gmail.com> In-Reply-To: <426bed111001100130u61bbeb03s242dd012abc76a5@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001111042.19334.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 11 Jan 2010 11:23:19 -0500 (EST) 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 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Weongyo Jeong , current@freebsd.org Subject: Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver 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, 11 Jan 2010 16:23:20 -0000 On Sunday 10 January 2010 4:30:13 am Rohit Grover wrote: > Hi Weongyo, > > On Sun, Jan 10, 2010 at 7:16 PM, Weongyo Jeong wrote: > > On Sun, Jan 10, 2010 at 06:41:21PM +1300, Rohit Grover wrote: > >> Hi, > >> > >> > Please try attached patch in bwn_probe() and show me dmesg output. ?If > >> > bwn(4) doesn't print anything that means ssb(4) works incorrectly. ?But > >> > there are some outputs and bwn(4) doesn't be attached then your device > >> > revision isn't supported. > >> > > >> > >> > >> After applying your patch, I get the following upon loading if_bwn: > >> > >> bwn0: vendor 0x4243 cid 0x812 rev 12 > >> > >> Therefore, I should infer that the device revision isn't supported? > > > > Yes it looks your revision isn't supported. > > > >> Do you know when this device might be supported? > > > > I think it could be supported when bwn(4) supports N PHYs I hope. > > Not being able to use the wireless hardware on my current laptop with > FreeBSD has caused me inconvenience to the point where I am seriously > contemplating the purchase of a new laptop. > Is there even a remote possibility that you may be able to estimate > when bwn(4) may be able to support such hardware? You might try ndis(4). I am using it for my Broadcom wireless card with an N- phy until bwn(4) supports my part natively. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 17:59:56 2010 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 2FC5C106566C for ; Mon, 11 Jan 2010 17:59:56 +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 AEA648FC2A for ; Mon, 11 Jan 2010 17:59:55 +0000 (UTC) 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 "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id BE2B592DE; Mon, 11 Jan 2010 18:59:54 +0100 (CET) Received: from meribel.restart.bel (meribel.restart.bel [IPv6:2001:41d0:2:2d29:1:8::]) (authenticated bits=0) by restart.be (8.14.4/8.14.4) with ESMTP id o0BHxmDX023315 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 18:59:49 +0100 (CET) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be o0BHxmDX023315 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1263232794; bh=b3ZGYjEA7r/cLE9Q8wrhTgHoqckcH51FMI28QRsLQs0=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xRqtHjQ3zfXyPHYLlxKBG+yaZF5jaCRu8QHRhWLdo8aszRxiy0Te89NGXWWdz/ht7 hD2MoUj3JJQyj+0WbkO/Q== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be o0BHxmDX023315 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=mw5NHlqz7/a8vbQJvWc1fdIKz/9pL1sjby8Y2Pt+1uXhhhYGPpZ9xiDatDa4pVzFH Ya3nCWtafFBUoEGGsKyKw== Message-ID: <4B4B7523.6060409@restart.be> Date: Mon, 11 Jan 2010 19:59:47 +0100 From: Henri Hennebert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20091220 Thunderbird/3.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> In-Reply-To: <201001101437.37269.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 17:59:56 -0000 On 01/10/2010 14:37, Hans Petter Selasky wrote: > Hi, > > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which links > with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which > is provided by the video4bsd kernel module. There is full support for > mmap/read/write/open/close. poll is not supported. > > Basic operation and idea: > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the > interface for the V4L application. The video4bsd transports all data between > these two devices. In the case the V4L application is using mmap, no data is > copied due to shared kernel memory buffer! > > Licensing issues: > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB > drivers which are GPL licensed. Some files inside the webcamd remains BSD > licensed which allows for building similar BSD licensed daemons. > > The rest of the code is BSD licensed. > > Source code: > > 1) FreeBSD 8-stable > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > http://p4web.freebsd.org/chv.cgi?CH=172876 > > http://perforce.freebsd.org/chv.cgi?CH=172876 > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be checked > out in the same folder due to dependencies) > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > make all install > kldload video4bsd > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > make fetch > make patch > make all > make install > > # this will attach to the first detected webcam: > ./webcamd > > # this will try to attach to the given USB unit, interface and V4B unit. > ./webcamd -d ugen4.1 -i 0 -v 0 > > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > > Feedback and bug reports are welcome. > I try on a Fujitsu M2010: FreeBSD meribel.restart.bel 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0 r201748M: Thu Jan 7 16:23:56 CET 2010 root@meribel.restart.bel:/usr/obj/usr/src/sys/MERIBEL i386 [root@meribel ~]# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON [root@meribel ~]# /home/meribel/webcam/ulinux/webcamd -d ugen3.2 -i 0 -v 0 KrefGet: 0x34028404 = 1 KrefGet: 0x34028404 = 2 KrefGet: 0x3402860c = 1 KrefGet: 0x340286c8 = 1 Added device 0x33f18b04 KrefGet: 0x33f18b08 = 1 KrefGet: 0x33f18b08 = 2 [root@meribel ~]# chmod 666 /dev/video* /dev/usb/* [hlh@meribel ~]$ pwcview Webcam set to: 320x240 (sif) at 5 fps Give me a green window for some time and then this picture: http://verbier.restart.be/xfer/Screenshot-pwcview.png which stay still. I can't kill pwcview window. Thank you for your work! Henri From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 20:36:50 2010 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 01B8E1065672 for ; Mon, 11 Jan 2010 20:36:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f209.google.com (mail-gx0-f209.google.com [209.85.217.209]) by mx1.freebsd.org (Postfix) with ESMTP id AA9EE8FC0A for ; Mon, 11 Jan 2010 20:36:49 +0000 (UTC) Received: by gxk1 with SMTP id 1so9715475gxk.14 for ; Mon, 11 Jan 2010 12:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=7INYYC9/8VP5BZNftOmnOdLiCYrqxBmcvQT5Ib3PMu0=; b=WESLXl1hzlyIyussHbR41kqEEAwTIFO4WMhTCAXGI7HKWNvKaBXZ9fCxfgioxDswCE 9RSEGdaDTYuydKw/YOipgEI3CiTNCCkFdsVkZLkvmqPczbEz1gnMtDZsAcMa1uVtwcxh WxE7Bh0PUyZC0AcPWcbJnoMsn9+2BLM4v2BDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qMmJtsgMlW430dZzXpfhDC/QAY5j7a620TeNchWf9jFbfrDH3/YqexjB3BzaMrOAcr 8eMSfPVEur7tIzrRjFRs2OJ7i7KjLI5g41LwU8S9+0bvs9IdNyn7xGJXS0Xhz5DvlYXn hchn8BP2UvRJV/M7tjmXoy1kmD1fvzsuqXxWk= Received: by 10.150.105.3 with SMTP id d3mr10573474ybc.293.1263242203906; Mon, 11 Jan 2010 12:36:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm9060239ywh.31.2010.01.11.12.36.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 12:36:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 12:35:57 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 12:35:57 -0800 To: David Ehrmann Message-ID: <20100111203557.GB1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4ACD68.5030907@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 20:36:50 -0000 On Sun, Jan 10, 2010 at 11:04:08PM -0800, David Ehrmann wrote: > Pyun YongHyeon wrote: > >On Fri, Jan 08, 2010 at 02:43:02PM -0800, David Ehrmann wrote: > > > >>It seems to be working, but I'm going to keep testing it before I > >> > >>proclaim it fixed. Will these changes be in 8.1? > >> > I spoke too soon. Now an nfs client is having problems. I ran iperf > and saw what looks like a decent rx connection, but a tx connection > where up to 2% of UDP packets are dropped (see > http://pastebin.com/m1c067417 ). If both sides are gigabit connections, > I see more like 13%. If I flip client and server sides, the results > still show issues with vge tx. > Does netstat(1) also agree on the statistics? Another thing you may want to see is hardware MAC statistics. See the output of `sysctl dev.vge.0.stats` and check how many dropped counters are changed. > I ran iperf like this: iperf -s -u -r and iperf -c 10.0.x.x -u -r. > Other machines have problems with the vge interface, but drop no more > than a packet between themselves. > > This doesn't happen with my vr interface. I gave it an IP in a > 192.168.x.x subnet and repeated the test. Most of the time, zero > packets were dropped. When packets were dropped, it was fewer than 2%. > If receiver drops TX UDP frame sent by vge(4) would you try disabling TX checksum offloading of vge(4)? If packet drop happens only with UDP frames it could be checksum offload bug. Does your controller is VT6130(PCIe)? > Are there any known bugs that cause UDP tx packet drops on vge? No, I'm not aware of this. If you can narrow down which packets were dropped and can capture packets with tcpdump that would be great help to analyze the issue. From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 21:16:46 2010 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 9ED871065670; Mon, 11 Jan 2010 21:16:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id CF2598FC13; Mon, 11 Jan 2010 21:16:45 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=RYQgPGQ7BbsA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=kRccK-SBt_Mvd50vztIA:9 a=JDughqzA_pw9HdAhRCrh0vOk1ioA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1327425081; Mon, 11 Jan 2010 22:16:43 +0100 From: Hans Petter Selasky To: vova@fbsd.ru Date: Mon, 11 Jan 2010 22:15:22 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <1263244252.3558.29.camel@localhost> In-Reply-To: <1263244252.3558.29.camel@localhost> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201001112215.22702.hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 21:16:46 -0000 On Monday 11 January 2010 22:10:52 Vladimir Grebenschikov wrote: > Side question, is it possible to use audio microphone of USB camera ? > Yes, if you kldload snd_uaudio. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 21:42:42 2010 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 C80A01065670; Mon, 11 Jan 2010 21:42:42 +0000 (UTC) (envelope-from vova@parallels.com) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 38C688FC1D; Mon, 11 Jan 2010 21:42:41 +0000 (UTC) Received: from vbook.fbsd.ru ([77.232.23.6]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id o0BLArHx012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 00:10:54 +0300 (MSK) Received: from vova by vbook.fbsd.ru with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NURXI-0001JN-I5; Tue, 12 Jan 2010 00:10:52 +0300 From: Vladimir Grebenschikov To: Hans Petter Selasky In-Reply-To: <201001101437.37269.hselasky@c2i.net> References: <201001101437.37269.hselasky@c2i.net> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jan 2010 00:10:52 +0300 Message-ID: <1263244252.3558.29.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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: Mon, 11 Jan 2010 21:42:43 -0000 Hi=20 Thanks you for efforts! I've tested it with=20 ugen4.2: at usbus4, cfg=3D0 md=3DHOST spd=3DH= IGH (480Mbps) pwr=3DON on 9-CURRENT pwcview works fine: $ ./pwcview/pwcview Webcam set to: 320x240 (sif) at 5 fps skype detects video device, but shows only black window instead of picture. build webcamd.c with debug shows: $ ./webcamd Probing for 0.0.0 KrefGet: 0x483e2304 =3D 1 KrefGet: 0x483e2304 =3D 2 KrefGet: 0x483e2554 =3D 1 KrefGet: 0x483e2610 =3D 1 Added device 0x48318b04 KrefGet: 0x48318b08 =3D 1 Received command 1 0x00000000 KrefGet: 0x48318b08 =3D 2 Status =3D 0 Received command 5 0x40047601 Status =3D -22 Received command 5 0x403c7601 Status =3D 0 Received command 5 0x400e7606 Status =3D 0 Received command 5 0x800e7607 Status =3D -22 Received command 5 0x800e7607 Status =3D 0 Received command 5 0x40207609 Status =3D 0 Received command 5 0x8020760a Status =3D 0 ... and then in loop: Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 Status =3D -22 Received command 3 0x00025800 ... Side question, is it possible to use audio microphone of USB camera ? -----Original Message----- From: Hans Petter Selasky To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing Date: Sun, 10 Jan 2010 14:37:37 +0100 Hi, During the last couple of days I've spent some time to finish my webcam=20 daemon. My webcam daemon is basically an application which consists of=20 userspace Video4Linux USB webcam drivers and some uLinux glue code which li= nks=20 with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX whi= ch=20 is provided by the video4bsd kernel module. There is full support for=20 mmap/read/write/open/close. poll is not supported. Basic operation and idea: /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the=20 interface for the V4L application. The video4bsd transports all data betwee= n=20 these two devices. In the case the V4L application is using mmap, no data i= s=20 copied due to shared kernel memory buffer! Licensing issues: Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB=20 drivers which are GPL licensed. Some files inside the webcamd remains BSD=20 licensed which allows for building similar BSD licensed daemons. The rest of the code is BSD licensed. Source code: 1) FreeBSD 8-stable 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: http://p4web.freebsd.org/chv.cgi?CH=3D172876 http://perforce.freebsd.org/chv.cgi?CH=3D172876 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be check= ed=20 out in the same folder due to dependencies) svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd make all install kldload video4bsd svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux make fetch make patch make all make install # this will attach to the first detected webcam: ./webcamd # this will try to attach to the given USB unit, interface and V4B unit. ./webcamd -d ugen4.1 -i 0 -v 0 # this will display webcam contents from /dev/video0 by default. ./pwcview/pwcview Feedback and bug reports are welcome. Yes, I am working on getting this into ports! Known issues: 1) If you detach the USB webcam you need to manually restart the webcamd. --HPS Support: I will be available at #bsdusb on efnet during the day. _______________________________________________ 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 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 23:03:41 2010 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 9FFAF106568B for ; Mon, 11 Jan 2010 23:03:41 +0000 (UTC) (envelope-from kinphi@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 623EA8FC18 for ; Mon, 11 Jan 2010 23:03:41 +0000 (UTC) Received: by yxe1 with SMTP id 1so20345753yxe.3 for ; Mon, 11 Jan 2010 15:03:34 -0800 (PST) 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=qyfzWumv9leZsnzE8Sn2wWkm3MANE4vyd6m97CTmPoI=; b=LnVx0WuMd7d85RRQJhSvJO6VZbYpAnLEu1yPJWFyzrw0LG58rm20reTxNt7HpugtqW 5iL0MFOuZoiwsH7WiZlOpbCtfn3H3278Um6ZWHCU5Fy+XNZqz9hjgECQsjxDOB9+T/Xd U4ZPfcHovRpwU7AAar6OPbCwSQxQb0JmW3Iyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=E+XbvxMimT6wwm8O2eQNRABr6w1hbvvibDhLr4A4kqTI0U8eDcQiyYNqwgkeGQ2Q31 Y4b2HThojuXmA1KqWWd9OM9AX2uxh7xw6DBzOD4dmaoGPJBGNzEWKwu5jMdxSRWtz65R ij2xq+S0uhiZY4djEeZMDcfEj5+Y0+lXpSav8= MIME-Version: 1.0 Received: by 10.150.35.24 with SMTP id i24mr12658582ybi.348.1263249349878; Mon, 11 Jan 2010 14:35:49 -0800 (PST) Date: Mon, 11 Jan 2010 14:35:49 -0800 Message-ID: <74c4f9521001111435q4c7f6266p51430724dc566a48@mail.gmail.com> From: Phillip Kinsley To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Gcc question 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, 11 Jan 2010 23:03:41 -0000 I'm having problems with gcc4.2.1 and would like to use gcc4.4. I install gcc4.4 and binutils via ports. Now how do get gcc4.4 to be my default compiler? Thanks Phillip From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 22:30:32 2010 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 AF0271065693; Mon, 11 Jan 2010 22:30:32 +0000 (UTC) (envelope-from sklauder@trimind.de) Received: from mikako.shopkeeper.de (mikako.shopkeeper.de [82.119.175.20]) by mx1.freebsd.org (Postfix) with ESMTP id 3624C8FC14; Mon, 11 Jan 2010 22:30:31 +0000 (UTC) Received: from avalon.dobu.local (p4FF4783B.dip.t-dialin.net [79.244.120.59]) (authenticated bits=0) by mikako.shopkeeper.de (8.14.3/8.14.3) with ESMTP id o0BLqO26037388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 22:52:27 +0100 (CET) (envelope-from sklauder@trimind.de) Received: from avalon.dobu.local (localhost [127.0.0.1]) by avalon.dobu.local (8.14.3/8.14.2) with ESMTP id o0BLqO9P029432; Mon, 11 Jan 2010 22:52:24 +0100 (CET) (envelope-from sklauder@avalon.dobu.local) Received: (from sklauder@localhost) by avalon.dobu.local (8.14.3/8.14.3/Submit) id o0BLqNGK029431; Mon, 11 Jan 2010 22:52:23 +0100 (CET) (envelope-from sklauder) Date: Mon, 11 Jan 2010 22:52:23 +0100 From: Sascha Klauder To: Hans Petter Selasky Message-ID: <20100111215223.GA69823@trimind.de> References: <201001101437.37269.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001101437.37269.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at mikako.shopkeeper.de X-Virus-Status: Clean X-Mailman-Approved-At: Mon, 11 Jan 2010 23:08:12 +0000 Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 11 Jan 2010 22:30:32 -0000 On Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: > During the last couple of days I've spent some time to finish my webcam > daemon. My webcam daemon is basically an application which consists of > userspace Video4Linux USB webcam drivers and some uLinux glue code which links > with libc, pthreads and libusb. The webcamd talks to /dev/video_daemonX which > is provided by the video4bsd kernel module. There is full support for > mmap/read/write/open/close. poll is not supported. Tested and working fine so far (I've only checked the bundled pwcview application) with the builtin webcam of an Acer Aspire One 531: ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON > Feedback and bug reports are welcome. Thank you! Cheers, -sascha From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 23:15:32 2010 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 8F3E7106568F for ; Mon, 11 Jan 2010 23:15:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 596008FC13 for ; Mon, 11 Jan 2010 23:15:32 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id o0BNFdrJ018465; Mon, 11 Jan 2010 15:15:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id o0BNFdna018464; Mon, 11 Jan 2010 15:15:39 -0800 (PST) (envelope-from sgk) Date: Mon, 11 Jan 2010 15:15:39 -0800 From: Steve Kargl To: Phillip Kinsley Message-ID: <20100111231539.GA9825@troutmask.apl.washington.edu> References: <74c4f9521001111435q4c7f6266p51430724dc566a48@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74c4f9521001111435q4c7f6266p51430724dc566a48@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Gcc question 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, 11 Jan 2010 23:15:32 -0000 On Mon, Jan 11, 2010 at 02:35:49PM -0800, Phillip Kinsley wrote: > I'm having problems with gcc4.2.1 and would like to use gcc4.4. I > install gcc4.4 and binutils via ports. Now how do get gcc4.4 to be my > default compiler? > Add setenv CC /usr/local/bin/gcc44 alias cc /usr/local/bin/gcc44 to your .cshrc file. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jan 11 23:38:59 2010 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 3B876106566C for ; Mon, 11 Jan 2010 23:38:59 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 102198FC1E for ; Mon, 11 Jan 2010 23:38:58 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.237.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C486222E257; Mon, 11 Jan 2010 18:38:49 -0500 (EST) Message-ID: <4B4BB679.2060500@gmail.com> Date: Mon, 11 Jan 2010 15:38:33 -0800 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> In-Reply-To: <20100111203557.GB1228@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem 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, 11 Jan 2010 23:38:59 -0000 Pyun YongHyeon wrote: > If receiver drops TX UDP frame sent by vge(4) would you try > disabling TX checksum offloading of vge(4)? If packet drop happens > only with UDP frames it could be checksum offload bug. Does your > controller is VT6130(PCIe)? > First, netstat before and after the test: share2# netstat -I vge0 -d Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop vge0 1500 00:40:63:xx:xx:xx 38940717 0 0 55913584 0 0 0 vge0 1500 10.0.0.0/22 share2 38886994 - - 55898223 - - - share2# netstat -I vge0 -d Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop vge0 1500 00:40:63:xx:xx:xx 38942065 0 0 55914869 0 0 0 vge0 1500 10.0.0.0/22 share2 38888320 - - 55899491 - - - The error counters were uninteresting. Here's what the internal counters said, but they weren't very interesting, either: http://pastebin.com/m20114095 I ran the test, again, and had tcpdump capture the packets (on the host with the vge interface). tcpdump -i vge0 -w dump.cap -K -s 0 host 10.0.1.2 When I opened it up in Wireshark, it's reporting that the outgoing UDP checksums are incorrect; they're always 0x1ae3. That said, maybe the checksums are done in hardware AFTER tcpdump sees them. I set net.inet.udp.checksum to 0. The bad checksums are gone, but I still see dropped packets. It's on the motherboard, probably wired directly to a PCI-E connection, but yes, it is a VT6130. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 00:09:51 2010 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 C9B391065698 for ; Tue, 12 Jan 2010 00:09:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9E78FC2B for ; Tue, 12 Jan 2010 00:09:51 +0000 (UTC) Received: by qyk41 with SMTP id 41so10636628qyk.29 for ; Mon, 11 Jan 2010 16:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=s5GSae0q3qpU3TzEjyABk29AJJvCqgYHCZAQacYPSW4=; b=txnHCTMlfv1eDvraynztmRzoIZLEr7WzgbgkYBT1cSg0k72umAssTH+HV3H/v8FuHS FDIxXgjYBJ3ZHgMoRjeKl07+irnFm2yn7oHodwFCBPEANUulWdSlxgmjgfsSKGmsX4d1 OIOEmCVUoZve0GMSeZHytPRkl3x0+OzzjK7fQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=KFy8iNvwEdnXGud80gJr0g7ALwWXfeBnivTrURne1i57N9JxTCRpLoTWKwGNGqVSwX +fm1WBNPIFnV5PLBETaY8FNskq0QsNV5iWe0ms4n5SjvC07Dv4S2c8ma1yQlkZ2rjc+X I99dLOcLqg8sdN+vqAi6Zw69t60WrCa84VMFM= Received: by 10.224.108.5 with SMTP id d5mr17078648qap.294.1263254983955; Mon, 11 Jan 2010 16:09:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 26sm3066098qwa.0.2010.01.11.16.09.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 16:09:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 16:08:59 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 16:08:59 -0800 To: David Ehrmann Message-ID: <20100112000859.GD1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4BB679.2060500@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 00:09:52 -0000 On Mon, Jan 11, 2010 at 03:38:33PM -0800, David Ehrmann wrote: > Pyun YongHyeon wrote: > >If receiver drops TX UDP frame sent by vge(4) would you try > >disabling TX checksum offloading of vge(4)? If packet drop happens > >only with UDP frames it could be checksum offload bug. Does your > >controller is VT6130(PCIe)? > > > > First, netstat before and after the test: > > share2# netstat -I vge0 -d > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll Drop > vge0 1500 00:40:63:xx:xx:xx 38940717 0 0 > 55913584 0 0 0 > vge0 1500 10.0.0.0/22 share2 38886994 - - > 55898223 - - - > share2# netstat -I vge0 -d > Name Mtu Network Address Ipkts Ierrs Idrop > Opkts Oerrs Coll Drop > vge0 1500 00:40:63:xx:xx:xx 38942065 0 0 > 55914869 0 0 0 > vge0 1500 10.0.0.0/22 share2 38888320 - - > 55899491 - - - > > The error counters were uninteresting. Here's what the internal > counters said, but they weren't very interesting, either: > > http://pastebin.com/m20114095 > Ok, it indicates there are no FIFO overrun or no buf condition occurred in controller. > I ran the test, again, and had tcpdump capture the packets (on the host > with the vge interface). > > tcpdump -i vge0 -w dump.cap -K -s 0 host 10.0.1.2 > > When I opened it up in Wireshark, it's reporting that the outgoing UDP > checksums are incorrect; they're always 0x1ae3. That said, maybe the Because bpf(4) see the frame before controller inserts checksum value it always reports incorrect checksum. It's normal for TX checksum offload capable controller. In order to verify the hardware assisted checksum you should check that on receiver side. If the checksum was invalid, receiver dropped them. See "netstat -s | grep bad" on receiver host. > checksums are done in hardware AFTER tcpdump sees them. > > I set net.inet.udp.checksum to 0. The bad checksums are gone, but I > still see dropped packets. > This doesn't disable TX checksum offload of driver. Instead use #ifconfig vge0 -txcsum > It's on the motherboard, probably wired directly to a PCI-E connection, > but yes, it is a VT6130. Show me "pciconf -lcv" output. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 00:34:27 2010 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 6C1B11065676 for ; Tue, 12 Jan 2010 00:34:27 +0000 (UTC) (envelope-from jaz@goatcse.cx) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFDF8FC13 for ; Tue, 12 Jan 2010 00:34:27 +0000 (UTC) Received: by qyk41 with SMTP id 41so10647566qyk.29 for ; Mon, 11 Jan 2010 16:34:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.14.93 with SMTP id f29mr8748355qca.90.1263256464463; Mon, 11 Jan 2010 16:34:24 -0800 (PST) In-Reply-To: <60a0e8261001080746x4445d45dmbc218c49245eaeb7@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> <58c737d70907100058u263ab795g442c62d67ba2345f@mail.gmail.com> <2a41acea0907101026j65c16017kfb57cbd77c72577c@mail.gmail.com> <4A5B06B3.5020004@gmx.net> <60a0e8261001080746x4445d45dmbc218c49245eaeb7@mail.gmail.com> Date: Tue, 12 Jan 2010 11:34:24 +1100 Message-ID: <60a0e8261001111634k5540c2b4u27f940b48581118c@mail.gmail.com> From: Jaz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: no em0 with r195477 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, 12 Jan 2010 00:34:27 -0000 Looks like this problem has been reported, and 1 person has a work-around. Could someone make Korba's solution into a patch? From: Korba Date: Mon, 30 Nov 2009 19:52:45 +0100 I had the same problem. I changed the e1000_read_mac_addr_generic() function in /usr/src/sys/dev/e1000/e1000_nvm.c to the 7.2 version. It works for me. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 01:23:24 2010 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 5BE3F106566B for ; Tue, 12 Jan 2010 01:23:24 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 12D2F8FC13 for ; Tue, 12 Jan 2010 01:23:23 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.237.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AE77D22E1EB; Mon, 11 Jan 2010 20:23:14 -0500 (EST) Message-ID: <4B4BCEE9.1060600@gmail.com> Date: Mon, 11 Jan 2010 17:22:49 -0800 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> In-Reply-To: <20100112000859.GD1228@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem 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, 12 Jan 2010 01:23:24 -0000 Pyun YongHyeon wrote: >> I ran the test, again, and had tcpdump capture the packets (on the host >> with the vge interface). >> >> tcpdump -i vge0 -w dump.cap -K -s 0 host 10.0.1.2 >> >> When I opened it up in Wireshark, it's reporting that the outgoing UDP >> checksums are incorrect; they're always 0x1ae3. That said, maybe the >> > > Because bpf(4) see the frame before controller inserts checksum > value it always reports incorrect checksum. It's normal for TX > checksum offload capable controller. > In order to verify the hardware assisted checksum you should check > that on receiver side. If the checksum was invalid, receiver > dropped them. See "netstat -s | grep bad" on receiver host. > > I did this one between two similar FreeBSD systems (8.0 and 8.0 RC1, I think). There wasn't an error in netstat -s on the receiver, but I ran tcpdump, anyway. The checksums were good, but iperf ended with "read failed: connection refused." On the non-vge box, once the vge box is done sending, it sends four identical UDP packets to the vge host, I think to ask it for sending statistics. Instead of statistics, it got back an ICMP packet saying "port unreachable." This happens with a freebsd client, but not a linux client (I didn't confirm the ICMP message with tcpdump, though). All iperf versions are the same (2.0.4), but the linux one doesn't have any threading (which shouldn't be an issue when I'm not using that option). >> checksums are done in hardware AFTER tcpdump sees them. >> >> I set net.inet.udp.checksum to 0. The bad checksums are gone, but I >> still see dropped packets. >> >> > > This doesn't disable TX checksum offload of driver. Instead use > #ifconfig vge0 -txcsum > > I'm still losing packets, but now it's interesting. The other FreeBSD machine (a VMware VM on a fairly fast machine with another gigabit connection) loses just a few, now, and sometimes none. The linux box (200mhz, runs OpenWrt, 100mbps ethernet) still loses more than 1% of packets. I cut iperf back to 100kbps. The results were much better (0 packets lost), but this did happen one time: [ 3] WARNING: did not receive ack of last datagram after 10 tries. Maybe this is related to "port unreachable," and maybe to my nfs problem. The drops seem to be related to iperf not being able to do much processing at 200 mhz (which is a little surprising; I was only asking for 1Mbps). >> It's on the motherboard, probably wired directly to a PCI-E connection, >> but yes, it is a VT6130. >> > > Show me "pciconf -lcv" output. > vge0@pci0:3:0:0: class=0x020000 card=0x01101106 chip=0x31191106 rev=0x82 hdr=0x00 vendor = 'VIA Technologies Inc' device = ''Velocity' Gigabit Ethernet Controllers (VT6120/VT6121/VT6122)' class = network subclass = ethernet cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[90] = PCI-Express 1 endpoint max data 128(128) link x1(x1) cap 05[c0] = MSI supports 1 message, 64 bit, vector masks It might not be vge, after all, and might just be its speed...but that shouldn't cause a tcp nfs issue. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 00:44:03 2010 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 B2CF4106566B for ; Tue, 12 Jan 2010 00:44:03 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABD48FC1E for ; Tue, 12 Jan 2010 00:44:03 +0000 (UTC) Received: by qyk41 with SMTP id 41so10651802qyk.29 for ; Mon, 11 Jan 2010 16:43:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.51.231 with SMTP id e39mr1439132qag.138.1263255253300; Mon, 11 Jan 2010 16:14:13 -0800 (PST) X-Originating-IP: [128.95.133.176] In-Reply-To: <74c4f9521001111435q4c7f6266p51430724dc566a48@mail.gmail.com> References: <74c4f9521001111435q4c7f6266p51430724dc566a48@mail.gmail.com> Date: Mon, 11 Jan 2010 16:14:13 -0800 Message-ID: From: Rob Farmer To: Phillip Kinsley Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 12 Jan 2010 02:17:35 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Gcc question 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, 12 Jan 2010 00:44:03 -0000 On Mon, Jan 11, 2010 at 2:35 PM, Phillip Kinsley wrote: > I'm having problems with gcc4.2.1 and would like to use gcc4.4. I > install gcc4.4 and binutils via ports. Now how do get gcc4.4 to be my > default compiler? See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/index.html > > Thanks > > Phillip > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 02:49:48 2010 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 AA1F2106566B for ; Tue, 12 Jan 2010 02:49:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 58B7C8FC0C for ; Tue, 12 Jan 2010 02:49:48 +0000 (UTC) Received: by qyk41 with SMTP id 41so10710786qyk.29 for ; Mon, 11 Jan 2010 18:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TVqIkAfaLqdkAxoGHVIdaXGEO6lCOSPrLX1ig7x0cj0=; b=HyrXkyLc7HLt8ia/Nw6Fv54xqpozpFFtj66ZLZltEn0qFfJIoQ7LSv8iX+JaNXsYr4 UQRpe5DkmB8b1UPt5cu1kxE0P7xwSRIP2ClREanK5+U3a+LAVMDQ76NB0X71/fEm8UJ2 RWgrYZ1vOApILH6WpYOyiwrbDdszZgGuhegFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Xm0dpdo2RyAn8i4fldd8xWhuPW1kC5IATCIXi3P2/us9TW8y5vMDdi675O1RRbqhbm +bb2chg+IxummGTWy1x7FVYaf7MBQDxo+pFhEGVxQCY2HpPgNki+RBBXMAzYpTWY2G4X eZrq4fi+HyZbG6G1NitOQugZu2Wt+EppW917o= Received: by 10.224.55.145 with SMTP id u17mr2589867qag.370.1263264582972; Mon, 11 Jan 2010 18:49:42 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm19970726qwd.36.2010.01.11.18.49.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 18:49:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 18:49:00 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 18:49:00 -0800 To: David Ehrmann Message-ID: <20100112024900.GG1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> <4B4BCEE9.1060600@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4BCEE9.1060600@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 02:49:48 -0000 On Mon, Jan 11, 2010 at 05:22:49PM -0800, David Ehrmann wrote: > Pyun YongHyeon wrote: > >>I ran the test, again, and had tcpdump capture the packets (on the host > >>with the vge interface). > >> > >>tcpdump -i vge0 -w dump.cap -K -s 0 host 10.0.1.2 > >> > >>When I opened it up in Wireshark, it's reporting that the outgoing UDP > >>checksums are incorrect; they're always 0x1ae3. That said, maybe the > >> > > > >Because bpf(4) see the frame before controller inserts checksum > >value it always reports incorrect checksum. It's normal for TX > >checksum offload capable controller. > >In order to verify the hardware assisted checksum you should check > >that on receiver side. If the checksum was invalid, receiver > >dropped them. See "netstat -s | grep bad" on receiver host. > > > > > I did this one between two similar FreeBSD systems (8.0 and 8.0 RC1, I > think). There wasn't an error in netstat -s on the receiver, but I ran > tcpdump, anyway. The checksums were good, but iperf ended with "read > failed: connection refused." On the non-vge box, once the vge box is > done sending, it sends four identical UDP packets to the vge host, I > think to ask it for sending statistics. Instead of statistics, it got > back an ICMP packet saying "port unreachable." This happens with a > freebsd client, but not a linux client (I didn't confirm the ICMP > message with tcpdump, though). All iperf versions are the same (2.0.4), > but the linux one doesn't have any threading (which shouldn't be an > issue when I'm not using that option). It seems iperf on FreeBSD was broken. It incorrectly generates huge-packet with IP length 0 so other host disconnected the TCP connection. Not sure it could be related with threading though. Use netperf instead, it would be more reliable than iperf. > >>checksums are done in hardware AFTER tcpdump sees them. > >> > >>I set net.inet.udp.checksum to 0. The bad checksums are gone, but I > >>still see dropped packets. > >> > >> > > > >This doesn't disable TX checksum offload of driver. Instead use > >#ifconfig vge0 -txcsum > > > > > I'm still losing packets, but now it's interesting. The other FreeBSD > machine (a VMware VM on a fairly fast machine with another gigabit > connection) loses just a few, now, and sometimes none. The linux box > (200mhz, runs OpenWrt, 100mbps ethernet) still loses more than 1% of > packets. I cut iperf back to 100kbps. The results were much better (0 > packets lost), but this did happen one time: > It's normal see some dropped frames under high network load. And you can't compare gigabit controller to fast ethernet controller. > [ 3] WARNING: did not receive ack of last datagram after 10 tries. > > Maybe this is related to "port unreachable," and maybe to my nfs > problem. The drops seem to be related to iperf not being able to do > much processing at 200 mhz (which is a little surprising; I was only > asking for 1Mbps). > >>It's on the motherboard, probably wired directly to a PCI-E connection, > >>but yes, it is a VT6130. > >> > > > >Show me "pciconf -lcv" output. > > > vge0@pci0:3:0:0: class=0x020000 card=0x01101106 chip=0x31191106 > rev=0x82 hdr=0x00 > vendor = 'VIA Technologies Inc' > device = ''Velocity' Gigabit Ethernet Controllers > (VT6120/VT6121/VT6122)' > class = network > subclass = ethernet > cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 10[90] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > cap 05[c0] = MSI supports 1 message, 64 bit, vector masks > > It might not be vge, after all, and might just be its speed...but that > shouldn't cause a tcp nfs issue. I have exact the same revision of the hardware and I don't have encountered your issue here. Instead of measuring performance number with broken iperf, check whether you still get "Connection reset by peer" message with csup(1) when you use vge(4) interface. If you still see the message, please send me tcpdump capture in private. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 02:57:13 2010 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 245BD1065696 for ; Tue, 12 Jan 2010 02:57:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id C37208FC19 for ; Tue, 12 Jan 2010 02:57:12 +0000 (UTC) Received: by qyk41 with SMTP id 41so10714288qyk.29 for ; Mon, 11 Jan 2010 18:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=rh/psri3aaeld9tgeXmEc2NMIknQdAZRjd9WzTYEo5Q=; b=IwwGl6WEOYUIZiVYlKsUDMmCFuds/mjn7rjyOrTnF8GG7jJK3yz6P4hKnJcUtS/1OF N7IZYW+6fWPb5I+o0Ya7TDt31uDwOsdiFYVy8MG5rD1W6Q5ow3ZAVXlSusbDznXZpe1Q WN6Fd5xLZFKPDPCXW7OkxL5U33t7SaWDjmsd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=kKcuvH7sqQozT0Kom6orP1jkCFCJt88zYnVLE+zJOLDqpMCMY2wXtrlVCmRFm53WWe PKoKKwa5To5RDzYsaLspSSqsn6dOt7ecO+lTbu/cgJneHbC0f4yKiI/4KXAwZgEkADII up8gS4QjoEn12Fb5+oXyHTpp03tz7iH0xPVkM= Received: by 10.224.79.229 with SMTP id q37mr750972qak.2.1263265032020; Mon, 11 Jan 2010 18:57:12 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm5192553qyk.0.2010.01.11.18.57.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Jan 2010 18:57:11 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Jan 2010 18:56:29 -0800 From: Pyun YongHyeon Date: Mon, 11 Jan 2010 18:56:29 -0800 To: David Ehrmann Message-ID: <20100112025629.GH1228@michelle.cdnetworks.com> References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> <4B4BCEE9.1060600@gmail.com> <20100112024900.GG1228@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100112024900.GG1228@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 02:57:13 -0000 On Mon, Jan 11, 2010 at 06:49:00PM -0800, Pyun YongHyeon wrote: > On Mon, Jan 11, 2010 at 05:22:49PM -0800, David Ehrmann wrote: [...] > > I did this one between two similar FreeBSD systems (8.0 and 8.0 RC1, I > > think). There wasn't an error in netstat -s on the receiver, but I ran > > tcpdump, anyway. The checksums were good, but iperf ended with "read > > failed: connection refused." On the non-vge box, once the vge box is > > done sending, it sends four identical UDP packets to the vge host, I > > think to ask it for sending statistics. Instead of statistics, it got > > back an ICMP packet saying "port unreachable." This happens with a > > freebsd client, but not a linux client (I didn't confirm the ICMP > > message with tcpdump, though). All iperf versions are the same (2.0.4), > > but the linux one doesn't have any threading (which shouldn't be an > > issue when I'm not using that option). > > It seems iperf on FreeBSD was broken. It incorrectly generates > huge-packet with IP length 0 so other host disconnected the > TCP connection. Not sure it could be related with threading though. > Use netperf instead, it would be more reliable than iperf. > Disabling threading make iperf work again. And don't be surprised at the dropped counter of iperf, it's normal for UDP frames. Good hardware and fast system may have better numbers but you can't completely remove dropped counters. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 03:18:46 2010 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 17C4C106566B; Tue, 12 Jan 2010 03:18:45 +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 654F98FC16; Tue, 12 Jan 2010 03:18:45 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o0C3IfMr018713; Tue, 12 Jan 2010 03:18:41 GMT (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4B4BE98F.1000500@fletchermoorland.co.uk> Date: Tue, 12 Jan 2010 03:16:31 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20091217) MIME-Version: 1.0 To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,BAYES_00, FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: current@freebsd.org Subject: Audio levels in Virtualbox 3.1.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, 12 Jan 2010 03:18:46 -0000 Hi, I have just updated to VirtualBox 3.1.2 and have noticed the audio levels seem ALOT lower than the previous version (3.0.51 from the ports tree). At first I thought that there was no audio at all until I turned the speakers up by about 30% I tried running XMMS on the BSD host and the audio levels are indeed VERY different (with BSD being ALOT louder) Has anyone else seen this? The host is demophon# uname -a FreeBSD demophon.fletchermoorland.co.uk 9.0-CURRENT FreeBSD 9.0-CURRENT #28 r202126: Tue Jan 12 02:41:53 UTC 2010 paul@demophon.fletchermoorland.co.uk:/usr/obj/usr/src/sys/DEMOPHON amd64 demophon# more sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels simplex) pcm1: at cad 2 nid 1 on hdac1 [MPSAFE] (1p:2v/1r:1v channels duplex default) pcm2: at cad 2 nid 1 on hdac1 [MPSAFE] (1p:1v/1r:1v channels duplex) pcm3: at cad 2 nid 1 on hdac1 [MPSAFE] (1p:1v/1r:1v channels duplex) demophon# sysctl -a | grep snd ... hw.snd.default_unit: 1 ... The guest is Windows Vista using the OSS Driver and ICH AC97 options Cheers Paul From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 04:29:58 2010 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 B5745106566B for ; Tue, 12 Jan 2010 04:29:58 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id 869E68FC12 for ; Tue, 12 Jan 2010 04:29:58 +0000 (UTC) Received: from [10.0.0.171] (unknown [64.9.237.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 67F7322E1EB; Mon, 11 Jan 2010 23:29:39 -0500 (EST) Message-ID: <4B4BFAA7.8030103@gmail.com> Date: Mon, 11 Jan 2010 20:29:27 -0800 From: David Ehrmann User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4B40AFFA.6090706@gmail.com> <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> <4B4BCEE9.1060600@gmail.com> <20100112024900.GG1228@michelle.cdnetworks.com> In-Reply-To: <20100112024900.GG1228@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem 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, 12 Jan 2010 04:29:58 -0000 Pyun YongHyeon wrote: > It seems iperf on FreeBSD was broken. It incorrectly generates > huge-packet with IP length 0 so other host disconnected the > TCP connection. Not sure it could be related with threading though. > Use netperf instead, it would be more reliable than iperf. > I saw a lot of warnings when I opened the cap file in Wireshark about the length in the IP header being wrong. I'll start looking into netperf > It's normal see some dropped frames under high network load. And > you can't compare gigabit controller to fast ethernet controller. > Very true, and that's why I tried a lower load. I was a little surprised to see it choking at just 1 Mb/s (that's bits, not bytes), though. > I have exact the same revision of the hardware and I don't have > encountered your issue here. Instead of measuring performance > number with broken iperf, check whether you still get > "Connection reset by peer" message with csup(1) when you use vge(4) > interface. If you still see the message, please send me tcpdump > capture in private. > csup is still working. I actually think I *might* have the problem solved. Switching the mount from UDP (why it was the default for NFS in this Linux distro, I don't know) to TCP seems to have fixed it. My guess is that some sort of race condition occurred or there's a bug in someone's NFS flow control mechanism. A 10x CPU and network performance difference must be more than is usually tested. I hope. I'll keep testing NFS over TCP and see if it fixed my problem. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 04:53:03 2010 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 F0E0D1065698 for ; Tue, 12 Jan 2010 04:53:03 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9339F8FC20 for ; Tue, 12 Jan 2010 04:53:03 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0C4oUbH001418 for ; Tue, 12 Jan 2010 15:20:30 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Tue, 12 Jan 2010 15:23:02 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 15:23:01 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jan 2010 12:53:00 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0C4pl5a068448 for ; Tue, 12 Jan 2010 12:51:47 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0C4plRS068447 for freebsd-current@freebsd.org; Tue, 12 Jan 2010 12:51:47 +0800 (WST) (envelope-from wilkinsa) Date: Tue, 12 Jan 2010 12:51:47 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100112045147.GA68439@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 12 Jan 2010 04:53:00.0663 (UTC) FILETIME=[1DDD8870:01CA9343] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17126.004 X-TM-AS-Result: No--2.735400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: Help test softupdates journaling (SUJ) [SEC=UNCLASSIFIED] 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, 12 Jan 2010 04:53:04 -0000 0n Fri, Jan 08, 2010 at 02:56:45PM -1000, Jeff Roberson wrote: >To install you will need to apply http://people.freebsd.org/~jeff/suj.diff to a I get the following with a buildworld after your patch: cc -O0 -pipe -I/usr/src/sbin/fsck_ffs -I/usr/src/sbin/fsck_ffs/../mount -g -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/fsck_ffs/suj.c In file included from /usr/src/sbin/fsck_ffs/suj.c:1982: /usr/src/sbin/fsck_ffs/fsck.h:72: error: redefinition of 'union dinode' /usr/src/sbin/fsck_ffs/fsck.h:94: error: redefinition of 'struct inostat' /usr/src/sbin/fsck_ffs/fsck.h:121: error: redefinition of 'struct inostatlist' /usr/src/sbin/fsck_ffs/fsck.h:129: error: redefinition of 'struct bufarea' /usr/src/sbin/fsck_ffs/fsck.h:185: error: nested redefinition of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of 'enum fixstate' /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'DONTKNOW' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'DONTKNOW' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'NOFIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'NOFIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'FIX' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'FIX' was here /usr/src/sbin/fsck_ffs/fsck.h:185: error: redeclaration of enumerator 'IGNORE' /usr/src/sbin/fsck_ffs/fsck.h:185: error: previous definition of 'IGNORE' was here /usr/src/sbin/fsck_ffs/fsck.h:188: error: redefinition of 'struct inodesc' /usr/src/sbin/fsck_ffs/fsck.h:230: error: redefinition of 'struct dups' /usr/src/sbin/fsck_ffs/fsck.h:240: error: redefinition of 'struct inoinfo' /usr/src/sbin/fsck_ffs/suj.c:1990: error: redefinition of 'struct suj_seg' /usr/src/sbin/fsck_ffs/suj.c:1996: error: redefinition of 'struct suj_rec' /usr/src/sbin/fsck_ffs/suj.c:2000: error: redefinition of 'struct srechd' /usr/src/sbin/fsck_ffs/suj.c:2002: error: redefinition of 'struct suj_ino' /usr/src/sbin/fsck_ffs/suj.c:2012: error: redefinition of 'struct inohd' /usr/src/sbin/fsck_ffs/suj.c:2014: error: redefinition of 'struct suj_blk' /usr/src/sbin/fsck_ffs/suj.c:2019: error: redefinition of 'struct blkhd' /usr/src/sbin/fsck_ffs/suj.c:2021: error: redefinition of 'struct data_blk' /usr/src/sbin/fsck_ffs/suj.c:2028: error: redefinition of 'struct ino_blk' /usr/src/sbin/fsck_ffs/suj.c:2034: error: redefinition of 'struct iblkhd' /usr/src/sbin/fsck_ffs/suj.c:2036: error: redefinition of 'struct suj_cg' /usr/src/sbin/fsck_ffs/suj.c:2048: error: redefinition of 'struct cghd' /usr/src/sbin/fsck_ffs/suj.c:2049: error: redefinition of 'struct dblkhd' /usr/src/sbin/fsck_ffs/suj.c:2051: error: redefinition of 'struct seghd' /usr/src/sbin/fsck_ffs/suj.c:2053: error: redefinition of 'disk' /usr/src/sbin/fsck_ffs/suj.c:119: error: previous definition of 'disk' was here /usr/src/sbin/fsck_ffs/suj.c:2054: error: redefinition of 'fs' /usr/src/sbin/fsck_ffs/suj.c:120: error: previous definition of 'fs' was here /usr/src/sbin/fsck_ffs/suj.c:2064: error: redefinition of typedef 'ino_visitor' /usr/src/sbin/fsck_ffs/suj.c:130: error: previous declaration of 'ino_visitor' was here /usr/src/sbin/fsck_ffs/suj.c:2068: error: redefinition of 'errmalloc' /usr/src/sbin/fsck_ffs/suj.c:134: error: previous definition of 'errmalloc' was here /usr/src/sbin/fsck_ffs/suj.c:2082: error: redefinition of 'opendisk' /usr/src/sbin/fsck_ffs/suj.c:148: error: previous definition of 'opendisk' was here /usr/src/sbin/fsck_ffs/suj.c:2106: error: redefinition of 'closedisk' /usr/src/sbin/fsck_ffs/suj.c:172: error: previous definition of 'closedisk' was here /usr/src/sbin/fsck_ffs/suj.c:2142: error: redefinition of 'cg_lookup' /usr/src/sbin/fsck_ffs/suj.c:208: error: previous definition of 'cg_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2173: error: redefinition of 'ino_lookup' /usr/src/sbin/fsck_ffs/suj.c:239: error: previous definition of 'ino_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2201: error: redefinition of 'blk_lookup' /usr/src/sbin/fsck_ffs/suj.c:267: error: previous definition of 'blk_lookup' was here /usr/src/sbin/fsck_ffs/suj.c:2224: error: redefinition of 'dblk_read' /usr/src/sbin/fsck_ffs/suj.c:290: error: previous definition of 'dblk_read' was here /usr/src/sbin/fsck_ffs/suj.c:2257: error: redefinition of 'ino_read' /usr/src/sbin/fsck_ffs/suj.c:323: error: previous definition of 'ino_read' was here /usr/src/sbin/fsck_ffs/suj.c:2291: error: redefinition of 'ino_dirty' /usr/src/sbin/fsck_ffs/suj.c:357: error: previous definition of 'ino_dirty' was here /usr/src/sbin/fsck_ffs/suj.c:2317: error: redefinition of 'iblk_write' /usr/src/sbin/fsck_ffs/suj.c:383: error: previous definition of 'iblk_write' was here /usr/src/sbin/fsck_ffs/suj.c:2331: error: redefinition of 'ino_isfree' /usr/src/sbin/fsck_ffs/suj.c:397: error: previous definition of 'ino_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:2347: error: redefinition of 'blk_overlaps' /usr/src/sbin/fsck_ffs/suj.c:413: error: previous definition of 'blk_overlaps' was here /usr/src/sbin/fsck_ffs/suj.c:2363: error: redefinition of 'blk_equals' /usr/src/sbin/fsck_ffs/suj.c:429: error: previous definition of 'blk_equals' was here /usr/src/sbin/fsck_ffs/suj.c:2376: error: redefinition of 'blk_setmask' /usr/src/sbin/fsck_ffs/suj.c:442: error: previous definition of 'blk_setmask' was here /usr/src/sbin/fsck_ffs/suj.c:2393: error: redefinition of 'blk_isfree' /usr/src/sbin/fsck_ffs/suj.c:459: error: previous definition of 'blk_isfree' was here /usr/src/sbin/fsck_ffs/suj.c:2443: error: redefinition of 'blk_isindir' /usr/src/sbin/fsck_ffs/suj.c:509: error: previous definition of 'blk_isindir' was here /usr/src/sbin/fsck_ffs/suj.c:2465: error: redefinition of 'ino_free' /usr/src/sbin/fsck_ffs/suj.c:531: error: previous definition of 'ino_free' was here /usr/src/sbin/fsck_ffs/suj.c:2502: error: redefinition of 'blk_free' /usr/src/sbin/fsck_ffs/suj.c:568: error: previous definition of 'blk_free' was here /usr/src/sbin/fsck_ffs/suj.c:2546: error: redefinition of 'indir_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:612: error: previous definition of 'indir_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:2597: error: redefinition of 'ino_blkatoff' /usr/src/sbin/fsck_ffs/suj.c:663: error: previous definition of 'ino_blkatoff' was here /usr/src/sbin/fsck_ffs/suj.c:2654: error: redefinition of 'blk_isat' /usr/src/sbin/fsck_ffs/suj.c:720: error: previous definition of 'blk_isat' was here /usr/src/sbin/fsck_ffs/suj.c:2673: error: redefinition of 'ino_isat' /usr/src/sbin/fsck_ffs/suj.c:739: error: previous definition of 'ino_isat' was here /usr/src/sbin/fsck_ffs/suj.c:2766: error: redefinition of 'indir_visit' /usr/src/sbin/fsck_ffs/suj.c:832: error: previous definition of 'indir_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2827: error: redefinition of 'ino_visit' /usr/src/sbin/fsck_ffs/suj.c:893: error: previous definition of 'ino_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2877: error: redefinition of 'null_visit' /usr/src/sbin/fsck_ffs/suj.c:943: error: previous definition of 'null_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2888: error: redefinition of 'ino_adjblks' /usr/src/sbin/fsck_ffs/suj.c:954: error: previous definition of 'ino_adjblks' was here /usr/src/sbin/fsck_ffs/suj.c:2915: error: redefinition of 'blk_free_visit' /usr/src/sbin/fsck_ffs/suj.c:981: error: previous definition of 'blk_free_visit' was here /usr/src/sbin/fsck_ffs/suj.c:2931: error: redefinition of 'blk_free_lbn' /usr/src/sbin/fsck_ffs/suj.c:997: error: previous definition of 'blk_free_lbn' was here /usr/src/sbin/fsck_ffs/suj.c:2947: error: redefinition of 'ino_free_children' /usr/src/sbin/fsck_ffs/suj.c:1013: error: previous definition of 'ino_free_children' was here /usr/src/sbin/fsck_ffs/suj.c:3019: error: redefinition of 'ino_truncate' /usr/src/sbin/fsck_ffs/suj.c:1085: error: previous definition of 'ino_truncate' was here /usr/src/sbin/fsck_ffs/suj.c:3057: error: redefinition of 'ino_decr' /usr/src/sbin/fsck_ffs/suj.c:1123: error: previous definition of 'ino_decr' was here /usr/src/sbin/fsck_ffs/suj.c:3092: error: redefinition of 'ino_adjust' /usr/src/sbin/fsck_ffs/suj.c:1158: error: previous definition of 'ino_adjust' was here /usr/src/sbin/fsck_ffs/suj.c:3143: error: redefinition of 'ino_check' /usr/src/sbin/fsck_ffs/suj.c:1209: error: previous definition of 'ino_check' was here /usr/src/sbin/fsck_ffs/suj.c:3229: error: redefinition of 'blk_check' /usr/src/sbin/fsck_ffs/suj.c:1295: error: previous definition of 'blk_check' was here /usr/src/sbin/fsck_ffs/suj.c:3287: error: redefinition of 'cg_check' /usr/src/sbin/fsck_ffs/suj.c:1353: error: previous definition of 'cg_check' was here /usr/src/sbin/fsck_ffs/suj.c:3313: error: redefinition of 'cg_write' /usr/src/sbin/fsck_ffs/suj.c:1379: error: previous definition of 'cg_write' was here /usr/src/sbin/fsck_ffs/suj.c:3367: error: redefinition of 'cg_apply' /usr/src/sbin/fsck_ffs/suj.c:1433: error: previous definition of 'cg_apply' was here /usr/src/sbin/fsck_ffs/suj.c:3384: error: redefinition of 'suj_build_ino' /usr/src/sbin/fsck_ffs/suj.c:1450: error: previous definition of 'suj_build_ino' was here /usr/src/sbin/fsck_ffs/suj.c:3420: error: redefinition of 'suj_move_ino' /usr/src/sbin/fsck_ffs/suj.c:1486: error: previous definition of 'suj_move_ino' was here /usr/src/sbin/fsck_ffs/suj.c:3458: error: redefinition of 'suj_build_blk' /usr/src/sbin/fsck_ffs/suj.c:1524: error: previous definition of 'suj_build_blk' was here /usr/src/sbin/fsck_ffs/suj.c:3511: error: redefinition of 'suj_build' /usr/src/sbin/fsck_ffs/suj.c:1577: error: previous definition of 'suj_build' was here /usr/src/sbin/fsck_ffs/suj.c:3551: error: redefinition of 'suj_prune' /usr/src/sbin/fsck_ffs/suj.c:1617: error: previous definition of 'suj_prune' was here /usr/src/sbin/fsck_ffs/suj.c:3612: error: redefinition of 'suj_verifyino' /usr/src/sbin/fsck_ffs/suj.c:1678: error: previous definition of 'suj_verifyino' was here /usr/src/sbin/fsck_ffs/suj.c:3631: error: redefinition of 'struct jblocks' /usr/src/sbin/fsck_ffs/suj.c:3638: error: redefinition of 'struct jextent' /usr/src/sbin/fsck_ffs/suj.c:3647: error: redefinition of 'jblocks_create' /usr/src/sbin/fsck_ffs/suj.c:1713: error: previous definition of 'jblocks_create' was here /usr/src/sbin/fsck_ffs/suj.c:3669: error: redefinition of 'jblocks_next' /usr/src/sbin/fsck_ffs/suj.c:1735: error: previous definition of 'jblocks_next' was here /usr/src/sbin/fsck_ffs/suj.c:3699: error: redefinition of 'jblocks_advance' /usr/src/sbin/fsck_ffs/suj.c:1765: error: previous definition of 'jblocks_advance' was here /usr/src/sbin/fsck_ffs/suj.c:3706: error: redefinition of 'jblocks_destroy' /usr/src/sbin/fsck_ffs/suj.c:1772: error: previous definition of 'jblocks_destroy' was here /usr/src/sbin/fsck_ffs/suj.c:3714: error: redefinition of 'jblocks_add' /usr/src/sbin/fsck_ffs/suj.c:1780: error: previous definition of 'jblocks_add' was here /usr/src/sbin/fsck_ffs/suj.c:3755: error: redefinition of 'suj_add_block' /usr/src/sbin/fsck_ffs/suj.c:1821: error: previous definition of 'suj_add_block' was here /usr/src/sbin/fsck_ffs/suj.c:3762: error: redefinition of 'suj_read' /usr/src/sbin/fsck_ffs/suj.c:1828: error: previous definition of 'suj_read' was here /usr/src/sbin/fsck_ffs/suj.c:3830: error: redefinition of 'suj_check' /usr/src/sbin/fsck_ffs/suj.c:1896: error: previous definition of 'suj_check' was here *** Error code 1 Stop in /usr/src/sbin/fsck_ffs. *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Exit 1 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 09:39:19 2010 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 1D57C1065693 for ; Tue, 12 Jan 2010 09:39:19 +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 97FF48FC17 for ; Tue, 12 Jan 2010 09:39:18 +0000 (UTC) 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 "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id EF6999675; Tue, 12 Jan 2010 10:39:16 +0100 (CET) Received: from meribel.restart.bel (meribel.restart.bel [IPv6:2001:41d0:2:2d29:1:8::]) (authenticated bits=0) by restart.be (8.14.4/8.14.4) with ESMTP id o0C97e0i046016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 10:07:40 +0100 (CET) (envelope-from hlh@restart.be) X-DKIM: Sendmail DKIM Filter v2.8.3 restart.be o0C97e0i046016 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1263287270; bh=H+CzE65+aSlfLikt0qoCIkU2hCc0e4mAQg7P0uxbZx4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nLUVoMOuGAOKmXyX939wBCGvJbiKhV/OcBXBRg8EUv0E0kN6/+gZJtp0P8O4cor7c jU4sGkrztr9356lmbts/w== X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 restart.be o0C97e0i046016 DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=qDlqcGo9zJJpbOcYa2UhRQTdVbrypTwxPxUwcuA4br1aqwTOGPpU/ZIylY7S6WvS5 GZglCe7jCQMtrAmIMiJIg== Message-ID: <4B4C3BDC.4000104@restart.be> Date: Tue, 12 Jan 2010 10:07:40 +0100 From: Henri Hennebert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20091220 Thunderbird/3.0 MIME-Version: 1.0 To: Hans Petter Selasky , freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <4B4B7523.6060409@restart.be> In-Reply-To: <4B4B7523.6060409@restart.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2001:41d0:2:2d29:1:1:: Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 12 Jan 2010 09:39:19 -0000 On 01/11/2010 19:59, Henri Hennebert wrote: > On 01/10/2010 14:37, Hans Petter Selasky wrote: >> Hi, >> >> During the last couple of days I've spent some time to finish my webcam >> daemon. My webcam daemon is basically an application which consists of >> userspace Video4Linux USB webcam drivers and some uLinux glue code >> which links >> with libc, pthreads and libusb. The webcamd talks to >> /dev/video_daemonX which >> is provided by the video4bsd kernel module. There is full support for >> mmap/read/write/open/close. poll is not supported. >> >> Basic operation and idea: >> >> /dev/video_daemonX is the interface for the webcamd. /dev/videoX is the >> interface for the V4L application. The video4bsd transports all data >> between >> these two devices. In the case the V4L application is using mmap, no >> data is >> copied due to shared kernel memory buffer! >> >> Licensing issues: >> >> Effectivly the webcamd userland program becomes GPL'ed due to the V4L USB >> drivers which are GPL licensed. Some files inside the webcamd remains BSD >> licensed which allows for building similar BSD licensed daemons. >> >> The rest of the code is BSD licensed. >> >> Source code: >> >> 1) FreeBSD 8-stable >> >> 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: >> >> http://p4web.freebsd.org/chv.cgi?CH=172876 >> >> http://perforce.freebsd.org/chv.cgi?CH=172876 >> >> 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be >> checked >> out in the same folder due to dependencies) >> >> svn --username anonsvn --password anonsvn \ >> checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd >> >> make all install >> kldload video4bsd >> >> svn --username anonsvn --password anonsvn \ >> checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux >> >> make fetch >> make patch >> make all >> make install >> >> # this will attach to the first detected webcam: >> ./webcamd >> >> # this will try to attach to the given USB unit, interface and V4B unit. >> ./webcamd -d ugen4.1 -i 0 -v 0 >> >> # this will display webcam contents from /dev/video0 by default. >> ./pwcview/pwcview >> >> Feedback and bug reports are welcome. >> > I try on a Fujitsu M2010: > > FreeBSD meribel.restart.bel 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0 > r201748M: Thu Jan 7 16:23:56 CET 2010 > root@meribel.restart.bel:/usr/obj/usr/src/sys/MERIBEL i386 > > [root@meribel ~]# usbconfig > ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) > pwr=ON > ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW > (1.5Mbps) pwr=ON > ugen1.2: at usbus1, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON > ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > [root@meribel ~]# /home/meribel/webcam/ulinux/webcamd -d ugen3.2 -i 0 -v 0 > KrefGet: 0x34028404 = 1 > KrefGet: 0x34028404 = 2 > KrefGet: 0x3402860c = 1 > KrefGet: 0x340286c8 = 1 > Added device 0x33f18b04 > KrefGet: 0x33f18b08 = 1 > KrefGet: 0x33f18b08 = 2 > > [root@meribel ~]# chmod 666 /dev/video* /dev/usb/* > > [hlh@meribel ~]$ pwcview > Webcam set to: 320x240 (sif) at 5 fps > > Give me a green window for some time and then this picture: > > http://verbier.restart.be/xfer/Screenshot-pwcview.png > > which stay still. > > I can't kill pwcview window. > Better news... I try on the same config an external webcam (Logitech QuickCam Messenger) [root@meribel ulinux]# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.3: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON [root@meribel ulinux]# ./webcamd -d ugen0.3 -i 0 -v 0 KrefGet: 0x34028904 = 1 Added device 0x33fdf304 KrefGet: 0x33fdf308 = 1 KrefGet: 0x33fdf308 = 2 KrefPut: 0x33fdf308 = 2 And pwcview work perfectly :-) Henri From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 12:48:55 2010 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 6D5A71065672 for ; Tue, 12 Jan 2010 12:48:55 +0000 (UTC) (envelope-from mik@pc.dk) Received: from pqueueb.post.tele.dk (pqueueb.post.tele.dk [193.162.153.10]) by mx1.freebsd.org (Postfix) with ESMTP id 06AD88FC16 for ; Tue, 12 Jan 2010 12:48:54 +0000 (UTC) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by pqueueb.post.tele.dk (Postfix) with ESMTP id A4FDD8038 for ; Tue, 12 Jan 2010 13:18:06 +0100 (CET) Received: from miknet.dk (0x5738c0ef.rdnqu2.dynamic.dsl.tele.dk [87.56.192.239]) by pfepa.post.tele.dk (Postfix) with ESMTP id 2CA9FA5001D for ; Tue, 12 Jan 2010 13:17:31 +0100 (CET) Date: Tue, 12 Jan 2010 13:16:41 +0100 From: Martin Kristensen To: freebsd-current@freebsd.org Message-ID: <20100112131641.15f44ead@miknet.dk> In-Reply-To: <201001101437.37269.hselasky@c2i.net> References: <201001101437.37269.hselasky@c2i.net> Organization: Private X-Mailer: Claws Mail 3.7.3 (GTK+ 2.18.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing 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, 12 Jan 2010 12:48:55 -0000 On Sun, 10 Jan 2010 14:37:37 +0100 Hans Petter Selasky wrote: > Hi, > > During the last couple of days I've spent some time to finish my > webcam daemon. My webcam daemon is basically an application which > consists of userspace Video4Linux USB webcam drivers and some uLinux > glue code which links with libc, pthreads and libusb. The webcamd > talks to /dev/video_daemonX which is provided by the video4bsd kernel > module. There is full support for mmap/read/write/open/close. poll is > not supported. > > Basic operation and idea: > > /dev/video_daemonX is the interface for the webcamd. /dev/videoX is > the interface for the V4L application. The video4bsd transports all > data between these two devices. In the case the V4L application is > using mmap, no data is copied due to shared kernel memory buffer! > > Licensing issues: > > Effectivly the webcamd userland program becomes GPL'ed due to the V4L > USB drivers which are GPL licensed. Some files inside the webcamd > remains BSD licensed which allows for building similar BSD licensed > daemons. > > The rest of the code is BSD licensed. > > Source code: > > 1) FreeBSD 8-stable > > 2) Apply the patch below and re-install libusb in /usr/src/lib/libusb: > > http://p4web.freebsd.org/chv.cgi?CH=172876 > > http://perforce.freebsd.org/chv.cgi?CH=172876 > > 3) Compile ulinux (webcamd + libv4l + pwcview) and video4bsd (must be > checked out in the same folder due to dependencies) > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/video4bsd > > make all install > kldload video4bsd > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > make fetch > make patch > make all > make install > > # this will attach to the first detected webcam: > ./webcamd > > # this will try to attach to the given USB unit, interface and V4B > unit. ./webcamd -d ugen4.1 -i 0 -v 0 > > # this will display webcam contents from /dev/video0 by default. > ./pwcview/pwcview > > Feedback and bug reports are welcome. > > Yes, I am working on getting this into ports! > > Known issues: > > 1) If you detach the USB webcam you need to manually restart the > webcamd. > > --HPS > > Support: I will be available at #bsdusb on efnet during the day. > _______________________________________________ > 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 works for me on 8-stable, although I get flickering on the lower third of the pwcview screen. I am using a logitech quickcam pro 9000. Output from webcamd: KrefGet: 0x800c95c04 = 1 KrefGet: 0x800c95c04 = 2 KrefGet: 0x800c960bc = 1 KrefGet: 0x800c961ac = 1 Added device 0x800ce2d08 KrefGet: 0x800ce2d0c = 1 KrefGet: 0x800ce2d0c = 2 KrefPut: 0x800ce2d0c = 2 Output from pwcview: libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec libv4lconvert: Error decompressing JPEG: fill_nbits error: need 1 more bits libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffd libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffd libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffd libv4lconvert: Error decompressing JPEG: fill_nbits error: need 1 more bits libv4lconvert: Error decompressing JPEG: fill_nbits error: need 1 more bits libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffd9 libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffd9 libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffd9 libv4lconvert: Error decompressing JPEG: fill_nbits error: need 5 more bits libv4lconvert: Error decompressing JPEG: fill_nbits error: need 1 more bits libv4lconvert: Error decompressing JPEG: fill_nbits error: need 5 more bits libv4lconvert: Error decompressing JPEG: fill_nbits error: need 4 more bits libv4lconvert: Error decompressing JPEG: fill_nbits error: need 3 more bits libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff Great job! -- Martin Kristensen From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 14:57:27 2010 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 5F063106568B for ; Tue, 12 Jan 2010 14:57:27 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD838FC13 for ; Tue, 12 Jan 2010 14:57:26 +0000 (UTC) Received: from compute2.internal (compute2.internal [10.202.2.42]) by gateway1.messagingengine.com (Postfix) with ESMTP id 44675CC8D2 for ; Tue, 12 Jan 2010 09:57:26 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 12 Jan 2010 09:57:26 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=eIw/zm/P1E/zBUOWaaaCZGnpaOo=; b=P0Cr+1Wb3Xgn8KLmQfBn7WW89kSeZmiOtWCGD2jvdatYJPqR+jVq7tLRS6dV/oq4GE8IGlvEQERfTamArC6U583TTu4bcoiKLCZGID6++JOfeT44ezN2D3V/I3QK3ohdBHMYx2wmR9EOmjtN3ZeMhr0NPDosXMTb1DG79SDbzdc= X-Sasl-enc: 2iftdPidbPfzDYEPQhgcxXvEgpuY7O79K8e6cq0WdrYw 1263308245 Received: from [192.168.123.18] (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id D82431DF5 for ; Tue, 12 Jan 2010 09:57:25 -0500 (EST) Message-ID: <4B4C8DD4.2090309@incunabulum.net> Date: Tue, 12 Jan 2010 14:57:24 +0000 From: Bruce Simpson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B4225D9.9050504@FreeBSD.org> In-Reply-To: <4B4225D9.9050504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Call for tester: VirtualBox 3.1.2 for FreeBSD (take 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, 12 Jan 2010 14:57:27 -0000 Beat, This is great stuff, thank you very much. Now, even XenServer will run in a FreeBSD VirtualBox. cheers, BMS From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 15:32:13 2010 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 BE04B1065676 for ; Tue, 12 Jan 2010 15:32:13 +0000 (UTC) (envelope-from mike@mike-burns.com) Received: from jack.mike-burns.com (mike-burns.com [208.79.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id AE44C8FC08 for ; Tue, 12 Jan 2010 15:32:13 +0000 (UTC) Received: by jack.mike-burns.com (Postfix, from userid 1001) id A568E1141A; Tue, 12 Jan 2010 10:19:24 -0500 (EST) Date: Tue, 12 Jan 2010 10:19:24 -0500 From: Mike Burns To: freebsd-current@freebsd.org Message-ID: <20100112151924.GR77044@jack.mike-burns.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: DisplayPort 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, 12 Jan 2010 15:32:13 -0000 [I emailed freebsd-x11 about this[1], twice, and got no response so I'm asking here.] Is there any work being done on DisplayPort? Are there any patches floating around that I can try? [1] http://bit.ly/7gCK64 -- Mike Burns mike@mike-burns.com http://mike-burns.com From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 17:29:44 2010 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 6027A1065672 for ; Tue, 12 Jan 2010 17:29:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0D4A28FC15 for ; Tue, 12 Jan 2010 17:29:43 +0000 (UTC) Received: by qyk4 with SMTP id 4so10207636qyk.7 for ; Tue, 12 Jan 2010 09:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TIOahzTBxsc4m+L7eMqAsZu+oN0WZswbmkLNNRwm9DA=; b=IoJcepTApk/tI/MK3nv8V9zwd06FcN3WG1On60YbrmpCTSqwEhISQLSOXYi7Pb7dhn NENsIbl/XfUvZNAHLkEdvUliBHlrZt2Ln+NbqT6jTNLm7oNfes/IIzXILB+QG90vrFlz JxtQD1lpuDRn3chKiuGK+gRbw4sccAaYtVqeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Zr3YEynmtljtQluiqyWcZ44gB6fkW5+rfkpqbwVDr/cQwv9+fFxH4Rv6h8WJ2OAC5C H1f6Vdr/wiTTVbj6mhIFnJXhoiO1azaIXW2SuHyll1RopFjKcQU9Of1JtQxge5QnRLjs 2dYcijUaV5xvbcyHH//ksqV0j2TFf2NFyC73M= Received: by 10.224.24.204 with SMTP id w12mr17676327qab.366.1263317377457; Tue, 12 Jan 2010 09:29:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm864358qyk.4.2010.01.12.09.29.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Jan 2010 09:29:35 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 12 Jan 2010 09:28:54 -0800 From: Pyun YongHyeon Date: Tue, 12 Jan 2010 09:28:54 -0800 To: David Ehrmann Message-ID: <20100112172854.GI1228@michelle.cdnetworks.com> References: <20100103221630.GV1166@michelle.cdnetworks.com> <4B47B4F6.8030106@gmail.com> <20100109013145.GG18529@michelle.cdnetworks.com> <4B4ACD68.5030907@gmail.com> <20100111203557.GB1228@michelle.cdnetworks.com> <4B4BB679.2060500@gmail.com> <20100112000859.GD1228@michelle.cdnetworks.com> <4B4BCEE9.1060600@gmail.com> <20100112024900.GG1228@michelle.cdnetworks.com> <4B4BFAA7.8030103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B4BFAA7.8030103@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: vge traffic problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 17:29:44 -0000 On Mon, Jan 11, 2010 at 08:29:27PM -0800, David Ehrmann wrote: > Pyun YongHyeon wrote: > >It seems iperf on FreeBSD was broken. It incorrectly generates > >huge-packet with IP length 0 so other host disconnected the > >TCP connection. Not sure it could be related with threading though. > >Use netperf instead, it would be more reliable than iperf. > > > I saw a lot of warnings when I opened the cap file in Wireshark about > the length in the IP header being wrong. I'll start looking into netperf > Yeah, there must be a bug in iperf thread handling. Maybe default configuration of iperf should be changed until iperf bug is fixed. > >It's normal see some dropped frames under high network load. And > >you can't compare gigabit controller to fast ethernet controller. > > > Very true, and that's why I tried a lower load. I was a little > surprised to see it choking at just 1 Mb/s (that's bits, not bytes), though. Even though vge(4) is not one of the best controller you can still get more than 650Mbps TX, 920Mbps RX for bulk TCP transfers. For smaller sized TCP segments the number would be much lower than that but that's normal for virtually all controllers. I have a local patch which pushes TX performance numbers up to 800Mbps for vge(4) but it requires fast CPU to do that so I'm not sure whether I want to put it to tree or not. Since I didn't ever see this low TX performance numbers on PCIe based controllers there could be incorrectly programmed registers but datasheet said nothing about this issue. > >I have exact the same revision of the hardware and I don't have > >encountered your issue here. Instead of measuring performance > >number with broken iperf, check whether you still get > >"Connection reset by peer" message with csup(1) when you use vge(4) > >interface. If you still see the message, please send me tcpdump > >capture in private. > > > csup is still working. > > I actually think I *might* have the problem solved. Switching the mount > from UDP (why it was the default for NFS in this Linux distro, I don't > know) to TCP seems to have fixed it. My guess is that some sort of race > condition occurred or there's a bug in someone's NFS flow control > mechanism. A 10x CPU and network performance difference must be more > than is usually tested. I hope. > This could be related with NFS. If NFS over TCP works without problems on vge(4) it's more likely NFS issue. > I'll keep testing NFS over TCP and see if it fixed my problem. From owner-freebsd-current@FreeBSD.ORG Tue Jan 12 21:33:16 2010 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 0814F1065670 for ; Tue, 12 Jan 2010 21:33:16 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id B46058FC1D for ; Tue, 12 Jan 2010 21:33:15 +0000 (UTC) Received: by ywh35 with SMTP id 35so13651579ywh.7 for ; Tue, 12 Jan 2010 13:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mail-followup-to:mime-version:content-type :content-disposition:user-agent:organization:x-operation-sytem; bh=r3KLcFrLQgPIjRWNgIdUh5tT6C8QH5Bmb9RSFIa7PBw=; b=uB2+KFHRTwGn143KuULoAXZXpkffztqWZL3QkNBWMFg6ZgJA46GAgyO63sq/9WiHnb 9Oiax6zxzmEiaKjc69YpgCa6UGqDPSivO4dgmV9rSx4Z6VD8vwpDHpz+BuIJDS8105It jy4BKqj8AIgxWrbHqw0fWZX+eJCLKz3A5ZE9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=jz/nXdVxAAcU2rrcVO5z27pYAhPkZPj8PljmubZjnai9+CdUCxPPTo6fTmf67+h9e7 /lx/EA+zPEa7IhbocMNNlN2uDEt/2xsVIxh6SJ1JRNoeknz0X1rOrtJZb1mn96+6CdCh X7RWKgbq6Uv+TwxYoh5+J6FdAdgsqa5lukbN0= Received: by 10.151.88.42 with SMTP id q42mr13421059ybl.75.1263331989564; Tue, 12 Jan 2010 13:33:09 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm214259ywg.43.2010.01.12.13.33.07 (version=SSLv3 cipher=RC4-MD5); Tue, 12 Jan 2010 13:33:08 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Tue, 12 Jan 2010 13:33:29 -0800 From: Weongyo Jeong Date: Tue, 12 Jan 2010 13:33:29 -0800 To: current@freebsd.org Message-ID: <20100112213329.GV1491@weongyo> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Subject: HEADUP: major update of siba(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 21:33:16 -0000 Hello, As someone know I posted a new ssb(4) driver to support bwn(4) driver I'd written some weeks ago and gavin@ told me that there's a almost same-purpose driver called siba(4) that could be merged into one with ssb(4). As a result I made a patch here: http://people.freebsd.org/~weongyo/patch_siba_20100112.diff The changes are as follows: - This patch is focused to support Broadcom Wireless NICs so major consumer would be bwn(4) currently. - could break backward compatibility of siba(4). But I could not find consumers of siba(4), Makefile to build or examples in the tree. - adds a siba(4) man page that it'll be reviewed before committing. If no objections, I'll commit it by end of this week. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 01:16:18 2010 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 D44771065692 for ; Wed, 13 Jan 2010 01:16:18 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 985FF8FC14 for ; Wed, 13 Jan 2010 01:16:18 +0000 (UTC) Received: from [192.168.1.4] (adsl-1-207-120.bna.bellsouth.net [65.1.207.120]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0D1GGN9035057 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 20:16:16 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Mike Burns In-Reply-To: <20100112151924.GR77044@jack.mike-burns.com> References: <20100112151924.GR77044@jack.mike-burns.com> Content-Type: text/plain Organization: FreeBSD Date: Tue, 12 Jan 2010 19:16:10 -0600 Message-Id: <1263345370.2486.93.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: DisplayPort 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, 13 Jan 2010 01:16:18 -0000 On Tue, 2010-01-12 at 10:19 -0500, Mike Burns wrote: > [I emailed freebsd-x11 about this[1], twice, and got no response so I'm > asking here.] > > Is there any work being done on DisplayPort? Are there any patches floating > around that I can try? On radeon's it should work in X. I don't remember if you need the ddx driver from git or not though. I'm doubt that intel will work, since they have totally stopped working on anything that isn't GEM/KMS. It isn't entirely clear what you are asking about... but at least the video hardware is relevant. robert. > > [1] http://bit.ly/7gCK64 -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 02:10:22 2010 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 DDE251065783 for ; Wed, 13 Jan 2010 02:10:22 +0000 (UTC) (envelope-from mike@mike-burns.com) Received: from jack.mike-burns.com (mike-burns.com [208.79.89.210]) by mx1.freebsd.org (Postfix) with ESMTP id B8ED58FC17 for ; Wed, 13 Jan 2010 02:10:22 +0000 (UTC) Received: by jack.mike-burns.com (Postfix, from userid 1001) id 2AA1B1141A; Tue, 12 Jan 2010 21:07:50 -0500 (EST) Date: Tue, 12 Jan 2010 21:07:50 -0500 From: Mike Burns To: Robert Noland Message-ID: <20100113020750.GX77044@jack.mike-burns.com> Mail-Followup-To: Robert Noland , freebsd-current@freebsd.org References: <20100112151924.GR77044@jack.mike-burns.com> <1263345370.2486.93.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1263345370.2486.93.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: DisplayPort 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, 13 Jan 2010 02:10:22 -0000 On 2010-01-12 19.16.10 -0600, Robert Noland wrote: > On Tue, 2010-01-12 at 10:19 -0500, Mike Burns wrote: > > Is there any work being done on DisplayPort? Are there any patches > > floating around that I can try? > > On radeon's it should work in X. I don't remember if you need the ddx > driver from git or not though. I'm doubt that intel will work, since > they have totally stopped working on anything that isn't GEM/KMS. > > It isn't entirely clear what you are asking about... but at least the > video hardware is relevant. I had expected dmesg to say something when I plugged the DisplayPort monitor in, or I had at least expected something in dmesg mentioning that it knew there was a DisplayPort device on the system (`dmesg | grep vga | wc -l' gives six results, for example). I had assumed, because of all this, that FreeBSD simply didn't recognize DisplayPort. This laptop has two graphics cards in it; I'm currently using the Intel GM45 which you mention probably doesn't support DisplayPort. The other card (ATI Mobility Radeon 3650 HD) causes the system to hang just after the boot prompt (where it displays the |/-\ animation, but it hangs on the |). So that's where I am now. Moving forward: who do I pester about getting the Intel card to understand DisplayPort? Where do I file a bug about the ATI card preventing the system from booting (and how do I even send useful information besides "it doesn't boot")?. Also, Robert, thank you for responding. This is a Lenovo Thinkpad T500. % uname -a FreeBSD battered.mike-burns.com 8.0-STABLE FreeBSD 8.0-STABLE #2: Thu Dec 24 22:22:54 EST 2009 root@battered.mike-burns.com:/usr/obj/usr/src/sys/BATTERED amd64 -- Mike Burns mike@mike-burns.com http://mike-burns.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 09:01:10 2010 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 829E71065670 for ; Wed, 13 Jan 2010 09:01:10 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 127378FC1A for ; Wed, 13 Jan 2010 09:01:09 +0000 (UTC) Received: by fxm27 with SMTP id 27so317441fxm.3 for ; Wed, 13 Jan 2010 01:00:59 -0800 (PST) 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=vEKRKxV+m+fvWCFJ00tOAUXRL7wQ8eXaQm4/jzCfYbM=; b=PMvOYHKJKYoYSCwrrBmvWYfhkoTAbWvLQxWYByLksgBqMeIj3mKk/f3ACGeN32GR73 jWvWawocv7akrcvMvnHJH458BWwU0q8TmwRB2RwN5D/xKui/Od1T8rT6IopIGB4/Rg6g UDiifMdY4YNLI0W6/xf4RLiZQ0qQGz7FoSBGo= 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=dIrTI4aZtYtWNWFYKDBjUwHfNqEDqSUN5lRZljoEZzOrZITtBbhAVSDvd71fBcAdcn XbVs6yJMgwGkv8Z+KRAlrynaZb/orqqpxNr5zPQcfpgKjg6sjSpUO12fC21idBEvvGwY TCzRwj95uYK1opp64nygl+kBWS985MRSg4iE0= MIME-Version: 1.0 Received: by 10.223.5.87 with SMTP id 23mr11630730fau.87.1263373255264; Wed, 13 Jan 2010 01:00:55 -0800 (PST) In-Reply-To: <20100113020750.GX77044@jack.mike-burns.com> References: <20100112151924.GR77044@jack.mike-burns.com> <1263345370.2486.93.camel@balrog.2hip.net> <20100113020750.GX77044@jack.mike-burns.com> Date: Wed, 13 Jan 2010 11:00:55 +0200 Message-ID: From: George Liaskos To: mike@mike-burns.com, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: DisplayPort 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, 13 Jan 2010 09:01:10 -0000 I have the same thinkpad, ATi works pretty well for me and the DisplayPort gets recognized but i haven't test it so far. I am on 8 stable amd64 too, with mesa from git i get almost 1800 fps on glxgears and i can keep my coffee warm too :p On Wed, Jan 13, 2010 at 4:07 AM, Mike Burns wrote: > On 2010-01-12 19.16.10 -0600, Robert Noland wrote: >> On Tue, 2010-01-12 at 10:19 -0500, Mike Burns wrote: >> > Is there any work being done on DisplayPort? =A0Are there any patches >> > floating around that I can try? >> >> On radeon's it should work in X. =A0I don't remember if you need the ddx >> driver from git or not though. =A0I'm doubt that intel will work, since >> they have totally stopped working on anything that isn't GEM/KMS. >> >> It isn't entirely clear what you are asking about... but at least the >> video hardware is relevant. > > I had expected dmesg to say something when I plugged the DisplayPort moni= tor > in, or I had at least expected something in dmesg mentioning that it knew > there was a DisplayPort device on the system (`dmesg | grep vga | wc -l' > gives six results, for example). =A0I had assumed, because of all this, t= hat > FreeBSD simply didn't recognize DisplayPort. > > This laptop has two graphics cards in it; I'm currently using the Intel G= M45 > which you mention probably doesn't support DisplayPort. =A0The other card= (ATI > Mobility Radeon 3650 HD) causes the system to hang just after the boot > prompt (where it displays the |/-\ animation, but it hangs on the |). > > So that's where I am now. =A0Moving forward: who do I pester about gettin= g the > Intel card to understand DisplayPort? =A0Where do I file a bug about the = ATI > card preventing the system from booting (and how do I even send useful > information besides "it doesn't boot")?. > > Also, Robert, thank you for responding. > > > This is a Lenovo Thinkpad T500. > % uname -a > =A0FreeBSD battered.mike-burns.com 8.0-STABLE FreeBSD 8.0-STABLE #2: > =A0Thu Dec 24 22:22:54 EST 2009 > =A0root@battered.mike-burns.com:/usr/obj/usr/src/sys/BATTERED =A0amd64 > > -- > Mike Burns mike@mike-burns.com http://mike-burns.com > _______________________________________________ > 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 Jan 13 12:28:47 2010 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 8B18F106568F for ; Wed, 13 Jan 2010 12:28:47 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6048FC12 for ; Wed, 13 Jan 2010 12:28:46 +0000 (UTC) Received: from [192.168.1.4] (adsl-1-207-120.bna.bellsouth.net [65.1.207.120]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o0DCSi9G039482 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 07:28:45 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Mike Burns In-Reply-To: <20100113020750.GX77044@jack.mike-burns.com> References: <20100112151924.GR77044@jack.mike-burns.com> <1263345370.2486.93.camel@balrog.2hip.net> <20100113020750.GX77044@jack.mike-burns.com> Content-Type: text/plain Organization: FreeBSD Date: Wed, 13 Jan 2010 06:28:38 -0600 Message-Id: <1263385719.2486.112.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: DisplayPort 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, 13 Jan 2010 12:28:47 -0000 On Tue, 2010-01-12 at 21:07 -0500, Mike Burns wrote: > On 2010-01-12 19.16.10 -0600, Robert Noland wrote: > > On Tue, 2010-01-12 at 10:19 -0500, Mike Burns wrote: > > > Is there any work being done on DisplayPort? Are there any patches > > > floating around that I can try? > > > > On radeon's it should work in X. I don't remember if you need the ddx > > driver from git or not though. I'm doubt that intel will work, since > > they have totally stopped working on anything that isn't GEM/KMS. > > > > It isn't entirely clear what you are asking about... but at least the > > video hardware is relevant. > > I had expected dmesg to say something when I plugged the DisplayPort monitor > in, or I had at least expected something in dmesg mentioning that it knew > there was a DisplayPort device on the system (`dmesg | grep vga | wc -l' > gives six results, for example). I had assumed, because of all this, that > FreeBSD simply didn't recognize DisplayPort. > > This laptop has two graphics cards in it; I'm currently using the Intel GM45 > which you mention probably doesn't support DisplayPort. The other card (ATI > Mobility Radeon 3650 HD) causes the system to hang just after the boot > prompt (where it displays the |/-\ animation, but it hangs on the |). > > So that's where I am now. Moving forward: who do I pester about getting the > Intel card to understand DisplayPort? Where do I file a bug about the ATI > card preventing the system from booting (and how do I even send useful > information besides "it doesn't boot")?. The multiple card case is doomed to failure for the time being. I expect the issue that you are having booting with the radeon is that it is a hybrid setup. I forget the name of it, but it will use the intel chip when it doesn't need power and switch to the radeon when it does. If your bios has options to fully disable the intel chip and only use the radeon, then I suspect that you may have better luck. I've been told that DPs worked on console on radeons, though hot-plug support likely doesn't. When I asked the amd folks about it, they told me that all of the support should be in the X driver now, but I think you might need the driver from git. As for intel. You might get it to work if you updated the DDX (X driver) to the 2.9 series, but you will lose drm support since they dropped support for anything that doesn't have GEM. Who to bug? Well, that would likely be me, but my time is in very short supply right now and I don't actually have any DP hardware. robert. > Also, Robert, thank you for responding. > > > This is a Lenovo Thinkpad T500. > % uname -a > FreeBSD battered.mike-burns.com 8.0-STABLE FreeBSD 8.0-STABLE #2: > Thu Dec 24 22:22:54 EST 2009 > root@battered.mike-burns.com:/usr/obj/usr/src/sys/BATTERED amd64 > -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 18:39:03 2010 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 3972F1065698 for ; Wed, 13 Jan 2010 18:39:03 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id AC2D88FC2B for ; Wed, 13 Jan 2010 18:39:02 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0DIcjue011648; Wed, 13 Jan 2010 19:39:00 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0DIcj3N011647; Wed, 13 Jan 2010 19:38:45 +0100 (CET) (envelope-from olli) Date: Wed, 13 Jan 2010 19:38:45 +0100 (CET) Message-Id: <201001131838.o0DIcj3N011647@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 13 Jan 2010 19:39:01 +0100 (CET) Cc: Subject: bge(4), 5715S, IBM BladeCenter, no carrier 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, 13 Jan 2010 18:39:03 -0000 Hi, I've got problems with the bge(4) interfaces on certain blades installed within an IBM BladeCenter. AFAIK these are fiber PHYs connected to internal fiber-to-copper transceivers inside the blade chassis. Basically, the interfaces are recognized and attached, but I don't get a carrier detected. The hardware is ok, and there is indeed a gigabit switch connected to the ports (under Linux, the carrier is detected and the interfaces work fine). ifconfig output: bge0: flags=9843 metric 0 mtu 1500 options=9b ether 00:21:5e:4c:07:22 inet 10.2.13.42 netmask 0xffffff00 broadcast 10.2.13.255 media: Ethernet 1000baseT (none) status: no carrier Related pciconf -lv entries: pcib3@pci0:21:0:0: class=0x060400 card=0x00000000 chip=0x01031166 rev=0xb5 hdr=0x01 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Broadcom dual gigabit, pci bridge (BCM5715)' class = bridge subclass = PCI-PCI bge0@pci0:22:4:0: class=0x020000 card=0x03671014 chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet (There are more interfaces; I list bge0 only for brevity.) Excerpt from dmesg -v: bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X bge0: bpf attached bge0: Ethernet address: 00:21:5e:4c:07:22 bge0: [MPSAFE] bge0: [ITHREAD] Actually this is an 8-stable snapshot from December, but with if_bge.c and if_bgereg.h from 9-current as of today, because I saw a bunch of commits to HEAD last week. (That's why I'm posting this to -current.) If there's anything else I can do to track this problem down, please let me know. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 18:46:08 2010 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 A2FAF1065670 for ; Wed, 13 Jan 2010 18:46:08 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 78C2A8FC12 for ; Wed, 13 Jan 2010 18:46:08 +0000 (UTC) Received: by pzk15 with SMTP id 15so15073217pzk.3 for ; Wed, 13 Jan 2010 10:45:57 -0800 (PST) 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=+xV4OQOAZQ3dZGimJw78tdZEYZakWlHMRU1SQpui0Eg=; b=YS28/Et49ZYRd7315uJdsCMYpH4rVDRxkAZLSG0d6xLQlk7JtxMkqMlT+SnC3u4Ha+ iP9p8J+FuauyiEhBZ38wnsMqPR8JDPv4xck20IDkuAfm2l3AWGCpH3cbShbGgGcMm5DD uVCRW9CgfD2OPo4DN9MyniVp8sL0/Th6AwBEk= 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=WEi1Tjx8cGw2EDFKyJo9OlN7IVt2MHB0D6pjr0RgyzhVuTD5KzyLrSpn7ZL+Cy9T21 O/5HWy3Z2+bMZgEvLDVKJBdMVq4Up7X+4Dmsl84OAbWVFAgR5C7KRiUaQYrw9Gfi1Faf LeyrVAZLY1Mg11iI1/5A3dhhgZNmmqxXSrrfU= MIME-Version: 1.0 Received: by 10.115.113.14 with SMTP id q14mr306637wam.178.1263408357389; Wed, 13 Jan 2010 10:45:57 -0800 (PST) In-Reply-To: <201001131838.o0DIcj3N011647@lurza.secnetix.de> References: <201001131838.o0DIcj3N011647@lurza.secnetix.de> Date: Wed, 13 Jan 2010 10:45:57 -0800 Message-ID: From: Xin LI To: Oliver Fromme Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier 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, 13 Jan 2010 18:46:08 -0000 On Wed, Jan 13, 2010 at 10:38 AM, Oliver Fromme wr= ote: > Hi, > > I've got problems with the bge(4) interfaces on certain > blades installed within an IBM BladeCenter. =C2=A0AFAIK these > are fiber PHYs connected to internal fiber-to-copper > transceivers inside the blade chassis. > > Basically, the interfaces are recognized and attached, > but I don't get a carrier detected. =C2=A0The hardware is > ok, and there is indeed a gigabit switch connected to > the ports (under Linux, the carrier is detected and the > interfaces work fine). > > ifconfig output: > > bge0: flags=3D9843 metric 0= mtu 1500 > =C2=A0 =C2=A0 =C2=A0 =C2=A0options=3D9b > =C2=A0 =C2=A0 =C2=A0 =C2=A0ether 00:21:5e:4c:07:22 > =C2=A0 =C2=A0 =C2=A0 =C2=A0inet 10.2.13.42 netmask 0xffffff00 broadcast 1= 0.2.13.255 > =C2=A0 =C2=A0 =C2=A0 =C2=A0media: Ethernet 1000baseT (none) > =C2=A0 =C2=A0 =C2=A0 =C2=A0status: no carrier > > Related pciconf -lv entries: > > pcib3@pci0:21:0:0: =C2=A0 =C2=A0 =C2=A0class=3D0x060400 card=3D0x00000000= chip=3D0x01031166 rev=3D0xb5 hdr=3D0x01 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'ServerWorks (Was: Reliance Compute= r Corp)' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'Broadcom dual gigabit, pci bridge = (BCM5715)' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D bridge > =C2=A0 =C2=A0subclass =C2=A0 =3D PCI-PCI > bge0@pci0:22:4:0: =C2=A0 =C2=A0 =C2=A0 class=3D0x020000 card=3D0x03671014= chip=3D0x167914e4 rev=3D0xa3 hdr=3D0x00 > =C2=A0 =C2=A0vendor =C2=A0 =C2=A0 =3D 'Broadcom Corporation' > =C2=A0 =C2=A0device =C2=A0 =C2=A0 =3D 'NetXtreme 5715S Gigabit Ethernet' > =C2=A0 =C2=A0class =C2=A0 =C2=A0 =C2=A0=3D network > =C2=A0 =C2=A0subclass =C2=A0 =3D ethernet > > (There are more interfaces; I list bge0 only for brevity.) > > Excerpt from dmesg -v: > > bge0: m= em 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci2= 2 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > bge0: bpf attached > bge0: Ethernet address: 00:21:5e:4c:07:22 > bge0: [MPSAFE] > bge0: [ITHREAD] > > Actually this is an 8-stable snapshot from December, but > with if_bge.c and if_bgereg.h from 9-current as of today, > because I saw a bunch of commits to HEAD last week. > (That's why I'm posting this to -current.) Which PHY is attached to it? e.g. dmesg | grep miibus? --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 19:02:27 2010 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 B86DB106566B for ; Wed, 13 Jan 2010 19:02:27 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 26E9E8FC12 for ; Wed, 13 Jan 2010 19:02:26 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0DJ2Arm013146; Wed, 13 Jan 2010 20:02:25 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0DJ2AKQ013145; Wed, 13 Jan 2010 20:02:10 +0100 (CET) (envelope-from olli) Date: Wed, 13 Jan 2010 20:02:10 +0100 (CET) Message-Id: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, delphij@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Wed, 13 Jan 2010 20:02:26 +0100 (CET) Cc: Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier 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, 13 Jan 2010 19:02:27 -0000 Xin LI wrote: > On Wed, Jan 13, 2010 at 10:38 AM, Oliver Fromme wrote: > > [...] > > Excerpt from dmesg -v: > > > > bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > > bge0: attempting to allocate 1 MSI vectors (8 supported) > > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > > bge0: using IRQ 256 for MSI > > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > > bge0: bpf attached > > bge0: Ethernet address: 00:21:5e:4c:07:22 > > bge0: [MPSAFE] > > bge0: [ITHREAD] > > > > Actually this is an 8-stable snapshot from December, but > > with if_bge.c and if_bgereg.h from 9-current as of today, > > because I saw a bunch of commits to HEAD last week. > > (That's why I'm posting this to -current.) > > Which PHY is attached to it? > > e.g. dmesg | grep miibus? Hmm. Interestingly, I don't see any PHY in the verbose dmesg output from the 9-current driver. Maybe I should merge the brgphy driver from 9-current to the 8-stable machine, too. I'll try that tomorrow. (But shouldn't there be a warning message if bge attaches without any PHY?) In the (non-verbose) output using the 8-stable driver, the following appears in dmesg: miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto The symptom is the same in either case, though: ifconfig displays "status: no carrier". Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 19:29:47 2010 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 82ADD1065693 for ; Wed, 13 Jan 2010 19:29:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2342E8FC19 for ; Wed, 13 Jan 2010 19:29:46 +0000 (UTC) Received: by qyk4 with SMTP id 4so10938235qyk.7 for ; Wed, 13 Jan 2010 11:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uoQ6Z7K+eXXtPWM7G35Ki0oXVvH710UjFbIS3TdlaPM=; b=xOUyggV7WijzPl1bE38NgiitgxdcNgmwQu46oewm+5XmFB6W60pWLymtlfRpZrNgYc bp9llRuL9AsNA1m0nP1NtHK8TSlT1TpGioiLlYSeJ5xREkoosPxSKiaUSpXOQFiEYP62 x6yvIUn3t/sTix6nvGmXclGOkRQGc09p9HKSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aZGnO8JWI0MczwAb2PaKddreB5US3BQtj0gv0pOsc/Qk7St0DB9k/n1CmON5XI+5Lp uM3GmeILXDjU2lAInrmnLTuDqirRCq3mVUuk9pXt8E8ABkoY9znzth6jURDyfh8Z6cdy zYD2amSql5WCFzWdz+5Jr7+Gzs3RS+2qw1xl0= Received: by 10.224.117.145 with SMTP id r17mr1007257qaq.7.1263410977804; Wed, 13 Jan 2010 11:29:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm4046335qwj.13.2010.01.13.11.29.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 11:29:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 13 Jan 2010 11:28:55 -0800 From: Pyun YongHyeon Date: Wed, 13 Jan 2010 11:28:55 -0800 To: Oliver Fromme Message-ID: <20100113192855.GN1228@michelle.cdnetworks.com> References: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:29:47 -0000 On Wed, Jan 13, 2010 at 08:02:10PM +0100, Oliver Fromme wrote: > Xin LI wrote: > > On Wed, Jan 13, 2010 at 10:38 AM, Oliver Fromme wrote: > > > [...] > > > Excerpt from dmesg -v: > > > > > > bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 > > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > > > bge0: attempting to allocate 1 MSI vectors (8 supported) > > > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > > > bge0: using IRQ 256 for MSI > > > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > > > bge0: bpf attached > > > bge0: Ethernet address: 00:21:5e:4c:07:22 > > > bge0: [MPSAFE] > > > bge0: [ITHREAD] > > > > > > Actually this is an 8-stable snapshot from December, but > > > with if_bge.c and if_bgereg.h from 9-current as of today, > > > because I saw a bunch of commits to HEAD last week. > > > (That's why I'm posting this to -current.) > > > > Which PHY is attached to it? > > > > e.g. dmesg | grep miibus? > > Hmm. Interestingly, I don't see any PHY in the verbose dmesg > output from the 9-current driver. Maybe I should merge the > brgphy driver from 9-current to the 8-stable machine, too. > I'll try that tomorrow. I guess that wouldn't help. > (But shouldn't there be a warning message if bge attaches > without any PHY?) > If bge(4) think it have to directly handle PHY without using mii(4) it wouldn't use mii(4) such that you wouldn't see mii(4) related message. ATM bge(4) directly handles fiber PHYs under certain conditions as em(4) does. em(4) does not use mii(4) at all so that wouldn't be problem on em(4). But bge(4) also uses mii(4) so it only uses mii(4) under certain cases. I don't like that behavior and would like to remove that but it would require a lot of code to properly handle link state changes. I still didn't fully understand the complexity of link state handling used in driver. > In the (non-verbose) output using the 8-stable driver, the > following appears in dmesg: > > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > You said controller has fiber PHY, but brgphy(4) incorrectly think it has copper PHY. Maybe this is the real problem. I'll see what can be done. From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 19:42:56 2010 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 22E4E106566B; Wed, 13 Jan 2010 19:42:56 +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 BEAE28FC13; Wed, 13 Jan 2010 19:42:55 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id B2C731CCD8; Wed, 13 Jan 2010 20:42:54 +0100 (CET) Date: Wed, 13 Jan 2010 20:42:54 +0100 From: Ed Schouten To: current@FreeBSD.org Message-ID: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="51vBd0xT+ONhEBA5" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ports@FreeBSD.org Subject: HEADS UP: gone. All welcome . 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, 13 Jan 2010 19:42:56 -0000 --51vBd0xT+ONhEBA5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, I just made various commits to FreeBSD HEAD to remove our old user accounting database interface (see utmp(5)) and replace it by the POSIX standardized utmpx interface (see getutxent(3)). This means we just got rid of some annoyances that are as old as the FreeBSD project itself: - Hostnames were originally restricted to 16 bytes, which is way too short for your average hostname generated by your ISP, but also for IPv6 addresses, which are at most 32 + 7 =3D 39 characters. - No support for login sessions not related to TTYs, like ppp(8), ftpd(8) sessions. - No support for multiple login sessions on one TTY, for example generated by login(1). I was not able to give us a smooth transition from utmp towards utmpx, simply because our utmp implementation offered almost no utility functions, which means all consumers modify the database files themselves. This means you should probably recompile any applications you're interested in that uses the user accounting database. I realize this may be quite uncomfortable, but we can't always win. [ This information is mainly for port maintainers: ] I've noticed there is some breakage in ports, but it shouldn't be too serious. I've seen cases where an application includes , even though it doesn't use anything provided by that header. In other cases they used fields like UT_NAMESIZE to derive the maximum user name length supported by the system, which is clearly not what this definition was intended for. I've incremented __FreeBSD_version to 900007 to identify the import of utmpx. In case a certain port breaks badly, let me know and I'm willing to take a look at it. Be sure to give it a try and report any issues. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --51vBd0xT+ONhEBA5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktOIj4ACgkQ52SDGA2eCwVEEgCeORwIpMhnpGv0TY0nP4DJHKqa GK8AnjuP9XVV7uPFD9e7prbXKaUaoo7r =nAuS -----END PGP SIGNATURE----- --51vBd0xT+ONhEBA5-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 19:47:37 2010 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 CD86D106566B for ; Wed, 13 Jan 2010 19:47:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE158FC15 for ; Wed, 13 Jan 2010 19:47:37 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so327086qwe.7 for ; Wed, 13 Jan 2010 11:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=t+D9Wkzn+poxdxozrC85pjeY810JT3mE8a4rC9Z1FFA=; b=G9lYb9p1UfBV7ipNbaCA2ouzpr/OsB5uJAxDE/c2YTPnuFHVghZGmRlKBxwWOBJ+sS fK1R+q4UHM7xUssRB9JcaqxTJw/WJTP/OQDJ771BDiUPnjt8UFoRiZHWiK1OThru7nUX 3Wqh/+VE7F8D4HyGiOJXqfMRFjdSgci4fpHq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TQSsUL5nlBx9BdGXsppnhwyLdbVpqGto06o72B+oGaZrqO8ZsLct7h5bMje/E1wW8E QNE2nPJiPWvzBU1BeILhMR30u5/A0BWyNzzTJsmTw+3xiLr6Cf4GSZNln7wyPQGhFiyF J6humnoBEIIxRTtJTSX7+B2/en3beJo+vcwz8= Received: by 10.224.31.6 with SMTP id w6mr15862874qac.34.1263412049566; Wed, 13 Jan 2010 11:47:29 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 21sm1773608qyk.4.2010.01.13.11.47.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 11:47:28 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 13 Jan 2010 11:46:47 -0800 From: Pyun YongHyeon Date: Wed, 13 Jan 2010 11:46:47 -0800 To: Oliver Fromme Message-ID: <20100113194647.GO1228@michelle.cdnetworks.com> References: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> <20100113192855.GN1228@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100113192855.GN1228@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 19:47:38 -0000 On Wed, Jan 13, 2010 at 11:28:55AM -0800, Pyun YongHyeon wrote: > On Wed, Jan 13, 2010 at 08:02:10PM +0100, Oliver Fromme wrote: > > Xin LI wrote: > > > On Wed, Jan 13, 2010 at 10:38 AM, Oliver Fromme wrote: > > > > [...] > > > > Excerpt from dmesg -v: > > > > > > > > bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 > > > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > > > > bge0: attempting to allocate 1 MSI vectors (8 supported) > > > > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > > > > bge0: using IRQ 256 for MSI > > > > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > > > > bge0: bpf attached > > > > bge0: Ethernet address: 00:21:5e:4c:07:22 > > > > bge0: [MPSAFE] > > > > bge0: [ITHREAD] > > > > > > > > Actually this is an 8-stable snapshot from December, but > > > > with if_bge.c and if_bgereg.h from 9-current as of today, > > > > because I saw a bunch of commits to HEAD last week. > > > > (That's why I'm posting this to -current.) > > > > > > Which PHY is attached to it? > > > > > > e.g. dmesg | grep miibus? > > > > Hmm. Interestingly, I don't see any PHY in the verbose dmesg > > output from the 9-current driver. Maybe I should merge the > > brgphy driver from 9-current to the 8-stable machine, too. > > I'll try that tomorrow. > > I guess that wouldn't help. > > > (But shouldn't there be a warning message if bge attaches > > without any PHY?) > > > > If bge(4) think it have to directly handle PHY without using mii(4) > it wouldn't use mii(4) such that you wouldn't see mii(4) related > message. > ATM bge(4) directly handles fiber PHYs under certain conditions as > em(4) does. em(4) does not use mii(4) at all so that wouldn't be > problem on em(4). But bge(4) also uses mii(4) so it only uses > mii(4) under certain cases. I don't like that behavior and would > like to remove that but it would require a lot of code to properly > handle link state changes. I still didn't fully understand the > complexity of link state handling used in driver. > > > In the (non-verbose) output using the 8-stable driver, the > > following appears in dmesg: > > > > miibus0: on bge0 > > brgphy0: PHY 1 on miibus0 > > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > > > > You said controller has fiber PHY, but brgphy(4) incorrectly > think it has copper PHY. Maybe this is the real problem. I'll see > what can be done. Would you show me the output of "devinfo -rv | grep brgphy" and "pciconf -lcv" for your bge(4) controller? From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 23:40:53 2010 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 2D4B8106566C for ; Wed, 13 Jan 2010 23:40:53 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by mx1.freebsd.org (Postfix) with ESMTP id A6B7E8FC13 for ; Wed, 13 Jan 2010 23:40:52 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0DNeeHH018601; Thu, 14 Jan 2010 00:40:40 +0100 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Thu, 14 Jan 2010 00:40:39 +0100 User-Agent: KMail/1.9.10 References: <20100113194254.GR64905@hoeg.nl> In-Reply-To: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201001140040.39973.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: ports@freebsd.org, Ed Schouten , current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 13 Jan 2010 23:40:53 -0000 On Wednesday 13 January 2010 20:42:54 Ed Schouten wrote: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). This means we just got > rid of some annoyances that are as old as the FreeBSD project itself: > > - Hostnames were originally restricted to 16 bytes, which is way too > short for your average hostname generated by your ISP, but also for > IPv6 addresses, which are at most 32 + 7 =3D 39 characters. This is most welcome :-) > > - No support for login sessions not related to TTYs, like ppp(8), > ftpd(8) sessions. > > - No support for multiple login sessions on one TTY, for example > generated by login(1). > > I was not able to give us a smooth transition from utmp towards utmpx, > simply because our utmp implementation offered almost no utility > functions, which means all consumers modify the database files > themselves. This means you should probably recompile any applications > you're interested in that uses the user accounting database. I realize > this may be quite uncomfortable, but we can't always win. > > [ This information is mainly for port maintainers: ] > > I've noticed there is some breakage in ports, but it shouldn't be too > serious. I've seen cases where an application includes , even > though it doesn't use anything provided by that header. In other cases > they used fields like UT_NAMESIZE to derive the maximum user name length > supported by the system, which is clearly not what this definition was > intended for. I've incremented __FreeBSD_version to 900007 to identify > the import of utmpx. In case a certain port breaks badly, let me know > and I'm willing to take a look at it. > > Be sure to give it a try and report any issues. Thanks! =46rom the commit logs I can tell it was a lot of work on something that ma= ny=20 people wouldn't consider a very glamourous or spectacular piece of FreeBSD. So let me just say: Thanks! Cheers, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 23:54:55 2010 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 62BD2106566B; Wed, 13 Jan 2010 23:54:55 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx3.utsp.utwente.nl [130.89.2.14]) by mx1.freebsd.org (Postfix) with ESMTP id DAE198FC14; Wed, 13 Jan 2010 23:54:54 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0DNeeHH018601; Thu, 14 Jan 2010 00:40:40 +0100 From: Pieter de Goeje To: freebsd-current@freebsd.org Date: Thu, 14 Jan 2010 00:40:39 +0100 User-Agent: KMail/1.9.10 References: <20100113194254.GR64905@hoeg.nl> In-Reply-To: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201001140040.39973.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: ports@freebsd.org, Ed Schouten , current@freebsd.org Subject: Re: HEADS UP: gone. All welcome . 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, 13 Jan 2010 23:54:55 -0000 On Wednesday 13 January 2010 20:42:54 Ed Schouten wrote: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). This means we just got > rid of some annoyances that are as old as the FreeBSD project itself: > > - Hostnames were originally restricted to 16 bytes, which is way too > short for your average hostname generated by your ISP, but also for > IPv6 addresses, which are at most 32 + 7 =3D 39 characters. This is most welcome :-) > > - No support for login sessions not related to TTYs, like ppp(8), > ftpd(8) sessions. > > - No support for multiple login sessions on one TTY, for example > generated by login(1). > > I was not able to give us a smooth transition from utmp towards utmpx, > simply because our utmp implementation offered almost no utility > functions, which means all consumers modify the database files > themselves. This means you should probably recompile any applications > you're interested in that uses the user accounting database. I realize > this may be quite uncomfortable, but we can't always win. > > [ This information is mainly for port maintainers: ] > > I've noticed there is some breakage in ports, but it shouldn't be too > serious. I've seen cases where an application includes , even > though it doesn't use anything provided by that header. In other cases > they used fields like UT_NAMESIZE to derive the maximum user name length > supported by the system, which is clearly not what this definition was > intended for. I've incremented __FreeBSD_version to 900007 to identify > the import of utmpx. In case a certain port breaks badly, let me know > and I'm willing to take a look at it. > > Be sure to give it a try and report any issues. Thanks! =46rom the commit logs I can tell it was a lot of work on something that ma= ny=20 people wouldn't consider a very glamourous or spectacular piece of FreeBSD. So let me just say: Thanks! Cheers, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 05:52:52 2010 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 25FA01065670 for ; Thu, 14 Jan 2010 05:52:52 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id BBDAD8FC0C for ; Thu, 14 Jan 2010 05:52:51 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0E5oH8W015177; Thu, 14 Jan 2010 16:20:17 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 14 Jan 2010 16:22:50 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 16:22:50 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 13:52:49 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0E5pUYD081066; Thu, 14 Jan 2010 13:51:30 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0E5pUro081065; Thu, 14 Jan 2010 13:51:30 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 14 Jan 2010 13:51:30 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100114055129.GC80705@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, thierry@FreeBSD.org References: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100113194254.GR64905@hoeg.nl> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 14 Jan 2010 05:52:49.0238 (UTC) FILETIME=[CDA61F60:01CA94DD] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17130.004 X-TM-AS-Result: No--9.784600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: thierry@freebsd.org Subject: Re: HEADS UP: gone. All welcome [SEC=UNCLASSIFIED] 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, 14 Jan 2010 05:52:52 -0000 0n Wed, Jan 13, 2010 at 08:42:54PM +0100, Ed Schouten wrote: >I've noticed there is some breakage in ports, but it shouldn't be too >serious. I've seen cases where an application includes , even >though it doesn't use anything provided by that header. In other cases >they used fields like UT_NAMESIZE to derive the maximum user name length >supported by the system, which is clearly not what this definition was >intended for. I've incremented __FreeBSD_version to 900007 to identify >the import of utmpx. In case a certain port breaks badly, let me know >and I'm willing to take a look at it. > >Be sure to give it a try and report any issues. Thanks! Great stuff ed! Thanks! I thought I would test this with my terminal of choice (x11/rxvt-unicode) and found some breakage (Cc'ing $MAINTAINER). e.g. (FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010) ===> Building for rxvt-unicode-9.07 c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c rxvt.C c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c background.C c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c command.C c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c rxvtfont.C c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c init.C c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage -I/usr/local/include -c logging.C In file included from logging.C:40: ptytty.h:36:4: error: #error cannot build with utmp support - no utmp or utmpx struct found *** Error code 1 Stop in /usr/ports/x11/rxvt-unicode/work/rxvt-unicode-9.07/src. *** Error code 1 Stop in /usr/ports/x11/rxvt-unicode/work/rxvt-unicode-9.07. *** Error code 1 Stop in /usr/ports/x11/rxvt-unicode. *** Error code 1 Stop in /usr/ports/x11/rxvt-unicode. *** Error code 1 Stop in /usr/ports/x11/rxvt-unicode. -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 07:29:16 2010 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 32F791065692 for ; Thu, 14 Jan 2010 07:29:16 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id CB77E8FC23 for ; Thu, 14 Jan 2010 07:29:15 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0E7QfTO027633; Thu, 14 Jan 2010 17:56:41 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 14 Jan 2010 17:59:14 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 17:59:14 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 15:29:13 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0E7RsBn081543; Thu, 14 Jan 2010 15:27:54 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0E7Rs9N081542; Thu, 14 Jan 2010 15:27:54 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 14 Jan 2010 15:27:53 +0800 From: "Wilkinson, Alex" To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201001101437.37269.hselasky@c2i.net> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 14 Jan 2010 07:29:13.0379 (UTC) FILETIME=[4543FF30:01CA94EB] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17130.004 X-TM-AS-Result: No--5.287300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] 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, 14 Jan 2010 07:29:16 -0000 0n Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: >Feedback and bug reports are welcome. Hi Hans, Thanks for your help in getting the needed files from svn etc. video4bsd.ko builds on loads perfectly fine, however usbcam/ulinux fails upon the "make all" with the following errors: cc -O2 -pipe -I/var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca -I/var/tmp/ulinux/libv4l/linux/include -I/var/tmp/ulinux/libv4l/linux -I/var/tmp/ulinux -I/var/tmp/ulinux/dummy -DCONFIG_VIDEO_V4L1_COMPAT -DHAVE_WEBCAMD -include webcamd_global.h -O2 -Wall -fvisibility=hidden -std=gnu99 -fstack-protector -c /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:54:1: warning: "DRIVER_VERSION_NUMBER" redefined In file included from ./webcamd_global.h:93, from :0: /var/tmp/ulinux/libv4l/linux/drivers/media/video/uvc/uvcvideo.h:144:1: warning: this is the location of the previous definition /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'create_urbs': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:560: warning: passing argument 4 of 'usb_buffer_alloc' from incompatible pointer type /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'vidioc_querycap': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1135: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1138: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1143: warning: pointer targets in passing argument 1 of 'snprintf' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1145: warning: pointer targets in passing argument 2 of 'usb_make_path' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'vidioc_g_audio': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1270: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'vidioc_enumaudio': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1280: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'vidioc_enum_input': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:1306: warning: pointer targets in passing argument 1 of 'strncpy' differ in signedness /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c: In function 'gspca_dev_probe': /var/tmp/ulinux/libv4l/linux/drivers/media/video/gspca/gspca.c:2084: error: 'struct usb_device' has no member named 'config' *** Error code 1 Stop in /var/tmp/ulinux. *** Error code 1 Stop in /var/tmp/ulinux. Using: FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010 -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 08:26:12 2010 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 3E604106568B; Thu, 14 Jan 2010 08:26:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 92CEE8FC08; Thu, 14 Jan 2010 08:26:10 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9zKBo0zsyzYA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Sg12pKgaeaoPPRsb7MAA:9 a=GAX9CYN9YC3gAFqZgFgihFT7W5sA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.16) with ESMTPA id 1160707278; Thu, 14 Jan 2010 09:26:09 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 14 Jan 2010 09:24:47 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> In-Reply-To: <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001140924.47454.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, "Wilkinson, Alex" Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] 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, 14 Jan 2010 08:26:12 -0000 On Thursday 14 January 2010 08:27:53 Wilkinson, Alex wrote: > 0n Sun, Jan 10, 2010 at 02:37:37PM +0100, Hans Petter Selasky wrote: > >Feedback and bug reports are welcome. > > Hi Hans, > > Thanks for your help in getting the needed files from svn etc. > > video4bsd.ko builds on loads perfectly fine, however usbcam/ulinux fails > upon the "make all" with the following errors: > Hi, I think Andrew made a fixed port which you can test. The V4L sources has changed since the last couple of days. The build error you are seeing has been fixed in the latest SVN version of my code. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 08:49:55 2010 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 4C552106566C; Thu, 14 Jan 2010 08:49:55 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id A3B278FC14; Thu, 14 Jan 2010 08:49:54 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0E8lJfn009415; Thu, 14 Jan 2010 19:17:19 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id ; Thu, 14 Jan 2010 19:19:53 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 19:19:53 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 16:49:51 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0E8mW5O081830; Thu, 14 Jan 2010 16:48:32 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0E8mVQP081829; Thu, 14 Jan 2010 16:48:31 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 14 Jan 2010 16:48:31 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100114084831.GL80705@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> <201001140924.47454.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <201001140924.47454.hselasky@c2i.net> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 14 Jan 2010 08:49:51.0676 (UTC) FILETIME=[891D87C0:01CA94F6] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17130.004 X-TM-AS-Result: No--4.485200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] 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, 14 Jan 2010 08:49:55 -0000 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: >I think Andrew made a fixed port which you can test. Can you please point me in the direction to this ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 09:03:36 2010 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 1CCDF1065670; Thu, 14 Jan 2010 09:03:36 +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 D29A18FC19; Thu, 14 Jan 2010 09:03:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 56AE57B79C; Thu, 14 Jan 2010 22:03:34 +1300 (NZDT) 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 WpbjYvr8BPtI; Thu, 14 Jan 2010 22:03:30 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Thu, 14 Jan 2010 22:03:30 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A87DB11432; Thu, 14 Jan 2010 22:03:29 +1300 (NZDT) Date: Thu, 14 Jan 2010 22:03:29 +1300 From: Andrew Thompson To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Message-ID: <20100114090329.GH63408@citylink.fud.org.nz> References: <201001101437.37269.hselasky@c2i.net> <20100114072753.GJ80705@stlux503.dsto.defence.gov.au> <201001140924.47454.hselasky@c2i.net> <20100114084831.GL80705@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100114084831.GL80705@stlux503.dsto.defence.gov.au> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing [SEC=UNCLASSIFIED] 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, 14 Jan 2010 09:03:36 -0000 On Thu, Jan 14, 2010 at 04:48:31PM +0800, Wilkinson, Alex wrote: > > 0n Thu, Jan 14, 2010 at 09:24:47AM +0100, Hans Petter Selasky wrote: > > >I think Andrew made a fixed port which you can test. > > Can you please point me in the direction to this ? I'l update the tarball tomorrow and send it out. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 10:08:48 2010 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 E5B1C1065693 for ; Thu, 14 Jan 2010 10:08:48 +0000 (UTC) (envelope-from thierry@FreeBSD.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 210868FC12 for ; Thu, 14 Jan 2010 10:08:46 +0000 (UTC) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 87425CA8C59 for ; Thu, 14 Jan 2010 10:52:28 +0100 (CET) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 76F88D480FC; Thu, 14 Jan 2010 10:52:21 +0100 (CET) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) by smtp5-g21.free.fr (Postfix) with ESMTP id 84F37D480BB; Thu, 14 Jan 2010 10:52:19 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 80) id 5754F11446; Thu, 14 Jan 2010 10:52:12 +0100 (CET) Received: from 192.196.142.22 ([192.196.142.22]) by graf.pompo.net (Horde Framework) with HTTP; Thu, 14 Jan 2010 10:52:12 +0100 Message-ID: <20100114105212.136723nqo4fq0was@graf.pompo.net> X-Priority: 3 (Normal) Date: Thu, 14 Jan 2010 10:52:12 +0100 From: thierry@FreeBSD.org To: "Wilkinson, Alex" References: <20100113194254.GR64905@hoeg.nl> <20100114055129.GC80705@stlux503.dsto.defence.gov.au> In-Reply-To: <20100114055129.GC80705@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) / FreeBSD-8.0 X-Originating-IP: 192.196.142.22 X-Remote-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: gone. All welcome [SEC=UNCLASSIFIED] 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, 14 Jan 2010 10:08:49 -0000 Selon "Wilkinson, Alex" le Jeu 14 jan 06:51:30 2010 : > 0n Wed, Jan 13, 2010 at 08:42:54PM +0100, Ed Schouten wrote: > > >I've noticed there is some breakage in ports, but it shouldn't be too > >serious. I've seen cases where an application includes , even > >though it doesn't use anything provided by that header. In other cases > >they used fields like UT_NAMESIZE to derive the maximum user name length > >supported by the system, which is clearly not what this definition was > >intended for. I've incremented __FreeBSD_version to 900007 to identify > >the import of utmpx. In case a certain port breaks badly, let me know > >and I'm willing to take a look at it. > > > >Be sure to give it a try and report any issues. Thanks! > > Great stuff ed! Thanks! I thought I would test this with my terminal > of choice > (x11/rxvt-unicode) and found some breakage (Cc'ing $MAINTAINER). Thanks for the notification! I'm away ATM, but I'll check it ASAP. Regards, -- Th. Thomas. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 10:37:02 2010 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 1603C1065679; Thu, 14 Jan 2010 10:37:02 +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 CF9D48FC08; Thu, 14 Jan 2010 10:37:01 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 443D11CDBC; Thu, 14 Jan 2010 11:37:01 +0100 (CET) Date: Thu, 14 Jan 2010 11:37:01 +0100 From: Ed Schouten To: freebsd-current@freebsd.org, thierry@FreeBSD.org Message-ID: <20100114103701.GB64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> <20100114055129.GC80705@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdHLGu+Fu6w8YZia" Content-Disposition: inline In-Reply-To: <20100114055129.GC80705@stlux503.dsto.defence.gov.au> User-Agent: Mutt/1.5.20 (2009-06-14) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: HEADS UP: gone. All welcome [SEC=UNCLASSIFIED] 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, 14 Jan 2010 10:37:02 -0000 --CdHLGu+Fu6w8YZia Content-Type: multipart/mixed; boundary="4U4gLV4B6W9z7LAp" Content-Disposition: inline --4U4gLV4B6W9z7LAp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, * Wilkinson, Alex wrote: > Great stuff ed! Thanks! I thought I would test this with my terminal of c= hoice > (x11/rxvt-unicode) and found some breakage (Cc'ing $MAINTAINER). >=20 > e.g. >=20 > (FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010) >=20 > =3D=3D=3D> Building for rxvt-unicode-9.07 > > c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include > -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2= -pipe > -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libA= fterImage > -I/usr/local/include -c logging.C > In file included from logging.C:40: > ptytty.h:36:4: error: #error cannot build with utmp support - no utmp = or utmpx > struct found The attached patch should fix it. --=20 Ed Schouten WWW: http://80386.nl/ --4U4gLV4B6W9z7LAp-- --CdHLGu+Fu6w8YZia Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktO880ACgkQ52SDGA2eCwVRsQCfZa5A7bgKtQ8TP4QVZ5ljgx7/ yugAnj0KW/wRo+20M3nC+z6cfttJuI7a =nycV -----END PGP SIGNATURE----- --CdHLGu+Fu6w8YZia-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 11:58:46 2010 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 3379B106566B for ; Thu, 14 Jan 2010 11:58:46 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id BF31C8FC15 for ; Thu, 14 Jan 2010 11:58:45 +0000 (UTC) Received: by ewy3 with SMTP id 3so767488ewy.13 for ; Thu, 14 Jan 2010 03:58:39 -0800 (PST) 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=EoXIFdlNYURicZqv8vrc5mjDe1xfdovrKAMH3PU/YZQ=; b=YsQXC2uiY8VAmh2qEa1T4xc2kP6OPlrOu6UxteB/xHvT4aRKfBvpBCKx5mnQ3peruG 3J5ba4RaXP2zoP4V+RIrpZApr9vmgqqG63c6a/2S8vqf0pod0kaeMB0LM2GW2QwA6fdc H3252RnoloFTiv4aFnMR52sIRzFxnzKqNPeIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QS5wqfk56QydOI4hUPZ/f2uGo/reMY+oR6DcK4draM03RJTN9nUjIRtkyR2Vfg+leL VTsInJVlElsGxh9QzoTyQ5sXVIRt162O8+JlRdWqCRjVei4cGwqSzRK4p7X2F8++ksjZ qZLxvkgJr+Ymw2CkgWabYWyN/TB0tqWLYoIBo= MIME-Version: 1.0 Received: by 10.216.90.79 with SMTP id d57mr213549wef.117.1263468623391; Thu, 14 Jan 2010 03:30:23 -0800 (PST) Date: Thu, 14 Jan 2010 06:30:23 -0500 Message-ID: From: Aryeh Friedman To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Subject: very bizare behaviour from ssh/rlogin/rsh/telnet 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, 14 Jan 2010 11:58:46 -0000 When I connect from my machine from home (FreeBSD aryeh-desktop.istudentunion.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Jan 14 05:54:28 EST 2010 root@aryeh-desktop.istudentunion.com:/usr/obj/home/src/sys/GENERIC i386) to one of the servers at work (FreeBSD jack.istudentunion.com 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Jan 7 02:15:16 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC i386) with ssh/rlogin/rsh/telnet on some files vi (vim) simply locks the entire terminal/console (tried physical console [no GUI or other non-termcap based getty device)/xterm/Terminal [xfce4]) completely (does not respond any sort of typing meant for the remote machine [does allow ~. and ^] escapes to exit the above mentioned commands]) this also happens when I run certain commands that are avaible in devel/aegis... This *DOES NOT* occur with any other network/scoket connections *AND* if I use putty in windows7 to the same remote machine there is no freeze up... This just all the sudden happened (it was working until a hour or so ago)... I have tried the following fixes: * Reboot both machines * Tried both console and XOrg based connection methods * Connected to the remote machine with ftp, browser etc. and copied/viewed the files and commands in question (second item only as much as possible without a direct connection) * Tried different OS on the local side (same physical machine [dual boot]) * Rm'ed my user account and remade it (make sure there is no weird configs) * csup'ed the most recent -CURRENT (as of about 45 mins ago) and did a make DESTDIR=/ world kernel with no errors (have done the same on the local machine many times) and mergemaster -aui then reboot Final note: As far I can tell I did nothing that would of caused this (it happened all sudden during a remote connection in Terminal with no other programs open) From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 12:12:14 2010 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 B24811065670 for ; Thu, 14 Jan 2010 12:12:14 +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 771B08FC0C for ; Thu, 14 Jan 2010 12:12:14 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id E33651CCD8; Thu, 14 Jan 2010 13:12:13 +0100 (CET) Resent-From: Ed Schouten Resent-Date: Thu, 14 Jan 2010 13:12:13 +0100 Resent-Message-ID: <20100114121213.GE64905@hoeg.nl> Resent-To: current@FreeBSD.org Date: Thu, 14 Jan 2010 13:08:28 +0100 From: Ed Schouten To: "Wilkinson, Alex" Message-ID: <20100114120828.GD64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> <20100114055129.GC80705@stlux503.dsto.defence.gov.au> <20100114103701.GB64905@hoeg.nl> <20100114114813.GN80705@stlux503.dsto.defence.gov.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tDRV7uPxdQFXdprF" Content-Disposition: inline In-Reply-To: <20100114114813.GN80705@stlux503.dsto.defence.gov.au> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: HEADS UP: gone. All welcome [SEC=UNCLASSIFIED] 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, 14 Jan 2010 12:12:14 -0000 --tDRV7uPxdQFXdprF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Alex, * Wilkinson, Alex wrote: > I dont think there was any attachment ed ? There was, but it seems Mailman ate it. I've included it inline: %%% --- src/ptytty.h +++ src/ptytty.h @@ -16,7 +16,7 @@ #endif =20 #if UTMP_SUPPORT -# if !defined(UTMPX_FILE) || !defined(HAVE_STRUCT_UTMPX) || defined(__GLIB= C__) +# if !defined(HAVE_STRUCT_UTMPX) || defined(__GLIBC__) # undef HAVE_UTMPX_H # undef HAVE_STRUCT_UTMPX # endif %%% --=20 Ed Schouten WWW: http://80386.nl/ --tDRV7uPxdQFXdprF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktPCTsACgkQ52SDGA2eCwWCpQCdGJJKtu2wpnOJjejBDTQLSdX+ 1UYAn2jRKmxghnj8ieR5AD0YDcyJJsUF =BttH -----END PGP SIGNATURE----- --tDRV7uPxdQFXdprF-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 12:23:38 2010 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 CECF610656C3 for ; Thu, 14 Jan 2010 12:23:38 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 310868FC20 for ; Thu, 14 Jan 2010 12:23:37 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0ECL2KU012543 for ; Thu, 14 Jan 2010 22:51:03 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Thu, 14 Jan 2010 22:53:36 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 22:53:36 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 20:23:35 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0ECMFh8097681 for ; Thu, 14 Jan 2010 20:22:15 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0ECMF48097680 for freebsd-current@freebsd.org; Thu, 14 Jan 2010 20:22:15 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 14 Jan 2010 20:22:15 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100114122215.GA97653@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20100113194254.GR64905@hoeg.nl> <20100114055129.GC80705@stlux503.dsto.defence.gov.au> <20100114103701.GB64905@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20100114103701.GB64905@hoeg.nl> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 14 Jan 2010 12:23:35.0661 (UTC) FILETIME=[64CE59D0:01CA9514] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17130.007 X-TM-AS-Result: No--12.541300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: gone. All welcome [SEC=UNCLASSIFIED] 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, 14 Jan 2010 12:23:38 -0000 0n Thu, Jan 14, 2010 at 11:37:01AM +0100, Ed Schouten wrote: >Hi all, > >* Wilkinson, Alex wrote: >> Great stuff ed! Thanks! I thought I would test this with my terminal of choice >> (x11/rxvt-unicode) and found some breakage (Cc'ing $MAINTAINER). >> >> e.g. >> >> (FreeBSD 9.0-CURRENT #0 r202270: Thu Jan 14 11:20:04 WST 2010) >> >> ===> Building for rxvt-unicode-9.07 >> >> c++ -I.. -I. -I. -I./../libev -DHAVE_CONFIG_H -I/usr/local/include >> -D_THREAD_SAFE -I/usr/local/include -I/usr/local/include/freetype2 -O2 -pipe >> -fno-strict-aliasing -w -I/usr/local/include -I/usr/local/include/libAfterImage >> -I/usr/local/include -c logging.C >> In file included from logging.C:40: >> ptytty.h:36:4: error: #error cannot build with utmp support - no utmp or utmpx >> struct found > >The attached patch should fix it. Great! Patch fixed this issue. Port builds fine again. Thanks! -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 13:37:04 2010 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 54DF21065672 for ; Thu, 14 Jan 2010 13:37:04 +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 829548FC15 for ; Thu, 14 Jan 2010 13:37:02 +0000 (UTC) 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 PAA09038; Thu, 14 Jan 2010 15:36:57 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B4F1DF8.1040603@icyb.net.ua> Date: Thu, 14 Jan 2010 15:36:56 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Ed Schouten References: <20100113194254.GR64905@hoeg.nl> In-Reply-To: <20100113194254.GR64905@hoeg.nl> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . 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, 14 Jan 2010 13:37:04 -0000 on 13/01/2010 21:42 Ed Schouten said the following: > Hello everyone, > > I just made various commits to FreeBSD HEAD to remove our old user > accounting database interface (see utmp(5)) and replace it by the POSIX > standardized utmpx interface (see getutxent(3)). Ed, please pardon my ignorance but will I have to do anything with utmp/wtmp/etc files after upgrading my system to the new code? Will lasr still correctly show logins that happened before the upgrade? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 13:43:14 2010 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 D007A1065672 for ; Thu, 14 Jan 2010 13:43:14 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 328028FC1A for ; Thu, 14 Jan 2010 13:43:13 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0EDedLl022981 for ; Fri, 15 Jan 2010 00:10:39 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Fri, 15 Jan 2010 00:13:13 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jan 2010 00:13:12 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 21:43:11 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0EDfptE098221 for ; Thu, 14 Jan 2010 21:41:51 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0EDfpnf098220 for freebsd-current@freebsd.org; Thu, 14 Jan 2010 21:41:51 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 14 Jan 2010 21:41:51 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100114134151.GA98196@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20100113194254.GR64905@hoeg.nl> <4B4F1DF8.1040603@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4B4F1DF8.1040603@icyb.net.ua> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 14 Jan 2010 13:43:11.0692 (UTC) FILETIME=[838AD8C0:01CA951F] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17130.007 X-TM-AS-Result: No--4.051100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: HEADS UP: gone. All welcome . [SEC=UNCLASSIFIED] 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, 14 Jan 2010 13:43:14 -0000 0n Thu, Jan 14, 2010 at 03:36:56PM +0200, Andriy Gapon wrote: >on 13/01/2010 21:42 Ed Schouten said the following: >> Hello everyone, >> >> I just made various commits to FreeBSD HEAD to remove our old user >> accounting database interface (see utmp(5)) and replace it by the POSIX >> standardized utmpx interface (see getutxent(3)). > >Ed, > >please pardon my ignorance but will I have to do anything with utmp/wtmp/etc files >after upgrading my system to the new code? >Will lasr still correctly show logins that happened before the upgrade? seems to still work: [FreeBSD 9.0-CURRENT #0 r202270:] #last root pts/5 :0 Thu 14 Jan 20:20 - 20:20 (00:00) user pts/3 hostname.dsto.defence. Thu 14 Jan 20:14 still logged in user ttyv1 Thu 14 Jan 12:40 still logged in boot time Thu 14 Jan 12:40 -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 14:01:34 2010 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 43BF9106566B; Thu, 14 Jan 2010 14:01:34 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 540D88FC1D; Thu, 14 Jan 2010 14:01:32 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0EE11gf016991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 23:01:12 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 14 Jan 2010 23:01:01 +0900 Message-ID: From: Hajimu UMEMOTO To: Ed Schouten In-Reply-To: <20100113194254.GR64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 14 Jan 2010 23:01:12 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: HEADS UP: gone. All welcome . 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, 14 Jan 2010 14:01:34 -0000 Hi, >>>>> On Wed, 13 Jan 2010 20:42:54 +0100 >>>>> Ed Schouten said: ed> I just made various commits to FreeBSD HEAD to remove our old user ed> accounting database interface (see utmp(5)) and replace it by the POSIX ed> standardized utmpx interface (see getutxent(3)). This means we just got ed> rid of some annoyances that are as old as the FreeBSD project itself: Thank you for a great job! ed> - Hostnames were originally restricted to 16 bytes, which is way too ed> short for your average hostname generated by your ISP, but also for ed> IPv6 addresses, which are at most 32 + 7 = 39 characters. At last, we can know the host where login from using IPv6. Unfortunately, w(1) shows no entry at 2nd login. It seems logout breaks utx.lastlogin and utx.active. Any idea? ume@ameno:~% ssh yoshino.mahoroba.org Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 9.0-CURRENT (YOSHINO) #0: Thu Jan 14 16:03:58 JST 2010 Welcome to FreeBSD! 10:48PM up 27 mins, 1 user, load averages: 0.07, 0.28, 0.39 ume@yoshino:~% w 10:48PM up 27 mins, 1 user, load averages: 0.07, 0.28, 0.39 USER TTY FROM LOGIN@ IDLE WHAT ume pts/0 ameno.mahoroba.org 10:48PM - w ume@yoshino:~% ll /var/run/utx.active /var/log/utx.l* -rw-r--r-- 1 root wheel 197 Jan 14 22:48 /var/log/utx.lastlogin -rw-r--r-- 1 root wheel 89 Jan 14 22:48 /var/log/utx.log -rw-r--r-- 1 root wheel 197 Jan 14 22:48 /var/run/utx.active ume@yoshino:~% logout Connection to yoshino.mahoroba.org closed. ume@ameno:~% ssh yoshino.mahoroba.org Last login: Thu Jan 14 22:48:56 2010 from ameno.mahoroba.org Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 9.0-CURRENT (YOSHINO) #0: Thu Jan 14 16:03:58 JST 2010 Welcome to FreeBSD! 10:49PM up 27 mins, 0 users, load averages: 0.05, 0.26, 0.38 ume@yoshino:~% w 10:49PM up 27 mins, 0 users, load averages: 0.05, 0.26, 0.38 USER TTY FROM LOGIN@ IDLE WHAT ume@yoshino:~% ll /var/run/utx.active /var/log/utx.l* -rw-r--r-- 1 root wheel 4294967493 Jan 14 22:49 /var/log/utx.lastlogin -rw-r--r-- 1 root wheel 201 Jan 14 22:49 /var/log/utx.log -rw-r--r-- 1 root wheel 4294967493 Jan 14 22:49 /var/run/utx.active Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 15:24:41 2010 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 9871E106566B for ; Thu, 14 Jan 2010 15:24: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 5DD4A8FC1A for ; Thu, 14 Jan 2010 15:24:41 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id AE7931CDBC; Thu, 14 Jan 2010 16:24:40 +0100 (CET) Date: Thu, 14 Jan 2010 16:24:40 +0100 From: Ed Schouten To: Andriy Gapon Message-ID: <20100114152440.GG64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> <4B4F1DF8.1040603@icyb.net.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MyoRluM0kqF8ITrS" Content-Disposition: inline In-Reply-To: <4B4F1DF8.1040603@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: HEADS UP: gone. All welcome . 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, 14 Jan 2010 15:24:41 -0000 --MyoRluM0kqF8ITrS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Andriy Gapon wrote: > please pardon my ignorance but will I have to do anything with utmp/wtmp/= etc files > after upgrading my system to the new code? > Will lasr still correctly show logins that happened before the upgrade? Right now it's not handled at all. We probably shouldn't care about utmp and lastlog. As long as an administrator can analyze the wtmp files, it should be fine. I am planning on adding a tool, probably called wtmpcvt(1), which will allow you to convert it to the new format. Then you can pass it to last(1)'s -f. --=20 Ed Schouten WWW: http://80386.nl/ --MyoRluM0kqF8ITrS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktPNzgACgkQ52SDGA2eCwUUMwCdEpOWsrSnnhEzWYZGrVxChneW 9koAnRm5qa41L0PE4nhDREWWxvuIus6j =fD41 -----END PGP SIGNATURE----- --MyoRluM0kqF8ITrS-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 15:57:58 2010 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 F2AE41065672 for ; Thu, 14 Jan 2010 15:57:58 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id DBDF18FC0A for ; Thu, 14 Jan 2010 15:57:58 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 476D7845A9; Thu, 14 Jan 2010 10:57:57 -0500 (EST) Date: Thu, 14 Jan 2010 10:57:55 -0500 From: Jeff Blank To: freebsd-current@freebsd.org Message-ID: <20100114155755.GA77799@mr-happy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: make delete-old fails when removing catpages 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, 14 Jan 2010 15:57:59 -0000 Hi, 9-CURRENT, csups around 2000 UTC yesterday and 0100 UTC today, fails when removing some catpages during 'make delete-old'. Output below is from after the initial failure, and context had left my scrollback buffer, but the first file that failed was /usr/share/man/cat1/rcp.1.gz. I removed it by hand with no issues and ran again: ========== # make delete-old >>> Removing old files (only deletes safe to delete libs) remove /usr/share/man/cat1/ipftest.1.gz? *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # rm /usr/share/man/cat1/ipftest.1.gz # make delete-old >>> Removing old files (only deletes safe to delete libs) remove /usr/share/man/cat1/ipresend.1.gz? *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ========== etc. At the remove prompt, there's about a half-second pause before the first '*** Error code 1'. As you can see, I'm not redirecting/piping to make's stdin. I can open a fresh xterm, ssh into the host and delete-old again, same results. Continuing on, if I rm /usr/share/man/cat[13]/* and re-run delete-old, I stop getting errors for some files, but it still fails to remove anything: ========== # make delete-old >>> Removing old files (only deletes safe to delete libs) remove /usr/share/man/cat4/ipf.4.gz? remove /usr/share/man/cat5/ipf.5.gz? remove /usr/share/man/cat5/utmp.5.gz? remove /usr/share/man/cat8/rlogind.8.gz? remove /usr/share/man/cat8/ipf.8.gz? remove /usr/share/man/cat8/bcmfw.8.gz? remove /usr/share/man/cat8/chkprintcap.8.gz? *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ========== All filenames are printed at once as above, and then there's the brief pause again before the error. There are no issues removing libraries via the delete-old-libs target. src.conf: WITHOUT_ATM=true WITHOUT_BLUETOOTH=true WITHOUT_GPIB=true WITHOUT_HTML=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_LPR=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_OBJC=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_SENDMAIL=true WITHOUT_SLIP=true WITHOUT_WIRELESS=true No issues with delete-old and this src.conf under 8-STABLE. This is a new install and my first foray into 9-CURRENT, so I don't know how long this problem has existed. Install was from the 201001 snapshot DVD image. This is a VirtualBox 3.1.2 guest (FreeBSD 8-STABLE host), but that shouldn't be related, should it? (I don't have hardware available for testing 9-CURRENT, in any case.) Any ideas? Other info I need to supply? thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 16:04:50 2010 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 E1134106566B for ; Thu, 14 Jan 2010 16:04:50 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 22B498FC16 for ; Thu, 14 Jan 2010 16:04:49 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0EG4VPG067124; Thu, 14 Jan 2010 17:04:47 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0EG4Vx8067123; Thu, 14 Jan 2010 17:04:31 +0100 (CET) (envelope-from olli) Date: Thu, 14 Jan 2010 17:04:31 +0100 (CET) Message-Id: <201001141604.o0EG4Vx8067123@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100113194647.GO1228@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 14 Jan 2010 17:04:48 +0100 (CET) Cc: Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier 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, 14 Jan 2010 16:04:51 -0000 Pyun YongHyeon wrote: > On Wed, Jan 13, 2010 at 11:28:55AM -0800, Pyun YongHyeon wrote: > > On Wed, Jan 13, 2010 at 08:02:10PM +0100, Oliver Fromme wrote: > > > Hmm. Interestingly, I don't see any PHY in the verbose dmesg > > > output from the 9-current driver. Maybe I should merge the > > > brgphy driver from 9-current to the 8-stable machine, too. > > > I'll try that tomorrow. > > > > I guess that wouldn't help. You were right, it didn't help. > > If bge(4) think it have to directly handle PHY without using mii(4) > > it wouldn't use mii(4) such that you wouldn't see mii(4) related > > message. > > ATM bge(4) directly handles fiber PHYs under certain conditions as > > em(4) does. em(4) does not use mii(4) at all so that wouldn't be > > problem on em(4). But bge(4) also uses mii(4) so it only uses > > mii(4) under certain cases. I don't like that behavior and would > > like to remove that but it would require a lot of code to properly > > handle link state changes. I still didn't fully understand the > > complexity of link state handling used in driver. > > [...] > > You said controller has fiber PHY, but brgphy(4) incorrectly > > think it has copper PHY. Maybe this is the real problem. I'll see > > what can be done. > > Would you show me the output of "devinfo -rv | grep brgphy" and > "pciconf -lcv" for your bge(4) controller? Ok, I've got more information. As a reminder, this is a 8-stable snapshot from December, with if_bge and brgphy from 9-current as of today. (In fact I just copied the whole mii directory, not just brgphy.) The result is that there is no brgphy found at all, so devinfo doesn't list it either. Next thing I did was to apply the patch from PR 122551 because the problem description sounds somewhat similar to what I have (though not identical). The result: Now a brgphy is found, but it lists only copper media, not 1000baseSX. I'm pretty sure this is a fiber PHY, though. So, still "no carrier". :-( Here's the information you requested (with the patch from PR 122551) ... devinfo -rv: bge0 pnpinfo vendor=0x14e4 device=0x1679 subvendor=0x1014 subdevice=0x0367 class=0x020000 at slot=4 function=0 Interrupt request lines: 256 I/O memory addresses: 0x97a00000-0x97a0ffff miibus0 brgphy0 pnpinfo oui=0x818 model=0x34 rev=0x0 at phyno=1 pciconf -lcv: bge0@pci0:22:4:0: class=0x020000 card=0x03671014 chip=0x167914e4 rev=0xa3 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme 5715S Gigabit Ethernet' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message dmesg (verbose boot): bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 56 bge0: using IRQ 256 for MSI bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0034, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:21:5e:4c:07:22 bge0: [MPSAFE] bge0: [ITHREAD] ifconfig -m: bge0: flags=8843 metric 0 mtu 1500 options=9b capabilities=9b ether 00:21:5e:4c:07:22 inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.255 media: Ethernet autoselect (none) status: no carrier supported media: media autoselect media 1000baseT mediaopt full-duplex media 1000baseT media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none Actually, the blade (its an IBM BladeCenter HS22) contains four NICs: two bge(4) and two bce(4). All of them are fiber (1000baseSX). None of them work. I can open a new thread for the bce(4) issue, but first I would prefer to get the bge(4) interfaces working. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 16:56:07 2010 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 82E7B1065676; Thu, 14 Jan 2010 16:56:07 +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 217FC8FC16; Thu, 14 Jan 2010 16:56:07 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 58A3A1CCD8; Thu, 14 Jan 2010 17:56:06 +0100 (CET) Date: Thu, 14 Jan 2010 17:56:06 +0100 From: Ed Schouten To: Hajimu UMEMOTO Message-ID: <20100114165606.GH64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="79VAcntGpWtJGd4r" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: HEADS UP: gone. All welcome . 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, 14 Jan 2010 16:56:07 -0000 --79VAcntGpWtJGd4r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, * Hajimu UMEMOTO wrote: > ume@yoshino:~% ll /var/run/utx.active /var/log/utx.l* > -rw-r--r-- 1 root wheel 4294967493 Jan 14 22:49 /var/log/utx.lastlogin > -rw-r--r-- 1 root wheel 201 Jan 14 22:49 /var/log/utx.log > -rw-r--r-- 1 root wheel 4294967493 Jan 14 22:49 /var/run/utx.active Just to make sure everyone else is informed: I fixed this bug earlier today. It turned out I forgot to add a cast somewhere, which caused the file descriptor to be moved by 2^32 - 197 bytes forward, instead of 197 backward. It only occurs on 32 bit platforms. If you rebuild and reinstall world, the files should be automatically truncated upon reboot, because the utmpx code notices this form of file corruption. --=20 Ed Schouten WWW: http://80386.nl/ --79VAcntGpWtJGd4r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktPTKYACgkQ52SDGA2eCwXpeACfcLl+zQpy+44O+i81PdxqRZwp Xt4AniM2n7r1AIGnjE5AIRSzX7+ovp8x =nWUo -----END PGP SIGNATURE----- --79VAcntGpWtJGd4r-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 17:03:24 2010 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 04D7C106566B; Thu, 14 Jan 2010 17:03:24 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 67F0E8FC14; Thu, 14 Jan 2010 17:03:23 +0000 (UTC) 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 o0EH3HAW080046; Thu, 14 Jan 2010 11:03:17 -0600 (CST) (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=G0qPwtMumZiU5Eh6XZSCHaa1x/nANWxaynCuGe8iarG12Ijf8WlUZ2jhsByNF4/is ef5gQeJdhpnFawTHEIfvef0ACVER/ly4MVOkN88cT5XwJ8YBCCzVGKqtiIinMVaVF3m KuxLic6/v1P49vB2afCvAKpCu2dYERpDAaDE/bA= Message-ID: <4B4F4E55.1050906@jrv.org> Date: Thu, 14 Jan 2010 11:03:17 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Hans Petter Selasky References: <20091002150931.K35591@pooker.samsco.org> <200911050922.10205.hselasky@c2i.net> <4AFCB277.5070306@delphij.net> <200911130909.30828.hselasky@c2i.net> In-Reply-To: <200911130909.30828.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marcel Moolenaar , Alexander Motin Subject: Re: Fix for USB media not found at boot 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, 14 Jan 2010 17:03:24 -0000 Hans Petter Selasky wrote: > The changeset in question has not been committed to mainstream. > > Scott Long is working on an improved solution. Please coordinate with him. Has anything happened with the general case? A friend of mine reported to me a regression between 8.0-RELEASE and 8-STABLE that turns out to be this issue with SATA port multipliers. I have the same problem, except that I need to further wait for GEOM to make visible a gmirror made of two slow devices (behind SATA port multiplier). From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 17:48:16 2010 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 AF3721065670 for ; Thu, 14 Jan 2010 17:48:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE4C8FC22 for ; Thu, 14 Jan 2010 17:48:15 +0000 (UTC) Received: by qyk4 with SMTP id 4so11848841qyk.7 for ; Thu, 14 Jan 2010 09:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=mQpDYMEISCwsF+3x1/+Y6d4YF1aKH63r63ijFTrBRnE=; b=othow6ypM5yf3sg4WSCAL7eIhwI9LcenimrUPpqjNO10gsDaufosX3LDBfDaD9Z92S 6/yQ+Ud6lOicr80ZtACm7wIkwvtRuHjQXtjYufgHDPnSB2Ay9+n5Su3QGVIwJnOpsmtj kDJ55y6VCX+1jUJF1rAJsvrWSVXjtoTrVIvkY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Ol8TJp0HRWZef2iKc4WF+H05Y7OpJ59I3qL7WACKPyrpPiNWDCM0ABnYH3wqvoNmfP ySvxVRT/au22w1ANiU9BB7m95AHTJvLJahncS2p4H1R9klBBHY0SusmleCpY3M/BeHt3 lWQZ15cQfSfEJ+FVTGgbNajzqWAUFfuy2oAMk= Received: by 10.224.86.199 with SMTP id t7mr1069765qal.142.1263491284719; Thu, 14 Jan 2010 09:48:04 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 2sm2347575qwi.57.2010.01.14.09.48.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 09:48:03 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 09:47:23 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 09:47:23 -0800 To: Oliver Fromme Message-ID: <20100114174723.GV1228@michelle.cdnetworks.com> References: <20100113194647.GO1228@michelle.cdnetworks.com> <201001141604.o0EG4Vx8067123@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FEz7ebHBGB6b2e8X" Content-Disposition: inline In-Reply-To: <201001141604.o0EG4Vx8067123@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 17:48:16 -0000 --FEz7ebHBGB6b2e8X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 14, 2010 at 05:04:31PM +0100, Oliver Fromme wrote: > Pyun YongHyeon wrote: > > On Wed, Jan 13, 2010 at 11:28:55AM -0800, Pyun YongHyeon wrote: > > > On Wed, Jan 13, 2010 at 08:02:10PM +0100, Oliver Fromme wrote: > > > > Hmm. Interestingly, I don't see any PHY in the verbose dmesg > > > > output from the 9-current driver. Maybe I should merge the > > > > brgphy driver from 9-current to the 8-stable machine, too. > > > > I'll try that tomorrow. > > > > > > I guess that wouldn't help. > > You were right, it didn't help. > > > > If bge(4) think it have to directly handle PHY without using mii(4) > > > it wouldn't use mii(4) such that you wouldn't see mii(4) related > > > message. > > > ATM bge(4) directly handles fiber PHYs under certain conditions as > > > em(4) does. em(4) does not use mii(4) at all so that wouldn't be > > > problem on em(4). But bge(4) also uses mii(4) so it only uses > > > mii(4) under certain cases. I don't like that behavior and would > > > like to remove that but it would require a lot of code to properly > > > handle link state changes. I still didn't fully understand the > > > complexity of link state handling used in driver. > > > [...] > > > You said controller has fiber PHY, but brgphy(4) incorrectly > > > think it has copper PHY. Maybe this is the real problem. I'll see > > > what can be done. > > > > Would you show me the output of "devinfo -rv | grep brgphy" and > > "pciconf -lcv" for your bge(4) controller? > > Ok, I've got more information. > > As a reminder, this is a 8-stable snapshot from December, > with if_bge and brgphy from 9-current as of today. > (In fact I just copied the whole mii directory, not just > brgphy.) > > The result is that there is no brgphy found at all, so > devinfo doesn't list it either. > > Next thing I did was to apply the patch from PR 122551 > because the problem description sounds somewhat similar > to what I have (though not identical). > > The result: Now a brgphy is found, but it lists only > copper media, not 1000baseSX. I'm pretty sure this is > a fiber PHY, though. So, still "no carrier". :-( > > Here's the information you requested (with the patch > from PR 122551) ... > > devinfo -rv: > > bge0 pnpinfo vendor=0x14e4 device=0x1679 subvendor=0x1014 subdevice=0x0367 class=0x020000 at slot=4 function=0 > Interrupt request lines: > 256 > I/O memory addresses: > 0x97a00000-0x97a0ffff > miibus0 > brgphy0 pnpinfo oui=0x818 model=0x34 rev=0x0 at phyno=1 > > pciconf -lcv: > > bge0@pci0:22:4:0: class=0x020000 card=0x03671014 chip=0x167914e4 rev=0xa3 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme 5715S Gigabit Ethernet' > class = network > subclass = ethernet > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message > > dmesg (verbose boot): > > bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > bge0: using IRQ 256 for MSI > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x000818, model 0x0034, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: bpf attached > bge0: Ethernet address: 00:21:5e:4c:07:22 > bge0: [MPSAFE] > bge0: [ITHREAD] > > ifconfig -m: > > bge0: flags=8843 metric 0 mtu 1500 > options=9b > capabilities=9b > ether 00:21:5e:4c:07:22 > inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.255 > media: Ethernet autoselect (none) > status: no carrier > supported media: > media autoselect > media 1000baseT mediaopt full-duplex > media 1000baseT > media 100baseTX mediaopt full-duplex > media 100baseTX > media 10baseT/UTP mediaopt full-duplex > media 10baseT/UTP > media none > Thanks for the information. Would you try attached patch? If the patch still reports 10/100/1000 copper PHY, try adding 'sc->mii_flags |= MIIF_HAVEFIBER' to force setting MIIF_HAVEFIBER flag in brgphy.c:brgphy_attach. > Actually, the blade (its an IBM BladeCenter HS22) contains > four NICs: two bge(4) and two bce(4). All of them are > fiber (1000baseSX). None of them work. I can open a new > thread for the bce(4) issue, but first I would prefer to > get the bge(4) interfaces working. > Ok, let's fix bge(4) first. --FEz7ebHBGB6b2e8X Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.BCM5715S.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 202268) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -2603,6 +2603,7 @@ #define BGE_FLAG_JUMBO 0x00000002 #define BGE_FLAG_WIRESPEED 0x00000004 #define BGE_FLAG_EADDR 0x00000008 +#define BGE_FLAG_MII_SERDES 0x00000010 #define BGE_FLAG_MSI 0x00000100 #define BGE_FLAG_PCIX 0x00000200 #define BGE_FLAG_PCIE 0x00000400 Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 202268) +++ sys/dev/bge/if_bge.c (working copy) @@ -902,7 +902,8 @@ mii = device_get_softc(sc->bge_miibus); BGE_CLRBIT(sc, BGE_MAC_MODE, BGE_MACMODE_PORTMODE); - if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T) + if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_T || + IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_GMII); else BGE_SETBIT(sc, BGE_MAC_MODE, BGE_PORTMODE_MII); @@ -1783,13 +1784,20 @@ if (!(BGE_IS_5705_PLUS(sc))) CSR_WRITE_4(sc, BGE_RXLS_MODE, BGE_RXLSMODE_ENABLE); + val = BGE_MACMODE_TXDMA_ENB | BGE_MACMODE_RXDMA_ENB | + BGE_MACMODE_RX_STATS_CLEAR | BGE_MACMODE_TX_STATS_CLEAR | + BGE_MACMODE_RX_STATS_ENB | BGE_MACMODE_TX_STATS_ENB | + BGE_MACMODE_FRMHDR_DMA_ENB; + + if (sc->bge_flags & BGE_FLAG_TBI) + val |= BGE_PORTMODE_TBI; + else if (sc->bge_flags & BGE_FLAG_MII_SERDES) + val |= BGE_PORTMODE_GMII; + else + val |= BGE_PORTMODE_MII; + /* Turn on DMA, clear stats */ - CSR_WRITE_4(sc, BGE_MAC_MODE, BGE_MACMODE_TXDMA_ENB | - BGE_MACMODE_RXDMA_ENB | BGE_MACMODE_RX_STATS_CLEAR | - BGE_MACMODE_TX_STATS_CLEAR | BGE_MACMODE_RX_STATS_ENB | - BGE_MACMODE_TX_STATS_ENB | BGE_MACMODE_FRMHDR_DMA_ENB | - ((sc->bge_flags & BGE_FLAG_TBI) ? - BGE_PORTMODE_TBI : BGE_PORTMODE_MII)); + CSR_WRITE_4(sc, BGE_MAC_MODE, val); /* Set misc. local control, enable interrupts on attentions */ CSR_WRITE_4(sc, BGE_MISC_LOCAL_CTL, BGE_MLC_INTR_ONATTN); @@ -2851,12 +2859,14 @@ hwcfg = ntohl(hwcfg); } - if ((hwcfg & BGE_HWCFG_MEDIA) == BGE_MEDIA_FIBER) - sc->bge_flags |= BGE_FLAG_TBI; - /* The SysKonnect SK-9D41 is a 1000baseSX card. */ - if ((pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16) == SK_SUBSYSID_9D41) - sc->bge_flags |= BGE_FLAG_TBI; + if ((pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16) == + SK_SUBSYSID_9D41 || (hwcfg & BGE_HWCFG_MEDIA) == BGE_MEDIA_FIBER) { + if (BGE_IS_5714_FAMILY(sc)) + sc->bge_flags |= BGE_FLAG_MII_SERDES; + else + sc->bge_flags |= BGE_FLAG_TBI; + } if (sc->bge_flags & BGE_FLAG_TBI) { ifmedia_init(&sc->bge_ifmedia, IFM_IMASK, bge_ifmedia_upd, Index: sys/dev/mii/brgphy.c =================================================================== --- sys/dev/mii/brgphy.c (revision 202269) +++ sys/dev/mii/brgphy.c (working copy) @@ -197,6 +197,7 @@ case MII_OUI_xxBROADCOM: switch (bsc->mii_model) { case MII_MODEL_xxBROADCOM_BCM5706: + case MII_MODEL_xxBROADCOM_BCM5714: /* * The 5464 PHY used in the 5706 supports both copper * and fiber interfaces over GMII. Need to check the --FEz7ebHBGB6b2e8X-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 18:10:29 2010 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 7D015106568B for ; Thu, 14 Jan 2010 18:10:29 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2A98FC08 for ; Thu, 14 Jan 2010 18:10:28 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so221812eye.9 for ; Thu, 14 Jan 2010 10:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=NMo5z7/T8xvjyRN5U1C9DvOWcrj/iU4NtQH3YimYt34=; b=GLOtfhepi3I3eI9bGYFgQTfS7TEmUwyvrba2AIMtATj+zWHprAdEFySmceqFdwZsBz Lr51i80F4PpFDtegjMbCF6wLxygf2rlO4qYElOXhUtM3qBwj9gZ4u5mXnWUioyedmohG AXhX2I2cBYLmPj72AS+pV7uMJTmP2dYIKK/pQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=c7XxH5tIMxYWrJFijVWqzQ/nGfVbOZBmc5XQhcehdfQGH4O7JCp2CtfHLmY/Xiktv7 R+naKHwdPdDTLH+TtWmfwHeoLjj35YnFr/6rc9/UD6MeUmzDUefwTVSneTO0kw9xxOAm glP9JwjOVtkdqnk1LRMraHGP+4GSGAH2+5L6I= Received: by 10.213.110.210 with SMTP id o18mr1145679ebp.13.1263491291647; Thu, 14 Jan 2010 09:48:11 -0800 (PST) Received: from peanut.dreadbsd.org (mna75-2-82-67-196-50.fbx.proxad.net [82.67.196.50]) by mx.google.com with ESMTPS id 13sm707361ewy.5.2010.01.14.09.48.01 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 09:48:02 -0800 (PST) Sender: Antoine Brodin Date: Thu, 14 Jan 2010 18:47:58 +0100 From: Antoine Brodin To: Jeff Blank Message-Id: <20100114184758.3c4e18ca.antoine@FreeBSD.org> In-Reply-To: <20100114155755.GA77799@mr-happy.com> References: <20100114155755.GA77799@mr-happy.com> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Regression in sh(1) ? (Was: make delete-old fails when removing catpages) 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, 14 Jan 2010 18:10:29 -0000 Jeff Blank wrote: > Hi, > > 9-CURRENT, csups around 2000 UTC yesterday and 0100 UTC today, fails > when removing some catpages during 'make delete-old'. Output below is > from after the initial failure, and context had left my scrollback > buffer, but the first file that failed was /usr/share/man/cat1/rcp.1.gz. > I removed it by hand with no issues and ran again: > > ========== > # make delete-old > >>> Removing old files (only deletes safe to delete libs) > remove /usr/share/man/cat1/ipftest.1.gz? *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > # rm /usr/share/man/cat1/ipftest.1.gz > # make delete-old > >>> Removing old files (only deletes safe to delete libs) > remove /usr/share/man/cat1/ipresend.1.gz? *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. [Snip] This seems to be a regression in sh(1). Simple test case: This succeeds on stable/8: %%% > sh $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done remove /tmp/foo? y /tmp/foo %%% and fails on head: %%% > sh $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done remove /tmp/foo? $ %%% Cheers, Antoine From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 18:32:53 2010 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 F17C7106566B for ; Thu, 14 Jan 2010 18:32:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7A01A8FC1B for ; Thu, 14 Jan 2010 18:32:52 +0000 (UTC) Received: by fxm27 with SMTP id 27so1142166fxm.3 for ; Thu, 14 Jan 2010 10:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=zn/fiA7kiasTm4bzWORIDeo2zyCXdkgt/kd2hJhSo4Y=; b=jADibHUfI/XL096/OzMmZlcnt7yZdEAG4VZ0EHDNH7W1Q4bebqRqdRTILH9GjaGLBB 4ERxDQtMOMfcSJTKsx+5ScqnvCYtpR0oeH70uvlEWtt/jffgZopLIwFj/PwnsNU/kaDY RAAkfZNxdpbmzbJOyUgWKu+WohCgHT+R4+zFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ORv9lnIVoRJ/2i5ga4mwmR8bGVT1240yVoSk7iRYZjZOixnAGlhJQi6QBucK2KOJmg 22xR6VHV3RGOAAxznpau7EnwB3ZVLGk1/VM4hcQRKz6WVKj5ya2yHg0b8ubTixGkPBOP 4c87sDUaQSOzgtAwu02dQBHEYuPAU0ASdpOZ4= Received: by 10.223.21.15 with SMTP id h15mr1473476fab.15.1263493963448; Thu, 14 Jan 2010 10:32:43 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm47314fxm.8.2010.01.14.10.32.41 (version=SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 10:32:42 -0800 (PST) Sender: Alexander Motin Message-ID: <4B4F6346.3090404@FreeBSD.org> Date: Thu, 14 Jan 2010 20:32:38 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <20091002150931.K35591@pooker.samsco.org> <200911050922.10205.hselasky@c2i.net> <4AFCB277.5070306@delphij.net> <200911130909.30828.hselasky@c2i.net> <4B4F4E55.1050906@jrv.org> In-Reply-To: <4B4F4E55.1050906@jrv.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Marcel Moolenaar , Hans Petter Selasky Subject: Re: Fix for USB media not found at boot 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, 14 Jan 2010 18:32:54 -0000 James R. Van Artsdalen wrote: > Hans Petter Selasky wrote: >> The changeset in question has not been committed to mainstream. >> >> Scott Long is working on an improved solution. Please coordinate with him. > > Has anything happened with the general case? A friend of mine reported > to me a regression between 8.0-RELEASE and 8-STABLE that turns out to be > this issue with SATA port multipliers. > > I have the same problem, except that I need to further wait for GEOM to > make visible a gmirror made of two slow devices (behind SATA port > multiplier). There is a set of several related problems I am aware of and working on: 1. There are problems with synchronization of different CAM parts. It wasn't so important for SCSI, but it does for ATA, especially for error recovery. Recently I have made patch in Perforce (one you are testing now) to solve that. 2. Automatic device hot-plug is not very unified in CAM and just not implemented yet for plain SATA (without PMP). It is related to the topic by several questions like: what if controller detects device appearance before CAM initially scanned, should we do it twice? 3. There are problems with late-coming SIMs, such as umass on USB, ATA on PCCard/CardBus and so on. As they may arrive too late for system-wide CAM bus scanning, each of them have to handle own scan by them selves. Now I am going to rewrite scan process, to make every bus scanned automatically on arrive, as soon as system will be able to do it. It will remove some duplicate code from about ten different drivers and should make process more unified. 4. Port Multiplier is a some kind of late-coming device. It has own scanning routine, which may only start, when main scan is already completing. There are two possible ways: either make main bus scan call wait for some event from PMP driver before return, or ignore it there and let system wait on root mounting, while all such scan processes will be finished. I haven't decided yet, which way to go. 5. To make device ordering repeatable between reboots, CAM originally used quite simple and dirty practice of not loading peripheral drivers, until all buses complete scan. It was working fine in a simple world without hot-plug. But it just not working any more for late-coming devices. At this moment I don't see really good solution here, as there is no moment when we can be sure that all possible devices are arrived. It is possible to bind device numbers by hands, but it is overcomplicated for the most cases. Problems 4 and 5 result in common general question: What to do with late devices? Either try in any possible way extend CAM bus scanning period for them (which is even theoretically impossible, as some device will always trying to get late there), or gave up there and put all chips on delaying FS mounting stage. In last case we have to do something with unstable device numbering. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 18:40:04 2010 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 CBEC6106566B for ; Thu, 14 Jan 2010 18:40:04 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0C68FC08 for ; Thu, 14 Jan 2010 18:40:04 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0EIdlWm073655; Thu, 14 Jan 2010 19:40:03 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0EIdlhG073654; Thu, 14 Jan 2010 19:39:47 +0100 (CET) (envelope-from olli) Date: Thu, 14 Jan 2010 19:39:47 +0100 (CET) Message-Id: <201001141839.o0EIdlhG073654@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, pyunyh@gmail.com In-Reply-To: <20100114174723.GV1228@michelle.cdnetworks.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 14 Jan 2010 19:40:03 +0100 (CET) Cc: Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier 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, 14 Jan 2010 18:40:04 -0000 Pyun YongHyeon wrote: > Thanks for the information. Would you try attached patch? Yes! The patch works perfectly. Thank you very much! With that patch, brgphy correctly detects 1000baseSX. I get a link, and tcpdump sees packets flying by. Would you please commit this, and MFC to stable/[78] after a while? > If the patch still reports 10/100/1000 copper PHY, try adding > 'sc->mii_flags |= MIIF_HAVEFIBER' to force setting MIIF_HAVEFIBER > flag in brgphy.c:brgphy_attach. I didn't have to do that. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 19:18:43 2010 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 6AEDD106566B for ; Thu, 14 Jan 2010 19:18:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1D98E8FC0A for ; Thu, 14 Jan 2010 19:18:42 +0000 (UTC) Received: by qyk4 with SMTP id 4so11944752qyk.7 for ; Thu, 14 Jan 2010 11:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Citco3kEJDfeYuwa7kvGOkmAE4CRgn2OS4/YKYCtz8Y=; b=Uba0JX3W0no5qi+Re6Wf/tf78l/DcDxfBVYcEnanzt+4jOijZU3tYijSjyqSK6arzh bufNUZN14eZLwWxpL3hiXF7nH+kwYYoMCEbvaN4m1ooFQAXXrFrWSdInHvFz1/o3w+tl fI86dJt59eD2I00G34daoiscj7yKcwhCC+v7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Vg8TI7FBkCr/B3C0RLyw44KNpWyn/J8CjFCYt4Faw6dtsUDMh8g8KIszkPkk5CKbtd u2KEKt5t3NmJQ4gKjcWqBElK9Z4qJrHzFrUK2j4cmeIxcLnr5jexeJGnMwjcImI+wEx4 /4N5YajPlt9hQPibfQrNovi78NNjG1Frrk34w= Received: by 10.224.86.130 with SMTP id s2mr1225685qal.85.1263496702947; Thu, 14 Jan 2010 11:18:22 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm2559923qwd.36.2010.01.14.11.18.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Jan 2010 11:18:21 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 14 Jan 2010 11:17:38 -0800 From: Pyun YongHyeon Date: Thu, 14 Jan 2010 11:17:38 -0800 To: Oliver Fromme Message-ID: <20100114191738.GZ1228@michelle.cdnetworks.com> References: <20100114174723.GV1228@michelle.cdnetworks.com> <201001141839.o0EIdlhG073654@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001141839.o0EIdlhG073654@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.ORG Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 19:18:43 -0000 On Thu, Jan 14, 2010 at 07:39:47PM +0100, Oliver Fromme wrote: > Pyun YongHyeon wrote: > > Thanks for the information. Would you try attached patch? > > Yes! The patch works perfectly. Thank you very much! > With that patch, brgphy correctly detects 1000baseSX. > I get a link, and tcpdump sees packets flying by. > > Would you please commit this, and MFC to stable/[78] > after a while? > Done(r202293, r202294). > > If the patch still reports 10/100/1000 copper PHY, try adding > > 'sc->mii_flags |= MIIF_HAVEFIBER' to force setting MIIF_HAVEFIBER > > flag in brgphy.c:brgphy_attach. > > I didn't have to do that. > Ok, now let's open new thread for bce(4) issues. From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 19:41:07 2010 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 E5E841065670; Thu, 14 Jan 2010 19:41:07 +0000 (UTC) (envelope-from chet.ramey@case.edu) Received: from mpv2.tis.cwru.edu (mpv2.tis.cwru.edu [129.22.105.37]) by mx1.freebsd.org (Postfix) with ESMTP id 9369F8FC1C; Thu, 14 Jan 2010 19:41:07 +0000 (UTC) Received: from mpv5.TIS.cwru.edu (mpv5.tis.CWRU.Edu [129.22.105.51]) by mpv2.tis.cwru.edu (MOS 4.1.8-GA) with ESMTP id AEG75370; Thu, 14 Jan 2010 14:25:56 -0500 Received: from caleb.INS.CWRU.Edu (caleb.INS.CWRU.Edu [129.22.8.211]) by mpv5.TIS.cwru.edu (MOS 3.10.8-GA) with ESMTP id EXQ13324 (AUTH cpr); Thu, 14 Jan 2010 14:25:49 -0500 (EST) Message-ID: <4B4F6FBD.5090707@case.edu> Date: Thu, 14 Jan 2010 14:25:49 -0500 From: Chet Ramey User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Antoine Brodin References: <20100114155755.GA77799@mr-happy.com> <20100114184758.3c4e18ca.antoine@FreeBSD.org> In-Reply-To: <20100114184758.3c4e18ca.antoine@FreeBSD.org> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/51, host=mpv2.tis.cwru.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020204.4B4F6FC2.0092,ss=1,fgs=0, ip=0.0.0.0, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false X-Mailman-Approved-At: Thu, 14 Jan 2010 20:41:25 +0000 Cc: freebsd-current@freebsd.org, chet.ramey@case.edu, Jeff Blank Subject: Re: Regression in sh(1) ? (Was: make delete-old fails when removing catpages) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chet.ramey@case.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 19:41:08 -0000 On 1/14/10 12:47 PM, Antoine Brodin wrote: > This seems to be a regression in sh(1). > Simple test case: > This succeeds on stable/8: > %%% >> sh > $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done > remove /tmp/foo? y > /tmp/foo > %%% > > and fails on head: > %%% >> sh > $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done > remove /tmp/foo? $ > %%% If these are the actual commands that fail, this is more of a bug fix than a regression. The command "3<&0" is not supposed to be equivalent to "exec 3<&0", and the effects of the redirection should not persist in the calling shell. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/ From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 21:07:30 2010 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 CAC251065787 for ; Thu, 14 Jan 2010 21:07:30 +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 6F9C48FC20 for ; Thu, 14 Jan 2010 21:07:30 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 64C681CDE3; Thu, 14 Jan 2010 22:07:29 +0100 (CET) Date: Thu, 14 Jan 2010 22:07:29 +0100 From: Ed Schouten To: Andrzej Tobola Message-ID: <20100114210729.GN64905@hoeg.nl> References: <20100113194254.GR64905@hoeg.nl> <20100113220010.GC32376@volt.iem.pw.edu.pl> <20100113220238.GV64905@hoeg.nl> <20100113225057.GA55325@amp2.iem.pw.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ulYX2yhpjtvapoxU" Content-Disposition: inline In-Reply-To: <20100113225057.GA55325@amp2.iem.pw.edu.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: utmp/utmpx conversion tool 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, 14 Jan 2010 21:07:30 -0000 --ulYX2yhpjtvapoxU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andrzej, I'm sending this back to the lists, because I think it is an interesting question. * Andrzej Tobola wrote: > If I need to preserve datbases - do You have any tool to convert > /var/run/utmp, /var/log/lastlog and /var/log/wtmp to the new format ? I see little use in converting utmp and lastlog to the new format. The utmp file normally shouldn't survive a reboot, while the data provided by lastlog is just `value added'. I can imagine people do want to be able to convert their wtmp files. This is why I just committed a tool called wtmpcvt(1) (also mentioned in UPDATING now). This tool allows you to convert the log files to the new format and view them using last(1) and ac(8). There is no procedure to do this automatically. I also don't want to do this, because if things go wrong, I don't want to be responsible for corrupting everyone's log files. --=20 Ed Schouten WWW: http://80386.nl/ --ulYX2yhpjtvapoxU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktPh5EACgkQ52SDGA2eCwU8ywCfQXl3JLMd1LCQzJoQdELzUhcK J+QAnAr1hPdvjW3VvjjMBidEt35851GW =vTMq -----END PGP SIGNATURE----- --ulYX2yhpjtvapoxU-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 14 23:33:52 2010 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 3E58F106568F; Thu, 14 Jan 2010 23:33:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 02E3F8FC0A; Thu, 14 Jan 2010 23:33:52 +0000 (UTC) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id D30DD1DD483; Fri, 15 Jan 2010 00:33:50 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1677) id B919E73FA1; Fri, 15 Jan 2010 00:33:50 +0100 (CET) Date: Fri, 15 Jan 2010 00:33:50 +0100 From: Jilles Tjoelker To: Antoine Brodin Message-ID: <20100114233350.GA77512@stack.nl> References: <20100114155755.GA77799@mr-happy.com> <20100114184758.3c4e18ca.antoine@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100114184758.3c4e18ca.antoine@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, Jeff Blank Subject: Re: Regression in sh(1) ? (Was: make delete-old fails when removing catpages) 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, 14 Jan 2010 23:33:52 -0000 On Thu, Jan 14, 2010 at 06:47:58PM +0100, Antoine Brodin wrote: > This seems to be a regression in sh(1). > Simple test case: > This succeeds on stable/8: > %%% > > sh > $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done > remove /tmp/foo? y > /tmp/foo > %%% > and fails on head: > %%% > > sh > $ touch /tmp/foo; 3<&0; echo /tmp/foo | while read i; do rm -vi ${i} <&3 ; done > remove /tmp/foo? $ > %%% This is because src/Makefile.inc1 had a bug, 'exec' is required to have a redirection persist after the command. I have fixed this. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Fri Jan 15 23:00:44 2010 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 7D81F106566B for ; Fri, 15 Jan 2010 23:00:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 30C958FC13 for ; Fri, 15 Jan 2010 23:00:43 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so161941qwd.7 for ; Fri, 15 Jan 2010 15:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:mime-version:content-type:content-disposition :user-agent; bh=zczvvA0IJr7uc5sLhfbacMNqOvcqP6aPEi6NJrPwj5Y=; b=opRX+1GLX7wh/u9iFyqgYFjKbNDyfMwTXiiEwpyz8cwBN3C1Mjn/u/LzkHgXpJHcKX opXIJcyIWD7WXQ/8CXQvP9tq3pkk4w5adyJLVRIZ1piCO3QEHQiekPph1qp0WWiGwbHE Jxxowl/fcyW0AozplCk1Xaay84s1+wpe74haA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; b=c738WwjW7veTRVolUMYcLpE8RIZA7Gt3D/UAOYfU1YNggoa5Kpwek7lymsk52YM5+I oaULaWHQXFWLJVqs9B2kTnKjU2r3AqaaSDM/YQUTl6B7RCWYZpN3ky8MfoRJ1DAtTqYc 2ClwdiNxs1BBOeJDhNXi0pXFR3qzNcmoIiRAA= Received: by 10.224.58.201 with SMTP id i9mr2717642qah.8.1263596437636; Fri, 15 Jan 2010 15:00:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 22sm2071913qyk.10.2010.01.15.15.00.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 15 Jan 2010 15:00:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 15 Jan 2010 14:59:57 -0800 From: Pyun YongHyeon Date: Fri, 15 Jan 2010 14:59:57 -0800 To: freebsd-current@FreeBSD.org Message-ID: <20100115225957.GL1228@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rCwQ2Y43eQY6RBgR" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: CFT: bge(4) ASF handling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 23:00:44 -0000 --rCwQ2Y43eQY6RBgR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, It seems bge(4) had long standing issues on ASF handling. Floris Bos sent me a patch that fixes ASF issues. While reading bge(4) I also noticed new handshake method was not enabled on all BCM575X family of controllers. So if you have ever experienced problems with ASF or you had to disable ASF in bge(hw.bge.allow_asf) please test attached patch with ASF and let me know how it goes on your box. Note, ASF handling was disabled except HEAD so you may have to enable it explicitly on your box with hw.bge.allow_asf tunable. I'm not sure but this would also have effects on bge(4) suspend/resume issues. So if you have BCM575X or higher controller and if you have problems with suspend/resume on bge(4) please give it try. Thanks. --rCwQ2Y43eQY6RBgR Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.asf.diff" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 202406) +++ sys/dev/bge/if_bge.c (working copy) @@ -2744,9 +2744,8 @@ & BGE_HWCFG_ASF) { sc->bge_asf_mode |= ASF_ENABLE; sc->bge_asf_mode |= ASF_STACKUP; - if (sc->bge_asicrev == BGE_ASICREV_BCM5750) { + if (BGE_IS_575X_PLUS(sc)) sc->bge_asf_mode |= ASF_NEW_HANDSHAKE; - } } } @@ -3677,7 +3676,7 @@ if (sc->bge_asf_count) sc->bge_asf_count --; else { - sc->bge_asf_count = 5; + sc->bge_asf_count = 2; bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM_FW, BGE_FW_DRV_ALIVE); bge_writemem_ind(sc, BGE_SOFTWARE_GENNCOMM_FW_LEN, 4); --rCwQ2Y43eQY6RBgR-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 16 01:21:19 2010 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 A35EA1065670 for ; Sat, 16 Jan 2010 01:21:19 +0000 (UTC) (envelope-from kg6ymn@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF8F8FC20 for ; Sat, 16 Jan 2010 01:21:19 +0000 (UTC) Received: by ywh35 with SMTP id 35so1003406ywh.7 for ; Fri, 15 Jan 2010 17:21:16 -0800 (PST) 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=FUGroVG/ImWyiUOPFx9YAsLcKqLhpKI2EdZEY0VeS9c=; b=hYSQi4rOkvfVdPofehyNrG0CZiOuiGgdH34CoiSpIxKM3BJUB79L7xSIo2idZ5qX4t MRZGWFBCM7H/jh9HdpMiUA9tdg06HgLf02Mmdh+KlYMuqQX//zz3InzWiAL8ouy9cXbO yLvG8m2E1gJtIMMqsSsYnh4JwsKjGOs6crhlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NNhAJ8Afb0v4w+MNJhmcEXFOQgZVdSwsLS6iiCMusrY1vTMYAEdRCVFRVMBkym0YOp UqQxCS6C78swhu/uRjgVUHn/tPqHRfe6ofHo4JnmuXqLd7svy2qM5ZfFVLUioYBL4SOS utcESysqAMdSrazJ8bvNQiASUVKRR7qQrB7+M= MIME-Version: 1.0 Received: by 10.150.47.32 with SMTP id u32mr1900380ybu.125.1263604876351; Fri, 15 Jan 2010 17:21:16 -0800 (PST) Date: Fri, 15 Jan 2010 17:21:16 -0800 Message-ID: From: michael brindle To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: -CURRENT Bug in portupgrade with sudo 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, 16 Jan 2010 01:21:19 -0000 Hello. So, apparently, when one attempts to use portupgrade from a normal user shell, by way of sudo, portupgrade will remove the user from the /usr/local/etc/sudoers file. Also, the user is unable to use the su utility to become root to add themselves back into the /usr/local/etc/sudoers file. Also, this may also be a bug in X, because I rarely run command-line only, next time I upgrade my ports, I will remember to drop into command-line only first. for example: > sudo portupgrade -af Password: (in another terminal) > sudo vi Password: is not in the sudoers file. This incident will be reported. > -- Michael Brindle From owner-freebsd-current@FreeBSD.ORG Sat Jan 16 02:06:36 2010 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 2F77F1065670; Sat, 16 Jan 2010 02:06:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 069138FC1E; Sat, 16 Jan 2010 02:06:35 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0G26ZFO031410; Fri, 15 Jan 2010 21:06:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0G26Zvi031394; Sat, 16 Jan 2010 02:06:35 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jan 2010 02:06:35 GMT Message-Id: <201001160206.o0G26Zvi031394@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Sat, 16 Jan 2010 02:06:36 -0000 TB --- 2010-01-16 01:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-16 01:05:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-16 01:05:00 - cleaning the object tree TB --- 2010-01-16 01:05:27 - cvsupping the source tree TB --- 2010-01-16 01:05:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-16 01:05:59 - building world TB --- 2010-01-16 01:05:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 01:05:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 01:05:59 - TARGET=pc98 TB --- 2010-01-16 01:05:59 - TARGET_ARCH=i386 TB --- 2010-01-16 01:05:59 - TZ=UTC TB --- 2010-01-16 01:05:59 - __MAKE_CONF=/dev/null TB --- 2010-01-16 01:05:59 - cd /src TB --- 2010-01-16 01:05:59 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 16 01:06:00 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 16 02:05:10 UTC 2010 TB --- 2010-01-16 02:05:10 - generating LINT kernel config TB --- 2010-01-16 02:05:10 - cd /src/sys/pc98/conf TB --- 2010-01-16 02:05:10 - /usr/bin/make -B LINT TB --- 2010-01-16 02:05:10 - building LINT kernel TB --- 2010-01-16 02:05:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 02:05:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 02:05:10 - TARGET=pc98 TB --- 2010-01-16 02:05:10 - TARGET_ARCH=i386 TB --- 2010-01-16 02:05:10 - TZ=UTC TB --- 2010-01-16 02:05:10 - __MAKE_CONF=/dev/null TB --- 2010-01-16 02:05:10 - cd /src TB --- 2010-01-16 02:05:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 16 02:05:10 UTC 2010 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/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 -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 -ffreestan! ding -fstack-protector /src/sys/i386/i386/local_apic.c:37:23: error: opt_atpic.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-16 02:06:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-16 02:06:35 - ERROR: failed to build lint kernel TB --- 2010-01-16 02:06:35 - 2708.96 user 641.65 system 3694.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 16 11:42:52 2010 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 919BC106566C for ; Sat, 16 Jan 2010 11:42:52 +0000 (UTC) (envelope-from sziszi@bsd.hu) Received: from mail.rubicom.hu (mail.rubicom.hu [89.147.80.28]) by mx1.freebsd.org (Postfix) with ESMTP id 14EE88FC08 for ; Sat, 16 Jan 2010 11:42:51 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=mail.rubicom.hu) by mail.rubicom.hu with smtp (Exim 4.63) (envelope-from ) id 1NW73J-0001pw-FS for freebsd-current@freebsd.org; Sat, 16 Jan 2010 12:42:49 +0100 Received: from ip59935289.rubicom.hu ([89.147.82.137] helo=baranyfelhocske.buza.adamsfamily.xx) by mail.rubicom.hu with esmtp (Exim 4.63) (envelope-from ) id 1NW73I-0001pV-Vt for freebsd-current@freebsd.org; Sat, 16 Jan 2010 12:42:49 +0100 Received: from baranyfelhocske.buza.adamsfamily.xx (localhost [127.0.0.1]) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3) with ESMTP id o0GBgm5h001705 for ; Sat, 16 Jan 2010 12:42:48 +0100 (CET) (envelope-from sziszi@bsd.hu) Received: (from sziszi@localhost) by baranyfelhocske.buza.adamsfamily.xx (8.14.3/8.14.3/Submit) id o0GBgmrn001704 for freebsd-current@freebsd.org; Sat, 16 Jan 2010 12:42:48 +0100 (CET) (envelope-from sziszi@bsd.hu) X-Authentication-Warning: baranyfelhocske.buza.adamsfamily.xx: sziszi set sender to sziszi@bsd.hu using -f Date: Sat, 16 Jan 2010 12:42:48 +0100 From: Szilveszter Adam To: freebsd-current@freebsd.org Message-ID: <20100116114248.GA1652@baranyfelhocske.buza.adamsfamily.xx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: -CURRENT Bug in portupgrade with sudo 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, 16 Jan 2010 11:42:52 -0000 Hello and G'day, On Fri, Jan 15, 2010 at 05:21:16PM -0800, michael brindle wrote: > So, apparently, when one attempts to use portupgrade from a normal user > shell, by way of sudo, portupgrade will remove the user from the > /usr/local/etc/sudoers file. I cannot confirm this. I have been using portupgrade with sudo for literally years now, and it has always worked. The only trick is when you have to upgrade the sudo port itself, since the sudo command disappears in the middle of the upgrade process. In that case you have to first pkg_deinstall the sudo port and then "make install" in the sudo port directory the old-fashioned way. But this is really the only quirk I have come across. > Also, the user is unable to use the su utility to become root to add > themselves back into the /usr/local/etc/sudoers file. Of course depending on what you mean by this. If the user has been in the wheel group previously, they will certainly be able to use su. This has nothing to do with sudo or portupgrade. > Also, this may also be a bug in X, because I rarely run command-line only, > next time I upgrade my ports, I will remember to drop into command-line only > first. Highly unlikely. > for example: > > sudo portupgrade -af I have never tried it this way, and, thinking of it, it may not necessarily do what you think it does. However, portupgrade has the ability to run as normal user, and invoke sudo only when it is needed. I suggest you look into the portupgrade man page and in particular, investigate the "-s" switch. Also, using -af with portupgrade is really a sledgehammer. It will not help you much when you try to diagnose a possible problem. At a minimum, try to gather more information about what happens during the upgrade (possibly by also making log files) and narrow it down to the specific point when you think the sudoers files is changed. Investigate the "-v" switch for portupgrade as well as other debugging and logging options. It would be best if you did not try to upgrade everything at once, but rather, one-by-one. (This is a good practice anyway; the -af may do more work than it would be needed and at the same time, you may miss important information because all of it just scrolls up on your terminal too fast. Also, by using -af, you will probably not be able to follow /usr/ports/UPDATING either, although it is strongly recommended to do so when upgrading the ports.) -- Regards: Szilveszter ADAM Budapest Hungary From owner-freebsd-current@FreeBSD.ORG Sat Jan 16 12:11:33 2010 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 D94141065694; Sat, 16 Jan 2010 12:11:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B03048FC12; Sat, 16 Jan 2010 12:11:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0GCBWaJ025446; Sat, 16 Jan 2010 07:11:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0GCBWNm025403; Sat, 16 Jan 2010 12:11:32 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jan 2010 12:11:32 GMT Message-Id: <201001161211.o0GCBWNm025403@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Sat, 16 Jan 2010 12:11:34 -0000 TB --- 2010-01-16 11:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-16 11:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-16 11:10:00 - cleaning the object tree TB --- 2010-01-16 11:10:14 - cvsupping the source tree TB --- 2010-01-16 11:10:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-16 11:10:48 - building world TB --- 2010-01-16 11:10:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 11:10:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 11:10:48 - TARGET=pc98 TB --- 2010-01-16 11:10:48 - TARGET_ARCH=i386 TB --- 2010-01-16 11:10:48 - TZ=UTC TB --- 2010-01-16 11:10:48 - __MAKE_CONF=/dev/null TB --- 2010-01-16 11:10:48 - cd /src TB --- 2010-01-16 11:10:48 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 16 11:10:48 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 16 12:10:05 UTC 2010 TB --- 2010-01-16 12:10:05 - generating LINT kernel config TB --- 2010-01-16 12:10:05 - cd /src/sys/pc98/conf TB --- 2010-01-16 12:10:05 - /usr/bin/make -B LINT TB --- 2010-01-16 12:10:05 - building LINT kernel TB --- 2010-01-16 12:10:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 12:10:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 12:10:05 - TARGET=pc98 TB --- 2010-01-16 12:10:05 - TARGET_ARCH=i386 TB --- 2010-01-16 12:10:05 - TZ=UTC TB --- 2010-01-16 12:10:05 - __MAKE_CONF=/dev/null TB --- 2010-01-16 12:10:05 - cd /src TB --- 2010-01-16 12:10:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 16 12:10:05 UTC 2010 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/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 -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 -ffreestan! ding -fstack-protector /src/sys/i386/i386/local_apic.c:37:23: error: opt_atpic.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-16 12:11:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-16 12:11:32 - ERROR: failed to build lint kernel TB --- 2010-01-16 12:11:32 - 2710.48 user 629.54 system 3692.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Jan 16 22:52:47 2010 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 B3A9F106566B; Sat, 16 Jan 2010 22:52:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8C51A8FC08; Sat, 16 Jan 2010 22:52:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0GMqkZr099549; Sat, 16 Jan 2010 17:52:46 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0GMqktM099520; Sat, 16 Jan 2010 22:52:46 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Jan 2010 22:52:46 GMT Message-Id: <201001162252.o0GMqktM099520@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Sat, 16 Jan 2010 22:52:47 -0000 TB --- 2010-01-16 21:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-16 21:25:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-16 21:25:00 - cleaning the object tree TB --- 2010-01-16 21:25:21 - cvsupping the source tree TB --- 2010-01-16 21:25:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-16 21:26:28 - building world TB --- 2010-01-16 21:26:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 21:26:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 21:26:28 - TARGET=pc98 TB --- 2010-01-16 21:26:28 - TARGET_ARCH=i386 TB --- 2010-01-16 21:26:28 - TZ=UTC TB --- 2010-01-16 21:26:28 - __MAKE_CONF=/dev/null TB --- 2010-01-16 21:26:28 - cd /src TB --- 2010-01-16 21:26:28 - /usr/bin/make -B buildworld >>> World build started on Sat Jan 16 21:26:28 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Jan 16 22:25:48 UTC 2010 TB --- 2010-01-16 22:25:48 - generating LINT kernel config TB --- 2010-01-16 22:25:48 - cd /src/sys/pc98/conf TB --- 2010-01-16 22:25:48 - /usr/bin/make -B LINT TB --- 2010-01-16 22:25:48 - building LINT kernel TB --- 2010-01-16 22:25:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 22:25:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 22:25:48 - TARGET=pc98 TB --- 2010-01-16 22:25:48 - TARGET_ARCH=i386 TB --- 2010-01-16 22:25:48 - TZ=UTC TB --- 2010-01-16 22:25:48 - __MAKE_CONF=/dev/null TB --- 2010-01-16 22:25:48 - cd /src TB --- 2010-01-16 22:25:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Jan 16 22:25:48 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Jan 16 22:47:08 UTC 2010 TB --- 2010-01-16 22:47:08 - building GENERIC kernel TB --- 2010-01-16 22:47:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-16 22:47:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-16 22:47:08 - TARGET=pc98 TB --- 2010-01-16 22:47:08 - TARGET_ARCH=i386 TB --- 2010-01-16 22:47:08 - TZ=UTC TB --- 2010-01-16 22:47:08 - __MAKE_CONF=/dev/null TB --- 2010-01-16 22:47:08 - cd /src TB --- 2010-01-16 22:47:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Jan 16 22:47:08 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/qdivrem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/ucmpdi2.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/udivdi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/libkern/umoddi3.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/cbus_dma.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/pc98/cbus/clock.c /src/sys/pc98/cbus/clock.c:104: error: variable 'using_lapic_timer' has initializer but incomplete type /src/sys/pc98/cbus/clock.c:104: error: 'LAPIC_CLOCK_NONE' undeclared here (not in a function) *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-16 22:52:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-16 22:52:46 - ERROR: failed to build GENERIC kernel TB --- 2010-01-16 22:52:46 - 3904.41 user 858.62 system 5266.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full