From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 03:41: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 9577A106566B; Sun, 10 Oct 2010 03:41:47 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2015D8FC1C; Sun, 10 Oct 2010 03:41:46 +0000 (UTC) Received: by gxk8 with SMTP id 8so913773gxk.13 for ; Sat, 09 Oct 2010 20:41:46 -0700 (PDT) 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 :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=hjTy1wQlDKdLEW8lPlR6s1kZE9AuVSruc9raenrfxrw=; b=vSUWMT2gwba53YnGLOipetnfahgPDy7hJSeedVPMkEp73YX9v4yXbiDojc72SSUlwI IhwEuvSTE+PaLE4ptZ0frFnFSdPH7ovyCicRAGXWfSqeQH78TBtHeuZpK+yqjU+I/8TT nKzn7CAFUmHymgNz5WVOTSslBCD//mCBikOHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Gsm8HlUSlJFnSykdQMZ8SGfRteKE2LaaeWxTce34Oyo2KTyT/IUNy69zNYMCGqWKpl H+lmCIQ3oU7U0yctEWpBdaYTvTQuOBCp/QcBxoekhwki3Vds9jLjcmuv6VLO+Z2mixIV v4/2WdwdVSe3Vqyrp6+gRJ0yTM66G+/JN2siY= Received: by 10.150.201.18 with SMTP id y18mr5049945ybf.329.1286682106252; Sat, 09 Oct 2010 20:41:46 -0700 (PDT) Received: from centel.dataix.local ([99.181.144.115]) by mx.google.com with ESMTPS id v9sm4519174yba.3.2010.10.09.20.41.43 (version=SSLv3 cipher=RC4-MD5); Sat, 09 Oct 2010 20:41:44 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CB135F5.20804@DataIX.net> Date: Sat, 09 Oct 2010 23:41:41 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: pluknet References: <4C76CA06.5010001@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , freebsd-rc@freebsd.org, FreeBSD Current Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 03:41:47 -0000 On 08/27/2010 05:17, pluknet wrote: > On 27 August 2010 00:09, Doug Barton wrote: >> On 08/26/2010 12:53 PM, pluknet wrote: >>> >>> [cc'ing current@ as rc@ looks too quite] >>> >>> Hi. >>> >>> Since ifconfig has grown to label interfaces with >>> ifconfig $ifname description "foobar", what about >>> to give it more life and store i/face descriptions >>> semi-permanently, so they will survive between reboots? >>> >>> This patch adds a functionality to rc.d to label >>> interfaces at boot time. >>> >>> Comments are welcome. >> >> This seems like a good addition, thanks. Please also write a patch for >> rc.conf.5 to describe this new functionality and I'll be happy to commit it. > > Xin Li helped me with updating rc.conf.5 (thanks!). > It's included in attached patch. > >> One note below. >> >> >>> --- etc/network.subr (revision 211280) >>> +++ etc/network.subr (working copy) >>> @@ -1187,6 +1187,24 @@ >>> return 0 >>> } >>> >>> +# ifnet_descr >>> +# Add description to all requested interfaces. >>> +# >>> +ifnet_descr() >>> +{ >>> + local _if _ifdescr >>> + >>> + # ifconfig_IF_descr >>> + for _if in `ifconfig -l`; do >>> + _ifdescr="`get_if_var $_if ifconfig_IF_descr`" >>> + if [ ! -z "$_ifdescr" ]; then >> >> This is probably better as [ -n "$_ifdescr" ] >> > > This was blindly copy&pasted after ifnet_rename(). > So, it makes sense probably to change test expression there as well. > [see ifnet_rename() proposed change below inline] > This change to ifnet_rename() is not included in attached patch > to not complicate things unnecessarily for now. > > Index: etc/network.subr > =================================================================== > --- etc/network.subr (revision 211280) > +++ etc/network.subr (working copy) > @@ -1179,7 +1179,7 @@ > # ifconfig_IF_name > for _if in `ifconfig -l`; do > _ifname=`get_if_var $_if ifconfig_IF_name` > - if [ ! -z "$_ifname" ]; then > + if [ -n "$_ifname" ]; then > ifconfig $_if name $_ifname > fi > done Was this ever committed ? If so does anyone have any referring svn revisions ? Also if this is committed or planned to be committed is there a chance it could be MFC'd ? Would be awesome if this was available on a production release without patching ;) Thanks in advance, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 06:29: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 83EC21065670 for ; Sun, 10 Oct 2010 06:29:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0498E8FC17 for ; Sun, 10 Oct 2010 06:29:40 +0000 (UTC) Received: by qwe4 with SMTP id 4so907757qwe.13 for ; Sat, 09 Oct 2010 23:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QXXFFsNT2JMqeFbsuwxQZUmACRdgtbZ5YdIupnPP17I=; b=NsKMmXCvXwBmIJfL4UKTkqKwTv3jHK1+uEq/mx4vbLF0hPcNp+QRmvEaGAetaDwKGD ZwSbhOoF9+ZfGTSGWUBgATnG143EzrH4ntmq5/eUlRq0fAqv9AYm6vpc6Tz5Z9ZALhuN e7vMjYH1ohmXzGt9gRG2kPEQyHNzLg3WuesmY= 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=Vnqm1WzqxfB2mxLvFrFsDva422WpvP21R6fduP+zeaQETV6pt1+T63CiUjVNDQLch8 sly0RhEnrCt70pgJ1J6fVU4E5tCFhZE+VHZnnOCj/cvR58npqcOvFgkvcBrL+xu/Itav p9ofFwKKHqoSzaRuxw/jH0q5nIeVPBFCMso/o= MIME-Version: 1.0 Received: by 10.224.49.72 with SMTP id u8mr3282269qaf.9.1286692180461; Sat, 09 Oct 2010 23:29:40 -0700 (PDT) Received: by 10.229.61.29 with HTTP; Sat, 9 Oct 2010 23:29:40 -0700 (PDT) In-Reply-To: <4CB135F5.20804@DataIX.net> References: <4C76CA06.5010001@FreeBSD.org> <4CB135F5.20804@DataIX.net> Date: Sun, 10 Oct 2010 10:29:40 +0400 Message-ID: From: Sergey Kandaurov To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-rc@freebsd.org, FreeBSD Current Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 06:29:41 -0000 On 10 October 2010 07:41, jhell wrote: > On 08/27/2010 05:17, pluknet wrote: >> On 27 August 2010 00:09, Doug Barton wrote: >>> On 08/26/2010 12:53 PM, pluknet wrote: >>>> >>>> [cc'ing current@ as rc@ looks too quite] >>>> >>>> Hi. >>>> >>>> Since ifconfig has grown to label interfaces with >>>> ifconfig $ifname description "foobar", what about >>>> to give it more life and store i/face descriptions >>>> semi-permanently, so they will survive between reboots? >>>> >>>> This patch adds a functionality to rc.d to label >>>> interfaces at boot time. >>>> >>>> Comments are welcome. >>> >>> This seems like a good addition, thanks. Please also write a patch for >>> rc.conf.5 to describe this new functionality and I'll be happy to commi= t it. >> >> Xin Li helped me with updating rc.conf.5 (thanks!). >> It's included in attached patch. >> >>> =A0One note below. >>> >>> >>>> --- etc/network.subr =A0 =A0(revision 211280) >>>> +++ etc/network.subr =A0 =A0(working copy) >>>> @@ -1187,6 +1187,24 @@ >>>> =A0 =A0 =A0 =A0 return 0 >>>> =A0} >>>> >>>> +# ifnet_descr >>>> +# =A0 =A0 =A0Add description to all requested interfaces. >>>> +# >>>> +ifnet_descr() >>>> +{ >>>> + =A0 =A0 =A0 local _if _ifdescr >>>> + >>>> + =A0 =A0 =A0 # ifconfig_IF_descr >>>> + =A0 =A0 =A0 for _if in `ifconfig -l`; do >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ifdescr=3D"`get_if_var $_if ifconfig_IF= _descr`" >>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ ! -z "$_ifdescr" ]; then >>> >>> This is probably better as [ -n "$_ifdescr" ] >>> >> >> This was blindly copy&pasted after ifnet_rename(). >> So, it makes sense probably to change test expression there as well. >> [see ifnet_rename() proposed change below inline] >> This change to ifnet_rename() is not included in attached patch >> to not complicate things unnecessarily for now. >> >> Index: etc/network.subr >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- etc/network.subr =A0 =A0(revision 211280) >> +++ etc/network.subr =A0 =A0(working copy) >> @@ -1179,7 +1179,7 @@ >> =A0 =A0 =A0 =A0 # ifconfig_IF_name >> =A0 =A0 =A0 =A0 for _if in `ifconfig -l`; do >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ifname=3D`get_if_var $_if ifconfig_IF_n= ame` >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ ! -z "$_ifname" ]; then >> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ -n "$_ifname" ]; then >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifconfig $_if name $_ifn= ame >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fi >> =A0 =A0 =A0 =A0 done > > Was this ever committed ? If so does anyone have any referring svn > revisions ? > > Also if this is committed or planned to be committed is there a chance > it could be MFC'd ? > > Would be awesome if this was available on a production release without > patching ;) > Hi. I'm going to commit this after a proper review. --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 15:54: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 ED61D1065698; Sun, 10 Oct 2010 15:54:18 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 5E8598FC15; Sun, 10 Oct 2010 15:54:17 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 888F545E8E; Sun, 10 Oct 2010 17:54:16 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DB24245CAC; Sun, 10 Oct 2010 17:54:10 +0200 (CEST) Date: Sun, 10 Oct 2010 17:53:40 +0200 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20101010155340.GQ1733@garage.freebsd.pl> References: <4CA3BD7C.9080306@feral.com> <4CA4CCE3.9060408@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0Qexx6XJGNEACt6j" Content-Disposition: inline In-Reply-To: <4CA4CCE3.9060408@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: sos@FreeBSD.org, FreeBSD-Current , Andriy Gapon , phk@FreeBSD.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:54:19 -0000 --0Qexx6XJGNEACt6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: > Andriy Gapon wrote: > > on 30/09/2010 01:28 Matthew Jacob said the following: > >> If something like that was in place, I assure you that things would st= art to use > >> it very quickly. > >=20 > > I am not sure about this. > > Because, e.g. I don't see an easy way to know that media is changed in = scsi_cd > > driver. That is, without polling. I don't consider polling to be an e= asy way for > > a number of reasons. >=20 > SATA specification defines concept of Asynchronous Notification. It is > already used by port multipliers to report about PHY events. It is also > supposed to be used by CD drives to report media change. I haven't seen > such devices yet, but hope they may appear sometimes. >=20 > And even without AN support it would be nice to implement proper > handling for SCSI "UA - media changed" errors within CAM. It still won't > be perfect without using polling, but probably still something. I'd like to know the original reason why CD device is represented by GEOM provider and not CD media. For my naive thinking CD media should be GEOM provider that we taste once the media is inserted and orphan once the media is removed. I don't see any reasons for CD device to be useful GEOM provider, but maybe I'm overlooking something. Poul-Henning or Soren, do you remember who made and why this design choice? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --0Qexx6XJGNEACt6j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyx4YQACgkQForvXbEpPzR0cQCg7Lp+sRsDQmbHM5t3NLUqH8F0 9o8An2F+2UZHWAjtP0DNvDTLbrK/TeJk =cIDJ -----END PGP SIGNATURE----- --0Qexx6XJGNEACt6j-- From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 17:23: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 E86E4106564A; Sun, 10 Oct 2010 17:23:07 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2B08FC08; Sun, 10 Oct 2010 17:23:07 +0000 (UTC) Received: by iwn8 with SMTP id 8so3556428iwn.13 for ; Sun, 10 Oct 2010 10:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=d7g4DoVKRWMbEIFdnmlUlgbeCBw1Co15pK/o6HMWNnM=; b=sygAbuTnT5MXLfF0rP7FuyPdQ+612wmr+aTjQ5au3CI6TgK+LN2GFZxyB0ZcBmFxTh P7YdN/xjSYomYZoohQAuonSGZCdqFE0lbsvaOtUtcMI+q5Q5KQmQsQCauBNo8GoKuB2c PwmlSxLcmEZlVHTHItJ/rZCunCkqXghAAV/DI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=l0Yc5ZVsI2jIidmBpMlxp+6twome9JutXKeh8ENm4aqGAcdYSClLrIihFhgKgbb69D Jgq6D1Fntl2w4tCA1kUqMGpa/uUOQCQ6OfTMHAH/F2D5KHyCUFFe6lvGiK4rMqUpnft9 oEApApUbAxRXerGIo1qkHKlZShjm0ByxA2RU4= MIME-Version: 1.0 Received: by 10.231.12.11 with SMTP id v11mr2224140ibv.13.1286731385016; Sun, 10 Oct 2010 10:23:05 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sun, 10 Oct 2010 10:23:04 -0700 (PDT) In-Reply-To: References: <4C76CA06.5010001@FreeBSD.org> <4CB135F5.20804@DataIX.net> Date: Sun, 10 Oct 2010 10:23:04 -0700 X-Google-Sender-Auth: MLEfSXI5xQ9R6uf-VpTNILAmtPM Message-ID: From: Garrett Cooper To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-rc@freebsd.org, FreeBSD Current Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 17:23:08 -0000 On Sat, Oct 9, 2010 at 11:29 PM, Sergey Kandaurov wrote= : > On 10 October 2010 07:41, jhell wrote: >> On 08/27/2010 05:17, pluknet wrote: >>> On 27 August 2010 00:09, Doug Barton wrote: >>>> On 08/26/2010 12:53 PM, pluknet wrote: >>>>> >>>>> [cc'ing current@ as rc@ looks too quite] >>>>> >>>>> Hi. >>>>> >>>>> Since ifconfig has grown to label interfaces with >>>>> ifconfig $ifname description "foobar", what about >>>>> to give it more life and store i/face descriptions >>>>> semi-permanently, so they will survive between reboots? >>>>> >>>>> This patch adds a functionality to rc.d to label >>>>> interfaces at boot time. >>>>> >>>>> Comments are welcome. >>>> >>>> This seems like a good addition, thanks. Please also write a patch for >>>> rc.conf.5 to describe this new functionality and I'll be happy to comm= it it. >>> >>> Xin Li helped me with updating rc.conf.5 (thanks!). >>> It's included in attached patch. >>> >>>> =A0One note below. >>>> >>>> >>>>> --- etc/network.subr =A0 =A0(revision 211280) >>>>> +++ etc/network.subr =A0 =A0(working copy) >>>>> @@ -1187,6 +1187,24 @@ >>>>> =A0 =A0 =A0 =A0 return 0 >>>>> =A0} >>>>> >>>>> +# ifnet_descr >>>>> +# =A0 =A0 =A0Add description to all requested interfaces. >>>>> +# >>>>> +ifnet_descr() >>>>> +{ >>>>> + =A0 =A0 =A0 local _if _ifdescr >>>>> + >>>>> + =A0 =A0 =A0 # ifconfig_IF_descr >>>>> + =A0 =A0 =A0 for _if in `ifconfig -l`; do >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ifdescr=3D"`get_if_var $_if ifconfig_I= F_descr`" >>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ ! -z "$_ifdescr" ]; then >>>> >>>> This is probably better as [ -n "$_ifdescr" ] >>>> >>> >>> This was blindly copy&pasted after ifnet_rename(). >>> So, it makes sense probably to change test expression there as well. >>> [see ifnet_rename() proposed change below inline] >>> This change to ifnet_rename() is not included in attached patch >>> to not complicate things unnecessarily for now. >>> >>> Index: etc/network.subr >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- etc/network.subr =A0 =A0(revision 211280) >>> +++ etc/network.subr =A0 =A0(working copy) >>> @@ -1179,7 +1179,7 @@ >>> =A0 =A0 =A0 =A0 # ifconfig_IF_name >>> =A0 =A0 =A0 =A0 for _if in `ifconfig -l`; do >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _ifname=3D`get_if_var $_if ifconfig_IF_= name` >>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ ! -z "$_ifname" ]; then >>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if [ -n "$_ifname" ]; then >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ifconfig $_if name $_if= name >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fi >>> =A0 =A0 =A0 =A0 done >> >> Was this ever committed ? If so does anyone have any referring svn >> revisions ? >> >> Also if this is committed or planned to be committed is there a chance >> it could be MFC'd ? >> >> Would be awesome if this was available on a production release without >> patching ;) >> > > Hi. > > I'm going to commit this after a proper review. I'm not sure it would get resolved after this commit, but one minor annoyance is that restarting the netif rc.d script purges all gateways set, so I have to do and restart the routing rc.d script (if my connectivity doesn't get whacked). I think there was something else with natd and ipfw that I've run into in the past where I've restarted those scripts and things weren't all puppydogs and rainbows on my CURRENT systems. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 18:51: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 B8EAE106566B; Sun, 10 Oct 2010 18:51:30 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 69D608FC12; Sun, 10 Oct 2010 18:51:30 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Sun, 10 Oct 2010 14:40:41 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id EB2F133C00; Sun, 10 Oct 2010 14:40:41 -0400 (EDT) Date: Sun, 10 Oct 2010 14:40:41 -0400 From: Ed Maste To: Robert Watson Message-ID: <20101010184041.GA10473@sandvine.com> Mail-Followup-To: Ed Maste , Robert Watson , Attilio Rao , FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: Attilio Rao , freebsd-net@freebsd.org, Sergey Kandaurov , FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:51:30 -0000 On Sat, Oct 09, 2010 at 02:15:39AM +0100, Robert Watson wrote: > Network dumps would be a great addition to the FreeBSD debugging suite! > [...] It seems that at EuroBSDCon there was a discussion of Contiki[1] and the uIPv6 stack[2] that it contains, and I think something like this could be a great future enhancement for netdump and similar consumers. Ideally I'd like to see us get to having a clean, simple API for transmitting and receiving packets and a basic stack that could be shared by netdump, as well as a network-enabled ddb, gdb backend, and perhaps console. Using the uIPv6 stack for this would get us v6 support (as the name suggests), as well as a supported / maintained stack vs. what is in netdump now. It's also BSD-licensed. This could be a good future project, although I think the current netdump implementation is worth bringing in soon (taking into account the good feedback received to date, of course). [1] http://www.sics.se/contiki/about-contiki.html [2] http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html - Ed From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 20:55: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 4B9A9106564A; Sun, 10 Oct 2010 20:55:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EED5A8FC15; Sun, 10 Oct 2010 20:55:18 +0000 (UTC) Received: by fxm12 with SMTP id 12so458003fxm.13 for ; Sun, 10 Oct 2010 13:55:18 -0700 (PDT) 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=hLEH8lVjiftOSjZYVk+Rje3Mg8/6K75AxntWjOn5DBE=; b=LQmUuhtLm5X19uqQ4hR14hcwIk1LbWcN2DcUce3HjV9X1Cc32Jxn/nPpGyeZm3k07R 21Z3qeBG1WlmerC4Y/Y3QMVkeHNnaMUXoz0qkztjPVijOAg0eRfx8iP6ta1neBUxkh15 T7NoY5mm+kgvwUdRK0e6fkbaRksR41LGHxc+U= 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=GzR7fEYLw7cSUVWle5FI0tcXuBof/dlPy6w3HgOINtMDw7dyuIBEv7IE/pg6IYQHV/ oGPI6qnxnrCY5/Ascoo5FvXH16Ul6KS5aS2pM50sely+lXwdGsi/ZLqZGgZ2GGdf0/g1 OgcvqD9H3thmythRuSm0AxmygxvKbjBQtZdLk= Received: by 10.223.86.80 with SMTP id r16mr1025394fal.42.1286744117105; Sun, 10 Oct 2010 13:55:17 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (1.eurobsdcon.punkt.de [217.29.34.225]) by mx.google.com with ESMTPS id z19sm2090551fam.40.2010.10.10.13.55.15 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 13:55:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CB22833.70304@FreeBSD.org> Date: Sun, 10 Oct 2010 22:55:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4CA3BD7C.9080306@feral.com> <4CA4CCE3.9060408@FreeBSD.org> <20101010155340.GQ1733@garage.freebsd.pl> In-Reply-To: <20101010155340.GQ1733@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: sos@FreeBSD.org, FreeBSD-Current , Andriy Gapon , phk@FreeBSD.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:55:20 -0000 Pawel Jakub Dawidek wrote: > On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: >> Andriy Gapon wrote: >>> on 30/09/2010 01:28 Matthew Jacob said the following: >>>> If something like that was in place, I assure you that things would start to use >>>> it very quickly. >>> I am not sure about this. >>> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd >>> driver. That is, without polling. I don't consider polling to be an easy way for >>> a number of reasons. >> SATA specification defines concept of Asynchronous Notification. It is >> already used by port multipliers to report about PHY events. It is also >> supposed to be used by CD drives to report media change. I haven't seen >> such devices yet, but hope they may appear sometimes. >> >> And even without AN support it would be nice to implement proper >> handling for SCSI "UA - media changed" errors within CAM. It still won't >> be perfect without using polling, but probably still something. > > I'd like to know the original reason why CD device is represented by > GEOM provider and not CD media. For my naive thinking CD media should be > GEOM provider that we taste once the media is inserted and orphan once > the media is removed. I don't see any reasons for CD device to be useful > GEOM provider, but maybe I'm overlooking something. > > Poul-Henning or Soren, do you remember who made and why this design choice? SCSI drivers receive no notification on media insertion. Somebody should poll device. At this moment it is handled by consumers. Indeed not sure it is the best idea. If we want driver to bother with this polling - we may do as you propose. Actually in sdhci(4) driver I am doing this way - mmcsdX device appears when card inserted and disappears on removal. I think first thing that may brake if there will be no cdX device - loading the media with some commands. Also it may be non-intuitive that drive is present, but disk is not registered in GEOM. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Oct 10 22:24: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 AE4EF106564A for ; Sun, 10 Oct 2010 22:24:28 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC2E8FC0A for ; Sun, 10 Oct 2010 22:24:28 +0000 (UTC) Received: from 165-100-179-94.pool.ukrtel.net ([94.179.100.165] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5448-000EBS-LX for freebsd-current@freebsd.org; Mon, 11 Oct 2010 01:08:24 +0300 Date: Mon, 11 Oct 2010 01:08:23 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Message-ID: <20101011010823.1363825f@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 22:24:28 -0000 Hi! My system has an svn r213507 FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun Oct 10 22:43:18 EEST 2010 root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 after upgrading to r213666 my system hangs after logging into gdm had to go back to r213507 Thanks! From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 05:30:26 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 55654106564A; Mon, 11 Oct 2010 05:30:26 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id D05568FC20; Mon, 11 Oct 2010 05:30:25 +0000 (UTC) Received: by yxe42 with SMTP id 42so663172yxe.13 for ; Sun, 10 Oct 2010 22:30:25 -0700 (PDT) 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 :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=DKf1Q7/+zFcDbnky3Y/efslqtwxCJ4gju8gIpJ1Xsqg=; b=Pungeoh6NH2SnTTg9ME9A9LwfshJTge/8xd2CkwXLL3MVbCdiBjIK0erVICz3pdXW4 VmbQCGtQYszwS1K1f0PIvrJqrTpBxhw274bz/87h7+d2wHWoGR9dbHEaXxhPC/T+KHpq vbr+AkEq6zlSULi/XFvnmG3Sev7RIm+RjFIu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=L9ZGWS1IZbJOw+OGab9q2Rh7v7I5Pzr6kyI+Vix8iacIICs+fOCxsRXf4KVQkxQcrl LBHqlJRVR6mzChNjLpFwz/aGCWa/ww6j9Z8LeRArfSrcmpbJY5iJwZTNM9QAmnI2WeQS 7HmmdWu/KuCSyslwQhnWVgenOh9sFxm2Yo4r4= Received: by 10.151.8.8 with SMTP id l8mr6125156ybi.251.1286775024931; Sun, 10 Oct 2010 22:30:24 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-144-115.dsl.klmzmi.sbcglobal.net [99.181.144.115]) by mx.google.com with ESMTPS id q5sm2425962ybe.6.2010.10.10.22.30.18 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 22:30:19 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CB2A0E9.50108@DataIX.net> Date: Mon, 11 Oct 2010 01:30:17 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Garrett Cooper References: <4C76CA06.5010001@FreeBSD.org> <4CB135F5.20804@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , FreeBSD Current , Sergey Kandaurov , freebsd-rc@FreeBSD.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 05:30:26 -0000 On 10/10/2010 13:23, Garrett Cooper wrote: > > I'm not sure it would get resolved after this commit, but one > minor annoyance is that restarting the netif rc.d script purges all > gateways set, so I have to do and restart the routing rc.d script (if > my connectivity doesn't get whacked). I think there was something else > with natd and ipfw that I've run into in the past where I've restarted > those scripts and things weren't all puppydogs and rainbows on my > CURRENT systems. > > Thanks, > -Garrett Is that the dynamic routes only or also the static routes ? Either or if it would be any of the above it would be nice if these were kept if it was only a restart of the interface, but offhand nothing comes to mind that could prevent this from happening since the routes are acting according to when the interface becomes inactive then the route becomes meaningless. Maybe if the action of 'restart' to etc/rc.d/netif could also call etc/rc.d/routing with 'restart' if the configuration of the interface happens to match one of the recorded routes in rc.conf(5). Just a thought. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 05:34:25 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 33863106566C; Mon, 11 Oct 2010 05:34:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CBCD28FC19; Mon, 11 Oct 2010 05:34:24 +0000 (UTC) Received: by iwn8 with SMTP id 8so4121114iwn.13 for ; Sun, 10 Oct 2010 22:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PqOYSSeXvVolNAgpkvRhqbTUYaXP1pSokAmbhdPxdlc=; b=KAmLNkJc4qKx1Re5vaYCZGbhQgNGYjuaFSO/4chRo/zFSoRiFJHgZKc2vAVxrih9KQ 91srXtv+7R1GrAQ5jTiZMU8/crm2a1WzME7DGGCAOR0sBQTwD2qEHwPVRrSbfN/iTcuC I5BF1S/5eLGnETImEwNObUBj+MizEccx3kZq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CGIMBqnHNEqhz4i6ub/Nf52aTIaf/v74wla0gdPbyKbUDX3Rud5AzpsMa19vgvXLKn qDcksaGnegXYxvPGqCGIZC8rtvSk29GCrwrabdr0cw/xpdSdtvQNNRYZbyDlKnUYEfSD YAVkz7i+7WYLY4h8eMF6HV9Akj58y3nkKFM60= MIME-Version: 1.0 Received: by 10.231.150.139 with SMTP id y11mr4316284ibv.80.1286775263870; Sun, 10 Oct 2010 22:34:23 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Sun, 10 Oct 2010 22:34:23 -0700 (PDT) In-Reply-To: <4CB2A0E9.50108@DataIX.net> References: <4C76CA06.5010001@FreeBSD.org> <4CB135F5.20804@DataIX.net> <4CB2A0E9.50108@DataIX.net> Date: Sun, 10 Oct 2010 22:34:23 -0700 X-Google-Sender-Auth: sldb57rLgku4d62xtQZeOnSL-wQ Message-ID: From: Garrett Cooper To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , freebsd-rc@freebsd.org, Sergey Kandaurov , FreeBSD Current Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 05:34:25 -0000 On Sun, Oct 10, 2010 at 10:30 PM, jhell wrote: > On 10/10/2010 13:23, Garrett Cooper wrote: >> >> =A0 =A0 I'm not sure it would get resolved after this commit, but one >> minor annoyance is that restarting the netif rc.d script purges all >> gateways set, so I have to do and restart the routing rc.d script (if >> my connectivity doesn't get whacked). I think there was something else >> with natd and ipfw that I've run into in the past where I've restarted >> those scripts and things weren't all puppydogs and rainbows on my >> CURRENT systems. >> >> Thanks, >> -Garrett > > Is that the dynamic routes only or also the static routes ? > > Either or if it would be any of the above it would be nice if these were > kept if it was only a restart of the interface, but offhand nothing > comes to mind that could prevent this from happening since the routes > are acting according to when the interface becomes inactive then the > route becomes meaningless. > > Maybe if the action of 'restart' to etc/rc.d/netif could also call > etc/rc.d/routing with 'restart' if the configuration of the interface > happens to match one of the recorded routes in rc.conf(5). I just tested it on my test machine and it happens with static routes; dynamic routes automatically get reset by dhclient, et all. It used to be for both though in earlier versions of FreeBSD, IIRC. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 05:45: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 61319106566B; Mon, 11 Oct 2010 05:45:07 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id C4C558FC0A; Mon, 11 Oct 2010 05:45:06 +0000 (UTC) Received: by ywh2 with SMTP id 2so643705ywh.13 for ; Sun, 10 Oct 2010 22:45:05 -0700 (PDT) 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 :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Cgxm1YPkfHfacz3m6SHMdChw7/wpp6LTodaw1xgbV5g=; b=YnzziOcGNr8di/wJkGJJKLXKSB1jNgA9Jphsl7HmJjCH8n2W4cL/MpWrQltsdWDudO RWkMapRl2rgVfoxXZo42plgIY327BJca7lLMyBFjRifO1Q7VN9NODjB6d7AgqOR48/3p q2YNTeWFIeTXf5AcQIWlBUe27jfUVTDQWcEXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=E2BD4OKad/ElsiArcFUIWx2KJzl48R9JGy52Fql3NWkBIOoa7MBB+vEV0AieFN0jCy Uwnd24cPpIc5SGeBOrYcB+3jZcjgFxpwIYrVCNGLZ4LkV2ocLfusUL0JFlpiCeCEYYhg HjllIySeHF41BeBGpUrmpeWVPFZn95tgNaBNo= Received: by 10.236.108.34 with SMTP id p22mr10795856yhg.72.1286775905834; Sun, 10 Oct 2010 22:45:05 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-144-115.dsl.klmzmi.sbcglobal.net [99.181.144.115]) by mx.google.com with ESMTPS id f43sm4817742yhc.26.2010.10.10.22.45.03 (version=SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 22:45:04 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4CB2A45E.8070602@DataIX.net> Date: Mon, 11 Oct 2010 01:45:02 -0400 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100917 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Garrett Cooper References: <4C76CA06.5010001@FreeBSD.org> <4CB135F5.20804@DataIX.net> <4CB2A0E9.50108@DataIX.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Doug Barton , freebsd-rc@FreeBSD.org, Sergey Kandaurov Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 05:45:07 -0000 On 10/11/2010 01:34, Garrett Cooper wrote: > On Sun, Oct 10, 2010 at 10:30 PM, jhell wrote: >> On 10/10/2010 13:23, Garrett Cooper wrote: >>> >>> I'm not sure it would get resolved after this commit, but one >>> minor annoyance is that restarting the netif rc.d script purges all >>> gateways set, so I have to do and restart the routing rc.d script (if >>> my connectivity doesn't get whacked). I think there was something else >>> with natd and ipfw that I've run into in the past where I've restarted >>> those scripts and things weren't all puppydogs and rainbows on my >>> CURRENT systems. >>> >>> Thanks, >>> -Garrett >> >> Is that the dynamic routes only or also the static routes ? >> >> Either or if it would be any of the above it would be nice if these were >> kept if it was only a restart of the interface, but offhand nothing >> comes to mind that could prevent this from happening since the routes >> are acting according to when the interface becomes inactive then the >> route becomes meaningless. >> >> Maybe if the action of 'restart' to etc/rc.d/netif could also call >> etc/rc.d/routing with 'restart' if the configuration of the interface >> happens to match one of the recorded routes in rc.conf(5). > > I just tested it on my test machine and it happens with static > routes; dynamic routes automatically get reset by dhclient, et all. It > used to be for both though in earlier versions of FreeBSD, IIRC. > Thanks! > -Garrett That has been something that has bugged me for a while. Ill take a look at some possibilities (with just the scripts in rc.d) that might be a solution to this soon as I get a chance over this next week. It might just be meaningful to merge the correct areas of the routing script into the netif scripts restart and relevant sections. Ill look at this as soon as I get a chance. Unless if someone has another theory about whether those routes should be deleted at all if the ifnet address still exists on the parent interface ?. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 07:59: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 6EA09106564A for ; Mon, 11 Oct 2010 07:59:07 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2F0DC8FC14 for ; Mon, 11 Oct 2010 07:59:06 +0000 (UTC) Received: from 165-100-179-94.pool.ukrtel.net ([94.179.100.165] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5DHl-0008AA-VJ for freebsd-current@freebsd.org; Mon, 11 Oct 2010 10:59:06 +0300 Date: Mon, 11 Oct 2010 10:59:04 +0300 From: Ivan Klymenko To: freebsd-current@freebsd.org Message-ID: <20101011105904.70dd7e7f@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 07:59:07 -0000 =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko wrote: > > Hi! > > > > My system has an svn r213507 > > > > FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun > > Oct 10 22:43:18 EEST 2010 > > root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > > > > after upgrading to r213666 my system hangs after logging into gdm > > > > had to go back to r213507 >=20 > What video driver are you using? > -Garrett >=20 >=20 NVIDIA Driver Version: 260.19.06 but Xorg successfully starts and GDM login screen appears system hangs after a few seconds after entering the password ... I noticed the following: gvfsd does not create a directory of the form / var/tmp/gvfs-- may hang system due to gvfsd? From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 09:04: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 7A1511065670 for ; Mon, 11 Oct 2010 09:04:28 +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 C371C8FC1A for ; Mon, 11 Oct 2010 09:04:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19084; Mon, 11 Oct 2010 12:04:24 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P5EIy-000KUk-2F; Mon, 11 Oct 2010 12:04:24 +0300 Message-ID: <4CB2D317.9010004@icyb.net.ua> Date: Mon, 11 Oct 2010 12:04:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ivan Klymenko References: <20101011105904.70dd7e7f@ukr.net> In-Reply-To: <20101011105904.70dd7e7f@ukr.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 09:04:28 -0000 on 11/10/2010 10:59 Ivan Klymenko said the following: > Ð’ Sun, 10 Oct 2010 15:37:55 -0700 > Garrett Cooper пишет: > >> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko wrote: >>> Hi! >>> >>> My system has an svn r213507 >>> >>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun >>> Oct 10 22:43:18 EEST 2010 >>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 >>> >>> after upgrading to r213666 my system hangs after logging into gdm >>> >>> had to go back to r213507 >> >> What video driver are you using? >> -Garrett >> >> > > NVIDIA Driver Version: 260.19.06 > > but Xorg successfully starts and GDM login screen appears > system hangs after a few seconds after entering the password ... > I noticed the following: gvfsd does not create a directory of the > form / var/tmp/gvfs-- may hang system due to gvfsd? If you can access the system remotely or quickly switch to console, then you should be able to examine state of your system and get some facts. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 10: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 92C3D106564A; Mon, 11 Oct 2010 10:29:44 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD2F8FC14; Mon, 11 Oct 2010 10:29:43 +0000 (UTC) Received: from alph.d.allbsd.org (p3165-ipbf2308funabasi.chiba.ocn.ne.jp [114.148.246.165]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.3) with ESMTP id o9BATO0F004040; Mon, 11 Oct 2010 19:29:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.4/8.14.4) with ESMTP id o9BATMUK051667; Mon, 11 Oct 2010 19:29:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 11 Oct 2010 19:29:14 +0900 (JST) Message-Id: <20101011.192914.82309657.hrs@allbsd.org> To: pluknet@gmail.com From: Hiroki Sato In-Reply-To: References: <4C76CA06.5010001@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Oct_11_19_29_14_2010_564)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 11 Oct 2010 19:29:38 +0900 (JST) X-Spam-Status: No, score=-96.6 required=13.0 tests=CONTENT_TYPE_PRESENT, FAKEDWORD_BACKQUOTE,FORGED_RCVD_IP,MIMEQENC,QENCPTR2,RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org, freebsd-rc@FreeBSD.org Subject: Re: [RFC] ifconfig description support in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 10:29:44 -0000 ----Security_Multipart(Mon_Oct_11_19_29_14_2010_564)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, pluknet wrote in : pl> On 27 August 2010 00:09, Doug Barton wrote: pl> > On 08/26/2010 12:53 PM, pluknet wrote: pl> >> pl> >> [cc'ing current@ as rc@ looks too quite] pl> >> pl> >> Hi. pl> >> pl> >> Since ifconfig has grown to label interfaces with pl> >> ifconfig $ifname description "foobar", what about pl> >> to give it more life and store i/face descriptions pl> >> semi-permanently, so they will survive between reboots? pl> >> pl> >> This patch adds a functionality to rc.d to label pl> >> interfaces at boot time. pl> >> pl> >> Comments are welcome. pl> > pl> > This seems like a good addition, thanks. Please also write a patc= h for pl> > rc.conf.5 to describe this new functionality and I'll be happy to= commit it. pl> = pl> Xin Li helped me with updating rc.conf.5 (thanks!). pl> It's included in attached patch. (snip) pl> >> + =A0 =A0 =A0 # ifconfig_IF_descr pl> >> + =A0 =A0 =A0 for _if in `ifconfig -l`; do I think using "ifconfig -l" here is not a good idea. Setting a description for each interface in a function invoked by ifn_start() would be better. This is beacuse the netif script can be run not only at boottime but also via devd or by hand for a specific interface. So, if the ifnet_descr is there, "/etc/rc.d/netif start IF" does not make it run. Since the description is a per-interface property, "/etc/rc.d/netif start IF" should set one, and "/etc/rc.d/netif stop IF" should clear one, IMHO. Also, "ifconfig -l" is not compatible with $network_interfaces, so you need to use list_net_interface() for that purpose instead (if you move ifnet_descr() into ifn_start() it is useless, though). -- Hiroki ----Security_Multipart(Mon_Oct_11_19_29_14_2010_564)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkyy5voACgkQTyzT2CeTzy3yDgCgwGGsv/3cH6Ayycz4Yi4hsaYw rmMAnjEngZlkiYgjmOr/t4m48P91GtYv =ilJ8 -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Oct_11_19_29_14_2010_564)---- From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 13:17: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 B06F21065679; Mon, 11 Oct 2010 13:17:20 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 49F248FC17; Mon, 11 Oct 2010 13:17:20 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 6B9F62A28D2D; Mon, 11 Oct 2010 15:17:19 +0200 (CEST) Date: Mon, 11 Oct 2010 15:17:19 +0200 From: Ed Schouten To: delphij@FreeBSD.org, current@FreeBSD.org Message-ID: <20101011131719.GA90530@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: truss calls setpgid() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:17:20 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I've been seeing this bug for a very long time, but I was too lazy to figure out the root cause earlier. It is TTY related, but in this case the TTY layer is not to blame. It does things correctly. When you run a command in truss which calls ioctls on TTYs, it just locks up. This is because truss runs jobs in a separate process group. This also means you cannot send signals to it: truss sleep 10000 Pressing ^C here won't work. I've fixed it locally like this: Index: usr.bin/truss/setup.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- usr.bin/truss/setup.c (revision 213113) +++ usr.bin/truss/setup.c (working copy) @@ -78,7 +78,6 @@ } if (pid =3D=3D 0) { /* Child */ ptrace(PT_TRACE_ME, 0, 0, 0); - setpgid (0, 0);=20 execvp(command[0], command); err(1, "execvp %s", command[0]); Question: was this intentional? I'd rather not break stuff. Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyzDl8ACgkQ52SDGA2eCwXUlwCdGaKtxCJecJfxRbJSSpLsXHSm TJUAn1QwBeKzcpgAdX7p9nMH4+hmTgZO =UZAB -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 13:57: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 8A6EF106566C; Mon, 11 Oct 2010 13:57:56 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id 455158FC08; Mon, 11 Oct 2010 13:57:56 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 6FA894D771; Mon, 11 Oct 2010 15:57:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id qWenzp4tdYIi; Mon, 11 Oct 2010 15:57:52 +0200 (CEST) Received: from danger-mbp.local (adsl-dyn172.78-99-31.t-com.sk [78.99.31.172]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: danger@rulez.sk) by services.syscare.sk (Postfix) with ESMTPSA id 544E24D756; Mon, 11 Oct 2010 15:57:52 +0200 (CEST) Message-ID: <4CB317DF.5040501@FreeBSD.org> Date: Mon, 11 Oct 2010 15:57:51 +0200 From: Daniel Gerzo Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12pre) Gecko/20101010 Lanikai/3.1.6pre MIME-Version: 1.0 To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:57:56 -0000 Hello, this is a reminder to anyone who's planning on sending a status report to us. The submission deadline is 15th Sept 2010. I know that many of you guys have spent last few days in Karlsruhe (and I hope to receive some additional reports covering the EuroBSDCon/DevSummit events), so that I understand that the reports might still be on their way. I just wanted to note, that to this date we have received only 5 entries. Please, if you are planning to send your entry, let us know so we can at least count with you and poke you if we don't receive it soon :) -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports - 3Q/2010 Date: Thu, 30 Sep 2010 08:29:48 +0200 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, hackers@freebsd.org, questions@freebsd.org Dear all, I would like to remind you that the next round of status reports covering the third quarter of 2010 is due on October 15th, 2010. This initiative is very welcome in our community. Therefore, I would like to ask you to submit your status reports soon, so that we can compile the report on time. Do not hesitate and write us a few lines - a short description about what you are working on, what are your plans and goals, so we can inform our community about your great work! Check out the reports from the past to get some inspiration of what your submission should look like. If you know about a project that should be included in the status report, please let us know as well, so we can poke the responsible people to provide us with something useful. Updates to submissions from the last report are welcome too. Note that the submissions are accepted from anyone involved with the FreeBSD community, you do not have to be a FreeBSD committer. Submissions about anything related to FreeBSD are very welcome! Please email us the filled-in XML template which can be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form located at http://www.freebsd.org/cgi/monthly.cgi. For more information, please visit http://www.freebsd.org/news/status/. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 15:37:09 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 31CC2106566B for ; Mon, 11 Oct 2010 15:37:09 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE25F8FC14 for ; Mon, 11 Oct 2010 15:37:08 +0000 (UTC) Received: by ywh2 with SMTP id 2so826849ywh.13 for ; Mon, 11 Oct 2010 08:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zXOYiEtLH2x45uN64z0B88iIDfqtrd9OpMo+HDOtqOk=; b=qzRf9ae3uewOau08sWUsUL7QVSo8lUs6CVoePDGAByZEV1puCNOD95PB2tVUmHANQe X6aBMcdOBpLEab6akbp8tKGnoOWA8zvyoZKXzcCD2R6ybY1PLn8cTrZ5FcsdUfINbeCA aEhI1a75O15SyAnFZKLTn1VUp3RLnP/wMbp4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=u7/gpqccdCTgVH6G0GAm2Q8klnFyJwcUmcHtgxNFdrSU0RXn7EXockkSu2dzIoyMkE 1j/1UQU1KHE7vN0Y+aSdvyaVVInWbnu6frbDmgq7T9iSp1nrl44s8BnPQy5q4RcnBMMI O7dPJwAbUqVTgjy1qAU9dAzhXum7vEMBQWw2c= MIME-Version: 1.0 Received: by 10.42.29.133 with SMTP id r5mr1885447icc.235.1286811426773; Mon, 11 Oct 2010 08:37:06 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Mon, 11 Oct 2010 08:37:05 -0700 (PDT) In-Reply-To: <4CB2D317.9010004@icyb.net.ua> References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> Date: Mon, 11 Oct 2010 08:37:05 -0700 X-Google-Sender-Auth: WaYltcnAJ37RauqsF2yMSAGgpB8 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ivan Klymenko , freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:37:09 -0000 On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon wrote: > on 11/10/2010 10:59 Ivan Klymenko said the following: >> =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 >> Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko wrote: >>>> Hi! >>>> >>>> My system has an svn r213507 >>>> >>>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun >>>> Oct 10 22:43:18 EEST 2010 >>>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 >>>> >>>> after upgrading to r213666 my system hangs after logging into gdm >>>> >>>> had to go back to r213507 >>> >>> What video driver are you using? >>> -Garrett >>> >>> >> >> NVIDIA Driver Version: 260.19.06 >> >> but Xorg successfully starts and GDM login screen appears >> system hangs after a few seconds after entering the password ... >> I noticed the following: gvfsd does not create a directory of the >> form / var/tmp/gvfs-- may hang system due to gvfsd? That seems a bit interesting. The other thing you can do is start running a binary search on the breakage because you have a range of good versions vs bad versions to look through. > If you can access the system remotely or quickly switch to console, then = you > should be able to examine state of your system and get some facts. If you have ddb compiled into the kernel (and you should) try CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead, which would require a serial connection (RS-232 or IEEE-1394). HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 16:46: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 03BD61065670 for ; Mon, 11 Oct 2010 16:46:22 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id A9B1F8FC1A for ; Mon, 11 Oct 2010 16:46:21 +0000 (UTC) Received: by gwb15 with SMTP id 15so1331071gwb.13 for ; Mon, 11 Oct 2010 09:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uu5ToV5BKnzjZo6cmu/6XiJlZvPEe+2px7GRmZ6rZNw=; b=GTazjjolLZaxWTxCyqoVhFunPBY00zmOAMDt+yao7oXcE9i6OCP7A1DvHZv5pWZrJT MzwaFL8odX7un/nI/XCqfNgnT49G3U6i13HyB1MbiA4zGqSuFfRkpHkZeaw0r6BdBMCs p5fcQF8bJIrlL/vaDnjO0N33XQ03k0jSl5gNg= 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=OPX7xhvrcNgfJK03Ep+okjmta32bC2FagKNYvuYPX2h7fDLKUTYFDvCSZceQ3z1OPM t4Qk9dMmVj0+hBlDLT4G+76oSeLZPNOlYKlgeV1vTJ0v290liIqaIe4LhPDsGvibhwUK f+OabKrUbKx6Eb1pz169+0PdPvW/gcWWt1RGM= MIME-Version: 1.0 Received: by 10.42.214.195 with SMTP id hb3mr2248177icb.407.1286815580287; Mon, 11 Oct 2010 09:46:20 -0700 (PDT) Received: by 10.231.167.65 with HTTP; Mon, 11 Oct 2010 09:46:20 -0700 (PDT) In-Reply-To: <4CA0184B.7030506@freebsd.org> References: <4CA0184B.7030506@freebsd.org> Date: Mon, 11 Oct 2010 11:46:20 -0500 Message-ID: From: "Sam Fourman Jr." To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: -current under Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 16:46:22 -0000 On Sun, Sep 26, 2010 at 11:06 PM, Julian Elischer wrot= e: > =A0After bruce C gave me the hint of kern.eventtimer.periodic=3D1, I was = able to > boot -current on my vps > at rootbsd.com, but it hangs on reboot.. some time before the unmounts as > the > file systems need to be cleaned on the next successful boot. > Has anyone had any experience with this? > > unfortunately I can't yet tell you the version of Xen in use there. > For what it is worth, I have the same shutdown issues on real hardware using 9 CURRENT eg dell 6450 (old p3 xeon) dell 2650 as well as a white box (below is a partial dmesg) Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #20: Mon Oct 11 07:57:28 CDT 2010 root@FNFS.PuffyBSD.Com:/usr/obj/usr/src/sys/FNFS amd64 CPU: AMD Phenom(tm) II X4 B50 Processor (3100.28-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x100f42 Family =3D 10 Model =3D 4 S= tepping =3D 2 Features=3D0x178bfbff Features2=3D0x802009 AMD Features=3D0xee500800 AMD Features2=3D0x37ff TSC: P-state invariant real memory =3D 8589934592 (8192 MB) avail memory =3D 7986311168 (7616 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <041410 APIC1753> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20100915/tbfadt-655) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <041410 XSDT1753> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of fed40000, 5000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 I think I have a HP machine that wont shut down either --=20 Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 17:34: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 4F85A106564A for ; Mon, 11 Oct 2010 17:34:36 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 085308FC08 for ; Mon, 11 Oct 2010 17:34:35 +0000 (UTC) Received: by qyk30 with SMTP id 30so570867qyk.13 for ; Mon, 11 Oct 2010 10:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=o4vvpEkeY29RTfUeYRVNLefVvb5d8xZOruB2cDDs2f8=; b=ibX2x09v9DJUSjokvgWU5N2naAjJyoyekzlu37TzTS7HSu5vjxy99hg/a6oR1YPFqQ A7W1c25zkonQq9K0sDEJfHB2HidvGqD/jCtM7Z4ZARJ+Ql2e1kI1jpJbgMnpQ3lV0JFB b/qKE+NjuJmE2KdYVYzsLmz1ak8ojLeyHaalc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=O1BZlvU4xHtIKGUiNhgaCC3Yb5UWt9j0RWMNyk9hgdPISGuu13QElX8oZv4A+GScNd M/4Xd9Wg1OZLpULeG9sNJmgCJHviX0FXgJQqPlVjfbZkXuXZ935OJPGGkZqxjqukp95D b9mhneNZ50fgxcqHVuYd6/s2oovDaDnTog6+0= MIME-Version: 1.0 Received: by 10.229.246.83 with SMTP id lx19mr5343851qcb.127.1286818475140; Mon, 11 Oct 2010 10:34:35 -0700 (PDT) Received: by 10.220.178.1 with HTTP; Mon, 11 Oct 2010 10:34:34 -0700 (PDT) Date: Mon, 11 Oct 2010 17:34:34 +0000 Message-ID: From: Paul B Mahol To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: panic on kthread_exit under INVARIANTS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 17:34:36 -0000 Hi, If kernel threads were created via kproc_kthread_add() when last kernel thread exits it will trigger panic. It panics in queue.h .... probably introduced with recent commit. From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:13: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 AD7A2106578A; Mon, 11 Oct 2010 18:13:38 +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 364698FC13; Mon, 11 Oct 2010 18:13:38 +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 E1CC946B35; Mon, 11 Oct 2010 14:13:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 040AF8A029; Mon, 11 Oct 2010 14:13:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Oct 2010 11:03:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CA3BD7C.9080306@feral.com> <20101010155340.GQ1733@garage.freebsd.pl> <4CB22833.70304@FreeBSD.org> In-Reply-To: <4CB22833.70304@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010111103.26780.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Motin , Pawel Jakub Dawidek , Andriy Gapon , sos@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:13:41 -0000 On Sunday, October 10, 2010 4:55:15 pm Alexander Motin wrote: > Pawel Jakub Dawidek wrote: > > On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: > >> Andriy Gapon wrote: > >>> on 30/09/2010 01:28 Matthew Jacob said the following: > >>>> If something like that was in place, I assure you that things would start to use > >>>> it very quickly. > >>> I am not sure about this. > >>> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd > >>> driver. That is, without polling. I don't consider polling to be an easy way for > >>> a number of reasons. > >> SATA specification defines concept of Asynchronous Notification. It is > >> already used by port multipliers to report about PHY events. It is also > >> supposed to be used by CD drives to report media change. I haven't seen > >> such devices yet, but hope they may appear sometimes. > >> > >> And even without AN support it would be nice to implement proper > >> handling for SCSI "UA - media changed" errors within CAM. It still won't > >> be perfect without using polling, but probably still something. > > > > I'd like to know the original reason why CD device is represented by > > GEOM provider and not CD media. For my naive thinking CD media should be > > GEOM provider that we taste once the media is inserted and orphan once > > the media is removed. I don't see any reasons for CD device to be useful > > GEOM provider, but maybe I'm overlooking something. > > > > Poul-Henning or Soren, do you remember who made and why this design choice? > > SCSI drivers receive no notification on media insertion. Somebody should > poll device. At this moment it is handled by consumers. Indeed not sure > it is the best idea. If we want driver to bother with this polling - we > may do as you propose. Actually in sdhci(4) driver I am doing this way - > mmcsdX device appears when card inserted and disappears on removal. > > I think first thing that may brake if there will be no cdX device - > loading the media with some commands. Also it may be non-intuitive that > drive is present, but disk is not registered in GEOM. With CD drives you are also rather stuck in that the existing ABI for controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are done on the /dev/cdX device. Ideally enclosures for removable media would be separate devices from the removable media itself, but a lot of existing software for CD's would break if this changes now. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:13: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 E8FE510657BC for ; Mon, 11 Oct 2010 18:13:41 +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 008A58FC08 for ; Mon, 11 Oct 2010 18:13:40 +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 A855546BA4; Mon, 11 Oct 2010 14:13:39 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BD3E98A01D; Mon, 11 Oct 2010 14:13:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Oct 2010 11:10:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101011105904.70dd7e7f@ukr.net> In-Reply-To: <20101011105904.70dd7e7f@ukr.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201010111110.17980.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ivan Klymenko Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:13:42 -0000 On Monday, October 11, 2010 3:59:04 am Ivan Klymenko wrote: > =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >=20 > > On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko wrote: > > > Hi! > > > > > > My system has an svn r213507 > > > > > > FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun > > > Oct 10 22:43:18 EEST 2010 > > > root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > > > > > > after upgrading to r213666 my system hangs after logging into gdm > > > > > > had to go back to r213507 > >=20 > > What video driver are you using? > > -Garrett > >=20 > >=20 >=20 > NVIDIA Driver Version: 260.19.06 >=20 > but Xorg successfully starts and GDM login screen appears > system hangs after a few seconds after entering the password ... > I noticed the following: gvfsd does not create a directory of the > form / var/tmp/gvfs-- may hang system due to gvfsd? Did you recompile the nvidia.ko module after upgrading? =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:13: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 EA6C710657C0; Mon, 11 Oct 2010 18:13:41 +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 B866E8FC0A; Mon, 11 Oct 2010 18:13:41 +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 5C1B146BA0; Mon, 11 Oct 2010 14:13:41 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 825788A027; Mon, 11 Oct 2010 14:13:40 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Oct 2010 11:13:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101011131719.GA90530@hoeg.nl> In-Reply-To: <20101011131719.GA90530@hoeg.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010111113.30648.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Ed Schouten , delphij@freebsd.org Subject: Re: truss calls setpgid() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:13:42 -0000 On Monday, October 11, 2010 9:17:19 am Ed Schouten wrote: > Hi all, > > I've been seeing this bug for a very long time, but I was too lazy to > figure out the root cause earlier. It is TTY related, but in this case > the TTY layer is not to blame. It does things correctly. > > When you run a command in truss which calls ioctls on TTYs, it just > locks up. This is because truss runs jobs in a separate process group. > This also means you cannot send signals to it: > > truss sleep 10000 > > Pressing ^C here won't work. > > I've fixed it locally like this: > > Index: usr.bin/truss/setup.c > =================================================================== > --- usr.bin/truss/setup.c (revision 213113) > +++ usr.bin/truss/setup.c (working copy) > @@ -78,7 +78,6 @@ > } > if (pid == 0) { /* Child */ > ptrace(PT_TRACE_ME, 0, 0, 0); > - setpgid (0, 0); > execvp(command[0], command); > err(1, "execvp %s", command[0]); > > Question: was this intentional? I'd rather not break stuff. It was added in the switch from procfs to ptrace(), but it's not clear why the child has a new process group. It doesn't look like truss ever tries to kill the entire group for example. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:13: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 F1B931065863; Mon, 11 Oct 2010 18:13:43 +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 815FB8FC12; Mon, 11 Oct 2010 18:13:43 +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 27CEC46B0C; Mon, 11 Oct 2010 14:13:43 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 34DC58A009; Mon, 11 Oct 2010 14:13:42 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 11 Oct 2010 11:50:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101005153926.88b4c1e1.daichi@freebsd.org> In-Reply-To: <20101005153926.88b4c1e1.daichi@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010111150.00785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Daichi GOTO , freebsd-current@freebsd.org, Garrett Cooper Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:13:44 -0000 On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: > Next step discussion engaged from this research I guess. > > Should we do change FreeBSD's fcntl(2) to return correct l_pid > when called with F_SETLK? Or keep current behavior?? > I want to hear other developers ideas and suggetions. POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's current behavior is fine. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:36:05 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 9558B106564A for ; Mon, 11 Oct 2010 18:36:05 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 49FA38FC13 for ; Mon, 11 Oct 2010 18:36:05 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5NEA-0009H4-Mv ; Mon, 11 Oct 2010 21:36:03 +0300 Date: Mon, 11 Oct 2010 21:36:01 +0300 From: Ivan Klymenko To: John Baldwin Message-ID: <20101011213601.2c2f71a7@ukr.net> In-Reply-To: <201010111110.17980.jhb@freebsd.org> References: <20101011105904.70dd7e7f@ukr.net> <201010111110.17980.jhb@freebsd.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:36:05 -0000 =D0=92 Mon, 11 Oct 2010 11:10:17 -0400 John Baldwin =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Monday, October 11, 2010 3:59:04 am Ivan Klymenko wrote: > > =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > > Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >=20 > > > On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko > > > wrote: > > > > Hi! > > > > > > > > My system has an svn r213507 > > > > > > > > FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: > > > > Sun Oct 10 22:43:18 EEST 2010 > > > > root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > > > > > > > > after upgrading to r213666 my system hangs after logging into > > > > gdm > > > > > > > > had to go back to r213507 > > >=20 > > > What video driver are you using? > > > -Garrett > > >=20 > > >=20 > >=20 > > NVIDIA Driver Version: 260.19.06 > >=20 > > but Xorg successfully starts and GDM login screen appears > > system hangs after a few seconds after entering the password ... > > I noticed the following: gvfsd does not create a directory of the > > form / var/tmp/gvfs-- may hang system due to gvfsd? >=20 > Did you recompile the nvidia.ko module after upgrading? >=20 Yes, of course. From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:43: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 80E3C106564A; Mon, 11 Oct 2010 18:43:47 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 33D6D8FC17; Mon, 11 Oct 2010 18:43:46 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5NLa-000AOZ-UU ; Mon, 11 Oct 2010 21:43:43 +0300 Date: Mon, 11 Oct 2010 21:43:42 +0300 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101011214342.5457874b@ukr.net> In-Reply-To: References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:43:47 -0000 =D0=92 Mon, 11 Oct 2010 08:37:05 -0700 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon wrote: > > on 11/10/2010 10:59 Ivan Klymenko said the following: > >> =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > >> Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko > >>> wrote: > >>>> Hi! > >>>> > >>>> My system has an svn r213507 > >>>> > >>>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: > >>>> Sun Oct 10 22:43:18 EEST 2010 > >>>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > >>>> > >>>> after upgrading to r213666 my system hangs after logging into gdm > >>>> > >>>> had to go back to r213507 > >>> > >>> What video driver are you using? > >>> -Garrett > >>> > >>> > >> > >> NVIDIA Driver Version: 260.19.06 > >> > >> but Xorg successfully starts and GDM login screen appears > >> system hangs after a few seconds after entering the password ... > >> I noticed the following: gvfsd does not create a directory of the > >> form / var/tmp/gvfs-- may hang system due to gvfsd? >=20 > That seems a bit interesting. > The other thing you can do is start running a binary search on the > breakage because you have a range of good versions vs bad versions to > look through. >=20 > > If you can access the system remotely or quickly switch to console, > > then you should be able to examine state of your system and get > > some facts. >=20 > If you have ddb compiled into the kernel (and you should) try > CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead, > which would require a serial connection (RS-232 or IEEE-1394). > HTH, > -Garrett Thank you! I'll try to recompile the kernel with DDB shortly and after blocking press ctrl+alt+esc, which would show the trace output... From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:49: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 A9E3A106564A for ; Mon, 11 Oct 2010 18:49:44 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2F78FC0C for ; Mon, 11 Oct 2010 18:49:44 +0000 (UTC) Received: by qyk30 with SMTP id 30so326934qyk.13 for ; Mon, 11 Oct 2010 11:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=bhoI+54Z3JKLe4mBcEssFOivshZZL2vhcQCfhbEwO0c=; b=NemGaJ6EKw0Px/Jj6g7LCZotCt6WVDXRGGlIFGnSWNraLaoolJtpuza2kQpVmvex9W tNOcBojVO7zY9r5An602z/UqtkkmwZHncWIJuEreV4TGvi29si0WfYCttw8P71YZ+JQl 76JwZSmRcNZSAEGCEV+dp0lOHfzflY611v6o8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; b=izLyzv0KDVLNs1NONM6fS+pfkPo76Lht+HDAIMRUDnZTCG6su986JUOC6g7/jkmK3D oCmGn9xinoPVHqwf6/5+vmuaemHAD6M6o7uQ5aGUCRLxwXZ0bZw4okBrxMfI+PII/hTd OB02J12HU4u3+M2HxizV7ZDCNLpHKwqgsmG3w= Received: by 10.229.228.137 with SMTP id je9mr5326916qcb.219.1286822979718; Mon, 11 Oct 2010 11:49:39 -0700 (PDT) Received: from localhost (tor-exit-proxy3-readme.formlessnetworking.net [208.53.142.39]) by mx.google.com with ESMTPS id l14sm3808066qck.17.2010.10.11.11.49.37 (version=SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 11:49:39 -0700 (PDT) From: Anonymous To: Ivan Klymenko References: <20101011105904.70dd7e7f@ukr.net> Date: Mon, 11 Oct 2010 22:49:29 +0400 In-Reply-To: <20101011105904.70dd7e7f@ukr.net> (Ivan Klymenko's message of "Mon, 11 Oct 2010 10:59:04 +0300") Message-ID: <86lj64h8ee.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:49:44 -0000 Ivan Klymenko writes: > =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > Garrett Cooper writes: > >>On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko wrote: >>> My system has an svn r213507 >>> >>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun >>> Oct 10 22:43:18 EEST 2010 >>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 >>> >>> after upgrading to r213666 my system hangs after logging into gdm >>> >>> had to go back to r213507 >> >> What video driver are you using? > > NVIDIA Driver Version: 260.19.06 Do you have local patches to make it compile on /head? Could they be the cause of the hang? 260.19.04 and 260.19.06 use taskqueue_run(9) that was removed in /head@r210377. From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 19:18: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 7159C106566B for ; Mon, 11 Oct 2010 19:18:20 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 305B48FC13 for ; Mon, 11 Oct 2010 19:18:19 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5Nt4-000IWz-T3 ; Mon, 11 Oct 2010 22:18:19 +0300 Date: Mon, 11 Oct 2010 22:18:18 +0300 From: Ivan Klymenko To: Anonymous Message-ID: <20101011221818.0ed775b1@ukr.net> In-Reply-To: <86lj64h8ee.fsf@gmail.com> References: <20101011105904.70dd7e7f@ukr.net> <86lj64h8ee.fsf@gmail.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 19:18:20 -0000 =D0=92 Mon, 11 Oct 2010 22:49:29 +0400 Anonymous =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Ivan Klymenko writes: >=20 > > =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > > Garrett Cooper writes: > > > >>On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko > >>wrote: > >>> My system has an svn r213507 > >>> > >>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: Sun > >>> Oct 10 22:43:18 EEST 2010 > >>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > >>> > >>> after upgrading to r213666 my system hangs after logging into gdm > >>> > >>> had to go back to r213507 > >> > >> What video driver are you using? > > > > NVIDIA Driver Version: 260.19.06 >=20 > Do you have local patches to make it compile on /head? Could they be > the cause of the hang? 260.19.04 and 260.19.06 use taskqueue_run(9) > that was removed in /head@r210377. patches exist, but the cause is not in them - as Xorg starts, the system hangs after a few seconds after entering the password box to login gdm without a password - it works --- src/nvidia_os.c.orig 2010-09-15 01:26:27.000000000 +0300 +++ src/nvidia_os.c 2010-09-15 01:27:51.000000000 +0300 @@ -13,6 +13,67 @@ #include "nv.h" #include "nv-freebsd.h" =20 +struct taskqueue { + STAILQ_HEAD(, task) tq_queue; + const char *tq_name; + taskqueue_enqueue_fn tq_enqueue; + void *tq_context; + struct task *tq_running; + struct mtx tq_mutex; + struct thread **tq_threads; + int tq_tcount; + int tq_spin; + int tq_flags; +}; + +static void taskqueue_run(struct taskqueue *, struct task **); + +static __inline void +TQ_LOCK(struct taskqueue *tq) +{ + if (tq->tq_spin) + mtx_lock_spin(&tq->tq_mutex); + else + mtx_lock(&tq->tq_mutex); +} + +static __inline void +TQ_UNLOCK(struct taskqueue *tq) +{ + if (tq->tq_spin) + mtx_unlock_spin(&tq->tq_mutex); + else + mtx_unlock(&tq->tq_mutex); +} + +static void +taskqueue_run(struct taskqueue *queue, struct task **tpp) +{ =20 + struct task *task; + int pending; + + mtx_assert(&queue->tq_mutex, MA_OWNED); + while (STAILQ_FIRST(&queue->tq_queue)) { + /* + * Carefully remove the first task from the queue and + * zero its pending count. + */ + task =3D STAILQ_FIRST(&queue->tq_queue); + STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); + pending =3D task->ta_pending; + task->ta_pending =3D 0; + task->ta_running =3D tpp; + *tpp =3D task; + TQ_UNLOCK(queue); + + task->ta_func(task->ta_context, pending); + + TQ_LOCK(queue); + *tpp =3D NULL; + wakeup(task); + } +} + MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations"); TASKQUEUE_DEFINE_THREAD(nvidia); =20 @@ -332,7 +393,8 @@ =20 RM_STATUS NV_API_CALL os_flush_work_queue(void) { - taskqueue_run(taskqueue_nvidia); +// taskqueue_run(taskqueue_nvidia); + taskqueue_run(taskqueue_nvidia, &taskqueue_nvidia->tq_running); return RM_OK; } =20 From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 20:12:30 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 76C271065672; Mon, 11 Oct 2010 20:12:30 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 1CBE68FC19; Mon, 11 Oct 2010 20:12:29 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DA44D45EE6; Mon, 11 Oct 2010 22:12:28 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C137145E93; Mon, 11 Oct 2010 22:12:22 +0200 (CEST) Date: Mon, 11 Oct 2010 22:11:56 +0200 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20101011201156.GB2346@garage.freebsd.pl> References: <4CA3BD7C.9080306@feral.com> <20101010155340.GQ1733@garage.freebsd.pl> <4CB22833.70304@FreeBSD.org> <201010111103.26780.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: <201010111103.26780.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon , sos@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:12:30 -0000 --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 11, 2010 at 11:03:26AM -0400, John Baldwin wrote: > With CD drives you are also rather stuck in that the existing ABI for > controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) a= re > done on the /dev/cdX device. Ideally enclosures for removable media would > be separate devices from the removable media itself, but a lot of existing > software for CD's would break if this changes now. Right, but I still wonder if we could execute provider orphan and retaste on various events like media insertion or removal. If media is removed we orphan provider and recreate it, which will trigger retaste, and this is fine there will be nothing to read from or write to (we will simply return errors as we do now, I think). This way we nicely co-operate with GEOM, but also with other tools that don't require media to be present (if there is no media devfs entry still exists and handles ioctls, it just return errors on read requests). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyzb4wACgkQForvXbEpPzS2kACgwm7yHuK8uCEsKGhWFY0Wc1Fp gMwAnive/5dGqazefom+qhiMVioJ7RVb =5s5S -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 20:45: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 884B41065670 for ; Mon, 11 Oct 2010 20:45:41 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE838FC1F for ; Mon, 11 Oct 2010 20:45:40 +0000 (UTC) Received: by qyk30 with SMTP id 30so467211qyk.13 for ; Mon, 11 Oct 2010 13:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=dlFmYF+aFCv1jd5wMfG/CsQZW8JvErpwr87KLkJ1kSI=; b=wfsmLa/FhV7O0lFEvMRpluMtXCY8QZYuAK6MduwXvllQELI4T9fzVWiYwzezpwZvQ0 qsidQ9PGVHaMaBrLpcxRrqta5Dx1stp0ds2zxKwi6tLoHV7mlYwNvv+cK1RiZ+KYfnvc T5QgyUCltu9bpPPOt9ixSH1/tMlek/80eymxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=r5+4fUfdtlv1DSjrt5mGjMUwXua2QNwctdwstmlUVY0f/moSX56r3pR/qte2nL+PR5 HKtzEHsmGXLSDnzM031g8CX45l4BkoIC54xg1UZ1m7B8hjqrjX6TmcRR4XLfuW4PGvWQ EtOdO6YotmJlng78/DGLZBhA2GPzgH0OIcJ+c= MIME-Version: 1.0 Received: by 10.224.184.65 with SMTP id cj1mr4923074qab.95.1286829940016; Mon, 11 Oct 2010 13:45:40 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Mon, 11 Oct 2010 13:45:39 -0700 (PDT) Date: Mon, 11 Oct 2010 15:45:39 -0500 Message-ID: From: "Sam Fourman Jr." To: FreeBSD Current , Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: nfs zfs lockup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:45:41 -0000 I believe NFS is upsetting ZFS v15 on FreeBSD current (kernel sources from today) this happened while trying to sftp a 4gb file here is a back trace # procstat -k 2675 2436 1081 18 5 0 PID TID COMM TDNAME KSTACK 2675 100292 sftp-server - mi_switch sleepq_wait _cv_wait txg_wait_open zfs_freebsd_write VOP_WRITE_APV vn_write dofilewrite kern_writev write syscallenter syscall Xfast_syscall 2436 100337 cvsup - mi_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup zfs_dirent_lock zfs_dirlook zfs_lookup zfs_freebsd_lookup vfs_cache_lookup VOP_LOOKUP_APV lookup namei kern_statat_vnhook 1081 100299 nfsd nfsd: master mi_switch sleepq_wait _cv_wait zio_wait dbuf_read dbuf_findbp dbuf_hold_impl dbuf_hold dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup zfs_dirent_lock zfs_dirlook zfs_lookup zfs_freebsd_lookup vfs_cache_lookup VOP_LOOKUP_APV 1081 100318 nfsd nfsd: service mi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 1081 100319 nfsd nfsd: service mi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 1081 100320 nfsd nfsd: service mi_switch sleepq_wait __lockmgr_args vop_stdlock VOP_LOCK1_APV _vn_lock zfs_fhtovp nfsvno_fhtovp nfsd_fhtovp nfsrvd_dorpc nfssvc_program svc_run_internal svc_thread_start fork_exit fork_trampoline 18 100081 syncer - mi_switch sleepq_wait _cv_wait zio_wait zil_commit zfs_sync sync_fsync sync_vnode sched_sync fork_exit fork_trampoline 5 100071 zfskern arc_reclaim_thre mi_switch sleepq_timedwait _cv_timedwait arc_reclaim_thread fork_exit fork_trampoline 5 100072 zfskern l2arc_feed_threa mi_switch sleepq_timedwait _cv_timedwait l2arc_feed_thread fork_exit fork_trampoline 5 100125 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait txg_thread_wait txg_quiesce_thread fork_exit fork_trampoline 5 100126 zfskern txg_thread_enter mi_switch sleepq_timedwait _cv_timedwait txg_thread_wait txg_sync_thread fork_exit fork_trampoline 5 100182 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait txg_quiesce_thread fork_exit fork_trampoline 5 100183 zfskern txg_thread_enter mi_switch sleepq_wait _cv_wait zio_wait dsl_pool_sync spa_sync txg_sync_thread fork_exit fork_trampoline 0 100000 kernel swapper mi_switch sleepq_timedwait _sleep scheduler mi_startup btext 0 100016 kernel firmware taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100021 kernel acpi_task_0 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100022 kernel acpi_task_1 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100023 kernel acpi_task_2 mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100024 kernel kqueue taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100026 kernel thread taskq mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100059 kernel em0 taskq mi_switch sleepq_wait msleep_spin taskqueue_thread_loop fork_exit fork_trampoline 0 100067 kernel system_taskq_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100068 kernel system_taskq_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100069 kernel system_taskq_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100070 kernel system_taskq_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100073 kernel deadlkres mi_switch sleepq_timedwait _sleep deadlkres fork_exit fork_trampoline 0 100084 kernel zio_null_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100085 kernel zio_null_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100086 kernel zio_read_issue_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100087 kernel zio_read_issue_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100088 kernel zio_read_issue_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100089 kernel zio_read_issue_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100090 kernel zio_read_issue_4 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100091 kernel zio_read_issue_5 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100092 kernel zio_read_issue_6 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100093 kernel zio_read_issue_7 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100094 kernel zio_read_intr_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100095 kernel zio_read_intr_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100096 kernel zio_read_intr_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100097 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100098 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100099 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100100 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100101 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100102 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100103 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100104 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100105 kernel zio_write_intr_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100106 kernel zio_write_intr_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100107 kernel zio_write_intr_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100108 kernel zio_write_intr_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100109 kernel zio_write_intr_4 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100110 kernel zio_write_intr_5 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100111 kernel zio_write_intr_6 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100112 kernel zio_write_intr_7 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100113 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100114 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100115 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100116 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100117 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100118 kernel zio_free_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100119 kernel zio_free_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100120 kernel zio_claim_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100121 kernel zio_claim_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100122 kernel zio_ioctl_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100123 kernel zio_ioctl_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100124 kernel zfs_vn_rele_task mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100127 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100141 kernel zio_null_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100142 kernel zio_null_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100143 kernel zio_read_issue_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100144 kernel zio_read_issue_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100145 kernel zio_read_issue_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100146 kernel zio_read_issue_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100147 kernel zio_read_issue_4 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100148 kernel zio_read_issue_5 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100149 kernel zio_read_issue_6 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100150 kernel zio_read_issue_7 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100151 kernel zio_read_intr_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100152 kernel zio_read_intr_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100153 kernel zio_read_intr_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100154 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100155 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100156 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100157 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100158 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100159 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100160 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100161 kernel zio_write_issue_ mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100162 kernel zio_write_intr_0 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100163 kernel zio_write_intr_1 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100164 kernel zio_write_intr_2 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100165 kernel zio_write_intr_3 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100166 kernel zio_write_intr_4 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100167 kernel zio_write_intr_5 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100168 kernel zio_write_intr_6 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100169 kernel zio_write_intr_7 mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100170 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100171 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100172 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100173 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100174 kernel zio_write_intr_h mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100175 kernel zio_free_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100176 kernel zio_free_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100177 kernel zio_claim_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100178 kernel zio_claim_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100179 kernel zio_ioctl_issue mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100180 kernel zio_ioctl_intr mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100181 kernel zfs_vn_rele_task mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100195 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100196 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100197 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100198 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100199 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100200 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100201 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100202 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100203 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100204 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100205 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100206 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100207 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100208 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100209 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100210 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100211 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100212 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100213 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100214 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100215 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100216 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100217 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100218 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100219 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100220 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100221 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100222 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100223 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100224 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100225 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100226 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100227 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100228 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100229 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100230 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100231 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100232 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100233 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100234 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100235 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100236 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100237 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100238 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100239 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100240 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100241 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100242 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100243 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100244 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100245 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100246 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100247 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100248 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100249 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100250 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100251 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100252 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100253 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100254 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100255 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100256 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100257 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100258 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100259 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100260 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100261 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline 0 100262 kernel zil_clean mi_switch sleepq_wait _sleep taskqueue_thread_loop fork_exit fork_trampoline -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 21:13: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 3F2471065673 for ; Mon, 11 Oct 2010 21:13:59 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out1.libero.it (cp-out1.libero.it [212.52.84.101]) by mx1.freebsd.org (Postfix) with ESMTP id 04BC38FC22 for ; Mon, 11 Oct 2010 21:13:58 +0000 (UTC) Received: from libero.it (192.168.33.220) by cp-out1.libero.it (8.5.115) id 4AB2342316216FD5; Mon, 11 Oct 2010 23:02:01 +0200 Date: Mon, 11 Oct 2010 23:02:01 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "jh" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 82.59.51.232 Cc: freebsd-current Subject: Re:HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 21:13:59 -0000 > > Since r213526 device names are checked on device registration. That is,= > if you call a make_dev*() function with an invalid device name, a panic= > will occur by default. For make_dev_credf(9) or make_dev_p(9) you can > specify the MAKEDEV_CHECKNAME flag to get an error return instead of a > panic. > > Invalid names are as follows: > > - empty name > - names longer than SPECNAMELEN > - names containing "." or ".." path component > - names ending with '/' > - already existing device names > > So, if you see a "bad si_name" panic you may have encountered a driver > bug. > > Currently several GEOM classes (notably geom_label) allow to create > devices with invalid names. Below is a link to a patch which converts > g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag. It's not= > a complete solution and essentially changes the panic to a printf. > > http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff > > -- > Jaakko Hi, I faced that kind of panic today and now I'm able to boot again into CURR= ENT after applying the patch and rebuilding kernel. The panic is caused by: g_dev_taste(): make_dev_p() failed (gp->name=3Dext2fs//, error=3D22) as I have a linux partition (I swear, it's for my mom!) on the same machi= ne. As I don't care about that partition (being ext4 I can't even mount it), = is there any solution other then applying the patch after every csup? Thanks Barbara From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 21:56:17 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 90C961065694; Mon, 11 Oct 2010 21:56:17 +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 7F05A8FC27; Mon, 11 Oct 2010 21:56:16 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA03120; Tue, 12 Oct 2010 00:56:14 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P5QLt-000LIm-OT; Tue, 12 Oct 2010 00:56:13 +0300 Message-ID: <4CB387FD.2030101@icyb.net.ua> Date: Tue, 12 Oct 2010 00:56:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4CA0184B.7030506@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: -current under Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 21:56:17 -0000 on 11/10/2010 19:46 Sam Fourman Jr. said the following: > On Sun, Sep 26, 2010 at 11:06 PM, Julian Elischer wrote: >> After bruce C gave me the hint of kern.eventtimer.periodic=1, I was able to >> boot -current on my vps >> at rootbsd.com, but it hangs on reboot.. some time before the unmounts as >> the >> file systems need to be cleaned on the next successful boot. >> Has anyone had any experience with this? >> >> unfortunately I can't yet tell you the version of Xen in use there. >> > > For what it is worth, I have the same shutdown issues on real hardware > using 9 CURRENT Breaking into ddb at that point and examining stacks of all threads[*] would greatly help to pinpoint the issue. [*] or forcing a dump for postmortem examination with kgdb. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 22:53: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 0A240106566C for ; Mon, 11 Oct 2010 22:53: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 DC7FC8FC15 for ; Mon, 11 Oct 2010 22:53:31 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9BMrVV1002909 for ; Mon, 11 Oct 2010 15:53:31 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9BMrVnL002908 for freebsd-current@freebsd.org; Mon, 11 Oct 2010 15:53:31 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Oct 2010 15:53:31 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20101011225331.GA2829@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 22:53:32 -0000 It seems recent changes to the bge driver are causing some problems with my hardware where the watchdog is now timing out. /var/log/messages contains 14:23:14 kernel: SMP: AP CPU #1 Launched! 14:23:14 kernel: Trying to mount root from ufs:/dev/ad6s1a 14:23:15 kernel: bge1: link state changed to UP 14:23:15 lpd[1190]: lpd startup: logging=0 14:23:15 ntpd[1224]: ntpd 4.2.4p5-a (1) 14:23:15 kernel: bge0: link state changed to UP 14:23:24 ntpd[1225]: time reset -0.677316 s 14:23:24 ntpd[1225]: kernel time sync status change 2001 14:31:01 kernel: bge0: watchdog timeout -- resetting 14:31:01 kernel: bge0: link state changed to DOWN 14:31:02 kernel: Limiting icmp unreach response from 613 to 200 packets/sec 14:31:04 ntpd[1225]: sendto(140.142.2.8) (fd=22): No route to host 14:31:04 kernel: bge0: link state changed to UP 14:31:30 kernel: Limiting icmp unreach response from 205 to 200 packets/sec 14:31:31 kernel: Limiting icmp unreach response from 203 to 200 packets/sec 15:40:11 su: kargl to root on /dev/pts/0 15:40:35 kernel: bge0: link state changed to DOWN 15:40:38 kernel: bge0: link state changed to UP The last 2 bge messages are from me manually using ifconfig to bring my net connect back to life. troutmask:kargl[206] sysctl -a | grep bge.0 dev.bge.0.%desc: Broadcom Gigabit Ethernet Controller, ASIC rev. 0x002100 dev.bge.0.%driver: bge dev.bge.0.%location: slot=9 function=0 handle=\_SB_.PCI0.GOLA.GLAN dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1648 subvendor=0x14e4 subdevice=0x1644 class=0x020000 dev.bge.0.%parent: pci2 dev.bge.0.forced_collapse: 0 dev.bge.0.forced_udpcsum: 0 dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 325 dev.bge.0.stats.DmaReadQueueFull: 0 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 469 dev.bge.0.stats.RingStatusUpdate: 330 dev.bge.0.stats.Interrupts: 330 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.ifHCInOctets: 569452 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UnicastPkts: 497 dev.bge.0.stats.rx.MulticastPkts: 1 dev.bge.0.stats.rx.FCSErrors: 0 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.ifHCOutOctets: 39056 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UnicastPkts: 468 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 1 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 dev.bge.0.wake: 0 In the time that it's taken me to compose this message the timeout has fire again. 15:47:01 kernel: Limiting icmp unreach response from 662 to 200 packets/sec 15:47:02 kernel: Limiting icmp unreach response from 446 to 200 packets/sec 15:47:03 kernel: Limiting icmp unreach response from 436 to 200 packets/sec 15:47:04 kernel: Limiting icmp unreach response from 464 to 200 packets/sec 15:47:05 kernel: Limiting icmp unreach response from 438 to 200 packets/sec 15:47:06 kernel: Limiting icmp unreach response from 445 to 200 packets/sec 15:47:07 kernel: bge0: watchdog timeout -- resetting 15:47:07 kernel: bge0: link state changed to DOWN 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec 15:47:11 kernel: bge0: link state changed to UP 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec 15:49:42 kernel: bge0: link state changed to DOWN 15:49:44 kernel: bge0: link state changed to UP I not seen these icmp unreach response messages. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 23:17:49 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 5ED2B106566C for ; Mon, 11 Oct 2010 23:17:49 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 28CFE8FC1A for ; Mon, 11 Oct 2010 23:17:48 +0000 (UTC) Received: by pzk33 with SMTP id 33so806029pzk.13 for ; Mon, 11 Oct 2010 16:17:48 -0700 (PDT) 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=fSJIo+int/wkMR3LLcDaxH3N6z/yM+k37rBMmXKN/oU=; b=cfCCInUuNN+GLe3xQ8QzweLbPPoduj7NNDzlnG4JHBVtLBemK9sDt6FAaVOTx4KzRC fbxJaYEfkkGJfFLVUETdp3nT0OrU3roEcvSfjJl4JjQYaZPPhqXe1UDK17B7iSIXhR5g Dn/5bN6wFSPoI1jhFaRL7U6CBS4J4ejzVhIFM= 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=O2YV5Bq0KzOQ7hiplDXgTW8SJpkihzUxIRS/oT3URKVZf4JZLU9lonKIqhBbuJJrfL v1DJmumlXAB3PmlcBcVyLyzFEU7CgOCVCR71fsVBru1vc52iwRocuip+zEn4UYRuz4F4 I1iFJJ77QU53tlz6PP+/PG6G8TvONIP3xv+6c= Received: by 10.142.173.20 with SMTP id v20mr642791wfe.164.1286839068277; Mon, 11 Oct 2010 16:17:48 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm8659000wfd.6.2010.10.11.16.17.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 16:17:46 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Oct 2010 16:16:04 -0700 From: Pyun YongHyeon Date: Mon, 11 Oct 2010 16:16:04 -0700 To: Steve Kargl Message-ID: <20101011231604.GI4607@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="7qSK/uQB79J36Y4o" Content-Disposition: inline In-Reply-To: <20101011225331.GA2829@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems 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 Oct 2010 23:17:49 -0000 --7qSK/uQB79J36Y4o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: > It seems recent changes to the bge driver are causing > some problems with my hardware where the watchdog is > now timing out. > > /var/log/messages contains > > 14:23:14 kernel: SMP: AP CPU #1 Launched! > 14:23:14 kernel: Trying to mount root from ufs:/dev/ad6s1a > 14:23:15 kernel: bge1: link state changed to UP > 14:23:15 lpd[1190]: lpd startup: logging=0 > 14:23:15 ntpd[1224]: ntpd 4.2.4p5-a (1) > 14:23:15 kernel: bge0: link state changed to UP > 14:23:24 ntpd[1225]: time reset -0.677316 s > 14:23:24 ntpd[1225]: kernel time sync status change 2001 > 14:31:01 kernel: bge0: watchdog timeout -- resetting > 14:31:01 kernel: bge0: link state changed to DOWN > 14:31:02 kernel: Limiting icmp unreach response from 613 to 200 packets/sec > 14:31:04 ntpd[1225]: sendto(140.142.2.8) (fd=22): No route to host > 14:31:04 kernel: bge0: link state changed to UP > 14:31:30 kernel: Limiting icmp unreach response from 205 to 200 packets/sec > 14:31:31 kernel: Limiting icmp unreach response from 203 to 200 packets/sec > 15:40:11 su: kargl to root on /dev/pts/0 > 15:40:35 kernel: bge0: link state changed to DOWN > 15:40:38 kernel: bge0: link state changed to UP > > The last 2 bge messages are from me manually using > ifconfig to bring my net connect back to life. > > troutmask:kargl[206] sysctl -a | grep bge.0 > dev.bge.0.%desc: Broadcom Gigabit Ethernet Controller, ASIC rev. 0x002100 > dev.bge.0.%driver: bge > dev.bge.0.%location: slot=9 function=0 handle=\_SB_.PCI0.GOLA.GLAN > dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1648 subvendor=0x14e4 subdevice=0x1644 class=0x020000 > dev.bge.0.%parent: pci2 > dev.bge.0.forced_collapse: 0 > dev.bge.0.forced_udpcsum: 0 > dev.bge.0.stats.FramesDroppedDueToFilters: 0 > dev.bge.0.stats.DmaWriteQueueFull: 0 > dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 > dev.bge.0.stats.NoMoreRxBDs: 0 > dev.bge.0.stats.InputDiscards: 0 > dev.bge.0.stats.InputErrors: 0 > dev.bge.0.stats.RecvThresholdHit: 325 > dev.bge.0.stats.DmaReadQueueFull: 0 > dev.bge.0.stats.DmaReadHighPriQueueFull: 0 > dev.bge.0.stats.SendDataCompQueueFull: 0 > dev.bge.0.stats.RingSetSendProdIndex: 469 > dev.bge.0.stats.RingStatusUpdate: 330 > dev.bge.0.stats.Interrupts: 330 > dev.bge.0.stats.AvoidedInterrupts: 0 > dev.bge.0.stats.SendThresholdHit: 0 > dev.bge.0.stats.rx.ifHCInOctets: 569452 > dev.bge.0.stats.rx.Fragments: 0 > dev.bge.0.stats.rx.UnicastPkts: 497 > dev.bge.0.stats.rx.MulticastPkts: 1 > dev.bge.0.stats.rx.FCSErrors: 0 > dev.bge.0.stats.rx.AlignmentErrors: 0 > dev.bge.0.stats.rx.xonPauseFramesReceived: 0 > dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 > dev.bge.0.stats.rx.ControlFramesReceived: 0 > dev.bge.0.stats.rx.xoffStateEntered: 0 > dev.bge.0.stats.rx.FramesTooLong: 0 > dev.bge.0.stats.rx.Jabbers: 0 > dev.bge.0.stats.rx.UndersizePkts: 0 > dev.bge.0.stats.rx.inRangeLengthError: 0 > dev.bge.0.stats.rx.outRangeLengthError: 0 > dev.bge.0.stats.tx.ifHCOutOctets: 39056 > dev.bge.0.stats.tx.Collisions: 0 > dev.bge.0.stats.tx.XonSent: 0 > dev.bge.0.stats.tx.XoffSent: 0 > dev.bge.0.stats.tx.flowControlDone: 0 > dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 > dev.bge.0.stats.tx.SingleCollisionFrames: 0 > dev.bge.0.stats.tx.MultipleCollisionFrames: 0 > dev.bge.0.stats.tx.DeferredTransmissions: 0 > dev.bge.0.stats.tx.ExcessiveCollisions: 0 > dev.bge.0.stats.tx.LateCollisions: 0 > dev.bge.0.stats.tx.UnicastPkts: 468 > dev.bge.0.stats.tx.MulticastPkts: 0 > dev.bge.0.stats.tx.BroadcastPkts: 1 > dev.bge.0.stats.tx.CarrierSenseErrors: 0 > dev.bge.0.stats.tx.Discards: 0 > dev.bge.0.stats.tx.Errors: 0 > dev.bge.0.wake: 0 > > In the time that it's taken me to compose this message > the timeout has fire again. > > 15:47:01 kernel: Limiting icmp unreach response from 662 to 200 packets/sec > 15:47:02 kernel: Limiting icmp unreach response from 446 to 200 packets/sec > 15:47:03 kernel: Limiting icmp unreach response from 436 to 200 packets/sec > 15:47:04 kernel: Limiting icmp unreach response from 464 to 200 packets/sec > 15:47:05 kernel: Limiting icmp unreach response from 438 to 200 packets/sec > 15:47:06 kernel: Limiting icmp unreach response from 445 to 200 packets/sec > 15:47:07 kernel: bge0: watchdog timeout -- resetting > 15:47:07 kernel: bge0: link state changed to DOWN > 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec > 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec > 15:47:11 kernel: bge0: link state changed to UP > 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec > 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec > 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec > 15:49:42 kernel: bge0: link state changed to DOWN > 15:49:44 kernel: bge0: link state changed to UP > > I not seen these icmp unreach response messages. > The icmp unreach has nothing to do with bge(4). Check whether a server that listens on an UDP port is still alive on your box. What worries me is bge(4) watchdog timeouts. It looks like your controller is BCM5704. I also have bge(4) regression report from marius on sparc64. He said r213945 seemed to cause the issue and I'm working on the issue. Could you also try the attached patch? --7qSK/uQB79J36Y4o Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.rxprod.patch" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 213695) +++ sys/dev/bge/if_bge.c (working copy) @@ -1619,9 +1619,6 @@ CSR_WRITE_4(sc, BGE_RX_STD_RCB_MAXLEN_FLAGS, rcb->bge_maxlen_flags); CSR_WRITE_4(sc, BGE_RX_STD_RCB_NICADDR, rcb->bge_nicaddr); - /* Reset the standard receive producer ring producer index. */ - bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, 0); - /* * Initialize the jumbo RX producer ring control * block. We set the 'ring disabled' bit in the @@ -1665,6 +1662,9 @@ bge_writembx(sc, BGE_MBX_RX_MINI_PROD_LO, 0); } + /* Reset the standard receive producer ring producer index. */ + bge_writembx(sc, BGE_MBX_RX_STD_PROD_LO, 0); + /* * The BD ring replenish thresholds control how often the * hardware fetches new BD's from the producer rings in host --7qSK/uQB79J36Y4o-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 23:49: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 EB4DB1065672 for ; Mon, 11 Oct 2010 23:49:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BD4308FC18 for ; Mon, 11 Oct 2010 23:49:43 +0000 (UTC) Received: by pwi6 with SMTP id 6so410536pwi.13 for ; Mon, 11 Oct 2010 16:49:43 -0700 (PDT) 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=SGMQ6XXRDAB8Qv+N5U4togmfTVtcKUmcpus0WEMBJxc=; b=F7FTTmQ0mo7nptYagWTzCHYenhJnPodTCiEnfcpOfOyfV7Ui+GepqT/sOhFvk+aXEB +K/GrzegYTFvKkXrB78y75Rxr8ZREpsqHdn45TwbhoKLf/9uHvcXDdruM/70TPQHhMB+ 2F9BrHWjpMrmv37mV7aNuycqeuj8MMGCyFrfc= 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=oJYRoJ/Yrlm6mN5x7lsxS1tflnflwjCzO3SUsVpEydO6542Smy0uGSYucFwkxHfqZC OQkOYgHqYu4nxqjrOZhbISfXd7H7hRUjuWSOWMX2S0NTKakoGXSrGH8uB+i4oEAVcssa GojNsW2rtJ8LglqPMHOdGx9oP4Yin3CC7qvQM= Received: by 10.114.46.20 with SMTP id t20mr7688443wat.181.1286840983092; Mon, 11 Oct 2010 16:49:43 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id f20sm11426028waj.20.2010.10.11.16.49.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 16:49:41 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Oct 2010 16:47:59 -0700 From: Pyun YongHyeon Date: Mon, 11 Oct 2010 16:47:59 -0700 To: freebsd-current@FreeBSD.org Message-ID: <20101011234759.GJ4607@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Call for bge(4) testers 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 Oct 2010 23:49:44 -0000 Hi, I have been working on bge(4) for a while to support a new Broadcom controller. Before doing that I committed many fundamental changes to bge(4) in order to make it easy to add more controllers. Because bge(4) supports many variants of controllers and have lots of workaround for specific controller revisions it is possible for me to break something on certain controllers. If you have bge(4) controller please give it try and let me know how it works. Thanks. From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 00:02: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 63DAE1065672 for ; Tue, 12 Oct 2010 00:02:17 +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 1ECDD8FC17 for ; Tue, 12 Oct 2010 00:02:17 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9C02GMF001595; Mon, 11 Oct 2010 17:02:16 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9C02G6r001594; Mon, 11 Oct 2010 17:02:16 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Oct 2010 17:02:16 -0700 From: Steve Kargl To: Pyun YongHyeon Message-ID: <20101012000216.GA1554@troutmask.apl.washington.edu> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101011231604.GI4607@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 00:02:17 -0000 On Mon, Oct 11, 2010 at 04:16:04PM -0700, Pyun YongHyeon wrote: > On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: > > > > In the time that it's taken me to compose this message > > the timeout has fire again. > > > > 15:47:07 kernel: bge0: watchdog timeout -- resetting > > 15:47:07 kernel: bge0: link state changed to DOWN > > 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec > > 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec > > 15:47:11 kernel: bge0: link state changed to UP > > 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec > > 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec > > 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec > > 15:49:42 kernel: bge0: link state changed to DOWN > > 15:49:44 kernel: bge0: link state changed to UP > > > > I not seen these icmp unreach response messages. > > > > The icmp unreach has nothing to do with bge(4). Check whether a > server that listens on an UDP port is still alive on your box. > What worries me is bge(4) watchdog timeouts. It looks like your > controller is BCM5704. I also have bge(4) regression report from > marius on sparc64. He said r213945 seemed to cause the issue and > I'm working on the issue. Could you also try the attached patch? The patch did not help. In fact, the icmp (which may be a side effect of the bge0 device wedging) has become much worse. SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad6s1a bge1: link state changed to UP bge0: link state changed to UP Limiting icmp unreach response from 3433 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2017 to 200 packets/sec Limiting icmp unreach response from 2049 to 200 packets/sec bge0: watchdog timeout -- resetting bge0: link state changed to DOWN Limiting icmp unreach response from 1962 to 200 packets/sec Limiting icmp unreach response from 2174 to 200 packets/sec Limiting icmp unreach response from 2180 to 200 packets/sec Limiting icmp unreach response from 2163 to 200 packets/sec bge0: link state changed to UP (removing 50 or so icmp messages). I don't know if the following helps, but thought I would include it here. troutmask:sgk[204] ping hpc PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available ping: sendto: No buffer space available -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 00:11:11 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 452DF106564A for ; Tue, 12 Oct 2010 00:11:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10B418FC17 for ; Tue, 12 Oct 2010 00:11:10 +0000 (UTC) Received: by pxi4 with SMTP id 4so447121pxi.13 for ; Mon, 11 Oct 2010 17:11:10 -0700 (PDT) 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=6fgY/kfIeW7yDGgTvNFlZmOtrOX99Mmv0sRj317LR80=; b=IRZ9pxWfBsO9lg7Ie/U6y0up+Zklwlgo9TbykMLjWzduEihXHkTq6DkI+hfSJ2SEok ExhrSya/0ZWhtk7jdYJAE8RFJQd+3adfI6tEsEOhikzcBgTTgYdQ6iUiEH5Oi8EYkAe1 4/HOCeCuOGfyAxhoWdskMKhEB3/oMgeksr3HE= 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=Pzp2bBfKinnJm/7H1c2OYseejMYBpwDjKFOk/nMRAoCP6ZcGxEjWDOIkll9euMyxBU zym9J6HKtfyQXrvRkYyV3PokZlu5WxTxM6C+xBuk69YdyI1exf2I7gT4YHB6u+ivJCM0 MphYL4ILtIPsfg/jD6A53Ec8kYjwQsAn7h1oQ= Received: by 10.142.241.19 with SMTP id o19mr5722474wfh.20.1286842270456; Mon, 11 Oct 2010 17:11:10 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w42sm23622wfh.3.2010.10.11.17.11.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 17:11:09 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Oct 2010 17:09:27 -0700 From: Pyun YongHyeon Date: Mon, 11 Oct 2010 17:09:27 -0700 To: Steve Kargl Message-ID: <20101012000927.GK4607@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012000216.GA1554@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems 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 Oct 2010 00:11:11 -0000 On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: > On Mon, Oct 11, 2010 at 04:16:04PM -0700, Pyun YongHyeon wrote: > > On Mon, Oct 11, 2010 at 03:53:31PM -0700, Steve Kargl wrote: > > > > > > In the time that it's taken me to compose this message > > > the timeout has fire again. > > > > > > 15:47:07 kernel: bge0: watchdog timeout -- resetting > > > 15:47:07 kernel: bge0: link state changed to DOWN > > > 15:47:07 kernel: Limiting icmp unreach response from 439 to 200 packets/sec > > > 15:47:08 kernel: Limiting icmp unreach response from 330 to 200 packets/sec > > > 15:47:11 kernel: bge0: link state changed to UP > > > 15:47:12 kernel: Limiting icmp unreach response from 214 to 200 packets/sec > > > 15:47:13 kernel: Limiting icmp unreach response from 202 to 200 packets/sec > > > 15:47:14 kernel: Limiting icmp unreach response from 238 to 200 packets/sec > > > 15:49:42 kernel: bge0: link state changed to DOWN > > > 15:49:44 kernel: bge0: link state changed to UP > > > > > > I not seen these icmp unreach response messages. > > > > > > > The icmp unreach has nothing to do with bge(4). Check whether a > > server that listens on an UDP port is still alive on your box. > > What worries me is bge(4) watchdog timeouts. It looks like your > > controller is BCM5704. I also have bge(4) regression report from > > marius on sparc64. He said r213945 seemed to cause the issue and > > I'm working on the issue. Could you also try the attached patch? > > The patch did not help. In fact, the icmp (which may be a side > effect of the bge0 device wedging) has become much worse. > > SMP: AP CPU #1 Launched! > Trying to mount root from ufs:/dev/ad6s1a > bge1: link state changed to UP > bge0: link state changed to UP > Limiting icmp unreach response from 3433 to 200 packets/sec > Limiting icmp unreach response from 2017 to 200 packets/sec > Limiting icmp unreach response from 2017 to 200 packets/sec > Limiting icmp unreach response from 2049 to 200 packets/sec > bge0: watchdog timeout -- resetting > bge0: link state changed to DOWN > Limiting icmp unreach response from 1962 to 200 packets/sec > Limiting icmp unreach response from 2174 to 200 packets/sec > Limiting icmp unreach response from 2180 to 200 packets/sec > Limiting icmp unreach response from 2163 to 200 packets/sec > bge0: link state changed to UP > > (removing 50 or so icmp messages). > > I don't know if the following helps, but thought I would > include it here. > > troutmask:sgk[204] ping hpc > PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ping: sendto: No buffer space available > Would you show me the revision number of if_bge.c/if_bgereg.h? %cd /usr/src/sys/dev/bge %ident if_bge.c if_bgereg.h > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 00:15:11 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 6E78B1065672 for ; Tue, 12 Oct 2010 00:15:11 +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 4CB8F8FC1D for ; Tue, 12 Oct 2010 00:15:11 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9C0FA5a006800; Mon, 11 Oct 2010 17:15:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9C0FAXQ006799; Mon, 11 Oct 2010 17:15:10 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Oct 2010 17:15:10 -0700 From: Steve Kargl To: Pyun YongHyeon Message-ID: <20101012001510.GA6789@troutmask.apl.washington.edu> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012000927.GK4607@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 00:15:11 -0000 On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: > On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: > > > > troutmask:sgk[204] ping hpc > > PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > > > Would you show me the revision number of if_bge.c/if_bgereg.h? > %cd /usr/src/sys/dev/bge > %ident if_bge.c if_bgereg.h > if_bge.c: $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ if_bgereg.h: $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 00:26: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 11D16106566B for ; Tue, 12 Oct 2010 00:26:22 +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 E33898FC16 for ; Tue, 12 Oct 2010 00:26:21 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9C0QLNE001578; Mon, 11 Oct 2010 17:26:21 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9C0QLcc001577; Mon, 11 Oct 2010 17:26:21 -0700 (PDT) (envelope-from sgk) Date: Mon, 11 Oct 2010 17:26:21 -0700 From: Steve Kargl To: Pyun YongHyeon Message-ID: <20101012002621.GA1554@troutmask.apl.washington.edu> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012001510.GA6789@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 00:26:22 -0000 On Mon, Oct 11, 2010 at 05:15:10PM -0700, Steve Kargl wrote: > On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: > > On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: > > > > > > troutmask:sgk[204] ping hpc > > > PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes > > > ping: sendto: No buffer space available > > > ping: sendto: No buffer space available > > > ping: sendto: No buffer space available > > > ping: sendto: No buffer space available > > > > > > > Would you show me the revision number of if_bge.c/if_bgereg.h? > > %cd /usr/src/sys/dev/bge > > %ident if_bge.c if_bgereg.h > > > > if_bge.c: > $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ > > if_bgereg.h: > $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari Note, my old kernel which works fine shows troutmask:kargl[202] ident /boot/sgk/kernel | grep bge $FreeBSD: head/sys/dev/bge/if_bge.c 211596 2010-08-22 01:39:09Z yongari $ -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 00:35: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 AD6BE106566B for ; Tue, 12 Oct 2010 00:35:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 73FE98FC0A for ; Tue, 12 Oct 2010 00:35:13 +0000 (UTC) Received: by pvg7 with SMTP id 7so8343pvg.13 for ; Mon, 11 Oct 2010 17:35:12 -0700 (PDT) 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=g8Pk44E8rdwp6VeXm/lJkSecG+o1FI0s6f+vdUKr+Qg=; b=MYFMBr+V+FEOEQ9vrgkr/rdZ0QCGr2bsWkKSaDdekTsm1lvPYIlmZV3P9XFgbcHPTA 4WvMyJWb7eUOl5/uTCPlF+IIggK1Z4UaMxOwO9N3loyI8A2iexpdXVUH5VQhq4cel4lb +JrSCPKh5oCLEfbQPRy3glM0GNS5uIeFPaiHg= 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=SqwxV02kGfwbnSXwfHk/DzT2N5YvFJ/Cy8WKQ6kRGyaLKbRq0tL62cmemvWVGe4MTG BTB56osBgF4BpmF0xLaaZNnRs6q8jfYOwoV38ofF2wMaZV875nD8VXgZdzqJBe2Smhuo 4G7Ti9k3s154LziBG2PtPdmOXzsaorCiKDOnw= Received: by 10.142.213.3 with SMTP id l3mr5767486wfg.6.1286843712821; Mon, 11 Oct 2010 17:35:12 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c22sm12010747waa.13.2010.10.11.17.35.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 17:35:11 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 11 Oct 2010 17:33:29 -0700 From: Pyun YongHyeon Date: Mon, 11 Oct 2010 17:33:29 -0700 To: Steve Kargl Message-ID: <20101012003329.GL4607@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> <20101012002621.GA1554@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6Nae48J/T25AfBN4" Content-Disposition: inline In-Reply-To: <20101012002621.GA1554@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems 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 Oct 2010 00:35:13 -0000 --6Nae48J/T25AfBN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 11, 2010 at 05:26:21PM -0700, Steve Kargl wrote: > On Mon, Oct 11, 2010 at 05:15:10PM -0700, Steve Kargl wrote: > > On Mon, Oct 11, 2010 at 05:09:27PM -0700, Pyun YongHyeon wrote: > > > On Mon, Oct 11, 2010 at 05:02:16PM -0700, Steve Kargl wrote: > > > > > > > > troutmask:sgk[204] ping hpc > > > > PING hpc.apl.washington.edu (10.208.78.111): 56 data bytes > > > > ping: sendto: No buffer space available > > > > ping: sendto: No buffer space available > > > > ping: sendto: No buffer space available > > > > ping: sendto: No buffer space available > > > > > > > > > > Would you show me the revision number of if_bge.c/if_bgereg.h? > > > %cd /usr/src/sys/dev/bge > > > %ident if_bge.c if_bgereg.h > > > > > > > if_bge.c: > > $FreeBSD: head/sys/dev/bge/if_bge.c 213587 2010-10-08 17:58:07Z yongari $ > > > > if_bgereg.h: > > $FreeBSD: head/sys/dev/bge/if_bgereg.h 213486 2010-10-06 17:47:13Z yongari > > Note, my old kernel which works fine shows > > troutmask:kargl[202] ident /boot/sgk/kernel | grep bge > $FreeBSD: head/sys/dev/bge/if_bge.c 211596 2010-08-22 01:39:09Z yongari $ > Thanks for the info. I still suspect r213495 might break BCM5704. Due to lack of BCM5704 I still couldn't test it except guessing. How about attached one? --6Nae48J/T25AfBN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bge.rxprod.patch2" Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 213711) +++ sys/dev/bge/if_bge.c (working copy) @@ -1736,7 +1736,8 @@ RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, - BGE_RCB_FLAG_RING_DISABLED); + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, + BGE_RCB_FLAG_RING_DISABLED)); RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); bge_writembx(sc, BGE_MBX_RX_CONS0_LO + (i * (sizeof(uint64_t))), 0); --6Nae48J/T25AfBN4-- From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 01:41: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 E9B5A1065673 for ; Tue, 12 Oct 2010 01:41:17 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BCD3D8FC0C; Tue, 12 Oct 2010 01:41:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o9C1fGHP055925; Tue, 12 Oct 2010 01:41:17 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4CB42D3D.1050509@freebsd.org> Date: Tue, 12 Oct 2010 09:41:17 +0000 From: David Xu User-Agent: Thunderbird 2.0.0.24 (X11/20100630) MIME-Version: 1.0 To: Paul B Mahol References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: panic on kthread_exit under INVARIANTS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 01:41:18 -0000 Paul B Mahol wrote: > Hi, > > If kernel threads were created via kproc_kthread_add() > when last kernel thread exits it will trigger panic. > > It panics in queue.h .... probably introduced with rec I have committed a patch, can you try it ? http://svn.freebsd.org/changeset/base/213714 Regards, David Xu From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 02:51:30 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 9649F106564A for ; Tue, 12 Oct 2010 02:51:30 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 565128FC0C for ; Tue, 12 Oct 2010 02:51:30 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o9C2JEjf000834 for ; Mon, 11 Oct 2010 19:19:14 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o9C2JEfd000829 for freebsd-current@freebsd.org; Mon, 11 Oct 2010 19:19:14 -0700 (PDT) (envelope-from obrien) Date: Mon, 11 Oct 2010 19:19:14 -0700 From: "David O'Brien" To: freebsd-current@freebsd.org Message-ID: <20101012021914.GA72371@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Subject: [PATCH] fix shell bug in ${var%pattern} expansion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 02:51:30 -0000 At $WORK we hit a bug where ${var%/*} was not producing the correct expansion. There are two patches to fix this. I prefer the first as I feel it is cleaner from an API perspective. I've also added a regression testcase that shows the problem. Thoughts? --=20 -- David (obrien@FreeBSD.org) Commit log: Do not assume in growstackstr() that a "precious" character will be immediately written into the stack after the call. Instead let the caller manage the "space left". Currently growstackstr()'s assumption causes problems with STACKSTRNUL() where we want to be able to turn a stack into a C string, and later pretend the NUL is not there. This fixes a bug in STACKSTRNUL() (that grew the stack) where: 1. STADJUST() called after a STACKSTRNUL() results in an improper adjust. This can be seen in ${var%pattern} and ${var%%pattern} evaluation. 2. Memory leak in STPUTC() called after a STACKSTRNUL(). ----------%<----------%<----------%<----------%<----------%<---------- =20 Index: bin/sh/memalloc.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/sh/memalloc.h (revision 213714) +++ bin/sh/memalloc.h (working copy) @@ -67,9 +67,16 @@ void ungrabstackstr(char *, char *); #define stackblock() stacknxt #define stackblocksize() stacknleft #define STARTSTACKSTR(p) p =3D stackblock(), sstrnleft =3D stackblocksize() -#define STPUTC(c, p) (--sstrnleft >=3D 0? (*p++ =3D (c)) : (p =3D growstac= kstr(), *p++ =3D (c))) +#define STPUTC(c, p) (--sstrnleft >=3D 0? (*p++ =3D (c)) : (p =3D growstac= kstr(), --sstrnleft, *p++ =3D (c))) #define CHECKSTRSPACE(n, p) { if (sstrnleft < n) p =3D makestrspace(); } #define USTPUTC(c, p) (--sstrnleft, *p++ =3D (c)) +/* + * STACKSTRNUL's use is where we want to be able to turn a stack + * (non-sentinel, character counting string) into a C string, + * and later pretend the NUL is not there. + * Note: Because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used + * on a stack that will grabstackstr()ed. + */ #define STACKSTRNUL(p) (sstrnleft =3D=3D 0? (p =3D growstackstr(), *p =3D = '\0') : (*p =3D '\0')) #define STUNPUTC(p) (++sstrnleft, --p) #define STTOPC(p) p[-1] Index: bin/sh/histedit.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/sh/histedit.c (revision 213714) +++ bin/sh/histedit.c (working copy) @@ -418,7 +418,7 @@ fc_replace(const char *s, char *p, char=20 } else STPUTC(*s++, dest); } - STACKSTRNUL(dest); + STPUTC('\0', dest); dest =3D grabstackstr(dest); =20 return (dest); Index: bin/sh/memalloc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/sh/memalloc.c (revision 213714) +++ bin/sh/memalloc.c (working copy) @@ -295,6 +295,12 @@ grabstackblock(int len) * is space for at least one character. */ =20 +static char * +growstrstackblock(int n) { + growstackblock(); + sstrnleft =3D stackblocksize() - n; + return stackblock() + n; +} =20 char * growstackstr(void) @@ -304,12 +310,10 @@ growstackstr(void) len =3D stackblocksize(); if (herefd >=3D 0 && len >=3D 1024) { xwrite(herefd, stackblock(), len); - sstrnleft =3D len - 1; + sstrnleft =3D len; return stackblock(); } - growstackblock(); - sstrnleft =3D stackblocksize() - len - 1; - return stackblock() + len; + return growstrstackblock(len); } =20 =20 @@ -323,9 +327,7 @@ makestrspace(void) int len; =20 len =3D stackblocksize() - sstrnleft; - growstackblock(); - sstrnleft =3D stackblocksize() - len; - return stackblock() + len; + return growstrstackblock(len); } =20 =20 ----------%<----------%<----------%<----------%<----------%<---------- ALTERNATE PATCH: Index: bin/sh-1/memalloc.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/sh-1/memalloc.h (revision 213696) +++ bin/sh-1/memalloc.h (working copy) @@ -70,7 +70,17 @@ void ungrabstackstr(char *, char *); #define STPUTC(c, p) (--sstrnleft >=3D 0? (*p++ =3D (c)) : (p =3D growstac= kstr(), *p++ =3D (c))) #define CHECKSTRSPACE(n, p) { if (sstrnleft < n) p =3D makestrspace(); } #define USTPUTC(c, p) (--sstrnleft, *p++ =3D (c)) -#define STACKSTRNUL(p) (sstrnleft =3D=3D 0? (p =3D growstackstr(), *p =3D = '\0') : (*p =3D '\0')) +/* + * growstackstr() has the assumption that a "precious" character will be + * immediately written into it, so it sets up 'sstrnleft' appropriately. + * But that is not the case for STACKSTRNUL, where we want to be able to + * turn a stack (non-sentinel, character counting string) into a C string, + * and later pretend the NUL is not there (without adjusting 'sstrnleft'). + * Note: because of STACKSTRNUL's semantics, STACKSTRNUL cannot be used on + * a stack that will grabstackstr()ed. + */ +#define STACKSTRNUL(p) (sstrnleft =3D=3D 0? (p =3D growstackstr(), *p =3D = '\0', ++sstrnleft) : (*p =3D '\0')) +//#define STACKSTRNUL(p) (sstrnleft =3D=3D 0? (p =3D growstackstr(), *p = =3D '\0') : (*p =3D '\0')) #define STUNPUTC(p) (++sstrnleft, --p) #define STTOPC(p) p[-1] #define STADJUST(amount, p) (p +=3D (amount), sstrnleft -=3D (amount)) Index: bin/sh-1/histedit.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/sh-1/histedit.c (revision 213696) +++ bin/sh-1/histedit.c (working copy) @@ -418,7 +418,8 @@ fc_replace(const char *s, char *p, char=20 } else STPUTC(*s++, dest); } - STACKSTRNUL(dest); + //STACKSTRNUL(dest); + STPUTC('\0', dest); dest =3D grabstackstr(dest); =20 return (dest); ----------%<----------%<----------%<----------%<----------%<---------- Index: tools/regression/bin/sh/expansion/trim4.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/regression/bin/sh/expansion/trim4.0 (revision 0) +++ tools/regression/bin/sh/expansion/trim4.0 (revision 0) @@ -0,0 +1,12 @@ +# $FreeBSD$ + +J1=3D"/homes/SOME_USER" + +J2=3D"A5678901234567890123456789012345678901234567890123456789012345678901= 234567890123456789012345678911234567891123456789112345678911234567891123456= 789112345678911234567891123456789112345678912345678901234567890123456789012= 34567A567890123456789012345678901234567890123456789012345678901234567890123= 456789012345678901234567891123456789112345678911234567891123456789112345678= 911234567891123456789112345678911234567890123" + +J3=3D"C1234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890 HI" + +# Trigger bug in VSTRIMRIGHT processing STADJUST() call in expand.c:subeva= lvar() +J4=3D"${J2} ${J1%/*} $J3" + +echo $J4 Property changes on: tools/regression/bin/sh/expansion/trim4.0 ___________________________________________________________________ Added: svn:keywords + FreeBSD=3D%H Index: tools/regression/bin/sh/expansion/trim4.0.stdout =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- tools/regression/bin/sh/expansion/trim4.0.stdout (revision 0) +++ tools/regression/bin/sh/expansion/trim4.0.stdout (revision 0) @@ -0,0 +1 @@ +A5678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678911234567891123456789112345678911234567891123456789112= 34567891123456789112345678911234567891234567890123456789012345678901234567A= 567890123456789012345678901234567890123456789012345678901234567890123456789= 012345678901234567891123456789112345678911234567891123456789112345678911234= 567891123456789112345678911234567890123 /homes C123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 890123456789012345678901234567890123456789012345678901234567890123456789012= 345678901234567890123456789012345678901234567890123456789012345678901234567= 8901234567890 HI From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 03:21: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 E2533106564A; Tue, 12 Oct 2010 03:21:58 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id A04478FC12; Tue, 12 Oct 2010 03:21:58 +0000 (UTC) Received: from [192.168.2.3] (blexe.ongs.co.jp [202.216.246.93]) by natial.ongs.co.jp (Postfix) with ESMTPSA id DA2A112543B; Tue, 12 Oct 2010 12:21:56 +0900 (JST) References: <20101004123725.65d09b9e.daichi@ongs.co.jp> <20101005153926.88b4c1e1.daichi@freebsd.org> <201010111150.00785.jhb@freebsd.org> Message-Id: <91E542A6-331C-4164-84FE-187916338B60@ongs.co.jp> From: Daichi GOTO To: John Baldwin In-Reply-To: <201010111150.00785.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B500) Mime-Version: 1.0 (iPad Mail 7B500) Date: Tue, 12 Oct 2010 12:22:18 +0200 Cc: "freebsd-fs@freebsd.org" , Daichi GOTO , "freebsd-current@freebsd.org" , Garrett Cooper Subject: Re: fcntl always fails to delete lock file, and PID is always -6464 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 03:21:59 -0000 Sent from my iPad On Oct 11, 2010, at 5:50 PM, John Baldwin wrote: > On Tuesday, October 05, 2010 2:39:26 am Daichi GOTO wrote: >> Next step discussion engaged from this research I guess. >> >> Should we do change FreeBSD's fcntl(2) to return correct l_pid >> when called with F_SETLK? Or keep current behavior?? >> I want to hear other developers ideas and suggetions. > > POSIX doesn't say that F_SETLK returns a valid l_pid, so I think FreeBSD's > current behavior is fine. Yes, I agree. POSIX says so. > -- > John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 05:22: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 89415106566C for ; Tue, 12 Oct 2010 05:22:04 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 3C0F28FC14 for ; Tue, 12 Oct 2010 05:22:03 +0000 (UTC) Received: by qyk30 with SMTP id 30so316987qyk.13 for ; Mon, 11 Oct 2010 22:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ynsW0MVbcUFw2We5hrbQdcyxLSGaGB8UAv5zQyjo9Ww=; b=KzMUoun9Bh5KqkaSQaMASVPvdx7kGF4hfqaVhKvstARDxEKmM2iee2zhB0myvC8zRh 92T1S6WoGUzge1f2FdmADjxV/Ri4p68tDjSY8WGtwUEloI9Lc48Yx2efZyeUqDg6gs2q GdTBcS4fn/sMF8pYqoNPTYukXdV539S1dH0OQ= 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=veE0umhacHLk0t7yEOURKRflkY3187X77OcLkGRIx7DTtMhYkL9Ri8japwHAtA8SAN usg7foTV0hOEBeOQERbMKeQogyPSTbF/iNpKIh9K1jbItIIQ8DQJPMoONHWrzGJTFebZ o5qvVNpS200aae9DQuX6JkCBymvPdED8taD4Q= MIME-Version: 1.0 Received: by 10.229.233.199 with SMTP id jz7mr5885245qcb.35.1286860920204; Mon, 11 Oct 2010 22:22:00 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Mon, 11 Oct 2010 22:22:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 00:22:00 -0500 Message-ID: From: "Sam Fourman Jr." To: FreeBSD Current , Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: nfs zfs lockup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 05:22:04 -0000 On Mon, Oct 11, 2010 at 3:45 PM, Sam Fourman Jr. wrote: > I believe NFS is upsetting ZFS v15 on FreeBSD current (kernel sources > from today) > this happened while trying to sftp a 4gb file > here is a lockup without nfs even started FNFS# procstat -k 2503 PID TID COMM TDNAME KSTACK 2503 100340 sftp-server - mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_select select syscallenter syscall Xfast_syscall FNFS# -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 08:17:49 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 C67951065674 for ; Tue, 12 Oct 2010 08:17:49 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 8273D8FC08 for ; Tue, 12 Oct 2010 08:17:49 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id B7DF6176097; Tue, 12 Oct 2010 11:17:45 +0300 (EEST) Date: Tue, 12 Oct 2010 11:17:45 +0300 From: Jaakko Heinonen To: barbara Message-ID: <20101012081744.GA48485@jh> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current Subject: Re: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:17:49 -0000 On 2010-10-11, barbara wrote: > The panic is caused by: > g_dev_taste(): make_dev_p() failed (gp->name=ext2fs//, error=22) > as I have a linux partition (I swear, it's for my mom!) on the same machine. > As I don't care about that partition (being ext4 I can't even mount > it), is there any solution other then applying the patch after every > csup? If you don't need ext2fs labels you can put the following line to /boot/loader.conf as a workaround: kern.geom.label.ext2fs.enable=0 -- Jaakko From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 08:35: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 19021106566C; Tue, 12 Oct 2010 08:35:47 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id D3B9B8FC1B; Tue, 12 Oct 2010 08:35:45 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5aKl-0009AY-At ; Tue, 12 Oct 2010 11:35:44 +0300 Date: Tue, 12 Oct 2010 11:35:42 +0300 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101012113542.5eaf5321@ukr.net> In-Reply-To: References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:35:47 -0000 =D0=92 Mon, 11 Oct 2010 08:37:05 -0700 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Mon, Oct 11, 2010 at 2:04 AM, Andriy Gapon wrote: > > on 11/10/2010 10:59 Ivan Klymenko said the following: > >> =D0=92 Sun, 10 Oct 2010 15:37:55 -0700 > >> Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> On Sun, Oct 10, 2010 at 3:08 PM, Ivan Klymenko > >>> wrote: > >>>> Hi! > >>>> > >>>> My system has an svn r213507 > >>>> > >>>> FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r213507: > >>>> Sun Oct 10 22:43:18 EEST 2010 > >>>> root@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 > >>>> > >>>> after upgrading to r213666 my system hangs after logging into gdm > >>>> > >>>> had to go back to r213507 > >>> > >>> What video driver are you using? > >>> -Garrett > >> > >> NVIDIA Driver Version: 260.19.06 > >> > >> but Xorg successfully starts and GDM login screen appears > >> system hangs after a few seconds after entering the password ... > >> I noticed the following: gvfsd does not create a directory of the > >> form / var/tmp/gvfs-- may hang system due to gvfsd? >=20 > That seems a bit interesting. > The other thing you can do is start running a binary search on the > breakage because you have a range of good versions vs bad versions to > look through. >=20 > > If you can access the system remotely or quickly switch to console, > > then you should be able to examine state of your system and get > > some facts. >=20 > If you have ddb compiled into the kernel (and you should) try > CTRL-ALT-ESC after the lockup. You may also want to try KGDB instead, > which would require a serial connection (RS-232 or IEEE-1394). > HTH, > -Garrett --I have updated the source code to r213666 --rebuilt and reinstall: world and kernel GENERIC --reinstall nvidia driver with my patch: ##################### --- src/nvidia_os.c.orig 2010-09-15 01:26:27.000000000 +0300 +++ src/nvidia_os.c 2010-09-15 01:27:51.000000000 +0300 @@ -13,6 +13,67 @@ #include "nv.h" #include "nv-freebsd.h" =20 +struct taskqueue { + STAILQ_HEAD(, task) tq_queue; + const char *tq_name; + taskqueue_enqueue_fn tq_enqueue; + void *tq_context; + struct task *tq_running; + struct mtx tq_mutex; + struct thread **tq_threads; + int tq_tcount; + int tq_spin; + int tq_flags; +}; + +static void taskqueue_run(struct taskqueue *, struct task **); + +static __inline void +TQ_LOCK(struct taskqueue *tq) +{ + if (tq->tq_spin) + mtx_lock_spin(&tq->tq_mutex); + else + mtx_lock(&tq->tq_mutex); +} + +static __inline void +TQ_UNLOCK(struct taskqueue *tq) +{ + if (tq->tq_spin) + mtx_unlock_spin(&tq->tq_mutex); + else + mtx_unlock(&tq->tq_mutex); +} + +static void +taskqueue_run(struct taskqueue *queue, struct task **tpp) +{ =20 + struct task *task; + int pending; + + mtx_assert(&queue->tq_mutex, MA_OWNED); + while (STAILQ_FIRST(&queue->tq_queue)) { + /* + * Carefully remove the first task from the queue and + * zero its pending count. + */ + task =3D STAILQ_FIRST(&queue->tq_queue); + STAILQ_REMOVE_HEAD(&queue->tq_queue, ta_link); + pending =3D task->ta_pending; + task->ta_pending =3D 0; + task->ta_running =3D tpp; + *tpp =3D task; + TQ_UNLOCK(queue); + + task->ta_func(task->ta_context, pending); + + TQ_LOCK(queue); + *tpp =3D NULL; + wakeup(task); + } +} + MALLOC_DEFINE(M_NVIDIA, "nvidia", "NVIDIA memory allocations"); TASKQUEUE_DEFINE_THREAD(nvidia); =20 @@ -332,7 +393,8 @@ =20 RM_STATUS NV_API_CALL os_flush_work_queue(void) { - taskqueue_run(taskqueue_nvidia); +// taskqueue_run(taskqueue_nvidia); + taskqueue_run(taskqueue_nvidia, &taskqueue_nvidia->tq_running); return RM_OK; } ##################### --reboo --authorization window will appear gdm --i choose a user, enter a password and press "Enter" --takes a few seconds and my system hangs --I press CTRL + ALT + ESC, but nothing happens :( Here are some of the messages log at this loading: Oct 12 01:06:57 nonamehost syslogd: kernel boot file is /boot/kernel/kernel Oct 12 01:06:57 nonamehost kernel: Copyright (c) 1992-2010 The FreeBSD Proj= ect. Oct 12 01:06:57 nonamehost kernel: Copyright (c) 1979, 1980, 1983, 1986, 19= 88, 1989, 1991, 1992, 1993, 1994 Oct 12 01:06:57 nonamehost kernel: The Regents of the University of Califor= nia. All rights reserved. Oct 12 01:06:57 nonamehost kernel: FreeBSD is a registered trademark of The= FreeBSD Foundation. Oct 12 01:06:57 nonamehost kernel: FreeBSD 9.0-CURRENT #0 r213666: Tue Oct = 12 00:23:58 EEST 2010 Oct 12 01:06:57 nonamehost kernel: ivan@nonamehost:/usr/obj/usr/src/sys/GEN= ERIC amd64 Oct 12 01:06:57 nonamehost kernel: WARNING: WITNESS option enabled, expect = reduced performance. Oct 12 01:06:57 nonamehost kernel: CPU: Intel(R) Core(TM)2 Duo CPU T725= 0 @ 2.00GHz (1994.48-MHz K8-class CPU) Oct 12 01:06:57 nonamehost kernel: Origin =3D "GenuineIntel" Id =3D 0x6fd = Family =3D 6 Model =3D f Stepping =3D 13 Oct 12 01:06:57 nonamehost kernel: Features=3D0xbfebfbff Oct 12 01:06:57 nonamehost kernel: Features2=3D0xe3bd Oct 12 01:06:57 nonamehost kernel: AMD Features=3D0x20100800 Oct 12 01:06:57 nonamehost kernel: AMD Features2=3D0x1 Oct 12 01:06:57 nonamehost kernel: TSC: P-state invariant Oct 12 01:06:57 nonamehost kernel: real memory =3D 2147483648 (2048 MB) Oct 12 01:06:57 nonamehost kernel: avail memory =3D 2032889856 (1938 MB) Oct 12 01:06:57 nonamehost kernel: Event timer "LAPIC" quality 400 Oct 12 01:06:57 nonamehost kernel: ACPI APIC Table: Oct 12 01:06:57 nonamehost kernel: FreeBSD/SMP: Multiprocessor System Detec= ted: 2 CPUs Oct 12 01:06:57 nonamehost kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Oct 12 01:06:57 nonamehost kernel: cpu0 (BSP): APIC ID: 0 Oct 12 01:06:57 nonamehost kernel: cpu1 (AP): APIC ID: 1 Oct 12 01:06:57 nonamehost kernel: ioapic0: Changing APIC ID to 2 Oct 12 01:06:57 nonamehost kernel: ioapic0 irqs 0-23 on mothe= rboard Oct 12 01:06:57 nonamehost kernel: Cuse4BSD v0.1.13 @ /dev/cuse Oct 12 01:06:57 nonamehost kernel: kbd1 at kbdmux0 Oct 12 01:06:57 nonamehost kernel: acpi0: on motherboard Oct 12 01:06:57 nonamehost kernel: hpet0: iome= m 0xfed00000-0xfed003ff on acpi0 Oct 12 01:06:57 nonamehost kernel: Timecounter "HPET" frequency 14318180 Hz= quality 900 Oct 12 01:06:57 nonamehost kernel: Event timer "HPET" frequency 14318180 Hz= quality 550 Oct 12 01:06:57 nonamehost kernel: Event timer "HPET1" frequency 14318180 H= z quality 440 Oct 12 01:06:57 nonamehost kernel: acpi0: reservation of 0, 9f000 (3) failed Oct 12 01:06:57 nonamehost kernel: acpi0: reservation of 100000, 7fd6d800 (= 3) failed Oct 12 01:06:57 nonamehost kernel: Timecounter "ACPI-fast" frequency 357954= 5 Hz quality 1000 Oct 12 01:06:57 nonamehost kernel: acpi_timer0: <24-bit timer at 3.579545MH= z> port 0x1008-0x100b on acpi0 Oct 12 01:06:57 nonamehost kernel: cpu0: on acpi0 Oct 12 01:06:57 nonamehost kernel: cpu1: on acpi0 Oct 12 01:06:57 nonamehost kernel: pcib0: port 0xcf8= -0xcff on acpi0 Oct 12 01:06:57 nonamehost kernel: pci0: on pcib0 Oct 12 01:06:57 nonamehost kernel: pcib1: at device 1= .0 on pci0 Oct 12 01:06:57 nonamehost kernel: pci1: on pcib1 Oct 12 01:06:57 nonamehost kernel: vgapci0: port 0= xef00-0xef7f mem 0xfd000000-0xfdffffff,0xe0000000-0xefffffff,0xfa000000-0xf= bffffff irq 16 at device 0.0 on pci1 Oct 12 01:06:57 nonamehost kernel: acpi_video0: on v= gapci0 Oct 12 01:06:57 nonamehost kernel: nvidia0: on vgapci0 Oct 12 01:06:57 nonamehost kernel: vgapci0: child nvidia0 requested pci_ena= ble_busmaster Oct 12 01:06:57 nonamehost kernel: vgapci0: child nvidia0 requested pci_ena= ble_io Oct 12 01:06:57 nonamehost kernel: vgapci0: child nvidia0 requested pci_ena= ble_io Oct 12 01:06:57 nonamehost kernel: uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 Oct 12 01:06:57 nonamehost kernel: uhci0: LegSup =3D 0x2f00 Oct 12 01:06:57 nonamehost kernel: usbus0: on uhci0 Oct 12 01:06:57 nonamehost kernel: uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 Oct 12 01:06:57 nonamehost kernel: uhci1: LegSup =3D 0x2f00 Oct 12 01:06:57 nonamehost kernel: usbus1: on uhci1 Oct 12 01:06:57 nonamehost kernel: ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 Oct 12 01:06:57 nonamehost kernel: usbus2: EHCI version 1.0 Oct 12 01:06:57 nonamehost kernel: usbus2: on ehci0 Oct 12 01:06:57 nonamehost kernel: hdac0: mem 0xfebfc000-0xfebfffff irq 21 at device 27.0 on pci0 Oct 12 01:06:57 nonamehost kernel: hdac0: HDA Driver Revision: 20100226_0142 Oct 12 01:06:57 nonamehost kernel: pcib2: at device 2= 8.0 on pci0 Oct 12 01:06:57 nonamehost kernel: pci11: on pcib2 Oct 12 01:06:57 nonamehost kernel: pcib3: at device 2= 8.1 on pci0 Oct 12 01:06:57 nonamehost kernel: pci12: on pcib3 Oct 12 01:06:57 nonamehost kernel: pci12: at device 0.0 (no drive= r attached) Oct 12 01:06:57 nonamehost kernel: pcib4: at device 2= 8.3 on pci0 Oct 12 01:06:57 nonamehost kernel: pci13: on pcib4 Oct 12 01:06:57 nonamehost kernel: pcib5: at device 2= 8.5 on pci0 Oct 12 01:06:57 nonamehost kernel: pci9: on pcib5 Oct 12 01:06:57 nonamehost kernel: bge0: mem 0xf9bf0000-0xf9bfffff irq 17 at device 0.0 on pci9 Oct 12 01:06:57 nonamehost kernel: bge0: CHIP ID 0x0000c002; ASIC REV 0x0c;= CHIP REV 0xc0; PCI-E Oct 12 01:06:57 nonamehost kernel: miibus0: on bge0 Oct 12 01:06:57 nonamehost kernel: brgphy0: PHY = 1 on miibus0 Oct 12 01:06:57 nonamehost kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseT= X, 100baseTX-FDX, auto Oct 12 01:06:57 nonamehost kernel: bge0: Ethernet address: 00:1c:23:f9:bb:5f Oct 12 01:06:57 nonamehost kernel: uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 Oct 12 01:06:57 nonamehost kernel: uhci2: LegSup =3D 0x2f00 Oct 12 01:06:57 nonamehost kernel: usbus3: on uhci2 Oct 12 01:06:57 nonamehost kernel: uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 Oct 12 01:06:57 nonamehost kernel: uhci3: LegSup =3D 0x2f00 Oct 12 01:06:57 nonamehost kernel: usbus4: on uhci3 Oct 12 01:06:57 nonamehost kernel: uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 Oct 12 01:06:57 nonamehost kernel: uhci4: LegSup =3D 0x2f00 Oct 12 01:06:57 nonamehost kernel: usbus5: on uhci4 Oct 12 01:06:57 nonamehost kernel: ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 Oct 12 01:06:57 nonamehost kernel: usbus6: EHCI version 1.0 Oct 12 01:06:57 nonamehost kernel: usbus6: on ehci1 Oct 12 01:06:57 nonamehost kernel: pcib6: at device 3= 0.0 on pci0 Oct 12 01:06:57 nonamehost kernel: pci3: on pcib6 Oct 12 01:06:57 nonamehost kernel: fwohci0: <1394 Open Host Controller Inte= rface> mem 0xf9aff800-0xf9afffff irq 19 at device 1.0 on pci3 Oct 12 01:06:57 nonamehost kernel: fwohci0: OHCI version 1.10 (ROM=3D0) Oct 12 01:06:57 nonamehost kernel: fwohci0: No. of Isochronous channels is = 4. Oct 12 01:06:57 nonamehost kernel: fwohci0: EUI64 32:4f:c0:00:1c:e5:20:70 Oct 12 01:06:57 nonamehost kernel: fwohci0: Phy 1394a available S400, 1 por= ts. Oct 12 01:06:57 nonamehost kernel: fwohci0: Link S400, max_rec 2048 bytes. Oct 12 01:06:57 nonamehost kernel: firewire0: on f= wohci0 Oct 12 01:06:57 nonamehost kernel: fwe0: on firewi= re0 Oct 12 01:06:57 nonamehost kernel: if_fwe0: Fake Ethernet address: 32:4f:c0= :e5:20:70 Oct 12 01:06:57 nonamehost kernel: fwe0: Ethernet address: 32:4f:c0:e5:20:70 Oct 12 01:06:57 nonamehost kernel: fwip0: on firewire0 Oct 12 01:06:57 nonamehost kernel: fwip0: Firewire address: 32:4f:c0:00:1c:= e5:20:70 @ 0xfffe00000000, S400, maxrec 2048 Oct 12 01:06:57 nonamehost kernel: sbp0: on fire= wire0 Oct 12 01:06:57 nonamehost kernel: dcons_crom0: o= n firewire0 Oct 12 01:06:57 nonamehost kernel: dcons_crom0: bus_addr 0x2064000 Oct 12 01:06:57 nonamehost kernel: fwohci0: Initiate bus reset Oct 12 01:06:57 nonamehost kernel: fwohci0: fwohci_intr_core: BUS reset Oct 12 01:06:57 nonamehost kernel: fwohci0: fwohci_intr_core: node_id=3D0x0= 0000000, SelfID Count=3D1, CYCLEMASTER mode Oct 12 01:06:57 nonamehost kernel: pci3: at device 1.1 (no driver attached) Oct 12 01:06:57 nonamehost kernel: pci3: at device 1.2 (n= o driver attached) Oct 12 01:06:57 nonamehost kernel: pci3: at device 1.3 (n= o driver attached) Oct 12 01:06:57 nonamehost kernel: pci3: at device 1.4 (n= o driver attached) Oct 12 01:06:57 nonamehost kernel: isab0: at device 31.0 o= n pci0 Oct 12 01:06:57 nonamehost kernel: isa0: on isab0 Oct 12 01:06:57 nonamehost kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 3= 1.1 on pci0 Oct 12 01:06:57 nonamehost kernel: ata0: on atapci0 Oct 12 01:06:57 nonamehost kernel: ahci0: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6ef= f mem 0xfebfb800-0xfebfbfff irq 17 at device 31.2 on pci0 Oct 12 01:06:57 nonamehost kernel: ahci0: AHCI v1.10 with 3 3Gbps ports, Po= rt Multiplier not supported Oct 12 01:06:57 nonamehost kernel: ahcich0: at channel 0 on = ahci0 Oct 12 01:06:57 nonamehost kernel: ahcich1: at channel 2 on = ahci0 Oct 12 01:06:57 nonamehost kernel: pci0: at device 31.3= (no driver attached) Oct 12 01:06:57 nonamehost kernel: acpi_lid0: o= n acpi0 Oct 12 01:06:57 nonamehost kernel: acpi_button0: on acpi0 Oct 12 01:06:57 nonamehost kernel: acpi_button1: on acpi0 Oct 12 01:06:57 nonamehost kernel: acpi_acad0: on acpi0 Oct 12 01:06:57 nonamehost kernel: battery0: = on acpi0 Oct 12 01:06:57 nonamehost kernel: acpi_tz0: on acpi0 Oct 12 01:06:57 nonamehost kernel: atkbdc0: p= ort 0x60,0x64,0x62,0x66 irq 1 on acpi0 Oct 12 01:06:57 nonamehost kernel: atkbd0: irq 1 on atkbdc0 Oct 12 01:06:57 nonamehost kernel: kbd0 at atkbd0 Oct 12 01:06:57 nonamehost kernel: atkbd0: [GIANT-LOCKED] Oct 12 01:06:57 nonamehost kernel: psm0: irq 12 on atkbdc0 Oct 12 01:06:57 nonamehost kernel: psm0: [GIANT-LOCKED] Oct 12 01:06:57 nonamehost kernel: psm0: model GlidePoint, device ID 0 Oct 12 01:06:57 nonamehost kernel: atrtc0: port 0x70-0x= 71,0x72-0x77 irq 8 on acpi0 Oct 12 01:06:57 nonamehost kernel: attimer0: port 0x40-0x43,0x50= -0x53 irq 2 on acpi0 Oct 12 01:06:57 nonamehost kernel: Timecounter "i8254" frequency 1193182 Hz= quality 0 Oct 12 01:06:57 nonamehost kernel: orm0: at iomem 0xc0000= -0xcd7ff,0xcd800-0xcffff on isa0 Oct 12 01:06:57 nonamehost kernel: sc0: at flags 0x100 on = isa0 Oct 12 01:06:57 nonamehost kernel: sc0: VGA <16 virtual consoles, flags=3D0= x300> Oct 12 01:06:57 nonamehost kernel: vga0: at port 0x3c0-0x= 3df iomem 0xa0000-0xbffff on isa0 Oct 12 01:06:57 nonamehost kernel: ppc0: cannot reserve I/O port range Oct 12 01:06:57 nonamehost kernel: est0: on cpu0 Oct 12 01:06:57 nonamehost kernel: p4tcc0: = on cpu0 Oct 12 01:06:57 nonamehost kernel: est1: on cpu1 Oct 12 01:06:57 nonamehost kernel: p4tcc1: = on cpu1 Oct 12 01:06:57 nonamehost kernel: Timecounter "TSC" frequency 1994477390 H= z quality 800 Oct 12 01:06:57 nonamehost kernel: Timecounters tick every 1.000 msec Oct 12 01:06:57 nonamehost kernel: firewire0: 1 nodes, maxhop <=3D 0 cable = IRM irm(0) (me)=20 Oct 12 01:06:57 nonamehost kernel: firewire0: bus manager 0=20 Oct 12 01:06:57 nonamehost kernel: usbus0: 12Mbps Full Speed USB v1.0 Oct 12 01:06:57 nonamehost kernel: usbus1: 12Mbps Full Speed USB v1.0 Oct 12 01:06:57 nonamehost kernel: usbus2: 480Mbps High Speed USB v2.0 Oct 12 01:06:57 nonamehost kernel: usbus3: 12Mbps Full Speed USB v1.0 Oct 12 01:06:57 nonamehost kernel: usbus4: 12Mbps Full Speed USB v1.0 Oct 12 01:06:57 nonamehost kernel: usbus5: 12Mbps Full Speed USB v1.0 Oct 12 01:06:57 nonamehost kernel: usbus6: 480Mbps High Speed USB v2.0 Oct 12 01:06:57 nonamehost kernel: ugen0.1: at usbus0 Oct 12 01:06:57 nonamehost kernel: uhub0: on usbus0 Oct 12 01:06:57 nonamehost kernel: ugen1.1: at usbus1 Oct 12 01:06:57 nonamehost kernel: uhub1: on usbus1 Oct 12 01:06:57 nonamehost kernel: ugen2.1: at usbus2 Oct 12 01:06:57 nonamehost kernel: uhub2: on usbus2 Oct 12 01:06:57 nonamehost kernel: ugen3.1: at usbus3 Oct 12 01:06:57 nonamehost kernel: uhub3: on usbus3 Oct 12 01:06:57 nonamehost kernel: ugen4.1: at usbus4 Oct 12 01:06:57 nonamehost kernel: uhub4: on usbus4 Oct 12 01:06:57 nonamehost kernel: ugen5.1: at usbus5 Oct 12 01:06:57 nonamehost kernel: uhub5: on usbus5 Oct 12 01:06:57 nonamehost kernel: ugen6.1: at usbus6 Oct 12 01:06:57 nonamehost kernel: uhub6: on usbus6 Oct 12 01:06:57 nonamehost kernel: acd0: DVDR = at ata0-master UDMA33=20 Oct 12 01:06:57 nonamehost kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X Oct 12 01:06:57 nonamehost kernel: hdac0: HDA Codec #1: Conexant (Unknown) Oct 12 01:06:57 nonamehost kernel: pcm0: at cad 0 nid 1 on hdac0 Oct 12 01:06:57 nonamehost kernel: pcm1: at cad 0 nid 1 on hdac0 Oct 12 01:06:57 nonamehost kernel: pcm2: at cad 0 nid 1 on hdac0 Oct 12 01:06:57 nonamehost kernel: uhub0: 2 ports with 2 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub1: 2 ports with 2 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub3: 2 ports with 2 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub4: 2 ports with 2 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub5: 2 ports with 2 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub2: 4 ports with 4 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: uhub6: 6 ports with 6 removable, self po= wered Oct 12 01:06:57 nonamehost kernel: ugen6.2: at usbus6 Oct 12 01:06:57 nonamehost kernel: ada0 at ahcich0 bus 0 scbus1 target 0 lu= n 0 Oct 12 01:06:57 nonamehost kernel: ada0: ATA-8 SATA = 2.x device Oct 12 01:06:57 nonamehost kernel: ada0: 300.000MB/s transfers (SATA 2.x, U= DMA6, PIO 8192bytes) Oct 12 01:06:57 nonamehost kernel: ada0: Command Queueing enabled Oct 12 01:06:57 nonamehost kernel: ada0: 305245MB (625142448 512 byte secto= rs: 16H 63S/T 16383C) Oct 12 01:06:57 nonamehost kernel: SMP: AP CPU #1 Launched! Oct 12 01:06:57 nonamehost kernel: WARNING: WITNESS option enabled, expect = reduced performance. Oct 12 01:06:57 nonamehost kernel: ugen4.2: at usbus4 Oct 12 01:06:57 nonamehost kernel: ums0: on usbus4 Oct 12 01:06:57 nonamehost kernel: ums0: 8 buttons and [XYZ] coordinates ID= =3D0 Oct 12 01:06:57 nonamehost kernel: Trying to mount root from ufs:/dev/ada0s= 1a Oct 12 01:06:57 nonamehost savecore: first and last dump headers disagree o= n /dev/ada0s1b Oct 12 01:06:57 nonamehost savecore: unsaved dumps found but not saved Oct 12 01:06:57 nonamehost savecore: first and last dump headers disagree o= n /dev/ada0s1b Oct 12 01:06:57 nonamehost savecore: unsaved dumps found but not saved Oct 12 01:07:00 nonamehost kernel: lock order reversal: Oct 12 01:07:00 nonamehost kernel: 1st 0xffffff807a670af8 bufwait (bufwait)= @ /usr/src/sys/kern/vfs_bio.c:2659 Oct 12 01:07:00 nonamehost kernel: 2nd 0xffffff0005ef6600 dirhash (dirhash)= @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 Oct 12 01:07:00 nonamehost kernel: KDB: stack backtrace: Oct 12 01:07:00 nonamehost kernel:=20 Oct 12 01:07:00 nonamehost kernel: db_trace_self_wrapper() at db_trace_self= _wrappe Oct 12 01:07:00 nonamehost kernel: r+0x2a Oct 12 01:07:00 nonamehost kernel:=20 Oct 12 01:07:00 nonamehost kernel: kdb_backtrace() at=20 Oct 12 01:07:00 nonamehost kernel: kdb_backtrace+0x37 Oct 12 01:07:01 nonamehost kernel:=20 Oct 12 01:07:01 nonamehost kernel: _witness_debugger() at _witness_debugger= +0x2e Oct 12 01:07:01 nonamehost kernel: witness_checkorder() at witness_checkord= er+0xa94 Oct 12 01:07:01 nonamehost kernel: _sx_xlock() at _sx_xlock+0x55 Oct 12 01:07:01 nonamehost kernel: ufsdirhash_acquire() at ufsdirhash_acqui= re+0x33 Oct 12 01:07:01 nonamehost kernel: ufsdirhash_add() at ufsdirhash_add+0x19 Oct 12 01:07:01 nonamehost kernel: ufs_direnter() at ufs_direnter+0x8b4 Oct 12 01:07:01 nonamehost kernel: ufs_mkdir() at ufs_mkdir+0x41f Oct 12 01:07:01 nonamehost kernel: VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 Oct 12 01:07:01 nonamehost kernel: kern_mkdirat() at kern_mkdirat+0x270 Oct 12 01:07:01 nonamehost kernel: syscallenter() at=20 Oct 12 01:07:01 nonamehost kernel: syscallenter+0x1aa Oct 12 01:07:01 nonamehost kernel:=20 Oct 12 01:07:01 nonamehost kernel: syscall() at syscall+0x4c Oct 12 01:07:01 nonamehost kernel: Xfast_syscall() at Xfast_syscall+0xe2 Oct 12 01:07:01 nonamehost kernel: --- syscall (136, FreeBSD ELF64, mkdir),= rip =3D 0x8007316cc, rsp =3D 0x7fffffffe788, rbp =3D 0x800c07050 --- Oct 12 01:07:01 nonamehost root: /etc/rc: WARNING: failed to start webcamd Oct 12 01:07:01 nonamehost kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST = asc=3D0x24 ascq=3D0x00=20 Oct 12 01:07:02 nonamehost kernel: (probe0:ata0:0:0:0): TEST UNIT READY. CD= B: 0 0 0 0 0 0=20 Oct 12 01:07:02 nonamehost kernel: (probe0:ata0:0:0:0): CAM status: SCSI St= atus Error Oct 12 01:07:02 nonamehost kernel: (probe0:ata0:0:0:0): SCSI status: Check = Condition Oct 12 01:07:02 nonamehost kernel: (probe0:ata0:0:0:0): SCSI sense: NOT REA= DY asc:3a,0 (Medium not present) Oct 12 01:07:02 nonamehost kernel: cd0 at ata0 bus 0 scbus3 target 0 lun 0 Oct 12 01:07:02 nonamehost kernel: cd0: Removab= le CD-ROM SCSI-0 device=20 Oct 12 01:07:02 nonamehost kernel: cd0: 33.000MB/s transfers Oct 12 01:07:02 nonamehost kernel: cd0: Attempt to query device size failed= : NOT READY, Medium not present Oct 12 01:07:02 nonamehost kernel: kqemu version 0x00010400 Oct 12 01:07:02 nonamehost kernel: kqemu: KQEMU installed, max_locked_mem= =3D1031540kB. Oct 12 01:07:02 nonamehost kernel: sdhci0: mem 0xf9aff400= -0xf9aff4ff irq 18 at device 1.1 on pci3 Oct 12 01:07:02 nonamehost kernel: sdhci0: 1 slot(s) allocated Oct 12 01:07:02 nonamehost kernel: GEOM: md0: geometry does not match label= (1h,63s !=3D 1h,1s). Oct 12 01:07:03 nonamehost kernel: fuse4bsd: version 0.3.9-pre1, FUSE ABI 7= .8 Oct 12 01:07:04 nonamehost kernel: acd0: FAILURE - ATA_IDENTIFY status=3D51= error=3D4 LBA=3D0 Oct 12 01:07:16 nonamehost kernel: ugen4.2: at usbus4 (disconnecte= d) Oct 12 01:07:16 nonamehost kernel: ums0: at uhub4, port 2, addr 2 (disconne= cted) Oct 12 01:07:19 nonamehost kernel: ugen4.2: at usbus4 Oct 12 01:07:19 nonamehost kernel: ums0: on usbus4 Oct 12 01:07:19 nonamehost kernel: ums0: 8 buttons and [XYZ] coordinates ID= =3D0 Oct 12 01:07:23 nonamehost avahi-daemon[2043]: WARNING: No NSS support for = mDNS detected, consider installing nss-mdns! Oct 12 01:07:52 nonamehost kernel: lock order reversal: Oct 12 01:07:52 nonamehost kernel: 1st 0xffffff0019f5f248 filedesc structur= e (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1133 Oct 12 01:07:52 nonamehost kernel: 2nd 0xffffff004696edb8 ufs (ufs) @ /usr/= src/sys/kern/vfs_subr.c:4176 Oct 12 01:07:52 nonamehost kernel: KDB: stack backtrace: Oct 12 01:07:52 nonamehost kernel: db_trace_self_wrapper() at db_trace_self= _wrapper+0x2a Oct 12 01:07:52 nonamehost kernel: kdb_backtrace() at kdb_backtrace+0x37 Oct 12 01:07:52 nonamehost kernel: _witness_debugger() at _witness_debugger= +0x2e Oct 12 01:07:52 nonamehost kernel: witness_checkorder() at witness_checkord= er+0xa94 Oct 12 01:07:52 nonamehost kernel: __lockmgr_args() at __lockmgr_args+0x138c Oct 12 01:07:52 nonamehost kernel: ffs_lock() at ffs_lock+0x8c Oct 12 01:07:52 nonamehost kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Oct 12 01:07:52 nonamehost kernel: _vn_lock() at _vn_lock+0x44 Oct 12 01:07:52 nonamehost kernel: knlist_remove_kq() at knlist_remove_kq+0= x67 Oct 12 01:07:52 nonamehost kernel: knote_fdclose() at knote_fdclose+0x177 Oct 12 01:07:52 nonamehost kernel: kern_close() at kern_close+0xe9 Oct 12 01:07:52 nonamehost kernel: syscallenter() at syscallenter+0x1aa Oct 12 01:07:52 nonamehost kernel: syscall() at syscall+0x4c Oct 12 01:07:52 nonamehost kernel: Xfast_syscall() at Xfast_syscall+0xe2 Oct 12 01:07:52 nonamehost kernel: --- syscall (6, FreeBSD ELF64, close), r= ip =3D 0x800e90aac, rsp =3D 0x7fffffffe878, rbp =3D 0x8010686d0 --- what I do next? :( From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 08:51:09 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 70ABD1065670; Tue, 12 Oct 2010 08:51:09 +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 87FE38FC26; Tue, 12 Oct 2010 08:51:08 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA13095; Tue, 12 Oct 2010 11:51:06 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P5aZe-000OCC-9T; Tue, 12 Oct 2010 11:51:06 +0300 Message-ID: <4CB42179.10302@icyb.net.ua> Date: Tue, 12 Oct 2010 11:51:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ivan Klymenko References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> In-Reply-To: <20101012113542.5eaf5321@ukr.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Garrett Cooper Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:51:09 -0000 on 12/10/2010 11:35 Ivan Klymenko said the following: > --i choose a user, enter a password and press "Enter" have you switched to text console after the above and before the next? > --takes a few seconds and my system hangs > --I press CTRL + ALT + ESC, but nothing happens You might want to add DEBUG_VFS_LOCKS. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 09:00: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 67B5D106564A; Tue, 12 Oct 2010 09:00:13 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 111A88FC13; Tue, 12 Oct 2010 09:00:12 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5aiR-000JZn-Po ; Tue, 12 Oct 2010 12:00:12 +0300 Date: Tue, 12 Oct 2010 12:00:02 +0300 From: Ivan Klymenko To: Andriy Gapon Message-ID: <20101012120002.75ed1f2d@ukr.net> In-Reply-To: <4CB42179.10302@icyb.net.ua> References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, Garrett Cooper Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 09:00:13 -0000 =D0=92 Tue, 12 Oct 2010 11:51:05 +0300 Andriy Gapon =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > on 12/10/2010 11:35 Ivan Klymenko said the following: > > --i choose a user, enter a password and press "Enter" >=20 > have you switched to text console after the above and before the next? After the system hangs - no after a reboot - yes - I went to the console and rebuilt world and kernel v= ersion r231507 again ... >=20 > > --takes a few seconds and my system hangs > > --I press CTRL + ALT + ESC, but nothing happens >=20 > You might want to add DEBUG_VFS_LOCKS. >=20 Yes, I can, but this whole procedure takes me many hours ... I have FreeBSD - the only system on the PC and I need it in working order -= I'm working on it Surely no one will be able to repeat my steps, that would verify this especially since I've written previously that the cause may be in the vfs .= .. From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 09:04: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 6627A1065670; Tue, 12 Oct 2010 09:04:29 +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 702748FC15; Tue, 12 Oct 2010 09:04:27 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA13295; Tue, 12 Oct 2010 12:04:24 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P5amW-000ODH-9w; Tue, 12 Oct 2010 12:04:24 +0300 Message-ID: <4CB42497.4080105@icyb.net.ua> Date: Tue, 12 Oct 2010 12:04:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Ivan Klymenko References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> In-Reply-To: <20101012120002.75ed1f2d@ukr.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org, Garrett Cooper Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 09:04:29 -0000 on 12/10/2010 12:00 Ivan Klymenko said the following: > Ð’ Tue, 12 Oct 2010 11:51:05 +0300 > Andriy Gapon пишет: > >> on 12/10/2010 11:35 Ivan Klymenko said the following: >>> --i choose a user, enter a password and press "Enter" >> >> have you switched to text console after the above and before the next? > > After the system hangs - no I specifically asked if you switched to text console right after pressing Enter in the above step. Sorry if that was not clear. > after a reboot - yes - I went to the console and rebuilt world and kernel version r231507 again ... > >> >>> --takes a few seconds and my system hangs >>> --I press CTRL + ALT + ESC, but nothing happens >> >> You might want to add DEBUG_VFS_LOCKS. >> > > Yes, I can, but this whole procedure takes me many hours ... > I have FreeBSD - the only system on the PC and I need it in working order - I'm working on it > > Surely no one will be able to repeat my steps, that would verify this > especially since I've written previously that the cause may be in the vfs ... Not sure what your point is. So far you seem to be the only one who has the problem (or has reported it, at least). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 09:07: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 E13591065670 for ; Tue, 12 Oct 2010 09:07:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A135F8FC18 for ; Tue, 12 Oct 2010 09:07:02 +0000 (UTC) Received: by iwn8 with SMTP id 8so5923076iwn.13 for ; Tue, 12 Oct 2010 02:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=f00NpfaR72rQcXiseIKRwzuLetDe6JITR1c7ftEBrpc=; b=GAKHs6lPBAIcD40rteCftJqAXs0NHKXNCE59P2LYFvflXkDUf8EYsXSJoD/VtAcfMY 4I2T7eM82c7ffLO5xDQYuu4thDZE0tldDNGoLFlmE4pwATMy40hzhbH0M3gMNO5+pPQf m+qUt85hv59A1RZ6+a0i22bdFHSuERsodeBn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VIPYqyhfNvQDO9KHcYBHYcHP1Kq47iZA/ONDNVv0syzgX+7LQtXlf7dJfC8OZrkr/n uIAqNc7PkLVEj3MJUzQw6DAVmT3umDjScPkDYHOWwV3RmxND4f19FK7rPILqodsEz0Sd MqE27DPTjG71QU3q75ENrGdcU05aQ0E+Db8x0= MIME-Version: 1.0 Received: by 10.231.14.8 with SMTP id e8mr5547251iba.16.1286874421992; Tue, 12 Oct 2010 02:07:01 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 12 Oct 2010 02:07:01 -0700 (PDT) In-Reply-To: <4CB42497.4080105@icyb.net.ua> References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> <4CB42497.4080105@icyb.net.ua> Date: Tue, 12 Oct 2010 02:07:01 -0700 X-Google-Sender-Auth: O8NeapeXf0p6HO8lf22S0gqr9H0 Message-ID: From: Garrett Cooper To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Ivan Klymenko , freebsd-current@freebsd.org Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 09:07:03 -0000 On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: > on 12/10/2010 12:00 Ivan Klymenko said the following: >> =D0=92 Tue, 12 Oct 2010 11:51:05 +0300 >> Andriy Gapon =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> on 12/10/2010 11:35 Ivan Klymenko said the following: >>>> --i choose a user, enter a password and press "Enter" >>> >>> have you switched to text console after the above and before the next? >> >> After the system hangs - no > > I specifically asked if you switched to text console right after pressing= Enter > in the above step. =C2=A0Sorry if that was not clear. > >> after a reboot - yes - I went to the console and rebuilt world and kerne= l version r231507 again ... >> >>> >>>> --takes a few seconds and my system hangs >>>> --I press CTRL + ALT + ESC, but nothing happens >>> >>> You might want to add DEBUG_VFS_LOCKS. >>> >> >> Yes, I can, but this whole procedure takes me many hours ... >> I have FreeBSD - the only system on the PC and I need it in working orde= r - I'm working on it >> >> Surely no one will be able to repeat my steps, that would verify this >> especially since I've written previously that the cause may be in the vf= s ... > > Not sure what your point is. > So far you seem to be the only one who has the problem (or has reported i= t, at > least). Could you try disabling some of your modules (fuse, nvidia, etc) in a stepwise manner? fuse is of particular interest for me to see whether or not it resolves the problem. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 11:51: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 EF3A2106566C; Tue, 12 Oct 2010 11:51:10 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id A6EB98FC08; Tue, 12 Oct 2010 11:51:10 +0000 (UTC) Received: from 234-31-132-95.pool.ukrtel.net ([95.132.31.234] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5dNt-0008O6-6D ; Tue, 12 Oct 2010 14:51:09 +0300 Date: Tue, 12 Oct 2010 14:51:07 +0300 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101012145107.2b23914f@ukr.net> In-Reply-To: References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> <4CB42497.4080105@icyb.net.ua> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 11:51:11 -0000 =D0=92 Tue, 12 Oct 2010 02:07:01 -0700 Garrett Cooper =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: > > on 12/10/2010 12:00 Ivan Klymenko said the following: > >> =D0=92 Tue, 12 Oct 2010 11:51:05 +0300 > >> Andriy Gapon =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> on 12/10/2010 11:35 Ivan Klymenko said the following: > >>>> --i choose a user, enter a password and press "Enter" > >>> > >>> have you switched to text console after the above and before the > >>> next? > >> > >> After the system hangs - no > > > > I specifically asked if you switched to text console right after > > pressing Enter in the above step. =C2=A0Sorry if that was not clear. > > > >> after a reboot - yes - I went to the console and rebuilt world and > >> kernel version r231507 again ... > >> > >>> > >>>> --takes a few seconds and my system hangs > >>>> --I press CTRL + ALT + ESC, but nothing happens > >>> > >>> You might want to add DEBUG_VFS_LOCKS. > >>> > >> > >> Yes, I can, but this whole procedure takes me many hours ... > >> I have FreeBSD - the only system on the PC and I need it in > >> working order - I'm working on it > >> > >> Surely no one will be able to repeat my steps, that would verify > >> this especially since I've written previously that the cause may > >> be in the vfs ... > > > > Not sure what your point is. > > So far you seem to be the only one who has the problem (or has > > reported it, at least). >=20 > Could you try disabling some of your modules (fuse, nvidia, etc) > in a stepwise manner? fuse is of particular interest for me to see > whether or not it resolves the problem. > Thanks, > -Garrett --I have updated the source code to r213666 --rebuilt and reinstall: ONLY kernel GENERIC + options DEBUG_VFS_LO= CKS --i NOT reinstall nvidia driver with my patch... --i removed fusefs_enable=3D"YES" in /etc/rc.conf <<<< 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 F3E8F106566C for ; Tue, 12 Oct 2010 12:03:12 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A65198FC1C for ; Tue, 12 Oct 2010 12:03:12 +0000 (UTC) Received: by ywh2 with SMTP id 2so1183562ywh.13 for ; Tue, 12 Oct 2010 05:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RMqo/qATCJSLbvsstIjX2fDprgGdSx61KszN2RXVFfk=; b=ZRgMG5mcSmSOxqyJhUvQ8VNz9aCcVxQZ8b52pTHrYGgO1IgeG9HuRCLFr4oiX6VVZ1 Ykl+RZPTn5BCChFPnf7sDOCCrajzUgMjXWsAu7XKvlnWc7tQeUbD6mfYtktYlhB4NpTK HKy95vmiGQOrphQJIMp7Qhg735P3jAnYAqjMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dRqcLBtt8k1KsdAGCCI3Eey9XIpOCa+2IDF46uin3Iqqk1nNxhsUvYezc2+VlCEtmt fs6W591zrDpJt1Dokz+CGwhJRzyj6Me5eB7oIB2cJdQTu4345qF+1HJSNzRIsQmZonfX X7O5z0QrTQb0A2/3Dwo87RPnK3sZQvRy1TMqI= MIME-Version: 1.0 Received: by 10.42.76.66 with SMTP id d2mr2901305ick.219.1286884991860; Tue, 12 Oct 2010 05:03:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Tue, 12 Oct 2010 05:03:11 -0700 (PDT) In-Reply-To: <20101012145107.2b23914f@ukr.net> References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> <4CB42497.4080105@icyb.net.ua> <20101012145107.2b23914f@ukr.net> Date: Tue, 12 Oct 2010 05:03:11 -0700 X-Google-Sender-Auth: IJiiwZZ0M4TmhVkWXIa1_GVsgt0 Message-ID: From: Garrett Cooper To: Ivan Klymenko Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 12:03:13 -0000 On Tue, Oct 12, 2010 at 4:51 AM, Ivan Klymenko wrote: > =F7 Tue, 12 Oct 2010 02:07:01 -0700 > Garrett Cooper =D0=C9=DB=C5=D4: > >> On Tue, Oct 12, 2010 at 2:04 AM, Andriy Gapon wrote: >> > on 12/10/2010 12:00 Ivan Klymenko said the following: >> >> =F7 Tue, 12 Oct 2010 11:51:05 +0300 >> >> Andriy Gapon =D0=C9=DB=C5=D4: >> >> >> >>> on 12/10/2010 11:35 Ivan Klymenko said the following: >> >>>> --i choose a user, enter a password and press "Enter" >> >>> >> >>> have you switched to text console after the above and before the >> >>> next? >> >> >> >> After the system hangs - no >> > >> > I specifically asked if you switched to text console right after >> > pressing Enter in the above step. =9ASorry if that was not clear. >> > >> >> after a reboot - yes - I went to the console and rebuilt world and >> >> kernel version r231507 again ... >> >> >> >>> >> >>>> --takes a few seconds and my system hangs >> >>>> --I press CTRL + ALT + ESC, but nothing happens >> >>> >> >>> You might want to add DEBUG_VFS_LOCKS. >> >>> >> >> >> >> Yes, I can, but this whole procedure takes me many hours ... >> >> I have FreeBSD - the only system on the PC and I need it in >> >> working order - I'm working on it >> >> >> >> Surely no one will be able to repeat my steps, that would verify >> >> this especially since I've written previously that the cause may >> >> be in the vfs ... >> > >> > Not sure what your point is. >> > So far you seem to be the only one who has the problem (or has >> > reported it, at least). >> >> =9A =9A Could you try disabling some of your modules (fuse, nvidia, etc) >> in a stepwise manner? fuse is of particular interest for me to see >> whether or not it resolves the problem. >> Thanks, >> -Garrett > > --I have updated the source code to r213666 > --rebuilt and reinstall: ONLY kernel GENERIC + options =9A =9A =9A =9A DE= BUG_VFS_LOCKS > --i NOT reinstall nvidia driver with my patch... > --i removed fusefs_enable=3D"YES" in /etc/rc.conf =9A<<<< =9A =9A =9A =9Afusefs-kmod-0.3.9.p1.20080208_6 > > system booted fine and I successfully logged on to gdm! :) > > cause system hangs at the entrance to gdm was a module of the ports of fu= se.ko Try recompiling the module and load it to see whether or not the module has been broken in your recent CURRENT update. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 12:50:31 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 3B951106566B; Tue, 12 Oct 2010 12:50:31 +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 E29D18FC17; Tue, 12 Oct 2010 12:50:29 +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 PAA18687; Tue, 12 Oct 2010 15:50:28 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4CB45993.3090600@icyb.net.ua> Date: Tue, 12 Oct 2010 15:50:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4CA3BD7C.9080306@feral.com> <20101010155340.GQ1733@garage.freebsd.pl> <4CB22833.70304@FreeBSD.org> <201010111103.26780.jhb@freebsd.org> <20101011201156.GB2346@garage.freebsd.pl> In-Reply-To: <20101011201156.GB2346@garage.freebsd.pl> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@FreeBSD.org, phk@FreeBSD.org, John Baldwin , sos@FreeBSD.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 12:50:31 -0000 on 11/10/2010 23:11 Pawel Jakub Dawidek said the following: > Right, but I still wonder if we could execute provider orphan and > retaste on various events like media insertion or removal. If media is I think nobody would disagree with that approach. The issue is to reliably detect those events without interfering with normal usage of the device. Not extremely hard to do, but still has to be done. > removed we orphan provider and recreate it, which will trigger retaste, > and this is fine there will be nothing to read from or write to (we will > simply return errors as we do now, I think). This way we nicely > co-operate with GEOM, but also with other tools that don't require media > to be present (if there is no media devfs entry still exists and handles > ioctls, it just return errors on read requests). > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 13:14:49 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 A751D106566C; Tue, 12 Oct 2010 13:14:49 +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 728678FC1A; Tue, 12 Oct 2010 13:14:49 +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 1866346B51; Tue, 12 Oct 2010 09:14:49 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 278848A029; Tue, 12 Oct 2010 09:14:48 -0400 (EDT) From: John Baldwin To: Pawel Jakub Dawidek Date: Tue, 12 Oct 2010 09:08:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CA3BD7C.9080306@feral.com> <201010111103.26780.jhb@freebsd.org> <20101011201156.GB2346@garage.freebsd.pl> In-Reply-To: <20101011201156.GB2346@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201010120908.24120.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 12 Oct 2010 09:14:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon , sos@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:14:49 -0000 On Monday, October 11, 2010 4:11:56 pm Pawel Jakub Dawidek wrote: > On Mon, Oct 11, 2010 at 11:03:26AM -0400, John Baldwin wrote: > > With CD drives you are also rather stuck in that the existing ABI for > > controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are > > done on the /dev/cdX device. Ideally enclosures for removable media would > > be separate devices from the removable media itself, but a lot of existing > > software for CD's would break if this changes now. > > Right, but I still wonder if we could execute provider orphan and > retaste on various events like media insertion or removal. If media is > removed we orphan provider and recreate it, which will trigger retaste, > and this is fine there will be nothing to read from or write to (we will > simply return errors as we do now, I think). This way we nicely > co-operate with GEOM, but also with other tools that don't require media > to be present (if there is no media devfs entry still exists and handles > ioctls, it just return errors on read requests). Oh, I would be fine with that. I was just explaining the legacy reasons for why we can't do the obvious thing and have separate devices for media and media holders. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 13:36:45 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 C9014106566B for ; Tue, 12 Oct 2010 13:36:45 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 943848FC19 for ; Tue, 12 Oct 2010 13:36:45 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9CDaimW026302 for ; Tue, 12 Oct 2010 06:36:44 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CB4646F.3000703@feral.com> Date: Tue, 12 Oct 2010 06:36:47 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20101012081744.GA48485@jh> In-Reply-To: <20101012081744.GA48485@jh> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Tue, 12 Oct 2010 06:36:45 -0700 (PDT) Subject: Re: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:36:45 -0000 Good workaround, still a nasty surprising bug. > On 2010-10-11, barbara wrote: >> The panic is caused by: >> g_dev_taste(): make_dev_p() failed (gp->name=ext2fs//, error=22) >> as I have a linux partition (I swear, it's for my mom!) on the same machine. >> As I don't care about that partition (being ext4 I can't even mount >> it), is there any solution other then applying the patch after every >> csup? > If you don't need ext2fs labels you can put the following line to > /boot/loader.conf as a workaround: > > kern.geom.label.ext2fs.enable=0 > From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 14:09:11 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 6F30B106564A for ; Tue, 12 Oct 2010 14:09:11 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id E57788FC08 for ; Tue, 12 Oct 2010 14:09:10 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id o9CCjO6p004589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Oct 2010 14:45:24 +0200 Received: from [192.168.100.128] (141.Red-88-4-42.dynamicIP.rima-tde.net [88.4.42.141]) (authenticated bits=0) by ackerman2.upc.es (8.13.8/8.13.8) with ESMTP id o9CCjKa4027168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Oct 2010 14:45:24 +0200 Message-ID: <4CB4585F.5020305@entel.upc.edu> Date: Tue, 12 Oct 2010 14:45:19 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100922 Thunderbird/3.1.4 MIME-Version: 1.0 CC: freebsd-current@freebsd.org References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> <4CB42497.4080105@icyb.net.ua> <20101012145107.2b23914f@ukr.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 12 Oct 2010 14:45:24 +0200 (CEST) Subject: Re: system hangs after logging into gdm [related but OFFTOPIC] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:09:11 -0000 > Try recompiling the module and load it to see whether or not the > module has been broken in your recent CURRENT update. > Thanks! I think fuse has many problems. I locks when being used by gvfs-fuse-daemon (which I may say is very useful as it avoids the task of manually mounting remote network places when using a non gio-aware application). I tried it with both stable and current, and both i386 and amd64. No luck. Is there any plan to port puffs to freebsd ? I read there was a google summer of code in 2009 to port it, but I'm unable to obtain any info. Best regards, Gus > _______________________________________________ > 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 Oct 12 14:22: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 B8E6B1065670 for ; Tue, 12 Oct 2010 14:22:10 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 86EB08FC0A for ; Tue, 12 Oct 2010 14:22:10 +0000 (UTC) Received: by pzk33 with SMTP id 33so944081pzk.13 for ; Tue, 12 Oct 2010 07:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4HHHRYfzVQ+n+lpJLa+kc8EEFHaAQbb870nDUpwEoYM=; b=jWKZBNtlsqsKiXsRK28BGwkmn7FsPAyM64c/n1tR/XQ7BH6C1ECvAK6WYMYKzl+akZ QBdAG1ac0p15zgM1Jv/BfkKn788C/f1Sbxah2AIA6zVj8DrQYrE6C5d+9eHEuA1kXwCM jF9pQ1nRy5wOcIMeDldAZk52FLoO7LRRBQAcA= 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=Lfp6EZmB41QDVHIhhMksTXEp3vudNC13tCD2+F+hEiUK/nAeQIWKxFA969GxlKvaGs V/VtxHV0SOuTiPJkN0o8WM/26e6UQ+GApy8oI31TNvW57zAXid5LWQ8FtoQqHMxFcrcF dIu8KKKX39pjKehD1iCbQae/FCN2jd3UE6y2o= MIME-Version: 1.0 Received: by 10.114.58.19 with SMTP id g19mr8642998waa.73.1286893330109; Tue, 12 Oct 2010 07:22:10 -0700 (PDT) Received: by 10.220.178.1 with HTTP; Tue, 12 Oct 2010 07:22:10 -0700 (PDT) In-Reply-To: <4CB42D3D.1050509@freebsd.org> References: <4CB42D3D.1050509@freebsd.org> Date: Tue, 12 Oct 2010 14:22:10 +0000 Message-ID: From: Paul B Mahol To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: panic on kthread_exit under INVARIANTS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:22:10 -0000 On 10/12/10, David Xu wrote: > Paul B Mahol wrote: >> Hi, >> >> If kernel threads were created via kproc_kthread_add() >> when last kernel thread exits it will trigger panic. >> >> It panics in queue.h .... probably introduced with rec > > > I have committed a patch, can you try it ? > http://svn.freebsd.org/changeset/base/213714 Yes, panic doesn't happen any more. From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 14:24:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A1E661065672; Tue, 12 Oct 2010 14:24:13 +0000 (UTC) Date: Tue, 12 Oct 2010 14:24:13 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101012142413.GA17042@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: partition types 'freebsd-boot' and (g/ufs)labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:24:13 -0000 hi there, glabel seems to ignore IDs, if there are proper labels available. e.g. if a partition has a glabel or a ufs label the gptid or ufsid won't get displayed in 'glabel status'. however for partitions of the type 'freebsd-boot' this doesn't seem to be the case: Name Status Components label/boot N/A ada0p1 gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 label/swap N/A ada0p2 ufs/rootfs N/A ada0p3 label/swapfs N/A ada1p1 ufs/varfs N/A ada1p2 ufs/usrfs N/A ada1p3 as you can see ada0p1 has a proper glabel in place, still in addition to that 'glabel status' shows its gptid. is this really necessary? cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 15:07:15 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 D54CA1065672 for ; Tue, 12 Oct 2010 15:07:15 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 90DA48FC1D for ; Tue, 12 Oct 2010 15:07:15 +0000 (UTC) Received: by yxe42 with SMTP id 42so1294204yxe.13 for ; Tue, 12 Oct 2010 08:07:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=4h1e/vhD5ZXrshn3HapFbBfpKTE4nll3zvlkDUrKVjo=; b=tRBBNADZ0cPgN793vkdaD6yIKZhMKL0yizklq+frNDwQNRdA3158Qmu8SM7AsH/zpc dUcaE+WthqBoTtmzSsFOg5ZEnzrHUKafm1OmcQ+wGDhKhGaHv535Zqf07VWdgkU1bV2j UE53Low3qbox+yvURtcN5xFKAYzrnBHS3vWWU= 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 :content-type; b=YtVUOleUSuiuDZ+yRskSsZFXQUjATmdInBrYMwzHnZkaH2k/qB4ABVewbZhpI2emqI LGJQD4VM3cH4pQlMjAQXoXFdGgG7SvRPLUn4gL2FWrzV/B91fnoLf1bUpSEQ/pDhmTir ivr0HE6iA4mrEx0pYccYefn7h/py35ztea8pA= Received: by 10.42.12.129 with SMTP id y1mr2635308icy.185.1286894587686; Tue, 12 Oct 2010 07:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.140 with HTTP; Tue, 12 Oct 2010 07:42:46 -0700 (PDT) In-Reply-To: <20101012142413.GA17042@freebsd.org> References: <20101012142413.GA17042@freebsd.org> From: Edho P Arief Date: Tue, 12 Oct 2010 21:42:46 +0700 Message-ID: To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: partition types 'freebsd-boot' and (g/ufs)labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:07:15 -0000 On Tue, Oct 12, 2010 at 9:24 PM, Alexander Best wrote: > > as you can see ada0p1 has a proper glabel in place, still in addition to that > 'glabel status' shows its gptid. is this really necessary? > I believe the gptid will only vanish if the partition in question is being used (mounted, part of geom or part of zpool) -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 15:24: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 83A87106564A for ; Tue, 12 Oct 2010 15:24:41 +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 605C58FC08 for ; Tue, 12 Oct 2010 15:24:41 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9CFOfk6001690; Tue, 12 Oct 2010 08:24:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9CFOegP001689; Tue, 12 Oct 2010 08:24:40 -0700 (PDT) (envelope-from sgk) Date: Tue, 12 Oct 2010 08:24:40 -0700 From: Steve Kargl To: Pyun YongHyeon Message-ID: <20101012152440.GA1615@troutmask.apl.washington.edu> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> <20101012002621.GA1554@troutmask.apl.washington.edu> <20101012003329.GL4607@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012003329.GL4607@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:24:41 -0000 On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > > Thanks for the info. I still suspect r213495 might break BCM5704. > Due to lack of BCM5704 I still couldn't test it except guessing. > How about attached one? > Index: sys/dev/bge/if_bge.c > =================================================================== > --- sys/dev/bge/if_bge.c (revision 213711) > +++ sys/dev/bge/if_bge.c (working copy) > @@ -1736,7 +1736,8 @@ > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > - BGE_RCB_FLAG_RING_DISABLED); > + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > + BGE_RCB_FLAG_RING_DISABLED)); > RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > (i * (sizeof(uint64_t))), 0); Unfortunately, this patch does not fix the issue. If I revert r213495 via 'svn merge -r213495:213494 .' in the sys/dev/bge directory, I can build a working kernel. So, I can confirm that r213495 is the source of the problem with a BCM5704 based NIC. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 01:43:11 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 1EB6E106564A for ; Mon, 11 Oct 2010 01:43:11 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (dev.null.cz [89.185.226.27]) by mx1.freebsd.org (Postfix) with ESMTP id A00998FC14 for ; Mon, 11 Oct 2010 01:43:10 +0000 (UTC) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.13.1/8.13.1) with ESMTP id o9B15x02078590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 03:06:04 +0200 (CEST) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.13.1/8.13.1/Submit) id o9B15w6T078589; Mon, 11 Oct 2010 03:05:58 +0200 (CEST) (envelope-from buki) Date: Mon, 11 Oct 2010 03:05:58 +0200 From: "Marek 'Buki' =?iso-8859-2?Q?Kozlovsk=FD?=" To: freebsd-current@freebsd.org Message-ID: <20101011010558.GL28251@dev.null.cz> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sMZCuqyhuhd4ycTi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV 0.88.7/7593/Mon Jun 30 23:00:22 2008 on dev.null.cz X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 12 Oct 2010 17:41:12 +0000 Cc: =?iso-8859-2?B?Um91Yu3oZWsgWmRlbuxr?= Subject: Re: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 01:43:11 -0000 --sMZCuqyhuhd4ycTi Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 09, 2010 at 11:37:49AM +0200, Roub=ED=E8ek Zden=ECk wrote: > I would be also happy to see that coming as I have a problem using curren= t openssl as ipv6 client for tests, though it is bsd v7.3. >=20 well, you always have security/openssl port. > Sorry for not providing anything more then just my wish. >=20 > regards, zdenek > ________________________________________ > From: owner-freebsd-current@freebsd.org [owner-freebsd-current@freebsd.or= g] On Behalf Of Rui Paulo [rpaulo@FreeBSD.org] > Sent: Friday, October 08, 2010 11:42 PM > To: Fabien Thomas > Cc: freebsd-current@freebsd.org > Subject: Re: OpenSSL 1.0 >=20 > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: >=20 > > > > Is there any plan to import OpenSSL 1.0 into the tree? >=20 > You should ask the maintainers. I suspect it's just a matter of available= time (for them). >=20 > Regards, > -- > Rui Paulo >=20 Buki --=20 PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net --sMZCuqyhuhd4ycTi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFMsmL2PzhIkpLLm08RAjbNAJ4jXIPbZaL8vIr3tKncAzmZLj6w8wCgrmCG K1ATvY6rOaFjktdPDjuN5L0= =EzPT -----END PGP SIGNATURE----- --sMZCuqyhuhd4ycTi-- From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 20:38: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 F15D8106564A for ; Mon, 11 Oct 2010 20:38:46 +0000 (UTC) (envelope-from simonln@me.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id DF5B48FC0C for ; Mon, 11 Oct 2010 20:38:46 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [172.10.20.2] (unknown [94.144.63.6]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LA500LVC56EZC00@asmtp028.mac.com>; Mon, 11 Oct 2010 12:38:21 -0700 (PDT) From: "Simon L. B. Nielsen" In-reply-to: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> Date: Mon, 11 Oct 2010 21:37:25 +0200 Message-id: <8B2D0B98-2BE1-4C0C-B1CE-A0E19BBEEA74@me.com> References: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> To: Fabien Thomas X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 12 Oct 2010 17:41:47 +0000 Cc: freebsd-current@freebsd.org Subject: Re: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:38:47 -0000 On 8 Oct 2010, at 13:40, Fabien Thomas wrote: > Is there any plan to import OpenSSL 1.0 into the tree? Hey, Yes, the current plan is to have it in 9.0, but when it will be imported I can't say yet as it depends on having a good continuos chunk of time, which I haven't had too much of lately. I had hoped to get around to looking at it during EuroBSDCon 2010, but I didn't. -- Simon L. B. Nielsen Hat: OpenSSL maintainer From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 20: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 6FED5106564A; Mon, 11 Oct 2010 20:38:59 +0000 (UTC) (envelope-from simonln@me.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 58EC18FC14; Mon, 11 Oct 2010 20:38:59 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-2 Received: from [172.10.20.2] (unknown [94.144.63.6]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LA500LVC56EZC00@asmtp028.mac.com>; Mon, 11 Oct 2010 12:38:33 -0700 (PDT) From: "Simon L. B. Nielsen" In-reply-to: Date: Mon, 11 Oct 2010 21:37:40 +0200 Content-transfer-encoding: quoted-printable Message-id: <582666AB-0082-487D-B5A9-6AAC9B7D2531@me.com> References: <7839CA44-E467-4C77-AC41-BF5389FFCCDC@netasq.com> To: =?utf-8?Q?Roub=C3=AD=C4=8Dek_Zden=C4=9Bk?= X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 12 Oct 2010 17:41:47 +0000 Cc: "freebsd-current@freebsd.org" , Rui Paulo , Fabien Thomas Subject: Re: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:38:59 -0000 On 9 Oct 2010, at 11:37, Roub=ED=E8ek Zden=ECk wrote: > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: >=20 >> Is there any plan to import OpenSSL 1.0 into the tree? > I would be also happy to see that coming as I have a problem using = current openssl as ipv6 client for tests, though it is bsd v7.3. If you need a newer version of OpenSSL in FreeBSD 7 you should try the = OpenSSL ports. FreeBSD 7 will probably get the latest 0.9.8 before = FreeBSD 7.4, but it won't get OpenSSL 1.0 (and neither will FreeBSD 8 = for that matter). --=20 Simon L. B. Nielsen Hat: OpenSSL maintainer From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 08:16: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 48E47106564A; Mon, 11 Oct 2010 08:16:55 +0000 (UTC) (envelope-from soren.schmidt@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A10078FC0C; Mon, 11 Oct 2010 08:16:54 +0000 (UTC) Received: by wyf19 with SMTP id 19so77363wyf.13 for ; Mon, 11 Oct 2010 01:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Rsijf9A83OUknbXih8mK/Qf2oGbyCQYgjw34iOIZ34s=; b=MObJ5pbq+jO9UY6uwVn5PSTUa57doiqCvIb6/4xrEIalKw6USVfUrYwk3bcB8VY/tn 9rDctALDRhmXyIHrSMFZtRVSRspx8BpENDiucY1vs2Ch2AAwKcqK9dRJta9ZlHaxZtbc L6/HyZ5Rb0uHhHmBRCOaZxdc7wToQD/QDayP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Mp49mMp6CBmOBNfhtB3VAM0K2kCB32yVV/+nyIOuhbIUY7c86JOJmrPD+VnZm3yed/ JIDflT1nlrEsiFwHP7gYPnXJs4S56ME1aEcSu0xkayLEPw+w6jbBKxxQZV/8BFGhcIn6 eJSNvcLICXvHOODz+FESIKvRTyKZwqWnhSgZA= Received: by 10.216.16.33 with SMTP id g33mr3329278weg.40.1286783206147; Mon, 11 Oct 2010 00:46:46 -0700 (PDT) Received: from ws.deepcore.dk (cable.deepcore.dk [217.20.59.72]) by mx.google.com with ESMTPS id x23sm2359317weq.10.2010.10.11.00.46.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Oct 2010 00:46:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <4CB22833.70304@FreeBSD.org> Date: Mon, 11 Oct 2010 09:46:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <358D7DEF-4EEB-4E22-A251-DC383FF57BCD@gmail.com> References: <4CA3BD7C.9080306@feral.com> <4CA4CCE3.9060408@FreeBSD.org> <20101010155340.GQ1733@garage.freebsd.pl> <4CB22833.70304@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 12 Oct 2010 17:42:08 +0000 Cc: sos@FreeBSD.ORG, FreeBSD-Current , Pawel Jakub Dawidek , Andriy Gapon , phk@FreeBSD.ORG Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:16:55 -0000 On 10/10/2010, at 22.55, Alexander Motin wrote: > Pawel Jakub Dawidek wrote: >> On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: >>> Andriy Gapon wrote: >>>> on 30/09/2010 01:28 Matthew Jacob said the following: >>>>> If something like that was in place, I assure you that things = would start to use >>>>> it very quickly. >>>> I am not sure about this. >>>> Because, e.g. I don't see an easy way to know that media is changed = in scsi_cd >>>> driver. That is, without polling. I don't consider polling to be = an easy way for >>>> a number of reasons. >>> SATA specification defines concept of Asynchronous Notification. It = is >>> already used by port multipliers to report about PHY events. It is = also >>> supposed to be used by CD drives to report media change. I haven't = seen >>> such devices yet, but hope they may appear sometimes. >>>=20 >>> And even without AN support it would be nice to implement proper >>> handling for SCSI "UA - media changed" errors within CAM. It still = won't >>> be perfect without using polling, but probably still something. >>=20 >> I'd like to know the original reason why CD device is represented by >> GEOM provider and not CD media. For my naive thinking CD media should = be >> GEOM provider that we taste once the media is inserted and orphan = once >> the media is removed. I don't see any reasons for CD device to be = useful >> GEOM provider, but maybe I'm overlooking something. >>=20 >> Poul-Henning or Soren, do you remember who made and why this design = choice? >=20 > SCSI drivers receive no notification on media insertion. Somebody = should > poll device. At this moment it is handled by consumers. Indeed not = sure > it is the best idea. If we want driver to bother with this polling - = we > may do as you propose. Actually in sdhci(4) driver I am doing this way = - > mmcsdX device appears when card inserted and disappears on removal. >=20 > I think first thing that may brake if there will be no cdX device - > loading the media with some commands. Also it may be non-intuitive = that > drive is present, but disk is not registered in GEOM. Think burning data on empty media. -S=F8ren "Any sufficiently advanced technology is indistinguishable from magic." -- From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 18:12: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 CC621106567A; Tue, 12 Oct 2010 18:12:43 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.23]) by mx1.freebsd.org (Postfix) with ESMTP id 82C0C8FC1C; Tue, 12 Oct 2010 18:12:42 +0000 (UTC) Received: from 127-22-132-95.pool.ukrtel.net ([95.132.22.127] helo=localhost) by fsm1.ukr.net with esmtps ID 1P5jL7-000IEt-7P ; Tue, 12 Oct 2010 21:12:41 +0300 Date: Tue, 12 Oct 2010 21:12:39 +0300 From: Ivan Klymenko To: Garrett Cooper Message-ID: <20101012211239.58a93142@ukr.net> In-Reply-To: References: <20101011105904.70dd7e7f@ukr.net> <4CB2D317.9010004@icyb.net.ua> <20101012113542.5eaf5321@ukr.net> <4CB42179.10302@icyb.net.ua> <20101012120002.75ed1f2d@ukr.net> <4CB42497.4080105@icyb.net.ua> <20101012145107.2b23914f@ukr.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: system hangs after logging into gdm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:12:43 -0000 > > --I have updated the source code to r213666 > > --rebuilt and reinstall: ONLY kernel GENERIC + options > > DEBUG_VFS_LOCKS --i NOT reinstall nvidia driver with my patch... > > --i removed fusefs_enable=3D"YES" in /etc/rc.conf =C2=A0<<<< > =C2=A0 =C2=A0 =C2=A0 =C2=A0fusefs-kmod-0.3.9.p1.20080208_6 > > > > system booted fine and I successfully logged on to gdm! :) > > > > cause system hangs at the entrance to gdm was a module of the ports > > of fuse.ko >=20 > Try recompiling the module and load it to see whether or not the > module has been broken in your recent CURRENT update. > Thanks! > -Garrett I updated the kernel source code and the world to r213666 I rebuilt the port fusefs-kmod-0.3.9.p1.20080208_6 everything works fine! In fact, there is no problem! Thank you all! P.S. I am ashamed that I could not find the problem yourself, the more that= once during the FreeBSD 5.4 I am on such a problem with fuse.ko already st= umbled. : ( From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 18:49:06 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 1827B1065670; Tue, 12 Oct 2010 18:49:06 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0050C8FC14; Tue, 12 Oct 2010 18:49:05 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o9CIn5C8030353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Oct 2010 11:49:05 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 567A51CC3E; Tue, 12 Oct 2010 11:49:05 -0700 (PDT) To: "Simon L. B. Nielsen" In-reply-to: Your message of "Mon, 11 Oct 2010 21:37:40 +0200." <582666AB-0082-487D-B5A9-6AAC9B7D2531@me.com> Date: Tue, 12 Oct 2010 11:49:05 -0700 From: "Kevin Oberman" Message-Id: <20101012184905.567A51CC3E@ptavv.es.net> Cc: =?utf-8?Q?Roub=C3=AD=C4=8Dek_Zden=C4=9Bk?= , Rui Paulo , Fabien Thomas , "freebsd-current@freebsd.org" Subject: Re: OpenSSL 1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:49:06 -0000 > From: "Simon L. B. Nielsen" > Date: Mon, 11 Oct 2010 21:37:40 +0200 > Sender: owner-freebsd-current@freebsd.org > > On 9 Oct 2010, at 11:37, Roubíèek Zdenìk wrote: > > > On 8 Oct 2010, at 12:40, Fabien Thomas wrote: > > > >> Is there any plan to import OpenSSL 1.0 into the tree? > > I would be also happy to see that coming as I have a problem using > current openssl as ipv6 client for tests, though it is bsd v7.3. > > If you need a newer version of OpenSSL in FreeBSD 7 you should try the > OpenSSL ports. FreeBSD 7 will probably get the latest 0.9.8 before > FreeBSD 7.4, but it won't get OpenSSL 1.0 (and neither will FreeBSD 8 > for that matter). The problem is API differences. I hit ports which work with the port but fail with the base system and other ports that work with the base libssl but fail with the port installed. As a result, I have stuck with the base system. I've had to remove the port version a couple of times and rebuild all of the ports that had linked to it. A real pain. I understand why maintainers make some ports work with the old openssl in the base, but other don't and that road leads to madness. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 19:25: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 10C16106564A for ; Tue, 12 Oct 2010 19:25:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B4D3D8FC17 for ; Tue, 12 Oct 2010 19:25:26 +0000 (UTC) Received: by gwb15 with SMTP id 15so1862800gwb.13 for ; Tue, 12 Oct 2010 12:25:25 -0700 (PDT) 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=g42mSB2y8tFsUFMiJepex4HYFEEcMXOwyyhmsARKBUk=; b=ZHYiGTcXuwflSI9Zi2o77LM10cgpzEI0agNQQ3DixJSq8loIHqroqEzqnJl/TqvqAB z56AhYSqvTe6rhNvmHOEhgPSK8Tff/azhxgfSKeC7h0/coybdf/Y1PlRaAOu9WLcCCA8 duhiFZ4hDJibEbkLwL6605X3gfwUlI8dXnsHI= 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=XsNc7Z7z8ZZesnaMZJ9ccv/tR6wsUm3OjQshLQTfDANWw1wkChNPc5AMkQbKq1qBkF 4FtPm6rK/rAm6rnx41PK0iTXZZmqUUrhhg+2CK3rD+GqaVbjmvrKw6slKupt+qO54Sc4 7EnpN5Jucrmy2XQr00nhr6rwXpqy2JbehxJuo= Received: by 10.236.105.130 with SMTP id k2mr15732990yhg.57.1286911525781; Tue, 12 Oct 2010 12:25:25 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 28sm10914691anv.6.2010.10.12.12.25.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Oct 2010 12:25:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 12 Oct 2010 12:23:40 -0700 From: Pyun YongHyeon Date: Tue, 12 Oct 2010 12:23:40 -0700 To: Steve Kargl Message-ID: <20101012192340.GG10094@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> <20101012002621.GA1554@troutmask.apl.washington.edu> <20101012003329.GL4607@michelle.cdnetworks.com> <20101012152440.GA1615@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012152440.GA1615@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: recent bge(4) changes causing problems 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 Oct 2010 19:25:27 -0000 On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: > On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > > > > Thanks for the info. I still suspect r213495 might break BCM5704. > > Due to lack of BCM5704 I still couldn't test it except guessing. > > How about attached one? > > > Index: sys/dev/bge/if_bge.c > > =================================================================== > > --- sys/dev/bge/if_bge.c (revision 213711) > > +++ sys/dev/bge/if_bge.c (working copy) > > @@ -1736,7 +1736,8 @@ > > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > > RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > > RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > > - BGE_RCB_FLAG_RING_DISABLED); > > + BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > > + BGE_RCB_FLAG_RING_DISABLED)); > > RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > > bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > > (i * (sizeof(uint64_t))), 0); > > Unfortunately, this patch does not fix the issue. > > If I revert r213495 via 'svn merge -r213495:213494 .' > in the sys/dev/bge directory, I can build a working > kernel. So, I can confirm that r213495 is the source > of the problem with a BCM5704 based NIC. > Fix committed to HEAD(r213742). From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 20:11:30 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 8C6141065695 for ; Tue, 12 Oct 2010 20:11:30 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB5B8FC1E for ; Tue, 12 Oct 2010 20:11:29 +0000 (UTC) Received: by gyf3 with SMTP id 3so1332140gyf.13 for ; Tue, 12 Oct 2010 13:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=M129JlZwmEhZquujEU3d0md3PXuoa+GO8bJSRlPOsEc=; b=Uwbm6PCuJdJqV+msR1mJ/GEnLo+/lDdlasRP9Z3U4OCgwhrt91AvSSacHxSiGUcC14 ym/1FxKvWCca0SktmsVSGC42RCCm/mGfR1+XK0z4e5FO+Q59SZtASF2YyGvxIvvZ+X4H 4hbdsGJYGfoReYvlhlg0AonSEtBvoUx43s/i0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EsWQz2XaYXhlRHYQk/RVTo3LxL0uNrpdX7juF9WiqcsoPpfs+6oXTcWu4VClLVRTDS TCCYuCzyY+lHYlmoysZaCR7Tg7mt5xwvYSfmo8MSHL4XTWshimLbpbK7YPx7feFDzN9A Al4V0VkZ/rpAKaDEeOLb00LfyqAvbLyo1qapc= MIME-Version: 1.0 Received: by 10.90.73.9 with SMTP id v9mr3847248aga.89.1286914289375; Tue, 12 Oct 2010 13:11:29 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.90.109.16 with HTTP; Tue, 12 Oct 2010 13:11:29 -0700 (PDT) In-Reply-To: <20101012192340.GG10094@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> <20101012002621.GA1554@troutmask.apl.washington.edu> <20101012003329.GL4607@michelle.cdnetworks.com> <20101012152440.GA1615@troutmask.apl.washington.edu> <20101012192340.GG10094@michelle.cdnetworks.com> Date: Tue, 12 Oct 2010 13:11:29 -0700 X-Google-Sender-Auth: tRoMiwtmkxPYiactrq20qfNlYFE Message-ID: From: Garrett Cooper To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: recent bge(4) changes causing problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:11:30 -0000 On Tue, Oct 12, 2010 at 12:23 PM, Pyun YongHyeon wrote: > On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: >> On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: >> > >> > Thanks for the info. I still suspect r213495 might break BCM5704. >> > Due to lack of BCM5704 I still couldn't test it except guessing. >> > How about attached one? >> >> > Index: sys/dev/bge/if_bge.c >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > --- sys/dev/bge/if_bge.c =A0 =A0(revision 213711) >> > +++ sys/dev/bge/if_bge.c =A0 =A0(working copy) >> > @@ -1736,7 +1736,8 @@ >> > =A0 =A0 =A0 =A0 =A0 =A0 RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi= , 0); >> > =A0 =A0 =A0 =A0 =A0 =A0 RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo= , 0); >> > =A0 =A0 =A0 =A0 =A0 =A0 RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 BGE_RCB_FLAG_RING_DISABLED); >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring= _cnt, >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 BGE_RCB_FLAG_RING_DISABLED)); >> > =A0 =A0 =A0 =A0 =A0 =A0 RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); >> > =A0 =A0 =A0 =A0 =A0 =A0 bge_writembx(sc, BGE_MBX_RX_CONS0_LO + >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (i * (sizeof(uint64_t))), 0); >> >> Unfortunately, this patch does not fix the issue. >> >> If I revert r213495 via 'svn merge -r213495:213494 .' >> in the sys/dev/bge directory, I can build a working >> kernel. =A0So, I can confirm that r213495 is the source >> of the problem with a BCM5704 based NIC. >> > > Fix committed to HEAD(r213742). Could this be a firmware bug? A similar issue has occurred in the past with bce(4) where you have to upgrade the firmware and the driver in tandem in order for things to function properly, so maybe if the firmware was upgraded to the latest version (unfortunately only Linux methods exist I think), this issue would go away? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 20:31: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 3D3F4106566B for ; Tue, 12 Oct 2010 20:31:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDFF48FC13 for ; Tue, 12 Oct 2010 20:31:54 +0000 (UTC) Received: by ywh2 with SMTP id 2so1429916ywh.13 for ; Tue, 12 Oct 2010 13:31:54 -0700 (PDT) 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=Qi2Rk+Rsb9nSIpv1fnlmQQHF8a64QYUkK1hDEhxn2xo=; b=HdQuOXLqLV0624x7xnHankm0wNf9i+TrddPqv+2HrndgYoSsSOlxeM681q9Gulf+5Z 63PuJp6TpwbdJEn4wi5A0NSHInh8dbnb3ml3NaxDlXpAVPlz6zNMJBHZZc7RMZ/HbMOv TGGS9mdxwSXkIHHlc2c0K37UEzdnbaogcqKrY= 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=aXjdCgdivggYF9XL9yzaR3FX58Lz75l0meiI8rugDy3+EuuZ/v66RNAmFHreCbIhI/ 0BAUwhGa2hpVOYyDKERMMI2UCb6p8dBHA7Xk68wz+1EvIwAL6NXPbVSgg94vCIHRDXMO W+nl4t2ufuEYhvsuP34rfren7XLIzvm3lA5Yo= Received: by 10.100.6.2 with SMTP id 2mr4070837anf.75.1286915513962; Tue, 12 Oct 2010 13:31:53 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z9sm10984554ank.27.2010.10.12.13.31.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Oct 2010 13:31:52 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 12 Oct 2010 13:30:07 -0700 From: Pyun YongHyeon Date: Tue, 12 Oct 2010 13:30:07 -0700 To: Garrett Cooper Message-ID: <20101012203007.GH10094@michelle.cdnetworks.com> References: <20101011225331.GA2829@troutmask.apl.washington.edu> <20101011231604.GI4607@michelle.cdnetworks.com> <20101012000216.GA1554@troutmask.apl.washington.edu> <20101012000927.GK4607@michelle.cdnetworks.com> <20101012001510.GA6789@troutmask.apl.washington.edu> <20101012002621.GA1554@troutmask.apl.washington.edu> <20101012003329.GL4607@michelle.cdnetworks.com> <20101012152440.GA1615@troutmask.apl.washington.edu> <20101012192340.GG10094@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org, Steve Kargl Subject: Re: recent bge(4) changes causing problems 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 Oct 2010 20:31:55 -0000 On Tue, Oct 12, 2010 at 01:11:29PM -0700, Garrett Cooper wrote: > On Tue, Oct 12, 2010 at 12:23 PM, Pyun YongHyeon wrote: > > On Tue, Oct 12, 2010 at 08:24:40AM -0700, Steve Kargl wrote: > >> On Mon, Oct 11, 2010 at 05:33:29PM -0700, Pyun YongHyeon wrote: > >> > > >> > Thanks for the info. I still suspect r213495 might break BCM5704. > >> > Due to lack of BCM5704 I still couldn't test it except guessing. > >> > How about attached one? > >> > >> > Index: sys/dev/bge/if_bge.c > >> > =================================================================== > >> > --- sys/dev/bge/if_bge.c ? ?(revision 213711) > >> > +++ sys/dev/bge/if_bge.c ? ?(working copy) > >> > @@ -1736,7 +1736,8 @@ > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_hi, 0); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_hostaddr.bge_addr_lo, 0); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_maxlen_flags, > >> > - ? ? ? ? ? ? ? BGE_RCB_FLAG_RING_DISABLED); > >> > + ? ? ? ? ? ? ? BGE_RCB_MAXLEN_FLAGS(sc->bge_return_ring_cnt, > >> > + ? ? ? ? ? ? ? BGE_RCB_FLAG_RING_DISABLED)); > >> > ? ? ? ? ? ? RCB_WRITE_4(sc, vrcb, bge_nicaddr, 0); > >> > ? ? ? ? ? ? bge_writembx(sc, BGE_MBX_RX_CONS0_LO + > >> > ? ? ? ? ? ? ? ? (i * (sizeof(uint64_t))), 0); > >> > >> Unfortunately, this patch does not fix the issue. > >> > >> If I revert r213495 via 'svn merge -r213495:213494 .' > >> in the sys/dev/bge directory, I can build a working > >> kernel. ?So, I can confirm that r213495 is the source > >> of the problem with a BCM5704 based NIC. > >> > > > > Fix committed to HEAD(r213742). > > Could this be a firmware bug? A similar issue has occurred in the > past with bce(4) where you have to upgrade the firmware and the driver > in tandem in order for things to function properly, so maybe if the > firmware was upgraded to the latest version (unfortunately only Linux > methods exist I think), this issue would go away? Not sure whether this is firmware related thing or not. Public data sheet explicitly says that BCM5700 with external SSRAM is the only controller that supports mini ring. So r213475 disabled mini ring for BCM5700 only. Data sheet also says disabling mini ring for all BCM570[0-4] controllers is optional one in its initialization. However that was not true and all BCM570[0-4] seems to require disabling mini ring. > Thanks, > -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 20:57: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 3E52F1065679 for ; Tue, 12 Oct 2010 20:57:44 +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 7880B8FC1E for ; Tue, 12 Oct 2010 20:57:43 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA25932; Tue, 12 Oct 2010 23:57:38 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1P5luj-000PBX-TQ; Tue, 12 Oct 2010 23:57:37 +0300 Message-ID: <4CB4CBC1.40301@icyb.net.ua> Date: Tue, 12 Oct 2010 23:57:37 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matthew Jacob References: <20101012081744.GA48485@jh> <4CB4646F.3000703@feral.com> In-Reply-To: <4CB4646F.3000703@feral.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 20:57:44 -0000 on 12/10/2010 16:36 Matthew Jacob said the following: > Good workaround, still a nasty surprising bug. Yeah. I also would prefer ignoring such a partition or somehow sanitizing its name or etc. panic(9) on bad internal state of a kernel sounds appropriate, panic(9) on bad input sounds like trouble. P.S. Matthew, it seems like you have a really unhelpful mail client program: first, it top-posts :-) second, it doesn't always attribute quoted text. It also doesn't cc in replies the addresses that were in to or cc of original message, which may or may not be a good thing. >> On 2010-10-11, barbara wrote: >>> The panic is caused by: >>> g_dev_taste(): make_dev_p() failed (gp->name=ext2fs//, error=22) >>> as I have a linux partition (I swear, it's for my mom!) on the same machine. >>> As I don't care about that partition (being ext4 I can't even mount >>> it), is there any solution other then applying the patch after every >>> csup? >> If you don't need ext2fs labels you can put the following line to >> /boot/loader.conf as a workaround: >> >> kern.geom.label.ext2fs.enable=0 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Oct 12 21:35:06 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 0D98D1065695 for ; Tue, 12 Oct 2010 21:35:06 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id CBD568FC1C for ; Tue, 12 Oct 2010 21:35:05 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o9CLYurA031685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 12 Oct 2010 14:35:05 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4CB4D47D.9030008@feral.com> Date: Tue, 12 Oct 2010 14:34:53 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20101012081744.GA48485@jh> <4CB4646F.3000703@feral.com> <4CB4CBC1.40301@icyb.net.ua> In-Reply-To: <4CB4CBC1.40301@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Tue, 12 Oct 2010 14:35:05 -0700 (PDT) Subject: Re: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 21:35:06 -0000 I am antisocial. Okay, changed it so my replies are above the quotes. Seems to have attributes here. And I usually hit 'reply list' since multiple copies burns bandwidth. On 10/12/2010 1:57 PM, Andriy Gapon wrote: > > P.S. Matthew, it seems like you have a really unhelpful mail client program: > first, it top-posts :-) > second, it doesn't always attribute quoted text. > > It also doesn't cc in replies the addresses that were in to or cc of original > message, which may or may not be a good thing. > > From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 01:28:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 562281065670; Wed, 13 Oct 2010 01:28:03 +0000 (UTC) Date: Wed, 13 Oct 2010 01:28:03 +0000 From: Alexander Best To: Edho P Arief Message-ID: <20101013012803.GA25895@freebsd.org> References: <20101012142413.GA17042@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: partition types 'freebsd-boot' and (g/ufs)labels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 01:28:03 -0000 On Tue Oct 12 10, Edho P Arief wrote: > On Tue, Oct 12, 2010 at 9:24 PM, Alexander Best wrote: > > > > as you can see ada0p1 has a proper glabel in place, still in addition to that > > 'glabel status' shows its gptid. is this really necessary? > > > > I believe the gptid will only vanish if the partition in question is > being used (mounted, part of geom or part of zpool) thank you very much for the hint. that sounds very reasonable. cheers, alex > > -- > O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 08:49: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 3E531106566B for ; Wed, 13 Oct 2010 08:49:59 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id EDB048FC12 for ; Wed, 13 Oct 2010 08:49:58 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id EF578139833; Wed, 13 Oct 2010 11:49:53 +0300 (EEST) Date: Wed, 13 Oct 2010 11:49:53 +0300 From: Jaakko Heinonen To: Andriy Gapon Message-ID: <20101013084953.GA54686@jh> References: <20101012081744.GA48485@jh> <4CB4646F.3000703@feral.com> <4CB4CBC1.40301@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB4CBC1.40301@icyb.net.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Matthew Jacob Subject: Re: HEADS UP: device name checking on device registration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:49:59 -0000 On 2010-10-12, Andriy Gapon wrote: > on 12/10/2010 16:36 Matthew Jacob said the following: > > Good workaround, still a nasty surprising bug. > > Yeah. I also would prefer ignoring such a partition or somehow sanitizing its > name or etc. panic(9) on bad internal state of a kernel sounds appropriate, > panic(9) on bad input sounds like trouble. I am working on a change for GEOM. I will post a patch to -geom for comments shortly. I want just to note that previously bad names could cause erratic behavior (including panics) deep in devfs code instead of catching them early. -- Jaakko From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 11:04:57 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 247CD1065670; Wed, 13 Oct 2010 11:04:57 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB3A8FC16; Wed, 13 Oct 2010 11:04:56 +0000 (UTC) Received: by gyf3 with SMTP id 3so1585862gyf.13 for ; Wed, 13 Oct 2010 04:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FmnrUex4CjnM75QJfA42JdvQTvm8kn9MiFt1JhEptUw=; b=WbAeTyOjyFs8YEucVk80GK59Dj5IgJ2AbhAmrpZp1HFgrDh0iRiBX7tqLqn1QwFMZq anJlB/0OrJYpyswC6iuChSY35VSlwyEF2fMk0JO4j+ut0s3IwaEVuZviDtkqmQa4vkZg Y4DscHfTMDKy9RNcAVRhAKHsbzs3humynHT2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=AZviO6avwzfw5akY1JCjmspEyk+ISzogsT/houLAuWx+Ux/neQa3IAZTOBFf2RDMLs BXzmIJFVPyhqYN1F/xOuUMJXtZXT4+q0e4DK+udCsJ9ouoIP4akEDRysnC3rwiexmzI7 /v6bWGWQD17+SFAxpKU9cQ1EfKntob3LTNSsE= MIME-Version: 1.0 Received: by 10.151.42.5 with SMTP id u5mr819214ybj.259.1286967895490; Wed, 13 Oct 2010 04:04:55 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.150.143.19 with HTTP; Wed, 13 Oct 2010 04:04:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 13:04:54 +0200 X-Google-Sender-Auth: HVuO12zbGvEvfCtL0I3E8Q5_WfM Message-ID: From: Attilio Rao To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Nima Misaghian , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 11:04:57 -0000 2010/10/9 Robert Watson : > On Fri, 8 Oct 2010, Attilio Rao wrote: > >>> GENERAL FRAMEWORK ARCHITECTURE >>> >>> Netdump is composed, right now, by an userland "server" and a kernel >>> "client". The former is run on the target machine (where the dump will >>> phisically happen) and it is responsible for receiving =C2=A0the packet= s >>> containing coredumps frame and for correctly writing them on-disk. The >>> latter is part of the kernel installed on the source machine (where the= dump >>> is initiated) and is responsible for building correctly UDP packets >>> containing the coredump frames, pushing through the network interface a= nd >>> routing them appropriately. > > Hi Attilio: > > Network dumps would be a great addition to the FreeBSD debugging suite! = =C2=A0A > few casual comments and questions, I need to spend some more time ponderi= ng > the implications of the current netdump design later in the week. > > (1) Did you consider using tftp as the network dump protocol, rather than= a > custom protocol? =C2=A0It's also a simple UDP-based, ACKed file transfer > protocol, with the advantage that it's widely supported by exiting tftp > daemons, packet sniffers, security devices, etc. =C2=A0This wouldn't requ= ire > using a stock tftpd, although that would certainly be a benefit as well. > =C2=A0The post-processing of crashdumps that seems to happen in the netdu= mp > server could, presumably, happen "offline" as easily...? I don't understand the "offline" question but, really, I don't know why tftp wasn't considered in the first place. Let me do some small search and see how much we could benefit from it. > (2) Have you thought about adding a checksum to the dump format, since > packets are going over the wire on UDP, etc? =C2=A0Even an MD5 sum wouldn= 't be > too hard to arrange: all the code is in the kernel already, requires > relatively little state storage, and is designed for streamed data. Someone else already brought this point and I agree, we could use a checksum here. > (3) As the bounds checking/etc behavior in dumping grows more complex, it > seems a shame to replicate it in architecture-specific code. =C2=A0Could = we pull > the mediaoffset/mediasize checking into common code? =C2=A0Also, a reserv= ed > size/offset of "0" meaning "no limit" sounds slightly worrying; it might = be > slightly more conservative to add a flags field to dumperinfo and have a > flag indicating "size is no object" for netdump, rather than overloading = the > existing fields. I don't agree with you here. The real problem is that dumpsys is highly disk-specific (I've commented about it somewhere, maybe the e-mail or maybe the commit logs). What we'd need is to have something like netdumpsys() which tries to use network, but it is not short to make and the mediasize+mediaoffset concept really rappresents an higher bound which can't be 0. I think it is a reasonable compromise so far but it is subjected to further improvements for sure. > Some specific patch comments: > > + * XXX: This should be split into machdep and non-machdep parts > > What MD parts are in the file? This is just a stale comment. > The sysctl parts of the patch have a number of issues: Sysctl are still not overhauled just because I'm not sure we want to keep them. That is one of the points I raised in the main e-mail and I'd really would like to hear opinions about if we should keep them rather than having a setup userland process, etc. I'm sorry about this, but please keep in mind that the file still needs a lot of cleanup so some comments are a bit out of date and other parts may not be still perfectly overhauled. > +sysctl_force_crash(SYSCTL_HANDLER_ARGS) > > Does this belong in the netdump code? =C2=A0We already have some of these= options > in debug.kdb.*, but perhaps others should be added there as well. For this specific case, I'd really axe it out rather. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get and fill a= header mbuf, then chain data as an > extended > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* mbuf. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MGETHDR(m, M_DONTWAIT,= MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freak= y, > and may have some truly awful side effects. =C2=A0I suppose this is the c= ost of > trying to combine code paths in the network device driver rather than hav= e > an independent path in the netdump case, but it's quite unfortunate and w= ill > significantly reduce the robustness of netdumps in the face of, for examp= le, > mbuf starvation. I'm not sure in which other way we could fix that actually. Maybe a pre-allocated pool of mbufs? > + =C2=A0 =C2=A0 =C2=A0 if (ntohs(ah->ar_hrd) !=3D ARPHRD_ETHER && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_IEEE80= 2 && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_ARCNET= && > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ntohs(ah->ar_hrd) !=3D ARPHRD_IEEE13= 94) { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NETDDEBUG("nd_handle_a= rp: unknown hardware address fmt " > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "0x%2D)\= n", (unsigned char *)&ah->ar_hrd, ""); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return; > + =C2=A0 =C2=A0 =C2=A0 } > > Are you sure you don't want to just check for ETHER here? I'd really like to hear Ryan's or Ed's idea here. > + =C2=A0 =C2=A0 =C2=A0 /* XXX: Probably should check if we're the recipie= nt MAC address */ > + =C2=A0 =C2=A0 =C2=A0 /* Done ethernet processing. Strip off the etherne= t header */ > > Yes, quite probably. =C2=A0What if you panic in promiscuous mode? > > + =C2=A0 =C2=A0 =C2=A0 /* > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* The first write (at offset 0) is the kerne= l dump header. =C2=A0Flag it > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* for the server to treat specially. =C2=A0X= XX: This doesn't strip out > the > + =C2=A0 =C2=A0 =C2=A0 =C2=A0* footer KDH, although it shouldn't hurt any= thing. > + =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > > The footer allows us to confirm that the tail end of a dump matches the > beginning; while probably not strictly necessary in this scenario, it's n= ot > a bad idea given the lack of a checksum. So I assume you are in favor of it, right? > + =C2=A0 =C2=A0 =C2=A0 /* Default the nic to the first available interfac= e */ > + =C2=A0 =C2=A0 =C2=A0 if ((ifn =3D TAILQ_FIRST(&ifnet)) !=3D NULL) do { > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if ((ifn->if_flags & I= FF_UP) =3D=3D 0) > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 continue; > > More locking needed. Please refer to the second patch I posted. It should have proper locking and actually this code is just trimmed (more locking in V_ifnet accessings, but not in this codepath). > > - =C2=A0 =C2=A0 =C2=A0 void =C2=A0 =C2=A0*if_pspare[7]; > + =C2=A0 =C2=A0 =C2=A0 struct =C2=A0netdump_methods *if_ndumpfuncs; /* ne= tdump virtual methods > */ > + =C2=A0 =C2=A0 =C2=A0 void =C2=A0 =C2=A0*if_pspare[6]; > =C2=A0 =C2=A0 =C2=A0 =C2=A0int =C2=A0 =C2=A0 if_ispare[4]; > > In HEAD, at least, you should add your field and not use the spare. =C2= =A0The > spare should only be used on a merge to a KBI-stable branch (such as 8.x)= . Thanks, for picking this. > I need to ponder your changes to ifnet and to the drivers some more; I > recognize the benefits of maximal code alignment, but I worry a lot about > these code paths having side effects (not least, calls into memory > allocators, which in turn can enter VM, etc). =C2=A0I wonder if, given th= at, we > need to teach the mbuf allocator to be much more conservative if netdumpi= ng > is active... Sorry, which calls from drivers should get in the memory allocator? Are you just referring to the mbuf headers allocation? Changes to the drivers are mostly stright-forward -- they just try to do polling in locked or unlocked mode, following DDB entering or not (basically how other DDB-agnostic routines already do in FreeBSD for the known locking problems we discussed several times in the past). Thanks for your valuable feedback, looking forward to hear more. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 13:07:23 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 D4154106566B for ; Wed, 13 Oct 2010 13:07:23 +0000 (UTC) (envelope-from ecrist@secure-computing.net) Received: from kenny.secure-computing.net (kenny.secure-computing.net [173.8.118.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8BBEC8FC12 for ; Wed, 13 Oct 2010 13:07:23 +0000 (UTC) Received: from [192.168.1.8] (ms.choksondik.secure-computing.net [173.8.118.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ecrist@secure-computing.net) by kenny.secure-computing.net (Postfix) with ESMTP id DC8032E0A6; Wed, 13 Oct 2010 07:42:19 -0500 (CDT) From: Eric Crist Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Oct 2010 07:42:19 -0500 Message-Id: <7B979EC3-3829-424A-9187-E1294371B192@secure-computing.net> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Thomas Johnson Subject: NFSv3 + 8.1 + rpc.[lockd|statd] issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:07:24 -0000 Hey folks, We have a machine running FreeBSD 8.1-RELEASEp1 acting as an NFS server = hosting 3 ZFS file systems on an external enclosure. There are a bunch = of machines, ranging from 4.11, 7.1, and 8.x systems acting as NFS = clients to this server. Running dmesg on the NFS server shows no errors = at all, but the three different clients show differing errors. On the = panther example below, it was reported last night a 48MB file took about = 90 minutes to transfer. I'm working on upgrading the 7.1 system to 8.1 now, so I'm not quite as = concerned with that, but the rpcbind errors that show on both 7.1 and = 8.1 are causing core dumps on some of our applications. Any help is appreciated. =3D=3D=3D Data below =3D=3D=3D ecrist@jaguar-1:~-> date Wed Oct 13 07:33:46 CDT 2010 ecrist@jaguar-1:~-> dmesg ecrist@jaguar-1:~-> uname -a FreeBSD jaguar-1.claimlynx.com 8.1-RC2 FreeBSD 8.1-RC2 #1: Wed Jul 14 = 11:34:02 CDT 2010 = root@jaguar-1.claimlynx.com:/usr/obj/usr/src/sys/GENERIC-CARP amd64 ecrist@jaguar-1:~-> uptime 7:33AM up 83 days, 8:42, 2 users, load averages: 1.08, 1.25, 0.94 ecrist@jaguar-1:~-> On the clients, however, many of them are reporting assorted problems. = The 7.1 system reports the following: ecrist@panther:~-> date Wed Oct 13 07:34:43 CDT 2010 ecrist@panther:~-> dmesg ... Can't start NLM - unable to contact NSM NLM: failed to contact remote rpcbind, stat =3D 5, port =3D 28416 NLM: failed to contact remote rpcbind, stat =3D 5, port =3D 28416 NLM: failed to contact remote rpcbind, stat =3D 5, port =3D 28416 nfs server jaguar.stor:/array/production: not responding nfs server jaguar.stor:/array/production: is alive again nfs server jaguar.stor:/array/production: not responding ... ecrist@panther:~-> uname -a FreeBSD panther.claimlynx.com 7.1-RELEASE-p3 FreeBSD 7.1-RELEASE-p3 #2: = Sun Mar 22 08:21:50 CDT 2009 = root@cougar.claimlynx.com:/usr/obj/usr/src/sys/SMP-ASR i386 ecrist@panther:~-> uptime 7:34AM up 30 days, 16:13, 4 users, load averages: 0.97, 1.00, 0.91 ecrist@panther:~->=20 Our 4.11 system: ecrist@puma:~-> date Wed Oct 13 07:38:09 CDT 2010 ecrist@puma:~-> dmesg got bad cookie vp 0xe93fd240 bp 0xcfa2d2ec got bad cookie vp 0xe859e740 bp 0xcfa96644 ... nfs server jaguar.stor:/array/production: not responding nfs server jaguar.stor:/array/production: is alive again nfs server jaguar.stor:/array/archive: not responding nfs server jaguar.stor:/array/archive: is alive again nfs server jaguar.stor:/array/archive: not responding nfs server jaguar.stor:/array/archive: is alive again nfs server jaguar.stor:/array/archive: not responding nfs server jaguar.stor:/array/production: not responding nfs server jaguar.stor:/array/archive: is alive again nfs server jaguar.stor:/array/production: is alive again nfs server jaguar.stor:/array/archive: not responding nfs server jaguar.stor:/array/archive: is alive again nfs server jaguar.stor:/array/production: not responding nfs server jaguar.stor:/array/production: is alive again nfs server jaguar.stor:/array/production: not responding ... ecrist@puma:~-> uname -a FreeBSD puma.claimlynx.com 4.11-RELEASE-p2 FreeBSD 4.11-RELEASE-p2 #1: = Wed Apr 13 18:25:25 CDT 2005 = drue@puma.claimlynx.com:/usr/obj/usr/src/sys/PUMA i386 ecrist@puma:~-> uptime 7:38AM up 30 days, 15:27, 1 user, load averages: 0.02, 0.02, 0.00 ecrist@puma:~->=20 And, finally, an 8.1 system: ecrist@puma-2:~-> date Wed Oct 13 07:39:27 CDT 2010 ecrist@puma-2:~-> dmesg ... NLM: failed to contact remote rpcbind, stat =3D 5, port =3D 28416 NLM: failed to contact remote rpcbind, stat =3D 5, port =3D 28416 ecrist@puma-2:~-> uname -a FreeBSD puma-2.claimlynx.com 8.1-RELEASE FreeBSD 8.1-RELEASE #2: Mon Aug = 2 12:50:40 CDT 2010 = root@jaguar-1.claimlynx.com:/usr/obj/usr/src/sys/GENERIC-CARP amd64 ecrist@puma-2:~-> uptime 7:39AM up 70 days, 18:25, 3 users, load averages: 0.00, 0.00, 0.00 ecrist@puma-2:~->= From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 13:43:38 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 8529B1065670; Wed, 13 Oct 2010 13:43:38 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by mx1.freebsd.org (Postfix) with ESMTP id 263488FC16; Wed, 13 Oct 2010 13:43:38 +0000 (UTC) Received: from labgw2.phaedrus.sandvine.com (192.168.222.22) by WTL-EXCH-1.sandvine.com (192.168.196.31) with Microsoft SMTP Server id 14.0.694.0; Wed, 13 Oct 2010 09:43:37 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 10332) id 6561E33C00; Wed, 13 Oct 2010 09:43:37 -0400 (EDT) Date: Wed, 13 Oct 2010 09:43:37 -0400 From: Ed Maste To: Attilio Rao Message-ID: <20101013134337.GA30028@sandvine.com> Mail-Followup-To: Ed Maste , Attilio Rao , Robert Watson , FreeBSD Current , freebsd-net@freebsd.org, Ryan Stone References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Ryan Stone , Robert Watson , FreeBSD Current Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:43:38 -0000 On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote: > 2010/10/9 Robert Watson : > > (1) Did you consider using tftp as the network dump protocol, rather than a > > custom protocol? ??It's also a simple UDP-based, ACKed file transfer > > protocol, with the advantage that it's widely supported by exiting tftp > > daemons, packet sniffers, security devices, etc. ??This wouldn't require > > using a stock tftpd, although that would certainly be a benefit as well. > > ??The post-processing of crashdumps that seems to happen in the netdump > > server could, presumably, happen "offline" as easily...? > > I don't understand the "offline" question but, really, I don't know > why tftp wasn't considered in the first place. > Let me do some small search and see how much we could benefit from it. I think Robert means having something other than the netdump server doing the post-processing - e.g., a cron job could look in the directory where a tftp server saved a core file and run a script to extract the desired information. TFTP has a number of advantages; I'm not sure if the original author of the netdump code considered it and rejected it for some reason. I think the original implementation used a broadcast packet to locate the server though, so a custom server was required in any case. That said, I don't think it matters too much if we go ahead with the current version and switch to TFTP later on. > > (2) Have you thought about adding a checksum to the dump format, since > > packets are going over the wire on UDP, etc? ??Even an MD5 sum wouldn't be > > too hard to arrange: all the code is in the kernel already, requires > > relatively little state storage, and is designed for streamed data. > > Someone else already brought this point and I agree, we could use a > checksum here. Both a whole dump and per-packet checksum could be valuable. If we want the former I think this should be done in the dump infrastructure, so that disk dumps get it too. The latter conflicts somewhat with a desire to switch to TFTP though (other than a standard UDP packet checksum). > > The sysctl parts of the patch have a number of issues: > > Sysctl are still not overhauled just because I'm not sure we want to > keep them. That is one of the points I raised in the main e-mail and > I'd really would like to hear opinions about if we should keep them > rather than having a setup userland process, etc. > I'm sorry about this, but please keep in mind that the file still > needs a lot of cleanup so some comments are a bit out of date and > other parts may not be still perfectly overhauled. Attilio suggested adding a userland tool to configure netdump in lieu of the current sysctls. I don't have a strong opinion either way; the only real advantage to the sysctl approach that I see is that the use of the mirrored loader tunables is more obvious. > > The idea of calling into the mbuf allocator in this context is just freaky, > > and may have some truly awful side effects. ??I suppose this is the cost of > > trying to combine code paths in the network device driver rather than have > > an independent path in the netdump case, but it's quite unfortunate and will > > significantly reduce the robustness of netdumps in the face of, for example, > > mbuf starvation. > > I'm not sure in which other way we could fix that actually. Maybe a > pre-allocated pool of mbufs? Despite the freakiness, I can only offer the observation that it has worked very well for us in practise. > > + ?? ?? ?? if (ntohs(ah->ar_hrd) != ARPHRD_ETHER && > > + ?? ?? ?? ?? ?? ntohs(ah->ar_hrd) != ARPHRD_IEEE802 && > > ... > > > > Are you sure you don't want to just check for ETHER here? > > I'd really like to hear Ryan's or Ed's idea here. Interesting, I can't find this in our local version. It looks like this check was copied from if_ether.c::arpintr(). > > + ?? ?? ?? /* XXX: Probably should check if we're the recipient MAC address */ > > + ?? ?? ?? /* Done ethernet processing. Strip off the ethernet header */ > > > > Yes, quite probably. ??What if you panic in promiscuous mode? Well, the packet would get dropped at the next layer up, in nd_handle_ip. -Ed From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 13:46: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 34906106566C for ; Wed, 13 Oct 2010 13:46:19 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id E57958FC08 for ; Wed, 13 Oct 2010 13:46:18 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1P61er-00042C-G7 for freebsd-current@freebsd.org; Wed, 13 Oct 2010 14:46:17 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1P61er-00031Z-CN for freebsd-current@freebsd.org; Wed, 13 Oct 2010 14:46:17 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o9DDkHuE066979 for ; Wed, 13 Oct 2010 14:46:17 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o9DDkHEh066978 for freebsd-current@freebsd.org; Wed, 13 Oct 2010 14:46:17 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 13 Oct 2010 14:46:17 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20101013134616.GA66891@mech-cluster241.men.bris.ac.uk> 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: 3 different ral(4) pcmcia card (same chip) give the same error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:46:19 -0000 Is damien@ still active in ral(4) development? I'm posting here in case he's not. many thanks anton ----- Forwarded message from Anton Shterenlikht ----- Date: Tue, 12 Oct 2010 12:07:35 +0100 From: Anton Shterenlikht To: damien@freebsd.org Subject: 3 different ral(4) pcmcia devices give the same error Hi Damien On amd64 r213648 I've 3 different ral(4) cards, all giving ral0: could not read from BBP ral0: timeout waiting for BBP According to ral(4) man page, all 3 cards should work. The full details are below. Please advise many thanks anton ###################################################################### Sitecom WL-112 MAC: 00:0C:F6:0F:EF:D5 SN: WL11244809326 ##################### ral0@pci0:3:0:0: class=0x028000 card=0x9070182d chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology, Corp.' device = 'Ralink Chipset 802.11b/g WLAN Card ( RT2560F)' class = network ral0: mem 0xb7fb4000-0xb7fb5fff irq 20 at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x00), RF RT2522 ral0: flags=8802 metric 0 mtu 2290 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier wlan0: flags=8802 metric 0 mtu 1500 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 bintval 0 ral0: could not read from BBP ral0: timeout waiting for BBP ###################################################################### MSI Micro-Star International CB54G2, 802.11 b/g compliant MAC: 00:11:09:E7:0A:F9 SN: MS-6835B0501095335 ##################### ral0@pci0:3:0:0: class=0x028000 card=0x68351462 chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology, Corp.' device = 'Ralink Chipset 802.11b/g WLAN Card ( RT2560F)' class = network ral0: mem 0xb7fb4000-0xb7fb5fff irq 20 at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x00), RF RT2522 ral0: flags=8802 metric 0 mtu 2290 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier wlan0: flags=8802 metric 0 mtu 1500 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 bintval 0 ral0: could not read from BBP ral0: timeout waiting for BBP ###################################################################### ASUS CB54G2, 802.11 b/g compliant MAC: 00:11:09:E7:0A:F9 SN: MS-6835B0501095335 ##################### ral0@pci0:3:0:0: class=0x028000 card=0x107f1043 chip=0x02011814 rev=0x01 hdr=0x00 vendor = 'Ralink Technology, Corp.' device = 'Ralink Chipset 802.11b/g WLAN Card ( RT2560F)' class = network ral0: mem 0xb7fb4000-0xb7fb5fff irq 20 at device 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x00), RF RT2522 ral0: flags=8802 metric 0 mtu 2290 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier wlan0: flags=8802 metric 0 mtu 1500 ether 00:00:00:00:00:00 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 bintval 0 ral0: could not read from BBP ral0: timeout waiting for BBP ----- End forwarded message ----- -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 13:53: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 33FDF106566C for ; Wed, 13 Oct 2010 13:53:54 +0000 (UTC) (envelope-from danilobaio@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC8DF8FC1A for ; Wed, 13 Oct 2010 13:53:53 +0000 (UTC) Received: by ywh2 with SMTP id 2so1759235ywh.13 for ; Wed, 13 Oct 2010 06:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uiJxWVjYWqDDrGTBTcwwXi/4FZGnbChAnlPogmmvJ4c=; b=Wps0Wlt2LFdHhcjA3DLBWtHm2CxGsSMjA5hzGrkUU4uSQRClBZWFJ8/4SNjl1kfiWH J3fFqMWcjS2MQy4TxqdSOMLpH0DKb5CyiRmcu5kIf3v1RZqn3kRytLN3Yk95mrPceuwJ uA6l6J9qJZvvTn6DeuDeBZ/d6ml6yZvsfX460= 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=rm53qDtzwbjeGmdEnxm4zDs8Q8oMQB8L6CFlwXpGLxmV1MRBmaChPn+TyL5Oyydn+B unnJqaoF/nnz4wzpGRUx18AyqrCdFOYKX54OJxXyr254f+Pg5B3qFoz89vWgSIbzM5GZ tKSBCwiGQZ47FFJ7NPsblJWZLFhVxWk2XXbpI= MIME-Version: 1.0 Received: by 10.150.11.11 with SMTP id 11mr1117090ybk.219.1286976545878; Wed, 13 Oct 2010 06:29:05 -0700 (PDT) Received: by 10.150.56.39 with HTTP; Wed, 13 Oct 2010 06:29:05 -0700 (PDT) In-Reply-To: References: <34E50FDC-C866-4E13-8391-55503B94EB8B@samsco.org> Date: Wed, 13 Oct 2010 10:29:05 -0300 Message-ID: From: Danilo Baio To: Ian FREISLICH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: mfi and Dell PERC 6/i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 13:53:54 -0000 On Wed, Aug 25, 2010 at 10:51 AM, Danilo Baio wrote: > > > On Wed, Aug 25, 2010 at 10:24 AM, Ian FREISLICH wrote: > >> Danilo Baio wrote: >> > > Scott Long wrote: >> > > The firmware on the controller crashed. The best I can suggest is t= o >> look >> > > for newer firmware (mfiutil can flash firmware) and to call LSI or >> Dell >> > > tech-support and report the problem. In the past, there have been >> bugs with >> > > patrol reads causing crashes under heavy load, so you might also loo= k >> at >> > > disabling that option. >> >> Dell will not be interested unless the adapter is running the most >> recent firmware. >> >> > Intersting, patrol read is automatic and before crash show on the logs >> that >> > patrol read has started. >> > >> > I disabled this feature, rebooted the server and didn't show that >> firmware >> > error... >> > >> > I will test for some days. >> >> Dell, (maybe) Scott and I recomend that you ensure you're on the >> latest firmware: >> >> [firewall2] ~ # mfiutil -u0 show adapter >> mfi0 Adapter: >> Product Name: PERC 6/i Adapter >> Serial Number: 1122334455667788 >> Firmware: 6.2.0-0013 >> RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 >> Battery Backup: present >> NVRAM: 32K >> Onboard Memory: 256M >> Minimum Stripe: 8K >> Maximum Stripe: 1M >> >> I'm sure there are bugs on this firmware too, but reading the fixes >> that were made between the version that came on the adapter and >> this version were Truely Frightening. >> >> It's trivial to update the firmware with the mfiutl program. >> >> Ian >> >> -- >> Ian Freislich >> > > > > Hi Ian, > > It=B4s already running the last one. > > bazinga# mfiutil -u0 show adapter > mfi0 Adapter: > Product Name: PERC 6/i Integrated > > Serial Number: 1122334455667788 > Firmware: 6.2.0-0013 > RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 > Battery Backup: present > NVRAM: 32K > Onboard Memory: 256M > Minimum Stripe: 8K > Maximum Stripe: 1M > > > bazinga# mfiutil -u0 show firmware > > mfi0 Firmware Package Version: 6.2.0-0013 > mfi0 Firmware Images: > Name Version Date Time Status > APP 1.22.02-0612 Mar 30 2009 14:41:22 active > BIOS 2.04.00 active > BCON 1.1-46-e_15-Rel Mar 2 2008 14:06:08 active > CTLR 1.02-015B Jan 27 2009 12:02:58 active > PCLI 01.00-023:#%00006 Nov 25 2008 17:21:50 active > BTBL 1.00.00.01-0011 Nov 27 2007 18:29:20 active > bazinga# > > > It is the last one that i've found on dell website: > http://ftp.us.dell.com/SAS-RAID/R216023.txt > > This is a firmware release for the Dell PERC 6/i Adapter. > > Component Current Version Previous Version > > Package 6.2.0-0013 6.1.1-0047 > Firmware 1.22.02-0612 1.21.02-0528 > Bootblock 1.00.00.01-0011 1.00.00.01-0011 > Ctrl-R 1.02.015B 1.02.014B > > Hi guys, Solved my problem. The support DELL replaced the battery and the problem persisted, so they replaced all the controller for a new one and solved the problem. Today this controller is running on a production/stress server with no problem, uptime 31 days. FreeBSD 8.1 Raid 1 (2 disks sata 500) and Raid 10 (four disks sas 15k) Thank you all. --=20 Danilo Gon=E7alves Baio (dbaio) danilobaio (*) gmail . com +55 (44) 8801 1257 From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 14:55: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 F3A79106564A for ; Wed, 13 Oct 2010 14:55:36 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9718FC19 for ; Wed, 13 Oct 2010 14:55:36 +0000 (UTC) Received: by ewy21 with SMTP id 21so951920ewy.13 for ; Wed, 13 Oct 2010 07:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=VYCCck2gL04regPPFqXD9JQVaRzgLR6bqDTc59SgxFg=; b=lIbIEikWkJCWsyEIdJL/EB/TOfS5YU9euSKRgmCoi75tqVKm9uK6FMjStfyuUPUc+A chjbKZffPaAwpWIocf5vLYfF4uLUdNxpPVKg1eplAKSzG4py62hoa1EesINGmfoKzLAX Rcfc/ikPSuKGB1UPKRemkuATiBEzcBXWQl4Zs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=mC05VKydb+O1dh3kC4tk1+MMJGPmLB16/Eq+t6lkCwfNEWYt8LlO/Na9seTvVSXk6F wI6AlIs9aZQy+UCG1Rq2USeM8t7iQOEWbmHFEqjAYxchyeTo4e8P0JncDK10v7TOvKRO jQJL9wIgMQAn7fmb6onPJL0dPXFvQqU7ThPB0= Received: by 10.213.19.19 with SMTP id y19mr2678313eba.65.1286980098230; Wed, 13 Oct 2010 07:28:18 -0700 (PDT) Received: from localhost ([77.74.36.78]) by mx.google.com with ESMTPS id z55sm15039092eeh.15.2010.10.13.07.28.09 (version=SSLv3 cipher=RC4-MD5); Wed, 13 Oct 2010 07:28:11 -0700 (PDT) Date: Wed, 13 Oct 2010 17:28:00 +0300 From: "Sergey V. Dyatko" To: Anton Shterenlikht Message-ID: <20101013172800.771ff241@gmail.com> In-Reply-To: <20101013134616.GA66891@mech-cluster241.men.bris.ac.uk> References: <20101013134616.GA66891@mech-cluster241.men.bris.ac.uk> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3 different ral(4) pcmcia card (same chip) give the same error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:55:37 -0000 On Wed, 13 Oct 2010 14:46:17 +0100 Anton Shterenlikht wrote: > Is damien@ still active in ral(4) development? > I'm posting here in case he's not. > > many thanks > anton > As far I know damien@ leave Project long time ago, not so far I ask him for RT3090 support. Hi didn't reply, even on !@freebsd.org email, but according to obsd commit logs hi still working on wifi -- wbr, tiger From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 15:13: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 0CF131065670; Wed, 13 Oct 2010 15:13:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id A543D8FC0A; Wed, 13 Oct 2010 15:13:54 +0000 (UTC) Received: by qwe4 with SMTP id 4so2839994qwe.13 for ; Wed, 13 Oct 2010 08:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=nvLZEEQ0MKmpOfAmxkfeh74LIMfsWlOqJn0VMw7BjPo=; b=qlkvMY0hGRTn+qBBiYmKixQP73eoerKq/9YrjxZUFhURAn6G245znYtlsl7rFY4Ua6 /qt5cZsd2AZep7Fsxf+Pyj2mhoBGGnUQpUDnCVAzttvsfVeYjbu7UqNkaU7/68sX3Cbg 55apaE7QC4YanJVbFphTmahc4B2q1Xa/EJUbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ej1gNF8pFSbja7jmMj6sZuSdeC2uPlsHjLQoJKOS/1iAwKCdTbIYyBgXAGCVlyfi/2 RCCG5c3v5DsQ0FvQU5rSrlu91UzHMs58xaSpoVlCBvACmOcXkAh88V3jE0NOg1zUnTdo +wSH8n2pZGUtpxU4fvd+0AIPrMDI8j+3iQ4H8= MIME-Version: 1.0 Received: by 10.229.215.76 with SMTP id hd12mr7698960qcb.44.1286982833525; Wed, 13 Oct 2010 08:13:53 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Wed, 13 Oct 2010 08:13:53 -0700 (PDT) Date: Wed, 13 Oct 2010 10:13:53 -0500 Message-ID: From: "Sam Fourman Jr." To: FreeBSD Current , Andriy Gapon , Martin Matuska Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:13:55 -0000 FNFS# uname -a FreeBSD FNFS.PuffyBSD.Com 9.0-CURRENT FreeBSD 9.0-CURRENT #23: Wed Oct 13 08:07:13 CDT 2010 root@FNFS.PuffyBSD.Com:/usr/obj/usr/src/sys/FNFS amd64 FNFS# running CURRENT as of - r213742 FNFS# top -PS last pid: 65634; load averages: 3.39, 2.81, 1.62 up 0+01:47:43 10:07:35 322 processes: 6 running, 295 sleeping, 21 waiting CPU 0: 74.8% user, 0.0% nice, 7.5% system, 0.0% interrupt, 17.7% idle CPU 1: 85.4% user, 0.0% nice, 4.3% system, 0.0% interrupt, 10.2% idle CPU 2: 83.1% user, 0.0% nice, 8.7% system, 0.0% interrupt, 8.3% idle CPU 3: 82.3% user, 0.0% nice, 4.7% system, 0.0% interrupt, 13.0% idle Mem: 145M Active, 17M Inact, 6101M Wired, 1352K Cache, 1402M Free Swap: 63G Total, 63G Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 4 171 ki31 0K 64K RUN 0 409:24 203.32% idle 0 root 164 -8 0 0K 2608K - 0 1:54 0.00% kernel 12 root 21 -60 - 0K 336K WAIT 0 0:15 0.00% intr 1081 root 4 44 0 10052K 1080K zfs 0 0:14 0.00% nfsd 7 root 1 76 - 0K 16K ccb_sc 2 0:05 0.00% xpt_thrd 4 root 1 -8 - 0K 16K - 2 0:02 0.00% g_down 3 root 1 -8 - 0K 16K - 1 0:02 0.00% g_up 18 root 1 44 - 0K 16K zio->i 1 0:02 0.00% syncer 5 root 6 -8 - 0K 128K tx->tx 0 0:01 0.00% zfskern 2485 root 1 44 0 42480K 4232K select 0 0:01 0.00% sshd 13 root 1 44 - 0K 16K - 0 0:01 0.00% yarrow 2425 70 1 44 0 53492K 5584K select 3 0:00 0.00% postgres 2419 70 1 44 0 60780K 5804K select 2 0:00 0.00% postgres 2426 70 1 44 0 53492K 5584K select 0 0:00 0.00% postgres 2420 70 1 44 0 60780K 5788K select 1 0:00 0.00% postgres 2 root 1 -8 - 0K 16K - 1 0:00 0.00% g_event 14 root 28 -64 - 0K 448K - 0 0:00 0.00% usb 1916 70 1 44 0 53492K 5484K select 0 0:00 0.00% postgres 1594 70 1 44 0 60780K 5736K select 2 0:00 0.00% postgres 65625 root 1 96 0 26484K 18328K CPU2 2 0:00 0.00% cc1 44389 root 1 44 0 7296K 852K select 3 0:00 0.00% make 44471 root 1 45 0 7296K 1348K select 3 0:00 0.00% make 2857 sfourman 1 44 0 42480K 4456K select 0 0:00 0.00% sshd 17 root 1 -16 - 0K 16K vlruwt 2 0:00 0.00% vnlru 2427 70 1 44 0 53492K 5564K select 0 0:00 0.00% postgres 2421 70 1 44 0 60780K 5812K select 2 0:00 0.00% postgres 1066 root 1 44 0 11280K 1924K select 1 0:00 0.00% mountd 2858 sfourman 1 44 0 25060K 3400K select 1 0:00 0.00% sftp-server 3065 pixi 1 46 0 8096K 3716K tx->tx 0 0:00 0.00% cvsup 1625 root 1 44 0 11976K 3356K select 0 0:00 0.00% sendmail 2257 root 1 44 0 11976K 2900K select 3 0:00 0.00% sendmail 1955 root 1 44 0 11976K 3096K select 0 0:00 0.00% sendmail 1257 root 1 44 0 16408K 3392K select 1 0:00 0.00% sendmail FNFS# procstat -k -k 1081 PID TID COMM TDNAME KSTACK 1081 100284 nfsd nfsd: master mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 svc_run_internal+0x6e9 svc_run+0x8f nfsrvd_nfsd+0x92 nfssvc_nfsd+0x9b nfssvc+0xb6 syscallenter+0x331 syscall+0x4b Xfast_syscall+0xe2 1081 100291 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe 1081 100292 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe 1081 100293 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 __lockmgr_args+0x7a3 vop_stdlock+0x39 VOP_LOCK1_APV+0x52 _vn_lock+0x47 zfs_fhtovp+0x30e nfsvno_fhtovp+0x4f nfsd_fhtovp+0xa6 nfsrvd_dorpc+0x9d0 nfssvc_program+0x447 svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe FNFS# -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 15:59:27 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 CC2101065675; Wed, 13 Oct 2010 15:59:27 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4C96F8FC2A; Wed, 13 Oct 2010 15:59:27 +0000 (UTC) Received: by qyk31 with SMTP id 31so574498qyk.13 for ; Wed, 13 Oct 2010 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=NsdvrGMEtsxv8/kw+aXRpbxoMMztHv5vKLX+upw7cHc=; b=P1ypk4VI8X9JRih3VBuCrEGyvVCy+mP9lpbycv6xDvaPHQrP4r5wlglqK8fLfxH3yf D4lRh+0L8ojyz+2taIt7ihzI0yZ0eUZnbYoEixibogpnNVR488wuSjjjWnlTXoHID6m/ XigEbB5yoGlLDxaDTWBZzNyEBEt+Gu8xioejA= 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=TRg9pa0qMJCZ4ZfGwmMVdPJFO1YY18tf1PJWFFvmjB0Ti//tWEhm/C0x+ijrFtB5Bm I/NlUN/tK4vbUFKyaLCcTGvZq1jRhu/6zk+2Uz3okjq2HuNCKbDHJoxdBN38lBoeMJsK 8v33zPbXWNbeYVtbossxCu0tTeZ3xtvnBvwJ8= MIME-Version: 1.0 Received: by 10.224.87.222 with SMTP id x30mr6774304qal.225.1286985566438; Wed, 13 Oct 2010 08:59:26 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Wed, 13 Oct 2010 08:59:26 -0700 (PDT) In-Reply-To: <4CB5D5E1.9080505@freebsd.org> References: <4CB5D5E1.9080505@freebsd.org> Date: Wed, 13 Oct 2010 10:59:26 -0500 Message-ID: From: "Sam Fourman Jr." To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:59:27 -0000 > procstat -kk -a | fgrep zil_commit > > -- > Andriy Gapon > I rebooted... Next time it locks up, I will run that.. it locks up pretty regular, should not be a few hours -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 16:08:11 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 402C21065679 for ; Wed, 13 Oct 2010 16:08:11 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 965D98FC20 for ; Wed, 13 Oct 2010 16:08:10 +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 SAA13866; Wed, 13 Oct 2010 18:53:06 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CB5D5E1.9080505@freebsd.org> Date: Wed, 13 Oct 2010 18:53:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 16:08:11 -0000 on 13/10/2010 18:13 Sam Fourman Jr. said the following: > > FNFS# uname -a > FreeBSD FNFS.PuffyBSD.Com 9.0-CURRENT FreeBSD > 9.0-CURRENT #23: Wed Oct 13 08:07:13 CDT 2010 > root@FNFS.PuffyBSD.Com:/usr/obj/usr/src/sys/FNFS amd64 > FNFS# > > > running CURRENT as of - r213742 > > FNFS# top -PS > > last pid: 65634; load averages: 3.39, 2.81, > 1.62 > up 0+01:47:43 10:07:35 > 322 processes: 6 running, 295 sleeping, 21 waiting > CPU 0: 74.8% user, 0.0% nice, 7.5% system, 0.0% interrupt, 17.7% idle > CPU 1: 85.4% user, 0.0% nice, 4.3% system, 0.0% interrupt, 10.2% idle > CPU 2: 83.1% user, 0.0% nice, 8.7% system, 0.0% interrupt, 8.3% idle > CPU 3: 82.3% user, 0.0% nice, 4.7% system, 0.0% interrupt, 13.0% idle > Mem: 145M Active, 17M Inact, 6101M Wired, 1352K Cache, 1402M Free > Swap: 63G Total, 63G Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 11 root 4 171 ki31 0K 64K RUN 0 409:24 203.32% idle > 0 root 164 -8 0 0K 2608K - 0 1:54 0.00% kernel > 12 root 21 -60 - 0K 336K WAIT 0 0:15 0.00% intr > 1081 root 4 44 0 10052K 1080K zfs 0 0:14 0.00% nfsd > 7 root 1 76 - 0K 16K ccb_sc 2 0:05 0.00% xpt_thrd > 4 root 1 -8 - 0K 16K - 2 0:02 0.00% g_down > 3 root 1 -8 - 0K 16K - 1 0:02 0.00% g_up > 18 root 1 44 - 0K 16K zio->i 1 0:02 0.00% syncer > 5 root 6 -8 - 0K 128K tx->tx 0 0:01 0.00% zfskern > 2485 root 1 44 0 42480K 4232K select 0 0:01 0.00% sshd > 13 root 1 44 - 0K 16K - 0 0:01 0.00% yarrow > 2425 70 1 44 0 53492K 5584K select 3 0:00 0.00% postgres > 2419 70 1 44 0 60780K 5804K select 2 0:00 0.00% postgres > 2426 70 1 44 0 53492K 5584K select 0 0:00 0.00% postgres > 2420 70 1 44 0 60780K 5788K select 1 0:00 0.00% postgres > 2 root 1 -8 - 0K 16K - 1 0:00 0.00% g_event > 14 root 28 -64 - 0K 448K - 0 0:00 0.00% usb > 1916 70 1 44 0 53492K 5484K select 0 0:00 0.00% postgres > 1594 70 1 44 0 60780K 5736K select 2 0:00 0.00% postgres > 65625 root 1 96 0 26484K 18328K CPU2 2 0:00 0.00% cc1 > 44389 root 1 44 0 7296K 852K select 3 0:00 0.00% make > 44471 root 1 45 0 7296K 1348K select 3 0:00 0.00% make > 2857 sfourman 1 44 0 42480K 4456K select 0 0:00 0.00% sshd > 17 root 1 -16 - 0K 16K vlruwt 2 0:00 0.00% vnlru > 2427 70 1 44 0 53492K 5564K select 0 0:00 0.00% postgres > 2421 70 1 44 0 60780K 5812K select 2 0:00 0.00% postgres > 1066 root 1 44 0 11280K 1924K select 1 0:00 0.00% mountd > 2858 sfourman 1 44 0 25060K 3400K select 1 0:00 0.00% sftp-server > 3065 pixi 1 46 0 8096K 3716K tx->tx 0 0:00 0.00% cvsup > 1625 root 1 44 0 11976K 3356K select 0 0:00 0.00% sendmail > 2257 root 1 44 0 11976K 2900K select 3 0:00 0.00% sendmail > 1955 root 1 44 0 11976K 3096K select 0 0:00 0.00% sendmail > 1257 root 1 44 0 16408K 3392K select 1 0:00 0.00% sendmail > FNFS# procstat -k -k 1081 > PID TID COMM TDNAME KSTACK > 1081 100284 nfsd nfsd: master mi_switch+0x176 sleepq_wait+0x42 > _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c > nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 > svc_run_internal+0x6e9 svc_run+0x8f nfsrvd_nfsd+0x92 nfssvc_nfsd+0x9b nfssvc+0xb6 > syscallenter+0x331 syscall+0x4b Xfast_syscall+0xe2 > 1081 100291 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 > _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c > nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 > svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe > 1081 100292 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 > _cv_wait+0x129 zil_commit+0x7a zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c > nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 > svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe > 1081 100293 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 > __lockmgr_args+0x7a3 vop_stdlock+0x39 VOP_LOCK1_APV+0x52 _vn_lock+0x47 > zfs_fhtovp+0x30e nfsvno_fhtovp+0x4f nfsd_fhtovp+0xa6 nfsrvd_dorpc+0x9d0 > nfssvc_program+0x447 svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b > fork_trampoline+0xe > FNFS# procstat -kk -a | fgrep zil_commit -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 16:09: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 BB67610656AA; Wed, 13 Oct 2010 16:09:34 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B9FCB8FC17; Wed, 13 Oct 2010 16:09:33 +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 TAA14055; Wed, 13 Oct 2010 19:09:31 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CB5D9BB.7070205@freebsd.org> Date: Wed, 13 Oct 2010 19:09:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4CB5D5E1.9080505@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 16:09:34 -0000 on 13/10/2010 18:59 Sam Fourman Jr. said the following: > > procstat -kk -a | fgrep zil_commit > > -- > Andriy Gapon > > > > I rebooted... Next time it locks up, I will run that.. it locks up pretty regular, > should not be a few hours You might want to save complete procstat -kk -a output and post a link to that. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 16:17:05 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 3A7F3106566B; Wed, 13 Oct 2010 16:17:05 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id AD85A8FC0A; Wed, 13 Oct 2010 16:17:04 +0000 (UTC) Received: by qyk31 with SMTP id 31so595285qyk.13 for ; Wed, 13 Oct 2010 09:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FKicepe+wvxI3A4aIHdOU84CyVMDyP3etc5XZShRXSY=; b=Wn7SFUfeJgYylw0zQldg+Mio0yqb6HB/bXTqvynLN1eObHIkHSTheYTzbS22AfAzmF Imnv4YcKqHZeE0dwA0zX/du5RBtJRb5a1NjnZG2otGo60jEeIHha+kR+JeJxyRhiq+Jm Ce6+y/sxTSIGcBefj4/I1sP7a7ybbsEzAa+fY= 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=Ws/7vNGOqfQe4FIHXJotzCllJAg8xUl+oMlk5i/u+MmEvCKRSnLqwD4ULTjXyTP1Nq P8xZuMORZ3u1hGoABW5aeX34fOPM9e7QINXFyG/hQ5nXdWnUtflXhPawCO+wdXJzBD0h IlZDR5hQhu13N+GKnHoqURac6w1F37A7oYcPA= MIME-Version: 1.0 Received: by 10.224.218.74 with SMTP id hp10mr7122227qab.41.1286986623898; Wed, 13 Oct 2010 09:17:03 -0700 (PDT) Received: by 10.229.227.131 with HTTP; Wed, 13 Oct 2010 09:17:03 -0700 (PDT) In-Reply-To: References: <4CB5D5E1.9080505@freebsd.org> Date: Wed, 13 Oct 2010 11:17:03 -0500 Message-ID: From: "Sam Fourman Jr." To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 16:17:05 -0000 On Wed, Oct 13, 2010 at 10:59 AM, Sam Fourman Jr. wrote: > > procstat -kk -a | fgrep zil_commit >> >> -- >> Andriy Gapon >> > > > > full procstat -kk -a http://www.puffybsd.com/fnfs.txt -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 16:46: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 62BBD106564A; Wed, 13 Oct 2010 16:46:20 +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 33E228FC12; Wed, 13 Oct 2010 16:46:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9DGkJVQ049257; Wed, 13 Oct 2010 12:46:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9DGkJZi049256; Wed, 13 Oct 2010 16:46:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 13 Oct 2010 16:46:19 GMT Message-Id: <201010131646.o9DGkJZi049256@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 sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 16:46:20 -0000 TB --- 2010-10-13 11:48:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-13 11:48:20 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-10-13 11:48:20 - cleaning the object tree TB --- 2010-10-13 11:50:44 - cvsupping the source tree TB --- 2010-10-13 11:50:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-10-13 11:55:28 - building world TB --- 2010-10-13 11:55:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-13 11:55:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-13 11:55:28 - TARGET=sparc64 TB --- 2010-10-13 11:55:28 - TARGET_ARCH=sparc64 TB --- 2010-10-13 11:55:28 - TZ=UTC TB --- 2010-10-13 11:55:28 - __MAKE_CONF=/dev/null TB --- 2010-10-13 11:55:28 - cd /src TB --- 2010-10-13 11:55:28 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 13 11:55:30 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 Wed Oct 13 16:41:25 UTC 2010 TB --- 2010-10-13 16:41:25 - generating LINT kernel config TB --- 2010-10-13 16:41:25 - cd /src/sys/sparc64/conf TB --- 2010-10-13 16:41:25 - /usr/bin/make -B LINT TB --- 2010-10-13 16:41:25 - building LINT kernel TB --- 2010-10-13 16:41:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-13 16:41:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-13 16:41:25 - TARGET=sparc64 TB --- 2010-10-13 16:41:25 - TARGET_ARCH=sparc64 TB --- 2010-10-13 16:41:25 - TZ=UTC TB --- 2010-10-13 16:41:25 - __MAKE_CONF=/dev/null TB --- 2010-10-13 16:41:25 - cd /src TB --- 2010-10-13 16:41:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 13 16:41:26 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 [...] cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_gram.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_macro_gram.c lex -t /src/sys/dev/aic7xxx/aicasm/aicasm_scan.l > aicasm_scan.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_scan.c cc1: warnings being treated as errors /src/sys/dev/aic7xxx/aicasm/aicasm_scan.l:840: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-13 16:46:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-13 16:46:19 - ERROR: failed to build lint kernel TB --- 2010-10-13 16:46:19 - 2970.16 user 9903.83 system 17878.85 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 17:46:59 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 96A19106564A; Wed, 13 Oct 2010 17:46:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7761B8FC14; Wed, 13 Oct 2010 17:46:57 +0000 (UTC) Received: by ewy21 with SMTP id 21so1150113ewy.13 for ; Wed, 13 Oct 2010 10:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cVl9GYqaUJV/6wjFPm3t4KlO0pGyRLXf0fnJfrWB8QU=; b=pbjYfqg8LFKmYI2unYAO/8WAzcvFU217eRVZtUyZs2SJv/KmLWOBnaBcy1htEClx6u iwrnjhQXZ2eSFB//pQUEn6Sgg7qOHhsK9rGw7Bh52KSUD0v+7syJ7rEX88xZBWyyRL/O 6O16VncF9MrQ3fQC5iH/esNH+t4IQTCbdE/H0= 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=uXY70TAS9Te13E/4zRMWkiC82CF9vkDz5awIvSTc3KsX2p6u6vYhifG0yb+6q3wIZ5 E6JNWtrs17RMuyNpGBkKl+1wlAwZ6KsSWxd1tHppGma1Sbkqbux377qJ5vhwoha1EbW2 Sp20bzZtJ5GdX536BDLIHYiQghRuB45zKKJPs= MIME-Version: 1.0 Received: by 10.213.27.135 with SMTP id i7mr902554ebc.29.1286992016979; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) Received: by 10.213.105.208 with HTTP; Wed, 13 Oct 2010 10:46:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Oct 2010 13:46:56 -0400 Message-ID: From: Ryan Stone To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 17:46:59 -0000 On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote: > + /* > + * get and fill a header mbuf, then chain data as an > extended > + * mbuf. > + */ > + MGETHDR(m, M_DONTWAIT, MT_DATA); > > The idea of calling into the mbuf allocator in this context is just freaky, > and may have some truly awful side effects. I suppose this is the cost of > trying to combine code paths in the network device driver rather than have > an independent path in the netdump case, but it's quite unfortunate and will > significantly reduce the robustness of netdumps in the face of, for example, > mbuf starvation. Changing this will require very invasive changes to the network drivers. I know that the Intel drivers allocate their own mbufs for their receive rings and I imagine that all other drivers have to do something similar. Plus the drivers are responsible for freeing mbufs after they have been transmitted. It seems to me that the cost of making significant changes to the network drivers to support an alternate lifecycle for netdump mbufs far outweighs the cost of losing a couple of kernel dumps in extreme circumstances. From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 18:26: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 87C2A1065670; Wed, 13 Oct 2010 18:26:04 +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 5133A8FC13; Wed, 13 Oct 2010 18:26:04 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9DIQ33c006742; Wed, 13 Oct 2010 14:26:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9DIQ3n3006741; Wed, 13 Oct 2010 18:26:03 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 13 Oct 2010 18:26:03 GMT Message-Id: <201010131826.o9DIQ3n3006741@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 sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 18:26:04 -0000 TB --- 2010-10-13 13:47:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-13 13:47:40 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-10-13 13:47:40 - cleaning the object tree TB --- 2010-10-13 13:49:43 - cvsupping the source tree TB --- 2010-10-13 13:49:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-10-13 13:54:52 - building world TB --- 2010-10-13 13:54:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-13 13:54:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-13 13:54:52 - TARGET=sun4v TB --- 2010-10-13 13:54:52 - TARGET_ARCH=sparc64 TB --- 2010-10-13 13:54:52 - TZ=UTC TB --- 2010-10-13 13:54:52 - __MAKE_CONF=/dev/null TB --- 2010-10-13 13:54:52 - cd /src TB --- 2010-10-13 13:54:52 - /usr/bin/make -B buildworld >>> World build started on Wed Oct 13 13:54:53 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 Wed Oct 13 18:22:38 UTC 2010 TB --- 2010-10-13 18:22:38 - generating LINT kernel config TB --- 2010-10-13 18:22:38 - cd /src/sys/sun4v/conf TB --- 2010-10-13 18:22:38 - /usr/bin/make -B LINT TB --- 2010-10-13 18:22:38 - building LINT kernel TB --- 2010-10-13 18:22:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-13 18:22:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-13 18:22:38 - TARGET=sun4v TB --- 2010-10-13 18:22:38 - TARGET_ARCH=sparc64 TB --- 2010-10-13 18:22:38 - TZ=UTC TB --- 2010-10-13 18:22:38 - __MAKE_CONF=/dev/null TB --- 2010-10-13 18:22:38 - cd /src TB --- 2010-10-13 18:22:38 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 13 18:22:39 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 [...] cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_gram.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_macro_gram.c lex -t /src/sys/dev/aic7xxx/aicasm/aicasm_scan.l > aicasm_scan.c cc -O2 -pipe -nostdinc -I/usr/include -I. -I/src/sys/dev/aic7xxx/aicasm -std=gnu99 -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 -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_scan.c cc1: warnings being treated as errors /src/sys/dev/aic7xxx/aicasm/aicasm_scan.l:840: warning: function declaration isn't a prototype *** Error code 1 Stop in /obj/sun4v.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-13 18:26:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-13 18:26:03 - ERROR: failed to build lint kernel TB --- 2010-10-13 18:26:03 - 2941.75 user 10157.16 system 16703.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 18:43:17 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 8A49A106564A; Wed, 13 Oct 2010 18:43:17 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 558C78FC15; Wed, 13 Oct 2010 18:43:15 +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 VAA16489; Wed, 13 Oct 2010 21:43:13 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CB5FDC0.6000701@freebsd.org> Date: Wed, 13 Oct 2010 21:43:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4CB5D5E1.9080505@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 18:43:17 -0000 on 13/10/2010 19:17 Sam Fourman Jr. said the following: > full procstat -kk -a > > http://www.puffybsd.com/fnfs.txt It seems that thread 100281 is stuck waiting on zio and other threads are waiting on it (because it set zilog->zl_writer and hasn't unset it) or other stuck threads in chain: 1081 100281 nfsd nfsd: service mi_switch+0x176 sleepq_wait+0x42 _cv_wait+0x129 zio_wait+0x61 zil_commit+0x3df zfs_freebsd_fsync+0xd6 VOP_FSYNC_APV+0x6c nfsvno_fsync+0xb7 nfsrvd_commit+0xe3 nfsrvd_dorpc+0x39d nfssvc_program+0x447 svc_run_internal+0x6e9 svc_thread_start+0xb fork_exit+0x11b fork_trampoline+0xe Here's the zio that the thread waits on: (kgdb) p *zio $2 = {io_bookmark = {zb_objset = 0, zb_object = 0, zb_level = 0, zb_blkid = 0}, io_prop = {zp_checksum = ZIO_CHECKSUM_INHERIT, zp_compress = ZIO_COMPRESS_INHERIT, zp_type = DMU_OT_NONE, zp_level = 0 '\0', zp_ndvas = 0 '\0'}, io_type = ZIO_TYPE_NULL, io_child_type = ZIO_CHILD_LOGICAL, io_cmd = 0, io_priority = 0 '\0', io_reexecute = 0 '\0', io_state = "\001", io_txg = 0, io_spa = 0xffffff00056c6000, io_bp = 0x0, io_bp_copy = {blk_dva = {{dva_word = {0, 0}}, {dva_word = {0, 0}}, {dva_word = {0, 0}}}, blk_prop = 0, blk_pad = {0, 0, 0}, blk_birth = 0, blk_fill = 0, blk_cksum = {zc_word = {0, 0, 0, 0}}}, io_parent_list = {list_size = 48, list_offset = 16, list_head = {list_next = 0xffffff00081aa0e8, list_prev = 0xffffff00081aa0e8}}, io_child_list = { list_size = 48, list_offset = 32, list_head = {list_next = 0xffffff0005fdc080, list_prev = 0xffffff00082d84a0}}, io_walk_link = 0x0, io_logical = 0x0, io_transform_stack = 0x0, io_ready = 0, io_done = 0, io_private = 0x0, io_bp_orig = {blk_dva = {{dva_word = {0, 0}}, {dva_word = {0, 0}}, {dva_word = {0, 0}}}, blk_prop = 0, blk_pad = {0, 0, 0}, blk_birth = 0, blk_fill = 0, blk_cksum = { zc_word = {0, 0, 0, 0}}}, io_data = 0x0, io_size = 0, io_vd = 0x0, io_vsd = 0x0, io_vsd_free = 0, io_offset = 0, io_deadline = 0, io_offset_node = {avl_child = {0x0, 0x0}, avl_pcb = 0}, io_deadline_node = {avl_child = {0x0, 0x0}, avl_pcb = 0}, io_vdev_tree = 0x0, io_flags = 1, io_stage = ZIO_STAGE_CHECKSUM_VERIFY, io_pipeline = 33792, io_orig_flags = 1, io_orig_stage = ZIO_STAGE_OPEN, io_orig_pipeline = 33792, io_error = 0, io_child_error = {0, 0, 0}, io_children = {{0, 0}, {0, 0}, {0, 31}}, io_stall = 0xffffff00081aa288, io_gang_leader = 0x0, io_gang_tree = 0x0, io_executor = 0xffffff006b2d7450, io_waiter = 0xffffff006b2d7450, io_lock = {lock_object = {lo_name = 0xffffffff80c29a8b "zio->io_lock", lo_flags = 40960000, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, io_cv = {cv_description = 0xffffffff80c29a9a "zio->io_cv)", cv_waiters = 1}, io_ena = 0, io_task = {ost_task = {ta_running = 0x0, ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0, ta_context = 0x0}, ost_func = 0, ost_arg = 0x0, ost_magic = 0}} As you can see io_executor is not NULL and: (kgdb) p *(struct thread*)zio->io_executor $6 = {td_lock = 0xffffffff808eb2b8, td_proc = 0xffffff006b50c000, td_plist = {tqe_next = 0xffffff006b2d78a0, tqe_prev = 0xffffff006b2d7010}, td_runq = {tqe_next = 0x0, tqe_prev = 0xffffffff808d1308}, td_slpq = {tqe_next = 0x0, tqe_prev = 0xffffff000876a200}, td_lockq = {tqe_next = 0x0, tqe_prev = 0xffffff8233ffca40}, td_hash = {le_next = 0x0, le_prev = 0xffffff800022bdc8}, td_cpuset = 0xffffff00022cbdc8, td_sel = 0x0, td_sleepqueue = 0x0, td_turnstile = 0xffffff006b035c00, td_umtxq = 0xffffff006b2cf700, td_tid = 100281, td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xffffff006b2d7500}, sq_proc = 0xffffff006b50c000, sq_flags = 1}, td_flags = 524292, td_inhibitors = 2, td_pflags = 2097152, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0xffffff00081aa2d8, td_wmesg = 0xffffffff80c29a9a "zio->io_cv)", td_lastcpu = 1 '\001', td_oncpu = 255 '�', td_owepreempt = 0 '\0', td_tsqueue = 0 '\0', td_locks = -15929, td_rw_rlocks = 0, td_lk_slocks = 0, td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_ucred = 0xffffff00022cda00, td_estcpu = 0, td_slptick = 1335552, td_blktick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 1016, ru_ixrss = 9024, ru_idrss = 1723584, ru_isrss = 72192, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 59877, ru_msgrcv = 478009, ru_nsignals = 0, ru_nvcsw = 531964, ru_nivcsw = 939}, td_rux = {rux_runtime = 14928141752, rux_uticks = 0, rux_sticks = 564, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, td_incruntime = 0, td_runtime = 14928141752, td_pticks = 564, td_sticks = 0, td_iticks = 0, td_uticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 532903, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_name = "nfsd: service\000\000\000\000\000\000", td_fpop = 0x0, td_dbgflags = 0, td_dbgksi = {ksi_link = {tqe_next = 0x0, tqe_prev = 0x0}, ksi_info = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = {__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags = 0, ksi_sigq = 0x0}, td_ng_outbound = 0, td_osd = { osd_nslots = 1, osd_slots = 0xffffff0005e888a0, osd_next = {le_next = 0xffffff006b2d7bc0, le_prev = 0xffffffff808c9850}}, td_map_def_user = 0x0, td_rqindex = 32 ' ', td_base_pri = 160 '�', td_priority = 128 '\200', td_pri_class = 3 '\003', td_user_pri = 128 '\200', td_base_user_pri = 128 '\200', td_pcb = 0xffffff8234001d00, td_state = TDS_INHIBITED, td_retval = {0, 0}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xffffff80002ac7e0}}, c_time = 1340542, c_arg = 0xffffff006b2d7450, c_func = 0xffffffff803dcdd0 , c_lock = 0x0, c_flags = 16, c_cpu = 1}, td_frame = 0xffffff8234001c40, td_kstack_obj = 0xffffff006b3d4288, td_kstack = 18446743533416079360, td_kstack_pages = 4, td_critnest = 1, td_md = {md_spinlock_count = 1, md_saved_flags = 582}, td_sched = 0xffffff006b2d7870, td_ar = 0x0, td_lprof = {{lh_first = 0x0}, {lh_first = 0x0}}, td_dtrace = 0xffffff000869a300, td_errno = 0, td_vnet = 0x0, td_vnet_lpush = 0x0, td_intr_frame = 0x0} It's the same thread td_tid = 100281 - quite expected. So, zio is in this stage and state: p zio->io_stage $7 = ZIO_STAGE_CHECKSUM_VERIFY (kgdb) p zio->io_stall $9 = (uint64_t *) 0xffffff00081aa288 (kgdb) p *zio->io_stall $10 = 31 (kgdb) p zio->io_children $11 = {{0, 0}, {0, 0}, {0, 31}} (kgdb) p zio->io_child_type $12 = ZIO_CHILD_LOGICAL Further walking child zio hierarchy we reach the one that looks like this: $59 = {io_bookmark = {zb_objset = 400, zb_object = 0, zb_level = -1, zb_blkid = 22437}, io_prop = {zp_checksum = ZIO_CHECKSUM_INHERIT, zp_compress = ZIO_COMPRESS_INHERIT, zp_type = DMU_OT_NONE, zp_level = 0 '\0', zp_ndvas = 0 '\0'}, io_type = ZIO_TYPE_WRITE, io_child_type = ZIO_CHILD_VDEV, io_cmd = 0, io_priority = 0 '\0', io_reexecute = 0 '\0', io_state = "\001", io_txg = 0, io_spa = 0xffffff00056c6000, io_bp = 0xffffff01acdbaa30, io_bp_copy = {blk_dva = {{dva_word = {12884902144, 1678614837}}, {dva_word = {0, 0}}, {dva_word = {0, 0}}}, blk_prop = 9225910817809957119, blk_pad = {0, 0, 0}, blk_birth = 236695, blk_fill = 0, blk_cksum = {zc_word = {15569186404091016741, 3408946246337318984, 400, 22437}}}, io_parent_list = {list_size = 48, list_offset = 16, list_head = {list_next = 0xffffff000826b7c0, list_prev = 0xffffff000826b7c0}}, io_child_list = {list_size = 48, list_offset = 32, list_head = {list_next = 0xffffff00080aca98, list_prev = 0xffffff00080aca98}}, io_walk_link = 0x0, io_logical = 0xffffff0008b8d660, io_transform_stack = 0x0, io_ready = 0, io_done = 0xffffffff80b99ab0 , io_private = 0xffffff00b5f469a8, io_bp_orig = {blk_dva = {{dva_word = {12884902144, 1678614837}}, {dva_word = {0, 0}}, {dva_word = {0, 0}}}, blk_prop = 9225910817809957119, blk_pad = {0, 0, 0}, blk_birth = 236695, blk_fill = 0, blk_cksum = {zc_word = {15569186404091016741, 3408946246337318984, 400, 22437}}}, io_data = 0xffffff80e6565000, io_size = 131072, io_vd = 0xffffff00084cd000, io_vsd = 0x0, io_vsd_free = 0, io_offset = 859454990848, io_deadline = 20883, io_offset_node = {avl_child = {0x0, 0x0}, avl_pcb = 18446742974333891893}, io_deadline_node = {avl_child = {0x0, 0x0}, avl_pcb = 1}, io_vdev_tree = 0xffffff00084cd578, io_flags = 179, io_stage = ZIO_STAGE_VDEV_IO_START, io_pipeline = 47104, io_orig_flags = 131, io_orig_stage = ZIO_STAGE_READY, io_orig_pipeline = 47104, io_error = 0, io_child_error = {0, 0, 0}, io_children = {{0, 0}, {0, 0}, {0, 0}}, io_stall = 0x0, io_gang_leader = 0x0, io_gang_tree = 0x0, io_executor = 0xffffff000875a8a0, io_waiter = 0x0, io_lock = {lock_object = {lo_name = 0xffffffff80c29a8b "zio->io_lock", lo_flags = 40960000, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, io_cv = {cv_description = 0xffffffff80c29a9a "zio->io_cv)", cv_waiters = 0}, io_ena = 0, io_task = {ost_task = {ta_running = 0x0, ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0, ta_context = 0x0}, ost_func = 0, ost_arg = 0x0, ost_magic = 0}} Its executor: (kgdb) p *(struct thread *)$59->io_executor $61 = {td_lock = 0xffffffff808eb038, td_proc = 0xffffffff808c67a0, td_plist = {tqe_next = 0xffffff000875d000, tqe_prev = 0xffffff000875a460}, td_runq = {tqe_next = 0x0, tqe_prev = 0xffffffff808d0598}, td_slpq = {tqe_next = 0xffffff000875d000, tqe_prev = 0xffffff000875a480}, td_lockq = {tqe_next = 0x0, tqe_prev = 0xffffff8000074af0}, td_hash = {le_next = 0x0, le_prev = 0xffffff800022ba40}, td_cpuset = 0xffffff00022cbdc8, td_sel = 0x0, td_sleepqueue = 0x0, td_turnstile = 0xffffff000875c180, td_umtxq = 0xffffff000876f180, td_tid = 100168, td_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xffffff000875a950}, sq_proc = 0xffffffff808c67a0, sq_flags = 1}, td_flags = 524292, td_inhibitors = 2, td_pflags = 2097152, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0xffffff0005e91280, td_wmesg = 0xffffffff8068e670 "-", td_lastcpu = 0 '\0', td_oncpu = 255 '�', td_owepreempt = 0 '\0', td_tsqueue = 0 '\0', td_locks = 391, td_rw_rlocks = 0, td_lk_slocks = 0, td_blocked = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_ucred = 0xffffff00022ce000, td_estcpu = 0, td_slptick = 1335656, td_blktick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 9402, ru_nivcsw = 34}, td_rux = {rux_runtime = 630351495, rux_uticks = 0, rux_sticks = 19, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, td_incruntime = 0, td_runtime = 630351495, td_pticks = 19, td_sticks = 0, td_iticks = 0, td_uticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 9436, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_name = "zio_write_intr_high", td_fpop = 0x0, td_dbgflags = 0, td_dbgksi = {ksi_link = {tqe_next = 0x0, tqe_prev = 0x0}, ksi_info = {si_signo = 0, si_errno = 0, si_code = 0, si_pid = 0, si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, sival_ptr = 0x0, sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, _timer = {_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, __spare__ = { __spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags = 0, ksi_sigq = 0x0}, td_ng_outbound = 0, td_osd = {osd_nslots = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, td_map_def_user = 0x0, td_rqindex = 17 '\021', td_base_pri = 68 'D', td_priority = 68 'D', td_pri_class = 3 '\003', td_user_pri = 128 '\200', td_base_user_pri = 128 '\200', td_pcb = 0xffffff8233dc8d00, td_state = TDS_INHIBITED, td_retval = {0, 0}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, td_frame = 0xffffff8233dc8c40, td_kstack_obj = 0xffffff0008733360, td_kstack = 18446743533413748736, td_kstack_pages = 4, td_critnest = 1, td_md = {md_spinlock_count = 1, md_saved_flags = 582}, td_sched = 0xffffff000875acc0, td_ar = 0x0, td_lprof = {{lh_first = 0x0}, {lh_first = 0x0}}, td_dtrace = 0xffffff00086d2300, td_errno = 0, td_vnet = 0x0, td_vnet_lpush = 0x0, td_intr_frame = 0x0} This thread is: procstat -kk -a | fgrep 100168 0 100168 kernel zio_write_intr_h mi_switch+0x176 sleepq_wait+0x42 _sleep+0x317 taskqueue_thread_loop+0xdc fork_exit+0x11b fork_trampoline+0xe So, the last executor of the zio is zio_write_intr_high taskqueue thread. That's where i got stuck. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 21:42: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 3D1941065697; Wed, 13 Oct 2010 21:42:50 +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 045CC8FC2C; Wed, 13 Oct 2010 21:42:50 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 425331DD67F; Wed, 13 Oct 2010 23:42:48 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 2B45017312; Wed, 13 Oct 2010 23:42:48 +0200 (CEST) Date: Wed, 13 Oct 2010 23:42:48 +0200 From: Jilles Tjoelker To: obrien@freebsd.org, freebsd-current@freebsd.org Message-ID: <20101013214247.GA36354@stack.nl> References: <20101012021914.GA72371@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101012021914.GA72371@dragon.NUXI.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: [PATCH] fix shell bug in ${var%pattern} expansion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 21:42:50 -0000 On Mon, Oct 11, 2010 at 07:19:14PM -0700, David O'Brien wrote: > At $WORK we hit a bug where ${var%/*} was not producing the correct > expansion. There are two patches to fix this. I prefer the first > as I feel it is cleaner from an API perspective. I've also added > a regression testcase that shows the problem. > Thoughts? Thank you, I think this is the mysterious bug I encountered a while ago while making changes to arithmetic expansion, heavily using the stack string. It only failed when /etc/rc.d/nfsserver was called from /etc/rc on boot. Your patch looks good (the first one) and works for me. The second patch indeed seems a hack rather than fixing the problem properly. Style bug: > +growstrstackblock(int n) { The opening brace should be on its own line. Your test is too fragile: it often fails to detect the bug. Calling like sh -c '. expansion/trim4.0' gives the correct output even with a buggy sh. I propose something like this, or perhaps with an additional string comparison: # $FreeBSD$ v1=/homes/SOME_USER v2= v3=C123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 while [ ${#v2} -lt 2000 ]; do v4="${v2} ${v1%/*} $v3" if [ ${#v4} -ne $((${#v2} + ${#v3} + 8)) ]; then echo bad: ${#v4} -ne $((${#v2} + ${#v3} + 8)) fi v2=x$v2 v3=y$v3 done -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Wed Oct 13 23:24: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 12FE7106564A for ; Wed, 13 Oct 2010 23:24:12 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id E6FA38FC13 for ; Wed, 13 Oct 2010 23:24:11 +0000 (UTC) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.4/8.14.4) with ESMTP id o9DNOBWH018493; Wed, 13 Oct 2010 16:24:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.4/8.14.4/Submit) id o9DNOBqq018492; Wed, 13 Oct 2010 16:24:11 -0700 (PDT) (envelope-from obrien) Date: Wed, 13 Oct 2010 16:24:11 -0700 From: "David O'Brien" To: Jilles Tjoelker Message-ID: <20101013232411.GC17164@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Jilles Tjoelker , freebsd-current@freebsd.org References: <20101012021914.GA72371@dragon.NUXI.org> <20101013214247.GA36354@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101013214247.GA36354@stack.nl> X-Operating-System: FreeBSD 9.0-CURRENT X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] fix shell bug in ${var%pattern} expansion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 23:24:12 -0000 On Wed, Oct 13, 2010 at 11:42:48PM +0200, Jilles Tjoelker wrote: > Style bug: > > +growstrstackblock(int n) { > The opening brace should be on its own line. Indeed. I'm surprised I did that. Thank you for catching it. > Your test is too fragile: it often fails to detect the bug. Calling like > sh -c '. expansion/trim4.0' > gives the correct output even with a buggy sh. I propose something like > this, or perhaps with an additional string comparison: I also like this test better. Thank you for the review. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 08: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 6F8011065673; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 402018FC1C; Thu, 14 Oct 2010 08:01:34 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 368C646B2E; Thu, 14 Oct 2010 04:01:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 09:01:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Stone X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:01:34 -0000 On 13 Oct 2010, at 18:46, Ryan Stone wrote: > On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson = wrote: >> + /* >> + * get and fill a header mbuf, then chain data as an >> extended >> + * mbuf. >> + */ >> + MGETHDR(m, M_DONTWAIT, MT_DATA); >>=20 >> The idea of calling into the mbuf allocator in this context is just = freaky, >> and may have some truly awful side effects. I suppose this is the = cost of >> trying to combine code paths in the network device driver rather than = have >> an independent path in the netdump case, but it's quite unfortunate = and will >> significantly reduce the robustness of netdumps in the face of, for = example, >> mbuf starvation. >=20 > Changing this will require very invasive changes to the network > drivers. I know that the Intel drivers allocate their own mbufs for > their receive rings and I imagine that all other drivers have to do > something similar. Plus the drivers are responsible for freeing mbufs > after they have been transmitted. It seems to me that the cost of > making significant changes to the network drivers to support an > alternate lifecycle for netdump mbufs far outweighs the cost of losing > a couple of kernel dumps in extreme circumstances. My concern is less about occasional lost dumps that destabilising the = dumping process: calls into the memory allocator can currently trigger a = lot of interesting behaviours, such as further calls back into the VM = system, which can then trigger calls into other subsystems. What I'm = suggesting is that if we want the mbuf allocator to be useful in this = context, we need to teach it about things not to do in the dumping / = crash / ... context, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. Robert= From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 14:10:42 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 23768106564A; Thu, 14 Oct 2010 14:10:42 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 5FDC08FC1D; Thu, 14 Oct 2010 14:10:41 +0000 (UTC) Received: by qyk31 with SMTP id 31so51371qyk.13 for ; Thu, 14 Oct 2010 07:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VdrfBunv2f7NPCMKPfpABT+EG3J7PPEg7UNCTulp8Ok=; b=D2qKjp2jK2BNzg9HLFqHb/wjsobhlPkrFIIE1lIRamyi/As/ZtN1qoGA5yMOMSWOEi jljDNcdOgBJk8Ip8VDO79EUGILRWAp0Wu1pexZlF8bxu0Ct5nKcaItA/4WNdKxAMtP3l MoMvZ7Vt3em2vI/PAbUm0x3CZFhgiiy77uEnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vEnv7Dz1Vr0+hEOBSCvBOwE8MoaajplkKQS0ravA623OD/+QqOzfKUyoYnSb1KEwua mF5a+nCJ7DJ1ASG0zhrnCT7rLbB1sh3mErExAbb6H3ZMQFq/Ef/kvpMGcVbh2k1cR6FN WJZTJncob71IbUbG8PUrCqJtoZ8bUBjqINB3c= MIME-Version: 1.0 Received: by 10.224.76.78 with SMTP id b14mr7891677qak.75.1287065440468; Thu, 14 Oct 2010 07:10:40 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 07:10:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Oct 2010 16:10:26 +0200 X-Google-Sender-Auth: vsnm9Bpqhonyk5rLnsHoFrpYpkU Message-ID: From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:10:42 -0000 2010/10/14 Robert N. M. Watson : > > On 13 Oct 2010, at 18:46, Ryan Stone wrote: > >> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrot= e: >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* get and fill= a header mbuf, then chain data as an >>> extended >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* mbuf. >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MGETHDR(m, M_DONTWAI= T, MT_DATA); >>> >>> The idea of calling into the mbuf allocator in this context is just fre= aky, >>> and may have some truly awful side effects. =C2=A0I suppose this is the= cost of >>> trying to combine code paths in the network device driver rather than h= ave >>> an independent path in the netdump case, but it's quite unfortunate and= will >>> significantly reduce the robustness of netdumps in the face of, for exa= mple, >>> mbuf starvation. >> >> Changing this will require very invasive changes to the network >> drivers. =C2=A0I know that the Intel drivers allocate their own mbufs fo= r >> their receive rings and I imagine that all other drivers have to do >> something similar. =C2=A0Plus the drivers are responsible for freeing mb= ufs >> after they have been transmitted. =C2=A0It seems to me that the cost of >> making significant changes to the network drivers to support an >> alternate lifecycle for netdump mbufs far outweighs the cost of losing >> a couple of kernel dumps in extreme circumstances. > > My concern is less about occasional lost dumps that destabilising the dum= ping process: calls into the memory allocator can currently trigger a lot o= f interesting behaviours, such as further calls back into the VM system, wh= ich can then trigger calls into other subsystems. What I'm suggesting is th= at if we want the mbuf allocator to be useful in this context, we need to t= each it about things not to do in the dumping / crash / ... context, which = probably means helping uma out a bit in that regard. And a watchdog to make= sure the dump is making progress. I think that this would be way too complicated just to cope with panic within the VM/UMA (not sure what other subsystems you are referring to, wrt supposed to call). Besides, if we have a panic in the VM I'm sure that normal dumps could also be affected. When dealing with netdump, I'm not trying to fix all the bugs related to our dumping infrastructure because, as long as we already discussed, we know there are quite a few of them, but trying at least to follow the same fragile-ness than what we have today. And again, while I think the "watchdog" idea is good, I think it still applies to normal dumps too, it is not specific to netdump. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 14:23:37 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 57F781065793; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 261C58FC18; Thu, 14 Oct 2010 14:23:37 +0000 (UTC) Received: from [192.168.33.146] (lapwing-gw-1.csx.cam.ac.uk [131.111.1.66]) by cyrus.watson.org (Postfix) with ESMTPSA id AA26846B8F; Thu, 14 Oct 2010 10:23:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 14 Oct 2010 15:23:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: To: Attilio Rao X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 14:23:37 -0000 On 14 Oct 2010, at 15:10, Attilio Rao wrote: >> My concern is less about occasional lost dumps that destabilising the = dumping process: calls into the memory allocator can currently trigger a = lot of interesting behaviours, such as further calls back into the VM = system, which can then trigger calls into other subsystems. What I'm = suggesting is that if we want the mbuf allocator to be useful in this = context, we need to teach it about things not to do in the dumping / = crash / ... context, which probably means helping uma out a bit in that = regard. And a watchdog to make sure the dump is making progress. >=20 > I think that this would be way too complicated just to cope with panic > within the VM/UMA (not sure what other subsystems you are referring > to, wrt supposed to call). Besides, if we have a panic in the VM I'm > sure that normal dumps could also be affected. > When dealing with netdump, I'm not trying to fix all the bugs related > to our dumping infrastructure because, as long as we already > discussed, we know there are quite a few of them, but trying at least > to follow the same fragile-ness than what we have today. > And again, while I think the "watchdog" idea is good, I think it still > applies to normal dumps too, it is not specific to netdump. No, what I'm saying is: UMA needs to not call its drain handlers, and = ideally not call into VM to fill slabs, from the dumping context. That's = easy to implement and will cause the dump to fail rather than causing = the system to hang. Robert= From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 15:20:23 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 BC8FC1065693; Thu, 14 Oct 2010 15:20:23 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1196B8FC25; Thu, 14 Oct 2010 15:20:21 +0000 (UTC) Received: by qwe4 with SMTP id 4so3482780qwe.13 for ; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=aGR+ahDzDeBmYoN2FBFGhAYTsSu0bowfGBkF05Qxdp8=; b=MYEehXmmjpYjbFUjyrxhICH0fwkA9J+fZb3By1kOMJuCIzMhFcDWCWTD+lx7VGalKz wok5lZS9CNSQ9BYVDZ5vmEKY9oqr17pPclnR0DIGhT4ggGRxn+5AF95XI9Fwie7rq3YB kEoOlter0JGnzM2lFDSjd+Nx7Wm81qql150cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OkJAU5GANxCzsAvSSffUzfry8mOndjzLWel/8gpZQbh3mVEPUnfu6dKIH/EvGewuxc Y+O8n6WJECwqNBhgjT6A8CNcWaua2wd0L2laUh4vcp6eQGNYO4Zj2xEUOR0a4RoyOK5e E+ExxR0dhuk/+Ek/Zjw/PyHiHZ+BUyYKxL/Yo= MIME-Version: 1.0 Received: by 10.224.29.4 with SMTP id o4mr830471qac.38.1287069621115; Thu, 14 Oct 2010 08:20:21 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.229.221.141 with HTTP; Thu, 14 Oct 2010 08:20:19 -0700 (PDT) In-Reply-To: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> Date: Thu, 14 Oct 2010 17:20:19 +0200 X-Google-Sender-Auth: EALIKnMFJ19fQUtHNvbKXUyJay0 Message-ID: From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 15:20:23 -0000 2010/10/14 Robert N. M. Watson : > > On 14 Oct 2010, at 15:10, Attilio Rao wrote: > >>> My concern is less about occasional lost dumps that destabilising the d= umping process: calls into the memory allocator can currently trigger a lot= of interesting behaviours, such as further calls back into the VM system, = which can then trigger calls into other subsystems. What I'm suggesting is = that if we want the mbuf allocator to be useful in this context, we need to= teach it about things not to do in the dumping / crash / ... context, whic= h probably means helping uma out a bit in that regard. And a watchdog to ma= ke sure the dump is making progress. >> >> I think that this would be way too complicated just to cope with panic >> within the VM/UMA (not sure what other subsystems you are referring >> to, wrt supposed to call). Besides, if we have a panic in the VM I'm >> sure that normal dumps could also be affected. >> When dealing with netdump, I'm not trying to fix all the bugs related >> to our dumping infrastructure because, as long as we already >> discussed, we know there are quite a few of them, but trying at least >> to follow the same fragile-ness than what we have today. >> And again, while I think the "watchdog" idea is good, I think it still >> applies to normal dumps too, it is not specific to netdump. > > No, what I'm saying is: UMA needs to not call its drain handlers, and ide= ally not call into VM to fill slabs, from the dumping context. That's easy = to implement and will cause the dump to fail rather than causing the system= to hang. Ok. My point is, however, still the same: that should not happen just for the netdump specific case but for all the dumping/KDB/panic cases (I know it is unlikely current code !netdump calls into UMA but it is not an established pre-requisite and may still happen that some added code does). I still see this as a weakness on the infrastructure, independently from netdump. I can see that your point is that it is vital to netdump correct behaviour though, so I'd wonder if it worths fixing it now or later. More people's comment would be appreciated. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 17:20:54 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 E646B106566B; Thu, 14 Oct 2010 17:20:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E114A8FC1A; Thu, 14 Oct 2010 17:20:52 +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 UAA08296; Thu, 14 Oct 2010 20:20:49 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4CB73BF1.1070400@freebsd.org> Date: Thu, 14 Oct 2010 20:20:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4CB5D5E1.9080505@freebsd.org> <4CB5FDC0.6000701@freebsd.org> In-Reply-To: <4CB5FDC0.6000701@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Martin Matuska Subject: Re: Locked up nfsd after avg@ sendfile patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 17:20:54 -0000 on 13/10/2010 21:43 Andriy Gapon said the following: > Further walking child zio hierarchy we reach the one that looks like this: > $59 = {io_bookmark = {zb_objset = 400, zb_object = 0, zb_level = -1, zb_blkid = > 22437}, io_prop = {zp_checksum = ZIO_CHECKSUM_INHERIT, zp_compress = > ZIO_COMPRESS_INHERIT, zp_type = DMU_OT_NONE, > zp_level = 0 '\0', zp_ndvas = 0 '\0'}, io_type = ZIO_TYPE_WRITE, io_child_type > = ZIO_CHILD_VDEV, io_cmd = 0, io_priority = 0 '\0', io_reexecute = 0 '\0', > io_state = "\001", io_txg = 0, > io_spa = 0xffffff00056c6000, io_bp = 0xffffff01acdbaa30, io_bp_copy = {blk_dva = > {{dva_word = {12884902144, 1678614837}}, {dva_word = {0, 0}}, {dva_word = {0, > 0}}}, blk_prop = 9225910817809957119, > blk_pad = {0, 0, 0}, blk_birth = 236695, blk_fill = 0, blk_cksum = {zc_word = > {15569186404091016741, 3408946246337318984, 400, 22437}}}, io_parent_list = > {list_size = 48, list_offset = 16, > list_head = {list_next = 0xffffff000826b7c0, list_prev = 0xffffff000826b7c0}}, > io_child_list = {list_size = 48, list_offset = 32, list_head = {list_next = > 0xffffff00080aca98, > list_prev = 0xffffff00080aca98}}, io_walk_link = 0x0, io_logical = > 0xffffff0008b8d660, io_transform_stack = 0x0, io_ready = 0, io_done = > 0xffffffff80b99ab0 , > io_private = 0xffffff00b5f469a8, io_bp_orig = {blk_dva = {{dva_word = > {12884902144, 1678614837}}, {dva_word = {0, 0}}, {dva_word = {0, 0}}}, blk_prop = > 9225910817809957119, blk_pad = {0, 0, 0}, > blk_birth = 236695, blk_fill = 0, blk_cksum = {zc_word = > {15569186404091016741, 3408946246337318984, 400, 22437}}}, io_data = > 0xffffff80e6565000, io_size = 131072, io_vd = 0xffffff00084cd000, > io_vsd = 0x0, io_vsd_free = 0, io_offset = 859454990848, io_deadline = 20883, > io_offset_node = {avl_child = {0x0, 0x0}, avl_pcb = 18446742974333891893}, > io_deadline_node = {avl_child = {0x0, 0x0}, > avl_pcb = 1}, io_vdev_tree = 0xffffff00084cd578, io_flags = 179, io_stage = > ZIO_STAGE_VDEV_IO_START, io_pipeline = 47104, io_orig_flags = 131, io_orig_stage = > ZIO_STAGE_READY, > io_orig_pipeline = 47104, io_error = 0, io_child_error = {0, 0, 0}, io_children > = {{0, 0}, {0, 0}, {0, 0}}, io_stall = 0x0, io_gang_leader = 0x0, io_gang_tree = 0x0, > io_executor = 0xffffff000875a8a0, io_waiter = 0x0, io_lock = {lock_object = > {lo_name = 0xffffffff80c29a8b "zio->io_lock", lo_flags = 40960000, lo_data = 0, > lo_witness = 0x0}, sx_lock = 1}, > io_cv = {cv_description = 0xffffffff80c29a9a "zio->io_cv)", cv_waiters = 0}, > io_ena = 0, io_task = {ost_task = {ta_running = 0x0, ta_link = {stqe_next = 0x0}, > ta_pending = 0, ta_priority = 0, > ta_func = 0, ta_context = 0x0}, ost_func = 0, ost_arg = 0x0, ost_magic = 0}} So, after some more investigation, it looks like this zio is genuinely stuck, because its bio is stuck in geom because its ccb/command is stuck in arcmsr. Looks like the driver (controller/firmware) isn't processing any more requests. Perhaps a hardware issue, but I reckon that the driver should have detected the situation, timed out the commands and reset the hardware (if needed). Anyway, it looks that this is not related to ZFS[*]. Maybe firmware and BIOS should be updated, maybe hardware replaced. [*] Perhaps ZFS should have its own zio timeout mechanism. And/or GEOM. And/or peripheral or transport layer of CAM. But, IMO, the SIM drivers must have it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Oct 14 22:52: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 4FD4C106564A for ; Thu, 14 Oct 2010 22:52:58 +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 D234E8FC15 for ; Thu, 14 Oct 2010 22:52:57 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=iBCGAMPDYtSF9sDXX85uHY3wcnYctfVT8vFpe3qPflY= c=1 sm=1 a=8SiqrvMBkfUA:10 a=8nJEP1OIZ-IA:10 a=CL8lFSKtTFcA:10 a=i9M/sDlu2rpZ9XS819oYzg==:17 a=6I5d2MoRAAAA:8 a=VFscrPYYAHwoIx1wxuoA:9 a=jQ8FpJV9uD_-oXBsf3MA:7 a=t-Uzwxh79TugGd3J4L4KgGuwT7oA:4 a=wPNLvfGTeEIA:10 a=i9M/sDlu2rpZ9XS819oYzg==:117 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 35460854 for freebsd-current@freebsd.org; Fri, 15 Oct 2010 00:52:56 +0200 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: Fri, 15 Oct 2010 00:54:14 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010150054.14448.hselasky@c2i.net> Subject: Possible solution for USB EHCI IRQ problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 22:52:58 -0000 Hi, Anyone out there experiencing so-called EHCI-hangs, can try applying the following patch by hand: http://p4web.freebsd.org/@@184749?ac=10 ==== //depot/projects/usb/src/sys/dev/usb/controller/ehci.c#62 (text+ko) ==== @@ -1589,6 +1589,10 @@ usb_callout_reset(&sc->sc_tmo_pcd, hz, (void *)&ehci_pcd_enable, sc); } + /* if there was a doorbell, clear the doorbell busy flag */ + if (status & EHCI_STS_IAA) + sc->sc_flags &= ~EHCI_SCFLG_IAADBUSY; + status &= ~(EHCI_STS_INT | EHCI_STS_ERRINT | EHCI_STS_PCD | EHCI_STS_IAA); if (status != 0) { @@ -2313,7 +2317,7 @@ * XXX Certain nVidia chipsets choke when using the IAAD * feature too frequently. */ - if (sc->sc_flags & EHCI_SCFLG_IAADBUG) + if (sc->sc_flags & (EHCI_SCFLG_IAADBUG | EHCI_SCFLG_IAADBUSY)) return; /* XXX Performance quirk: Some Host Controllers have a too low @@ -2321,8 +2325,10 @@ * Controller after queueing the BULK transfer. */ temp = EOREAD4(sc, EHCI_USBCMD); - if (!(temp & EHCI_CMD_IAAD)) + if (!(temp & EHCI_CMD_IAAD)) { EOWRITE4(sc, EHCI_USBCMD, temp | EHCI_CMD_IAAD); + sc->sc_flags |= EHCI_SCFLG_IAADBUSY; + } } struct usb_pipe_methods ehci_device_bulk_methods = ==== //depot/projects/usb/src/sys/dev/usb/controller/ehci.h#20 (text+ko) ==== @@ -347,6 +347,7 @@ #define EHCI_SCFLG_TT 0x0020 /* transaction translator present */ #define EHCI_SCFLG_LOSTINTRBUG 0x0040 /* workaround for VIA / ATI chipsets */ #define EHCI_SCFLG_IAADBUG 0x0080 /* workaround for nVidia chipsets */ +#define EHCI_SCFLG_IAADBUSY 0x0100 /* doorbell is busy */ uint8_t sc_offs; /* offset to operational registers */ uint8_t sc_doorbell_disable; /* set on doorbell failure */ --HPS From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 18:05:10 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 1B62F106566C for ; Fri, 15 Oct 2010 18:05:10 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id AFE768FC14 for ; Fri, 15 Oct 2010 18:05:09 +0000 (UTC) Received: from uucp by gromit.grondar.org with UUCP (Exim 4.72) (envelope-from ) id 1P6oeS-0007Ig-Pd for current@freebsd.org; Fri, 15 Oct 2010 19:05:08 +0100 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6oe7-0000lL-JV for current@freebsd.org; Fri, 15 Oct 2010 19:04:47 +0100 Message-Id: To: current@freebsd.org From: Mark Murray Date: Fri, 15 Oct 2010 19:04:47 +0100 Cc: Subject: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:05:10 -0000 Hi IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the following (which works): $ ifconfig gif0 create $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 $ ifconfig gif0 inet6 2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128 $ route -n add -inet6 default 2001:1111:2222:3333::1 $ ifconfig gif0 up ... when my non-working setup in /etc/rc.conf contains gif_interfaces="gif0" gifconfig_gif0="192.168.0.2 11.22.33.44" gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" ipv6_defaultrouter="-inet6 default 2001:1111:2222:3333::1" ... which used to work. The bit that fails is the bit where gif0 gets its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6="..." and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto gif0. This used to work, but setting up IPv6 in CURRENT is a moving target, and I can't find a working example any more. I've looked in /etc/defaults/rc.conf, but the gifN examples there are all devoid of any IPv6 examples. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 18:14: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 1191510656A9 for ; Fri, 15 Oct 2010 18:14:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9473F8FC16 for ; Fri, 15 Oct 2010 18:14:58 +0000 (UTC) Received: (qmail 19304 invoked by uid 399); 15 Oct 2010 18:14:57 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Oct 2010 18:14:57 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CB89A21.4050509@FreeBSD.org> Date: Fri, 15 Oct 2010 11:14:57 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org, hrs@FreeBSD.org References: In-Reply-To: X-Enigmail-Version: 1.2a1pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:14:59 -0000 On 10/15/2010 11:04 AM, Mark Murray wrote: > Hi > > IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the > following (which works): > > $ ifconfig gif0 create > $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 > $ ifconfig gif0 inet6 2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128 > $ route -n add -inet6 default 2001:1111:2222:3333::1 > $ ifconfig gif0 up > > ... when my non-working setup in /etc/rc.conf contains > > gif_interfaces="gif0" > gifconfig_gif0="192.168.0.2 11.22.33.44" > gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" > ipv6_defaultrouter="-inet6 default 2001:1111:2222:3333::1" > > ... which used to work. The bit that fails is the bit where gif0 gets > its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6="..." > and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto > gif0. > > This used to work, but setting up IPv6 in CURRENT is a moving > target, and I can't find a working example any more. I've looked in > /etc/defaults/rc.conf, but the gifN examples there are all devoid of any > IPv6 examples. Sorry for your frustration. Hiroki has taken over the IPv6 configuration responsibility, so hopefully he can help get you on the right path. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 18:28: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 685091065672 for ; Fri, 15 Oct 2010 18:28:17 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id E58AD8FC1D for ; Fri, 15 Oct 2010 18:28:16 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P6p0n-0001uy-Il for freebsd-current@freebsd.org; Fri, 15 Oct 2010 20:28:13 +0200 Received: from 207.155.204.151.ptr.us.xo.net ([207.155.204.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Oct 2010 20:28:13 +0200 Received: from atkin901 by 207.155.204.151.ptr.us.xo.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Oct 2010 20:28:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Date: Fri, 15 Oct 2010 11:28:03 -0700 Lines: 53 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 207.155.204.151.ptr.us.xo.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100920 Thunderbird/3.1.4 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 18:28:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/15/2010 11:04, Mark Murray wrote: > Hi > > IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the > following (which works): > > $ ifconfig gif0 create > $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 > $ ifconfig gif0 inet6 2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128 > $ route -n add -inet6 default 2001:1111:2222:3333::1 > $ ifconfig gif0 up > > ... when my non-working setup in /etc/rc.conf contains > > gif_interfaces="gif0" > gifconfig_gif0="192.168.0.2 11.22.33.44" > gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" > ipv6_defaultrouter="-inet6 default 2001:1111:2222:3333::1" > > ... which used to work. The bit that fails is the bit where gif0 gets > its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6="..." > and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto > gif0. > > This used to work, but setting up IPv6 in CURRENT is a moving > target, and I can't find a working example any more. I've looked in > /etc/defaults/rc.conf, but the gifN examples there are all devoid of any > IPv6 examples. I found that my ipv6 tunnel setup needed to be dead last in startup. I could not get it to configure properly via rc.conf and come up. So I just setup the following script to run after the system comes up (using your ip examples): /etc/rc.d/rtadvd stop ifconfig gif0 inet6 2002001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128 ifconfig gif0 inet6 -ifdisabled route add -inet6 default 2001:1111:2222:3333::1 ifconfig internal inet6 2001:1111:4444:3333::/64 eui64 ifconfig internal inet6 -ifdisabled /etc/rc.d/rtadvd start -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky4nTMACgkQrDN5kXnx8yYbSwCgl34QIrmZwCVF+em+ZoeJPOi0 S/cAnAzmCVxrsoiubNWEW8QWcR1dRlBN =rM+v -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:15: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 9F464106566C for ; Fri, 15 Oct 2010 19:15:55 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 741538FC08 for ; Fri, 15 Oct 2010 19:15:55 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id 93D5515754E; Fri, 15 Oct 2010 14:15:54 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id RQ4ZTD7Z9OO3; Fri, 15 Oct 2010 14:15:54 -0500 From: Rui Paulo Content-Type: text/plain; charset=us-ascii Message-Id: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> Date: Fri, 15 Oct 2010 20:15:52 +0100 To: hackers@freebsd.org, "current@freebsd.org Current" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: Subject: Removal of libobjc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:15:55 -0000 Hi, I was hoping we could remove libobjc from the base system as it's = seriously outdated and it's not used by anything on the base system. If there are any objections, please speak up. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:19: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 37646106564A; Fri, 15 Oct 2010 19:19:46 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id E0FBA8FC0A; Fri, 15 Oct 2010 19:19:45 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 5FC129CB06B; Fri, 15 Oct 2010 21:19:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2cbHK2FTLZo; Fri, 15 Oct 2010 21:19:43 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E29A09CB23F; Fri, 15 Oct 2010 21:19:42 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id o9FJJgxa045690; Fri, 15 Oct 2010 21:19:42 +0200 (CEST) (envelope-from rdivacky) Date: Fri, 15 Oct 2010 21:19:42 +0200 From: Roman Divacky To: Rui Paulo Message-ID: <20101015191942.GA45582@freebsd.org> References: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: hackers@freebsd.org, "current@freebsd.org Current" Subject: Re: Removal of libobjc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:19:46 -0000 On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: > Hi, > > I was hoping we could remove libobjc from the base system as it's seriously outdated and it's not used by anything on the base system. > > If there are any objections, please speak up. please wait until the ports are converted to use libobjc2 (already in progress).. it should be a few days/weeks at most now I think roman From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:25:43 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 72A04106564A; Fri, 15 Oct 2010 19:25:43 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 41AF28FC18; Fri, 15 Oct 2010 19:25:43 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D0DB646BA3; Fri, 15 Oct 2010 15:25:42 -0400 (EDT) Date: Fri, 15 Oct 2010 20:25:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , freebsd-net@freebsd.org, Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:25:43 -0000 On Thu, 14 Oct 2010, Attilio Rao wrote: >> No, what I'm saying is: UMA needs to not call its drain handlers, and >> ideally not call into VM to fill slabs, from the dumping context. That's >> easy to implement and will cause the dump to fail rather than causing the >> system to hang. > > My point is, however, still the same: that should not happen just for the > netdump specific case but for all the dumping/KDB/panic cases (I know it is > unlikely current code !netdump calls into UMA but it is not an established > pre-requisite and may still happen that some added code does). I still see > this as a weakness on the infrastructure, independently from netdump. I can > see that your point is that it is vital to netdump correct behaviour though, > so I'd wonder if it worths fixing it now or later. Quite a bit of our kernel and dumping infrastructure special cases debugging and dumping behavior to avoid sources of non-robustness. For example, serial drivers avoid locking, and for disk dumps we bypass GEOM to avoid the memory allocation, freeing, and threading that it depends on. The goal here is to be robust when handling dumps: hanging is worse than not dumping, since you won't get the dump either way, and if you don't reboot then the system requires manual intervention to recover. Example of things that are critical to avoid include: - The dumping thread tripping over locks held by the panicked thread, or by another now-suspended thread, leading to deadlock against a suspended thread. - Corrupting dumps by increasing concurrency in the panic case. We ran into a case a year or two ago where changing VM state during the dump on amd64 caused file system corruption as the dump code assumed that the space required for a dump didn't change while dumping took place. Any code dependency we add in the panic / KDB / dump path is one more risk that we don't successfully dump and reboot, so we need to minimize that code. Robert From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:35:05 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 ADADD106566B; Fri, 15 Oct 2010 19:35:05 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4858FC15; Fri, 15 Oct 2010 19:35:05 +0000 (UTC) Received: from c.earth.lavabit.com (c.earth.lavabit.com [192.168.111.12]) by karen.lavabit.com (Postfix) with ESMTP id A6B1C157549; Fri, 15 Oct 2010 14:35:04 -0500 (CDT) Received: from rui-macbook.lan (bl17-136-196.dsl.telepac.pt [188.82.136.196]) by lavabit.com with ESMTP id D42MLNF8MSPS; Fri, 15 Oct 2010 14:35:04 -0500 References: <2AD11EA8-18FC-46E1-AE97-184599A054AD@freebsd.org> <20101015191942.GA45582@freebsd.org> In-Reply-To: <20101015191942.GA45582@freebsd.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <1C20C791-3D0D-4695-BF82-FD8211323561@freebsd.org> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Fri, 15 Oct 2010 20:35:01 +0100 To: Roman Divacky X-Mailer: Apple Mail (2.1081) Cc: hackers@freebsd.org, "current@freebsd.org Current" Subject: Re: Removal of libobjc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:35:05 -0000 On 15 Oct 2010, at 20:19, Roman Divacky wrote: > On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: >> Hi, >>=20 >> I was hoping we could remove libobjc from the base system as it's = seriously outdated and it's not used by anything on the base system. >>=20 >> If there are any objections, please speak up. >=20 > please wait until the ports are converted to use libobjc2 (already in = progress).. >=20 > it should be a few days/weeks at most now I think Yes, I was just asking if someone was against it. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:38: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 08D3410656C6; Fri, 15 Oct 2010 19:38:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id B19B08FC1C; Fri, 15 Oct 2010 19:38:57 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D42275ACC3; Fri, 15 Oct 2010 21:18:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D08B15ACB7; Fri, 15 Oct 2010 21:18:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id ABCC15CD54; Fri, 15 Oct 2010 21:18:04 +0200 (CEST) Received: from wep4035.physik.uni-wuerzburg.de ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.5.2HF17) with ESMTP id 2010101521180396-7764 ; Fri, 15 Oct 2010 21:18:03 +0200 Date: Fri, 15 Oct 2010 21:18:02 +0200 From: Alexey Shuvaev To: Mark Murray Message-ID: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> References: MIME-Version: 1.0 In-Reply-To: Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.5.2HF17 | August 31, 2010) at 10/15/2010 09:18:04 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.5.2HF17 | August 31, 2010) at 10/15/2010 09:18:04 PM, Serialize complete at 10/15/2010 09:18:04 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: current@freebsd.org Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:38:58 -0000 On Fri, Oct 15, 2010 at 07:04:47PM +0100, Mark Murray wrote: > Hi > > IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the > following (which works): > > $ ifconfig gif0 create > $ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44 > $ ifconfig gif0 inet6 2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128 > $ route -n add -inet6 default 2001:1111:2222:3333::1 > $ ifconfig gif0 up > > ... when my non-working setup in /etc/rc.conf contains > > gif_interfaces="gif0" > gifconfig_gif0="192.168.0.2 11.22.33.44" > gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" ^^^^ ^^^^ I suppose you should prefix it with "inet6" keyword. There are 2 examples in rc.conf (search for "Sample IPv6"). > ipv6_defaultrouter="-inet6 default 2001:1111:2222:3333::1" > > ... which used to work. The bit that fails is the bit where gif0 gets > its tunnel IPv6 addresses. I've tried both gifconfig_gif0_ipv6="..." > and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto > gif0. > > This used to work, but setting up IPv6 in CURRENT is a moving > target, and I can't find a working example any more. I've looked in > /etc/defaults/rc.conf, but the gifN examples there are all devoid of any > IPv6 examples. > HTH, Alexey. From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:39:13 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 DE55110656AA; Fri, 15 Oct 2010 19:39:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC9B8FC13; Fri, 15 Oct 2010 19:39:12 +0000 (UTC) Received: by iwn6 with SMTP id 6so786126iwn.13 for ; Fri, 15 Oct 2010 12:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=iTz6zF4dhgB8tpOCDrEMJj4b/uhGitBEZaEW9uWTgOU=; b=FDy8gw2qnyDzle46MnzDchKOooTzXHf0wk+4I0Qw0Z5euBRwEjO34FYDT9Bbqzy7d0 NzWP2RVOV+k/jUBH1mIIDy3q24OsXwHFeGdNd8JZcFLQtA8T+/WRK9NOiQE7sLp9xSaN pX0+2nrkBfWkYXnejmZhL0djBEZWJWI/luxCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cQUFAGyg84IZg+3As0GhN6Oj0UWrbKmJARmk080YUu5Ha88YF2Q3JFETj3SrIXpUSq bxbnmUMAESGeIkJ3Ymdp2D5q7OVnqao75UrhgMoZHr5x7TkgaHo0lULFop70rGWM6oLl R0Xbgil4qYNKWj/Ro7fGj6MnNoseRuKbiQkO0= MIME-Version: 1.0 Received: by 10.231.144.74 with SMTP id y10mr1143822ibu.65.1287171551591; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.231.184.3 with HTTP; Fri, 15 Oct 2010 12:39:11 -0700 (PDT) In-Reply-To: References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> Date: Fri, 15 Oct 2010 12:39:11 -0700 X-Google-Sender-Auth: 6NTs1zcDiFapHTGRGuOeHVzConA Message-ID: From: Garrett Cooper To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:39:14 -0000 On Fri, Oct 15, 2010 at 12:25 PM, Robert Watson wrote= : > On Thu, 14 Oct 2010, Attilio Rao wrote: > >>> No, what I'm saying is: UMA needs to not call its drain handlers, and >>> ideally not call into VM to fill slabs, from the dumping context. That'= s >>> easy to implement and will cause the dump to fail rather than causing t= he >>> system to hang. >> >> My point is, however, still the same: that should not happen just for th= e >> netdump specific case but for all the dumping/KDB/panic cases (I know it= is >> unlikely current code !netdump calls into UMA but it is not an establish= ed >> pre-requisite and may still happen that some added code does). I still s= ee >> this as a weakness on the infrastructure, independently from netdump. I = can >> see that your point is that it is vital to netdump correct behaviour tho= ugh, >> so I'd wonder if it worths fixing it now or later. > > Quite a bit of our kernel and dumping infrastructure special cases debugg= ing > and dumping behavior to avoid sources of non-robustness. =A0For example, > serial drivers avoid locking, and for disk dumps we bypass GEOM to avoid = the > memory allocation, freeing, and threading that it depends on. > > The goal here is to be robust when handling dumps: hanging is worse than = not > dumping, since you won't get the dump either way, and if you don't reboot > then the system requires manual intervention to recover. =A0Example of th= ings > that are critical to avoid include: > > - The dumping thread tripping over locks held by the panicked thread, or = by > =A0another now-suspended thread, leading to deadlock against a suspended > =A0thread. > > - Corrupting dumps by increasing concurrency in the panic case. =A0We ran= into > a > =A0case a year or two ago where changing VM state during the dump on amd6= 4 > =A0caused file system corruption as the dump code assumed that the space > =A0required for a dump didn't change while dumping took place. > > Any code dependency we add in the panic / KDB / dump path is one more ris= k > that we don't successfully dump and reboot, so we need to minimize that > code. But there are already some cases that aren't properly handled today in the ddb area dealing with dumping that aren't handled properly. Take for instance the following two scenarios: 1. Call doadump twice from the debugger. 2. Call doadump, exit the debugger, reenter the debugger, and call doadump again. Both of these scenarios hang reliably for me. I'm not saying that we should regress things further, but I'm just noting that there are most likely a chunk of edgecases that aren't being handled properly when doing dumps that could be handled better / fixed. Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 19:46: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 E88B9106564A; Fri, 15 Oct 2010 19:46:00 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B5C948FC08; Fri, 15 Oct 2010 19:46:00 +0000 (UTC) Received: from [192.168.2.105] (host86-161-142-69.range86-161.btcentralplus.com [86.161.142.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AE5746B32; Fri, 15 Oct 2010 15:45:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: Date: Fri, 15 Oct 2010 20:45:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93AB0F13-5995-4AAD-BEFC-A6F1317E3CA6@freebsd.org> References: <15387E38-1E6C-4347-BEA1-61AEE31B5544@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) Cc: FreeBSD Current , freebsd-net@freebsd.org, Attilio Rao , Sergey Kandaurov , Jack F Vogel , Ryan Stone , Ryan Stone , Ed Maste Subject: Re: [PATCH] Netdump for review and testing -- preliminary version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:46:01 -0000 On 15 Oct 2010, at 20:39, Garrett Cooper wrote: > But there are already some cases that aren't properly handled > today in the ddb area dealing with dumping that aren't handled > properly. Take for instance the following two scenarios: > 1. Call doadump twice from the debugger. > 2. Call doadump, exit the debugger, reenter the debugger, and call > doadump again. > Both of these scenarios hang reliably for me. > I'm not saying that we should regress things further, but I'm just > noting that there are most likely a chunk of edgecases that aren't > being handled properly when doing dumps that could be handled better / > fixed. Right: one of the points I've made to Attilio is that we need to move to = a more principled model as to what sorts of things we allow in various = kernel environments. The early boot is a special environment -- so is = the debugger, but the debugger on panic is not the same as the debugger = when you can continue. Likewise, the crash dumping code is special, but = also not the same as the debugger. Right now, exceptional behaviour to = limit hangs/etc is done inconsistently. We need to develop a set of = principles that tell us what is permitted in what contexts, and then use = that to drive design decisions, normalizing what's there already. This is not dissimilar to what we do with locking already, BTW: we = define a set of kernel environments (fast interrupt handlers, = non-sleepable threads, sleepable thread holding non-sleepable locks, = etc), and based on those principles prevent significant sources of = instability that might otherwise arise in a complex, concurrent kernel. = We need to apply the same sort of approach to handling kernel debugging = and crashing. BTW, my view is that except in very exceptional cases, it should not be = possible to continue after generating a dump. Dumps often cause disk = controllers to get reset, which may leave outstanding I/O in nasty = situations. Unless the dump device and model is known not to interfere = with operation, we should set state indicating that the system is = non-continuable once a dump has occurred. Robert From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 20:25: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 62E25106564A for ; Fri, 15 Oct 2010 20:25:07 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id E8A958FC14 for ; Fri, 15 Oct 2010 20:25:06 +0000 (UTC) Received: from uucp by gromit.grondar.org with UUCP (Exim 4.72) (envelope-from ) id 1P6qpt-00062a-KJ for current@freebsd.org; Fri, 15 Oct 2010 21:25:05 +0100 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P6qp8-0000zW-AE; Fri, 15 Oct 2010 21:24:18 +0100 Message-Id: To: Alexey Shuvaev In-reply-to: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> References: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> From: Mark Murray Date: Fri, 15 Oct 2010 21:24:18 +0100 Cc: current@freebsd.org Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:25:07 -0000 Alexey Shuvaev writes: > > gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" > ^^^^ ^^^^ > I suppose you should prefix it with "inet6" keyword. > There are 2 examples in rc.conf (search for "Sample IPv6"). Aaaaah! It didn't occur to me that I might need TWO inet6's! I'll give that a go when I play with this again tomorrow. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 20:42:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DB8AC1065672; Fri, 15 Oct 2010 20:42:07 +0000 (UTC) Date: Fri, 15 Oct 2010 20:42:07 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101015204207.GA87192@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline Subject: iostat(8) manual fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:42:07 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, the iostat(8) manual seems to contain a few errors. this patch should take care of that. cheers. alex -- a13x --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iostat.8.diff" diff --git a/usr.sbin/iostat/iostat.8 b/usr.sbin/iostat/iostat.8 index 6a9ef02..3b03acc 100644 --- a/usr.sbin/iostat/iostat.8 +++ b/usr.sbin/iostat/iostat.8 @@ -60,7 +60,7 @@ .\" .\" @(#)iostat.8 8.1 (Berkeley) 6/6/93 .\" -.Dd April 17, 2006 +.Dd October 15, 2010 .Dt IOSTAT 8 .Os .Sh NAME @@ -102,11 +102,15 @@ Repeat the display times. If no repeat .Ar count -is specified, the default is infinity. +is specified, and +.Fl w +is specified, the default is infinity, otherwise the default is one. .It Fl C Display CPU statistics. This is on by default, unless .Fl d +or +.Fl x is specified. .It Fl d Display only device statistics. @@ -231,6 +235,8 @@ output, up to the number of devices that can be displayed in Display TTY statistics. This is on by default, unless .Fl d +or +.Fl x is specified. .It Fl w Pause --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 20:47:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5447A106566C; Fri, 15 Oct 2010 20:47:48 +0000 (UTC) Date: Fri, 15 Oct 2010 20:47:48 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101015204748.GA88259@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: some camcontrol(8) cleanups X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:47:49 -0000 hi there, i sent this patch to mav@, but he seems rather busy atm. maybe somebody else would like to take a look at it and see if it improves camcontrol's current behavior. cheers. alex ----- Forwarded message from Alexander Best ----- Date: Mon, 27 Sep 2010 00:35:41 +0000 From: Alexander Best To: Alexander Motin Subject: some camcontrol(8) cleanups hi there, since you're the most active committer to camcontrol i thought i'd mail you this patch which does some whitespace cleaning up in camcontrol.c along with some 'camcontrol identify' improvements (imo). the only real change is that i removed this check: if (parm->satacapabilities && parm->satacapabilities != 0xffff) i've run the patched camcontrol against a few devices and none seemed to return parm->satacapabilities == 0xffff. so i don't think this check is needed in order to prevent 'camcontrol identify' to falsely report NCQ supported/enabled. cheers. alex -- a13x diff --git a/sbin/camcontrol/camcontrol.c b/sbin/camcontrol/camcontrol.c index 9f26906..b822282 100644 --- a/sbin/camcontrol/camcontrol.c +++ b/sbin/camcontrol/camcontrol.c @@ -116,7 +116,7 @@ typedef enum { } cam_argmask; struct camcontrol_opts { - const char *optname; + const char *optname; cam_cmdmask cmdnum; cam_argmask argnum; const char *subopt; @@ -204,7 +204,7 @@ static int readdefects(struct cam_device *device, int argc, char **argv, char *combinedopt, int retry_count, int timeout); static void modepage(struct cam_device *device, int argc, char **argv, char *combinedopt, int retry_count, int timeout); -static int scsicmd(struct cam_device *device, int argc, char **argv, +static int scsicmd(struct cam_device *device, int argc, char **argv, char *combinedopt, int retry_count, int timeout); static int tagcontrol(struct cam_device *device, int argc, char **argv, char *combinedopt); @@ -234,7 +234,7 @@ static int atapm(struct cam_device *device, int argc, char **argv, #endif camcontrol_optret -getoption(char *arg, cam_cmdmask *cmdnum, cam_argmask *argnum, +getoption(char *arg, cam_cmdmask *cmdnum, cam_argmask *argnum, const char **subopt) { struct camcontrol_opts *opts; @@ -622,7 +622,7 @@ scsistart(struct cam_device *device, int startstop, int loadeject, else fprintf(stdout, "Error received from stop unit command\n"); - + if (arglist & CAM_ARG_VERBOSE) { cam_error_print(device, ccb, CAM_ESF_ALL, CAM_EPF_ALL, stderr); @@ -688,7 +688,7 @@ scsiinquiry(struct cam_device *device, int retry_count, int timeout) union ccb *ccb; struct scsi_inquiry_data *inq_buf; int error = 0; - + ccb = cam_getccb(device); if (ccb == NULL) { @@ -721,13 +721,13 @@ scsiinquiry(struct cam_device *device, int retry_count, int timeout) * scsi_inquiry() will convert an inq_len (which is passed in as * a u_int32_t, but the field in the CDB is only 1 byte) of 256 * to 0. Evidently, very few devices meet the spec in that - * regard. Some devices, like many Seagate disks, take the 0 as + * regard. Some devices, like many Seagate disks, take the 0 as * 0, and don't return any data. One Pioneer DVD-R drive * returns more data than the command asked for. * * So, since there are numerous devices that just don't work * right with the full inquiry size, we don't send the full size. - * + * * - The second reason not to use the full inquiry data length is * that we don't need it here. The only reason we issue a * standard inquiry is to get the vendor name, device name, @@ -1181,7 +1181,7 @@ atacapprint(struct ata_params *parm) } printf("\nFeature " - "Support Enable Value Vendor\n"); + "Support Enabled Value Vendor\n"); printf("read ahead %s %s\n", parm->support.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_LOOKAHEAD ? "yes" : "no"); @@ -1201,16 +1201,13 @@ atacapprint(struct ata_params *parm) ATA_QUEUE_LEN(parm->queue) + 1); } else printf("\n"); - if (parm->satacapabilities && parm->satacapabilities != 0xffff) { - printf("Native Command Queuing (NCQ) %s ", - parm->satacapabilities & ATA_SUPPORT_NCQ ? - "yes" : "no"); + printf("Native Command Queuing (NCQ) %s", + parm->satacapabilities & ATA_SUPPORT_NCQ ? "yes" : "no"); if (parm->satacapabilities & ATA_SUPPORT_NCQ) { - printf(" %d tags\n", + printf(" %d tags\n", ATA_QUEUE_LEN(parm->queue) + 1); } else printf("\n"); - } printf("SMART %s %s\n", parm->support.command1 & ATA_SUPPORT_SMART ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_SMART ? "yes" : "no"); @@ -1223,28 +1220,39 @@ atacapprint(struct ata_params *parm) printf("power management %s %s\n", parm->support.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no", parm->enabled.command1 & ATA_SUPPORT_POWERMGT ? "yes" : "no"); - printf("advanced power management %s %s %d/0x%02X\n", + printf("advanced power management %s %s", parm->support.command2 & ATA_SUPPORT_APM ? "yes" : "no", - parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no", - parm->apm_value, parm->apm_value); - printf("automatic acoustic management %s %s " - "%d/0x%02X %d/0x%02X\n", + parm->enabled.command2 & ATA_SUPPORT_APM ? "yes" : "no"); + if (parm->support.command2 & ATA_SUPPORT_APM) { + printf(" %d/0x%02X\n", + parm->apm_value, parm->apm_value); + } else + printf("\n"); + printf("automatic acoustic management %s %s", parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", - parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no", - ATA_ACOUSTIC_CURRENT(parm->acoustic), - ATA_ACOUSTIC_CURRENT(parm->acoustic), - ATA_ACOUSTIC_VENDOR(parm->acoustic), - ATA_ACOUSTIC_VENDOR(parm->acoustic)); + parm->enabled.command2 & ATA_SUPPORT_AUTOACOUSTIC ? "yes" :"no"); + if (parm->support.command2 & ATA_SUPPORT_AUTOACOUSTIC) { + printf(" %d/0x%02X %d/0x%02X\n", + ATA_ACOUSTIC_CURRENT(parm->acoustic), + ATA_ACOUSTIC_CURRENT(parm->acoustic), + ATA_ACOUSTIC_VENDOR(parm->acoustic), + ATA_ACOUSTIC_VENDOR(parm->acoustic)); + } else + printf("\n"); printf("media status notification %s %s\n", parm->support.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no", parm->enabled.command2 & ATA_SUPPORT_NOTIFY ? "yes" : "no"); printf("power-up in Standby %s %s\n", parm->support.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no", parm->enabled.command2 & ATA_SUPPORT_STANDBY ? "yes" : "no"); - printf("write-read-verify %s %s %d/0x%x\n", + printf("write-read-verify %s %s", parm->support2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", - parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no", - parm->wrv_mode, parm->wrv_mode); + parm->enabled2 & ATA_SUPPORT_WRITEREADVERIFY ? "yes" : "no"); + if (parm->support2 & ATA_SUPPORT_WRITEREADVERIFY) { + printf(" %d/0x%x\n", + parm->wrv_mode, parm->wrv_mode); + } else + printf("\n"); printf("unload %s %s\n", parm->support.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no", parm->enabled.extension & ATA_SUPPORT_UNLOAD ? "yes" : "no"); @@ -1255,7 +1263,6 @@ atacapprint(struct ata_params *parm) parm->support_dsm & ATA_SUPPORT_DSM_TRIM ? "yes" : "no"); } - static int ataidentify(struct cam_device *device, int retry_count, int timeout) { @@ -1902,7 +1909,7 @@ readdefects(struct cam_device *device, int argc, char **argv, /* * XXX KDM I should probably clean up the printout format for the - * disk defects. + * disk defects. */ switch (returned_format & SRDDH10_DLIST_FORMAT_MASK){ case SRDDH10_PHYSICAL_SECTOR_FORMAT: @@ -2011,7 +2018,7 @@ void reassignblocks(struct cam_device *device, u_int32_t *blocks, int num_blocks) { union ccb *ccb; - + ccb = cam_getccb(device); cam_freeccb(ccb); @@ -2114,7 +2121,7 @@ mode_select(struct cam_device *device, int save_pages, int retry_count, err(1, "error sending mode select command"); else errx(1, "error sending mode select command"); - + } cam_freeccb(ccb); @@ -2294,7 +2301,7 @@ scsicmd(struct cam_device *device, int argc, char **argv, char *combinedopt, if (arglist & CAM_ARG_CMD_IN) { warnx("command must either be " "read or write, not both"); - error = 1; + error = 1; goto scsicmd_bailout; } arglist |= CAM_ARG_CMD_OUT; @@ -2611,7 +2618,7 @@ camdebug(int argc, char **argv, char *combinedopt) warnx("bus:target, or bus:target:lun to debug"); } } - + if (error == 0) { ccb.ccb_h.func_code = XPT_DEBUG; @@ -2874,7 +2881,7 @@ cts_print(struct cam_device *device, struct ccb_trans_settings *cts) } /* - * Get a path inquiry CCB for the specified device. + * Get a path inquiry CCB for the specified device. */ static int get_cpi(struct cam_device *device, struct ccb_pathinq *cpi) @@ -2913,7 +2920,7 @@ get_cpi_bailout: } /* - * Get a get device CCB for the specified device. + * Get a get device CCB for the specified device. */ static int get_cgd(struct cam_device *device, struct ccb_getdev *cgd) @@ -3764,9 +3771,9 @@ doreport: fprintf(stdout, "\rFormatting: %ju.%02u %% " "(%d/%d) done", - (uintmax_t)(percentage / + (uintmax_t)(percentage / (0x10000 * 100)), - (unsigned)((percentage / + (unsigned)((percentage / 0x10000) % 100), val, 0x10000); fflush(stdout); @@ -3956,7 +3963,7 @@ retry: case RPL_LUNDATA_ATYP_PERIPH: if ((lundata->luns[i].lundata[j] & RPL_LUNDATA_PERIPH_BUS_MASK) != 0) - fprintf(stdout, "%d:", + fprintf(stdout, "%d:", lundata->luns[i].lundata[j] & RPL_LUNDATA_PERIPH_BUS_MASK); else if ((j == 0) @@ -3994,7 +4001,7 @@ retry: field_len_code = (lundata->luns[i].lundata[j] & RPL_LUNDATA_EXT_LEN_MASK) >> 4; field_len = field_len_code * 2; - + if ((eam_code == RPL_LUNDATA_EXT_EAM_WK) && (field_len_code == 0x00)) { fprintf(stdout, "%d", @@ -4352,7 +4359,7 @@ bailout: #endif /* MINIMALISTIC */ -void +void usage(int verbose) { fprintf(verbose ? stdout : stderr, @@ -4494,7 +4501,7 @@ usage(int verbose) #endif /* MINIMALISTIC */ } -int +int main(int argc, char **argv) { int c; @@ -4544,7 +4551,7 @@ main(int argc, char **argv) * this. getopt is kinda braindead, so you end up having to run * through the options twice, and give each invocation of getopt * the option string for the other invocation. - * + * * You would think that you could just have two groups of options. * The first group would get parsed by the first invocation of * getopt, and the second group would get parsed by the second @@ -4553,13 +4560,13 @@ main(int argc, char **argv) * to the argument _after_ the first argument in the second group. * So when the second invocation of getopt comes around, it doesn't * recognize the first argument it gets and then bails out. - * + * * A nice alternative would be to have a flag for getopt that says * "just keep parsing arguments even when you encounter an unknown * argument", but there isn't one. So there's no real clean way to * easily parse two sets of arguments without having one invocation * of getopt know about the other. - * + * * Without this hack, the first invocation of getopt would work as * long as the generic arguments are first, but the second invocation * (in the subfunction) would fail in one of two ways. In the case @@ -4573,14 +4580,14 @@ main(int argc, char **argv) * whether optind had been incremented one option too far. The * mechanics of that, however, are more daunting than just giving * both invocations all of the expect options for either invocation. - * + * * Needless to say, I wouldn't mind if someone invented a better * (non-GPL!) command line parsing interface than getopt. I * wouldn't mind if someone added more knobs to getopt to make it * work better. Who knows, I may talk myself into doing it someday, * if the standards weenies let me. As it is, it just leads to * hackery like this and causes people to avoid it in some cases. - * + * * KDM, September 8th, 1998 */ if (subopt != NULL) @@ -4607,7 +4614,7 @@ main(int argc, char **argv) /* * First catch people who try to do things like: - * camcontrol tur /dev/da0 + * camcontrol tur /dev/da0 * camcontrol doesn't take device nodes as arguments. */ if (argv[2][0] == '/') { ----- End forwarded message ----- -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 20:55: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 5CCCF106567A; Fri, 15 Oct 2010 20:55:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 1C0A58FC1A; Fri, 15 Oct 2010 20:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CFFE941C713; Fri, 15 Oct 2010 22:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id mPsjiUt0ZIMe; Fri, 15 Oct 2010 22:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id E61D541C705; Fri, 15 Oct 2010 22:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9C5A64448F3; Fri, 15 Oct 2010 20:51:33 +0000 (UTC) Date: Fri, 15 Oct 2010 20:51:33 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Mark Murray In-Reply-To: Message-ID: <20101015204947.N10185@maildrop.int.zabbadoz.net> References: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 20:55:12 -0000 On Fri, 15 Oct 2010, Mark Murray wrote: > Alexey Shuvaev writes: >>> gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" >> ^^^^ ^^^^ >> I suppose you should prefix it with "inet6" keyword. >> There are 2 examples in rc.conf (search for "Sample IPv6"). > > Aaaaah! > > It didn't occur to me that I might need TWO inet6's! I'll give that a go when > I play with this again tomorrow. It's just one inet6; put there what you would pass to ifconfig on the command line. The fact that ifconfig defaults to "inet" is the problem leading to more confusion. I think the samples in defaults/rc.conf will be more clear soon. /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 21:20: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 3A09B1065673; Fri, 15 Oct 2010 21:20:55 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id D16F58FC20; Fri, 15 Oct 2010 21:20:54 +0000 (UTC) Received: by qyk30 with SMTP id 30so1412873qyk.13 for ; Fri, 15 Oct 2010 14:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QaLZtPIB4Oo5GQ6gqAFX+5/4HTMsGmILYQiKsl9cpjw=; b=rscJ0VR0PxdBguV9RTLybYSYWKb2x12SyfH3oK1PDKtWuiYzR/fwNJOSfUX6kfhEx8 UnaqLMcc0Fm1tP1ycBnND8+FTRwATGAINEheQXbE2bs9EYnuK6EEwdsA82IjhYVUAZFf 8wI3EY1PHwWQuz4uIbixUZxpoC7aKg5irML0U= 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=en1ozaJmFxUTBru2i7t875LWKaYTTn3Kbh95KbG28QHnGQaYCpzOXSVRW6p24DbGNK UOeSWPhOsFYC+CdDxEAd0lcv3mgmrX0DlazX+EUyTUNsVdDH9ljwxdW7bPK/JCHnOOVh nxVCzBoSZU2eJeEob9y3cqJ7RJaM/LnYF8eos= MIME-Version: 1.0 Received: by 10.229.220.143 with SMTP id hy15mr1153819qcb.227.1287177653827; Fri, 15 Oct 2010 14:20:53 -0700 (PDT) Received: by 10.229.61.29 with HTTP; Fri, 15 Oct 2010 14:20:53 -0700 (PDT) In-Reply-To: <20101015204207.GA87192@freebsd.org> References: <20101015204207.GA87192@freebsd.org> Date: Sat, 16 Oct 2010 01:20:53 +0400 Message-ID: From: Sergey Kandaurov To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: iostat(8) manual fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:20:55 -0000 On 16 October 2010 00:42, Alexander Best wrote: > hi there, > > the iostat(8) manual seems to contain a few errors. this patch should take care > of that. > > cheers. > alex > BTW, the existing description for -c corresponds to the old (traditional) way. iostat w - repeat each w seconds, infinity (as no repeated count specified) iostat w c - repeat each w seconds, c times -- wbr, pluknet [ Who's trying to guess where it comes from... ] From owner-freebsd-current@FreeBSD.ORG Fri Oct 15 22:15:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AC07D106566C; Fri, 15 Oct 2010 22:15:44 +0000 (UTC) Date: Fri, 15 Oct 2010 22:15:44 +0000 From: Alexander Best To: Sergey Kandaurov Message-ID: <20101015221544.GA96739@freebsd.org> References: <20101015204207.GA87192@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@freebsd.org Subject: Re: iostat(8) manual fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 22:15:44 -0000 On Sat Oct 16 10, Sergey Kandaurov wrote: > On 16 October 2010 00:42, Alexander Best wrote: > > hi there, > > > > the iostat(8) manual seems to contain a few errors. this patch should take care > > of that. > > > > cheers. > > alex > > > > BTW, the existing description for -c corresponds to the old (traditional) way. > iostat w - repeat each w seconds, infinity (as no repeated count specified) > iostat w c - repeat each w seconds, c times ah i see. the old way however is no longer documented anywhere (on purpose). i read somewhere that at some point some devs wanted to remove it, but others wanted it to stay. personally i think adding a new switch to enable legacy mode would be nice (or adding an envar). but that's just my 0,02$ cheers. alex > > -- > wbr, > pluknet > [ Who's trying to guess where it comes from... ] -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 00:06:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BECEA1065698; Sat, 16 Oct 2010 00:06:05 +0000 (UTC) Date: Sat, 16 Oct 2010 00:06:05 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20101016000605.GA21898@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: log2(), log2f() and log2l() support in freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 00:06:05 -0000 hi there, could we please have support for log2(), log2f() and log2l() in freebsd? mplayer (svn) won't build without them. netbsd has support and there are two open pr related to this matter (including patches): 82654 83845 more details here: http://www.opengroup.org/onlinepubs/9699919799/ cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 01:09: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 B0254106566C; Sat, 16 Oct 2010 01:09:44 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 991778FC13; Sat, 16 Oct 2010 01:09:44 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 148CE2282A; Fri, 15 Oct 2010 18:48:13 -0600 (MDT) Received: by night.db.net (Postfix, from userid 100) id 2288B5C97; Fri, 15 Oct 2010 20:50:17 -0400 (EDT) Date: Fri, 15 Oct 2010 20:50:17 -0400 From: Diane Bruce To: Alexander Best Message-ID: <20101016005017.GA56570@night.db.net> References: <20101016000605.GA21898@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101016000605.GA21898@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: log2(), log2f() and log2l() support in freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 01:09:44 -0000 On Sat, Oct 16, 2010 at 12:06:05AM +0000, Alexander Best wrote: > hi there, > > could we please have support for log2(), log2f() and log2l() in freebsd? I have run into a similar problem. I already started with some complex functions: http://www.freebsd.org/cgi/query-pr.cgi?pr=147599&cat= And am willing to do the work to import those log2 functions. I have already looked at the work involved. I note one reply to the PR suggesting the Apple versions might be better, but I am not sure if their licence would be compatible with FreeBSD or not. > > mplayer (svn) won't build without them. netbsd has support and there are two > open pr related to this matter (including patches): Ah ha! So the log2 work has been done already. You should have attached the PR numbers! > > 82654 > 83845 Oh.. Ok, I have seen 82654. I believe my diff should take care of that one. 83845 should be committed or the NetBSD code brought in. (Most current version of fldigi needs log2.) - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 01:25: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 5DB4A1065670; Sat, 16 Oct 2010 01:25:47 +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 3E64A8FC0A; Sat, 16 Oct 2010 01:25:47 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o9G1Pig6082227; Fri, 15 Oct 2010 18:25:44 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o9G1PiA1082226; Fri, 15 Oct 2010 18:25:44 -0700 (PDT) (envelope-from sgk) Date: Fri, 15 Oct 2010 18:25:44 -0700 From: Steve Kargl To: Diane Bruce Message-ID: <20101016012544.GA82163@troutmask.apl.washington.edu> References: <20101016000605.GA21898@freebsd.org> <20101016005017.GA56570@night.db.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101016005017.GA56570@night.db.net> User-Agent: Mutt/1.4.2.3i Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: log2(), log2f() and log2l() support in freebsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 01:25:47 -0000 On Fri, Oct 15, 2010 at 08:50:17PM -0400, Diane Bruce wrote: > On Sat, Oct 16, 2010 at 12:06:05AM +0000, Alexander Best wrote: > > hi there, > > > > could we please have support for log2(), log2f() and log2l() in freebsd? > > I have run into a similar problem. I already started with some complex > functions: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=147599&cat= See my comment in the PR. Please, do not integrate the patch from that PR into FreeBSD without testing. Make sure your tests include complex numbers z = x + iy with combinations of x and y involving -inf, +inf, nan, +0, and -0. > Oh.. Ok, I have seen 82654. I believe my diff should take care of that one. > 83845 should be committed or the NetBSD code brought in. (Most current > version of fldigi needs log2.) Well, I wrote the patch in 82654. Having had sufficient interaction with bde and das, I have tried to withdraw the patch. It simply is not a robust patch. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 02:40:10 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 C47171065674; Sat, 16 Oct 2010 02:40:10 +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 63DB88FC08; Sat, 16 Oct 2010 02:40:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9G2e9IF056094; Fri, 15 Oct 2010 22:40:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9G2e99C056093; Sat, 16 Oct 2010 02:40:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Oct 2010 02:40:09 GMT Message-Id: <201010160240.o9G2e99C056093@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 amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 02:40:10 -0000 TB --- 2010-10-15 18:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-15 18:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-10-15 18:00:00 - cleaning the object tree TB --- 2010-10-15 18:05:06 - cvsupping the source tree TB --- 2010-10-15 18:05:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-10-15 18:16:53 - building world TB --- 2010-10-15 18:16:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-15 18:16:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-15 18:16:53 - TARGET=amd64 TB --- 2010-10-15 18:16:53 - TARGET_ARCH=amd64 TB --- 2010-10-15 18:16:53 - TZ=UTC TB --- 2010-10-15 18:16:53 - __MAKE_CONF=/dev/null TB --- 2010-10-15 18:16:53 - cd /src TB --- 2010-10-15 18:16:53 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 15 18:16:55 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 >>> stage 5.1: building 32 bit shim libraries [...] building shared library libulog.so.0 ===> lib/libusbhid (all) cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -isystem /obj/src/lib32/usr/include/ -L/obj/src/lib32/usr/lib32 -B/obj/src/lib32/usr/lib32 -O2 -pipe -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 -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libusbhid/descr.c cc1: warnings being treated as errors /src/lib/libusbhid/descr.c: In function 'hid_get_report_desc': /src/lib/libusbhid/descr.c:106: warning: assignment makes integer from pointer without a cast /src/lib/libusbhid/descr.c:127: warning: assignment makes integer from pointer without a cast /src/lib/libusbhid/descr.c:136: warning: cast to pointer from integer of different size *** Error code 1 Stop in /src/lib/libusbhid. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-16 02:40:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-16 02:40:09 - ERROR: failed to build world TB --- 2010-10-16 02:40:09 - 6541.34 user 16067.55 system 31208.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 03:18:42 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 3406B106566B; Sat, 16 Oct 2010 03:18:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id B5B8D8FC18; Sat, 16 Oct 2010 03:18:41 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o9G2tORZ013662; Fri, 15 Oct 2010 19:55:24 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 9D34B2D60F1; Fri, 15 Oct 2010 11:28:21 -0700 (PDT) Message-ID: <4CB89D79.2020704@freebsd.org> Date: Fri, 15 Oct 2010 11:29:13 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: scsi@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: don't forget the open source storage summit 25th -27th SF bay area X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 03:18:42 -0000 FreeNAS will be there.. if you are going to be there, show the flag! http://nexenta-summit2010.eventbrite.com/ Julian From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 08:20:09 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 04BB9106564A for ; Sat, 16 Oct 2010 08:20:08 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (unknown [IPv6:2001:ba8:0:1d5:216:d4ff:fe0d:d845]) by mx1.freebsd.org (Postfix) with ESMTP id 8DAE48FC1D for ; Sat, 16 Oct 2010 08:20:08 +0000 (UTC) Received: from uucp by gromit.grondar.org with UUCP (Exim 4.72) (envelope-from ) id 1P71zr-0007Vs-Ho for current@freebsd.org; Sat, 16 Oct 2010 09:20:07 +0100 Received: from localhost ([127.0.0.1] helo=groundzero.grondar.org) by groundzero.grondar.org with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1P71vA-0001rI-Tv; Sat, 16 Oct 2010 09:15:16 +0100 Message-Id: To: "Bjoern A. Zeeb" In-reply-to: <20101015204947.N10185@maildrop.int.zabbadoz.net> References: <20101015191802.GA55182@wep4035.physik.uni-wuerzburg.de> <20101015204947.N10185@maildrop.int.zabbadoz.net> From: Mark Murray Date: Sat, 16 Oct 2010 09:15:16 +0100 Cc: FreeBSD current mailing list Subject: Re: Setting up IPv6 in /etc/rc.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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 Oct 2010 08:20:09 -0000 "Bjoern A. Zeeb" writes: > On Fri, 15 Oct 2010, Mark Murray wrote: > > > Alexey Shuvaev writes: > >>> gifconfig_gif0_ipv6="2001:1111:2222:3333::2 2001:1111:2222:3333::1 prefixlen 128" > >> ^^^^ ^^^^ > >> I suppose you should prefix it with "inet6" keyword. > >> There are 2 examples in rc.conf (search for "Sample IPv6"). > > > > Aaaaah! > > > > It didn't occur to me that I might need TWO inet6's! I'll give that a go when > > I play with this again tomorrow. > > It's just one inet6; put there what you would pass to ifconfig on the > command line. The fact that ifconfig defaults to "inet" is the > problem leading to more confusion. In which case, I'm back to square one. What should work doesn't. I have the necessary commands in /etc/rc.local to bring up IPv6. > I think the samples in defaults/rc.conf will be more clear soon. Cool! Thanks. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 13:22:11 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 19B50106566C; Sat, 16 Oct 2010 13:22:11 +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 B59DD8FC08; Sat, 16 Oct 2010 13:22:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o9GDM9rW028204; Sat, 16 Oct 2010 09:22:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o9GDM9PC028203; Sat, 16 Oct 2010 13:22:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 16 Oct 2010 13:22:09 GMT Message-Id: <201010161322.o9GDM9PC028203@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 powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 13:22:11 -0000 TB --- 2010-10-16 04:38:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-10-16 04:38:21 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-10-16 04:38:21 - cleaning the object tree TB --- 2010-10-16 04:41:13 - cvsupping the source tree TB --- 2010-10-16 04:41:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-10-16 04:46:15 - building world TB --- 2010-10-16 04:46:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-10-16 04:46:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-10-16 04:46:15 - TARGET=powerpc TB --- 2010-10-16 04:46:15 - TARGET_ARCH=powerpc64 TB --- 2010-10-16 04:46:15 - TZ=UTC TB --- 2010-10-16 04:46:15 - __MAKE_CONF=/dev/null TB --- 2010-10-16 04:46:15 - cd /src TB --- 2010-10-16 04:46:15 - /usr/bin/make -B buildworld >>> World build started on Sat Oct 16 04:46:17 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 >>> stage 5.1: building 32 bit shim libraries [...] building shared library libulog.so.0 ===> lib/libusbhid (all) cc -m32 -mcpu=powerpc -DCOMPAT_32BIT -isystem /obj/powerpc.powerpc64/src/lib32/usr/include/ -L/obj/powerpc.powerpc64/src/lib32/usr/lib32 -B/obj/powerpc.powerpc64/src/lib32/usr/lib32 -O2 -pipe -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 -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/lib/libusbhid/descr.c cc1: warnings being treated as errors /src/lib/libusbhid/descr.c: In function 'hid_get_report_desc': /src/lib/libusbhid/descr.c:106: warning: assignment makes integer from pointer without a cast /src/lib/libusbhid/descr.c:127: warning: assignment makes integer from pointer without a cast /src/lib/libusbhid/descr.c:136: warning: cast to pointer from integer of different size *** Error code 1 Stop in /src/lib/libusbhid. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-10-16 13:22:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-10-16 13:22:09 - ERROR: failed to build world TB --- 2010-10-16 13:22:09 - 4471.26 user 15523.79 system 31428.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full