From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 01:25:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19DBEBC2 for ; Sun, 17 Mar 2013 01:25:37 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id AF393AFF for ; Sun, 17 Mar 2013 01:25:35 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 12358340 for freebsd-stable@freebsd.org; Sat, 16 Mar 2013 20:25:29 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Sat, 16 Mar 2013 20:25:29 -0500 Message-ID: In-Reply-To: <20130315001321.K32142@sola.nimnet.asn.au> References: <513E2DA5.70200@mac.com> <20130313152150.E32142@sola.nimnet.asn.au> <20130315001321.K32142@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 01:25:37 -0000 On Sun, 17 Mar 2013 02:14:30 +1100 (EST)  Ian Smith wrote: > On Wed, 13 Mar 2013 21:11:28 -0500, John Mehr wrote: > > On Wed, 13 Mar 2013 16:29:45 +1100 (EST) > >  Ian Smith wrote: > svn0.us-west.freebsd.org as per example, but it's the >closest to here > anyway; pings avg 217.5ms stddev 0.4ms, us-east avg >269.3ms sd 9.5ms. > fastest_cvsup used to find cvs mirrors in Australia at >around 55-70ms, > so for another while I thought RTT might be the issue - >but it's not. I'm seeing ~110ms pings to svn0.us-west.freebsd.org. > > > I'll definitely put in a verbosity level that does >exactly what you suggest.  > > Sorry about that. > > Not at all, and thanks!  But neither, I now find, is >logging the extra > time issue; as mentioned elsewhere, running at -v0 makes >next to no > difference, 12:48 west vs 12:54 east on 4 do-nothing >runs, 700KB/s link, > not running in script(1) - though I think that matters >not, or little. > > So I began watching top more closely, also running >iostat -w10, noticing > that svnup was pegging CPU at 100% with ~75% _system_? >time for nearly 9 > minutes of the run, doing little or no disk I/O and a >max of 130KB/s in, > 22.6KB/s out, no stress there, growing to ~20MB >resident, then doing a > flurry of disk I/O at about 3-5MB/s for the last 3m40s >odd.  IOW, svnup > here is mostly heavily CPU-bound, which I don't >understand, but then I > know nothing about what level of computation the >protocol demands. Except for the time duration of the run, the behavior you're describing is normal.  Using the svn protocol, the program runs in three phases: 1) It issues a series of get-dir commands to the server to get a list of all the files/directories in the repository and stores the structure in memory.  There is some disk activity during this as it creates the directory tree (it uses one lstat per directory and creates the directory if it doesn't exist).  On my development machine, this phase takes about 25% of the total time of a do-nothing run. 2) Because the svn protocol doesn't include MD5 signatures and the last-author/committed date/committed revision fields in the results of the get-dir commands although they *are* included in the http protocol responses it has to issue a get-file request for each file to get this information.  This phase takes about 50% of the total time of a do-nothing run. 3) The downloaded MD5 signatures are for versions of the files that do not have their $FreeBSD$ tags expanded, so each file on the local machine must be loaded into memory and have their $FreeBSD: ... $ tags collapsed and MD5 summed to see if there's a match.  If there's no match, the file on the server is downloaded.  This phase takes up the remaining 25% and is I/O intensive. This three step process is further complicated because of the huge time penalty that occurs when sending commands one-at-a-time.  To get around this, as many commands that can fit in 32KB are grouped together and sent in bulk. > I've done some more controlled tests since, running both >iostat -w10 and > netstat -w10 -dn before, during and until a bit after >the run, attached, > hoping these might help pinpoint any bottlenecks?  This >was running -v1 > default verbosity, hence the (not at all heavy) tty >output numbers. > > Just sometimes, running slower hardware can have >advantages!  On your > times, yours likely has more than 500% of my single-core >P3-M's 1133MHz > performance, which would tend to mask this issue pretty >well for you :) I do all of my development and test runs on a nettop with an AMD E-350 (dual core, 1.6GHz) processor, and with the program only utilizing one core I'd be willing to bet the two chips are in roughly the same league.  Memory and hard drives probably aren't, and with 512MB of memory, how does your swap utilization look? As soon as I can get a replacement CMOS battery, I'll be dusting off my old Athlon 2700+ system to run tests on it. > John Baldwin has best described when c{,v}sup deletes >(only in-tree) > files, covered in section 'delete' in csup(1).  I think >this should > probably be default behaviour, even if svn proper would >do otherwise. Will do.  Setting up both a default of deleting only files that appear in previous checkouts plus giving each user the option of skipping specific directories from any pruning is on the to-do list.  Thanks! > > cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:05:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 398A3C90 for ; Sun, 17 Mar 2013 12:05:21 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AB6BBDF9 for ; Sun, 17 Mar 2013 12:05:20 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HC53cc016821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 22:35:08 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Mar 2013 22:35:02 +1030 Subject: Functional KDE desktop To: "freebsd-stable@freebsd.org stable" Message-Id: <2B43A76D-345F-4FE1-86A5-680BC3318423@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:05:21 -0000 Hi, I am in the process of upgrading all the ports on a 9.1-PRERELEASE = system and I am having a lot of trouble building or running KDE 4.9.5. I couldn't build it due to x11/xsd not building (didn't make a necessary = header), or if I worked around that libkonq was not found by cmake. If I = manage to work around that I get an error dialogue when logging in. In the end I gave up and installed packages (version 4.8.4) however that = does work as startkde gives.. [midget 22:10] ~ >env PATH=3D$PATH:/usr/local/kde4/bin = /usr/local/kde4/bin/startkde xset: bad font path element (#12), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax startkde: Starting up... /usr/local/lib/libkdeui.so.7: Undefined symbol = "_ZN6Attica15ProviderManagerC1ERK6QFlagsINS0_12ProviderFlagEE" startkde: Could not start kdeinit4. Check your installation. c++filt says this symbol is.. = Attica::ProviderManager::ProviderManager(QFlags const&) Also, the startkde script does not set the pass so it never finds = kcheckrunning. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:07:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF2DEDD5 for ; Sun, 17 Mar 2013 12:07:23 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5764EE2C for ; Sun, 17 Mar 2013 12:07:22 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HC784D016922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 22:37:15 +1030 (CST) (envelope-from darius@dons.net.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Mar 2013 22:37:08 +1030 Subject: =?windows-1252?Q?What_is_the_Right_Way=28=99=29_to_run_X=3F?= To: "freebsd-stable@freebsd.org stable" Message-Id: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:07:23 -0000 Hi, I recently updated my 9.1-PRE system's ports and my previous X config = now results in no mouse (but the keyboard does work). I found that I needed to add the following.. Section "ServerFlags" Option "AllowEmptyInput" "False" EndSection I am pretty sure this used to be necessary, then wasn't, but now seems = required again.. =46rom what I can see this means a 'startx' with no = config is broken which is a bit of a step backwards. BTW I have dbus & hald running. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:14:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B66F5F94 for ; Sun, 17 Mar 2013 12:14:44 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 73181E65 for ; Sun, 17 Mar 2013 12:14:44 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so4771232oag.38 for ; Sun, 17 Mar 2013 05:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jVLBVaLg69uX/DiyAY78kvEZ68NdYPRRLGG4acNaTPk=; b=h6oJsyXF6EETRpHGGAFMs6RAsCPkfez7jLZ+Qi0QlEGw1CDgJvUtUERWKv1PVjsDIr xY1h/fpXcgFIdRPuW0uVOAEabodvEhyBJQTuP+PL270nfRC2O3DsL/WeRC52gEYv0ffJ dsS/yODk8joKSzoDpmFIGr1WQ+wrCTwOn2LLHXEoUN/dpH+8jQLigRJwuOTmXquljnom YTwerhE8rV/9uhonycORGBEc3wq14I6zlY/uu1xr8DVB9onIBUC9UOo3gJjk4UXb0HMH 2SpuZkR+MT6ShLrJhevFvhkmofYtp1j0qG2KNc/I191CVF8rhYlDWofN7+Gv4XMYAygz Ny8g== MIME-Version: 1.0 X-Received: by 10.182.98.44 with SMTP id ef12mr5512332obb.25.1363522478501; Sun, 17 Mar 2013 05:14:38 -0700 (PDT) Received: by 10.76.94.12 with HTTP; Sun, 17 Mar 2013 05:14:38 -0700 (PDT) In-Reply-To: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> Date: Sun, 17 Mar 2013 13:14:38 +0100 Message-ID: Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X=3F?= From: Andreas Nilsson To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:14:44 -0000 On Sun, Mar 17, 2013 at 1:07 PM, Daniel O'Connor wrote: > Hi, > I recently updated my 9.1-PRE system's ports and my previous X config now > results in no mouse (but the keyboard does work). > > I found that I needed to add the following.. > Section "ServerFlags" > Option "AllowEmptyInput" "False" > EndSection > > I am pretty sure this used to be necessary, then wasn't, but now seems > required again.. From what I can see this means a 'startx' with no config > is broken which is a bit of a step backwards. > > BTW I have dbus & hald running. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > On my intel-based systems there is no xorg.conf and on my nVidia-systems there is one, but it contains only: Section "Device" Identifier "nvidia" Driver "nvidia" Option "NoLogo" "true" EndSection Section "Screen" Identifier "default screen" Device "nvidia" EndSection so I think your setup is somehow broken. You didn't mention which version of xorg you are using. Does lshal show any inputdevices? Have you tried to do the build from a clean environment? Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:17:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7D8F912B for ; Sun, 17 Mar 2013 12:17:22 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ia0-x22d.google.com (mail-ia0-x22d.google.com [IPv6:2607:f8b0:4001:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDDAE80 for ; Sun, 17 Mar 2013 12:17:22 +0000 (UTC) Received: by mail-ia0-f173.google.com with SMTP id h37so4510337iak.4 for ; Sun, 17 Mar 2013 05:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xboBxQkkOxmeZ8CcqMCpwbYjqjfdvtOhXQWdla6OWxs=; b=l6QKYE5OuuY0PYf8hrX7cUhZ0k2bugJ/KGgAfj4pvI6omoSgRjvxmjmE9ztrRjWacr emERWPPc3mUDgN5M3dvZudo44hP9syG5PLON4/wIoTF3EoFzoMiIpOXaeaq4mfWLDTTe hfz8mBdQwMtoh6889DpauhFAjCzYVszdtmpWShH+ccgQ+X2LQ3VYH79uR1lni3At/xHq LXA/ofewIwakZ6hkHQPDrcheIEanbeyYyXeFPUfT/m2oMr/Ir5X/Nyy/51N6+NM34UhZ qf/x+Qmr1kDvM6fjO8ZFI6PRCtdLshF0W5lShKoks86ADEJof/h/P3gKkqT69XPzSmJR SZVQ== MIME-Version: 1.0 X-Received: by 10.50.197.170 with SMTP id iv10mr4486095igc.62.1363522641969; Sun, 17 Mar 2013 05:17:21 -0700 (PDT) Received: by 10.64.63.12 with HTTP; Sun, 17 Mar 2013 05:17:21 -0700 (PDT) Received: by 10.64.63.12 with HTTP; Sun, 17 Mar 2013 05:17:21 -0700 (PDT) In-Reply-To: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> Date: Sun, 17 Mar 2013 12:17:21 +0000 Message-ID: Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X=3F?= From: Chris Rees To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:17:22 -0000 On 17 Mar 2013 12:07, "Daniel O'Connor" wrote: > > Hi, > I recently updated my 9.1-PRE system's ports and my previous X config now results in no mouse (but the keyboard does work). > > I found that I needed to add the following.. > Section "ServerFlags" > Option "AllowEmptyInput" "False" > EndSection > > I am pretty sure this used to be necessary, then wasn't, but now seems required again.. From what I can see this means a 'startx' with no config is broken which is a bit of a step backwards. > > BTW I have dbus & hald running. Have you read http://www.wonkity.com/~wblock/docs/html/aei.html ? Chris From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:18:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F595232 for ; Sun, 17 Mar 2013 12:18:05 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C10B7E98 for ; Sun, 17 Mar 2013 12:18:04 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HCHm90017528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 22:47:53 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X?= =?windows-1252?Q?=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Sun, 17 Mar 2013 22:47:47 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> To: Andreas Nilsson X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:18:05 -0000 On 17/03/2013, at 22:44, Andreas Nilsson wrote: > so I think your setup is somehow broken. You didn't mention which = version of xorg you are using. Very possibly :) I have xorg-server 1.7.7_6,1 > Does lshal show any inputdevices? I see the following.. udi =3D '/org/freedesktop/Hal/devices/atkbdc_0' freebsd.driver =3D 'atkbdc' (string) freebsd.unit =3D 0 (0x0) (int) info.parent =3D '/org/freedesktop/Hal/devices/computer' (string) info.product =3D 'Keyboard controller (i8042)' (string) info.subsystem =3D 'platform' (string) info.udi =3D '/org/freedesktop/Hal/devices/atkbdc_0' (string) platform.id =3D 'atkbdc.0' (string) pnp.description =3D 'IBM Enhanced (101/102-key, PS/2 mouse support)' = (string) pnp.id =3D 'PNP0303' (string) udi =3D '/org/freedesktop/Hal/devices/atkbd_0' freebsd.device_file =3D '/dev/atkbd0' (string) freebsd.driver =3D 'atkbd' (string) freebsd.unit =3D 0 (0x0) (int) info.addons.singleton =3D {'hald-addon-input'} (string list) info.capabilities =3D {'input', 'input.keyboard', 'input.keys', = 'button'} (string list) info.category =3D 'input' (string) info.parent =3D '/org/freedesktop/Hal/devices/atkbdc_0' (string) info.product =3D 'AT Keyboard' (string) info.subsystem =3D 'platform' (string) info.udi =3D '/org/freedesktop/Hal/devices/atkbd_0' (string) input.device =3D '' (string) input.x11_driver =3D 'kbd' (string) platform.id =3D 'atkbd.0' (string) > Have you tried to do the build from a clean environment? Not really, I can't just nuke the existing packages and do an install (I = suppose I could do it in a chroot). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:20:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A5D094D4 for ; Sun, 17 Mar 2013 12:20:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3358CEC5 for ; Sun, 17 Mar 2013 12:19:59 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HCJjTt017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 22:49:51 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X?= =?windows-1252?Q?=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Sun, 17 Mar 2013 22:49:45 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <6B9C5E11-D493-4C9F-BFDC-0D6D07578093@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> To: Chris Rees X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:20:00 -0000 On 17/03/2013, at 22:47, Chris Rees wrote: > > BTW I have dbus & hald running. >=20 > Have you read http://www.wonkity.com/~wblock/docs/html/aei.html ? I have read it in the past. I _am_ running hald and am happy to do so, but it now appears broken = (this system did not need AEI until I updated last week). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:22:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FD965D8 for ; Sun, 17 Mar 2013 12:22:33 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D31D0EDF for ; Sun, 17 Mar 2013 12:22:32 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HCMHkS017759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 22:52:23 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X?= =?windows-1252?Q?=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Sun, 17 Mar 2013 22:52:17 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <24DCFAAE-44F3-439E-8214-FF5FA3DC400C@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> To: Andreas Nilsson X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:22:33 -0000 On 17/03/2013, at 22:47, "Daniel O'Connor" wrote: >> Does lshal show any inputdevices? >=20 > I see the following.. Oops, I just pasted the keyboard entries instead of the mouse ones.. udi =3D '/org/freedesktop/Hal/devices/usb_device_46d_c404_noserial_if0' freebsd.device_file =3D '/dev/ums1' (string) freebsd.driver =3D 'ums' (string) freebsd.unit =3D 1 (0x1) (int) info.addons =3D {'hald-addon-mouse-sysmouse'} (string list) info.bus =3D 'usb' (string) info.capabilities =3D {'input', 'input.mouse'} (string list) info.category =3D 'input' (string) info.parent =3D = '/org/freedesktop/Hal/devices/usb_device_46d_c404_noserial' (string) info.product =3D 'Trackball' (string) info.subsystem =3D 'usb' (string) info.udi =3D = '/org/freedesktop/Hal/devices/usb_device_46d_c404_noserial_if0' = (string) info.vendor =3D 'Logitech' (string) input.device =3D '/dev/sysmouse' (string) usb.bus_number =3D 2 (0x2) (int) usb.can_wake_up =3D true (bool) usb.configuration =3D '' (string) usb.configuration_value =3D 1 (0x1) (int) usb.device_class =3D 0 (0x0) (int) usb.device_protocol =3D 0 (0x0) (int) usb.device_revision_bcd =3D 544 (0x220) (int) usb.device_subclass =3D 0 (0x0) (int) usb.freebsd.devname =3D 'ums1' (string) usb.interface.class =3D 3 (0x3) (int) usb.interface.description =3D '' (string) usb.interface.number =3D 0 (0x0) (int) usb.interface.protocol =3D 2 (0x2) (int) usb.interface.subclass =3D 1 (0x1) (int) usb.is_self_powered =3D false (bool) usb.level_number =3D 1 (0x1) (int) usb.max_power =3D 100 (0x64) (int) usb.num_configurations =3D 1 (0x1) (int) usb.num_interfaces =3D 1 (0x1) (int) usb.num_ports =3D 0 (0x0) (int) usb.port_number =3D 4 (0x4) (int) usb.product =3D 'Trackball' (string) usb.product_id =3D 50180 (0xc404) (int) usb.serial =3D '' (string) usb.speed =3D 1.5 (1.5) (double) usb.speed_bcd =3D 336 (0x150) (int) usb.vendor =3D 'Logitech' (string) usb.vendor_id =3D 1133 (0x46d) (int) usb.version =3D 1.0 (1) (double) udi =3D '/org/freedesktop/Hal/devices/usb_device_46d_c012_noserial_if0' freebsd.device_file =3D '/dev/ums0' (string) freebsd.driver =3D 'ums' (string) freebsd.unit =3D 0 (0x0) (int) info.addons =3D {'hald-addon-mouse-sysmouse'} (string list) info.bus =3D 'usb' (string) info.capabilities =3D {'input', 'input.mouse'} (string list) info.category =3D 'input' (string) info.parent =3D = '/org/freedesktop/Hal/devices/usb_device_46d_c012_noserial' (string) info.product =3D 'USB-PS2 Optical Mouse' (string) info.subsystem =3D 'usb' (string) info.udi =3D = '/org/freedesktop/Hal/devices/usb_device_46d_c012_noserial_if0' = (string) info.vendor =3D 'Logitech' (string) input.device =3D '/dev/sysmouse' (string) usb.bus_number =3D 2 (0x2) (int) usb.can_wake_up =3D true (bool) usb.configuration =3D '' (string) usb.configuration_value =3D 1 (0x1) (int) usb.device_class =3D 0 (0x0) (int) usb.device_protocol =3D 0 (0x0) (int) usb.device_revision_bcd =3D 4896 (0x1320) (int) usb.device_subclass =3D 0 (0x0) (int) usb.freebsd.devname =3D 'ums0' (string) usb.interface.class =3D 3 (0x3) (int) usb.interface.description =3D '' (string) usb.interface.number =3D 0 (0x0) (int) usb.interface.protocol =3D 2 (0x2) (int) usb.interface.subclass =3D 1 (0x1) (int) usb.is_self_powered =3D false (bool) usb.level_number =3D 1 (0x1) (int) usb.max_power =3D 98 (0x62) (int) usb.num_configurations =3D 1 (0x1) (int) usb.num_interfaces =3D 1 (0x1) (int) usb.num_ports =3D 0 (0x0) (int) usb.port_number =3D 3 (0x3) (int) usb.product =3D 'USB-PS2 Optical Mouse' (string) usb.product_id =3D 49170 (0xc012) (int) usb.serial =3D '' (string) usb.speed =3D 1.5 (1.5) (double) usb.speed_bcd =3D 336 (0x150) (int) usb.vendor =3D 'Logitech' (string) usb.vendor_id =3D 1133 (0x46d) (int) usb.version =3D 2.0 (2) (double) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:30:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 857EA964 for ; Sun, 17 Mar 2013 12:30:45 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 4A930F2B for ; Sun, 17 Mar 2013 12:30:45 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id x4so4545744obh.2 for ; Sun, 17 Mar 2013 05:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TPtbXqEUTn7vTzrfOzZ/xDGWQDaurrDetEXBOvWN4jg=; b=oztUQVTthA4BjfkdF9PbDXz7pFa5xAeWBTzxGxrViIKwHYVHBtNT6O3BRslY1QrXHZ jX01lT2nfMWt+Pd1OvEBWx51s0iuUaKMa3c7HotHJsL4MppncEs/nWinEhBWJK3h00Yn FvfpNU/jSpAHFYpOi8d2vgn7QzOMOdylLr7W9n0PDdInNLsaSj4XzCEp0u99DktyOBSF egYWKb9XbUQwU/AI5cVzjN+RfTgnBWJCf4ymnAtfDo2Z22z+3tx4JRni9/vJ9LI6nTeO WuA4Ivwy8iVpuVkk7KjWk1d5uNFYkS7u3ywGnpkx6HIPZ0zXDRdSIfIyNDiY9KSDAPLS L9xA== MIME-Version: 1.0 X-Received: by 10.182.151.9 with SMTP id um9mr5456262obb.89.1363523444829; Sun, 17 Mar 2013 05:30:44 -0700 (PDT) Received: by 10.76.94.12 with HTTP; Sun, 17 Mar 2013 05:30:44 -0700 (PDT) In-Reply-To: References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> Date: Sun, 17 Mar 2013 13:30:44 +0100 Message-ID: Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X=3F?= From: Andreas Nilsson To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:30:45 -0000 On Sun, Mar 17, 2013 at 1:17 PM, Daniel O'Connor wrote: > > On 17/03/2013, at 22:44, Andreas Nilsson wrote: > > so I think your setup is somehow broken. You didn't mention which > version of xorg you are using. > > Very possibly :) > I have xorg-server 1.7.7_6,1 > > > Does lshal show any inputdevices? > > I see the following.. > > udi = '/org/freedesktop/Hal/devices/atkbdc_0' > freebsd.driver = 'atkbdc' (string) > freebsd.unit = 0 (0x0) (int) > info.parent = '/org/freedesktop/Hal/devices/computer' (string) > info.product = 'Keyboard controller (i8042)' (string) > info.subsystem = 'platform' (string) > info.udi = '/org/freedesktop/Hal/devices/atkbdc_0' (string) > platform.id = 'atkbdc.0' (string) > pnp.description = 'IBM Enhanced (101/102-key, PS/2 mouse support)' > (string) > pnp.id = 'PNP0303' (string) > > udi = '/org/freedesktop/Hal/devices/atkbd_0' > freebsd.device_file = '/dev/atkbd0' (string) > freebsd.driver = 'atkbd' (string) > freebsd.unit = 0 (0x0) (int) > info.addons.singleton = {'hald-addon-input'} (string list) > info.capabilities = {'input', 'input.keyboard', 'input.keys', 'button'} > (string list) > info.category = 'input' (string) > info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string) > info.product = 'AT Keyboard' (string) > info.subsystem = 'platform' (string) > info.udi = '/org/freedesktop/Hal/devices/atkbd_0' (string) > input.device = '' (string) > input.x11_driver = 'kbd' (string) > platform.id = 'atkbd.0' (string) > Looks promising. Just to make sure, have you verified that hald is still running? Things can crash... > > > > Have you tried to do the build from a clean environment? > > Not really, I can't just nuke the existing packages and do an install (I > suppose I could do it in a chroot). > That is a problem yes. Have you considered using poudriere to build packages? It is rather nice, it can build old-school and new-school packages, and is very configurable. It does require zfs though ;) > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:38:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 615A2B86 for ; Sun, 17 Mar 2013 12:38:16 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3718DF67 for ; Sun, 17 Mar 2013 12:38:15 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 0747637B65C; Sun, 17 Mar 2013 07:38:09 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3ZTKnD2YKzzQ6s; Sun, 17 Mar 2013 07:38:08 -0500 (CDT) Date: Sun, 17 Mar 2013 07:38:08 -0500 From: "Matthew D. Fuller" To: Daniel O'Connor Subject: Re: What is the Right =?utf-8?Q?Way=28?= =?utf-8?B?4oSiKQ==?= to run X? Message-ID: <20130317123808.GH53758@over-yonder.net> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:38:16 -0000 On Sun, Mar 17, 2013 at 10:37:08PM +1030 I heard the voice of Daniel O'Connor, and lo! it spake thus: > Hi, > I recently updated my 9.1-PRE system's ports and my previous X > config now results in no mouse (but the keyboard does work). > > I found that I needed to add the following.. > Section "ServerFlags" > Option "AllowEmptyInput" "False" > EndSection I think general wisdom is that AEI is a Bad Idea for various reasons that I don't remember, but seemed reasonable when I read them. However, some time back, X _did_ start being all stupid about finding the mouse for me. Un/re-plugging it (USB) after starting X made it show up working, but that's annoying and stupid (and not an option on other systems with e.g. PS/2 meece). I wound up sticking the "other half" of that oft-cargo-culted incantation: Section "ServerFlags" Option "AutoAddDevices" "off" EndSection in my config, and it's worked OK since. 's probably worth a try... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:56:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 095DAEF1 for ; Sun, 17 Mar 2013 12:56:33 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6CBE8FE4 for ; Sun, 17 Mar 2013 12:56:31 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HCuBkB019573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 23:26:17 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X?= =?windows-1252?Q?=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: Date: Sun, 17 Mar 2013 23:26:11 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <5DDB125E-A850-431C-B036-69EE9A0AAAED@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> To: Andreas Nilsson X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:56:33 -0000 On 17/03/2013, at 23:00, Andreas Nilsson wrote: > Looks promising. Just to make sure, have you verified that hald is = still running? Things can crash...=20 Yep, it's still running. >> > Have you tried to do the build from a clean environment? >=20 >> Not really, I can't just nuke the existing packages and do an install = (I suppose I could do it in a chroot). >=20 > That is a problem yes. Have you considered using poudriere to build = packages? It is rather nice, it can build old-school and new-school = packages, and is very configurable. It does require zfs though ;) I am using ZFS, I'll take a look :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 12:59:19 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A0FE6B for ; Sun, 17 Mar 2013 12:59:19 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AD22773 for ; Sun, 17 Mar 2013 12:59:17 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HCx0cF019675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Mar 2013 23:29:06 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X?= =?windows-1252?Q?=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20130317123808.GH53758@over-yonder.net> Date: Sun, 17 Mar 2013 23:28:59 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <6ABF0997-2E53-46E2-9AA1-F5AE7E16D080@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> <20130317123808.GH53758@over-yonder.net> To: "Matthew D. Fuller" X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 12:59:19 -0000 On 17/03/2013, at 23:08, "Matthew D. Fuller" = wrote: > However, some time back, X _did_ start being all stupid about finding > the mouse for me. Un/re-plugging it (USB) after starting X made it > show up working, but that's annoying and stupid (and not an option on > other systems with e.g. PS/2 meece). I wound up sticking the "other > half" of that oft-cargo-culted incantation: >=20 > Section "ServerFlags" > Option "AutoAddDevices" "off" > EndSection >=20 > in my config, and it's worked OK since. 's probably worth a try... Yeah, that does work too. It's just annoying it's necessary :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 14:28:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC77DD0D for ; Sun, 17 Mar 2013 14:28:18 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mx1.freebsd.org (Postfix) with ESMTP id A4DCF350 for ; Sun, 17 Mar 2013 14:28:18 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id i18so4883160oag.1 for ; Sun, 17 Mar 2013 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y7x8kDGEQVHU9rKCce66h9YbkJjoaNyeGhVXLWtC+6M=; b=c2m06uSk5a6Q9ZnrcOeRQtipORSWelxq8ygj0MVji64SlyiY1gdrIDQsx2Jj+XQO1t YtFvOIfPO8EbgexMIXspviu95fM5FlpHtx0nwwsDerM5JVESUNIkt4Uc/rkKb0pa5CWZ 6x+CTWWR4T/cKDn3iD7s8TSKyEK9zAgWV0HlnMQU8SSEHx1jwtPtgq7cQpmzQaSnHLpB JiCsDIEMd4W7eccQDqwVO8H7GNx8JJYxOfDS8tQELK78U4kzBS7Bz7G9IuxKy45WLGzV SbqPCEO+IP9fHPby4ZTc367Sj6dito/tabZnu6cqldZu1vXB1eCFg1TLnGRILEnMWmbv fj/Q== MIME-Version: 1.0 X-Received: by 10.60.31.193 with SMTP id c1mr5524792oei.63.1363530492543; Sun, 17 Mar 2013 07:28:12 -0700 (PDT) Received: by 10.76.94.12 with HTTP; Sun, 17 Mar 2013 07:28:12 -0700 (PDT) In-Reply-To: <6ABF0997-2E53-46E2-9AA1-F5AE7E16D080@dons.net.au> References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> <20130317123808.GH53758@over-yonder.net> <6ABF0997-2E53-46E2-9AA1-F5AE7E16D080@dons.net.au> Date: Sun, 17 Mar 2013 15:28:12 +0100 Message-ID: Subject: =?windows-1252?Q?Re=3A_What_is_the_Right_Way=28=99=29_to_run_X=3F?= From: Andreas Nilsson To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org stable" , "Matthew D. Fuller" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 14:28:19 -0000 On Sun, Mar 17, 2013 at 1:58 PM, Daniel O'Connor wrote: > > On 17/03/2013, at 23:08, "Matthew D. Fuller" > wrote: > > However, some time back, X _did_ start being all stupid about finding > > the mouse for me. Un/re-plugging it (USB) after starting X made it > > show up working, but that's annoying and stupid (and not an option on > > other systems with e.g. PS/2 meece). I wound up sticking the "other > > half" of that oft-cargo-culted incantation: > > > > Section "ServerFlags" > > Option "AutoAddDevices" "off" > > EndSection > > > > in my config, and it's worked OK since. 's probably worth a try... > > > Yeah, that does work too. It's just annoying it's necessary :) > Sure is. One thing that also comes to mind is moused. Do you have it running? I seem to remember having weird troubles when moused wasn't running. Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 15:06:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E72A772 for ; Sun, 17 Mar 2013 15:06:25 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3A033664 for ; Sun, 17 Mar 2013 15:06:25 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r2HF69jS008607; Sun, 17 Mar 2013 09:06:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r2HF69LJ008604; Sun, 17 Mar 2013 09:06:09 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 17 Mar 2013 09:06:09 -0600 (MDT) From: Warren Block To: "Matthew D. Fuller" Subject: =?UTF-8?Q?Re=3A_What_is_the_Right_Way=28=E2=84=A2=29_to_run_X=3F?= In-Reply-To: <20130317123808.GH53758@over-yonder.net> Message-ID: References: <82EEB5DC-DD57-4EC3-936A-2F28C4BAF0B4@dons.net.au> <20130317123808.GH53758@over-yonder.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Sun, 17 Mar 2013 09:06:09 -0600 (MDT) Cc: Daniel O'Connor , "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 15:06:25 -0000 On Sun, 17 Mar 2013, Matthew D. Fuller wrote: > On Sun, Mar 17, 2013 at 10:37:08PM +1030 I heard the voice of > Daniel O'Connor, and lo! it spake thus: >> Hi, >> I recently updated my 9.1-PRE system's ports and my previous X >> config now results in no mouse (but the keyboard does work). >> >> I found that I needed to add the following.. >> Section "ServerFlags" >> Option "AllowEmptyInput" "False" >> EndSection > > I think general wisdom is that AEI is a Bad Idea for various reasons > that I don't remember, but seemed reasonable when I read them. > > However, some time back, X _did_ start being all stupid about finding > the mouse for me. Un/re-plugging it (USB) after starting X made it > show up working, but that's annoying and stupid (and not an option on > other systems with e.g. PS/2 meece). I wound up sticking the "other > half" of that oft-cargo-culted incantation: > > Section "ServerFlags" > Option "AutoAddDevices" "off" > EndSection > > in my config, and it's worked OK since. 's probably worth a try... Both options were used to tell X not to use hal for input device detection. AEI was misused for that, but kind of worked while causing other problems. Turning off AutoAddDevices is the good way that does not cause other problems. Even better is just to deinstall hal. I believe it is still required by Gnome and KDE, but xfce runs fine without it. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 16:40:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B150FD51 for ; Sun, 17 Mar 2013 16:40:27 +0000 (UTC) (envelope-from pulley@dabus.com) Received: from aegir.dabus.com (aegir.dabus.com [173.14.229.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2BF935 for ; Sun, 17 Mar 2013 16:40:27 +0000 (UTC) Received: from aegir.dabus.com (localhost [127.0.0.1]) by aegir.dabus.com (Processor) with ESMTP id 49C125F312 for ; Sun, 17 Mar 2013 10:32:07 -0600 (MDT) DomainKey-Signature: a=rsa-sha1; b=XoUF6QRGj67XdeZ8d+BbrxD13R8lN/4UdVASXrYpiES3xsHN20cJbnwg5MK0nN5uCCq4H6wAfxOtIHXLxX8npThn9F3U+pfZ6xyGvVgn8MN0dHoml6XC5yFIFejSYKaT9dXk81dZ7LaqcyK5mIJdHuZnPpWh2g8L4T7J2fjflWA=; c=nofws; d=dabus.com; q=dns; s=aegir1 Received: from aldebaran.dabus.com (unknown [192.168.10.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by aegir.dabus.com (Dabus) with ESMTPSA id 77D185F30B for ; Sun, 17 Mar 2013 10:32:06 -0600 (MDT) Date: Sun, 17 Mar 2013 10:32:05 -0600 From: Eric S Pulley To: freebsd-stable@freebsd.org Subject: Re: Functional KDE desktop Message-ID: <20130317103205.3dcefc7e@aldebaran.dabus.com> In-Reply-To: <2B43A76D-345F-4FE1-86A5-680BC3318423@gsoft.com.au> References: <2B43A76D-345F-4FE1-86A5-680BC3318423@gsoft.com.au> Organization: Dabus X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:40:27 -0000 On Sun, 17 Mar 2013 22:35:02 +1030 "Daniel O'Connor" wrote: > Hi, > I am in the process of upgrading all the ports on a 9.1-PRERELEASE > system and I am having a lot of trouble building or running KDE 4.9.5. > > I couldn't build it due to x11/xsd not building (didn't make a > necessary header), or if I worked around that libkonq was not found > by cmake. If I manage to work around that I get an error dialogue > when logging in. > > In the end I gave up and installed packages (version 4.8.4) however > that does work as startkde gives.. [midget 22:10] ~ >env > PATH=$PATH:/usr/local/kde4/bin /usr/local/kde4/bin/startkde xset: > bad font path element (#12), possible causes are: Directory does not > exist or has wrong permissions Directory missing fonts.dir > Incorrect font server address or syntax > startkde: Starting up... > /usr/local/lib/libkdeui.so.7: Undefined symbol > "_ZN6Attica15ProviderManagerC1ERK6QFlagsINS0_12ProviderFlagEE" > startkde: Could not start kdeinit4. Check your installation. > > c++filt says this symbol is.. > Attica::ProviderManager::ProviderManager(QFlags > const&) > > Also, the startkde script does not set the pass so it never finds > kcheckrunning. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > I have it working fine here. I originally was using it on 9.0 then I upgraded everything but that didn't work well for the KDE 4.8->4.9 update in ports. Too many ports were split and moved around so I ended up removing all ports and remaking them all. One big gotcha is make sure you force a reconfigure on everything. My small nightmare was kdepim,kdepim-runtime and kdepimlibs there are now two deferment types of PIM you can built the old "4.8 style" and the new. Make sure you are consistent as these packages are deps for many others. For a while I was still picking up settings for the old style and it was breaking all over the place. If you want I can send you a list of all the stuff I have installed off list and you can see if you're somehow missing important bits... From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 18:55:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E28416CC for ; Sun, 17 Mar 2013 18:55:36 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2A2DEA for ; Sun, 17 Mar 2013 18:55:36 +0000 (UTC) To: freebsd-stable@freebsd.org Subject: 9.1-stable mergemaster -D fails Date: Sun, 17 Mar 2013 11:45:59 -0700 From: John Message-Id: <20130317184559.C3E48DBD@server.theusgroup.com> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: john@TheUsGroup.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:55:36 -0000 running 9.1-STABLE r247548 updating to 9.1-STABLE r248381 When updating to the new version in a zfs beadm environment, mergemaster -D /mnt fails with install: illegal option -- l install (1) in the new version has an added -l switch which is used in bsd.own.mk which in turn is used by mergemaster. Making mergemaster use the new install(1) fixes the problem. John Theus TheUsGroup.com From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 22:25:15 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6BCF490 for ; Sun, 17 Mar 2013 22:25:15 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4A46CE for ; Sun, 17 Mar 2013 22:25:15 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r2HMOg25013615; Sun, 17 Mar 2013 14:24:46 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201303172224.r2HMOg25013615@gw.catspoiler.org> Date: Sun, 17 Mar 2013 15:24:42 -0700 (PDT) From: Don Lewis Subject: =?iso-2022-jp?Q?Re:_What_is_the_Right_Way(=1B$(D"o=1B(B)_to_run?= X? To: andrnils@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: darius@dons.net.au, freebsd-stable@FreeBSD.org, fullermd@over-yonder.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:25:15 -0000 On 17 Mar, Andreas Nilsson wrote: > On Sun, Mar 17, 2013 at 1:58 PM, Daniel O'Connor wrote: > >> >> On 17/03/2013, at 23:08, "Matthew D. Fuller" >> wrote: >> > However, some time back, X _did_ start being all stupid about finding >> > the mouse for me. Un/re-plugging it (USB) after starting X made it >> > show up working, but that's annoying and stupid (and not an option on >> > other systems with e.g. PS/2 meece). I wound up sticking the "other >> > half" of that oft-cargo-culted incantation: >> > >> > Section "ServerFlags" >> > Option "AutoAddDevices" "off" >> > EndSection >> > >> > in my config, and it's worked OK since. 's probably worth a try... >> >> >> Yeah, that does work too. It's just annoying it's necessary :) >> > > Sure is. One thing that also comes to mind is moused. Do you have it > running? I seem to remember having weird troubles when moused wasn't > running. I ran into this problem a while back. The problem turned out to be that moused was exclusively opening /dev/psm0 before hald so that hald was unable open it. This happened first on my laptop, and I just disabled moused and everything seemed to work except that the trackpad no longer worked in console mode. I tried the same thing later when my primary desktop broke and it sort of worked. The problem that I ran into was that Xorg would occasionally wedge and spam its log with messages about problems with detecting the mouse protocol. Even worse, I found that my KVM switch would very reliably trigger this problem. After much hair pulling, I eventually re-enabled moused and added this to xorg.conf: Option "AllowEmptyInput" "Off" so that it would obey this mouse configuration section: Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection I don't recall if I disabled hald and changed xorg.conf to point to /dev/psm0 before I re-enabled moused. I do know that hald is currently disabled and nothing obvious seems to be broken in Gnome. I haven't had any issues with AllowEmptyInput so I never bothered to switch over to the preferred AutoAddDevices. From owner-freebsd-stable@FreeBSD.ORG Sun Mar 17 23:16:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47D2D1BE; Sun, 17 Mar 2013 23:16:29 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id C89AD862; Sun, 17 Mar 2013 23:16:28 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-9-156.lns21.adl2.internode.on.net [14.2.9.156]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2HNFp56080427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Mar 2013 09:45:58 +1030 (CST) (envelope-from darius@dons.net.au) Subject: Re: What is the Right Way($(D"o(B) to run X? Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <201303172224.r2HMOg25013615@gw.catspoiler.org> Date: Mon, 18 Mar 2013 09:45:51 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <624366A6-5E01-43CB-8C1A-2E4D595A1F90@dons.net.au> References: <201303172224.r2HMOg25013615@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.1499) X-Spam-Score: 1.415 (*) BAYES_00, RDNS_DYNAMIC, SUBJECT_NEEDS_ENCODING, SUBJ_ILLEGAL_CHARS X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org, fullermd@over-yonder.net, andrnils@gmail.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 23:16:29 -0000 On 18/03/2013, at 8:54, Don Lewis wrote: > I don't recall if I disabled hald and changed xorg.conf to point to > /dev/psm0 before I re-enabled moused. I do know that hald is = currently > disabled and nothing obvious seems to be broken in Gnome. >=20 > I haven't had any issues with AllowEmptyInput so I never bothered to > switch over to the preferred AutoAddDevices. This sounds exactly like what I have, although I do find it odd that hal = doesn't manage to open /dev/sysmouse and use that (even if it fails for = /dev/ums* etc). lshal does show a mount device listed with /dev/sysmouse = as the device name. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 01:21:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B9CD4DA; Mon, 18 Mar 2013 01:21:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 3D29FCF9; Mon, 18 Mar 2013 01:21:11 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id tb18so4871577obb.3 for ; Sun, 17 Mar 2013 18:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4k9HdvXsS9AwAdKDZnto4aZikW3YlW3mxw24GnoPgWg=; b=EFtb3BXPq9tGqr+0CZZUHuR6cUlY7Ej/3CTWDdDVhnVtEODcG9guHtviUFubsoUfrJ YiiarPl6BlAgWUWGuUreSHJO4NqoO2sDGnkJGWY+PdoXMngq6OuuROtDfhgWBL9cvIPp FRlvTwCbkp0w710yMCpuMdnYh4rQTWzmBc9zLNuTPNxepcJWzciWYwxB3hMAlyx5ymeL ZPkpPNyQ0PA9yQvxffaT9z16hOwB6oPH8OQGFvDHEzCAGvr+kVD6A684WWlGd0L73ms6 PaM57fGcNLUQ6F0U1nLB3/XOTa+QX1vM3O8b3fWnPOq8uYY8Umque1fLwuiFh/mXmMtW WulQ== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr5961014obc.30.1363569670494; Sun, 17 Mar 2013 18:21:10 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.11.165 with HTTP; Sun, 17 Mar 2013 18:21:10 -0700 (PDT) In-Reply-To: <624366A6-5E01-43CB-8C1A-2E4D595A1F90@dons.net.au> References: <201303172224.r2HMOg25013615@gw.catspoiler.org> <624366A6-5E01-43CB-8C1A-2E4D595A1F90@dons.net.au> Date: Sun, 17 Mar 2013 18:21:10 -0700 X-Google-Sender-Auth: S4sBtI-77ojLOhwvEA3dijd77Ig Message-ID: Subject: =?UTF-8?B?UmU6IFdoYXQgaXMgdGhlIFJpZ2h0IFdheSjvv70ibykgdG8gcnVuIFg/?= From: Kevin Oberman To: "Daniel O'Connor" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Don Lewis , freebsd-stable@freebsd.org, andrnils@gmail.com, fullermd@over-yonder.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 01:21:11 -0000 On Sun, Mar 17, 2013 at 4:15 PM, Daniel O'Connor wrote: > > On 18/03/2013, at 8:54, Don Lewis wrote: > > I don't recall if I disabled hald and changed xorg.conf to point to > > /dev/psm0 before I re-enabled moused. I do know that hald is currently > > disabled and nothing obvious seems to be broken in Gnome. > > > > I haven't had any issues with AllowEmptyInput so I never bothered to > > switch over to the preferred AutoAddDevices. > > This sounds exactly like what I have, although I do find it odd that hal > doesn't manage to open /dev/sysmouse and use that (even if it fails for > /dev/ums* etc). lshal does show a mount device listed with /dev/sysmouse as > the device name. > > Very odd. I have been running with xorg, sysmouse and hal for a long time > with no real issues. No AutoAddDevices or AllowEmptyInput at all. > lshal shows that the magic is working: di = '/org/freedesktop/Hal/devices/psm_0' freebsd.device_file = '/dev/psm0' (string) freebsd.driver = 'psm' (string) freebsd.unit = 0 (0x0) (int) info.addons = {'hald-addon-mouse-sysmouse'} (string list) info.capabilities = {'input', 'input.mouse'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string) info.product = 'PS/2 Mouse' (string) info.subsystem = 'platform' (string) info.udi = '/org/freedesktop/Hal/devices/psm_0' (string) input.device = '/dev/sysmouse' (string) input.x11_driver = 'mouse' (string) platform.id = 'psm.0' (string) Note that the input.device is sysmouse and that it works. Does lshal how the input device to be sysmouse on your system? -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 03:20:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 965C930D; Mon, 18 Mar 2013 03:20:25 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EDB88184; Mon, 18 Mar 2013 03:20:24 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-1-201.lns20.adl2.internode.on.net [121.45.1.201]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2I3JxLU005241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Mar 2013 13:50:05 +1030 (CST) (envelope-from darius@dons.net.au) Subject: =?utf-8?Q?Re=3A_What_is_the_Right_Way=28=EF=BF=BD=22o=29_to_run_?= =?utf-8?Q?X=3F?= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: Date: Mon, 18 Mar 2013 13:49:59 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201303172224.r2HMOg25013615@gw.catspoiler.org> <624366A6-5E01-43CB-8C1A-2E4D595A1F90@dons.net.au> To: Kevin Oberman X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Don Lewis , freebsd-stable@freebsd.org, andrnils@gmail.com, fullermd@over-yonder.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 03:20:25 -0000 On 18/03/2013, at 11:51, Kevin Oberman wrote: >> This sounds exactly like what I have, although I do find it odd that = hal doesn't manage to open /dev/sysmouse and use that (even if it fails = for /dev/ums* etc). lshal does show a mount device listed with = /dev/sysmouse as the device name. >=20 > Very odd. I have been running with xorg, sysmouse and hal for a long = time with no real issues. No AutoAddDevices or AllowEmptyInput at all. >=20 > lshal shows that the magic is working: > di =3D '/org/freedesktop/Hal/devices/psm_0' > freebsd.device_file =3D '/dev/psm0' (string) > freebsd.driver =3D 'psm' (string) > freebsd.unit =3D 0 (0x0) (int) > info.addons =3D {'hald-addon-mouse-sysmouse'} (string list) > info.capabilities =3D {'input', 'input.mouse'} (string list) > info.category =3D 'input' (string) > info.parent =3D '/org/freedesktop/Hal/devices/atkbdc_0' (string) > info.product =3D 'PS/2 Mouse' (string) > info.subsystem =3D 'platform' (string) > info.udi =3D '/org/freedesktop/Hal/devices/psm_0' (string) > input.device =3D '/dev/sysmouse' (string) > input.x11_driver =3D 'mouse' (string) > platform.id =3D 'psm.0' (string) >=20 > Note that the input.device is sysmouse and that it works. Does lshal = how the input device to be sysmouse on your system? Yes. I wonder, I have 2 USB mice maybe that is a problem. The full output of lshal is at http://www.dons.net.au/~darius/lshal.txt -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 10:41:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16C0BCC3 for ; Mon, 18 Mar 2013 10:41:57 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id DD0331EF for ; Mon, 18 Mar 2013 10:41:56 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id r2I8fjsr026207; Mon, 18 Mar 2013 04:41:45 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <5146D330.8020902@sentex.net> Date: Mon, 18 Mar 2013 04:41:20 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: latest sshd upgrade X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:41:57 -0000 Hi, I noticed on the latest openssh MFC, the previous behaviour of sshd checking both authorized_keys2 and authorized_keys is no longer the default. # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys AuthorizedKeysFile .ssh/authorized_keys vs # The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2 # but this is overridden so installations will only check .ssh/authorized_keys #AuthorizedKeysFile .ssh/authorized_keys in sshd_config. Is there a reason why this was done ? ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 11:04:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C75E1585 for ; Mon, 18 Mar 2013 11:04:23 +0000 (UTC) (envelope-from SRS0=W6Xf3F5m=NG=beatsnet.com=beat.siegenthaler@beatsnet.com) Received: from vulcan.beatsnet.com (netsigi-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:2e9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2F76599E for ; Mon, 18 Mar 2013 11:04:22 +0000 (UTC) Received: from mbp-wl.beatsnet.com (zux165-132.adsl.green.ch [80.254.165.132]) (authenticated bits=0) by vulcan.beatsnet.com (8.14.5/8.14.5) with ESMTP id r2IB42Lx071811 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Mon, 18 Mar 2013 12:04:17 +0100 (CET) (envelope-from beat.siegenthaler@beatsnet.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=beatsnet.com; s=VULCAN_DKIM; t=1363604659; bh=oDg3z2WouPLJsRLblPF3fY7e3JXavpsRmBYaU+OTV90=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=AsXoZkRuB7+9lBBm9rGObc4HSuKPjYBV0htT6TCP3gURNg22Z1b24nc650mmQxT/e AYAHI4TqNPXyeAi1Y3j6fAMwM900jOgW9fQazmp0MEVY5WVM+lzCw4ekM34j+STLxK L5HMFq8KkyC7p9HxidqWN3DdA576e0+yyx/mxVG8= Message-ID: <5146F49B.5080609@beatsnet.com> Date: Mon, 18 Mar 2013 12:03:55 +0100 From: Beat Siegenthaler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Subject: troubles with buildworld/sendmail/sasl/clang X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vulcan.beatsnet.com [193.138.215.102]); Mon, 18 Mar 2013 12:04:18 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97.6 at vulcan.beatsnet.com X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:04:23 -0000 Hi all, since some days i try to "make buildworld", but have some errors in sendmail. The make conf is not changed since years (in this case) . Adding NO_WERROR= in src.conf helps, but i think it is not the optimal solution? # SASL (cyrus-sasl v2) sendmail build flags... SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+=-L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL SENDMAIL_MC = /etc/mail/xyz.mc WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient ==============src.conf=================== CC=clang CXX=clang++ CPP=clang-cpp # This setting to build world without -Werror: # NO_WERROR= # This setting to build kernel without -Werror: # WERROR= =================buildworld=============== /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: error: incompatible pointer types passing 'void ()' to parameter of type 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' [-Werror,-Wincompatible-pointer-types] getsasldata, NULL, XS_AUTH); ^~~~~~~~~~~ /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: passing argument to parameter here extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); ^ /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from macro '__P' #define __P(protos) protos /* full-blown ANSI C */ ^ 3 errors generated. *** [usersmtp.o] Error code 1 1 error *** [all] Error code 2 1 error *** [usr.sbin.all__D] Error code 2 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error regards beat From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 11:08:48 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5423B69B for ; Mon, 18 Mar 2013 11:08:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by mx1.freebsd.org (Postfix) with ESMTP id 323EECD1 for ; Mon, 18 Mar 2013 11:08:48 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id xb4so6323712pbc.1 for ; Mon, 18 Mar 2013 04:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=OH7XbxW4KYRkv1tPWSmeMOpYcWbhVR2hTpPMB6FACC4=; b=oBVx74GKjN0bOXEaBuH3SIDWZ9+BC9GY2LS3u1+IAegTCIeGyUm+tYRONZhPH9IQHt /2JtGbRXtXetiYxPqo3wAzwO6Uxec1IhH4wmExaxcOztS9vLCDo03lTZ44jiLzYmXgoR 2PxGYBZqERNifKagAV/fenaKEMI988WTemgogjk8I0Ddt3Eg8DZe3WxoZIMSahbXHJCg Np8oeF+W+Ro39qRgyWnuyVNT083+82hKbdL8LZEi1W/07rldnVjlN7obvG+hI2CfpOla qkjHE3wt2upSzIcMLDShRGXaxuFEVE9pXNJNd81gNTAA5rtdAT37Qta+k9m+hUmPV7qI iIMg== X-Received: by 10.66.120.99 with SMTP id lb3mr8824717pab.173.1363589984753; Sun, 17 Mar 2013 23:59:44 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ce16sm7120371pac.5.2013.03.17.23.59.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Mar 2013 23:59:43 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 18 Mar 2013 15:59:38 +0900 From: YongHyeon PYUN Date: Mon, 18 Mar 2013 15:59:38 +0900 To: Michael BlackHeart Subject: Re: A few problems Message-ID: <20130318065938.GB1459@michelle.cdnetworks.com> References: 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-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:08:48 -0000 On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: > Hello there. I've got a couple of things I don't get or can't handle. > [...] > re0@pci0:4:0:0: class=0x020000 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet > bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled > bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled > bar [20] = type Prefetchable Memory, range 64, base 0xf8ff0000, > size 65536, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) > speed 2.5(2.5) > cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled > cap 03[d0] = VPD > ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected > ecap 0002[140] = VC 1 max VC0 > ecap 0003[160] = Serial 1 01000000684ce000 > > re0: flags=8843 metric 0 mtu 1500 > description: ToISP > options=8218b > ether 00:21:85:1c:24:fa > media: Ethernet autoselect (100baseTX ) > status: active [...] > One is that re0 doesn't neogatiate direct link with a connected PC > (using non-crossover UTP), but sk0 does that easy. It seems to me that > according to RTL8111 chip specification there shouldn't be any > problem, probably it's a driver problem? > What is your link parter for re0? I don't remember whether the PHY hardware really supports automatic MDI crossover detection. Even if the PHY hardware does not support it, the link partner would be able to do that. And could you show me the output of dmesg(re(4) and rgephy(4) only) and "devinfo -rv | grep rgephy"? From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 11:44:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DAF5B10 for ; Mon, 18 Mar 2013 11:44:24 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DD23D2D1 for ; Mon, 18 Mar 2013 11:44:23 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 53E8BC696; Mon, 18 Mar 2013 09:18:07 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 27B179B37; Mon, 18 Mar 2013 10:18:07 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mike Tancsa Subject: Re: latest sshd upgrade References: <5146D330.8020902@sentex.net> Date: Mon, 18 Mar 2013 10:18:06 +0100 In-Reply-To: <5146D330.8020902@sentex.net> (Mike Tancsa's message of "Mon, 18 Mar 2013 04:41:20 -0400") Message-ID: <86r4jd5anl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 11:44:24 -0000 Mike Tancsa writes: > I noticed on the latest openssh MFC, the previous behaviour of sshd > checking both authorized_keys2 and authorized_keys is no longer the > default. [...] Is there a reason why this was done ? authorized_keys2 has been deprecated for ages... but I shouldn't have merged that change. I'll revert it. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 13:01:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3599A281 for ; Mon, 18 Mar 2013 13:01:57 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.server1.bsdforen.de (bsdforen.de [82.193.243.81]) by mx1.freebsd.org (Postfix) with ESMTP id D8E53957 for ; Mon, 18 Mar 2013 13:01:56 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-134-3-231-194.hsi14.kabel-badenwuerttemberg.de [134.3.231.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.server1.bsdforen.de (Postfix) with ESMTPSA id 5B8BF8617E for ; Mon, 18 Mar 2013 14:01:45 +0100 (CET) Message-ID: <51471039.8070505@bsdforen.de> Date: Mon, 18 Mar 2013 14:01:45 +0100 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130309 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: System doesn't resume with active vbox VM X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:01:57 -0000 My system doesn't resume with an active VirtualBox VM, in this case Windows XP/32. I didn't test any other systems. The system comes back to the console screen, but doesn't get back into X. After a couple of seconds (no dump occurs) I get the BIOS screen and the system reboots with unclean file systems. # uname -a FreeBSD mobileKamikaze.norad 9.1-STABLE FreeBSD 9.1-STABLE #3 r247136: Fri Feb 22 00:52:22 CET 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 amd64 Hardware virtualization is turned on, the additions are installed in the VM. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 13:19:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B31A85D for ; Mon, 18 Mar 2013 13:19:18 +0000 (UTC) (envelope-from amdmiek@gmail.com) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by mx1.freebsd.org (Postfix) with ESMTP id C8DCDA18 for ; Mon, 18 Mar 2013 13:19:17 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id dr12so4833750wgb.23 for ; Mon, 18 Mar 2013 06:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AP1lDG0tbkXQ6lolUd6qU0kSBSwMtJGbpILxmWk15vA=; b=UCReq1y/SieC9uO9ZGPgLDXgyBDhRBKv9PlpjPP5wsosDg4FqHDPs2WdoKy/fcTYe5 GKcaVbxuG/8YCK+Mo/12QTjExTVQ0J3x56ib7jgnYHHOOcTEEm7zUnChvGxCuFUA3uKY gouIShQ8/ZRkmCalkLKHs0Wt9SngD7bqtACWfk08IjUoP6hX9KmUx2yaKjq6NpcbAbdX EuEgi5gJXTpDIG5oz8K3NP2C79idIhRv8F9XtSpWkR7JeX8k1aRkDrT+3YFHhKxI8fdg wklAYO6SPIcf8mmrltxq07RrMx/RGExQjkRmvhU/tXoikA4D3P4Noj4yxrebgL5VRl/g lnzQ== MIME-Version: 1.0 X-Received: by 10.180.185.176 with SMTP id fd16mr16579155wic.31.1363612751406; Mon, 18 Mar 2013 06:19:11 -0700 (PDT) Received: by 10.180.93.40 with HTTP; Mon, 18 Mar 2013 06:19:11 -0700 (PDT) In-Reply-To: <20130318065938.GB1459@michelle.cdnetworks.com> References: <20130318065938.GB1459@michelle.cdnetworks.com> Date: Mon, 18 Mar 2013 17:19:11 +0400 Message-ID: Subject: Re: A few problems From: Michael BlackHeart To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:19:18 -0000 2013/3/18 YongHyeon PYUN : > On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: >> Hello there. I've got a couple of things I don't get or can't handle. >> > > [...] > >> re0@pci0:4:0:0: class=0x020000 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 >> vendor = 'Realtek Semiconductor Co., Ltd.' >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' >> class = network >> subclass = ethernet >> bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled >> bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled >> bar [20] = type Prefetchable Memory, range 64, base 0xf8ff0000, >> size 65536, enabled >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 >> cap 05[50] = MSI supports 1 message, 64 bit >> cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) >> speed 2.5(2.5) >> cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled >> cap 03[d0] = VPD >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected >> ecap 0002[140] = VC 1 max VC0 >> ecap 0003[160] = Serial 1 01000000684ce000 >> >> re0: flags=8843 metric 0 mtu 1500 >> description: ToISP >> options=8218b >> ether 00:21:85:1c:24:fa >> media: Ethernet autoselect (100baseTX ) >> status: active > > [...] > >> One is that re0 doesn't neogatiate direct link with a connected PC >> (using non-crossover UTP), but sk0 does that easy. It seems to me that >> according to RTL8111 chip specification there shouldn't be any >> problem, probably it's a driver problem? >> > > What is your link parter for re0? I don't remember whether the PHY > hardware really supports automatic MDI crossover detection. Even if > the PHY hardware does not support it, the link partner would be > able to do that. > > And could you show me the output of dmesg(re(4) and rgephy(4) only) > and "devinfo -rv | grep rgephy"? Here's info: re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 17 at device 0.0 on pci4 re0: Using 1 MSI-X message re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:21:85:1c:24:fa devinfo -rv | grep rgephy rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 This link connected to Realtek 8111E under Win7. I'll repeat that when it's connected to sk0, everything works. Of course when I'm switching links, I change IPs and other configuration in rc.conf and reboots system. For example I'll provide info for sk0 (Dlink DGE-530T): skc0: port 0xe800-0xe8ff mem 0xfebec000-0xfebeffff irq 17 at device 1.0 on pci5 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:19:5b:86:3b:53 miibus1: on sk0 e1000phy0: PHY 0 on miibus1 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x5 at phyno=0 From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 16:20:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 388367E0; Mon, 18 Mar 2013 16:20:20 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD2F78C; Mon, 18 Mar 2013 16:20:19 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id x8so5058567wey.20 for ; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hEl4yd27G6vIt8eviNUy4k0FUq9IvoQM7JaJToCkGGU=; b=nFSx+nTcA++8N6xrckd3WGdCwNtrO1mkTYZwYwMVPPyX/N/reNWbQZBA7liL5KfToc yGJG2auOUqTcNhzYSnrUkHBW8+lXRDvrDmNRuyJ2XJP9/sqEsM/DUJ4pxzO+MwaXeSwY TRReL5lgBjDIMIqVnatiy3OWBKGqpNVnEhf3BTlWBBpL/y/cevuT3wTpwN25fB32MXRs qZ8NEx/+O5kRmt4wRNxui2WWBpApT3tkKZBFb9GBma3tTiHazH/l7qe+R2rqKiqefOpn 27iOcT8GBlb6vLpHF2i5X83VKH6y8fVxf1mxh13YtLNyhLWUknXB/u/iJdI6fW9wdRDg n23Q== MIME-Version: 1.0 X-Received: by 10.180.104.225 with SMTP id gh1mr6074290wib.27.1363623618703; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) Received: by 10.216.9.68 with HTTP; Mon, 18 Mar 2013 09:20:18 -0700 (PDT) In-Reply-To: <5146F49B.5080609@beatsnet.com> References: <5146F49B.5080609@beatsnet.com> Date: Mon, 18 Mar 2013 18:20:18 +0200 Message-ID: Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Kimmo Paasiala To: Beat Siegenthaler Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD current , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:20:20 -0000 On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler wrote: > Hi all, > > since some days i try to "make buildworld", but have some errors in > sendmail. > The make conf is not changed since years (in this case) . Adding > NO_WERROR= in src.conf helps, but i think it is not the optimal solution? > > # SASL (cyrus-sasl v2) sendmail build flags... > SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+=-L/usr/local/lib > SENDMAIL_LDADD+=-lsasl2 > SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL > > SENDMAIL_MC = /etc/mail/xyz.mc > WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient > > ==============src.conf=================== > > CC=clang > CXX=clang++ > CPP=clang-cpp > # This setting to build world without -Werror: > # NO_WERROR= > # This setting to build kernel without -Werror: > # WERROR= > > =================buildworld=============== > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > error: incompatible pointer types passing 'void ()' to parameter of type > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > [-Werror,-Wincompatible-pointer-types] > getsasldata, NULL, XS_AUTH); > ^~~~~~~~~~~ > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > passing argument to parameter here > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > ^ > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > macro '__P' > #define __P(protos) protos /* full-blown ANSI C */ > ^ > 3 errors generated. > *** [usersmtp.o] Error code 1 > 1 error > *** [all] Error code 2 > 1 error > *** [usr.sbin.all__D] Error code 2 > 1 error > *** [everything] Error code 2 > 1 error > *** [buildworld] Error code 2 > 1 error > > regards > beat I can not help with the error but I really have to make this question: Does FreeBSD really have to support pre-ANSI C compilers in 2013? -Kimmo From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 17:19:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE986A60 for ; Mon, 18 Mar 2013 17:19:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 8B7E3A81 for ; Mon, 18 Mar 2013 17:19:20 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b59c:c59a:c3:9796] (unknown [IPv6:2001:7b8:3a7:0:b59c:c59a:c3:9796]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3378F5C5B; Mon, 18 Mar 2013 18:19:19 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Dimitry Andric In-Reply-To: <5146F49B.5080609@beatsnet.com> Date: Mon, 18 Mar 2013 18:19:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5146F49B.5080609@beatsnet.com> To: Beat Siegenthaler X-Mailer: Apple Mail (2.1503) Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:19:20 -0000 On Mar 18, 2013, at 12:03, Beat Siegenthaler = wrote: > since some days i try to "make buildworld", but have some errors in > sendmail. > The make conf is not changed since years (in this case) . Adding > NO_WERROR=3D in src.conf helps, but i think it is not the optimal = solution? >=20 > # SASL (cyrus-sasl v2) sendmail build flags... > SENDMAIL_CFLAGS+=3D-I/usr/local/include -DSASL=3D2 > SENDMAIL_LDFLAGS+=3D-L/usr/local/lib > SENDMAIL_LDADD+=3D-lsasl2 > SENDMAIL_CFLAGS+=3D -D_FFR_SMTP_SSL ... > = /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > error: incompatible pointer types passing 'void ()' to parameter of = type > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE = *)' > [-Werror,-Wincompatible-pointer-types] > getsasldata, NULL, XS_AUTH); > ^~~~~~~~~~~ We used to build sendmail with NO_WERROR.clang=3D to disable -Werror specifically for clang, because there were some warnings that could not be suppressed otherwise. But since r246880 we reverted that workaround, so this may be why you are now seeing these -Werror messages. In any case, if you are pulling port headers into your buildworld, the effect is not always predictable, as ports are largely independent from base. So if you need a customized build of sendmail, would it not be better to use the mail/sendmail port instead? There you can easily enable all bells and whistles that are not enabled by default in base. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 17:30:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 584EBFB0 for ; Mon, 18 Mar 2013 17:30:21 +0000 (UTC) (envelope-from SRS0=W6Xf3F5m=NG=beatsnet.com=beat.siegenthaler@beatsnet.com) Received: from vulcan.beatsnet.com (netsigi-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:2e9::2]) by mx1.freebsd.org (Postfix) with ESMTP id A0715B55 for ; Mon, 18 Mar 2013 17:30:20 +0000 (UTC) Received: from mbp-wl.beatsnet.com (zux165-132.adsl.green.ch [80.254.165.132]) (authenticated bits=0) by vulcan.beatsnet.com (8.14.5/8.14.5) with ESMTP id r2IHU6dv090722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Mon, 18 Mar 2013 18:30:18 +0100 (CET) (envelope-from beat.siegenthaler@beatsnet.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=beatsnet.com; s=VULCAN_DKIM; t=1363627818; bh=uPhypXQU/I9758w+R/twgzSeOTw3znmp8NJXVK8beow=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XGf2Akst1xo5gKSJyXk/mLIAWbuoyPu8ZFMurMGX7LCWtk7Mjx1L1MNgRs3aG8bqC l3qRdDw1IduwW3HQC0hvKrOBGsRhFOWFdnBVzdn0Z3R2bB5VHik5fnVf/uJhjDqjNv uwTArGLbFg8zPygC7HeJbJEhndG/gYnM7qVcIPcU= Message-ID: <51474F18.8080104@beatsnet.com> Date: Mon, 18 Mar 2013 18:30:00 +0100 From: Beat Siegenthaler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: troubles with buildworld/sendmail/sasl/clang References: <5146F49B.5080609@beatsnet.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vulcan.beatsnet.com [193.138.215.102]); Mon, 18 Mar 2013 18:30:18 +0100 (CET) X-Virus-Scanned: clamav-milter 0.97.6 at vulcan.beatsnet.com X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:30:21 -0000 On 18.03.13 18:19, Dimitry Andric wrote: > We used to build sendmail with NO_WERROR.clang= to disable -Werror > specifically for clang, because there were some warnings that could > not be suppressed otherwise. So if you need a customized build of > sendmail, would it not be better to use the mail/sendmail port > instead? There you can easily enable all bells and whistles that are > not enabled by default in base. Ok, good point... force of habit. Since years. Will use Port... regards, Beat From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 18:01:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F682FB6 for ; Mon, 18 Mar 2013 18:01:56 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from nk11p00mm-asmtp005.mac.com (nk11p00mm-asmtp005.mac.com [17.158.161.4]) by mx1.freebsd.org (Postfix) with ESMTP id 71416E1C for ; Mon, 18 Mar 2013 18:01:56 +0000 (UTC) Received: from cswiger1.apple.com ([17.209.4.71]) by nk11p00mm-asmtp005.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MJV00CD0BF6T500@nk11p00mm-asmtp005.mac.com> for freebsd-stable@freebsd.org; Mon, 18 Mar 2013 18:01:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-03-18_01:2013-03-18,2013-03-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1303180140 Subject: Re: A few problems MIME-version: 1.0 (Apple Message framework v1085) Content-type: text/plain; charset=us-ascii From: Chuck Swiger In-reply-to: Date: Mon, 18 Mar 2013 11:01:54 -0700 Content-transfer-encoding: quoted-printable Message-id: <6A3147D1-128F-43C5-BF5D-5A593217C87C@mac.com> References: To: Michael BlackHeart X-Mailer: Apple Mail (2.1085) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:01:56 -0000 Hi-- On Mar 16, 2013, at 2:08 AM, Michael BlackHeart wrote: > Hello there. I've got a couple of things I don't get or can't handle. >=20 > I'm running: > FreeBSD diablo.miekoff.local 9.1-STABLE FreeBSD 9.1-STABLE #0 r248347: > Sat Mar 16 03:20:58 MSK 2013 > root@diablo.miekoff.local:/usr/obj/usr/src/sys/DIABLO64 amd64 >=20 >=20 > 1st of all, on dmesg there's something strange. It says: >=20 > real memory =3D 6442450944 (6144 MB) > avail memory =3D 4092743680 (3903 MB) >=20 > So real memory is about 6Gb, but localy installed only 4Gb. [ ... ] You've got an Intel P45 northbridge controller which supports = dual-channel mode, but that only works for DIMMs of the same size. You = might be able to get 6GB if you place the DIMMs in slots 1 and 2 instead = of 1 & 3 or 2 & 4. Otherwise, try getting another 4GB DIMM and using = 4GB + 4GB instead. Regards, --=20 -Chuck From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 18:55:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A69C6B; Mon, 18 Mar 2013 18:55:31 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8881AE; Mon, 18 Mar 2013 18:55:30 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.6/8.14.6) with ESMTP/inet6 id r2IIstG4038771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Mar 2013 03:55:00 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 19 Mar 2013 03:54:55 +0900 Message-ID: From: Hajimu UMEMOTO To: Dimitry Andric Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: References: <5146F49B.5080609@beatsnet.com> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/24.2 (i386-portbld-freebsd9.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.1-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 19 Mar 2013 03:55:01 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.7 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-5.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: FreeBSD-STABLE Mailing List , Beat Siegenthaler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:55:31 -0000 Hi, >>>>> On Mon, 18 Mar 2013 18:19:18 +0100 >>>>> Dimitry Andric said: dim> On Mar 18, 2013, at 12:03, Beat Siegenthaler wrote: > since some days i try to "make buildworld", but have some errors in > sendmail. > The make conf is not changed since years (in this case) . Adding > NO_WERROR= in src.conf helps, but i think it is not the optimal solution? > > # SASL (cyrus-sasl v2) sendmail build flags... > SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+=-L/usr/local/lib > SENDMAIL_LDADD+=-lsasl2 > SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL dim> ... > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > error: incompatible pointer types passing 'void ()' to parameter of type > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > [-Werror,-Wincompatible-pointer-types] > getsasldata, NULL, XS_AUTH); > ^~~~~~~~~~~ dim> We used to build sendmail with NO_WERROR.clang= to disable -Werror dim> specifically for clang, because there were some warnings that could not dim> be suppressed otherwise. But since r246880 we reverted that workaround, dim> so this may be why you are now seeing these -Werror messages. dim> In any case, if you are pulling port headers into your buildworld, the dim> effect is not always predictable, as ports are largely independent from dim> base. So if you need a customized build of sendmail, would it not be dim> better to use the mail/sendmail port instead? There you can easily dim> enable all bells and whistles that are not enabled by default in base. No, it seems to me that this error is not depending on sasl header. I suspect clang still has some problem in handling __P. Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 21:35:49 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D44248D0 for ; Mon, 18 Mar 2013 21:35:49 +0000 (UTC) (envelope-from amdmiek@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 5F838D36 for ; Mon, 18 Mar 2013 21:35:49 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so3537448wib.1 for ; Mon, 18 Mar 2013 14:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=rBcW0vPmkUJDHDyL6Bls5D6i4umPOFHDUgBnxAzqqIU=; b=i6RGKZ2yKEeuSZR0zoyrnnkl/UTi3KFEfdx2t+pwKwz3adzYHAE7Mwb8t8R+7U8tc8 a3nlkgqz1uyfuY91Fq6BIr2XCDk10ioExXB2OuuSA1U52ZIaEAgTetTB9yrV79aLIrr9 wiR3wYcp7WL3nRFaprSBRnDOcqs/V9EdFNM64L+4N7H7TQn2z4ydnqK5ZD+39a9bB9nC JWl0toixbla0L4bw503AWNImohmsckokQHvUHKYx1zEgHAg5arON1OpMsNiWARMSkZzg Zq+ctLKfGlMc+S24jDitq1WxASFX+eZazY+ju98dmRrdPMGozqw+qpky5ZizhOJ9Xcix oDZQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr28137181wjb.24.1363642548599; Mon, 18 Mar 2013 14:35:48 -0700 (PDT) Received: by 10.180.93.40 with HTTP; Mon, 18 Mar 2013 14:35:48 -0700 (PDT) In-Reply-To: References: <6A3147D1-128F-43C5-BF5D-5A593217C87C@mac.com> <20130318181658.GA42202@icarus.home.lan> Date: Tue, 19 Mar 2013 01:35:48 +0400 Message-ID: Subject: Re: A few problems From: Michael BlackHeart To: Chuck Swiger , freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jeremy Chadwick X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:35:49 -0000 2013/3/18 Chuck Swiger : > Hi-- > > On Mar 18, 2013, at 11:16 AM, Jeremy Chadwick wrote: >>> You've got an Intel P45 northbridge controller which supports dual-chan= nel mode, but that only works for DIMMs of the same size. You might be abl= e to get 6GB if you place the DIMMs in slots 1 and 2 instead of 1 & 3 or 2 = & 4. Otherwise, try getting another 4GB DIMM and using 4GB + 4GB instead. >> >> Off-list: >> >> Except that Michael said, re: his dmidecode output: >> >>> As you see it says that in DIMM4 there's 4Gb module, but it's 2Gb >>> actualy. It's a Kit of 2x2Gb. BIOS says that there's only 4Gb but >>> FreeBSD see 6Gb. I'll try later to switch modules into DIMM1 & DIMM3 >>> but I'm not expecting any difference. >> >> So let's recap: >> >> - DIMMs are operating in single-channel mode (vs. dual-channel) > > Are they? (I didn't see info one way or the other, but perhaps off-list = communication confirmed that.) > >> - DIMM2 claims to be 2GB >> - DIMM4 claims to be 4GB >> - Intel P45 supports up to 16GB RAM (4GB maximum per DIMM) >> - OS is amd64 >> >> If he did have 4GB+2GB installed, since he's using amd64, ideally he >> would be seeing FreeBSD report "avail memory =3D (around 6GB)", which >> isn't the case. So something isn't making sense here. > > Right. If one DIMM really is 4GB, then putting them into slots 1 & 2 sho= uld make a difference; or just install only one at a time to double-check. > >> Possibly the SMBIOS/DMI data claims to have a 4GB DIMM, yet in actuality >> chip-wise only has 2GB on it. In which case, the SMBIOS/DMI data is >> wrong, or the DIMM manufacturer is shady. >> >> I would not be surprised if the user had two DIMMs bought at different >> times (even if they're the same model), or that one is just manufactured >> wrong/badly. > > Maybe. If you put different sized DIMMs into slots paired up for dual-ch= annel mode, IIRC that era of Intel chipsets would work in dual-channel mode= using the smaller memory size. That resembles the current situation rathe= r closely-- ie, 6GB installed but only 4GB available. > > But I suppose it could be a DIMM which claims to be the wrong size in DMI= info.... > > Regards, > -- > -Chuck > I checked out. It's a kit of 2x2Gb as I said before. And I moved them to 1 and 3 slots and nothing changed. currently do not have any DDR2 modules to make some more tests. Here's proof: http://www.miekoff.ru/wp-content/uploads/P1020858.jpg And for the record, I used this memory on two other motherboards, one was running WinXP and another FreeBSD 8.3 and later 9.1. And all of them reported about 4Gb installed. Just like BIOS does. So it seems to me like some weird thing. On the one side it could be a FreeBSD's DMI mis-interpretating. On the other side as far as I know Corssair do not produce something, but just tunes and overclocks memory chips. And because of the radiators I can't visually compare chips one of them easily could be a 4Gb module locked to 2Gb or something like that. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 22:07:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70AE8CB3; Mon, 18 Mar 2013 22:07:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 2A66228; Mon, 18 Mar 2013 22:07:43 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::3416:d0fb:404b:fe0b] (unknown [IPv6:2001:7b8:3a7:0:3416:d0fb:404b:fe0b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6D2C75C5B; Mon, 18 Mar 2013 23:07:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Dimitry Andric In-Reply-To: Date: Mon, 18 Mar 2013 23:07:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5693EC94-324A-42D4-A9AE-68AD1CCA4FC4@FreeBSD.org> References: <5146F49B.5080609@beatsnet.com> To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.1503) Cc: Beat Siegenthaler , FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:07:43 -0000 On Mar 18, 2013, at 19:54, Hajimu UMEMOTO wrote: ... > dim> In any case, if you are pulling port headers into your = buildworld, the > dim> effect is not always predictable, as ports are largely = independent from > dim> base. So if you need a customized build of sendmail, would it = not be > dim> better to use the mail/sendmail port instead? There you can = easily > dim> enable all bells and whistles that are not enabled by default in = base. >=20 > No, it seems to me that this error is not depending on sasl header. I > suspect clang still has some problem in handling __P. It is not because of the __P macro specifically, but because of the way the function parameters are promoted for K&R functions. The getsasldata() function is first declared as: static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE = *)); Directly after that, it is defined as a K&R function: static void getsasldata(line, firstline, m, mci, e) char *line; bool firstline; MAILER *m; register MCI *mci; ENVELOPE *e; { ... About 1000 lines below that definition, the address of getsasldata gets passed to reply(), which is declared as: extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void = (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); so it accepts a function pointer parameter which matches the initial prototype of getsasldata(), but *not* the actual definition! Now, clang normally warns about the 'firstline' parameter being promoted from bool to int, as is required for K&R functions: contrib/sendmail/src/usersmtp.c:618:7: warning: promoted type 'int' of = K&R function parameter is not compatible with the parameter type 'bool' = declared in a previous prototype [-Wknr-promoted-parameter] bool firstline; ^ contrib/sendmail/src/usersmtp.c:612:42: note: previous declaration is = here static void getsasldata __P((char *, bool, MAILER *, MCI *, ENVELOPE = *)); ^ but since we suppress that warning using -Wno-knr-promoted-parameter, we do not see it during build world. However, this still means the function type is to be considered incompatible. This changes only when the definition of getsasldata() is moved further down in the file, specifically below all the places where it is passed as a function pointer to reply(). In that case, the compiler does not know yet the function is defined as K&R, and considers it to be compatible. One way to avoid this whole mess would be to stop pretending sendmail is C99 code, and define the 'bool' type as an int. That would solve all the K&R promotion problems in one fell swoop. And it requires just a minor hack in contrib/sendmail/include/sm/gen.h. Or, alternatively, fix all the function definitions to be actual C99 function definitions, but that would be a lot more work. :-)= From owner-freebsd-stable@FreeBSD.ORG Mon Mar 18 22:25:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F9A13B6 for ; Mon, 18 Mar 2013 22:25:03 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A88BD145 for ; Mon, 18 Mar 2013 22:25:02 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-1-201.lns20.adl2.internode.on.net [121.45.1.201]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2IMOMFe081877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Mar 2013 08:54:30 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Functional KDE desktop Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20130317103205.3dcefc7e@aldebaran.dabus.com> Date: Tue, 19 Mar 2013 08:54:21 +1030 Content-Transfer-Encoding: 7bit Message-Id: <4CDFA3FC-B04E-4879-896F-1FFDBE05648A@gsoft.com.au> References: <2B43A76D-345F-4FE1-86A5-680BC3318423@gsoft.com.au> <20130317103205.3dcefc7e@aldebaran.dabus.com> To: Eric S Pulley X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:25:03 -0000 On 18/03/2013, at 3:02, Eric S Pulley wrote: > I have it working fine here. I originally was using it on 9.0 then I > upgraded everything but that didn't work well for the KDE 4.8->4.9 > update in ports. Too many ports were split and moved around so I ended > up removing all ports and remaking them all. One big gotcha is make > sure you force a reconfigure on everything. > > My small nightmare was kdepim,kdepim-runtime and kdepimlibs > there are now two deferment types of PIM you can built the old "4.8 > style" and the new. Make sure you are consistent as these packages are > deps for many others. For a while I was still picking up settings for > the old style and it was breaking all over the place. Ugh I see. Any idea what these options are called? > If you want I can send you a list of all the stuff I have installed off > list and you can see if you're somehow missing important bits... I ended up nuking all of KDE/Qt and will try again. I also have had troubles with Python updates and a few things. I really like ports when installing but they are terrible when upgrading :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 04:56:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A01A6742 for ; Tue, 19 Mar 2013 04:56:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-da0-x233.google.com (mail-da0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0C2156 for ; Tue, 19 Mar 2013 04:56:36 +0000 (UTC) Received: by mail-da0-f51.google.com with SMTP id g27so65463dan.10 for ; Mon, 18 Mar 2013 21:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=0FFKKsLAnFEk/XF8s0/MJyvX/LdiRLSGfCZKX62Zr5o=; b=xZdIPcD8pUXN4UDMk3pOozC6zwmURiGyebLO1lMCNXRYnfx2boqTpLg1DwC2DfQbsP h+nVKkz6i2CNO6W8s8LQuKdjGZH8tIFpJ66DWUEbFEtcgjNog7u2gUcJ0i1bxlRInQOi +VW9sKpuYXiHrrZ2tiET3a/q6mfVLbclkNh2YhAJHuS3kAhkpr/nkHGF3Gn2Vp+4sY5V mVNA8vTFsjvDrGf3i47JJdDJGctVHXdJIOUOXfA8psFvEa8YM2zRepaO2xUPQmLRmml0 zkSGKfLXhnKvoqOUkmSS1pgIU/ppZMSgbBnPzz96qPy3FSNOjKa2BYEPFveiQlq0i6IU 8riA== X-Received: by 10.68.222.73 with SMTP id qk9mr981216pbc.115.1363668996252; Mon, 18 Mar 2013 21:56:36 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ip8sm22718863pbc.39.2013.03.18.21.56.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Mar 2013 21:56:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Mar 2013 13:56:29 +0900 From: YongHyeon PYUN Date: Tue, 19 Mar 2013 13:56:29 +0900 To: Michael BlackHeart Subject: Re: A few problems Message-ID: <20130319045629.GA1437@michelle.cdnetworks.com> References: <20130318065938.GB1459@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-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 04:56:36 -0000 On Mon, Mar 18, 2013 at 05:19:11PM +0400, Michael BlackHeart wrote: > 2013/3/18 YongHyeon PYUN : > > On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: > >> Hello there. I've got a couple of things I don't get or can't handle. > >> > > > > [...] > > > >> re0@pci0:4:0:0: class=0x020000 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 > >> vendor = 'Realtek Semiconductor Co., Ltd.' > >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > >> class = network > >> subclass = ethernet > >> bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled > >> bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled > >> bar [20] = type Prefetchable Memory, range 64, base 0xf8ff0000, > >> size 65536, enabled > >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > >> cap 05[50] = MSI supports 1 message, 64 bit > >> cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) > >> speed 2.5(2.5) > >> cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled > >> cap 03[d0] = VPD > >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected > >> ecap 0002[140] = VC 1 max VC0 > >> ecap 0003[160] = Serial 1 01000000684ce000 > >> > >> re0: flags=8843 metric 0 mtu 1500 > >> description: ToISP > >> options=8218b > >> ether 00:21:85:1c:24:fa > >> media: Ethernet autoselect (100baseTX ) > >> status: active > > > > [...] > > > >> One is that re0 doesn't neogatiate direct link with a connected PC > >> (using non-crossover UTP), but sk0 does that easy. It seems to me that > >> according to RTL8111 chip specification there shouldn't be any > >> problem, probably it's a driver problem? > >> > > > > What is your link parter for re0? I don't remember whether the PHY > > hardware really supports automatic MDI crossover detection. Even if > > the PHY hardware does not support it, the link partner would be > > able to do that. > > > > And could you show me the output of dmesg(re(4) and rgephy(4) only) > > and "devinfo -rv | grep rgephy"? > > Here's info: > > re0: port > 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 17 > at device 0.0 on pci4 > re0: Using 1 MSI-X message > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:21:85:1c:24:fa > > devinfo -rv | grep rgephy > rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 > > This link connected to Realtek 8111E under Win7. > I'll repeat that when it's connected to sk0, everything works. Of e1000phy(4) supports automatic crossover detection/correction. I thought newer RealTek 8211 PHYs also support the feature but it seems it's not enabled by default. Could you try attached patch and let me know how it goes? > course when I'm switching links, I change IPs and other configuration > in rc.conf and reboots system. > > For example I'll provide info for sk0 (Dlink DGE-530T): > > skc0: port 0xe800-0xe8ff mem > 0xfebec000-0xfebeffff irq 17 at device 1.0 on pci5 > skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > sk0: on skc0 > sk0: Ethernet address: 00:19:5b:86:3b:53 > miibus1: on sk0 > e1000phy0: PHY 0 on miibus1 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto > > e1000phy0 pnpinfo oui=0xac2 model=0x2 rev=0x5 at phyno=0 From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 04:57:26 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B45B1848 for ; Tue, 19 Mar 2013 04:57:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8E618173 for ; Tue, 19 Mar 2013 04:57:26 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id up1so90201pbc.9 for ; Mon, 18 Mar 2013 21:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=O08n6MvAv8IhotNGDQzFX9Ph8H8bj01MFgklAOXrh+E=; b=boe19vVsr/VLlo49aQBVbbC86Oy27j9XiEkvDZ0gmxdKHg2xAgQb6eXzLdZsTs/1+8 gi/xVHGKvlwT3U3wji5w22ruStAY72F4r4PSlB3mneg0Ox9RXbge0wX17dGIhB9+3OGl U/PaAycMfkzGOFxO0ZSpixAEM2LMK/9SEi+HPuZup9FpzIekw6NjmpGQc3Dff9IKtZyI uC740vWA16n6qP2qkmgobTVYTRvN9BWv6+uPA4wLPajIKUARKfg4QawbqLjciysV8c2/ iFRJ1XZ3PHsMkTTxisNWvttrWc1oHjECe9NeluBue+UTsXnDiSSFlwVOpFfJpuNkIZ45 Jocg== X-Received: by 10.68.220.230 with SMTP id pz6mr1037460pbc.46.1363669046039; Mon, 18 Mar 2013 21:57:26 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id li15sm10972634pab.2.2013.03.18.21.57.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Mar 2013 21:57:25 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Mar 2013 13:57:19 +0900 From: YongHyeon PYUN Date: Tue, 19 Mar 2013 13:57:19 +0900 To: Michael BlackHeart Subject: Re: A few problems Message-ID: <20130319045719.GB1437@michelle.cdnetworks.com> References: <20130318065938.GB1459@michelle.cdnetworks.com> <20130319045629.GA1437@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <20130319045629.GA1437@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 04:57:26 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 19, 2013 at 01:56:29PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 18, 2013 at 05:19:11PM +0400, Michael BlackHeart wrote: > > 2013/3/18 YongHyeon PYUN : > > > On Sat, Mar 16, 2013 at 01:08:06PM +0400, Michael BlackHeart wrote: > > >> Hello there. I've got a couple of things I don't get or can't handle. > > >> > > > > > > [...] > > > > > >> re0@pci0:4:0:0: class=0x020000 card=0x512c1462 chip=0x816810ec rev=0x02 hdr=0x00 > > >> vendor = 'Realtek Semiconductor Co., Ltd.' > > >> device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > >> class = network > > >> subclass = ethernet > > >> bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled > > >> bar [18] = type Memory, range 64, base 0xfeaff000, size 4096, enabled > > >> bar [20] = type Prefetchable Memory, range 64, base 0xf8ff0000, > > >> size 65536, enabled > > >> cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > >> cap 05[50] = MSI supports 1 message, 64 bit > > >> cap 10[70] = PCI-Express 1 endpoint IRQ 1 max data 128(256) link x1(x1) > > >> speed 2.5(2.5) > > >> cap 11[b0] = MSI-X supports 2 messages in map 0x20 enabled > > >> cap 03[d0] = VPD > > >> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected > > >> ecap 0002[140] = VC 1 max VC0 > > >> ecap 0003[160] = Serial 1 01000000684ce000 > > >> > > >> re0: flags=8843 metric 0 mtu 1500 > > >> description: ToISP > > >> options=8218b > > >> ether 00:21:85:1c:24:fa > > >> media: Ethernet autoselect (100baseTX ) > > >> status: active > > > > > > [...] > > > > > >> One is that re0 doesn't neogatiate direct link with a connected PC > > >> (using non-crossover UTP), but sk0 does that easy. It seems to me that > > >> according to RTL8111 chip specification there shouldn't be any > > >> problem, probably it's a driver problem? > > >> > > > > > > What is your link parter for re0? I don't remember whether the PHY > > > hardware really supports automatic MDI crossover detection. Even if > > > the PHY hardware does not support it, the link partner would be > > > able to do that. > > > > > > And could you show me the output of dmesg(re(4) and rgephy(4) only) > > > and "devinfo -rv | grep rgephy"? > > > > Here's info: > > > > re0: port > > 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xf8ff0000-0xf8ffffff irq 17 > > at device 0.0 on pci4 > > re0: Using 1 MSI-X message > > re0: Chip rev. 0x3c000000 > > re0: MAC rev. 0x00400000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > > 1000baseT-FDX-flow-master, auto, auto-flow > > re0: Ethernet address: 00:21:85:1c:24:fa > > > > devinfo -rv | grep rgephy > > rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x2 at phyno=1 > > > > This link connected to Realtek 8111E under Win7. > > I'll repeat that when it's connected to sk0, everything works. Of > > e1000phy(4) supports automatic crossover detection/correction. I > thought newer RealTek 8211 PHYs also support the feature but it > seems it's not enabled by default. Could you try attached patch and > let me know how it goes? > Attached patch. --k1lZvvs/B4yU6o8G Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rgephy.mdix.diff" Index: sys/dev/mii/rgephy.c =================================================================== --- sys/dev/mii/rgephy.c (revision 248449) +++ sys/dev/mii/rgephy.c (working copy) @@ -488,7 +488,7 @@ rgephy_load_dspcode(struct mii_softc *sc) static void rgephy_reset(struct mii_softc *sc) { - uint16_t ssr; + uint16_t pcr, ssr; if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev == 3) { /* RTL8211C(L) */ @@ -499,6 +499,15 @@ rgephy_reset(struct mii_softc *sc) } } + if (sc->mii_mpd_rev >= 2) { + pcr = PHY_READ(sc, RGEPHY_MII_PCR); + if ((pcr & RGEPHY_PCR_MDIX_AUTO) == 0) { + pcr &= ~RGEPHY_PCR_MDI_MASK; + pcr |= RGEPHY_PCR_MDIX_AUTO; + PHY_WRITE(sc, RGEPHY_MII_PCR, pcr); + } + } + mii_phy_reset(sc); DELAY(1000); rgephy_load_dspcode(sc); Index: sys/dev/mii/rgephyreg.h =================================================================== --- sys/dev/mii/rgephyreg.h (revision 248449) +++ sys/dev/mii/rgephyreg.h (working copy) @@ -137,6 +137,16 @@ #define RGEPHY_EXTSTS_T_FD_CAP 0x2000 /* 1000base-T FD capable */ #define RGEPHY_EXTSTS_T_HD_CAP 0x1000 /* 1000base-T HD capable */ +#define RGEPHY_MII_PCR 0x10 /* PHY Specific control register */ +#define RGEPHY_PCR_ASSERT_CRS 0x0800 +#define RGEPHY_PCR_FORCE_LINK 0x0400 +#define RGEPHY_PCR_MDI_MASK 0x0060 +#define RGEPHY_PCR_MDIX_AUTO 0x0040 +#define RGEPHY_PCR_MDIX_MANUAL 0x0020 +#define RGEPHY_PCR_MDI_MANUAL 0x0000 +#define RGEPHY_PCR_CLK125_DIS 0x0010 +#define RGEPHY_PCR_JABBER_DIS 0x0001 + /* RTL8211B(L)/RTL8211C(L) */ #define RGEPHY_MII_SSR 0x11 /* PHY Specific status register */ #define RGEPHY_SSR_S1000 0x8000 /* 1000Mbps */ --k1lZvvs/B4yU6o8G-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 08:20:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C3FBB9C5 for ; Tue, 19 Mar 2013 08:20:15 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1.freebsd.org (Postfix) with ESMTP id 60D5FAF1 for ; Tue, 19 Mar 2013 08:20:14 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id dr13so129217wgb.2 for ; Tue, 19 Mar 2013 01:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4G6sDAa8msU+wK9IF51ObKF4ayuKxgl0VSyYKA8bsX8=; b=VQaeIS3g4tJNBm1/Xj+/tWDHRbiKzcNYitYH1MakSP7tL8LGYjQbNCj81Lh2DfuWoY DoNwztpL/WmUbl8qcgO1KaAiMZVbENketinwDxoYKNz2f1rBgG435vTeBvgG5YZHeK+J ar3JDrEZECS3UV5SmPRu9PYjajvgmuLz7KyRnUCH3Y8aoI5lGocGFvgUyvr0n9AhUsDY nvASGPUgEFGH8Dh8wHVj+uEKSTzuB8nEGdMB42Eqhz/I5oe2fXFi3fmDDUPLvPxQ+D9m /cnvdFZ7+PflLtApZRpeOGrEmyOxyPsrV2uuYKSB0glj+LE7olKm3U6zwXDOEE5oPs3U RdJw== MIME-Version: 1.0 X-Received: by 10.194.77.129 with SMTP id s1mr1459491wjw.17.1363681214046; Tue, 19 Mar 2013 01:20:14 -0700 (PDT) Received: by 10.194.60.147 with HTTP; Tue, 19 Mar 2013 01:20:13 -0700 (PDT) In-Reply-To: <51471039.8070505@bsdforen.de> References: <51471039.8070505@bsdforen.de> Date: Tue, 19 Mar 2013 09:20:13 +0100 Message-ID: Subject: Re: System doesn't resume with active vbox VM From: David Demelier To: Dominic Fandrey Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 08:20:15 -0000 If the system reboots then you have a panic. Can you add dumpdev="AUTO" in your /etc/rc.conf? And then please give us a kernel panic backtrace : http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html 2013/3/18 Dominic Fandrey > My system doesn't resume with an active VirtualBox VM, in this case > Windows XP/32. I didn't test any other systems. > > The system comes back to the console screen, but doesn't get back > into X. After a couple of seconds (no dump occurs) I get the BIOS > screen and the system reboots with unclean file systems. > > # uname -a > FreeBSD mobileKamikaze.norad 9.1-STABLE FreeBSD 9.1-STABLE #3 r247136: Fri > Feb 22 00:52:22 CET 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 > amd64 > > Hardware virtualization is turned on, the additions are installed > in the VM. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:25:33 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BE8488A for ; Tue, 19 Mar 2013 17:25:33 +0000 (UTC) (envelope-from mich@freebsd.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0B92B802 for ; Tue, 19 Mar 2013 17:25:33 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id D4432289C34 for ; Tue, 19 Mar 2013 18:17:59 +0100 (CET) From: Michael Landin Hostbaek Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Core Dump / panic sleeping thread Message-Id: Date: Tue, 19 Mar 2013 18:18:06 +0100 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:25:33 -0000 Hi,=20 I am running a FreeBSD 9.1-REL system with GENERIC kernel: FreeBSD xxxxx 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Fri Jan 4 12:28:48 = CET 2013 root@xxxxx:/usr/obj/usr/src/sys/GENERIC amd64 It is crashing a couple of times per week, without any real pattern. = There are no hints in the syslog, and I only have the core debug to work = from... =20 It is a webserver, using a NFS mounted docroot (if it might help) - = here's the backtrace: This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock KDB: stack backtrace of thread 100256: #0 0xffffffff808f2d46 at mi_switch+0x186 #1 0xffffffff8092bb52 at sleepq_wait+0x42 #2 0xffffffff808f34d6 at _sleep+0x376 #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc #6 0xffffffff80818d37 at nfs_getattr+0x287 #7 0xffffffff8098f1c0 at vn_stat+0xb0 #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 #9 0xffffffff80986b55 at kern_statat+0x15 #10 0xffffffff80986c1a at sys_lstat+0x2a #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 panic: sleeping thread cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff809208a6 at kdb_backtrace+0x66 #1 0xffffffff808ea8be at panic+0x1ce #2 0xffffffff8092ed22 at propagate_priority+0x1d2 #3 0xffffffff8092fa4e at turnstile_wait+0x1be #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 #6 0xffffffff8081758c at ncl_readrpc+0xac #7 0xffffffff80824c45 at ncl_getpages+0x485 #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 #10 0xffffffff80b41cc3 at vm_fault+0x73 #11 0xffffffff80bd84b4 at trap_pfault+0x124 #12 0xffffffff80bd8c6c at trap+0x49c #13 0xffffffff80bc315f at calltrap+0x8 Uptime: 8d0h54m10s Dumping 2381 out of 24547 = MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from = /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from = /boot/kernel/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/if_em.ko...Reading symbols from = /boot/kernel/if_em.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_em.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from = /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from = /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=3DVariable "textdump" is not available. ) at pcpu.h:224 #1 0xffffffff808ea3a1 in kern_reboot (howto=3D260) at = /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff808ea897 in panic (fmt=3D0x1
) = at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff8092ed22 in propagate_priority (td=3DVariable "td" is not = available. ) at /usr/src/sys/kern/subr_turnstile.c:227 #4 0xffffffff8092fa4e in turnstile_wait (ts=3DVariable "ts" is not = available. ) at /usr/src/sys/kern/subr_turnstile.c:743 #5 0xffffffff808d8d48 in _mtx_lock_sleep (m=3D0xfffffe044a3c8238, = tid=3D18446741888664231936, opts=3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:471 #6 0xffffffff80820fa4 in nfscl_loadattrcache (vpp=3DVariable "vpp" is = not available. ) at /usr/src/sys/fs/nfsclient/nfs_clport.c:379 #7 0xffffffff8081758c in ncl_readrpc (vp=3D0xfffffe044a6cd780, = uiop=3D0xffffff86962fc650, cred=3DVariable "cred" is not available. ) at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:1369 #8 0xffffffff80824c45 in ncl_getpages (ap=3D0xffffff86962fc6f0) at = /usr/src/sys/fs/nfsclient/nfs_clbio.c:171 #9 0xffffffff80b5aa0c in vnode_pager_getpages = (object=3D0xfffffe016aa16570, m=3D0xffffff86962fc770, count=3DVariable = "count" is not available. ) at vnode_if.h:1154 #10 0xffffffff80b3fc93 in vm_fault_hold (map=3D0xfffffe007f7e3188, = vaddr=3D34366988288, fault_type=3D1 '\001', fault_flags=3DVariable = "fault_flags" is not available. ) at vm_pager.h:128 #11 0xffffffff80b41cc3 in vm_fault (map=3D0xfffffe007f7e3188, = vaddr=3D34366988288, fault_type=3DVariable "fault_type" is not = available. ) at /usr/src/sys/vm/vm_fault.c:229 #12 0xffffffff80bd84b4 in trap_pfault (frame=3D0xffffff86962fcc40, = usermode=3D1) at /usr/src/sys/amd64/amd64/trap.c:740 #13 0xffffffff80bd8c6c in trap (frame=3D0xffffff86962fcc40) at = /usr/src/sys/amd64/amd64/trap.c:358 #14 0xffffffff80bc315f in calltrap () at = /usr/src/sys/amd64/amd64/exception.S:228 #15 0x0000000802091386 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 Dump header from device /dev/mirror/gm0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 2496667648B (2381 MB) Blocksize: 512 Dumptime: Mon Mar 18 19:35:00 2013 Hostname: xxxxxxxxx Magic: FreeBSD Kernel Dump Version String: FreeBSD 9.1-RELEASE #0: Fri Jan 4 12:28:48 CET 2013 root@xxxxx:/usr/obj/usr/src/sys/GENERIC Panic String: sleeping thread Dump Parity: 826144189 Bounds: 5 Dump Status: good Any ideas?=20 Thanks,=20 /mich From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:34:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2BC9B7C for ; Tue, 19 Mar 2013 17:34:25 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by mx1.freebsd.org (Postfix) with ESMTP id 7EFE98AE for ; Tue, 19 Mar 2013 17:34:25 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so811202wid.6 for ; Tue, 19 Mar 2013 10:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=w3t+8/wPl0yxpPZv1BQuH4PgdkRnAigzLeo0r44khwQ=; b=avDHV1PdbWsuADYOb4ucRjDUMer5Rr4sO/uufiEwhDQM69ZXwVBu61oAEB7Psk1cJZ 2RvinpAdsckA3RHPhTh1Kq7VNQO4vycEbl1ockRd2Gu/euRMXYQUt5hnfu1fXcaXHt54 DinG4JtfqBJlqmB/GkU+v5wFRx+dvy1p6Dqu+KOg6mZmwh0eDF1gnG/3BRu1T4NBT5fZ mU6hTkjOm2S8+pSea6oxy3CY6uQFGfZuvsn8A3Kj50KsCycOXiLMvUUO/ffDVp+sbj3q 0L6TRQh0eVRg/1t4LWe2zf32YuPKkVNlmZG2+mXWwN+bEHdOpMM2f3DPVks6uuHUKWnx GIDQ== MIME-Version: 1.0 X-Received: by 10.180.78.168 with SMTP id c8mr4909984wix.27.1363714464620; Tue, 19 Mar 2013 10:34:24 -0700 (PDT) Received: by 10.194.60.147 with HTTP; Tue, 19 Mar 2013 10:34:24 -0700 (PDT) Date: Tue, 19 Mar 2013 18:34:24 +0100 Message-ID: Subject: Panic : bad pte From: David Demelier To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:34:25 -0000 Hello, There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can just say there is a problem in the 9.1-RELEASE because I had no panic before. What afraid me is that my production server also panic'ed a few days ago, fortunately it does not appears so often. This is a panic that happened on my desktop computer, with a graphic card. The crash usually appears when X starts. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: bad pte cpuid = 3 KDB: stack backtrace: Uptime: 2m31s Dumping 183 out of 1950 MB:..9%..18%..27%..35%..44%..53%..62%..79%..88%..96% Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0x0000000000000004 in ?? () #2 0xffffffff8048c156 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff8048c619 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 #4 0xffffffff8065f88a in pmap_remove_pages (pmap=0xfffffe0005a2fa60) at /usr/src/sys/amd64/amd64/pmap.c:4156 #5 0xffffffff8063d26b in vmspace_exit (td=0xfffffe0005a05470) at /usr/src/sys/vm/vm_map.c:422 #6 0xffffffff8045d725 in exit1 (td=0xfffffe0005a05470, rv=Variable "rv" is not available. ) at /usr/src/sys/kern/kern_exit.c:315 #7 0xffffffff8045e5ce in sys_sys_exit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:122 #8 0xffffffff8066737f in amd64_syscall (td=0xfffffe0005a05470, traced=0) at subr_syscall.c:135 #9 0xffffffff80652d97 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #10 0x0000000800d51c1c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Of course I may do something wrong, and I hope so but unfortunately I can't find any solution. May the nvidia driver be the problem? Kind regards -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:35:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 387D6C8C for ; Tue, 19 Mar 2013 17:35:32 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 115458CC for ; Tue, 19 Mar 2013 17:35:32 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta12.emeryville.ca.mail.comcast.net with comcast id DSMu1l00216AWCUACVbXGg; Tue, 19 Mar 2013 17:35:31 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id DVbW1l00e1t3BNj8SVbXLs; Tue, 19 Mar 2013 17:35:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BB5C373A1C; Tue, 19 Mar 2013 10:35:30 -0700 (PDT) Date: Tue, 19 Mar 2013 10:35:30 -0700 From: Jeremy Chadwick To: Michael Landin Hostbaek Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130319173530.GA72669@icarus.home.lan> 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363714531; bh=bJCQlSjjypg16V2QmQl1L0p/kMIBdUeYcgocJfVlRwQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=EeR9aoefWc4aV4gmyrg41a1pIbs7fDhweTib75OcMYFx2bXHYaGelacd5Q/v9FNuh dgqSuuvsAd0WoGInA4UX1vYK0FcmP4zt7Qv6ZDyRlmAy0CCxFRLN2MIwjymWYATD5e ITyDmDWdzYiWxr3sFzGz4otwh+qqwx9gAuQ6zd9yOXSpeZO2eTpFD9e0cw7vtZqE+6 +GW0h5ZW2NNv9oT9AJx9gMYPyp0V3tyHNDSxWz4Ou2gtapoHAksnyO438bQoTASY1u 0DWnB2q3OwQ6lT6c5u2cyRzHiC5Y5RAZROjyH4MPrcNiU8sTXwOvBEBXmthoW2YEV+ HjTAQ27cvthtQ== Cc: Rick Macklem , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:35:32 -0000 On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote: > Hi, > > I am running a FreeBSD 9.1-REL system with GENERIC kernel: > FreeBSD xxxxx 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Fri Jan 4 12:28:48 CET 2013 root@xxxxx:/usr/obj/usr/src/sys/GENERIC amd64 > > > It is crashing a couple of times per week, without any real pattern. There are no hints in the syslog, and I only have the core debug to work from... > > It is a webserver, using a NFS mounted docroot (if it might help) - here's the backtrace: > > > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock > KDB: stack backtrace of thread 100256: > #0 0xffffffff808f2d46 at mi_switch+0x186 > #1 0xffffffff8092bb52 at sleepq_wait+0x42 > #2 0xffffffff808f34d6 at _sleep+0x376 > #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce > #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d > #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc > #6 0xffffffff80818d37 at nfs_getattr+0x287 > #7 0xffffffff8098f1c0 at vn_stat+0xb0 > #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 > #9 0xffffffff80986b55 at kern_statat+0x15 > #10 0xffffffff80986c1a at sys_lstat+0x2a > #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 > #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 > panic: sleeping thread > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff809208a6 at kdb_backtrace+0x66 > #1 0xffffffff808ea8be at panic+0x1ce > #2 0xffffffff8092ed22 at propagate_priority+0x1d2 > #3 0xffffffff8092fa4e at turnstile_wait+0x1be > #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 > #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 > #6 0xffffffff8081758c at ncl_readrpc+0xac > #7 0xffffffff80824c45 at ncl_getpages+0x485 > #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c > #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 > #10 0xffffffff80b41cc3 at vm_fault+0x73 > #11 0xffffffff80bd84b4 at trap_pfault+0x124 > #12 0xffffffff80bd8c6c at trap+0x49c > #13 0xffffffff80bc315f at calltrap+0x8 > Uptime: 8d0h54m10s > Dumping 2381 out of 24547 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/kernel/geom_stripe.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/geom_stripe.ko > Reading symbols from /boot/kernel/if_em.ko...Reading symbols from /boot/kernel/if_em.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/if_em.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0xffffffff808ea3a1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff808ea897 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff8092ed22 in propagate_priority (td=Variable "td" is not available. > ) at /usr/src/sys/kern/subr_turnstile.c:227 > #4 0xffffffff8092fa4e in turnstile_wait (ts=Variable "ts" is not available. > ) at /usr/src/sys/kern/subr_turnstile.c:743 > #5 0xffffffff808d8d48 in _mtx_lock_sleep (m=0xfffffe044a3c8238, tid=18446741888664231936, opts=Variable "opts" is not available. > ) > at /usr/src/sys/kern/kern_mutex.c:471 > #6 0xffffffff80820fa4 in nfscl_loadattrcache (vpp=Variable "vpp" is not available. > ) at /usr/src/sys/fs/nfsclient/nfs_clport.c:379 > #7 0xffffffff8081758c in ncl_readrpc (vp=0xfffffe044a6cd780, uiop=0xffffff86962fc650, cred=Variable "cred" is not available. > ) > at /usr/src/sys/fs/nfsclient/nfs_clvnops.c:1369 > #8 0xffffffff80824c45 in ncl_getpages (ap=0xffffff86962fc6f0) at /usr/src/sys/fs/nfsclient/nfs_clbio.c:171 > #9 0xffffffff80b5aa0c in vnode_pager_getpages (object=0xfffffe016aa16570, m=0xffffff86962fc770, count=Variable "count" is not available. > ) > at vnode_if.h:1154 > #10 0xffffffff80b3fc93 in vm_fault_hold (map=0xfffffe007f7e3188, vaddr=34366988288, fault_type=1 '\001', fault_flags=Variable "fault_flags" is not available. > ) > at vm_pager.h:128 > #11 0xffffffff80b41cc3 in vm_fault (map=0xfffffe007f7e3188, vaddr=34366988288, fault_type=Variable "fault_type" is not available. > ) > at /usr/src/sys/vm/vm_fault.c:229 > #12 0xffffffff80bd84b4 in trap_pfault (frame=0xffffff86962fcc40, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:740 > #13 0xffffffff80bd8c6c in trap (frame=0xffffff86962fcc40) at /usr/src/sys/amd64/amd64/trap.c:358 > #14 0xffffffff80bc315f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 > #15 0x0000000802091386 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > > Dump header from device /dev/mirror/gm0s1b > Architecture: amd64 > Architecture Version: 2 > Dump Length: 2496667648B (2381 MB) > Blocksize: 512 > Dumptime: Mon Mar 18 19:35:00 2013 > Hostname: xxxxxxxxx > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 9.1-RELEASE #0: Fri Jan 4 12:28:48 CET 2013 > root@xxxxx:/usr/obj/usr/src/sys/GENERIC > Panic String: sleeping thread > Dump Parity: 826144189 > Bounds: 5 > Dump Status: good > > > > Any ideas? The kernel panic is happening in NFS-related code. Rick Macklem (and/or John Baldwin) should be able to help with this; I've CC'd both here. You're going to need to provide the following details: 1. Contents of /etc/rc.conf 2. Contents of /etc/sysctl.conf (if modified) 3. Contents of /etc/fstab 4. ifconfig -a 5. OS used by the NFS server, and all configuration details pertaining to that system You may also be asked to upgrade to 9.1-STABLE, as there may be fixes for whatever this is in base/stable/9 that are not in -RELEASE, but this is speculative on my part. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:43:40 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 75FCCE1D for ; Tue, 19 Mar 2013 17:43:40 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id 531EE92D for ; Tue, 19 Mar 2013 17:43:40 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta12.emeryville.ca.mail.comcast.net with comcast id DQoW1l0030QkzPwACVjg1f; Tue, 19 Mar 2013 17:43:40 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta02.emeryville.ca.mail.comcast.net with comcast id DVjf1l00M1t3BNj8NVjf7X; Tue, 19 Mar 2013 17:43:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5E31473A1C; Tue, 19 Mar 2013 10:43:39 -0700 (PDT) Date: Tue, 19 Mar 2013 10:43:39 -0700 From: Jeremy Chadwick To: David Demelier Subject: Re: Panic : bad pte Message-ID: <20130319174339.GA72813@icarus.home.lan> 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363715020; bh=36k+ma4Wwey0I286OYOEcz26YS53HSp4PkQtV55GBcI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=b8MQoDF6SjNmc9xkQwiPzGIxTVl3Q9J+OjiUzOL1ECBIebrsRdjd8FD+Cvmoqtm2n 9ZRX9+mN3+xI85xLO57CncuW2rBFOzySZZ7WDBEW0HJnkhD+1UFTQVQs574DRsByqx b8GJRbX466x1HWPD1iIogoDqKDKLBOoeOQJweZHROH/XL0gAtmMA9EVPr5krOWEeAe IiIy5vJLyRnnnO9imVTiEfULdq3opVzgO+7DRZ4DNv54rFFd9iYxmt+45QJrvieMaq iQA5cOfTLvksxhp5rVObG1WcYLaVQ5/ITzWETCGICmp98PRlwgSTeg1uUncRQH1Erx JZtUXrv2nSCWw== Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:43:40 -0000 On Tue, Mar 19, 2013 at 06:34:24PM +0100, David Demelier wrote: > Hello, > > There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can > just say there is a problem in the 9.1-RELEASE because I had no panic > before. What afraid me is that my production server also panic'ed a > few days ago, fortunately it does not appears so often. > > This is a panic that happened on my desktop computer, with a graphic > card. The crash usually appears when X starts. > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: bad pte > cpuid = 3 > KDB: stack backtrace: > Uptime: 2m31s > Dumping 183 out of 1950 MB:..9%..18%..27%..35%..44%..53%..62%..79%..88%..96% > > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0x0000000000000004 in ?? () > #2 0xffffffff8048c156 in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:448 > #3 0xffffffff8048c619 in panic (fmt=0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #4 0xffffffff8065f88a in pmap_remove_pages (pmap=0xfffffe0005a2fa60) > at /usr/src/sys/amd64/amd64/pmap.c:4156 > #5 0xffffffff8063d26b in vmspace_exit (td=0xfffffe0005a05470) at > /usr/src/sys/vm/vm_map.c:422 > #6 0xffffffff8045d725 in exit1 (td=0xfffffe0005a05470, rv=Variable > "rv" is not available. > ) at /usr/src/sys/kern/kern_exit.c:315 > #7 0xffffffff8045e5ce in sys_sys_exit (td=Variable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:122 > #8 0xffffffff8066737f in amd64_syscall (td=0xfffffe0005a05470, > traced=0) at subr_syscall.c:135 > #9 0xffffffff80652d97 in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:387 > #10 0x0000000800d51c1c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Of course I may do something wrong, and I hope so but unfortunately I > can't find any solution. May the nvidia driver be the problem? Interesting timing. Semi-recently (February) src/sys/amd64/amd64/pmap.c in 9.1-STABLE (not -RELEASE) was modified to increase the information shown for this specific type of panic. See revision 247079: http://svnweb.freebsd.org/base/stable/9/sys/amd64/amd64/pmap.c?view=log I've CC'd Konstantin Belousov (kib@), who should be able to help step you through getting information out of the crash dump, to help track down the root cause. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:46:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EADF7FD9; Tue, 19 Mar 2013 17:46:00 +0000 (UTC) (envelope-from mich@freebsd.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3A888960; Tue, 19 Mar 2013 17:46:00 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id C2C81289C18; Tue, 19 Mar 2013 18:45:52 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Core Dump / panic sleeping thread From: Michael Landin Hostbaek In-Reply-To: <20130319173530.GA72669@icarus.home.lan> Date: Tue, 19 Mar 2013 18:45:58 +0100 Message-Id: <0A794600-0D7C-4982-9665-1C39FEFCF8C1@freebsd.org> References: <20130319173530.GA72669@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Rick Macklem , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:46:01 -0000 On Mar 19, 2013, at 6:35 PM, Jeremy Chadwick wrote: > On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek = wrote: > The kernel panic is happening in NFS-related code. Rick Macklem = (and/or > John Baldwin) should be able to help with this; I've CC'd both here. OK, thanks.=20 >=20 > You're going to need to provide the following details: >=20 > 1. Contents of /etc/rc.conf sshd_enable=3D"YES" ntpdate_enable=3D"YES" ntpdate_hosts=3D"xx.xx.xx.xx" fsck_y_enable=3D"YES" named_enable=3D"YES" dumpdev=3D"AUTO" nfs_client_enable=3D"YES" rpc_lockd_enable=3D"YES" rpc_statd_enable=3D"YES" ifconfig_em0=3D"inet xx.xx.xx.xx netmask 255.255.255.0 broadcast = xx.xx.xx.xx" defaultrouter=3D"xx.xx.xx.xx" hostname=3D"xxxxxxxx" cloned_interfaces=3D"vlanXXXX" ifconfig_vlanXXXX=3D"inet xx.xx.xx.xx netmask 255.240.0.0 broadcast = xx.xx.xx.xx vlan XXXX vlandev em0" apache22_enable=3D"YES" pureftpd_enable=3D"YES" revealcloud_enable=3DYES > 2. Contents of /etc/sysctl.conf (if modified) vm.pmap.shpgperproc=3D250 > 3. Contents of /etc/fstab # Device Mountpoint FStype Options Dump = Pass# /dev/mirror/gm0s1a / ufs rw = 1 1 /dev/mirror/gm0s1b none swap sw = 0 0 /dev/mirror/gm0s1d /var ufs rw = 2 2 /dev/mirror/gm0s1e /logs ufs rw = 2 2 /dev/mirror/gm0s1f /extra ufs rw = 2 2 /dev/mirror/gm0s1g /usr ufs rw = 2 2 proc /proc procfs rw 0 = 0 xx.xx.xx.xx:/zpool-000xxx/www /mnt/www nfs rw = 0 0 xx.xx.xx.xx:/zpool-000xxx/data /mnt/data nfs rw,tcp = 0 0 linproc /compat/linux/proc linprocfs rw = 0 0 > 4. ifconfig -a em0: flags=3D8843 metric 0 mtu = 1500 = options=3D4219b ether 00:25:90:79:a5:ac inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.xx inet6 xxxxxx::a5ac%em0 prefixlen 64 scopeid 0x1=20 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=3D8c02 metric 0 mtu 1500 = options=3D4219b ether 00:25:90:79:a5:ad nd6 options=3D29 media: Ethernet autoselect status: no carrier lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb=20 inet 127.0.0.1 netmask 0xff000000=20 nd6 options=3D21 vlanXXXX: flags=3D8843 metric 0 = mtu 1500 options=3D103 ether 00:25:90:79:a5:ac inet xx.xx.xx.xx netmask 0xfff00000 broadcast xx.xx.xx.xx inet6 xxxxx:::5ac%vlanXXXX prefixlen 64 scopeid 0xc=20 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active vlan: XXXX parent interface: em0 > 5. OS used by the NFS server, and all configuration details pertaining > to that system This is a hosted service, so I do not have access to this - though I = believe this is a ZFS fs. Here's more info about the product: http://help.ovh.co.uk/Nas >=20 > You may also be asked to upgrade to 9.1-STABLE, as there may be fixes > for whatever this is in base/stable/9 that are not in -RELEASE, but = this > is speculative on my part. That is not a problem. I would simply like to confirm the issue, before = upgrading.=20 Thanks,=20 /mich From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 17:46:05 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 265AFFDB; Tue, 19 Mar 2013 17:46:05 +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 E7FEB961; Tue, 19 Mar 2013 17:46:03 +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 TAA16294; Tue, 19 Mar 2013 19:45:56 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <5148A454.1080303@FreeBSD.org> Date: Tue, 19 Mar 2013 19:45:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: Rick Macklem Subject: Re: Core Dump / panic sleeping thread References: <20130319173530.GA72669@icarus.home.lan> In-Reply-To: <20130319173530.GA72669@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:46:05 -0000 on 19/03/2013 19:35 Jeremy Chadwick said the following: > On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote: [snip] >> Unread portion of the kernel message buffer: >> Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock >> KDB: stack backtrace of thread 100256: >> #0 0xffffffff808f2d46 at mi_switch+0x186 >> #1 0xffffffff8092bb52 at sleepq_wait+0x42 >> #2 0xffffffff808f34d6 at _sleep+0x376 >> #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce >> #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d >> #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc >> #6 0xffffffff80818d37 at nfs_getattr+0x287 >> #7 0xffffffff8098f1c0 at vn_stat+0xb0 >> #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 >> #9 0xffffffff80986b55 at kern_statat+0x15 >> #10 0xffffffff80986c1a at sys_lstat+0x2a >> #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 >> #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 >> panic: sleeping thread >> cpuid = 0 >> KDB: stack backtrace: >> #0 0xffffffff809208a6 at kdb_backtrace+0x66 >> #1 0xffffffff808ea8be at panic+0x1ce >> #2 0xffffffff8092ed22 at propagate_priority+0x1d2 >> #3 0xffffffff8092fa4e at turnstile_wait+0x1be >> #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 >> #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 >> #6 0xffffffff8081758c at ncl_readrpc+0xac >> #7 0xffffffff80824c45 at ncl_getpages+0x485 >> #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c >> #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 >> #10 0xffffffff80b41cc3 at vm_fault+0x73 >> #11 0xffffffff80bd84b4 at trap_pfault+0x124 >> #12 0xffffffff80bd8c6c at trap+0x49c >> #13 0xffffffff80bc315f at calltrap+0x8 [snip] I think that the regular mutex which is acquired via NFSLOCKNODE() in nfscl_loadattrcache() can not be held across vnode_pager_setsize. I am not sure though when vap->va_size != np->n_size case is triggered. > You're going to need to provide the following details: > > 1. Contents of /etc/rc.conf > 2. Contents of /etc/sysctl.conf (if modified) > 3. Contents of /etc/fstab > 4. ifconfig -a > 5. OS used by the NFS server, and all configuration details pertaining > to that system > > You may also be asked to upgrade to 9.1-STABLE, as there may be fixes > for whatever this is in base/stable/9 that are not in -RELEASE, but this > is speculative on my part. > I do not see a need for any of these. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 18:28:12 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F05173B7; Tue, 19 Mar 2013 18:28:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEAEC2A; Tue, 19 Mar 2013 18:28:11 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2JIS2ra086351; Tue, 19 Mar 2013 20:28:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2JIS2ra086351 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2JIS2aA086350; Tue, 19 Mar 2013 20:28:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 19 Mar 2013 20:28:02 +0200 From: Konstantin Belousov To: Andriy Gapon Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130319182802.GQ3794@kib.kiev.ua> References: <20130319173530.GA72669@icarus.home.lan> <5148A454.1080303@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MPbGsu/ObDp3DThy" Content-Disposition: inline In-Reply-To: <5148A454.1080303@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , Rick Macklem , freebsd-stable@FreeBSD.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 18:28:12 -0000 --MPbGsu/ObDp3DThy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2013 at 07:45:56PM +0200, Andriy Gapon wrote: > on 19/03/2013 19:35 Jeremy Chadwick said the following: > > On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote: > [snip] > >> Unread portion of the kernel message buffer: > >> Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock > >> KDB: stack backtrace of thread 100256: > >> #0 0xffffffff808f2d46 at mi_switch+0x186 > >> #1 0xffffffff8092bb52 at sleepq_wait+0x42 > >> #2 0xffffffff808f34d6 at _sleep+0x376 > >> #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce > >> #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d > >> #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc > >> #6 0xffffffff80818d37 at nfs_getattr+0x287 > >> #7 0xffffffff8098f1c0 at vn_stat+0xb0 > >> #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 > >> #9 0xffffffff80986b55 at kern_statat+0x15 > >> #10 0xffffffff80986c1a at sys_lstat+0x2a > >> #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 > >> #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 > >> panic: sleeping thread > >> cpuid =3D 0 > >> KDB: stack backtrace: > >> #0 0xffffffff809208a6 at kdb_backtrace+0x66 > >> #1 0xffffffff808ea8be at panic+0x1ce > >> #2 0xffffffff8092ed22 at propagate_priority+0x1d2 > >> #3 0xffffffff8092fa4e at turnstile_wait+0x1be > >> #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 > >> #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 > >> #6 0xffffffff8081758c at ncl_readrpc+0xac > >> #7 0xffffffff80824c45 at ncl_getpages+0x485 > >> #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c > >> #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 > >> #10 0xffffffff80b41cc3 at vm_fault+0x73 > >> #11 0xffffffff80bd84b4 at trap_pfault+0x124 > >> #12 0xffffffff80bd8c6c at trap+0x49c > >> #13 0xffffffff80bc315f at calltrap+0x8 > [snip] >=20 > I think that the regular mutex which is acquired via NFSLOCKNODE() in > nfscl_loadattrcache() can not be held across vnode_pager_setsize. > I am not sure though when vap->va_size !=3D np->n_size case is triggered. When the file is modified on the server outside of the control of the client ? E.g., by direct access on the server, or from the other client. The only possible solution is to move the vnode_pager_setsize() outside the scope of the n_mtx. This is somewhat problematic because the nfsiod threads never bother to lock the vnode, so the truncation of the vm cache becomes racy. Still, this is probably the best cure. Another issue I see there is that vnode_pager_setsize() call is only performed for the VREG nodes. I believe that it is possible to cache the pages for the directories as well. Would you work out the patch ? --MPbGsu/ObDp3DThy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSK4yAAoJEJDCuSvBvK1BPxIQAKg8ejF+QzYx1OUIKiZQKILW lYwBtmTMrz+zYV8pshsJN31+nUm0Kd107MYFfsRNUeacegBwAYOFJi8daxDclZGo 83KdIisxPna5HXgsY9fNP3eJWxO1lh56wiqU6EPdYrpM68RIhiHVQAx9uq+70jah 4YvVuXzhwhzYh0DopY8gN+lBKZ1UGeZpK8TxduL35xk8ptCZSS9nwrDw7dljWj4k 1xdWCg2u1cqaCzMzqUFKOo80TPuoGW5dO3Kuox5bH1XSVqygR28QnOeqsNK2fjFy +ewyiFYOBusOqXSAYZdSNudem2bjL2cmWlm/P5h7RHb1wY1Kwc5F1BEmYw790ytO R1uzBmLesJYJ9r2e8K7e84/7VeRF7wzhtMlmYst+61v4TeZJ5zRaw7IElygfRhjD 4lYKZ2SXAOqC3sDUy0SaV/i8dedImnl+jyBQVEonulvUKMGsEw1bbFy8BwevZWt3 uDNu8EvLvKS3F3mlVVU2MXL8Qmt89eUB7c3u4+uKk2nWnv/TAqSeCkrEjPFj6qub jWMzDtnKA8Uquc6CLhjYNANX4BZw6uBbWTormHoYLIPYV0YLSw7+eWY4sCAtVSkT ecSCGAZ0h6tSX1Z5ut1VlRBuFhTPgdBCufRh+jDO1TLMXkz7yqc0W0HJ1ym+Fivh vKEutAea8wVmDNQkoTux =IAz5 -----END PGP SIGNATURE----- --MPbGsu/ObDp3DThy-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 19 23:38:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7464438F; Tue, 19 Mar 2013 23:38:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 03424D71; Tue, 19 Mar 2013 23:38:15 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAHr2SFGDaFvO/2dsb2JhbABDiBC8f4FbdIIkAQEBAwEBAQEgBCcgCxsOChEZAgQlAQkmBggHBAEcBIdtBgyvNYJAkAmNXnwZGweCLYETA488hGWCPoEfjVaCDYMmIDKBBTU X-IronPort-AV: E=Sophos;i="4.84,874,1355115600"; d="scan'208";a="21996215" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 19 Mar 2013 19:37:43 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 81BD5B3FAE; Tue, 19 Mar 2013 19:37:43 -0400 (EDT) Date: Tue, 19 Mar 2013 19:37:43 -0400 (EDT) From: Rick Macklem To: Andriy Gapon Message-ID: <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <5148A454.1080303@FreeBSD.org> Subject: Re: Core Dump / panic sleeping thread MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4081735_1266366528.1363736263504" X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:38:16 -0000 ------=_Part_4081735_1266366528.1363736263504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Andriy Gapon wrote: > on 19/03/2013 19:35 Jeremy Chadwick said the following: > > On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek > > wrote: > [snip] > >> Unread portion of the kernel message buffer: > >> Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock > >> KDB: stack backtrace of thread 100256: > >> #0 0xffffffff808f2d46 at mi_switch+0x186 > >> #1 0xffffffff8092bb52 at sleepq_wait+0x42 > >> #2 0xffffffff808f34d6 at _sleep+0x376 > >> #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce > >> #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d > >> #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc > >> #6 0xffffffff80818d37 at nfs_getattr+0x287 > >> #7 0xffffffff8098f1c0 at vn_stat+0xb0 > >> #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 > >> #9 0xffffffff80986b55 at kern_statat+0x15 > >> #10 0xffffffff80986c1a at sys_lstat+0x2a > >> #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 > >> #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 > >> panic: sleeping thread > >> cpuid = 0 > >> KDB: stack backtrace: > >> #0 0xffffffff809208a6 at kdb_backtrace+0x66 > >> #1 0xffffffff808ea8be at panic+0x1ce > >> #2 0xffffffff8092ed22 at propagate_priority+0x1d2 > >> #3 0xffffffff8092fa4e at turnstile_wait+0x1be > >> #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 > >> #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 > >> #6 0xffffffff8081758c at ncl_readrpc+0xac > >> #7 0xffffffff80824c45 at ncl_getpages+0x485 > >> #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c > >> #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 > >> #10 0xffffffff80b41cc3 at vm_fault+0x73 > >> #11 0xffffffff80bd84b4 at trap_pfault+0x124 > >> #12 0xffffffff80bd8c6c at trap+0x49c > >> #13 0xffffffff80bc315f at calltrap+0x8 > [snip] > > I think that the regular mutex which is acquired via NFSLOCKNODE() in > nfscl_loadattrcache() can not be held across vnode_pager_setsize. > I am not sure though when vap->va_size != np->n_size case is > triggered. > Yep, I'd agree to that. The same bug is in the old NFS client and the new NFS client cribbed the code from there. I have attached a simple patch that unlocks the mutex for the vnode_pager_setsize() call. Maybe you could test it? Thanks for reporting this, rick ps: Hopefully "patch" can apply this patch (there have been recent changes to this file, so the line#s could be off). It should be easy to do manually if not. The change is in nfscl_loadattrcache() in sys/fs/nfsclient/nfs_clport.c. > > You're going to need to provide the following details: > > > > 1. Contents of /etc/rc.conf > > 2. Contents of /etc/sysctl.conf (if modified) > > 3. Contents of /etc/fstab > > 4. ifconfig -a > > 5. OS used by the NFS server, and all configuration details > > pertaining > > to that system > > > > You may also be asked to upgrade to 9.1-STABLE, as there may be > > fixes > > for whatever this is in base/stable/9 that are not in -RELEASE, but > > this > > is speculative on my part. > > > I do not see a need for any of these. > > -- > Andriy Gapon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" ------=_Part_4081735_1266366528.1363736263504 Content-Type: text/x-patch; name=loadattrcache.patch Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=loadattrcache.patch LS0tIGZzL25mc2NsaWVudC9uZnNfY2xwb3J0LmMuc2F2aXQJMjAxMy0wMy0xOSAxODozNzozMy4w MDAwMDAwMDAgLTA0MDAKKysrIGZzL25mc2NsaWVudC9uZnNfY2xwb3J0LmMJMjAxMy0wMy0xOSAx ODo0NDoyMS4wMDAwMDAwMDAgLTA0MDAKQEAgLTQ0NCw3ICs0NDQsOSBAQCBuZnNjbF9sb2FkYXR0 cmNhY2hlKHN0cnVjdCB2bm9kZSAqKnZwcCwgCiAJCQkJbnAtPm5fc2l6ZSA9IHZhcC0+dmFfc2l6 ZTsKIAkJCQlucC0+bl9mbGFnIHw9IE5TSVpFQ0hBTkdFRDsKIAkJCX0KKwkJCU5GU1VOTE9DS05P REUobnApOwogCQkJdm5vZGVfcGFnZXJfc2V0c2l6ZSh2cCwgbnAtPm5fc2l6ZSk7CisJCQlORlNM T0NLTk9ERShucCk7CiAJCX0gZWxzZSB7CiAJCQlucC0+bl9zaXplID0gdmFwLT52YV9zaXplOwog CQl9Cg== ------=_Part_4081735_1266366528.1363736263504-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 09:33:47 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52C712BD; Wed, 20 Mar 2013 09:33:47 +0000 (UTC) (envelope-from mich@FreeBSD.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9EA9B4; Wed, 20 Mar 2013 09:33:47 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id 5570C289C23; Wed, 20 Mar 2013 10:33:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Core Dump / panic sleeping thread From: Michael Landin Hostbaek In-Reply-To: <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> Date: Wed, 20 Mar 2013 10:33:45 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6D020B6E-14F1-4E29-B93A-E3F2795D7860@FreeBSD.org> References: <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 09:33:47 -0000 On Mar 20, 2013, at 12:37 AM, Rick Macklem wrote: >> > Yep, I'd agree to that. The same bug is in the old NFS client and > the new NFS client cribbed the code from there. > > I have attached a simple patch that unlocks the mutex for the > vnode_pager_setsize() call. Maybe you could test it? > > Thanks for reporting this, rick > ps: Hopefully "patch" can apply this patch (there have been > recent changes to this file, so the line#s could be off). > It should be easy to do manually if not. The change is > in nfscl_loadattrcache() in sys/fs/nfsclient/nfs_clport.c. Thanks Rick, it's compiling right now. I will let you know if the problem persists. /mich ps. the patch worked perfectly up against REL9.1 From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 09:49:59 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C8316A0B; Wed, 20 Mar 2013 09:49:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3D802AB1; Wed, 20 Mar 2013 09:49:59 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2K9nsYr048555; Wed, 20 Mar 2013 11:49:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2K9nsYr048555 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2K9nsJU048554; Wed, 20 Mar 2013 11:49:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 11:49:54 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320094954.GV3794@kib.kiev.ua> References: <5148A454.1080303@FreeBSD.org> <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UDXac3CCxvoffKng" Content-Disposition: inline In-Reply-To: <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 09:49:59 -0000 --UDXac3CCxvoffKng Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 19, 2013 at 07:37:43PM -0400, Rick Macklem wrote: > Andriy Gapon wrote: > > on 19/03/2013 19:35 Jeremy Chadwick said the following: > > > On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek > > > wrote: > > [snip] > > >> Unread portion of the kernel message buffer: > > >> Sleeping thread (tid 100256, pid 85641) owns a non-sleepable lock > > >> KDB: stack backtrace of thread 100256: > > >> #0 0xffffffff808f2d46 at mi_switch+0x186 > > >> #1 0xffffffff8092bb52 at sleepq_wait+0x42 > > >> #2 0xffffffff808f34d6 at _sleep+0x376 > > >> #3 0xffffffff80b4f3ae at vm_object_page_remove+0x2ce > > >> #4 0xffffffff80b5ac7d at vnode_pager_setsize+0x17d > > >> #5 0xffffffff8082102c at nfscl_loadattrcache+0x2cc > > >> #6 0xffffffff80818d37 at nfs_getattr+0x287 > > >> #7 0xffffffff8098f1c0 at vn_stat+0xb0 > > >> #8 0xffffffff809869d9 at kern_statat_vnhook+0xf9 > > >> #9 0xffffffff80986b55 at kern_statat+0x15 > > >> #10 0xffffffff80986c1a at sys_lstat+0x2a > > >> #11 0xffffffff80bd7ae6 at amd64_syscall+0x546 > > >> #12 0xffffffff80bc3447 at Xfast_syscall+0xf7 > > >> panic: sleeping thread > > >> cpuid =3D 0 > > >> KDB: stack backtrace: > > >> #0 0xffffffff809208a6 at kdb_backtrace+0x66 > > >> #1 0xffffffff808ea8be at panic+0x1ce > > >> #2 0xffffffff8092ed22 at propagate_priority+0x1d2 > > >> #3 0xffffffff8092fa4e at turnstile_wait+0x1be > > >> #4 0xffffffff808d8d48 at _mtx_lock_sleep+0xd8 > > >> #5 0xffffffff80820fa4 at nfscl_loadattrcache+0x244 > > >> #6 0xffffffff8081758c at ncl_readrpc+0xac > > >> #7 0xffffffff80824c45 at ncl_getpages+0x485 > > >> #8 0xffffffff80b5aa0c at vnode_pager_getpages+0x9c > > >> #9 0xffffffff80b3fc93 at vm_fault_hold+0x673 > > >> #10 0xffffffff80b41cc3 at vm_fault+0x73 > > >> #11 0xffffffff80bd84b4 at trap_pfault+0x124 > > >> #12 0xffffffff80bd8c6c at trap+0x49c > > >> #13 0xffffffff80bc315f at calltrap+0x8 > > [snip] > >=20 > > I think that the regular mutex which is acquired via NFSLOCKNODE() in > > nfscl_loadattrcache() can not be held across vnode_pager_setsize. > > I am not sure though when vap->va_size !=3D np->n_size case is > > triggered. > >=20 > Yep, I'd agree to that. The same bug is in the old NFS client and > the new NFS client cribbed the code from there. >=20 > I have attached a simple patch that unlocks the mutex for the > vnode_pager_setsize() call. Maybe you could test it? >=20 > Thanks for reporting this, rick > ps: Hopefully "patch" can apply this patch (there have been > recent changes to this file, so the line#s could be off). > It should be easy to do manually if not. The change is > in nfscl_loadattrcache() in sys/fs/nfsclient/nfs_clport.c. >=20 >=20 > > > You're going to need to provide the following details: > > > > > > 1. Contents of /etc/rc.conf > > > 2. Contents of /etc/sysctl.conf (if modified) > > > 3. Contents of /etc/fstab > > > 4. ifconfig -a > > > 5. OS used by the NFS server, and all configuration details > > > pertaining > > > to that system > > > > > > You may also be asked to upgrade to 9.1-STABLE, as there may be > > > fixes > > > for whatever this is in base/stable/9 that are not in -RELEASE, but > > > this > > > is speculative on my part. > > > > > I do not see a need for any of these. > >=20 > > -- > > Andriy Gapon > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to > > "freebsd-stable-unsubscribe@freebsd.org" > --- fs/nfsclient/nfs_clport.c.savit 2013-03-19 18:37:33.000000000 -0400 > +++ fs/nfsclient/nfs_clport.c 2013-03-19 18:44:21.000000000 -0400 > @@ -444,7 +444,9 @@ nfscl_loadattrcache(struct vnode **vpp,=20 > np->n_size =3D vap->va_size; > np->n_flag |=3D NSIZECHANGED; > } > + NFSUNLOCKNODE(np); > vnode_pager_setsize(vp, np->n_size); > + NFSLOCKNODE(np); > } else { > np->n_size =3D vap->va_size; > } I do not like it. As I said in the previous response to Andrey, I think that moving the vnode_pager_setsize() after the unlock is better, since it reduces races with other thread seeing half-done attribute update or making attribute change simultaneously. --UDXac3CCxvoffKng Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSYZBAAoJEJDCuSvBvK1BAdIQAItosWsItKlK1fjCuub9R/Q0 0wPSKBIjKmgKHiHtIVEZJz9l9vCsALfRQCqYiFE2U3N5zaQUIXEQl9ZXajzWSOVR uNAXJ+kx7g0ChiwVE9vK8+7LGoW5c6eIJMymefLPZ0B1G3kpGJzqnc90HzEXMB17 Xsdfv+RXzSmstNxbukXk7DwRtRmUtoyaV0t07P5NOUFVnLclgO9ycI2vgmP5tYFe 5r6V78XH5tZLahzs9tMwqEGwTPQWOiveeXLR0mM9QP77hP/16i8dSvmWhkuxZunY abSELYVvDi39yHn8pK+YN1KtVJV5OJoHP4HzMM4wH+NeAyAfZh/bjPJrm1prdqfW BKwryxjj42TxxZrGS2l+gfBnr4EIhJIfPs36dw2p6H7O9oDbhQzmwVt+hJTB0ISZ PjQx9Lxjm7dDYIQdzIMqfMP6jdYwljSjIgsABMONF18p+QGh86o/FpAkuCxnmcqE KnPhMVhEgB/LDXJZBUNK3PWvnytJYZSmnErYKmXABA51R6OUqLNdN0KjdE4OgUXx BXlvNOfkZHog3Efu0jjYhTCGEK9X8oSJFcvotl/XdR5CyMKOzC3qrhbAIPuIOaLK I4wYy8HFeqAD6IR9ZLIwS4HBMm4IS+k2ZztLvpTQn5g08MHM19Q0/Z2J6t8PTUO2 AWclE8ePLKak9nKmdCwm =XLwM -----END PGP SIGNATURE----- --UDXac3CCxvoffKng-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 10:43:34 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3B9E767 for ; Wed, 20 Mar 2013 10:43:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 30779E06 for ; Wed, 20 Mar 2013 10:43:33 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-1-201.lns20.adl2.internode.on.net [121.45.1.201]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2KAh8bW060020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 21:13:14 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Mar 2013 21:13:08 +1030 Subject: Empty @cwd in some ports To: "freebsd-stable@freebsd.org stable" Message-Id: <2AB1C509-75DF-4CDC-91D7-8C1A3670065F@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 10:43:34 -0000 I noticed I have a lot of ports which have an empty @cwd line in the = +CONTENTS file (even after reinstalling). For example a2ps.. @comment PKG_FORMAT_REVISION:1.1 @name a2ps-a4-4.13b_4 @comment ORIGIN:print/a2ps-a4 @cwd /usr/local @pkgdep xineramaproto-1.2.1 @comment DEPORIGIN:x11/xineramaproto @exec /sbin/ldconfig -m /usr/local/lib @unexec /sbin/ldconfig -R @comment OPTIONS:+NLS -I18N +EMACS @cwd=20 @dirrm share/licenses/a2ps-a4-4.13b_4 And curl.. @comment PKG_FORMAT_REVISION:1.1 @name curl-7.24.0_2 @comment ORIGIN:ftp/curl @cwd /usr/local @pkgdep ca_root_nss-3.14.3 @comment DEPORIGIN:security/ca_root_nss @comment OPTIONS:-CARES -CURL_DEBUG -GNUTLS +IPV6 -KERBEROS4 -LDAP = -LDAPS -LIBIDN -LIBSSH2 -NTLM +OPENSSL +CA_BUNDLE +PROXY -RTMP @comment OPTIONS:-TRACKMEMORY @cwd=20 @dirrm share/licenses/curl-7.24.0_2 @unexec rmdir %D/share/licenses 2>/dev/null || true This seems pretty broken but I am not sure what causes it :( [midget 21:09] /var/db/pkg >egrep -l '@cwd $' */+CONTENTS| wc -l 300 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 11:13:07 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5B59BCDB; Wed, 20 Mar 2013 11:13:07 +0000 (UTC) (envelope-from mich@FreeBSD.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id 21ED1F3C; Wed, 20 Mar 2013 11:13:07 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id 975DF289C18; Wed, 20 Mar 2013 12:12:58 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Core Dump / panic sleeping thread From: Michael Landin Hostbaek In-Reply-To: <20130320094954.GV3794@kib.kiev.ua> Date: Wed, 20 Mar 2013 12:13:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> References: <5148A454.1080303@FreeBSD.org> <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> <20130320094954.GV3794@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , Rick Macklem , freebsd-stable@FreeBSD.org, Andriy Gapon , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:13:07 -0000 On Mar 20, 2013, at 10:49 AM, Konstantin Belousov = wrote: >=20 > I do not like it. As I said in the previous response to Andrey, > I think that moving the vnode_pager_setsize() after the unlock is > better, since it reduces races with other thread seeing half-done > attribute update or making attribute change simultaneously. OK - so should I wait for another patch - or?=20 Thanks, /mich From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 11:37:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00231409 for ; Wed, 20 Mar 2013 11:37:04 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7CDC1 for ; Wed, 20 Mar 2013 11:37:04 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so858855eek.29 for ; Wed, 20 Mar 2013 04:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=76YybcoIzZFdDUiy1LtdMFqtfGnCO0LJLtEAR9yRHIA=; b=mVBPV6vvELhXgCD3rXQQAQ9m2SLXSxNaywPYtIv8/k1gWFvlCtItTnzKlEb+72IB2d CYNFtScE5vmD8vfdGFU0Jj4gViABekW7gE3VNDLMWgrQu03wTNffxqpAUys2vhd6EdzY +pcZDPdnWWhB7EoGnlfoFba11DrHziRR2Mf0J6DjWA+feb3/hiFlNInzZZ0jIBHPCcpq Z5hC4HJJHklqBTMMlB6tpAQdIRbKUNCKGfuW9x/IGaFGGobce6ViSSdefpfir1OQ5GGO fsaeKh7Zox1zOWFb7Oyabn+uDkfd3oNn/oPjsEKnPO6eGRWj4CZgYpE7iLyQVggZcjIE bjGQ== X-Received: by 10.14.219.7 with SMTP id l7mr71015919eep.12.1363779423325; Wed, 20 Mar 2013 04:37:03 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id z45sm2074571eeu.10.2013.03.20.04.37.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Mar 2013 04:37:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 20 Mar 2013 12:36:59 +0100 From: Baptiste Daroussin To: Daniel O'Connor Subject: Re: Empty @cwd in some ports Message-ID: <20130320113659.GN67352@ithaqua.etoilebsd.net> References: <2AB1C509-75DF-4CDC-91D7-8C1A3670065F@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dPW7zu3hTOhZvCDO" Content-Disposition: inline In-Reply-To: <2AB1C509-75DF-4CDC-91D7-8C1A3670065F@gsoft.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:37:05 -0000 --dPW7zu3hTOhZvCDO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:13:08PM +1030, Daniel O'Connor wrote: > I noticed I have a lot of ports which have an empty @cwd line in the +CON= TENTS file (even after reinstalling). >=20 > For example a2ps.. > @comment PKG_FORMAT_REVISION:1.1 > @name a2ps-a4-4.13b_4 > @comment ORIGIN:print/a2ps-a4 > @cwd /usr/local > @pkgdep xineramaproto-1.2.1 > @comment DEPORIGIN:x11/xineramaproto > > @exec /sbin/ldconfig -m /usr/local/lib > @unexec /sbin/ldconfig -R > @comment OPTIONS:+NLS -I18N +EMACS > @cwd=20 > @dirrm share/licenses/a2ps-a4-4.13b_4 >=20 > And curl.. > @comment PKG_FORMAT_REVISION:1.1 > @name curl-7.24.0_2 > @comment ORIGIN:ftp/curl > @cwd /usr/local > @pkgdep ca_root_nss-3.14.3 > @comment DEPORIGIN:security/ca_root_nss > > @comment OPTIONS:-CARES -CURL_DEBUG -GNUTLS +IPV6 -KERBEROS4 -LDAP -LDAPS= -LIBIDN -LIBSSH2 -NTLM +OPENSSL +CA_BUNDLE +PROXY -RTMP > @comment OPTIONS:-TRACKMEMORY > @cwd=20 > @dirrm share/licenses/curl-7.24.0_2 > @unexec rmdir %D/share/licenses 2>/dev/null || true >=20 > This seems pretty broken but I am not sure what causes it :( > [midget 21:09] /var/db/pkg >egrep -l '@cwd $' */+CONTENTS| wc -l > 300 >=20 > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Empty cwd is normal, it is equivalent to @cwd %%PREFIX%% regards, Bapt --dPW7zu3hTOhZvCDO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFJn1sACgkQ8kTtMUmk6EwrGQCfe69ubUmH4QhsR2FOPHRYFpbn aWQAn31hi9T1YH5q+YBGhnVo5qP4VLdX =JbkN -----END PGP SIGNATURE----- --dPW7zu3hTOhZvCDO-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 12:36:51 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8864B13C; Wed, 20 Mar 2013 12:36:51 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id F14483EF; Wed, 20 Mar 2013 12:36:50 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-7-6.lns21.adl2.internode.on.net [14.2.7.6]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2KCaa7Y063451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Mar 2013 23:06:42 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Empty @cwd in some ports Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20130320113659.GN67352@ithaqua.etoilebsd.net> Date: Wed, 20 Mar 2013 23:06:35 +1030 Content-Transfer-Encoding: 7bit Message-Id: <34858823-BA4B-4553-90B2-D5553415914D@gsoft.com.au> References: <2AB1C509-75DF-4CDC-91D7-8C1A3670065F@gsoft.com.au> <20130320113659.GN67352@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1499) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 12:36:51 -0000 On 20/03/2013, at 22:06, Baptiste Daroussin wrote: > Empty cwd is normal, it is equivalent to @cwd %%PREFIX%% OK thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 13:14:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3BEFD02 for ; Wed, 20 Mar 2013 13:14:37 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by mx1.freebsd.org (Postfix) with ESMTP id 333E47BC for ; Wed, 20 Mar 2013 13:14:36 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id da11so1349919veb.38 for ; Wed, 20 Mar 2013 06:14:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version:x-gm-message-state; bh=YgLwQsgZ5vp4a377MqA7vDPx+KV1fDQJt0e7VshXCfY=; b=RaL0fsdvXdoytgIeP+X5K8WBTVs/M/xe8hx6tmqKCJHr90Ki8nqCjYPVDolvhUGmEg BG23qKV50vnJUWmJS0VVR5DAVnYTX6FKDBwEWq1gvJkdO6jY5fGlZnVsCKpi8ZIWR6zT 0Z/WjO3SVuK8G+x1BjZY5XeuMcU9g5pFbN/WgMQYJQj1blKJ9cpzLD/QmU9CvZRvGN/x AVm2LLoTvioSG4Ncyi+mu72P32C9Yuluzsh2q+yerQIoP8Itni85K6B4LGvIayB2+MSx Qet4s/ZmqNMI4oHWcSfzDS0M4bB6qof9ZvEPcOioOZs1INMMVnU7WsouFziQmKfZQ2K8 uaMg== X-Received: by 10.52.30.48 with SMTP id p16mr6723610vdh.118.1363785276214; Wed, 20 Mar 2013 06:14:36 -0700 (PDT) Received: from [97.1.33.217] (217.sub-97-1-33.myvzw.com. [97.1.33.217]) by mx.google.com with ESMTPS id dh7sm35005269vdb.0.2013.03.20.06.14.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 06:14:34 -0700 (PDT) Subject: Re: Core Dump / panic sleeping thread References: <20130319173530.GA72669@icarus.home.lan> <0A794600-0D7C-4982-9665-1C39FEFCF8C1@freebsd.org> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B146) In-Reply-To: <0A794600-0D7C-4982-9665-1C39FEFCF8C1@freebsd.org> Message-Id: <20F03334-E1AA-4FEA-B45F-33547D7E454D@longcount.org> Date: Wed, 20 Mar 2013 09:14:30 -0400 To: "freebsd-stable@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQkjAaZsGoCZQnv5FGU2uc3saJLKb1fHvqa66c1SvyRfaTJmTng1+MrqfeXj9AdQlp5/mJgU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:14:37 -0000 Comments in line . --- On Mar 19, 2013, at 1:45 PM, Michael Landin Hostbaek wrot= e: >=20 > On Mar 19, 2013, at 6:35 PM, Jeremy Chadwick wrote: >=20 >> On Tue, Mar 19, 2013 at 06:18:06PM +0100, Michael Landin Hostbaek wrote: >> The kernel panic is happening in NFS-related code. Rick Macklem (and/or >> John Baldwin) should be able to help with this; I've CC'd both here. >=20 > OK, thanks.=20 >=20 >=20 >>=20 >> You're going to need to provide the following details: >>=20 >> 1. Contents of /etc/rc.conf >=20 > sshd_enable=3D"YES" > ntpdate_enable=3D"YES" > ntpdate_hosts=3D"xx.xx.xx.xx" > fsck_y_enable=3D"YES" > named_enable=3D"YES" > dumpdev=3D"AUTO" > nfs_client_enable=3D"YES" > rpc_lockd_enable=3D"YES" > rpc_statd_enable=3D"YES" > ifconfig_em0=3D"inet xx.xx.xx.xx netmask 255.255.255.0 broadcast xx.xx.xx.= xx" > defaultrouter=3D"xx.xx.xx.xx" > hostname=3D"xxxxxxxx" > cloned_interfaces=3D"vlanXXXX" > ifconfig_vlanXXXX=3D"inet xx.xx.xx.xx netmask 255.240.0.0 broadcast xx.xx.= xx.xx vlan XXXX vlandev em0" > apache22_enable=3D"YES" > pureftpd_enable=3D"YES" > revealcloud_enable=3DYES >=20 >=20 >> 2. Contents of /etc/sysctl.conf (if modified) >=20 > vm.pmap.shpgperproc=3D250 >=20 Small side note. This sysctl is no longer valid . It's had no effect after 7= .2 iirc .=20 >> 3. Contents of /etc/fstab >=20 > # Device Mountpoint FStype Options Dump Pa= ss# > /dev/mirror/gm0s1a / ufs rw 1 1 > /dev/mirror/gm0s1b none swap sw 0 0 > /dev/mirror/gm0s1d /var ufs rw 2 2 > /dev/mirror/gm0s1e /logs ufs rw 2 2 > /dev/mirror/gm0s1f /extra ufs rw 2 2 > /dev/mirror/gm0s1g /usr ufs rw 2 2 > proc /proc procfs rw 0 0 > xx.xx.xx.xx:/zpool-000xxx/www /mnt/www nfs rw 0 0 > xx.xx.xx.xx:/zpool-000xxx/data /mnt/data nfs rw,tcp 0 0= > linproc /compat/linux/proc linprocfs rw 0 0 >=20 >=20 >> 4. ifconfig -a >=20 > em0: flags=3D8843 metric 0 mtu 150= 0 > options=3D4219b > ether 00:25:90:79:a5:ac > inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.xx > inet6 xxxxxx::a5ac%em0 prefixlen 64 scopeid 0x1=20 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > em1: flags=3D8c02 metric 0 mtu 1500 > options=3D4219b > ether 00:25:90:79:a5:ad > nd6 options=3D29 > media: Ethernet autoselect > status: no carrier > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D600003 > inet6 ::1 prefixlen 128=20 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb=20 > inet 127.0.0.1 netmask 0xff000000=20 > nd6 options=3D21 > vlanXXXX: flags=3D8843 metric 0 mt= u 1500 > options=3D103 > ether 00:25:90:79:a5:ac > inet xx.xx.xx.xx netmask 0xfff00000 broadcast xx.xx.xx.xx > inet6 xxxxx:::5ac%vlanXXXX prefixlen 64 scopeid 0xc=20 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: XXXX parent interface: em0 >=20 >=20 >> 5. OS used by the NFS server, and all configuration details pertaining >> to that system >=20 > This is a hosted service, so I do not have access to this - though I belie= ve this is a ZFS fs. > Here's more info about the product: http://help.ovh.co.uk/Nas >=20 >=20 >>=20 >> You may also be asked to upgrade to 9.1-STABLE, as there may be fixes >> for whatever this is in base/stable/9 that are not in -RELEASE, but this >> is speculative on my part. >=20 > That is not a problem. I would simply like to confirm the issue, before up= grading.=20 >=20 >=20 > Thanks,=20 >=20 > /mich >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Mark saad | mark.saad@longcount.org From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 13:22:31 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CED7C1AA; Wed, 20 Mar 2013 13:22:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 286EF824; Wed, 20 Mar 2013 13:22:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KDMMRU086517; Wed, 20 Mar 2013 15:22:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KDMMRU086517 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KDMMfk086516; Wed, 20 Mar 2013 15:22:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 15:22:22 +0200 From: Konstantin Belousov To: Michael Landin Hostbaek Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320132222.GC3794@kib.kiev.ua> References: <5148A454.1080303@FreeBSD.org> <153890828.4081736.1363736263509.JavaMail.root@erie.cs.uoguelph.ca> <20130320094954.GV3794@kib.kiev.ua> <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FqaIGMzVeQkeDzz8" Content-Disposition: inline In-Reply-To: <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Rick Macklem , freebsd-stable@FreeBSD.org, Andriy Gapon , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:22:31 -0000 --FqaIGMzVeQkeDzz8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote: >=20 > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov w= rote: > >=20 > > I do not like it. As I said in the previous response to Andrey, > > I think that moving the vnode_pager_setsize() after the unlock is > > better, since it reduces races with other thread seeing half-done > > attribute update or making attribute change simultaneously. >=20 > OK - so should I wait for another patch - or?=20 I think the following is what I mean. As an additional note, why nfs client does not trim the buffers when server reported node size change ? diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c index a07a67f..4fe2e35 100644 --- a/sys/fs/nfsclient/nfs_clport.c +++ b/sys/fs/nfsclient/nfs_clport.c @@ -361,6 +361,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr= *nap, void *nvaper, struct nfsnode *np; struct nfsmount *nmp; struct timespec mtime_save; + u_quad_t nsize; + int setnsize; =20 /* * If v_type =3D=3D VNON it is a new node, so fill in the v_type, @@ -418,6 +420,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr= *nap, void *nvaper, } else vap->va_fsid =3D vp->v_mount->mnt_stat.f_fsid.val[0]; np->n_attrstamp =3D time_second; + setnsize =3D 0; if (vap->va_size !=3D np->n_size) { if (vap->va_type =3D=3D VREG) { if (dontshrink && vap->va_size < np->n_size) { @@ -444,10 +447,13 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvat= tr *nap, void *nvaper, np->n_size =3D vap->va_size; np->n_flag |=3D NSIZECHANGED; } - vnode_pager_setsize(vp, np->n_size); } else { np->n_size =3D vap->va_size; } + if (vap->va_type =3D=3D VREG || vap->va_type =3D=3D VDIR) { + setnsize =3D 1; + nsize =3D vap->va_size; + } } /* * The following checks are added to prevent a race between (say) @@ -480,6 +486,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr= *nap, void *nvaper, KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, 0); #endif NFSUNLOCKNODE(np); + if (setnsize) + vnode_pager_setsize(vp, nsize); return (0); } =20 --FqaIGMzVeQkeDzz8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSbgNAAoJEJDCuSvBvK1B1DAQAJhalngZXNaZ5/QiS/0mC4BE k7P8UX/ukBZszZKni2YP4avrFTIIIPmRaJ5zR0BaoXO8MBq2fVob3MUB+ALdYmWm L/KrCB9+o/65yXQPTIZLCdBiCyv79ahLSXNz8qH5MCuyAOaJXC24AGKdLewRsAmX tHOErjdKSTZF1B1tSorPBy7TSTV5w/PCgWigdWUmTUOh6W2ORKe6QX4mZ01KprTe tSGX+ONd9rImQPao2ZbcbqGo6bfrH3lM5FxzhIn0FlQ93FQaVPr8C6OM87f3Z90T mu69C6eo50AJ2enGJTJxdKn3RllPVuCPIiupggjG4d+gb35yAd3LRh6lcrpvZQBm 0RkvOV69Em4Xjt74pCiLZYqco9dI2/dDbemsnHMJ2aRBYsKqURej4DxV/wmNDc1S +6z0zjenSuHp+JdiZVk7zbsu1AhqRH86JiH6omvAQeMazIe7aRsFs/ii9oYp05nf MhJSupjiDFva+tkbFD9e21LF13XSHrvQxYQexGDUu7cnij6WJalMdYfzwG3wVG7h HPiH5+h8fSC7q1rJJ+qrsY5vOgcGV71+YLPJP9b24PYiEOjAfQofaolobVo0klYK Q8VJEIYaPZV8U+zLf3+kPMapWgzYhJkqPOjyYuJZFlGmifdPIyNr+6e+6ef/XSgi /cIgbNo5CPsdVKMDMSir =U0zL -----END PGP SIGNATURE----- --FqaIGMzVeQkeDzz8-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 15:20:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEEE7C7; Wed, 20 Mar 2013 15:20:34 +0000 (UTC) (envelope-from mgamsjager@gmail.com) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id BBC46E37; Wed, 20 Mar 2013 15:20:33 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id er20so3126129lab.4 for ; Wed, 20 Mar 2013 08:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1mBaIUo79xEB7r0O6QXCcZttSx2kmgEbIhi7ZP6Ytmg=; b=DvOVC0wvJM16ssRnNbKw05oU4/UseL7ESlNwj6ixOrx24XtAf/cCfngdtR1DW+blJe Q7WJxYhkQahCryRktwcPK+UvOuA0vLFQ720oCwT82zsYdzM7KUfBnLqK8tHodSqaZQ6x 2U31KwS/f6soGfF0U6YwA4GWeviifAbFfmVcuazZcgl1jsThAGtcO+03tVEQq82EYfuQ /HxWlfKCgxSddvWJqfQ5itZVvwre51eqLLoDZ1Rb6cFSwba4E4bQriAvUv1hNw3hvN1H v4xm5/y/IDhmgfSu6CP61G+hD7zuTJv7VAv5xStRNjHmHMJth7e3HY5zQJW7imrlmdpR yJRA== X-Received: by 10.152.46.131 with SMTP id v3mr5641905lam.57.1363792832581; Wed, 20 Mar 2013 08:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.21.226 with HTTP; Wed, 20 Mar 2013 08:20:02 -0700 (PDT) In-Reply-To: <5141B491.1010800@FreeBSD.org> References: <5141B491.1010800@FreeBSD.org> From: Matthias Gamsjager Date: Wed, 20 Mar 2013 16:20:02 +0100 Message-ID: Subject: Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1 To: Bryan Drewery Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Ports , FreeBSD Current , freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:20:35 -0000 > Due to the security incident, there are still no official FreeBSD > packages. > Do you know what the status is on that issue? From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 15:38:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69C17731; Wed, 20 Mar 2013 15:38:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E9DD0F45; Wed, 20 Mar 2013 15:38:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANbWSVGDaFvO/2dsb2JhbABDiBa9BYFldIIkAQEFIwRSGw4KAgINGQIjNgYTiAIDD7AAiHYNiVuBI4sjghU0B4ItgRMDlQCBYItohRqDJiCBbA X-IronPort-AV: E=Sophos;i="4.84,879,1355115600"; d="scan'208";a="19918063" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 20 Mar 2013 11:37:56 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 97074B3F7D; Wed, 20 Mar 2013 11:37:56 -0400 (EDT) Date: Wed, 20 Mar 2013 11:37:56 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <1758615869.4102301.1363793876607.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130320132222.GC3794@kib.kiev.ua> Subject: Re: Core Dump / panic sleeping thread MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 15:38:10 -0000 Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek > wrote: > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov > > wrote: > > > > > > I do not like it. As I said in the previous response to Andrey, > > > I think that moving the vnode_pager_setsize() after the unlock is > > > better, since it reduces races with other thread seeing half-done > > > attribute update or making attribute change simultaneously. > > > > OK - so should I wait for another patch - or? > > I think the following is what I mean. As an additional note, why nfs > client does not trim the buffers when server reported node size change > ? > > diff --git a/sys/fs/nfsclient/nfs_clport.c > b/sys/fs/nfsclient/nfs_clport.c > index a07a67f..4fe2e35 100644 > --- a/sys/fs/nfsclient/nfs_clport.c > +++ b/sys/fs/nfsclient/nfs_clport.c > @@ -361,6 +361,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > struct nfsnode *np; > struct nfsmount *nmp; > struct timespec mtime_save; > + u_quad_t nsize; > + int setnsize; > > /* > * If v_type == VNON it is a new node, so fill in the v_type, > @@ -418,6 +420,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > } else > vap->va_fsid = vp->v_mount->mnt_stat.f_fsid.val[0]; > np->n_attrstamp = time_second; > + setnsize = 0; > if (vap->va_size != np->n_size) { > if (vap->va_type == VREG) { > if (dontshrink && vap->va_size < np->n_size) { > @@ -444,10 +447,13 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > np->n_size = vap->va_size; > np->n_flag |= NSIZECHANGED; > } > - vnode_pager_setsize(vp, np->n_size); > } else { > np->n_size = vap->va_size; > } > + if (vap->va_type == VREG || vap->va_type == VDIR) { > + setnsize = 1; > + nsize = vap->va_size; I might have used np->n_size here, since that is what is given as the argument for the pre-patched version, but since np->n_size should equal vap->va_size (it is set the same for all cases in the code at this point), it doesn't really matter. I have no idea what the implications of doing vnode_pager_setsize() for VDIR is, but Kostik would be much more conversant that I on this, so if he thinks it's ok, that's fine with me. > + } > } > /* > * The following checks are added to prevent a race between (say) > @@ -480,6 +486,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, 0); > #endif > NFSUNLOCKNODE(np); > + if (setnsize) > + vnode_pager_setsize(vp, nsize); > return (0); > } Yes, I think Kostik's version of the patch is good. I had thought of doing it that way, but want for the "minimal change" version. I agree that avoiding unlocking/relocking the mutex is a good idea, although I didn't see anything after the relock that I thought might be an issue if something changed while unlocked. Kostik, thanks for posting this version, rick ps: Michael, I'd suggest you try this patch instead of mine. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 16:29:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1D66DB6B for ; Wed, 20 Mar 2013 16:29:32 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id F3F922CC for ; Wed, 20 Mar 2013 16:29:31 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta02.emeryville.ca.mail.comcast.net with comcast id Dr5D1l0070lTkoCA2sVXgC; Wed, 20 Mar 2013 16:29:31 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id DsVW1l00K1t3BNj8QsVWTR; Wed, 20 Mar 2013 16:29:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5732B73A1C; Wed, 20 Mar 2013 09:29:30 -0700 (PDT) Date: Wed, 20 Mar 2013 09:29:30 -0700 From: Jeremy Chadwick To: Matthias Gamsjager Subject: Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1 Message-ID: <20130320162930.GA5230@icarus.home.lan> References: <5141B491.1010800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363796971; bh=SDfLa+6JNcfYqWmz7ahlU5fycNVEh8kb5Zr318srBl0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=IUuqcM2cv4vfRDup2QUvWfk2iSPSdJeXZiwQUONWFES6WY1e1de5cqUmf+yWoBu+i tXUyTjVPncY6V3tq6HLjmgiGaw/bFQqGF9jwgKbxdwKUFb60BHW1ck3h7UoDAEwaMW /9bz+JUdwnW8CqWfMZAFzJzFeNeFUACkp4EXXevlWboQA3HfICULkp70HUneL9RACF MOEYnnrdfvT6V3J2RSPSk+HeOsU4v6w4wvIsZavt4OO3xqW9geqQ6FredyscTNwasP VmmBjYBP1q5eozmJlQvF0xMivC2lS0x3qyDY+L/+himdXTMRwkTRvZYrtZdoToPe53 tzGsizpsMzfgA== Cc: FreeBSD Ports , FreeBSD Current , freebsd-stable@freebsd.org, freebsd-pkg@freebsd.org, Bryan Drewery X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:29:32 -0000 On Wed, Mar 20, 2013 at 04:20:02PM +0100, Matthias Gamsjager wrote: > > Due to the security incident, there are still no official FreeBSD > > packages. > > Do you know what the status is on that issue? I'd also like to find out what the status of this is. The packages at: ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/ Are still circa October 2012 -- that's 4-5 months ago. While I truly and deeply understand that proper engineering design and infrastructure changes take time, there has been absolutely no communication presented to the community as to what has (or hasn't) transpired, if there is (or isn't) a plan, or if people are simply waiting until future in-person BSD* events to work things out. freebsd-ops-announce has been silent on this matter as well: http://lists.freebsd.org/mailman/listinfo/freebsd-ops-announce At this point users and administrators do not know if newer packages will be made available or if they should stick to building purely from source. Deep down I'm worried that this will solicit a response of "switch to ports-mgmt/pkg and ports-mgmt/poudriere". While I'm not opposed to the tools themselves, I'm strongly opposed to that kind of response as I'm tired of seeing the security incident being used as a opportunistic crutch (as it was for the sudden cvsup/csup deprecation). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 17:31:09 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5564F3D4; Wed, 20 Mar 2013 17:31:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B6DFE80D; Wed, 20 Mar 2013 17:31:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KHV0du051849; Wed, 20 Mar 2013 19:31:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KHV0du051849 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KHV08Y051848; Wed, 20 Mar 2013 19:31:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 19:31:00 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320173100.GF3794@kib.kiev.ua> References: <20130320132222.GC3794@kib.kiev.ua> <1758615869.4102301.1363793876607.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N+0yS2UTPp5bxBJO" Content-Disposition: inline In-Reply-To: <1758615869.4102301.1363793876607.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 17:31:09 -0000 --N+0yS2UTPp5bxBJO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote: > Konstantin Belousov wrote: > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek > > wrote: > > > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov > > > wrote: > > > > > > > > I do not like it. As I said in the previous response to Andrey, > > > > I think that moving the vnode_pager_setsize() after the unlock is > > > > better, since it reduces races with other thread seeing half-done > > > > attribute update or making attribute change simultaneously. > > > > > > OK - so should I wait for another patch - or? > >=20 > > I think the following is what I mean. As an additional note, why nfs > > client does not trim the buffers when server reported node size change > > ? > >=20 > > diff --git a/sys/fs/nfsclient/nfs_clport.c > > b/sys/fs/nfsclient/nfs_clport.c > > index a07a67f..4fe2e35 100644 > > --- a/sys/fs/nfsclient/nfs_clport.c > > +++ b/sys/fs/nfsclient/nfs_clport.c > > @@ -361,6 +361,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > nfsvattr *nap, void *nvaper, > > struct nfsnode *np; > > struct nfsmount *nmp; > > struct timespec mtime_save; > > + u_quad_t nsize; > > + int setnsize; > >=20 > > /* > > * If v_type =3D=3D VNON it is a new node, so fill in the v_type, > > @@ -418,6 +420,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > nfsvattr *nap, void *nvaper, > > } else > > vap->va_fsid =3D vp->v_mount->mnt_stat.f_fsid.val[0]; > > np->n_attrstamp =3D time_second; > > + setnsize =3D 0; > > if (vap->va_size !=3D np->n_size) { > > if (vap->va_type =3D=3D VREG) { > > if (dontshrink && vap->va_size < np->n_size) { > > @@ -444,10 +447,13 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > nfsvattr *nap, void *nvaper, > > np->n_size =3D vap->va_size; > > np->n_flag |=3D NSIZECHANGED; > > } > > - vnode_pager_setsize(vp, np->n_size); > > } else { > > np->n_size =3D vap->va_size; > > } > > + if (vap->va_type =3D=3D VREG || vap->va_type =3D=3D VDIR) { > > + setnsize =3D 1; > > + nsize =3D vap->va_size; > I might have used np->n_size here, since that is what is given > as the argument for the pre-patched version, but since > np->n_size should equal vap->va_size (it is set the same for > all cases in the code at this point), it doesn't really matter. >=20 > I have no idea what the implications of doing vnode_pager_setsize() > for VDIR is, but Kostik would be much more conversant that I on this, > so if he thinks it's ok, that's fine with me. >=20 > > + } > > } > > /* > > * The following checks are added to prevent a race between (say) > > @@ -480,6 +486,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > nfsvattr *nap, void *nvaper, > > KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, 0); > > #endif > > NFSUNLOCKNODE(np); > > + if (setnsize) > > + vnode_pager_setsize(vp, nsize); > > return (0); > > } > Yes, I think Kostik's version of the patch is good. I had thought > of doing it that way, but want for the "minimal change" version. > I agree that avoiding unlocking/relocking the mutex is a good idea, > although I didn't see anything after the relock that I thought > might be an issue if something changed while unlocked. If the parallel calls to nfscl_loadattrcache() are possible, then IMHO at least the n_attrstamp could be cleared needlessly. >=20 > Kostik, thanks for posting this version, rick > ps: Michael, I'd suggest you try this patch instead of mine. Still, my patch has the issue I noted for the head as well: the buffers are not destroyed if the size of the vnode is decreased. I would be inclined to suggest the following change on top of my patch, but I am sure that it does not work, since vnode is generally not locked in the nfs_loadattrcache(), I think: diff --git a/sys/fs/nfsclient/nfs_clport.c b/sys/fs/nfsclient/nfs_clport.c index 4fe2e35..3a08424 100644 --- a/sys/fs/nfsclient/nfs_clport.c +++ b/sys/fs/nfsclient/nfs_clport.c @@ -487,7 +487,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct nfsvattr= *nap, void *nvaper, #endif NFSUNLOCKNODE(np); if (setnsize) - vnode_pager_setsize(vp, nsize); + vtruncbuf(vp, NOCRED, nsize, vp->v_bufobj.bo_bsize); return (0); } =20 --N+0yS2UTPp5bxBJO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSfJTAAoJEJDCuSvBvK1BDnIP/Rw0+zVoNBr+l/53ZxZoZGqP i6FjxyZXKExvllWiTeRu952gA5oCXnD8Lw3UEaKbHbtu2OG8fnQ82Z+lGMkhWtZp 5ZzkXP5aZOLc7aNRgQ9EggBIC1QgjAXPWM1mDsCtQw3nwUxucN0VIW1Lej3uTFER /mDsF5ISHsd0gILchlyRumAreJvcxTuAFPESUdjsQHoecy5dKStVtmdqg1Pw4hor NLlrCJrO49/vtPp4J2QtRv1mOyH6bjq8e3EfUNqpldoMcgJxCIch7xH2nhNPoZ4K Ozl8KTe8yLNpfatmqU0K3QM67EcJRUeE/z9HOa5qR4gWjYsDzG84SdKfHt/BBHLg 8QfGeLxWSPQREgDUiK9E29Owy5RvziSWF68Jed6DKVjBvHfrkIIZL9vXM/jxDx6F IrA/MEqKtww0aLY2iTPB+Yv9w7Q+TpvOOEuznaA+lXKA+np7wvtC7YzsZqgTuLng DHd6zcDY8XHKfvKjBcepE4lfFEXTyEmXMx6bqAh8Na6PWZWg+RmdA0w8RUM28rMd NMWJvnPlPcPv80jAKEtqwEYcdbHojDlRkR9HdOhgkcTd+MMgbA2e4lZIRIuZ8TD3 lvfF98qSDLFMhPjtyEvYV96DiCbkamkvNj8MMDOkUZW/sO3G7eNVkBeEK6rAaTSp kl5dzygqpNqSGePyF2ND =4441 -----END PGP SIGNATURE----- --N+0yS2UTPp5bxBJO-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 18:44:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF740C75; Wed, 20 Mar 2013 18:44:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CCFCED2F; Wed, 20 Mar 2013 18:44:02 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3D7FDB9BC; Wed, 20 Mar 2013 14:44:02 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Core Dump / panic sleeping thread Date: Wed, 20 Mar 2013 09:43:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <5148A454.1080303@FreeBSD.org> <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> <20130320132222.GC3794@kib.kiev.ua> In-Reply-To: <20130320132222.GC3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303200943.20356.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 14:44:02 -0400 (EDT) Cc: Jeremy Chadwick , Michael Landin Hostbaek , Rick Macklem , freebsd-stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:44:03 -0000 On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote: > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov wrote: > > > > > > I do not like it. As I said in the previous response to Andrey, > > > I think that moving the vnode_pager_setsize() after the unlock is > > > better, since it reduces races with other thread seeing half-done > > > attribute update or making attribute change simultaneously. > > > > OK - so should I wait for another patch - or? > > I think the following is what I mean. As an additional note, why nfs > client does not trim the buffers when server reported node size change ? Will changing the size always result in an mtime change forcing the client to throw away the data on the next read or fault anyway (or does it only affect ctime)? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 18:58:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 37D4C605; Wed, 20 Mar 2013 18:58:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB3AFE3A; Wed, 20 Mar 2013 18:58:15 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KIw8KU071488; Wed, 20 Mar 2013 20:58:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KIw8KU071488 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KIw8Wk071487; Wed, 20 Mar 2013 20:58:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 20:58:08 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320185808.GJ3794@kib.kiev.ua> References: <5148A454.1080303@FreeBSD.org> <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> <20130320132222.GC3794@kib.kiev.ua> <201303200943.20356.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZZEGMFFBHS0xR+g5" Content-Disposition: inline In-Reply-To: <201303200943.20356.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , Rick Macklem , freebsd-stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:58:16 -0000 --ZZEGMFFBHS0xR+g5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote: > On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote: > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wrote: > > >=20 > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov =20 > wrote: > > > >=20 > > > > I do not like it. As I said in the previous response to Andrey, > > > > I think that moving the vnode_pager_setsize() after the unlock is > > > > better, since it reduces races with other thread seeing half-done > > > > attribute update or making attribute change simultaneously. > > >=20 > > > OK - so should I wait for another patch - or?=20 > >=20 > > I think the following is what I mean. As an additional note, why nfs > > client does not trim the buffers when server reported node size change ? >=20 > Will changing the size always result in an mtime change forcing the clien= t to > throw away the data on the next read or fault anyway (or does it only aff= ect > ctime)? UFS only modifies ctime on truncation, it seems. --ZZEGMFFBHS0xR+g5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSga/AAoJEJDCuSvBvK1BfAYP/1EgLiteMNeP9kXLF2tMgTju suAOy0hYjAYl4leyyYS4l93n7Z2prDo8Ml+OrnJkTC52VdDwgag4z1+QuXK2a6SK crbxb6It+7kILt+WG12ydX8p28DI0zx2RR+lf6B3OP3Dk5eYww62sBGZ9fIqr3zz ELZozO2ehVoSSIGlxmcznoWudtQTKZ/PYDV6vvDS0sQ9/5DcqXupAoAlwFYxDGRB CSlg9B45Bm/MEc/MK2+KE1ut4nBRjteXjB5snKlKv0e630ycNKQovby1rJXQGLGh CKKSHG6TuOtI8MFSl7+8Wvzw2vVVtps2bzMJgspsDpO0rtLJEolcLqXR+aVPfCxv 2wvxG0v67bqvLOSGRKBC9TE+Lddh9oBHPRIqFwYX5lmQh8i6JBPT74H4BlNMRRAb gKCdh6RHiYohFGKe+v/ZK+GSq7ptbjqQu/jmG6Po2hFY/QO8p4q3RNolkGwXKOVf qmb58Uzt/4J8wAd3vPej0F6RNflw0/d2CJ1nGYx+ZSnNJ0TnmJTCsI3jiJ7GOug6 uyFB6CmJp6XPubBT1+9qLrVWw8v6irBnZKcDzl/800LQEChWwbhcHnM+6dDjStiB ueBkNOsvc4RL7jNeRTa3uIT13QiBELyIpA3Fn26PldHWtCPcbpvDqTukVq5ExCji wAZpvjsinWbW4eroNlVg =cpXk -----END PGP SIGNATURE----- --ZZEGMFFBHS0xR+g5-- From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 19:09:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D6D59ED; Wed, 20 Mar 2013 19:09:44 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 90D30EDE; Wed, 20 Mar 2013 19:09:43 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id o45so1648845wer.23 for ; Wed, 20 Mar 2013 12:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jI07cadKMzFD4K1C8FxWT0pOtTzJ1SJzo5rZmWV0eFg=; b=sNoz3c+7W8f6A2SJxfhSal4fdaoXFF0+yScgTAEGEFR5f5Uo9X6orUQI9fnYwqymhf I0kGDzh+nV8Oim9pRL4IAa/ySonl2CqFtj3zNghyS0nkbiJn3QnIYZVjQSzj4eKlgMu8 6nN3NCOl9aAjwQRzhJPC158gXNcMculrrHXKjwQFHXVYfdQAgHF3BlufuY5K7RKqAOkF kvbfFYoHWf6Xf3R7n8iICvclrXZ+vx7Qkz2ce7Pf9LfSPqd8PrR/M4QRTJ6Mrb9Yf15e s4XXMwvPO98+ts7PkG0exAdGjRBVpXB15X7il49kckvNG5s9ROrxFWzl+0klEPWYWwP6 WmcQ== MIME-Version: 1.0 X-Received: by 10.180.92.97 with SMTP id cl1mr509504wib.19.1363806582668; Wed, 20 Mar 2013 12:09:42 -0700 (PDT) Received: by 10.194.60.147 with HTTP; Wed, 20 Mar 2013 12:09:42 -0700 (PDT) In-Reply-To: <20130319174339.GA72813@icarus.home.lan> References: <20130319174339.GA72813@icarus.home.lan> Date: Wed, 20 Mar 2013 20:09:42 +0100 Message-ID: Subject: Re: Panic : bad pte From: David Demelier To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:09:44 -0000 2013/3/19 Jeremy Chadwick : > On Tue, Mar 19, 2013 at 06:34:24PM +0100, David Demelier wrote: >> Hello, >> >> There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I can >> just say there is a problem in the 9.1-RELEASE because I had no panic >> before. What afraid me is that my production server also panic'ed a >> few days ago, fortunately it does not appears so often. >> >> This is a panic that happened on my desktop computer, with a graphic >> card. The crash usually appears when X starts. >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you are >> welcome to change it and/or distribute copies of it under certain conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> panic: bad pte >> cpuid = 3 >> KDB: stack backtrace: >> Uptime: 2m31s >> Dumping 183 out of 1950 MB:..9%..18%..27%..35%..44%..53%..62%..79%..88%..96% >> >> Reading symbols from /boot/modules/nvidia.ko...done. >> Loaded symbols for /boot/modules/nvidia.ko >> #0 doadump (textdump=Variable "textdump" is not available. >> ) at pcpu.h:224 >> 224 pcpu.h: No such file or directory. >> in pcpu.h >> (kgdb) bt >> #0 doadump (textdump=Variable "textdump" is not available. >> ) at pcpu.h:224 >> #1 0x0000000000000004 in ?? () >> #2 0xffffffff8048c156 in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:448 >> #3 0xffffffff8048c619 in panic (fmt=0x1
) >> at /usr/src/sys/kern/kern_shutdown.c:636 >> #4 0xffffffff8065f88a in pmap_remove_pages (pmap=0xfffffe0005a2fa60) >> at /usr/src/sys/amd64/amd64/pmap.c:4156 >> #5 0xffffffff8063d26b in vmspace_exit (td=0xfffffe0005a05470) at >> /usr/src/sys/vm/vm_map.c:422 >> #6 0xffffffff8045d725 in exit1 (td=0xfffffe0005a05470, rv=Variable >> "rv" is not available. >> ) at /usr/src/sys/kern/kern_exit.c:315 >> #7 0xffffffff8045e5ce in sys_sys_exit (td=Variable "td" is not available. >> ) at /usr/src/sys/kern/kern_exit.c:122 >> #8 0xffffffff8066737f in amd64_syscall (td=0xfffffe0005a05470, >> traced=0) at subr_syscall.c:135 >> #9 0xffffffff80652d97 in Xfast_syscall () at >> /usr/src/sys/amd64/amd64/exception.S:387 >> #10 0x0000000800d51c1c in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> >> Of course I may do something wrong, and I hope so but unfortunately I >> can't find any solution. May the nvidia driver be the problem? > > Interesting timing. Semi-recently (February) src/sys/amd64/amd64/pmap.c > in 9.1-STABLE (not -RELEASE) was modified to increase the information > shown for this specific type of panic. See revision 247079: > > http://svnweb.freebsd.org/base/stable/9/sys/amd64/amd64/pmap.c?view=log > > I've CC'd Konstantin Belousov (kib@), who should be able to help step > you through getting information out of the crash dump, to help track > down the root cause. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | You will not believe that, when I leave the desktop. I completely detach the AC adaptor (usually at evening). And everyday when I plug it and start the machine it panics. But when it reboots and start again no panic anymore. I just can't believe it. The panic is completely different from yesterday's one : Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8010 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8049db4e stack pointer = 0x28:0xffffff8000225a90 frame pointer = 0x28:0xfffffe000247c8e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 10 (idle: cpu0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: Uptime: 1m3s Dumping 324 out of 1950 MB:..5%..15%..25%..35%..45%..55%..65%..74%..84%..94% Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=Variable "textdump" is not available. ) at pcpu.h:224 #1 0x0000000000000004 in ?? () #2 0xffffffff80489506 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #3 0xffffffff804899c9 in panic (fmt=0x1
) at /usr/src/sys/kern/kern_shutdown.c:636 #4 0xffffffff80664e39 in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #5 0xffffffff806651c4 in trap_pfault (frame=0xffffff80002259e0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 #6 0xffffffff806655bb in trap (frame=0xffffff80002259e0) at /usr/src/sys/amd64/amd64/trap.c:456 #7 0xffffffff8064fe5f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #8 0xffffffff8049db4e in callout_tickstofirst (limit=250) at /usr/src/sys/kern/kern_timeout.c:381 #9 0xffffffff806761d1 in getnextcpuevent (event=0xffffff8000225b10, idle=1) at /usr/src/sys/kern/kern_clocksource.c:282 #10 0xffffffff8067741e in cpu_idleclock () at /usr/src/sys/kern/kern_clocksource.c:785 #11 0xffffffff8065685a in cpu_idle (busy=0) at /usr/src/sys/amd64/amd64/machdep.c:801 #12 0xffffffff804b0a3f in sched_idletd (dummy=Variable "dummy" is not available. ) at /usr/src/sys/kern/sched_ule.c:2617 #13 0xffffffff8045c88d in fork_exit (callout=0xffffffff804b07f0 , arg=0x0, frame=0xffffff8000225c40) at /usr/src/sys/kern/kern_fork.c:992 #14 0xffffffff8065031e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000001 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0xffffffff809fcdc0 in affinity () #40 0x0000000000000000 in ?? () #41 0xfffffe000247cd20 in ?? () #42 0xfffffe000247c8e0 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffff8000225aa8 in ?? () #45 0xfffffe000247f8e0 in ?? () #46 0xffffffff804b1b49 in sched_switch (td=0xffffffff804b07f0, newtd=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1921 As you can see the uptime is almost the same, just after the start. I'm guessing if I have no hardware failure such as power problems. And now I'm writing from it aftour an uptime of one hour without any problem. This is just crazy. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 19:33:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95F6CDD3; Wed, 20 Mar 2013 19:33:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3754EFBA; Wed, 20 Mar 2013 19:33:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KJXZJE077667; Wed, 20 Mar 2013 21:33:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KJXZJE077667 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KJXZSX077666; Wed, 20 Mar 2013 21:33:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 21:33:35 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320193335.GK3794@kib.kiev.ua> References: <5148A454.1080303@FreeBSD.org> <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> <20130320132222.GC3794@kib.kiev.ua> <201303200943.20356.jhb@freebsd.org> <20130320185808.GJ3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4K1DhCUNwbLbQ12L" Content-Disposition: inline In-Reply-To: <20130320185808.GJ3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , Rick Macklem , freebsd-stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:33:39 -0000 --4K1DhCUNwbLbQ12L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 08:58:08PM +0200, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote: > > On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wro= te: > > > >=20 > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov =20 > > wrote: > > > > >=20 > > > > > I do not like it. As I said in the previous response to Andrey, > > > > > I think that moving the vnode_pager_setsize() after the unlock is > > > > > better, since it reduces races with other thread seeing half-done > > > > > attribute update or making attribute change simultaneously. > > > >=20 > > > > OK - so should I wait for another patch - or?=20 > > >=20 > > > I think the following is what I mean. As an additional note, why nfs > > > client does not trim the buffers when server reported node size chang= e ? > >=20 > > Will changing the size always result in an mtime change forcing the cli= ent to > > throw away the data on the next read or fault anyway (or does it only a= ffect > > ctime)? >=20 > UFS only modifies ctime on truncation, it seems. No, I was wrong. ffs_truncate() indeed only sets both IN_CHANGE | IN_UPDATE flags for the inode, and IN_UPDATE causes mtime update in ufs_itimes(), called from UFS_UPDATE(). --4K1DhCUNwbLbQ12L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSg8OAAoJEJDCuSvBvK1BBiUP+wWERkRa1csAo+2rUrItibqV ephUWDg5To2Jc0vPh8keZNUZrSmAQp47YSL9nUPV3LjGTYVR4Bfty2Uw78P6bcwO +BtgxBRcFZ6T9ix4tto3ptuptx1Vjq+issOXLRMlTJMqcTCFLqoWDOxPQhD+IwIJ WNb8gIFehtEsOv5FdBnYLwPtIya5ExNFnKOD9+I+jDJNhUlpKHN/6OUDZnQBI9/o /MeEVOQgBEGpceH+KgUStSPsCEKyzlMCV8EDwy866mFkZQUq752coKp7oGKpz/LF c3iVzwh5M3sXuFbt6ZW+wilAqdbhz+JS0ZHJnUGd1Fsy0TsI8eGJBEG3zbly82pr +SlUjViPcsVeVScyll05Sry4wlI4ZJzq3qtBkmyjoeAqpWMemLKDXEXYpXpn3ro+ THzsvKtUJC4MA74ukZMOjKiwBPbCWmcHOAftnwsO1by+hFr2k5gFUZD9SMU/+m1p On0FN5DDV+owWZVCS3XzBGVXi8Kx863L42t7GLvlsJf3eAzZzVk/AIjpoj7PFJs5 BHShhPyapUNKkVJHWCopPm9pA/OUEOUgYab+dpWGJlz3m6KOv7zu0GT36uxDNzj3 ytu+ucrKrZvK2U3vn9FfiA1AGr7YNOLrfNXtxsBXGwauH3r7tF0x0XMZQv7LNTsK YAgrEGQ7OPPq2BOqqdR4 =5MTz -----END PGP SIGNATURE----- --4K1DhCUNwbLbQ12L-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 01:14:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDBFE77B; Thu, 21 Mar 2013 01:14:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 30676EE3; Thu, 21 Mar 2013 01:14:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEADZeSlGDaFvO/2dsb2JhbAA7CIgdvR2Ba3SCJAEBBAEjBFIFFg4KAgINGQIjNgYTiAIDCQawDIhqDYlbgSOLJIEVgQA0B4ItgRMDlQCBYItohRqDJiCBbA X-IronPort-AV: E=Sophos;i="4.84,881,1355115600"; d="scan'208";a="22185724" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 20 Mar 2013 21:14:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 8D4B2B4032; Wed, 20 Mar 2013 21:14:37 -0400 (EDT) Date: Wed, 20 Mar 2013 21:14:37 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130320173100.GF3794@kib.kiev.ua> Subject: Re: Core Dump / panic sleeping thread MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:14:45 -0000 Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek > > > wrote: > > > > > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov > > > > wrote: > > > > > > > > > > I do not like it. As I said in the previous response to > > > > > Andrey, > > > > > I think that moving the vnode_pager_setsize() after the unlock > > > > > is > > > > > better, since it reduces races with other thread seeing > > > > > half-done > > > > > attribute update or making attribute change simultaneously. > > > > > > > > OK - so should I wait for another patch - or? > > > > > > I think the following is what I mean. As an additional note, why > > > nfs > > > client does not trim the buffers when server reported node size > > > change > > > ? > > > > > > diff --git a/sys/fs/nfsclient/nfs_clport.c > > > b/sys/fs/nfsclient/nfs_clport.c > > > index a07a67f..4fe2e35 100644 > > > --- a/sys/fs/nfsclient/nfs_clport.c > > > +++ b/sys/fs/nfsclient/nfs_clport.c > > > @@ -361,6 +361,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > struct nfsnode *np; > > > struct nfsmount *nmp; > > > struct timespec mtime_save; > > > + u_quad_t nsize; > > > + int setnsize; > > > > > > /* > > > * If v_type == VNON it is a new node, so fill in the v_type, > > > @@ -418,6 +420,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > } else > > > vap->va_fsid = vp->v_mount->mnt_stat.f_fsid.val[0]; > > > np->n_attrstamp = time_second; > > > + setnsize = 0; > > > if (vap->va_size != np->n_size) { > > > if (vap->va_type == VREG) { > > > if (dontshrink && vap->va_size < np->n_size) { > > > @@ -444,10 +447,13 @@ nfscl_loadattrcache(struct vnode **vpp, > > > struct > > > nfsvattr *nap, void *nvaper, > > > np->n_size = vap->va_size; > > > np->n_flag |= NSIZECHANGED; > > > } > > > - vnode_pager_setsize(vp, np->n_size); > > > } else { > > > np->n_size = vap->va_size; > > > } > > > + if (vap->va_type == VREG || vap->va_type == VDIR) { > > > + setnsize = 1; > > > + nsize = vap->va_size; > > I might have used np->n_size here, since that is what is given > > as the argument for the pre-patched version, but since > > np->n_size should equal vap->va_size (it is set the same for > > all cases in the code at this point), it doesn't really matter. > > > > I have no idea what the implications of doing vnode_pager_setsize() > > for VDIR is, but Kostik would be much more conversant that I on > > this, > > so if he thinks it's ok, that's fine with me. > > > > > + } > > > } > > > /* > > > * The following checks are added to prevent a race between (say) > > > @@ -480,6 +486,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, 0); > > > #endif > > > NFSUNLOCKNODE(np); > > > + if (setnsize) > > > + vnode_pager_setsize(vp, nsize); > > > return (0); > > > } > > Yes, I think Kostik's version of the patch is good. I had thought > > of doing it that way, but want for the "minimal change" version. > > I agree that avoiding unlocking/relocking the mutex is a good idea, > > although I didn't see anything after the relock that I thought > > might be an issue if something changed while unlocked. > If the parallel calls to nfscl_loadattrcache() are possible, then > IMHO at least the n_attrstamp could be cleared needlessly. > And that could result in an attribute cache miss, since setting n_attrstamp = 0 invalidates the cached attributes. I agree that your patch is preferred. I'll admit I was mostly lazy (and a little afraid of moving the vnode_pager_setsize()) when I did the patch. > > > > Kostik, thanks for posting this version, rick > > ps: Michael, I'd suggest you try this patch instead of mine. > Still, my patch has the issue I noted for the head as well: the > buffers > are not destroyed if the size of the vnode is decreased. I would be > inclined to suggest the following change on top of my patch, but I am > sure that it does not work, since vnode is generally not locked in > the nfs_loadattrcache(), I think: > Well, read/write sharing of files over NFS is pretty rare, so I suspect a truncation of a file by another client (or locally in the NFS server) is a rare event. As such, not invalidating the buffers here doesn't seem like a big issue? (The client uses np->n_size to determine EOF.) Also, I think close-to-open consistency will typically throw away the buffers on the next open when it sees the mtime changed. (Yes, there won't necessarily be another open, but...) As you point out, I don't think the vnode will be locked when nfscl_loadattrcache() is called for read/writes being done by the nfsiod threads and will only be a shared vnode lock for other reads. I think your patch without the below addition is just fine, rick > diff --git a/sys/fs/nfsclient/nfs_clport.c > b/sys/fs/nfsclient/nfs_clport.c > index 4fe2e35..3a08424 100644 > --- a/sys/fs/nfsclient/nfs_clport.c > +++ b/sys/fs/nfsclient/nfs_clport.c > @@ -487,7 +487,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > #endif > NFSUNLOCKNODE(np); > if (setnsize) > - vnode_pager_setsize(vp, nsize); > + vtruncbuf(vp, NOCRED, nsize, vp->v_bufobj.bo_bsize); > return (0); > } From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 01:52:11 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 08BE2C12; Thu, 21 Mar 2013 01:52:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8EADDFF0; Thu, 21 Mar 2013 01:52:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKZmSlGDaFvO/2dsb2JhbAA7CIgdvRyBa3SCJAEBBAEjBFIFFg4KAgINGQIjNgYTiAIDCQawDIhjDYlbgSOLJIEVgQA0B4ItgRMDlQCBYItohRqDJiCBbA X-IronPort-AV: E=Sophos;i="4.84,881,1355115600"; d="scan'208";a="20024259" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 20 Mar 2013 21:52:08 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C3089B3F85; Wed, 20 Mar 2013 21:52:08 -0400 (EDT) Date: Wed, 20 Mar 2013 21:52:08 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <1977353437.4130325.1363830728773.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20130320173100.GF3794@kib.kiev.ua> Subject: Re: Core Dump / panic sleeping thread MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 01:52:11 -0000 Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 11:37:56AM -0400, Rick Macklem wrote: > > Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek > > > wrote: > > > > > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov > > > > wrote: > > > > > > > > > > I do not like it. As I said in the previous response to > > > > > Andrey, > > > > > I think that moving the vnode_pager_setsize() after the unlock > > > > > is > > > > > better, since it reduces races with other thread seeing > > > > > half-done > > > > > attribute update or making attribute change simultaneously. > > > > > > > > OK - so should I wait for another patch - or? > > > > > > I think the following is what I mean. As an additional note, why > > > nfs > > > client does not trim the buffers when server reported node size > > > change > > > ? > > > > > > diff --git a/sys/fs/nfsclient/nfs_clport.c > > > b/sys/fs/nfsclient/nfs_clport.c > > > index a07a67f..4fe2e35 100644 > > > --- a/sys/fs/nfsclient/nfs_clport.c > > > +++ b/sys/fs/nfsclient/nfs_clport.c > > > @@ -361,6 +361,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > struct nfsnode *np; > > > struct nfsmount *nmp; > > > struct timespec mtime_save; > > > + u_quad_t nsize; > > > + int setnsize; > > > > > > /* > > > * If v_type == VNON it is a new node, so fill in the v_type, > > > @@ -418,6 +420,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > } else > > > vap->va_fsid = vp->v_mount->mnt_stat.f_fsid.val[0]; > > > np->n_attrstamp = time_second; > > > + setnsize = 0; > > > if (vap->va_size != np->n_size) { > > > if (vap->va_type == VREG) { > > > if (dontshrink && vap->va_size < np->n_size) { > > > @@ -444,10 +447,13 @@ nfscl_loadattrcache(struct vnode **vpp, > > > struct > > > nfsvattr *nap, void *nvaper, > > > np->n_size = vap->va_size; > > > np->n_flag |= NSIZECHANGED; > > > } > > > - vnode_pager_setsize(vp, np->n_size); > > > } else { > > > np->n_size = vap->va_size; > > > } > > > + if (vap->va_type == VREG || vap->va_type == VDIR) { > > > + setnsize = 1; > > > + nsize = vap->va_size; > > I might have used np->n_size here, since that is what is given > > as the argument for the pre-patched version, but since > > np->n_size should equal vap->va_size (it is set the same for > > all cases in the code at this point), it doesn't really matter. > > > > I have no idea what the implications of doing vnode_pager_setsize() > > for VDIR is, but Kostik would be much more conversant that I on > > this, > > so if he thinks it's ok, that's fine with me. > > > > > + } > > > } > > > /* > > > * The following checks are added to prevent a race between (say) > > > @@ -480,6 +486,8 @@ nfscl_loadattrcache(struct vnode **vpp, struct > > > nfsvattr *nap, void *nvaper, > > > KDTRACE_NFS_ATTRCACHE_LOAD_DONE(vp, vap, 0); > > > #endif > > > NFSUNLOCKNODE(np); > > > + if (setnsize) > > > + vnode_pager_setsize(vp, nsize); > > > return (0); > > > } > > Yes, I think Kostik's version of the patch is good. I had thought > > of doing it that way, but want for the "minimal change" version. > > I agree that avoiding unlocking/relocking the mutex is a good idea, > > although I didn't see anything after the relock that I thought > > might be an issue if something changed while unlocked. > If the parallel calls to nfscl_loadattrcache() are possible, then > IMHO at least the n_attrstamp could be cleared needlessly. > > > > > Kostik, thanks for posting this version, rick > > ps: Michael, I'd suggest you try this patch instead of mine. > Still, my patch has the issue I noted for the head as well: the > buffers > are not destroyed if the size of the vnode is decreased. I would be > inclined to suggest the following change on top of my patch, but I am > sure that it does not work, since vnode is generally not locked in > the nfs_loadattrcache(), I think: > Oh, and I think jhb@ was mentioning, if this client is only reading the file, it will invalidate the buffers when it sees the mtime change on a subsequent read. rick > diff --git a/sys/fs/nfsclient/nfs_clport.c > b/sys/fs/nfsclient/nfs_clport.c > index 4fe2e35..3a08424 100644 > --- a/sys/fs/nfsclient/nfs_clport.c > +++ b/sys/fs/nfsclient/nfs_clport.c > @@ -487,7 +487,7 @@ nfscl_loadattrcache(struct vnode **vpp, struct > nfsvattr *nap, void *nvaper, > #endif > NFSUNLOCKNODE(np); > if (setnsize) > - vnode_pager_setsize(vp, nsize); > + vtruncbuf(vp, NOCRED, nsize, vp->v_bufobj.bo_bsize); > return (0); > } From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 07:58:51 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C43BE55B; Thu, 21 Mar 2013 07:58:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3AAF7F7E; Thu, 21 Mar 2013 07:58:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2L7wlc9011988; Thu, 21 Mar 2013 09:58:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2L7wlc9011988 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2L7wlxk011987; Thu, 21 Mar 2013 09:58:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 09:58:47 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130321075847.GR3794@kib.kiev.ua> References: <20130320173100.GF3794@kib.kiev.ua> <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lA9F05uMKC/Ah7SI" Content-Disposition: inline In-Reply-To: <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Michael Landin Hostbaek , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 07:58:51 -0000 --lA9F05uMKC/Ah7SI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > Well, read/write sharing of files over NFS is pretty rare, so I suspect > a truncation of a file by another client (or locally in the NFS server) > is a rare event. As such, not invalidating the buffers here doesn't seem > like a big issue? (The client uses np->n_size to determine EOF.) >=20 > Also, I think close-to-open consistency will typically throw away the > buffers on the next open when it sees the mtime changed. (Yes, there > won't necessarily be another open, but...) nfs buffers are VMIO. Each VMIO buffer wires the pages it references. Wired pages cannot be freed by vnode_pager_setsize() if the file is truncated. --lA9F05uMKC/Ah7SI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSr22AAoJEJDCuSvBvK1BHKcP/irDDWtGtfynCFQfoYSLmWkT E4YQCN1QVPJ6gK0B6eGdOHV8x0F3nPhI7M5SebPNVWMdM5glWZgeSOL0sp7YHw1s SL6uTS6bOy70Wz6kK99HzC8Ga05WAJbghHAhc3jG32U6IbGyuW6IggCNl0laMMP2 iwV4X16IuGepQWWVcAViHokglDXHlh9bBAVBLFWCrRLUnTsVh1UVJtSaM5/oJ4E8 22cR5wP8ybmRPJ1KRp/K6xGwE+93XMhQThEcuBT0DuHcrWLamLzi0L1bPdO/W2BP ty8SvQIq8Dj05Fm69BOosLiiqTpLKIjuYokNYqUGLXQi4ItFZy+cYrP8zqQUhfN9 +1naxGFX4SbdlypWHimXWaDiptdRmVPynHUdIZYSAa+lKT1qQ5M6Mrm2ZkShfP9o 0mEOpcn/6b18yNew+X/Amaw9aSiRfQt45sAwGtGep7wfbkCq0SyAb06nq2ZvAKs4 D7rEu1bN7Ps6shXAIyfcJ870e9zRO4ln3fNK5RCs1J0ElOnnVrvd1PP2Tjhj7Yhh 40R5zJSNMcNYESLBGCCTR+3hUHf6m/SMtlI6L4sLgopqsixhtjFSsH1xUuAkokVO GNKWbhVxNNgjUJmeW+kwUbr+1MNT0M3lkgpQJP/OvT4r8b4snqiYsCGWxz+7l+6z jngayHwdaow0HOpImgpI =His/ -----END PGP SIGNATURE----- --lA9F05uMKC/Ah7SI-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 14:00:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3C52781E for ; Thu, 21 Mar 2013 14:00:23 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id E9AB6AFB for ; Thu, 21 Mar 2013 14:00:22 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=R4GB6KtX c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=8jhF2qGmtvsA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=KS5gVQhY--UA:10 a=LjTOzC1lAAAA:8 a=g3k24fdcAAAA:8 a=lLcgQo_oSKqTvFPuZIsA:9 a=CjuIK1q_8ugA:10 a=KmloqkfaIt8A:10 a=6k4BJ-aj_1UA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:34022] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id 1B/42-18243-1721B415; Thu, 21 Mar 2013 10:00:22 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20811.4719.174493.857351@jerusalem.litteratus.org> Date: Thu, 21 Mar 2013 10:00:15 -0400 To: Kimmo Paasiala Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: FreeBSD-STABLE Mailing List , FreeBSD current , Beat Siegenthaler X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:00:23 -0000 Kimmo Paasiala writes: > > =================buildworld=============== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > > [-Werror,-Wincompatible-pointer-types] > > getsasldata, NULL, XS_AUTH); > > ^~~~~~~~~~~ > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > > passing argument to parameter here > > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > > ^ > > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > > macro '__P' > > #define __P(protos) protos /* full-blown ANSI C */ > > ^ > > 3 errors generated. > > *** [usersmtp.o] Error code 1 > > > I can not help with the error but I really have to make this question: > Does FreeBSD really have to support pre-ANSI C compilers in 2013? I have been getting this also for at least the last two months. (There is no src.conf; make.conf is appended. Current system is: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 and I have cyrus-sasl-2.1.26_2 installed and working with that installation.) Respectfully, Robert Huff **************** make.conf CFLAGS= -O -pipe -g STRIP= SYMVER_ENABLED= yes X_WINDOW_SYSTEM= xorg HAVE_MOTIF= yes KERNCONF=JERUSALEM # To avoid building various parts of the base system: # (copied from /usr/share/examples/etc/make.conf NO_BIND_ETC= true # Do not install files to /etc/namedb NO_BLUETOOTH= true # do not build Bluetooth related stuff NO_PROFILE= true # Avoid compiling profiled libraries # to get automatic SASL in sendmail SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 # # to make CUPS magically keep working # See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html # CUPS_OVERWRITE_BASE= yes NO_LPR= true # added per /usr/ports/UPDATING entry 20090401 OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 # WITH_MOZILLA= libxul WITH_GECKO= libxul # # added 2007/03/04 per advice of # in re science/gramps # WITH_BERKELEYDB=db43 WITH_BDB_VER=43 WANT_OPENLDAP_VER=24 WANT_OPENLDAP_SASL=true # # as required by ports/UPDATING of 20121012 # SAMBA_ENABLE=YES # # PORTS: use clang unless gcc is explicitly required # # # default to using clang for all port builds, with the following # exceptions # ports which will only build with the base system GNU compiler (4.2) # # the "make index" target also seems to need this, for some reason .if target(index) | \ ${.CURDIR:M*/devel/antlr*} | \ ${.CURDIR:M*/devel/google-perftools* } | \ ${.CURDIR:M*/graphics/ImageMagick* } | \ ${.CURDIR:M*/graphics/opencv*} | \ ${.CURDIR:M*/x11/kdelibs4*} | \ USE_GCC?=4.2 .endif # ports which need *some* version of the GNU compiler (won't build with # clang or have runtime issues if built with clang) # use the highest version of gcc we have installed from ports (4.6) .if ${.CURDIR:M*/accessibility/jovie*} | \ ${.CURDIR:M*/accessibility/kdeaccessibility4*} | \ ${.CURDIR:M*/audio/grip*} | \ ${.CURDIR:M*/audio/mpg123*} | \ ${.CURDIR:M*/audio/rosegarden*} | \ ${.CURDIR:M*/databases/virtuoso*} | \ ${.CURDIR:M*/deskutils/kdepimlibs4*} | \ ${.CURDIR:M*/devel/apache-ant*} | \ ${.CURDIR:M*/devel/icu*} | \ ${.CURDIR:M*/devel/kdevelop-kde4*} | \ ${.CURDIR:M*/devel/kdevplatform*} | \ ${.CURDIR:M*/devel/log4j*} | \ ${.CURDIR:M*/games/kdegames4*} | \ ${.CURDIR:M*/graphics/tonicpoint-viewer*} | \ ${.CURDIR:M*/java/* } | \ ${.CURDIR:M*/lang/gcc* } | \ ${.CURDIR:M*/math/fftw3*} | \ ${.CURDIR:M*/multimedia/avidemux2*} | \ ${.CURDIR:M*/multimedia/kdemultimedia4*} | \ ${.CURDIR:M*/multimedia/vlc*} | \ ${.CURDIR:M*/multimedia/xbmc*} | \ ${.CURDIR:M*/net/kdenetwork4*} | \ ${.CURDIR:M*/net/mpich2*} | \ ${.CURDIR:M*/net/opal3*} | \ ${.CURDIR:M*/net-p2p/ktorrent*} | \ ${.CURDIR:M*/net-p2p/vuze*} | \ ${.CURDIR:M*/sysutils/lsof*} | \ ${.CURDIR:M*/textproc/docbook-xsl*} | \ ${.CURDIR:M*/textproc/fop*} | \ ${.CURDIR:M*/www/libxul*} | \ ${.CURDIR:M*/x11/kde4-baseapps*} | \ ${.CURDIR:M*/x11/kde4-workspace*} | \ ${.CURDIR:M*/x11/lxpanel*} | \ USE_GCC?=4.6+ .endif .if ${.CURDIR:M*/usr/ports/*} .if !defined(USE_GCC) .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP=clang-cpp .endif .endif .endif WITH_NEW_XORG=yes WITH_BSD_SORT= WITH_PKGNG=yes # added by use.perl 2013-03-11 11:53:01 PERL_VERSION=5.16.2 From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 14:16:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3CCD3BE; Thu, 21 Mar 2013 14:16:21 +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 9AB4FD19; Thu, 21 Mar 2013 14:16:21 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1UIgHp-0000Rv-9b; Thu, 21 Mar 2013 14:16:13 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UIgHo-0004Oh-D0; Thu, 21 Mar 2013 14:16:08 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r2LEG8oH041217; Thu, 21 Mar 2013 14:16:08 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r2LEG8cG041216; Thu, 21 Mar 2013 14:16:08 GMT (envelope-from mexas) Date: Thu, 21 Mar 2013 14:16:08 GMT From: Anton Shterenlikht Message-Id: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> To: kpaasial@gmail.com, roberthuff@rcn.com Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: <20811.4719.174493.857351@jerusalem.litteratus.org> X-Spam-Score: -4.7 X-Spam-Level: ---- Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, beat.siegenthaler@beatsnet.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:16:21 -0000 Kimmo Paasiala writes: > > =================buildworld=============== > > > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > error: incompatible pointer types passing 'void ()' to parameter of type > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)' > > [-Werror,-Wincompatible-pointer-types] > > getsasldata, NULL, XS_AUTH); > > ^~~~~~~~~~~ > > /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: note: > > passing argument to parameter here > > extern int reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void > > (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int)); > > ^ > > /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from > > macro '__P' > > #define __P(protos) protos /* full-blown ANSI C */ > > ^ > > 3 errors generated. > > *** [usersmtp.o] Error code 1 > > > I can not help with the error but I really have to make this question: > Does FreeBSD really have to support pre-ANSI C compilers in 2013? I have been getting this also for at least the last two months. (There is no src.conf; make.conf is appended. Current system is: FreeBSD 10.0-CURRENT #0: Sun Dec 30 12:52:09 EST 2012 amd64 and I have cyrus-sasl-2.1.26_2 installed and working with that installation.) Respectfully, Robert Huff me too, also on amd64 -current no src.conf # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+= -lsasl2 WITH_PKGNG=yes PERL_VERSION=5.16.2 Anton From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 17:39:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 50FBDDED; Thu, 21 Mar 2013 17:39:25 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id BF6F4F02; Thu, 21 Mar 2013 17:39:24 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hm14so6875862wib.3 for ; Thu, 21 Mar 2013 10:39:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=to+hdFgorHkjx2V+OBAbjG123sLK/IrdNkiUSwIh7t8=; b=f+VgwIG8J5ji+AUj1Q7fRm4Qho+1GBEVCdllYLKR7Qf5XBgwOH/OoF6j6mkYHIZBUL ZfjIq1V5Ki3u1fvNuEAZtMnBUNHTUgraYepJxgAb0xVeLT92ruapSs2KTAD4QzGwKt/h WO6CA0Ow3al8+SXAixc8CA9GlBWzdyRXPbcl+DRHi4wtxRG8GqNrfZzmECta6Y37tJBj HHmWZnQoYYsQZdtd7ziPh4Ux+heS2bUCGeIbQtog4KvV/pnCzaDZ8OJ2yDwxUwAPCPMP 1iTYKzH1JDuUPAxsStJDQNqf3xCntBobFDDpIV5HQxRr8ibf3ut+WdR1MZF44TkXVoDQ YOAA== X-Received: by 10.180.13.197 with SMTP id j5mr6306237wic.21.1363887563887; Thu, 21 Mar 2013 10:39:23 -0700 (PDT) Received: from melon.localnet (81.33.91.91.rev.sfr.net. [91.91.33.81]) by mx.google.com with ESMTPS id dp5sm6067619wib.1.2013.03.21.10.39.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Mar 2013 10:39:23 -0700 (PDT) From: David Demelier To: Jeremy Chadwick Subject: Re: Panic : bad pte Date: Thu, 21 Mar 2013 18:39:19 +0100 Message-ID: <2259572.v8BpEBAfUW@melon> User-Agent: KMail/4.9.5 (FreeBSD/9.1-RELEASE-p1; KDE/4.9.5; amd64; ; ) In-Reply-To: References: <20130319174339.GA72813@icarus.home.lan> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Cc: Konstantin Belousov , freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:39:25 -0000 Le mercredi 20 mars 2013 20:09:42 David Demelier a =E9crit : > 2013/3/19 Jeremy Chadwick : > > On Tue, Mar 19, 2013 at 06:34:24PM +0100, David Demelier wrote: > >> Hello, > >>=20 > >> There it is, all my computers on FreeBSD 9.1-RELEASE had panic. I = can > >> just say there is a problem in the 9.1-RELEASE because I had no pa= nic > >> before. What afraid me is that my production server also panic'ed = a > >> few days ago, fortunately it does not appears so often. > >>=20 > >> This is a panic that happened on my desktop computer, with a graph= ic > >> card. The crash usually appears when X starts. > >>=20 > >> GNU gdb 6.1.1 [FreeBSD] > >> Copyright 2004 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, a= nd you > >> are welcome to change it and/or distribute copies of it under cert= ain > >> conditions. Type "show copying" to see the conditions. > >> There is absolutely no warranty for GDB. Type "show warranty" for= > >> details. > >> This GDB was configured as "amd64-marcel-freebsd"... > >>=20 > >> Unread portion of the kernel message buffer: > >> panic: bad pte > >> cpuid =3D 3 > >> KDB: stack backtrace: > >> Uptime: 2m31s > >> Dumping 183 out of 1950 > >> MB:..9%..18%..27%..35%..44%..53%..62%..79%..88%..96% > >>=20 > >> Reading symbols from /boot/modules/nvidia.ko...done. > >> Loaded symbols for /boot/modules/nvidia.ko > >> #0 doadump (textdump=3DVariable "textdump" is not available. > >> ) at pcpu.h:224 > >> 224 pcpu.h: No such file or directory. > >>=20 > >> in pcpu.h > >>=20 > >> (kgdb) bt > >> #0 doadump (textdump=3DVariable "textdump" is not available. > >> ) at pcpu.h:224 > >> #1 0x0000000000000004 in ?? () > >> #2 0xffffffff8048c156 in kern_reboot (howto=3D260) at > >> /usr/src/sys/kern/kern_shutdown.c:448 > >> #3 0xffffffff8048c619 in panic (fmt=3D0x1
) > >> at /usr/src/sys/kern/kern_shutdown.c:636 > >> #4 0xffffffff8065f88a in pmap_remove_pages (pmap=3D0xfffffe0005a2= fa60) > >> at /usr/src/sys/amd64/amd64/pmap.c:4156 > >> #5 0xffffffff8063d26b in vmspace_exit (td=3D0xfffffe0005a05470) a= t > >> /usr/src/sys/vm/vm_map.c:422 > >> #6 0xffffffff8045d725 in exit1 (td=3D0xfffffe0005a05470, rv=3DVar= iable > >> "rv" is not available. > >> ) at /usr/src/sys/kern/kern_exit.c:315 > >> #7 0xffffffff8045e5ce in sys_sys_exit (td=3DVariable "td" is not > >> available. > >> ) at /usr/src/sys/kern/kern_exit.c:122 > >> #8 0xffffffff8066737f in amd64_syscall (td=3D0xfffffe0005a05470, > >> traced=3D0) at subr_syscall.c:135 > >> #9 0xffffffff80652d97 in Xfast_syscall () at > >> /usr/src/sys/amd64/amd64/exception.S:387 > >> #10 0x0000000800d51c1c in ?? () > >> Previous frame inner to this frame (corrupt stack?) > >> (kgdb) > >>=20 > >> Of course I may do something wrong, and I hope so but unfortunatel= y I > >> can't find any solution. May the nvidia driver be the problem? > >=20 > > Interesting timing. Semi-recently (February) src/sys/amd64/amd64/p= map.c > > in 9.1-STABLE (not -RELEASE) was modified to increase the informati= on > > shown for this specific type of panic. See revision 247079: > >=20 > > http://svnweb.freebsd.org/base/stable/9/sys/amd64/amd64/pmap.c?view= =3Dlog > >=20 > > I've CC'd Konstantin Belousov (kib@), who should be able to help st= ep > > you through getting information out of the crash dump, to help trac= k > > down the root cause. > >=20 > > -- > >=20 > > | Jeremy Chadwick jdc@koitsu.org = | > > | UNIX Systems Administrator http://jdc.koitsu.org/ = | > > | Mountain View, CA, US = | > > | Making life hard for others since 1977. PGP 4BD6C0CB = | >=20 > You will not believe that, when I leave the desktop. I completely > detach the AC adaptor (usually at evening). And everyday when I plug > it and start the machine it panics. But when it reboots and start > again no panic anymore. I just can't believe it. >=20 > The panic is completely different from yesterday's one : >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x8010 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff8049db4e > stack pointer =3D 0x28:0xffffff8000225a90 > frame pointer =3D 0x28:0xfffffe000247c8e0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 10 (idle: cpu0) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > Uptime: 1m3s > Dumping 324 out of 1950 MB:..5%..15%..25%..35%..45%..55%..65%..74%..8= 4%..94% >=20 > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > #0 doadump (textdump=3DVariable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump (textdump=3DVariable "textdump" is not available. > ) at pcpu.h:224 > #1 0x0000000000000004 in ?? () > #2 0xffffffff80489506 in kern_reboot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:448 > #3 0xffffffff804899c9 in panic (fmt=3D0x1
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #4 0xffffffff80664e39 in trap_fatal (frame=3D0xc, eva=3DVariable "ev= a" is > not available. > ) at /usr/src/sys/amd64/amd64/trap.c:857 > #5 0xffffffff806651c4 in trap_pfault (frame=3D0xffffff80002259e0, > usermode=3D0) at /usr/src/sys/amd64/amd64/trap.c:773 > #6 0xffffffff806655bb in trap (frame=3D0xffffff80002259e0) at > /usr/src/sys/amd64/amd64/trap.c:456 > #7 0xffffffff8064fe5f in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:228 > #8 0xffffffff8049db4e in callout_tickstofirst (limit=3D250) at > /usr/src/sys/kern/kern_timeout.c:381 > #9 0xffffffff806761d1 in getnextcpuevent (event=3D0xffffff8000225b10= , > idle=3D1) at /usr/src/sys/kern/kern_clocksource.c:282 > #10 0xffffffff8067741e in cpu_idleclock () at > /usr/src/sys/kern/kern_clocksource.c:785 > #11 0xffffffff8065685a in cpu_idle (busy=3D0) at > /usr/src/sys/amd64/amd64/machdep.c:801 > #12 0xffffffff804b0a3f in sched_idletd (dummy=3DVariable "dummy" is n= ot > available. ) at /usr/src/sys/kern/sched_ule.c:2617 > #13 0xffffffff8045c88d in fork_exit (callout=3D0xffffffff804b07f0 > , arg=3D0x0, frame=3D0xffffff8000225c40) at > /usr/src/sys/kern/kern_fork.c:992 > #14 0xffffffff8065031e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:602 > #15 0x0000000000000000 in ?? () > #16 0x0000000000000000 in ?? () > #17 0x0000000000000001 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000000 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0xffffffff809fcdc0 in affinity () > #40 0x0000000000000000 in ?? () > #41 0xfffffe000247cd20 in ?? () > #42 0xfffffe000247c8e0 in ?? () > #43 0x0000000000000000 in ?? () > #44 0xffffff8000225aa8 in ?? () > #45 0xfffffe000247f8e0 in ?? () > #46 0xffffffff804b1b49 in sched_switch (td=3D0xffffffff804b07f0, > newtd=3D0x0, flags=3DVariable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1921 >=20 > As you can see the uptime is almost the same, just after the start. > I'm guessing if I have no hardware failure such as power problems. An= d > now I'm writing from it aftour an uptime of one hour without any > problem. This is just crazy. >=20 You can forget all my emails. It's definitively a hardware failure. Eve= n=20 Windows 7 is crashing now. A few weeks ago I have sent the mother board= + CPU=20 unit + memory to my reseller and they said there are no problem at all = so for=20 now I suspect hard drive or power supply failures, however I wonder how= these=20 computer parts may break the system.. Regards, --=20 David Demelier From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 18:59:32 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E587F716; Thu, 21 Mar 2013 18:59:32 +0000 (UTC) (envelope-from mich@FreeBSD.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id B1AB6378; Thu, 21 Mar 2013 18:59:32 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id EADA9289C3D; Thu, 21 Mar 2013 19:59:16 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Core Dump / panic sleeping thread From: Michael Landin Hostbaek In-Reply-To: <20130321075847.GR3794@kib.kiev.ua> Date: Thu, 21 Mar 2013 19:59:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D7E0213-C1BC-4CA8-BABD-256C17DD692D@FreeBSD.org> References: <20130320173100.GF3794@kib.kiev.ua> <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> <20130321075847.GR3794@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , Rick Macklem , freebsd-stable@FreeBSD.org, Andriy Gapon , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 18:59:33 -0000 On Mar 21, 2013, at 8:58 AM, Konstantin Belousov = wrote: > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: >> Well, read/write sharing of files over NFS is pretty rare, so I = suspect >> a truncation of a file by another client (or locally in the NFS = server) >> is a rare event. As such, not invalidating the buffers here doesn't = seem >> like a big issue? (The client uses np->n_size to determine EOF.) >>=20 >> Also, I think close-to-open consistency will typically throw away the >> buffers on the next open when it sees the mtime changed. (Yes, there >> won't necessarily be another open, but...) > nfs buffers are VMIO. Each VMIO buffer wires the pages it references. > Wired pages cannot be freed by vnode_pager_setsize() if the file is > truncated. Should I wait for a new patch, or should I give the one you sent = yesterday a try?=20 Thanks,=20 /mich From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 20:39:20 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 776D5241; Thu, 21 Mar 2013 20:39:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0579A99E; Thu, 21 Mar 2013 20:39:19 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2LKdDV1046422; Thu, 21 Mar 2013 22:39:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2LKdDV1046422 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2LKdDLR046421; Thu, 21 Mar 2013 22:39:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 21 Mar 2013 22:39:13 +0200 From: Konstantin Belousov To: Michael Landin Hostbaek Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130321203913.GE3794@kib.kiev.ua> References: <20130320173100.GF3794@kib.kiev.ua> <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> <20130321075847.GR3794@kib.kiev.ua> <2D7E0213-C1BC-4CA8-BABD-256C17DD692D@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XB8Bkk/uMyOj+nVp" Content-Disposition: inline In-Reply-To: <2D7E0213-C1BC-4CA8-BABD-256C17DD692D@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jeremy Chadwick , Rick Macklem , freebsd-stable@FreeBSD.org, Andriy Gapon , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 20:39:20 -0000 --XB8Bkk/uMyOj+nVp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 21, 2013 at 07:59:25PM +0100, Michael Landin Hostbaek wrote: >=20 > On Mar 21, 2013, at 8:58 AM, Konstantin Belousov wr= ote: >=20 > > On Wed, Mar 20, 2013 at 09:14:37PM -0400, Rick Macklem wrote: > >> Well, read/write sharing of files over NFS is pretty rare, so I suspect > >> a truncation of a file by another client (or locally in the NFS server) > >> is a rare event. As such, not invalidating the buffers here doesn't se= em > >> like a big issue? (The client uses np->n_size to determine EOF.) > >>=20 > >> Also, I think close-to-open consistency will typically throw away the > >> buffers on the next open when it sees the mtime changed. (Yes, there > >> won't necessarily be another open, but...) > > nfs buffers are VMIO. Each VMIO buffer wires the pages it references. > > Wired pages cannot be freed by vnode_pager_setsize() if the file is > > truncated. >=20 > Should I wait for a new patch, or should I give the one you sent yesterda= y a try?=20 >=20 > Thanks,=20 You should use the r248567 + r248581. --XB8Bkk/uMyOj+nVp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRS2/wAAoJEJDCuSvBvK1BGJ0P/2uk+dFlx3j0j5uxUHUAmzyb Q5oGOu2Kj0Pu9qRr1A9W+AetjT834jSHIaPvSoFJOtNUl90SE9nVLVZ0RA9O6bUM ZBl2mvEbaxx3hBMhJTWzCE49ntvcCUdabfBERV86rBRiSzuJaijx2s/DgOR54MPt q+6/F/Qkmvybo1UHmJNqwoC+Vt20gfhcVBQdHMwvdd649ms8CwZYstxM4HZDTfkf pbbaWAuVTkqF/bbO1Gg4i1eDwL+D2YUCCZV2AOn1IwProOu0zNmgJqa8naA5H5pv byg5+0usdQglslsg1iyLDQ3XyR4kN2YCVR1ZFkCun8kdw8Nfcnos1paWaS7ZQuO1 M2sDX49VybiMKcF+HERbrotlrTezegBn6QfMDEP9oSQtDoMd4CSUGY3jfdJ4JvZS CqR24Lo5eBUGYjRDpTyyTSC6zq3DK3vP2oMkwfp3vU0mHztUQ3Cf7z5p5LjqbTPi RHbDWahkp3JwRq6Q9JVJ6EP8rPWMCTYo0TN2BSTmw9lbgUkN+khjNEzfuCb36pjd 6GTLYzBbpg3TODkoEQziO9pHBuYAZUyBmwO0lawRmlRqnkp8hS9pRH8JTVxTzNRW CWVXZr8Chzneq1Et4MfgRth/iGIj3Cxvok7HGRC1AFuPMzQDf8FFsCup88pNFmhA ngqq4JwRaByjF2abKxwl =7dsu -----END PGP SIGNATURE----- --XB8Bkk/uMyOj+nVp-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 21 22:09:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87FD6C7D; Thu, 21 Mar 2013 22:09:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 49345E27; Thu, 21 Mar 2013 22:09:15 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e55c:d560:d108:32ea] (unknown [IPv6:2001:7b8:3a7:0:e55c:d560:d108:32ea]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C03D65C5B; Thu, 21 Mar 2013 23:09:06 +0100 (CET) Content-Type: multipart/mixed; boundary="Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: troubles with buildworld/sendmail/sasl/clang From: Dimitry Andric In-Reply-To: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> Date: Thu, 21 Mar 2013 23:09:08 +0100 Message-Id: <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> References: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1503) Cc: kpaasial@gmail.com, roberthuff@rcn.com, freebsd-stable@freebsd.org, beat.siegenthaler@beatsnet.com, freebsd-current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 22:09:15 -0000 --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 21, 2013, at 15:16, Anton Shterenlikht = wrote: > Kimmo Paasiala writes: ... > > > = /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8: > > > error: incompatible pointer types passing 'void ()' to = parameter of type > > > 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, = ENVELOPE *)' > > > [-Werror,-Wincompatible-pointer-types] > > > getsasldata, NULL, = XS_AUTH); > > > ^~~~~~~~~~~ ... > # cat /etc/make.conf > SENDMAIL_CFLAGS+=3D -I/usr/local/include -DSASL=3D2 > SENDMAIL_LDFLAGS+=3D -L/usr/local/lib > SENDMAIL_LDADD+=3D -lsasl2 Use the port, or the attached patch, to disable usage of stdbool.h. --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429 Content-Disposition: attachment; filename=sendmail-disable-stdbool-1.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="sendmail-disable-stdbool-1.diff" Content-Transfer-Encoding: 7bit Index: contrib/sendmail/include/sm/gen.h =================================================================== --- contrib/sendmail/include/sm/gen.h (revision 248230) +++ contrib/sendmail/include/sm/gen.h (working copy) @@ -51,7 +51,7 @@ ** Define bool, true, false (from the C99 standard) */ -# if SM_CONF_STDBOOL_H +# if SM_CONF_STDBOOL_H && 0 # include # else /* SM_CONF_STDBOOL_H */ # ifndef __cplusplus --Apple-Mail=_EA33AD19-AED4-4FCC-A396-907B0E557429-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 00:06:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 86A3B150; Fri, 22 Mar 2013 00:06:43 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D81CB2B4; Fri, 22 Mar 2013 00:06:42 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E1C3828428; Fri, 22 Mar 2013 00:59:53 +0100 (CET) Received: from [192.168.1.2] (unknown [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 5152E28422; Fri, 22 Mar 2013 00:59:51 +0100 (CET) Message-ID: <514B9EF6.3000607@quip.cz> Date: Fri, 22 Mar 2013 00:59:50 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Harald Schmalzbauer , Jamie Gritton , freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> In-Reply-To: <20130219212430.GA92116@felucia.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:06:43 -0000 Jeremie Le Hen wrote: > On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: >> schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): >>> On 02/15/13 09:27, Harald Schmalzbauer wrote: >>>> Hello, >>>> >>>> like already posted, on 9.1-R, I highly appreciate the new jail(8) and >>>> jail.conf capabilities. Thanks for that extension! >>>> >>>> Accidentally I saw that "devfs_ruleset" seems to be ignored. >>>> If I list /dev/ I see all the hosts disk devices etc. >>>> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>>> Inside the jail, >>>> sysctl security.jail.devfs_ruleset returnes "1". >>>> But like mentioned, I can access all devices... >>>> >>>> Thanks for any help, >>>> >>>> -Harry >>> >>> devfs_ruleset is only used along with mount.devfs - do you also have >>> that set in jail.conf? >> >> Thanks for your response. >> >> Yes, I have mount.devfs; set. >> Otherwise I wouldn't have any device inside my jail. Verified - and like >> intended, right? >> Another notable discrepancy: The man page tells that devfs_rulset is "4" >> by default. >> But when I don't set devfs_rulset in jail.conf at all, inside the jail, >> 'sysctl security.jail.devfs_ruleset': 0 >> When set, like mentioned above, it returns the corresponding value, but >> it doesn't have any effect. >> How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like >> to help finding the source, but have missed the whole new jail evolution... >> Inside my jails, I don't have a fstab, outside I have them defined and >> enabled with "mount" - and noticed the non-reverted umounting. > > Look at what's in /dev from you jail. There should a few pseudo > devices (see below), but no real devices: > > $ ls /dev > crypto log ptmx random stdin urandom zfs > fd null pts stderr stdout zero I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC I am now testing new jail.conf possibilities and I am seeing all devices in /dev in jail. Even if I set all this in my jail.conf exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.clean; mount.devfs; devfs_ruleset = 4; allow.set_hostname = false; path = "/vol0/jail/$name"; exec.consolelog = "/var/log/jail/$name.console"; mount.fstab = "/etc/fstab.$name"; ## Jail bali bali { host.hostname = "bali.XXXXXXX.YY; ip4.addr = xx.xx.xx.xx; devfs_ruleset = 4; } # jexec 4 tcsh root@bali:/ # ls -l /dev/ total 4 crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad10 -> ada3 lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s1 -> ada3s1 lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1a -> ada3s1a lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1b -> ada3s1b lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1d -> ada3s1d lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1e -> ada3s1e lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1f -> ada3s1f lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1g -> ada3s1g lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s2 -> ada3s2 lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2a -> ada3s2a lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2b -> ada3s2b lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2d -> ada3s2d lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2e -> ada3s2e lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad4 -> ada0 lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad6 -> ada1 lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad8 -> ada2 lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s1 -> ada2s1 lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1a -> ada2s1a lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1b -> ada2s1b lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1d -> ada2s1d lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1e -> ada2s1e lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1f -> ada2s1f lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1g -> ada2s1g lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s2 -> ada2s2 lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2a -> ada2s2a lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2b -> ada2s2b lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2d -> ada2s2d lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2e -> ada2s2e crw-r----- 1 root operator 0, 106 Mar 1 19:39 ada0 crw-r----- 1 root operator 0, 108 Mar 1 19:39 ada1 crw-r----- 1 root operator 0, 114 Mar 1 19:39 ada2 crw-r----- 1 root operator 0, 120 Mar 1 19:39 ada2s1 crw-r----- 1 root operator 0, 130 Mar 1 19:39 ada2s1a crw-r----- 1 root operator 0, 132 Mar 1 19:39 ada2s1b crw-r----- 1 root operator 0, 134 Mar 1 19:39 ada2s1d crw-r----- 1 root operator 0, 136 Mar 1 19:39 ada2s1e crw-r----- 1 root operator 0, 138 Mar 1 19:39 ada2s1f crw-r----- 1 root operator 0, 140 Mar 1 19:39 ada2s1g crw-r----- 1 root operator 0, 122 Mar 1 19:39 ada2s2 crw-r----- 1 root operator 0, 142 Mar 1 19:39 ada2s2a crw-r----- 1 root operator 0, 144 Mar 1 19:39 ada2s2b crw-r----- 1 root operator 0, 146 Mar 1 19:39 ada2s2d crw-r----- 1 root operator 0, 148 Mar 1 19:39 ada2s2e crw-r----- 1 root operator 0, 116 Mar 1 19:39 ada3 crw-r----- 1 root operator 0, 124 Mar 1 19:39 ada3s1 crw-r----- 1 root operator 0, 150 Mar 1 19:39 ada3s1a crw-r----- 1 root operator 0, 154 Mar 1 19:39 ada3s1b crw-r----- 1 root operator 0, 156 Mar 1 19:39 ada3s1d crw-r----- 1 root operator 0, 161 Mar 1 19:39 ada3s1e crw-r----- 1 root operator 0, 165 Mar 1 19:39 ada3s1f crw-r----- 1 root operator 0, 167 Mar 1 19:39 ada3s1g crw-r----- 1 root operator 0, 126 Mar 1 19:39 ada3s2 crw-r----- 1 root operator 0, 170 Mar 1 19:39 ada3s2a crw-r----- 1 root operator 0, 173 Mar 1 19:39 ada3s2b crw-r----- 1 root operator 0, 175 Mar 1 19:39 ada3s2d crw-r----- 1 root operator 0, 177 Mar 1 19:39 ada3s2e crw------- 1 root kmem 0, 19 Mar 1 19:39 audit crw------- 1 root wheel 0, 11 Mar 1 19:39 bpf lrwxr-xr-x 1 root wheel 3 Mar 22 00:46 bpf0 -> bpf dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 cam crw-r----- 1 root operator 0, 118 Mar 1 19:39 cd0 crw-r----- 1 root operator 0, 208 Mar 1 19:39 cd1 crw------- 1 root wheel 0, 5 Mar 22 00:43 console crw------- 1 root wheel 0, 60 Mar 1 19:39 consolectl crw-rw-rw- 1 root wheel 0, 10 Mar 1 19:39 ctty crw-rw---- 1 uucp dialer 0, 41 Mar 1 19:39 cuau0 crw-rw---- 1 uucp dialer 0, 42 Mar 1 19:39 cuau0.init crw-rw---- 1 uucp dialer 0, 43 Mar 1 19:39 cuau0.lock crw-rw---- 1 uucp dialer 0, 64 Mar 1 19:39 cuau1 crw-rw---- 1 uucp dialer 0, 65 Mar 1 19:39 cuau1.init crw-rw---- 1 uucp dialer 0, 66 Mar 1 19:39 cuau1.lock crw-r----- 1 root operator 0, 209 Mar 1 19:39 da0 crw-r----- 1 root operator 0, 210 Mar 1 19:39 da1 crw------- 1 root wheel 0, 20 Mar 1 19:39 dcons crw------- 1 root wheel 0, 4 Mar 1 19:39 devctl cr-------- 1 root wheel 0, 100 Mar 1 19:39 devstat crw------- 1 root wheel 0, 21 Mar 1 19:39 dgdb dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 fd crw------- 1 root wheel 0, 15 Mar 1 19:39 fido crw-r----- 1 root operator 0, 3 Mar 1 19:39 geom.ctl crw------- 1 root wheel 0, 28 Mar 1 19:39 io lrwxr-xr-x 1 root wheel 5 Mar 22 00:46 kbd0 -> ukbd0 lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 kbd1 -> kbdmux0 crw------- 1 root wheel 0, 13 Mar 1 19:39 kbdmux0 crw------- 1 root wheel 0, 9 Mar 1 19:39 klog crw-r----- 1 root kmem 0, 17 Mar 1 19:39 kmem dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 led crw------- 1 root wheel 0, 72 Mar 1 19:39 mdctl crw-r----- 1 root kmem 0, 16 Mar 1 19:39 mem crw-rw-rw- 1 root wheel 0, 7 Mar 1 19:39 midistat dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 mirror crw------- 1 root kmem 0, 18 Mar 1 19:39 nfslock crw-rw-rw- 1 root wheel 0, 22 Mar 22 00:55 null crw------- 1 root operator 0, 101 Mar 1 19:39 pass0 crw------- 1 root operator 0, 102 Mar 1 19:39 pass1 crw------- 1 root operator 0, 103 Mar 1 19:39 pass2 crw------- 1 root operator 0, 104 Mar 1 19:39 pass3 crw------- 1 root operator 0, 105 Mar 1 19:39 pass4 crw------- 1 root operator 0, 185 Mar 1 19:39 pass5 crw------- 1 root operator 0, 206 Mar 1 19:39 pass6 crw------- 1 root operator 0, 207 Mar 1 19:39 pass7 crw-r--r-- 1 root wheel 0, 24 Mar 1 19:39 pci crw------- 1 root wheel 0, 194 Mar 1 19:40 pf crw-rw-rw- 1 root wheel 0, 25 Mar 1 19:39 ptmx dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 pts crw-rw-rw- 1 root wheel 0, 26 Mar 1 20:40 random cr--r--r-- 1 root wheel 0, 6 Mar 1 19:39 sndstat lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stderr -> fd/2 lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stdin -> fd/0 lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stdout -> fd/1 crw------- 1 root wheel 0, 8 Mar 1 19:39 sysmouse crw------- 1 root wheel 0, 38 Mar 1 19:39 ttyu0 crw------- 1 root wheel 0, 39 Mar 1 19:39 ttyu0.init crw------- 1 root wheel 0, 40 Mar 1 19:39 ttyu0.lock crw------- 1 root wheel 0, 61 Mar 1 19:39 ttyu1 crw------- 1 root wheel 0, 62 Mar 1 19:39 ttyu1.init crw------- 1 root wheel 0, 63 Mar 1 19:39 ttyu1.lock crw------- 1 root wheel 0, 44 Mar 1 19:40 ttyv0 crw------- 1 root wheel 0, 45 Mar 1 19:40 ttyv1 crw------- 1 root wheel 0, 46 Mar 1 19:40 ttyv2 crw------- 1 root wheel 0, 47 Mar 1 19:40 ttyv3 crw------- 1 root wheel 0, 48 Mar 1 19:40 ttyv4 crw------- 1 root wheel 0, 49 Mar 1 19:40 ttyv5 crw------- 1 root wheel 0, 50 Mar 1 19:40 ttyv6 crw------- 1 root wheel 0, 51 Mar 1 19:40 ttyv7 crw------- 1 root wheel 0, 52 Mar 1 19:39 ttyv8 crw------- 1 root wheel 0, 53 Mar 1 19:39 ttyv9 crw------- 1 root wheel 0, 54 Mar 1 19:39 ttyva crw------- 1 root wheel 0, 55 Mar 1 19:39 ttyvb crw------- 1 root wheel 0, 56 Mar 1 19:39 ttyvc crw------- 1 root wheel 0, 57 Mar 1 19:39 ttyvd crw------- 1 root wheel 0, 58 Mar 1 19:39 ttyve crw------- 1 root wheel 0, 59 Mar 1 19:39 ttyvf dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 ufs dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 ufsid lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen0.1 -> usb/0.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen1.1 -> usb/1.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen1.2 -> usb/1.2.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen2.1 -> usb/2.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen3.1 -> usb/3.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen3.2 -> usb/3.2.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen4.1 -> usb/4.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen5.1 -> usb/5.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen6.1 -> usb/6.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen7.1 -> usb/7.1.0 lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen7.2 -> usb/7.2.0 crw------- 1 root wheel 0, 163 Mar 1 19:39 ukbd0 crw-r--r-- 1 root operator 0, 169 Mar 1 19:39 ums0 crw-r--r-- 1 root operator 0, 172 Mar 1 19:39 ums1 lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 urandom -> random dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 usb crw-r--r-- 1 root operator 0, 70 Mar 1 19:39 usbctl crw------- 1 root wheel 0, 69 Mar 1 19:39 vboxdrv crw------- 1 root wheel 0, 196 Mar 1 19:40 vboxnetctl crw------- 1 root operator 0, 71 Mar 1 19:39 xpt0 crw-rw-rw- 1 root wheel 0, 23 Mar 1 19:39 zero Is it a problem in my understanding of manpage / configuration, or is it a bug in jail command on 9.1-RELEASE? Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 00:09:55 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1554429B; Fri, 22 Mar 2013 00:09:55 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id EC0E42D5; Fri, 22 Mar 2013 00:09:54 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-157.hsd1.ut.comcast.net [174.52.130.157]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r2M09qW6033575; Thu, 21 Mar 2013 18:09:53 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <514BA14F.3090609@FreeBSD.org> Date: Thu, 21 Mar 2013 18:09:51 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> In-Reply-To: <514B9EF6.3000607@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:09:55 -0000 On 03/21/13 17:59, Miroslav Lachman wrote: > Jeremie Le Hen wrote: >> On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: >>> schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): >>>> On 02/15/13 09:27, Harald Schmalzbauer wrote: >>>>> Hello, >>>>> >>>>> like already posted, on 9.1-R, I highly appreciate the new jail(8) and >>>>> jail.conf capabilities. Thanks for that extension! >>>>> >>>>> Accidentally I saw that "devfs_ruleset" seems to be ignored. >>>>> If I list /dev/ I see all the hosts disk devices etc. >>>>> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>>>> Inside the jail, >>>>> sysctl security.jail.devfs_ruleset returnes "1". >>>>> But like mentioned, I can access all devices... >>>>> >>>>> Thanks for any help, >>>>> >>>>> -Harry >>>> >>>> devfs_ruleset is only used along with mount.devfs - do you also have >>>> that set in jail.conf? >>> >>> Thanks for your response. >>> >>> Yes, I have mount.devfs; set. >>> Otherwise I wouldn't have any device inside my jail. Verified - and like >>> intended, right? >>> Another notable discrepancy: The man page tells that devfs_rulset is "4" >>> by default. >>> But when I don't set devfs_rulset in jail.conf at all, inside the jail, >>> 'sysctl security.jail.devfs_ruleset': 0 >>> When set, like mentioned above, it returns the corresponding value, but >>> it doesn't have any effect. >>> How gets devfs_rulset handled? Does jail(8) do the whole job? I'd like >>> to help finding the source, but have missed the whole new jail >>> evolution... >>> Inside my jails, I don't have a fstab, outside I have them defined and >>> enabled with "mount" - and noticed the non-reverted umounting. >> >> Look at what's in /dev from you jail. There should a few pseudo >> devices (see below), but no real devices: >> >> $ ls /dev >> crypto log ptmx random stdin urandom zfs >> fd null pts stderr stdout zero > > I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC > > I am now testing new jail.conf possibilities and I am seeing all devices > in /dev in jail. > > Even if I set all this in my jail.conf > > exec.start = "/bin/sh /etc/rc"; > exec.stop = "/bin/sh /etc/rc.shutdown"; > exec.clean; > mount.devfs; > devfs_ruleset = 4; > allow.set_hostname = false; > > path = "/vol0/jail/$name"; > exec.consolelog = "/var/log/jail/$name.console"; > mount.fstab = "/etc/fstab.$name"; > > ## Jail bali > bali { > host.hostname = "bali.XXXXXXX.YY; > ip4.addr = xx.xx.xx.xx; > devfs_ruleset = 4; > } > > > > > > # jexec 4 tcsh > > root@bali:/ # ls -l /dev/ > total 4 > crw-r--r-- 1 root wheel 0, 35 Mar 1 19:39 acpi > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad10 -> ada3 > lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s1 -> ada3s1 > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1a -> ada3s1a > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1b -> ada3s1b > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1d -> ada3s1d > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1e -> ada3s1e > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1f -> ada3s1f > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s1g -> ada3s1g > lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad10s2 -> ada3s2 > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2a -> ada3s2a > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2b -> ada3s2b > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2d -> ada3s2d > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad10s2e -> ada3s2e > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad4 -> ada0 > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad6 -> ada1 > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 ad8 -> ada2 > lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s1 -> ada2s1 > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1a -> ada2s1a > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1b -> ada2s1b > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1d -> ada2s1d > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1e -> ada2s1e > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1f -> ada2s1f > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s1g -> ada2s1g > lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 ad8s2 -> ada2s2 > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2a -> ada2s2a > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2b -> ada2s2b > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2d -> ada2s2d > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 ad8s2e -> ada2s2e > crw-r----- 1 root operator 0, 106 Mar 1 19:39 ada0 > crw-r----- 1 root operator 0, 108 Mar 1 19:39 ada1 > crw-r----- 1 root operator 0, 114 Mar 1 19:39 ada2 > crw-r----- 1 root operator 0, 120 Mar 1 19:39 ada2s1 > crw-r----- 1 root operator 0, 130 Mar 1 19:39 ada2s1a > crw-r----- 1 root operator 0, 132 Mar 1 19:39 ada2s1b > crw-r----- 1 root operator 0, 134 Mar 1 19:39 ada2s1d > crw-r----- 1 root operator 0, 136 Mar 1 19:39 ada2s1e > crw-r----- 1 root operator 0, 138 Mar 1 19:39 ada2s1f > crw-r----- 1 root operator 0, 140 Mar 1 19:39 ada2s1g > crw-r----- 1 root operator 0, 122 Mar 1 19:39 ada2s2 > crw-r----- 1 root operator 0, 142 Mar 1 19:39 ada2s2a > crw-r----- 1 root operator 0, 144 Mar 1 19:39 ada2s2b > crw-r----- 1 root operator 0, 146 Mar 1 19:39 ada2s2d > crw-r----- 1 root operator 0, 148 Mar 1 19:39 ada2s2e > crw-r----- 1 root operator 0, 116 Mar 1 19:39 ada3 > crw-r----- 1 root operator 0, 124 Mar 1 19:39 ada3s1 > crw-r----- 1 root operator 0, 150 Mar 1 19:39 ada3s1a > crw-r----- 1 root operator 0, 154 Mar 1 19:39 ada3s1b > crw-r----- 1 root operator 0, 156 Mar 1 19:39 ada3s1d > crw-r----- 1 root operator 0, 161 Mar 1 19:39 ada3s1e > crw-r----- 1 root operator 0, 165 Mar 1 19:39 ada3s1f > crw-r----- 1 root operator 0, 167 Mar 1 19:39 ada3s1g > crw-r----- 1 root operator 0, 126 Mar 1 19:39 ada3s2 > crw-r----- 1 root operator 0, 170 Mar 1 19:39 ada3s2a > crw-r----- 1 root operator 0, 173 Mar 1 19:39 ada3s2b > crw-r----- 1 root operator 0, 175 Mar 1 19:39 ada3s2d > crw-r----- 1 root operator 0, 177 Mar 1 19:39 ada3s2e > crw------- 1 root kmem 0, 19 Mar 1 19:39 audit > crw------- 1 root wheel 0, 11 Mar 1 19:39 bpf > lrwxr-xr-x 1 root wheel 3 Mar 22 00:46 bpf0 -> bpf > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 cam > crw-r----- 1 root operator 0, 118 Mar 1 19:39 cd0 > crw-r----- 1 root operator 0, 208 Mar 1 19:39 cd1 > crw------- 1 root wheel 0, 5 Mar 22 00:43 console > crw------- 1 root wheel 0, 60 Mar 1 19:39 consolectl > crw-rw-rw- 1 root wheel 0, 10 Mar 1 19:39 ctty > crw-rw---- 1 uucp dialer 0, 41 Mar 1 19:39 cuau0 > crw-rw---- 1 uucp dialer 0, 42 Mar 1 19:39 cuau0.init > crw-rw---- 1 uucp dialer 0, 43 Mar 1 19:39 cuau0.lock > crw-rw---- 1 uucp dialer 0, 64 Mar 1 19:39 cuau1 > crw-rw---- 1 uucp dialer 0, 65 Mar 1 19:39 cuau1.init > crw-rw---- 1 uucp dialer 0, 66 Mar 1 19:39 cuau1.lock > crw-r----- 1 root operator 0, 209 Mar 1 19:39 da0 > crw-r----- 1 root operator 0, 210 Mar 1 19:39 da1 > crw------- 1 root wheel 0, 20 Mar 1 19:39 dcons > crw------- 1 root wheel 0, 4 Mar 1 19:39 devctl > cr-------- 1 root wheel 0, 100 Mar 1 19:39 devstat > crw------- 1 root wheel 0, 21 Mar 1 19:39 dgdb > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 fd > crw------- 1 root wheel 0, 15 Mar 1 19:39 fido > crw-r----- 1 root operator 0, 3 Mar 1 19:39 geom.ctl > crw------- 1 root wheel 0, 28 Mar 1 19:39 io > lrwxr-xr-x 1 root wheel 5 Mar 22 00:46 kbd0 -> ukbd0 > lrwxr-xr-x 1 root wheel 7 Mar 22 00:46 kbd1 -> kbdmux0 > crw------- 1 root wheel 0, 13 Mar 1 19:39 kbdmux0 > crw------- 1 root wheel 0, 9 Mar 1 19:39 klog > crw-r----- 1 root kmem 0, 17 Mar 1 19:39 kmem > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 led > crw------- 1 root wheel 0, 72 Mar 1 19:39 mdctl > crw-r----- 1 root kmem 0, 16 Mar 1 19:39 mem > crw-rw-rw- 1 root wheel 0, 7 Mar 1 19:39 midistat > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 mirror > crw------- 1 root kmem 0, 18 Mar 1 19:39 nfslock > crw-rw-rw- 1 root wheel 0, 22 Mar 22 00:55 null > crw------- 1 root operator 0, 101 Mar 1 19:39 pass0 > crw------- 1 root operator 0, 102 Mar 1 19:39 pass1 > crw------- 1 root operator 0, 103 Mar 1 19:39 pass2 > crw------- 1 root operator 0, 104 Mar 1 19:39 pass3 > crw------- 1 root operator 0, 105 Mar 1 19:39 pass4 > crw------- 1 root operator 0, 185 Mar 1 19:39 pass5 > crw------- 1 root operator 0, 206 Mar 1 19:39 pass6 > crw------- 1 root operator 0, 207 Mar 1 19:39 pass7 > crw-r--r-- 1 root wheel 0, 24 Mar 1 19:39 pci > crw------- 1 root wheel 0, 194 Mar 1 19:40 pf > crw-rw-rw- 1 root wheel 0, 25 Mar 1 19:39 ptmx > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 pts > crw-rw-rw- 1 root wheel 0, 26 Mar 1 20:40 random > cr--r--r-- 1 root wheel 0, 6 Mar 1 19:39 sndstat > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stderr -> fd/2 > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stdin -> fd/0 > lrwxr-xr-x 1 root wheel 4 Mar 22 00:46 stdout -> fd/1 > crw------- 1 root wheel 0, 8 Mar 1 19:39 sysmouse > crw------- 1 root wheel 0, 38 Mar 1 19:39 ttyu0 > crw------- 1 root wheel 0, 39 Mar 1 19:39 ttyu0.init > crw------- 1 root wheel 0, 40 Mar 1 19:39 ttyu0.lock > crw------- 1 root wheel 0, 61 Mar 1 19:39 ttyu1 > crw------- 1 root wheel 0, 62 Mar 1 19:39 ttyu1.init > crw------- 1 root wheel 0, 63 Mar 1 19:39 ttyu1.lock > crw------- 1 root wheel 0, 44 Mar 1 19:40 ttyv0 > crw------- 1 root wheel 0, 45 Mar 1 19:40 ttyv1 > crw------- 1 root wheel 0, 46 Mar 1 19:40 ttyv2 > crw------- 1 root wheel 0, 47 Mar 1 19:40 ttyv3 > crw------- 1 root wheel 0, 48 Mar 1 19:40 ttyv4 > crw------- 1 root wheel 0, 49 Mar 1 19:40 ttyv5 > crw------- 1 root wheel 0, 50 Mar 1 19:40 ttyv6 > crw------- 1 root wheel 0, 51 Mar 1 19:40 ttyv7 > crw------- 1 root wheel 0, 52 Mar 1 19:39 ttyv8 > crw------- 1 root wheel 0, 53 Mar 1 19:39 ttyv9 > crw------- 1 root wheel 0, 54 Mar 1 19:39 ttyva > crw------- 1 root wheel 0, 55 Mar 1 19:39 ttyvb > crw------- 1 root wheel 0, 56 Mar 1 19:39 ttyvc > crw------- 1 root wheel 0, 57 Mar 1 19:39 ttyvd > crw------- 1 root wheel 0, 58 Mar 1 19:39 ttyve > crw------- 1 root wheel 0, 59 Mar 1 19:39 ttyvf > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 ufs > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 ufsid > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen0.1 -> usb/0.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen1.1 -> usb/1.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen1.2 -> usb/1.2.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen2.1 -> usb/2.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen3.1 -> usb/3.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen3.2 -> usb/3.2.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen4.1 -> usb/4.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen5.1 -> usb/5.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen6.1 -> usb/6.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen7.1 -> usb/7.1.0 > lrwxr-xr-x 1 root wheel 9 Mar 22 00:46 ugen7.2 -> usb/7.2.0 > crw------- 1 root wheel 0, 163 Mar 1 19:39 ukbd0 > crw-r--r-- 1 root operator 0, 169 Mar 1 19:39 ums0 > crw-r--r-- 1 root operator 0, 172 Mar 1 19:39 ums1 > lrwxr-xr-x 1 root wheel 6 Mar 22 00:46 urandom -> random > dr-xr-xr-x 2 root wheel 512 Mar 22 00:46 usb > crw-r--r-- 1 root operator 0, 70 Mar 1 19:39 usbctl > crw------- 1 root wheel 0, 69 Mar 1 19:39 vboxdrv > crw------- 1 root wheel 0, 196 Mar 1 19:40 vboxnetctl > crw------- 1 root operator 0, 71 Mar 1 19:39 xpt0 > crw-rw-rw- 1 root wheel 0, 23 Mar 1 19:39 zero > > > > Is it a problem in my understanding of manpage / configuration, or is it > a bug in jail command on 9.1-RELEASE? > > Miroslav Lachman It's a bug (deficiency) in the jail command. - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 00:20:44 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC5585D9; Fri, 22 Mar 2013 00:20:44 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6D97733E; Fri, 22 Mar 2013 00:20:44 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id F07AB28422; Fri, 22 Mar 2013 01:20:42 +0100 (CET) Received: from [192.168.1.2] (unknown [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 02D1728429; Fri, 22 Mar 2013 01:20:41 +0100 (CET) Message-ID: <514BA3D9.5010901@quip.cz> Date: Fri, 22 Mar 2013 01:20:41 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Jamie Gritton Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> In-Reply-To: <514BA14F.3090609@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:20:44 -0000 Jamie Gritton wrote: > On 03/21/13 17:59, Miroslav Lachman wrote: >> Jeremie Le Hen wrote: >>> On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: >>>> schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): >>>>> On 02/15/13 09:27, Harald Schmalzbauer wrote: >>>>>> Hello, >>>>>> >>>>>> like already posted, on 9.1-R, I highly appreciate the new jail(8) >>>>>> and >>>>>> jail.conf capabilities. Thanks for that extension! >>>>>> >>>>>> Accidentally I saw that "devfs_ruleset" seems to be ignored. >>>>>> If I list /dev/ I see all the hosts disk devices etc. >>>>>> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>>>>> Inside the jail, >>>>>> sysctl security.jail.devfs_ruleset returnes "1". >>>>>> But like mentioned, I can access all devices... [...] >> I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC >> >> I am now testing new jail.conf possibilities and I am seeing all devices >> in /dev in jail. >> >> Even if I set all this in my jail.conf >> >> exec.start = "/bin/sh /etc/rc"; >> exec.stop = "/bin/sh /etc/rc.shutdown"; >> exec.clean; >> mount.devfs; >> devfs_ruleset = 4; >> allow.set_hostname = false; >> >> path = "/vol0/jail/$name"; >> exec.consolelog = "/var/log/jail/$name.console"; >> mount.fstab = "/etc/fstab.$name"; >> >> ## Jail bali >> bali { >> host.hostname = "bali.XXXXXXX.YY; >> ip4.addr = xx.xx.xx.xx; >> devfs_ruleset = 4; >> } [...] >> Is it a problem in my understanding of manpage / configuration, or is it >> a bug in jail command on 9.1-RELEASE? >> >> Miroslav Lachman > > It's a bug (deficiency) in the jail command. Is there a workaround or is it impossible to use jails with devfs on FreeBSD 9.1? Shouldn't it be mentioned in 9.1 errata? Is it fixed in stable/9? Thank you for your reply and your great work on new jails! Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 00:46:59 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ACEBE9A2; Fri, 22 Mar 2013 00:46:59 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6D07D3FF; Fri, 22 Mar 2013 00:46:59 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-157.hsd1.ut.comcast.net [174.52.130.157]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r2M0kvMm034059; Thu, 21 Mar 2013 18:46:58 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <514BAA01.20402@FreeBSD.org> Date: Thu, 21 Mar 2013 18:46:57 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: new jail(8) ignoring devfs_ruleset? References: <511E61F5.1000805@omnilan.de> <511EC759.4060704@FreeBSD.org> <5121EC52.5040502@omnilan.de> <20130219212430.GA92116@felucia.tataz.chchile.org> <514B9EF6.3000607@quip.cz> <514BA14F.3090609@FreeBSD.org> <514BA3D9.5010901@quip.cz> In-Reply-To: <514BA3D9.5010901@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 00:46:59 -0000 On 03/21/13 18:20, Miroslav Lachman wrote: > Jamie Gritton wrote: >> On 03/21/13 17:59, Miroslav Lachman wrote: >>> Jeremie Le Hen wrote: >>>> On Mon, Feb 18, 2013 at 09:54:42AM +0100, Harald Schmalzbauer wrote: >>>>> schrieb Jamie Gritton am 16.02.2013 00:40 (localtime): >>>>>> On 02/15/13 09:27, Harald Schmalzbauer wrote: >>>>>>> Hello, >>>>>>> >>>>>>> like already posted, on 9.1-R, I highly appreciate the new jail(8) >>>>>>> and >>>>>>> jail.conf capabilities. Thanks for that extension! >>>>>>> >>>>>>> Accidentally I saw that "devfs_ruleset" seems to be ignored. >>>>>>> If I list /dev/ I see all the hosts disk devices etc. >>>>>>> I set "devfs_ruleset = 4;" and "enforce_statfs = 1;" in jail.conf. >>>>>>> Inside the jail, >>>>>>> sysctl security.jail.devfs_ruleset returnes "1". >>>>>>> But like mentioned, I can access all devices... > > [...] > >>> I can confirm mentioned problem on my FreeBSD 9.1-RELEASE amd64 GENERIC >>> >>> I am now testing new jail.conf possibilities and I am seeing all devices >>> in /dev in jail. >>> >>> Even if I set all this in my jail.conf >>> >>> exec.start = "/bin/sh /etc/rc"; >>> exec.stop = "/bin/sh /etc/rc.shutdown"; >>> exec.clean; >>> mount.devfs; >>> devfs_ruleset = 4; >>> allow.set_hostname = false; >>> >>> path = "/vol0/jail/$name"; >>> exec.consolelog = "/var/log/jail/$name.console"; >>> mount.fstab = "/etc/fstab.$name"; >>> >>> ## Jail bali >>> bali { >>> host.hostname = "bali.XXXXXXX.YY; >>> ip4.addr = xx.xx.xx.xx; >>> devfs_ruleset = 4; >>> } > > [...] > >>> Is it a problem in my understanding of manpage / configuration, or is it >>> a bug in jail command on 9.1-RELEASE? >> >> It's a bug (deficiency) in the jail command. > > Is there a workaround or is it impossible to use jails with devfs on > FreeBSD 9.1? > Shouldn't it be mentioned in 9.1 errata? > > Is it fixed in stable/9? > > Thank you for your reply and your great work on new jails! It's not fixed anywhere yet - it sometimes works in current, and sometimes doesn't. I've been meaning to patch it up, but it the problem is what I think it is, the patching up is a pretty big operation. It doesn't mean you can't use jails with devfs in 9.1, just that you can't use them with jail.conf. The old jail rc file that's all shell-based is still the official jail startup method, and that one still works. So existing systems will still work as expected, hence no errata. - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 02:59:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 88756E90 for ; Fri, 22 Mar 2013 02:59:14 +0000 (UTC) (envelope-from ca+envelope@esmtp.org) Received: from zardoc.esmtp.org (zardoc.esmtp.org [70.36.157.240]) by mx1.freebsd.org (Postfix) with ESMTP id 6D70FA6F for ; Fri, 22 Mar 2013 02:59:14 +0000 (UTC) Received: from quiet.esmtp.org (localhost. [127.0.0.1]) by zardoc.esmtp.org (MeTA1-1.0.Alpha14.0) with ESMTPS (TLS=TLSv1/SSLv3, cipher=DHE-RSA-AES256-SHA, bits=256, verify=FAIL) id S00000000001BD5E200; Thu, 21 Mar 2013 19:49:06 -0700 Received: (from ca@localhost) by quiet.esmtp.org (8.14.3/8.12.10.Beta0/Submit) id r2M2n6oh028732 for freebsd-stable@freebsd.org; Thu, 21 Mar 2013 19:49:06 -0700 (PDT) Date: Thu, 21 Mar 2013 19:49:06 -0700 From: Claus Assmann To: freebsd-stable@freebsd.org Subject: Re: troubles with buildworld/sendmail/sasl/clang Message-ID: <20130322024906.GA1681@quiet.esmtp.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-08-27) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 02:59:14 -0000 On Thu, Mar 21, 2013, Dimitry Andric wrote: > Use the port, or the attached patch, to disable usage of stdbool.h. It might be a better idea to change include/sm/os/sm_os_freebsd.h to set SM_CONF_STDBOOL_H See also libsm/README. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 07:38:43 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0B70FCBD for ; Fri, 22 Mar 2013 07:38:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEAA91A for ; Fri, 22 Mar 2013 07:38:42 +0000 (UTC) Received: from ur.dons.net.au (ppp14-2-11-4.lns21.adl2.internode.on.net [14.2.11.4]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r2M7c9tt085289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Mar 2013 18:08:15 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Mar 2013 18:08:09 +1030 Subject: KDE login causing processes stuck in zfs wchan To: "freebsd-stable@freebsd.org stable" Message-Id: <5D68BC49-DB3F-4387-972A-C2522519A086@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 07:38:43 -0000 Hi, I recently updated to KDE 4.9.5 and I've found that unless I disable = vfs.usermount (which stops gvfs from mounting) everything gets stuck in = [zfs] eventually. This is running on.. FreeBSD midget.dons.net.au 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #10 = r241435M: Thu Oct 11 15:03:22 CST 2012 = darius@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET amd64 Does anyone have a similar experience? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 08:22:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 591A07E3 for ; Fri, 22 Mar 2013 08:22:41 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38F68D15 for ; Fri, 22 Mar 2013 08:22:41 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id jt11so236370pbb.13 for ; Fri, 22 Mar 2013 01:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PsOrzPRe81SrGS/2xygXZNog9g15datJrA9r7JAyLoc=; b=HqceKkyit1h3aca3cc5hy0igVaT3Obh0e+9Mc0E+0Q4vO+1mvm4IdgMWAmUQH7UMiS /47EqDxJ1aJHo8CLYCHzKPUbI3loUB4v9Jwet91/4M/79VO4cvgwx9bn5NJBiC7mK2zY OCykWvJuQ/s6I3ASzSrdKNiGWOQqsC2lGT3nEhrzsjs9nxL0+XnUve5QoQqH90bLKzUP W1dxapZ2CTjebPqLKsX9sMyIKhIEE6Dhhh3f7vtmkw7N4qULwj4cLYA4RAPapfxhnGve xCCvRRx35bnXLBvatr5vfRc90POuvJTpD+g5+sx1GGtROhAcH9JqGdjxbmZnceArirS9 Tt3A== MIME-Version: 1.0 X-Received: by 10.68.213.7 with SMTP id no7mr1317048pbc.48.1363940560642; Fri, 22 Mar 2013 01:22:40 -0700 (PDT) Received: by 10.68.36.69 with HTTP; Fri, 22 Mar 2013 01:22:40 -0700 (PDT) In-Reply-To: <5D68BC49-DB3F-4387-972A-C2522519A086@gsoft.com.au> References: <5D68BC49-DB3F-4387-972A-C2522519A086@gsoft.com.au> Date: Fri, 22 Mar 2013 10:22:40 +0200 Message-ID: Subject: Re: KDE login causing processes stuck in zfs wchan From: Alexander Yerenkow To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-stable@freebsd.org stable" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:22:41 -0000 2013/3/22 Daniel O'Connor > Hi, > I recently updated to KDE 4.9.5 and I've found that unless I disable > vfs.usermount (which stops gvfs from mounting) everything gets stuck in > [zfs] eventually. > > If you could produce ps axwwwww & mount Maybe I could guess where's problem(s) lies. > This is running on.. > FreeBSD midget.dons.net.au 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #10 > r241435M: Thu Oct 11 15:03:22 CST 2012 darius@midget.dons.net.au:/usr/obj/usr/src/sys/MIDGET > amd64 > > Does anyone have a similar experience? > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 14:09:41 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FF9E402; Fri, 22 Mar 2013 14:09:41 +0000 (UTC) (envelope-from mich@FreeBSD.org) Received: from odometre.fr (mail.prodnet.eu [188.165.207.102]) by mx1.freebsd.org (Postfix) with ESMTP id CF792DF6; Fri, 22 Mar 2013 14:09:40 +0000 (UTC) Received: from [192.168.1.3] (dag94-5-88-173-204-6.fbx.proxad.net [88.173.204.6]) by odometre.fr (Postfix) with ESMTPA id EA2E5289C23; Fri, 22 Mar 2013 15:09:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Core Dump / panic sleeping thread From: Michael Landin Hostbaek In-Reply-To: <20130321203913.GE3794@kib.kiev.ua> Date: Fri, 22 Mar 2013 15:09:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: <0A7A4AC6-FFCA-41F3-8758-B25C62FCA6FC@FreeBSD.org> References: <20130320173100.GF3794@kib.kiev.ua> <223607151.4129243.1363828477555.JavaMail.root@erie.cs.uoguelph.ca> <20130321075847.GR3794@kib.kiev.ua> <2D7E0213-C1BC-4CA8-BABD-256C17DD692D@FreeBSD.org> <20130321203913.GE3794@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , Rick Macklem , freebsd-stable@FreeBSD.org, John Baldwin , Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:09:41 -0000 On Mar 21, 2013, at 9:39 PM, Konstantin Belousov wrote: > > You should use the r248567 + r248581. OK thanks. I've upgraded to 9-STABLE and applied your patches. Will let you know if I experience further crashes. thanks, /mich From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 15:43:43 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 792DE773 for ; Fri, 22 Mar 2013 15:43:43 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB2E7F2 for ; Fri, 22 Mar 2013 15:43:42 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id r2MEE3eX016773 for ; Fri, 22 Mar 2013 10:14:03 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id ZJR36630; Fri, 22 Mar 2013 10:14:03 -0400 (EDT) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id r2MEE3Ii030199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 22 Mar 2013 10:14:03 -0400 From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Virtio and GEOM labels Message-Id: Date: Fri, 22 Mar 2013 10:14:03 -0400 To: "stable@FreeBSD.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020201.514C672B.0257,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:43:43 -0000 I'm running FreeBSD 9-STABLE as a guest under RHEL 6.4 KVM = virtualisation. I have networking and storage in the FreeBSD guest = using the Virtio drivers (with the virtual disk set to "Virtio" in the = definition on the host). Everything is working nicely: I have a vtnet = network adapter and see vtbd devices for my virtual disks in FreeBSD. = Performance is much better compared with an emulated IDE device. The odd thing is that I don't see GEOM labels reflected in /dev. For = example, I have GPT labels defined in the guest, but I don't see them = show up under /dev/gpt. Similarly, my UFS labels don't show up under = /dev/ufs. I *do* see a /dev/gptid. That appears to be the only label = that shows up. Is there something special I need to do to get GPT and UFS labels to = appear when using Virtio? It seems to me that Virtio block devices = appear to be somewhat unusual. Unlike regular ATA and SCSI devices, my = vtbd devices don't appear in the boot dmesg (although a vtblk device = does), and "camcontrol devlist" does not list them. It's not clear to = me how I am supposed to interact with them other than via basic device = I/O through /dev/vtbdX. I thought that the virtio_scsi module might = make them appear as "da" devices and able to interacted with via = camcontrol, but this doesn't seem to be the case. I've included my system dmesg at the end of this message. Cheers, Paul. =3D=3D=3D=3D=3D Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #0 r248465: Mon Mar 18 11:19:23 EDT 2013 pmather@freebsd9.virtual.lib.vt.edu:/usr/obj/usr/src/sys/KVMTEST = amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: QEMU Virtual CPU version (cpu64-rhel6) (2100.15-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x6d3 Family =3D 0x6 Model =3D 0xd = Stepping =3D 3 = Features=3D0x783f3ff Features2=3D0x80002001 AMD Features=3D0x22500800 AMD Features2=3D0x73 real memory =3D 8589934592 (8192 MB) avail memory =3D 8255410176 (7872 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc020-0xc03f irq 11 = at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem = 0xf0000000-0xf1ffffff,0xf2000000-0xf2000fff at device 2.0 on pci0 virtio_pci0: port 0xc040-0xc05f mem = 0xf2020000-0xf2020fff irq 11 at device 3.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x711fffe3 = virtio_pci0: negotiated features: 0x110fbba3 = vtnet0: Ethernet address: 52:54:00:3e:48:94 virtio_pci1: port 0xc060-0xc07f irq 10 at = device 5.0 on pci0 vtballoon0: on virtio_pci1 virtio_pci1: host features: 0x71000002 = virtio_pci1: negotiated features: 0x0 virtio_pci2: port 0xc080-0xc0bf mem = 0xf2040000-0xf2040fff irq 10 at device 6.0 on pci0 vtblk0: on virtio_pci2 virtio_pci2: host features: 0x71000654 = virtio_pci2: negotiated features: 0x10000254 = vtblk0: 8192MB (16777216 512 byte sectors) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 uart0: port 0x3f8-0x3ff irq = 4 flags 0x10 on acpi0 orm0: at iomem 0xc9000-0xc97ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 ctl: CAM Target Layer loaded Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/vtbd0p2 [rw]... From owner-freebsd-stable@FreeBSD.ORG Fri Mar 22 19:48:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 554C4511 for ; Fri, 22 Mar 2013 19:48:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) by mx1.freebsd.org (Postfix) with ESMTP id 1E977FD4 for ; Fri, 22 Mar 2013 19:48:38 +0000 (UTC) X_CMAE_Category: 0,0 Undefined,Undefined X-CNFS-Analysis: v=2.0 cv=EehKsYaC c=1 sm=0 a=0NJkuBbZY5VCdgJ+v5fl0w==:17 a=8jhF2qGmtvsA:10 a=AaUjGI9IrlcA:10 a=kj9zAlcOel0A:10 a=OA2lqS22AAAA:8 a=sIt-5M63AAAA:8 a=KS5gVQhY--UA:10 a=WIFmMkYa0n_S9hbRSjQA:9 a=CjuIK1q_8ugA:10 a=0NJkuBbZY5VCdgJ+v5fl0w==:117 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=roberthuff@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=roberthuff@rcn.com; spf=neutral; sender-id=neutral Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 209.6.84.183 is neither permitted nor denied by domain of rcn.com) Received: from [209.6.84.183] ([209.6.84.183:52459] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 2.2.3.49 r(42060/42061)) with ESMTP id DF/34-28841-E85BC415; Fri, 22 Mar 2013 15:48:32 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20812.46478.436088.992576@jerusalem.litteratus.org> Date: Fri, 22 Mar 2013 15:48:30 -0400 To: Dimitry Andric Subject: Re: troubles with buildworld/sendmail/sasl/clang In-Reply-To: <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> References: <201303211416.r2LEG8cG041216@mech-cluster241.men.bris.ac.uk> <7DFCA510-5230-4EB6-8199-199DE7F8DE67@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid Cc: roberthuff@rcn.com, beat.siegenthaler@beatsnet.com, kpaasial@gmail.com, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, mexas@bristol.ac.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 19:48:39 -0000 Dimitry Andric writes: > Use the port, or the attached patch, to disable usage of > stdbool.h. Using the patch, world now compiles successfully. Thank you very much, Robert Huff From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 00:17:51 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF4D2FF3; Sat, 23 Mar 2013 00:17:51 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [IPv6:2607:fc50:1000:c200::face]) by mx1.freebsd.org (Postfix) with ESMTP id 94544DB2; Sat, 23 Mar 2013 00:17:51 +0000 (UTC) Received: from glenbarber.us (nucleus.glenbarber.us [IPv6:2001:470:8:1205:2:2:ff:29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 7256E23F66A; Fri, 22 Mar 2013 20:17:50 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.0 onyx.glenbarber.us 7256E23F66A Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Fri, 22 Mar 2013 20:17:48 -0400 From: Glen Barber To: freebsd-stable@FreeBSD.org Subject: FreeBSD 8.4-BETA1 is now available Message-ID: <20130323001748.GE1502@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ep0oHQY+/Gbo/zt0" Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Release Engineering Team X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:17:52 -0000 --ep0oHQY+/Gbo/zt0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The first BETA build of the 8.4-RELEASE release cycle is now available on the FTP servers for the amd64, i386, and pc98 architectures. The SHA256/MD5 sums are tacked on to the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/ (or any of the FreeBSD mirror sites). Since the stable/8 branch is relatively mature we hope there will only be one BETA build for this release cycle. If testing does not turn up any show-stopper caliber problems the next test build will be RC1. If you notice problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system use "stable/8". If you would like to use csup/cvsup mechanisms instead the branch tag to use is "RELENG_8". Please be aware that cvsup and CVS are both deprecated, and while upgrades using CVS or cvsup may work now they will not be supported for security updates through the life of 8.4. The following known issues are present in 8.4-BETA1 1) Due to a change in sshd, sshd does not look for authorized_keys2 in addition to authorized_keys. This will be fixed prior the next release. 2) Selecting 'All' on the 'Choose Distributions' screen attempts to install a DEBUG kernel which is not present in the image so the installation will fail. Just select one of the other distributions ("Developer", "Kern-Developer", "User", etc). 3) There is an accidental breakage in the OpenSSL ABI in this BETA build that will be fixed before the next test build. Applications built against OpenSSL will need to be rebuilt after upgrading to 8.4-BETA1. Additionally, any applications built on 8.4-BETA1 will need to be rebuilt when upgrading from -BETA1 to -RC1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.2-RELEASE or 8.3-RELEASE can upgrade as follows: # freebsd-update upgrade -r 8.4-BETA1 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Checksums: SHA256 (FreeBSD-8.4-BETA1-amd64-bootonly.iso) = bd882b0043dc9e295cbf4a9fead0c01b6def4119944c54a3a1980ccfc3040296 SHA256 (FreeBSD-8.4-BETA1-amd64-disc1.iso) = 4972ed9b73828f409f608aa543e3e90c9676912fd29154c59c0711600d2841c7 SHA256 (FreeBSD-8.4-BETA1-amd64-disc2.iso) = 8556c0bddba31037b12232d7a626ec5ab953eb02be06dfe078c6ed1099de9b58 SHA256 (FreeBSD-8.4-BETA1-amd64-disc3.iso) = 079f41ac1f2c1e4e01279280edd38586b6e191377d18dd0fe9de77bcf982d681 SHA256 (FreeBSD-8.4-BETA1-amd64-dvd1.iso) = c82120bbd3cdfdc9a5d0f98b7edd9e582f298bd1f7349f436cc2716d98105683 SHA256 (FreeBSD-8.4-BETA1-amd64-livefs.iso) = 95898a00b6346cd52363610d1cc751eec6e44482b042c7f0db3deffb340166a8 SHA256 (FreeBSD-8.4-BETA1-amd64-memstick.img) = f0cd770a4acb123c314753ed02a1390a2a0230c6bbaf831bfc185c4aa1a67abf SHA256 (FreeBSD-8.4-BETA1-i386-bootonly.iso) = d844f556590dcc9c4aaede65d420f3eb88d02e157299bec0d855c4c4d2045861 SHA256 (FreeBSD-8.4-BETA1-i386-disc1.iso) = 3ef76850fa6b38436c72b88691a07e7eef123075a897917341aa5b6cc38e637b SHA256 (FreeBSD-8.4-BETA1-i386-disc2.iso) = 4f60ecdeb63f5e2aeb6b956ec00ee4d4a02338c41717fd124d1eda97618c5f97 SHA256 (FreeBSD-8.4-BETA1-i386-disc3.iso) = 31ed088bf7a8366e0e2000fee41436438d6fbd5a903a8f2998485bea0f433d3c SHA256 (FreeBSD-8.4-BETA1-i386-dvd1.iso) = dea231361b80d4edb4610aa0299b00e8e26461f37a174c961f633f1c00b2dc8d SHA256 (FreeBSD-8.4-BETA1-i386-livefs.iso) = 5435146538e20b6564e60f2d8f7afd9031feebb0a7851a7090cfe3d10a4cc949 SHA256 (FreeBSD-8.4-BETA1-i386-memstick.img) = 86b7d66972836bac5d8e6e33dc03141510e3bcbd8b8c7ba720d095cee6aafaac SHA256 (FreeBSD-8.4-BETA1-pc98-bootonly.iso) = 82d5bc330ef70058604c844f65a66a8ce72fd1753498dcbdccf2bafb2e540cf1 SHA256 (FreeBSD-8.4-BETA1-pc98-disc1.iso) = 420a38247d23ab6ea9fbd1cfe536e82d47638636553c71a8b85974d454680596 SHA256 (FreeBSD-8.4-BETA1-pc98-livefs.iso) = 20014f12dbc80da069583f0bd96a76f94a3fbe563724d42bcb38513d595918a7 MD5 (FreeBSD-8.4-BETA1-amd64-bootonly.iso) = 972d1592765a6e571269405bd357fbc7 MD5 (FreeBSD-8.4-BETA1-amd64-disc1.iso) = 271f03ab62855e82a99ef88ed1c35c05 MD5 (FreeBSD-8.4-BETA1-amd64-disc2.iso) = af319ab9912b5ab325795852349fc635 MD5 (FreeBSD-8.4-BETA1-amd64-disc3.iso) = a4a4fa7154930f41f0edb47c6fe3bf31 MD5 (FreeBSD-8.4-BETA1-amd64-dvd1.iso) = 3d0aa25fe18444bde893df194e9035ca MD5 (FreeBSD-8.4-BETA1-amd64-livefs.iso) = 075a68343b21d926aee3367df8049e2e MD5 (FreeBSD-8.4-BETA1-amd64-memstick.img) = fa20dd8a5f7dd1fbe646b5632e7f9165 MD5 (FreeBSD-8.4-BETA1-i386-bootonly.iso) = 4d202d8c48699231646bb3161f44df31 MD5 (FreeBSD-8.4-BETA1-i386-disc1.iso) = da6e3cb73aa58bebc59f3fde4ce1035d MD5 (FreeBSD-8.4-BETA1-i386-disc2.iso) = 6d99c734c2f95cf3e889e7474f89767a MD5 (FreeBSD-8.4-BETA1-i386-disc3.iso) = db588f061f061c43e1498b234248aa5b MD5 (FreeBSD-8.4-BETA1-i386-dvd1.iso) = 75dc69c0c091e88f305638bfb16a68c2 MD5 (FreeBSD-8.4-BETA1-i386-livefs.iso) = bd0271d211a7b4b9d817ec2406ad3c07 MD5 (FreeBSD-8.4-BETA1-i386-memstick.img) = c437cfb4737b33ae654cbf966cc1391e MD5 (FreeBSD-8.4-BETA1-pc98-bootonly.iso) = 5e02331c1d02de5bb2bc238747899e1d MD5 (FreeBSD-8.4-BETA1-pc98-disc1.iso) = ad5f5b85854accfa89c98df7a3d3d727 MD5 (FreeBSD-8.4-BETA1-pc98-livefs.iso) = 27a7db98745ff99ae4b9ab3b0b436e21 Glen --ep0oHQY+/Gbo/zt0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJRTPSsAAoJEFJPDDeguUajEFkH/08isZQY48QWqi+yky2hm1hz a7V3cAUbYtlp64IFXw3uCRyceBUZ1RSEBe0DTbegPVPwFxqjiRelC29QVEq2DNhY I4zbWLL09L5fCeeA/zQFoSFU5LBhi5YgV5X/V3ZpNjh34s7z3AE3pNj1SCg5NeBJ 0mVf7Q1+huqIkfuPQc3RnrRCrV65a5rKzOKpTSJ6WDgXL3kWH9xDvpuoj8T6EbNm cdnzksDzVtm6XFfI+IUdfKWtdwzFJKjQjLRw9lJh8b5L2yaLnqjd3Az5RdDYe9Pq VfHe6AqDwJ1UoDEkDBwelkzdcpZ2LV1givGTB/8BSFrWfy27puT3fOmIplG6QLE= =E6Tw -----END PGP SIGNATURE----- --ep0oHQY+/Gbo/zt0-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 02:13:56 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75D16BC5; Sat, 23 Mar 2013 02:13:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 32F2493E; Sat, 23 Mar 2013 02:13:56 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N2Dt2P018288; Sat, 23 Mar 2013 02:13:55 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N2DsYc018258; Sat, 23 Mar 2013 02:13:54 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 02:13:54 GMT Message-Id: <201303230213.r2N2DsYc018258@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:13:56 -0000 TB --- 2013-03-22 23:35:45 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-22 23:35:45 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-22 23:35:45 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-03-22 23:35:45 - cleaning the object tree TB --- 2013-03-22 23:35:45 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-22 23:35:45 - cd /tinderbox/RELENG_9/i386/i386 TB --- 2013-03-22 23:35:45 - /usr/local/bin/svn cleanup /src TB --- 2013-03-22 23:36:57 - /usr/local/bin/svn update /src TB --- 2013-03-22 23:37:07 - building world TB --- 2013-03-22 23:37:07 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 23:37:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 23:37:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 23:37:07 - SRCCONF=/dev/null TB --- 2013-03-22 23:37:07 - TARGET=i386 TB --- 2013-03-22 23:37:07 - TARGET_ARCH=i386 TB --- 2013-03-22 23:37:07 - TZ=UTC TB --- 2013-03-22 23:37:07 - __MAKE_CONF=/dev/null TB --- 2013-03-22 23:37:07 - cd /src TB --- 2013-03-22 23:37:07 - /usr/bin/make -B buildworld >>> World build started on Fri Mar 22 23:37:08 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/i386.i386/src/tmp/usr/lib/libc.a /obj/i386.i386/src/tmp/usr/lib/libedit.a /obj/i386.i386/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/i386.i386/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 02:13:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 02:13:54 - ERROR: failed to build world TB --- 2013-03-23 02:13:54 - 7046.28 user 752.30 system 9489.05 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 02:19:20 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 08171EB1; Sat, 23 Mar 2013 02:19:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id BBF71979; Sat, 23 Mar 2013 02:19:19 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N2JJnn055687; Sat, 23 Mar 2013 02:19:19 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N2JJAk055686; Sat, 23 Mar 2013 02:19:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 02:19:19 GMT Message-Id: <201303230219.r2N2JJAk055686@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on i386/pc98 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:19:20 -0000 TB --- 2013-03-22 23:41:05 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-22 23:41:05 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-22 23:41:05 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2013-03-22 23:41:05 - cleaning the object tree TB --- 2013-03-22 23:41:05 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-22 23:41:05 - cd /tinderbox/RELENG_9/i386/pc98 TB --- 2013-03-22 23:41:05 - /usr/local/bin/svn cleanup /src TB --- 2013-03-22 23:42:15 - /usr/local/bin/svn update /src TB --- 2013-03-22 23:42:24 - building world TB --- 2013-03-22 23:42:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-22 23:42:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-22 23:42:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-22 23:42:24 - SRCCONF=/dev/null TB --- 2013-03-22 23:42:24 - TARGET=pc98 TB --- 2013-03-22 23:42:24 - TARGET_ARCH=i386 TB --- 2013-03-22 23:42:24 - TZ=UTC TB --- 2013-03-22 23:42:24 - __MAKE_CONF=/dev/null TB --- 2013-03-22 23:42:24 - cd /src TB --- 2013-03-22 23:42:24 - /usr/bin/make -B buildworld >>> World build started on Fri Mar 22 23:42:24 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/pc98.i386/src/tmp/usr/lib/libc.a /obj/pc98.i386/src/tmp/usr/lib/libedit.a /obj/pc98.i386/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/pc98.i386/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 02:19:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 02:19:19 - ERROR: failed to build world TB --- 2013-03-23 02:19:19 - 7040.80 user 770.49 system 9494.11 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 02:19:58 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC12EB6; Sat, 23 Mar 2013 02:19:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B310C98F; Sat, 23 Mar 2013 02:19:58 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N2JwcY057195; Sat, 23 Mar 2013 02:19:58 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N2JwAg057191; Sat, 23 Mar 2013 02:19:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 02:19:58 GMT Message-Id: <201303230219.r2N2JwAg057191@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on ia64/ia64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 02:19:58 -0000 TB --- 2013-03-23 00:53:25 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-23 00:53:25 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-23 00:53:25 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2013-03-23 00:53:25 - cleaning the object tree TB --- 2013-03-23 00:53:25 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-23 00:53:25 - cd /tinderbox/RELENG_9/ia64/ia64 TB --- 2013-03-23 00:53:25 - /usr/local/bin/svn cleanup /src TB --- 2013-03-23 00:54:24 - /usr/local/bin/svn update /src TB --- 2013-03-23 00:54:33 - building world TB --- 2013-03-23 00:54:33 - CROSS_BUILD_TESTING=YES TB --- 2013-03-23 00:54:33 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-23 00:54:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-23 00:54:33 - SRCCONF=/dev/null TB --- 2013-03-23 00:54:33 - TARGET=ia64 TB --- 2013-03-23 00:54:33 - TARGET_ARCH=ia64 TB --- 2013-03-23 00:54:33 - TZ=UTC TB --- 2013-03-23 00:54:33 - __MAKE_CONF=/dev/null TB --- 2013-03-23 00:54:33 - cd /src TB --- 2013-03-23 00:54:33 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 23 00:54:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/ia64.ia64/src/tmp/usr/lib/libc.a /obj/ia64.ia64/src/tmp/usr/lib/libedit.a /obj/ia64.ia64/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/ia64.ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 02:19:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 02:19:58 - ERROR: failed to build world TB --- 2013-03-23 02:19:58 - 3506.00 user 512.44 system 5192.67 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 03:14:26 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03294198; Sat, 23 Mar 2013 03:14:26 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B5A40BFF; Sat, 23 Mar 2013 03:14:25 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N3EPbD098315; Sat, 23 Mar 2013 03:14:25 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N3EPB0098296; Sat, 23 Mar 2013 03:14:25 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 03:14:25 GMT Message-Id: <201303230314.r2N3EPB0098296@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on mips/mips Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 03:14:26 -0000 TB --- 2013-03-23 02:13:55 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-23 02:13:55 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-23 02:13:55 - starting RELENG_9 tinderbox run for mips/mips TB --- 2013-03-23 02:13:55 - cleaning the object tree TB --- 2013-03-23 02:13:55 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-23 02:13:55 - cd /tinderbox/RELENG_9/mips/mips TB --- 2013-03-23 02:13:55 - /usr/local/bin/svn cleanup /src TB --- 2013-03-23 02:14:48 - /usr/local/bin/svn update /src TB --- 2013-03-23 02:14:58 - building world TB --- 2013-03-23 02:14:58 - CROSS_BUILD_TESTING=YES TB --- 2013-03-23 02:14:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-23 02:14:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-23 02:14:58 - SRCCONF=/dev/null TB --- 2013-03-23 02:14:58 - TARGET=mips TB --- 2013-03-23 02:14:58 - TARGET_ARCH=mips TB --- 2013-03-23 02:14:58 - TZ=UTC TB --- 2013-03-23 02:14:58 - __MAKE_CONF=/dev/null TB --- 2013-03-23 02:14:58 - cd /src TB --- 2013-03-23 02:14:58 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 23 02:14:59 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/mips.mipsel/src/tmp/usr/lib/libc.a /obj/mips.mipsel/src/tmp/usr/lib/libedit.a /obj/mips.mipsel/src/tmp/usr/lib/libtermcap.a >> .depend cc -O -pipe -G0 -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O -pipe -G0 -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/mips.mipsel/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 03:14:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 03:14:24 - ERROR: failed to build world TB --- 2013-03-23 03:14:24 - 2239.18 user 443.64 system 3629.62 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 04:30:05 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0EB3DCE; Sat, 23 Mar 2013 04:30:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id C3972F8D; Sat, 23 Mar 2013 04:30:04 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N4U4Tl099319; Sat, 23 Mar 2013 04:30:04 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N4U4Jj099317; Sat, 23 Mar 2013 04:30:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 04:30:04 GMT Message-Id: <201303230430.r2N4U4Jj099317@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on sparc64/sparc64 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 04:30:05 -0000 TB --- 2013-03-23 03:14:25 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-23 03:14:25 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-23 03:14:25 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2013-03-23 03:14:25 - cleaning the object tree TB --- 2013-03-23 03:14:25 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-23 03:14:25 - cd /tinderbox/RELENG_9/sparc64/sparc64 TB --- 2013-03-23 03:14:25 - /usr/local/bin/svn cleanup /src TB --- 2013-03-23 03:15:13 - /usr/local/bin/svn update /src TB --- 2013-03-23 03:15:23 - building world TB --- 2013-03-23 03:15:23 - CROSS_BUILD_TESTING=YES TB --- 2013-03-23 03:15:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-23 03:15:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-23 03:15:23 - SRCCONF=/dev/null TB --- 2013-03-23 03:15:23 - TARGET=sparc64 TB --- 2013-03-23 03:15:23 - TARGET_ARCH=sparc64 TB --- 2013-03-23 03:15:23 - TZ=UTC TB --- 2013-03-23 03:15:23 - __MAKE_CONF=/dev/null TB --- 2013-03-23 03:15:23 - cd /src TB --- 2013-03-23 03:15:23 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 23 03:15:24 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/sparc64.sparc64/src/tmp/usr/lib/libc.a /obj/sparc64.sparc64/src/tmp/usr/lib/libedit.a /obj/sparc64.sparc64/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/sparc64.sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 04:30:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 04:30:04 - ERROR: failed to build world TB --- 2013-03-23 04:30:04 - 2845.38 user 455.20 system 4538.45 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 04:57:07 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A594E36B; Sat, 23 Mar 2013 04:57:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 666FA88; Sat, 23 Mar 2013 04:57:07 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N4v66m015624; Sat, 23 Mar 2013 04:57:06 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N4v6R1015623; Sat, 23 Mar 2013 04:57:06 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 04:57:06 GMT Message-Id: <201303230457.r2N4v6R1015623@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 04:57:07 -0000 TB --- 2013-03-23 02:19:19 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-23 02:19:19 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-23 02:19:19 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2013-03-23 02:19:19 - cleaning the object tree TB --- 2013-03-23 02:19:19 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-23 02:19:19 - cd /tinderbox/RELENG_9/powerpc/powerpc TB --- 2013-03-23 02:19:19 - /usr/local/bin/svn cleanup /src TB --- 2013-03-23 02:20:08 - /usr/local/bin/svn update /src TB --- 2013-03-23 02:20:19 - building world TB --- 2013-03-23 02:20:19 - CROSS_BUILD_TESTING=YES TB --- 2013-03-23 02:20:19 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-23 02:20:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-23 02:20:19 - SRCCONF=/dev/null TB --- 2013-03-23 02:20:19 - TARGET=powerpc TB --- 2013-03-23 02:20:19 - TARGET_ARCH=powerpc TB --- 2013-03-23 02:20:19 - TZ=UTC TB --- 2013-03-23 02:20:19 - __MAKE_CONF=/dev/null TB --- 2013-03-23 02:20:19 - cd /src TB --- 2013-03-23 02:20:19 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 23 02:20:19 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/powerpc.powerpc/src/tmp/usr/lib/libc.a /obj/powerpc.powerpc/src/tmp/usr/lib/libedit.a /obj/powerpc.powerpc/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/powerpc.powerpc/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 04:57:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 04:57:06 - ERROR: failed to build world TB --- 2013-03-23 04:57:06 - 7037.53 user 729.21 system 9467.40 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 04:59:14 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 69712493; Sat, 23 Mar 2013 04:59:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 2A44ECF; Sat, 23 Mar 2013 04:59:14 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id r2N4xDOR027801; Sat, 23 Mar 2013 04:59:13 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r2N4xDrl027799; Sat, 23 Mar 2013 04:59:13 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 23 Mar 2013 04:59:13 GMT Message-Id: <201303230459.r2N4xDrl027799@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [releng_9 tinderbox] failure on powerpc64/powerpc Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 04:59:14 -0000 TB --- 2013-03-23 02:19:58 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-03-23 02:19:58 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-03-23 02:19:58 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2013-03-23 02:19:58 - cleaning the object tree TB --- 2013-03-23 02:19:58 - checking out /src from svn://svn.freebsd.org/base/stable/9 TB --- 2013-03-23 02:19:58 - cd /tinderbox/RELENG_9/powerpc64/powerpc TB --- 2013-03-23 02:19:58 - /usr/local/bin/svn cleanup /src TB --- 2013-03-23 02:21:07 - /usr/local/bin/svn update /src TB --- 2013-03-23 02:21:17 - building world TB --- 2013-03-23 02:21:17 - CROSS_BUILD_TESTING=YES TB --- 2013-03-23 02:21:17 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-23 02:21:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-23 02:21:17 - SRCCONF=/dev/null TB --- 2013-03-23 02:21:17 - TARGET=powerpc TB --- 2013-03-23 02:21:17 - TARGET_ARCH=powerpc64 TB --- 2013-03-23 02:21:17 - TZ=UTC TB --- 2013-03-23 02:21:17 - __MAKE_CONF=/dev/null TB --- 2013-03-23 02:21:17 - cd /src TB --- 2013-03-23 02:21:17 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 23 02:21:17 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 /src/sbin/fsdb/fsdb.c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/../fsck_ffs/dir.c /src/sbin/fsdb/../fsck_ffs/ea.c /src/sbin/fsdb/../fsck_ffs/fsutil.c /src/sbin/fsdb/../fsck_ffs/inode.c /src/sbin/fsdb/../fsck_ffs/pass1.c /src/sbin/fsdb/../fsck_ffs/pass1b.c /src/sbin/fsdb/../fsck_ffs/pass2.c /src/sbin/fsdb/../fsck_ffs/pass3.c /src/sbin/fsdb/../fsck_ffs/pass4.c /src/sbin/fsdb/../fsck_ffs/pass5.c /src/sbin/fsdb/../fsck_ffs/setup.c /src/sbin/fsdb/../fsck_ffs/utilities.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_subr.c /src/sbin/fsdb/../../sys/ufs/ffs/ffs_tables.c echo fsdb: /obj/powerpc.powerpc64/src/tmp/usr/lib/libc.a /obj/powerpc.powerpc64/src/tmp/usr/lib/libedit.a /obj/powerpc.powerpc64/src/tmp/usr/lib/libtermcap.a >> .depend cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdb.c cc -O2 -pipe -I/src/sbin/fsdb/../fsck_ffs -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsdb/fsdbutil.c /src/sbin/fsdb/fsdbutil.c: In function 'printindir': /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_prev' /src/sbin/fsdb/fsdbutil.c:244: error: 'struct bufarea' has no member named 'b_next' *** Error code 1 Stop in /src/sbin/fsdb. *** Error code 1 Stop in /obj/powerpc.powerpc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-23 04:59:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-23 04:59:13 - ERROR: failed to build world TB --- 2013-03-23 04:59:13 - 7089.98 user 737.49 system 9555.29 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 19:06:06 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 87C2A3AE3 for ; Sat, 23 Mar 2013 19:06:06 +0000 (UTC) (envelope-from eng.todor.todorov@gmail.com) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id 9325AD3C for ; Sat, 23 Mar 2013 19:06:05 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id w5so2328981bku.13 for ; Sat, 23 Mar 2013 12:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=lq5Ey84iSS+XtejjwFm7d+rVEsSebOTbUpiSdOFfC3Q=; b=yhOfbs6J//Jr4gyCUhrCWIgGH7LIsLOMJNBg/eGmb3JkLF7NeoRckHiq3IWTvH6do8 CGNMTrrVmziFDwvlUvLGtUgEkmc+F/q/osbubuvOdp7kHD6Yo+/ChBkIZovwBL4lzptw xkH7aF3f7HZVSjdHMrmregFF5fMBOYTqeduVSoSNKP4nuKjWUEbHtJYPgDJBw3P7ckYa 19zWw3VsrUcAjL7ifyAQeaxgIHvae90KV5hNNdSpzHz6XkxZM1HCSZfLaT3a0eBJcQ/A v/qemQmmao9Vosq5pxFkgXCGWheAopb7tWyQD1sBguiTXxyk3kHrFgMug2zrmSSxLl4A 4DoQ== X-Received: by 10.204.165.140 with SMTP id i12mr1060543bky.128.1364065563982; Sat, 23 Mar 2013 12:06:03 -0700 (PDT) Received: from [192.168.10.13] ([77.70.57.248]) by mx.google.com with ESMTPS id o2sm1613674bkv.3.2013.03.23.12.06.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 12:06:01 -0700 (PDT) Message-ID: <514DFD17.4070500@paladin.bulgarpress.com> Date: Sat, 23 Mar 2013 21:05:59 +0200 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: stable@freebsd.org Subject: Missing partition slices after upgrade 7.4 to 8.3 Content-Type: multipart/mixed; boundary="------------060405040500010000040408" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 19:06:06 -0000 This is a multi-part message in MIME format. --------------060405040500010000040408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, after upgrade from 7.4 to 8.3 I have encounter the following problem on two machines. Symptoms are as follows: 1. when I have one slice per disk it is not recognized (usually data on hardware RAID) 2. I've used BSDLABEL, not gpart in the past 3. if I have gmirror - it's recognized fine (usually the OS) Tried w/ 9.1 - the same result. I've searched the inet - can't find any clue. Any ideas appreciated. Attaching few screenshots from the IPMI after the crash. Thanks --------------060405040500010000040408-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 20:02:31 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EA9921C for ; Sat, 23 Mar 2013 20:02:31 +0000 (UTC) (envelope-from eng.todor.todorov@gmail.com) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by mx1.freebsd.org (Postfix) with ESMTP id B1370265 for ; Sat, 23 Mar 2013 20:02:30 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c50so2658277eek.30 for ; Sat, 23 Mar 2013 13:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=/mYt/Ag2HDWpQvw8dkXIg/gPCeCJzkvawsJvcC7laXk=; b=PvZrN1bb1GSmWwiLA60H4kTcIsdMc1MzZQGI2nsfIjFfEeUJ3y3HWDmL7G8EsKg7b5 VsOEOIKuGSGESPcvA3h5JSs+Rt9hhW10RQY/v1hsjjx1NZ/Z/Md5aC1IkpsoP3VikOJ1 Vba8YBVWtvbLCdKBO09I/xafCC+uQZWkVl2e5RTyf6tDB76FXCZyncbvAu0WfYPqzypt PsEZNLwULJDHpHPI4Pwhw8mMyrKYugAFraflmRqLgPIGShhCQZX4qozNikMZcXs8FYEf sM7F9Dm2RWm/5pVSzNyp0TNrT4r3FgbjiwCQT+1sAhWdZpJyDwSv128aIp/l1/KArJrc dFwg== X-Received: by 10.14.207.200 with SMTP id n48mr17380750eeo.4.1364068943835; Sat, 23 Mar 2013 13:02:23 -0700 (PDT) Received: from [192.168.10.13] ([77.70.57.248]) by mx.google.com with ESMTPS id k7sm9983645een.8.2013.03.23.13.02.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Mar 2013 13:02:22 -0700 (PDT) Message-ID: <514E0A4C.8070105@paladin.bulgarpress.com> Date: Sat, 23 Mar 2013 22:02:20 +0200 From: Mailing lists User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: stable@freebsd.org Subject: Re: Missing partition slices after upgrade 7.4 to 8.3 References: <514DFD17.4070500@paladin.bulgarpress.com> In-Reply-To: <514DFD17.4070500@paladin.bulgarpress.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:02:31 -0000 On 03/23/2013 09:05 PM, Mailing lists wrote: > Hi all, > after upgrade from 7.4 to 8.3 I have encounter the following problem on > two machines. > > Symptoms are as follows: > > 1. when I have one slice per disk it is not recognized (usually data on > hardware RAID) > 2. I've used BSDLABEL, not gpart in the past > 3. if I have gmirror - it's recognized fine (usually the OS) > > Tried w/ 9.1 - the same result. > > I've searched the inet - can't find any clue. > > Any ideas appreciated. Attaching few screenshots from the IPMI after the > crash. > > Thanks > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I see the attachments are not seen in the thread.. - when it's 8.3 or 9.1 I see /dev/da0s1 & /dev/da1s1 I did bsdlabel /dev/da0s1 and I can see 'c' raw partition of type 4.2BSD bsdlabel: partition c is not maked as unused! bsdlabel: An incorrect partition c may cause problems for standart system utilities. - when it's 7.4 I see /dev/da0s1c && /dev/da1s1c Thanks in advance! :) From owner-freebsd-stable@FreeBSD.ORG Sat Mar 23 20:20:32 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 370947B6 for ; Sat, 23 Mar 2013 20:20:32 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 2428C400 for ; Sat, 23 Mar 2013 20:20:32 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 9C8482AA471; Sat, 23 Mar 2013 14:20:29 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 32ABA1CCDF; Sat, 23 Mar 2013 15:19:26 -0500 (EST) Date: Sat, 23 Mar 2013 15:19:26 -0500 From: Diane Bruce To: Mailing lists Subject: Re: Missing partition slices after upgrade 7.4 to 8.3 Message-ID: <20130323201926.GA61963@night.db.net> References: <514DFD17.4070500@paladin.bulgarpress.com> <514E0A4C.8070105@paladin.bulgarpress.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514E0A4C.8070105@paladin.bulgarpress.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 20:20:32 -0000 On Sat, Mar 23, 2013 at 10:02:20PM +0200, Mailing lists wrote: > On 03/23/2013 09:05 PM, Mailing lists wrote: > > Hi all, > > after upgrade from 7.4 to 8.3 I have encounter the following problem on > > two machines. ... > > - when it's 8.3 or 9.1 I see /dev/da0s1 & /dev/da1s1 > I did bsdlabel /dev/da0s1 and I can see 'c' raw partition of type 4.2BSD > > bsdlabel: partition c is not maked as unused! > bsdlabel: An incorrect partition c may cause problems for standart > system utilities. > > - when it's 7.4 I see /dev/da0s1c && /dev/da1s1c > > Thanks in advance! :) http://www.freebsddiary.org/upgrade8.php c partition went away in 8 - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db