From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 14 00:41:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BCAD106564A for ; Sun, 14 Aug 2011 00:41:49 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44DC28FC18 for ; Sun, 14 Aug 2011 00:41:49 +0000 (UTC) Received: by qwc9 with SMTP id 9so2700659qwc.13 for ; Sat, 13 Aug 2011 17:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uhwWosuAxrXnUm1qi1oVnxbv02bfAXLJCjWxFg02i0I=; b=DKnAjxg8vKixxURPvmClhUV5L81V+GWEp1luLOyedyxHdyO/bycmgJrqqFXj0+3EJ8 V79d4oEG/9FgdOimtJyxuNHm0kW1H9cK46nZBiRtcE5NYJxNE93rbvHJGDCT3QId5zdL Cfh9LmyxUhDoCgK6zT9brGDt+qScqffqq+1iE= MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr1552676qci.254.1313282508593; Sat, 13 Aug 2011 17:41:48 -0700 (PDT) Received: by 10.229.53.212 with HTTP; Sat, 13 Aug 2011 17:41:48 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Aug 2011 08:41:48 +0800 Message-ID: From: ambrosehuang ambrose To: Shrikanth Kamath Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace unable to dump typedef'ed argument X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 00:41:49 -0000 same problem on 8.2-stable 2011/8/10 Shrikanth Kamath > I found this on a FreeBSD 8.1 box... > > %dtrace -l -f rtalloc_fib -v > > ... > Argument Types > args[0]: struct route * > args[1]: (unknown) > > The function defined in sys/net/route.c: void rtalloc_fib(struct route > *ro, u_int fibnum) > u_int is typedef unsigned int > > I checked the ctfdump for /boot/kernel/kernel and found u_int is a > resolved type. > > [14077] FUNC (rtalloc_fib) returns: 29 args: (1335, 5) > > Checking the CTF table "5" is found to be a resolved typedef. > > <4> INTEGER unsigned int encoding=0x0 offset=0 bits=32 > <5> TYPEDEF u_int refers to 4 > > But since it shows unknown with dtrace -l -f o/p, one cannot directly > use args[1]. > > Is this a known problem, any fix or workaround? > > > -- > Shrikanth R K > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 14 15:39:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 796E31065673 for ; Sun, 14 Aug 2011 15:39:15 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 471748FC1A for ; Sun, 14 Aug 2011 15:39:14 +0000 (UTC) Received: by iye7 with SMTP id 7so11633172iye.17 for ; Sun, 14 Aug 2011 08:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=X4xKNxRLiJMGU8Br+SUilgP/U9l2kHWLirtpK0WWxSk=; b=Ml38enFG5V1HKiI2vDTiroSUGQ+YDXF+4WXLyjp5hLaWnkZ1iBd6PDO1+hCjVgcMfe 3nwAxpoIGSe87F3OH2JCwxjv32tqigMZ0l/+2VZshEiGle5xA07onKevOj5H88aHl2PY ufkqbnx8R6ZMQcbdgAgIxNsFAn+qbqsoPTlrA= MIME-Version: 1.0 Received: by 10.42.148.133 with SMTP id r5mr3044164icv.220.1313336354583; Sun, 14 Aug 2011 08:39:14 -0700 (PDT) Received: by 10.231.30.73 with HTTP; Sun, 14 Aug 2011 08:39:14 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Aug 2011 10:39:14 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 15:39:15 -0000 Hi, hackers: My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for testing. The proposal of the project is here: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 The project creates a multibyte fork of the BSD-licensed nvi editor. It adds only 1 dependence, libiconv, =C2=A0to nvi-1.79, which presents in our base system currently. And the libiconv is included in -current's libc. The patch and the instruction of using the patch is at https://github.com/lichray/nvi2/wiki . Note that your -current box needs to be built WITH_ICONV=3D1 to include libiconv in libc. And such a knob enables iconv support in the new nvi at the same time. The patch will create contrib/nvi2, and it will not remove the unused contrib/nvi (patch(1) can not really remove files anyway). So for the next week, the feature set of the new nvi is frozen. I'll just wait for your testing reports and fix possible bugs. Thank you for giving me the opportunity to participate in GSoC. -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 14 19:57:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4D0731065670; Sun, 14 Aug 2011 19:57:26 +0000 (UTC) Date: Sun, 14 Aug 2011 19:57:26 +0000 From: Alexander Best To: Edward Tomasz Napiera?a Message-ID: <20110814195726.GA25655@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> <20110724222224.GA64487@freebsd.org> <20110724230617.GA69612@freebsd.org> <8D7CEA8F-AF55-4509-9C90-74FC42A9A020@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D7CEA8F-AF55-4509-9C90-74FC42A9A020@freebsd.org> Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 19:57:26 -0000 On Tue Jul 26 11, Edward Tomasz Napiera?a wrote: > Wiadomo?? napisana przez Alexander Best w dniu 25 lip 2011, o godz. 01:06: > > On Sun Jul 24 11, Alexander Best wrote: > >> On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: > >>> Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: > >>>> Edward Tomasz Napiera?a writes: > >>>> > >>>>> Patch below changes ps(1) to automatically size column widths according to their > >>>>> contents. From the user point of view, it prevents breaking layout with too wide values > >>>>> and in most cases makes output narrower. From the developer point of view, it removes > >>>>> the need to specify widths. Testing is welcome - the patch shouldn't change ps(1) > >>>>> behaviour except slightly changing the widths, but the code changes are pretty large > >>>>> and it's quite possible I've missed something. > >>>> > >>>> STAT column seems to be right-aligned when it was previously left-aligned. > >>>> This makes sorting it harder, e.g. > >>>> > >>>> $ ps ax | (IFS=; read h; echo $h; sort -k3) | less > >>> > >>> Good catch, thanks! Updated patch, which also fixes two issues affecting TTY column, > >>> is at http://people.freebsd.org/~trasz/ps-9.diff. > > > > any reason there are always a minimum of 2 spaces between the "TT" and the > > "TIME" column and not a single space? > > The 'TT' column ends with either a space, or a '-'. As you've noticed, in the common > case there will be no hyphens there; I'll see if I can remove the extra spacing. hmmm...i've never seen a "-" in the TT column to be honest. any chance your patch will get committed before 9.0? i really like it. :) > > -- > If you cut off my head, what would I say? Me and my head, or me and my body? From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 14 20:00:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 506681065673; Sun, 14 Aug 2011 20:00:39 +0000 (UTC) Date: Sun, 14 Aug 2011 20:00:39 +0000 From: Alexander Best To: Edward Tomasz Napiera?a Message-ID: <20110814200039.GB25655@freebsd.org> References: <0CEA161B-6767-4379-B923-585B3D4EA74E@freebsd.org> <86hb6e1bau.fsf@gmail.com> <589EB85A-1902-4643-A1FD-3C98445127DB@freebsd.org> <20110724222224.GA64487@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Test Rat , freebsd-hackers@freebsd.org Subject: Re: Autosizing column widths in ps(1). X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 20:00:39 -0000 On Wed Jul 27 11, Edward Tomasz Napiera?a wrote: > Wiadomo?? napisana przez Alexander Best w dniu 25 lip 2011, o godz. 00:22: > > On Sun Jul 24 11, Edward Tomasz Napiera?a wrote: > >> Wiadomo?? napisana przez Test Rat w dniu 22 lip 2011, o godz. 19:21: > >>> Edward Tomasz Napiera?a writes: > >>> > >>>> Patch below changes ps(1) to automatically size column widths according to their > >>>> contents. From the user point of view, it prevents breaking layout with too wide values > >>>> and in most cases makes output narrower. From the developer point of view, it removes > >>>> the need to specify widths. Testing is welcome - the patch shouldn't change ps(1) > >>>> behaviour except slightly changing the widths, but the code changes are pretty large > >>>> and it's quite possible I've missed something. > >>> > >>> STAT column seems to be right-aligned when it was previously left-aligned. > >>> This makes sorting it harder, e.g. > >>> > >>> $ ps ax | (IFS=; read h; echo $h; sort -k3) | less > >> > >> Good catch, thanks! Updated patch, which also fixes two issues affecting TTY column, > >> is at http://people.freebsd.org/~trasz/ps-9.diff. > > > > working great here. have you experienced any performance issues, due to ps > > having to iterate through all columns before constructing the output in > > comparison to the previous design? > > It had to iterate through them before; what has changed is that now it stores the strings > before printing them out. This means increased memory usage - if you have thousands > of processes, the new ps(1) will use tens of kilobytes of memory. Hardly > a showstopper, imho. > > > P.S.: one utility which would also benefit from auto column sizing is top, for > > sure! ;) > > The problem with top(1) is that you don't want your column widths to change > at every refresh. This is somewhat similar to the situation with vmstat(8). good point. however i guess for vmstat (and company), auto column sizing could be used when repetions haven't been requested (i.e. vmstat [-c1]). > > -- > If you cut off my head, what would I say? Me and my head, or me and my body? From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 14 20:06:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BB0B1065674 for ; Sun, 14 Aug 2011 20:06:02 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 65BA28FC08 for ; Sun, 14 Aug 2011 20:06:02 +0000 (UTC) Received: by iye7 with SMTP id 7so12112428iye.17 for ; Sun, 14 Aug 2011 13:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Wu5UrrR6C2zEDfNIJpvRFGk9nkqT613CUp7DV+MssfY=; b=G5JyRs815DzqUViCM6U1sW2CpoaC0CQvXvnyqqFAKma/9FBOBcENr2tf2gZ6xc1/O0 ecZT5I8AIrOa45iVkyiVJP/U2Eav8RZMRfXK7AJQtpnDOUoqe9jscbowjafjvrhTwbms nKBYodvcbCkrYExuGH5ieYkFZxehthGfv06v8= MIME-Version: 1.0 Received: by 10.42.150.196 with SMTP id b4mr3732989icw.153.1313352360693; Sun, 14 Aug 2011 13:06:00 -0700 (PDT) Received: by 10.231.30.73 with HTTP; Sun, 14 Aug 2011 13:06:00 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Aug 2011 15:06:00 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=90e6ba613ad6ec8f9404aa7cac91 Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2011 20:06:02 -0000 --90e6ba613ad6ec8f9404aa7cac91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Aug 14, 2011 at 10:39 AM, Zhihao Yuan wrote: > Hi, hackers: > > My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for > testing. The proposal of the project is here: > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 > > The project creates a multibyte fork of the BSD-licensed nvi editor. > It adds only 1 dependence, libiconv, =C2=A0to nvi-1.79, which presents in > our base system currently. And the libiconv is included in -current's > libc. > > The patch and the instruction of using the patch is at > https://github.com/lichray/nvi2/wiki . Note that your -current box > needs to be built WITH_ICONV=3D1 to include libiconv in libc. And such a > knob enables iconv support in the new nvi at the same time. > > The patch will create contrib/nvi2, and it will not remove the unused > contrib/nvi (patch(1) can not really remove files anyway). > > So for the next week, the feature set of the new nvi is frozen. I'll > just wait for your testing reports and fix possible bugs. Thank you > for giving me the opportunity to participate in GSoC. > > -- > Zhihao Yuan, nickname lichray > The best way to predict the future is to invent it. > ___________________________________________________ > 4BSD -- http://4bsd.biz/ > Let me try to ``quickly'' explain how to involve into the testing. First, download the patch from https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-14.diff.gz If you want to test the new nvi with the libiconv in libc, you need a -current src tree and a -current base system built WITH_ICONV=3D1. If you want to test it with the libiconv in ports (evil, testing only), you need either a -current or -stable src tree, and the port converters/libiconv installed under /usr/local. You also need to apply the additional patch included in the attachment *after* you applied the nvi2-freebsd patch to your src tree. After the src tree is patched, cd to usr.bin/vi under the src tree, make WITH_ICONV=3D1 Now you can run the new nvi with ./nvi . If you want to replace the system vi with this one, make WITH_ICONV=3D1 install *NOTE* FreeBSD's libncursesw only recognizes a subset of the locales which are supported by libc. Which means, not all libc locales work. For example, LC_CTYPE=3Dzh_CN.GBK won't work; use zh_CN.eucCN instead. Fortunately, UTF-8 locales work, whenever your X terminal enumerator supports it. --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ --90e6ba613ad6ec8f9404aa7cac91 Content-Type: application/octet-stream; name="nvi2-stable-Makefile.patch" Content-Disposition: attachment; filename="nvi2-stable-Makefile.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_grcfjpud0 SW5kZXg6IE1ha2VmaWxlCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIE1ha2VmaWxlCShyZXZpc2lvbiAyMjUxMTEp CisrKyBNYWtlZmlsZQkod29ya2luZyBjb3B5KQpAQCAtNDEsMTEgKzQxLDExIEBACiAuUEFUSDoJ JHtTUkNESVJ9L2NsCiAuUEFUSDoJJHtTUkNESVJ9L3ZpCiAKLUNGTEFHUys9LUkkey5DVVJESVJ9 IC1JJHtTUkNESVJ9IC1JJHtTUkNESVJ9L2luY2x1ZGUKK0NGTEFHUys9LUkkey5DVVJESVJ9IC1J JHtTUkNESVJ9IC1JJHtTUkNESVJ9L2luY2x1ZGUgLUkvdXNyL2xvY2FsL2luY2x1ZGUKIAogLmlm ZGVmIChXSVRIX0lDT05WKQogRFBBREQ9CQkke0xJQk5DVVJTRVNXfQotTERBREQ9CQktbG5jdXJz ZXN3CitMREFERD0JCS1sbmN1cnNlc3cgLWxpY29udiAtTC91c3IvbG9jYWwvbGliCiAuZWxzZQog RFBBREQ9CQkke0xJQk5DVVJTRVN9CiBMREFERD0JCS1sbmN1cnNlcwo= --90e6ba613ad6ec8f9404aa7cac91-- From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 00:59:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49DBB106564A for ; Mon, 15 Aug 2011 00:59:06 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0E68FC17 for ; Mon, 15 Aug 2011 00:59:05 +0000 (UTC) Received: by qwc9 with SMTP id 9so3002390qwc.13 for ; Sun, 14 Aug 2011 17:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3H4FQyz0tJq/30Yzs1E1NFz+ElVaFHUjD0aMBNB4+I0=; b=UQYwkRuu960LeK3BVRNgSJJUET3oL5YaYY/AVMXGtk4B9Zb1Xo0HRkc3ThWX8IORHp UNJmDkNyetURaIuIxhiZqDdEkhWK4sdwF1i4ACTcg/PF27RCaq+t5ppWTiS4J4ib1+j/ tBcal2owt2Sho307mpS+waYqdelk70f4fNMLA= MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr861672qcc.292.1313369945179; Sun, 14 Aug 2011 17:59:05 -0700 (PDT) Received: by 10.229.53.212 with HTTP; Sun, 14 Aug 2011 17:59:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 08:59:05 +0800 Message-ID: From: ambrosehuang ambrose To: Shrikanth Kamath Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace unable to dump typedef'ed argument X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 00:59:06 -0000 it has been fixed by kern/159064: [dtrace] MFC request for dtrace to fix "invalid probe specifier" 2011/8/14 ambrosehuang ambrose > same problem on 8.2-stable > > > 2011/8/10 Shrikanth Kamath > >> I found this on a FreeBSD 8.1 box... >> >> %dtrace -l -f rtalloc_fib -v >> >> ... >> Argument Types >> args[0]: struct route * >> args[1]: (unknown) >> >> The function defined in sys/net/route.c: void rtalloc_fib(struct route >> *ro, u_int fibnum) >> u_int is typedef unsigned int >> >> I checked the ctfdump for /boot/kernel/kernel and found u_int is a >> resolved type. >> >> [14077] FUNC (rtalloc_fib) returns: 29 args: (1335, 5) >> >> Checking the CTF table "5" is found to be a resolved typedef. >> >> <4> INTEGER unsigned int encoding=0x0 offset=0 bits=32 >> <5> TYPEDEF u_int refers to 4 >> >> But since it shows unknown with dtrace -l -f o/p, one cannot directly >> use args[1]. >> >> Is this a known problem, any fix or workaround? >> >> >> -- >> Shrikanth R K >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 12:32:53 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8293106566C for ; Mon, 15 Aug 2011 12:32:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 150378FC0C for ; Mon, 15 Aug 2011 12:32:52 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA13067; Mon, 15 Aug 2011 15:32:50 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4911F1.9030808@FreeBSD.org> Date: Mon, 15 Aug 2011 15:32:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Schaefer References: In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:32:53 -0000 on 13/08/2011 20:16 Joe Schaefer said the following: > Brand new machine with a Phenom II X6 1100T and under chronic load > the clock will stop running periodically until the machine eventually completely > freezes. Note: during these stalls the kernel is still running, the > machine is still > mostly responsive, it's just that the clock is frozen in time. > > I've disabled Turbo mode in the bios and toyed with just about every > other setting but nothing seems to resolve this problem. Based on the behavior > of the machine (just making buildworld will eventually kill it, upping > the -j flag > just kills it faster), I'm guessing it has something to do with the > Digi+ VRM features > but again nothing I've tried modifying in the bios seems to help. > > I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head now with > a dtrace enabled kernel. > > Suggestions? On head, start with checking what source is used for driving clocks: sysctl kern.eventtimer When the problem starts using vmstat -i to check interrupt rates and see if any relevant counter gets stuck. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 13:31:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3154106566B for ; Mon, 15 Aug 2011 13:31:08 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 890AE8FC12 for ; Mon, 15 Aug 2011 13:31:08 +0000 (UTC) Received: by vxh11 with SMTP id 11so5088485vxh.13 for ; Mon, 15 Aug 2011 06:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B3WnjY/IejKUe01cab/I4eWSZ6XHdIzmMs9/q7GSlIA=; b=Pd/VIqhQ8jb0TReF3OpEo3HaF45HQNWGeOjNiMOowSnAEqVZXbsFcoNX5APPfSRx5Z lDfptDKZ4Ld28Hj8XXorriRnhgXZtw1PGYg1AxcR/AG62zBxhu4/cE6/EAq8bIu1VV5B yvxBMqIiy7b92MYwoBD8KHX/nGIb2NLqS19vQ= MIME-Version: 1.0 Received: by 10.220.150.204 with SMTP id z12mr989101vcv.34.1313415067695; Mon, 15 Aug 2011 06:31:07 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 06:31:07 -0700 (PDT) In-Reply-To: <4E4911F1.9030808@FreeBSD.org> References: <4E4911F1.9030808@FreeBSD.org> Date: Mon, 15 Aug 2011 09:31:07 -0400 Message-ID: From: Joe Schaefer To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 13:31:09 -0000 On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon wrote: > on 13/08/2011 20:16 Joe Schaefer said the following: >> Brand new machine with a Phenom II X6 1100T and under chronic load >> the clock will stop running periodically until the machine eventually co= mpletely >> freezes. =C2=A0Note: during these stalls the kernel is still running, th= e >> machine is still >> mostly responsive, it's just that the clock is frozen in time. >> >> I've disabled Turbo mode in the bios and toyed with just about every >> other setting but nothing seems to resolve this problem. =C2=A0Based on = the behavior >> of the machine (just making buildworld will eventually kill it, upping >> the -j flag >> just kills it faster), I'm guessing it has something to do with the >> Digi+ VRM features >> but again nothing I've tried modifying in the bios seems to help. >> >> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running head now= with >> a dtrace enabled kernel. >> >> Suggestions? > > On head, start with checking what source is used for driving clocks: > sysctl kern.eventtimer % sysctl kern.eventtimer [master] kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 450 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 450 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 > > When the problem starts using vmstat -i to check interrupt rates and see = if any > relevant counter gets stuck. (during a buildworld run): joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 56943 1 irq19: ahci0 1004414 24 irq22: fwohci0 653499 16 irq46: atapci1 60047 1 irq256: hpet0:t0 8309347 205 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 93596 2 Total 10177889 251 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 57019 1 irq19: ahci0 1009467 24 irq22: fwohci0 653921 16 irq46: atapci1 60146 1 irq256: hpet0:t0 8381321 207 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 93694 2 Total 10255611 253 joe@sextant:~% date [mas= ter] Mon Aug 15 09:18:25 EDT 2011 joe@sextant:~% date [mas= ter] Mon Aug 15 09:18:27 EDT 2011 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 57410 1 irq19: ahci0 1019054 25 irq22: fwohci0 654275 16 irq46: atapci1 60230 1 irq256: hpet0:t0 8438249 208 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 93835 2 Total 10323096 254 joe@sextant:~% date [mas= ter] Mon Aug 15 09:19:41 EDT 2011 joe@sextant:~% date [mas= ter] Mon Aug 15 09:19:41 EDT 2011 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 57432 1 irq19: ahci0 1019054 25 irq22: fwohci0 654275 16 irq46: atapci1 60230 1 irq256: hpet0:t0 8438249 208 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 93852 2 Total 10323135 254 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 57436 1 irq19: ahci0 1019054 25 irq22: fwohci0 654275 16 irq46: atapci1 60230 1 irq256: hpet0:t0 8438249 208 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 93866 2 Total 10323153 254 joe@sextant:~% date [mas= ter] Mon Aug 15 09:19:41 EDT 2011 joe@sextant:~% date [mas= ter] Mon Aug 15 09:24:16 EDT 2011 joe@sextant:~% date [mas= ter] Mon Aug 15 09:24:16 EDT 2011 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 59317 1 irq19: ahci0 1020250 24 irq22: fwohci0 654352 16 irq46: atapci1 60248 1 irq256: hpet0:t0 8440763 206 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 94258 2 Total 10329231 252 joe@sextant:~% vmstat -i [mas= ter] interrupt total rate irq16: hdac2 39 0 irq17: ehci0 ehci1+ 2 0 irq18: ohci0 ohci1* 59330 1 irq19: ahci0 1020471 24 irq22: fwohci0 654411 16 irq46: atapci1 60263 1 irq256: hpet0:t0 8442455 206 irq259: hdac0 1 0 irq260: hdac1 1 0 irq261: re0 94325 2 Total 10331298 252 joe@sextant:~% date [mas= ter] Mon Aug 15 09:24:33 EDT 2011 From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 19:18:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6F73106566C; Mon, 15 Aug 2011 19:18:32 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 500C38FC13; Mon, 15 Aug 2011 19:18:31 +0000 (UTC) Received: by vxh11 with SMTP id 11so5456229vxh.13 for ; Mon, 15 Aug 2011 12:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PFUW2b3Af9e1CJZqUft18n5nL1804gW6KIQJt/bdZMQ=; b=ONlnjhCFPyTpw4KQZrgCbYSGaSY9rdCSYI1cOrYz0UEqli8lQDlwtOuN1XYvYNgnVA PMWf6Eo4TmSnQsLxfkx/vhT6UmaCgEvwV2nEVUKG+1SldqXnQDgh/EfZr7S9nalX4/ee NTVhZNgZ1amLx93SzTdLMg1+a+xV+YY0/Z0ws= MIME-Version: 1.0 Received: by 10.52.24.240 with SMTP id x16mr1479946vdf.298.1313435911437; Mon, 15 Aug 2011 12:18:31 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 12:18:31 -0700 (PDT) In-Reply-To: References: <4E4911F1.9030808@FreeBSD.org> Date: Mon, 15 Aug 2011 15:18:31 -0400 Message-ID: From: Joe Schaefer To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 19:18:32 -0000 On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon wrote: >> on 13/08/2011 20:16 Joe Schaefer said the following: >>> Brand new machine with a Phenom II X6 1100T and under chronic load >>> the clock will stop running periodically until the machine eventually c= ompletely >>> freezes. =C2=A0Note: during these stalls the kernel is still running, t= he >>> machine is still >>> mostly responsive, it's just that the clock is frozen in time. >>> >>> I've disabled Turbo mode in the bios and toyed with just about every >>> other setting but nothing seems to resolve this problem. =C2=A0Based on= the behavior >>> of the machine (just making buildworld will eventually kill it, upping >>> the -j flag >>> just kills it faster), I'm guessing it has something to do with the >>> Digi+ VRM features >>> but again nothing I've tried modifying in the bios seems to help. >>> >>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running head no= w with >>> a dtrace enabled kernel. >>> >>> Suggestions? >> >> On head, start with checking what source is used for driving clocks: >> sysctl kern.eventtimer > > % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[mast= er] > kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) > i8254(100) RTC(0) > kern.eventtimer.et.LAPIC.flags: 15 > kern.eventtimer.et.LAPIC.frequency: 0 > kern.eventtimer.et.LAPIC.quality: 400 > kern.eventtimer.et.HPET.flags: 3 > kern.eventtimer.et.HPET.frequency: 14318180 > kern.eventtimer.et.HPET.quality: 450 > kern.eventtimer.et.HPET1.flags: 3 > kern.eventtimer.et.HPET1.frequency: 14318180 > kern.eventtimer.et.HPET1.quality: 450 > kern.eventtimer.et.HPET2.flags: 3 > kern.eventtimer.et.HPET2.frequency: 14318180 > kern.eventtimer.et.HPET2.quality: 450 > kern.eventtimer.et.i8254.flags: 1 > kern.eventtimer.et.i8254.frequency: 1193182 > kern.eventtimer.et.i8254.quality: 100 > kern.eventtimer.et.RTC.flags: 17 > kern.eventtimer.et.RTC.frequency: 32768 > kern.eventtimer.et.RTC.quality: 0 > kern.eventtimer.periodic: 0 > kern.eventtimer.timer: HPET ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Changing this to "i8254" seems to have resolved the stalls. I'm running buildworld -j12 without issue. More than willing to test out a patch or two against head if anyone's still interested, otherwise I've thrown the change into loader.conf and will move along quietly. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:00:53 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92251106564A for ; Mon, 15 Aug 2011 21:00:53 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9258FC12 for ; Mon, 15 Aug 2011 21:00:52 +0000 (UTC) Received: by fxe4 with SMTP id 4so4957371fxe.13 for ; Mon, 15 Aug 2011 14:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sgfiwcBi1jQ6RzdIub9G8Y6i6wlfA3q1EN4ynmDhMUY=; b=iWiJM3+d1kY+uboG4L0O9nXKL5tdNhVkDOmSpSC2mNbo7X2xtNn/8gkdtWs5avo7nr eSB/LmWzW+mv0WEsKLYNiPPD0Mf7MKKPw926J+wc7LpHj+eCdeeB/wcRcELVTStLf2UY brIExGIFvq7Dyld8coZb9FeX1+GlRkaQYuRZs= Received: by 10.223.145.144 with SMTP id d16mr6018490fav.100.1313442051871; Mon, 15 Aug 2011 14:00:51 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p3sm5324046faa.33.2011.08.15.14.00.48 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 14:00:49 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E4988F0.7060000@FreeBSD.org> Date: Tue, 16 Aug 2011 00:00:32 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Schaefer References: <4E498326.2060308@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:00:53 -0000 On 15.08.2011 23:57, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin wrote: >> On 15.08.2011 22:18, Joe Schaefer wrote: >>> >>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer wrote: >>>> >>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon wrote: >>>>> >>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>> >>>>>> Brand new machine with a Phenom II X6 1100T and under chronic load >>>>>> the clock will stop running periodically until the machine eventually >>>>>> completely >>>>>> freezes. Note: during these stalls the kernel is still running, the >>>>>> machine is still >>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>> >>>>>> I've disabled Turbo mode in the bios and toyed with just about every >>>>>> other setting but nothing seems to resolve this problem. Based on the >>>>>> behavior >>>>>> of the machine (just making buildworld will eventually kill it, upping >>>>>> the -j flag >>>>>> just kills it faster), I'm guessing it has something to do with the >>>>>> Digi+ VRM features >>>>>> but again nothing I've tried modifying in the bios seems to help. >>>>>> >>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head now >>>>>> with >>>>>> a dtrace enabled kernel. >>>>>> >>>>>> Suggestions? >>>>> >>>>> On head, start with checking what source is used for driving clocks: >>>>> sysctl kern.eventtimer >>>> >>>> % sysctl kern.eventtimer [master] >>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>>> i8254(100) RTC(0) >>>> kern.eventtimer.et.LAPIC.flags: 15 >>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>> kern.eventtimer.et.LAPIC.quality: 400 >>>> kern.eventtimer.et.HPET.flags: 3 >>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>> kern.eventtimer.et.HPET.quality: 450 >>>> kern.eventtimer.et.HPET1.flags: 3 >>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>> kern.eventtimer.et.HPET1.quality: 450 >>>> kern.eventtimer.et.HPET2.flags: 3 >>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>> kern.eventtimer.et.HPET2.quality: 450 >>>> kern.eventtimer.et.i8254.flags: 1 >>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>> kern.eventtimer.et.i8254.quality: 100 >>>> kern.eventtimer.et.RTC.flags: 17 >>>> kern.eventtimer.et.RTC.frequency: 32768 >>>> kern.eventtimer.et.RTC.quality: 0 >>>> kern.eventtimer.periodic: 0 >>>> kern.eventtimer.timer: HPET >>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Changing this to "i8254" seems to have resolved the stalls. >>> I'm running buildworld -j12 without issue. More than willing >>> to test out a patch or two against head if anyone's still >>> interested, otherwise I've thrown the change into loader.conf >>> and will move along quietly. >> >> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET >> timer driver. That makes me think it is strange at least. Can you try also >> LAPIC timer and do alike experiments with kern.timeocunter? > > My problems with 8.2-RELEASE may have been network based. I don't recall > precisely if the clock was stalling there, my guess is no based on > what you wrote. > > I'll test LAPIC next ... so far so good. Just so I'm clear, you'd > like me to tweak > kern.timecounter.hardware as well? (Currently it's HPET). Yes. Instead. Ticking clock depends on both timecounter and eventtimer. >> Also, please check whether kern.timecounter.tc.X.counter value changes for >> the selected timercounter and whether you are receiving timer interrupts in >> `vmstat -i` -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:01:01 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2FD1065714 for ; Mon, 15 Aug 2011 21:01:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7EA68FC0A for ; Mon, 15 Aug 2011 21:01:00 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 4so4957371fxe.13 for ; Mon, 15 Aug 2011 14:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/acUp+JKA+1yCBNy7XMBkLI7K0p84f5W18qlYdcjwk0=; b=L744sdZb3RG6UukIJIKQxuD/T5WWuoy+Xfkdjc4ibq6M47Th796CFP4mIWJOTPKs3C r88e7JdfRKkCcveva5yqcJuOZL45GTcg9pna5I8sUyF6Hmz4ejcBLdHN3IRucJRbpAgx dDVzFXH4cB3Dky/kVvLxoDLpPKDqcNnLLBTfs= Received: by 10.223.85.145 with SMTP id o17mr6083477fal.16.1313440569491; Mon, 15 Aug 2011 13:36:09 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q15sm5313080fah.8.2011.08.15.13.36.07 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 13:36:08 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E498326.2060308@FreeBSD.org> Date: Mon, 15 Aug 2011 23:35:50 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Schaefer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:01:01 -0000 On 15.08.2011 22:18, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer wrote: >> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon wrote: >>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>> Brand new machine with a Phenom II X6 1100T and under chronic load >>>> the clock will stop running periodically until the machine eventually completely >>>> freezes. Note: during these stalls the kernel is still running, the >>>> machine is still >>>> mostly responsive, it's just that the clock is frozen in time. >>>> >>>> I've disabled Turbo mode in the bios and toyed with just about every >>>> other setting but nothing seems to resolve this problem. Based on the behavior >>>> of the machine (just making buildworld will eventually kill it, upping >>>> the -j flag >>>> just kills it faster), I'm guessing it has something to do with the >>>> Digi+ VRM features >>>> but again nothing I've tried modifying in the bios seems to help. >>>> >>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head now with >>>> a dtrace enabled kernel. >>>> >>>> Suggestions? >>> >>> On head, start with checking what source is used for driving clocks: >>> sysctl kern.eventtimer >> >> % sysctl kern.eventtimer [master] >> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >> i8254(100) RTC(0) >> kern.eventtimer.et.LAPIC.flags: 15 >> kern.eventtimer.et.LAPIC.frequency: 0 >> kern.eventtimer.et.LAPIC.quality: 400 >> kern.eventtimer.et.HPET.flags: 3 >> kern.eventtimer.et.HPET.frequency: 14318180 >> kern.eventtimer.et.HPET.quality: 450 >> kern.eventtimer.et.HPET1.flags: 3 >> kern.eventtimer.et.HPET1.frequency: 14318180 >> kern.eventtimer.et.HPET1.quality: 450 >> kern.eventtimer.et.HPET2.flags: 3 >> kern.eventtimer.et.HPET2.frequency: 14318180 >> kern.eventtimer.et.HPET2.quality: 450 >> kern.eventtimer.et.i8254.flags: 1 >> kern.eventtimer.et.i8254.frequency: 1193182 >> kern.eventtimer.et.i8254.quality: 100 >> kern.eventtimer.et.RTC.flags: 17 >> kern.eventtimer.et.RTC.frequency: 32768 >> kern.eventtimer.et.RTC.quality: 0 >> kern.eventtimer.periodic: 0 >> kern.eventtimer.timer: HPET > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Changing this to "i8254" seems to have resolved the stalls. > I'm running buildworld -j12 without issue. More than willing > to test out a patch or two against head if anyone's still > interested, otherwise I've thrown the change into loader.conf > and will move along quietly. 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET timer driver. That makes me think it is strange at least. Can you try also LAPIC timer and do alike experiments with kern.timeocunter? Also, please check whether kern.timecounter.tc.X.counter value changes for the selected timercounter and whether you are receiving timer interrupts in `vmstat -i` -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:13:54 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 694A0106566C; Mon, 15 Aug 2011 21:13:54 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 125DE8FC1C; Mon, 15 Aug 2011 21:13:53 +0000 (UTC) Received: by vxh11 with SMTP id 11so5569066vxh.13 for ; Mon, 15 Aug 2011 14:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=etoGHJknhagQ7rDRBZHUSe/lY4t6mA1L6G7sa6/V7i0=; b=aQ8/gdAFwfyA/qf5k1Ax3JIQBbUaP520yqQJvgq8lRu/qW9gu+p279IhqbcanNeteW RPM4ojNxeGErSSQKOinZLkyyTFS/ozEHv9OXT4Ya1CRXG5LSR7zEHjQvOh4tdvBtBZdC wcgniolhEW5hnF+7qffsdvSxFE+5K/Bmn31R0= MIME-Version: 1.0 Received: by 10.220.95.132 with SMTP id d4mr483404vcn.69.1313442833201; Mon, 15 Aug 2011 14:13:53 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 14:13:53 -0700 (PDT) In-Reply-To: <4E4988F0.7060000@FreeBSD.org> References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> Date: Mon, 15 Aug 2011 17:13:53 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:13:54 -0000 On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin wrote: > On 15.08.2011 23:57, Joe Schaefer wrote: >> >> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin =C2=A0= wrote: >>> >>> On 15.08.2011 22:18, Joe Schaefer wrote: >>>> >>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >>>> =C2=A0wrote: >>>>> >>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >>>>> =C2=A0wrote: >>>>>> >>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>>> >>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic load >>>>>>> the clock will stop running periodically until the machine eventual= ly >>>>>>> completely >>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still runnin= g, the >>>>>>> machine is still >>>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>>> >>>>>>> I've disabled Turbo mode in the bios and toyed with just about ever= y >>>>>>> other setting but nothing seems to resolve this problem. =C2=A0Base= d on >>>>>>> the >>>>>>> behavior >>>>>>> of the machine (just making buildworld will eventually kill it, >>>>>>> upping >>>>>>> the -j flag >>>>>>> just kills it faster), I'm guessing it has something to do with the >>>>>>> Digi+ VRM features >>>>>>> but again nothing I've tried modifying in the bios seems to help. >>>>>>> >>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running hea= d now >>>>>>> with >>>>>>> a dtrace enabled kernel. >>>>>>> >>>>>>> Suggestions? >>>>>> >>>>>> On head, start with checking what source is used for driving clocks: >>>>>> sysctl kern.eventtimer >>>>> >>>>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[master] >>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>>>> i8254(100) RTC(0) >>>>> kern.eventtimer.et.LAPIC.flags: 15 >>>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>>> kern.eventtimer.et.LAPIC.quality: 400 >>>>> kern.eventtimer.et.HPET.flags: 3 >>>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>>> kern.eventtimer.et.HPET.quality: 450 >>>>> kern.eventtimer.et.HPET1.flags: 3 >>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>>> kern.eventtimer.et.HPET1.quality: 450 >>>>> kern.eventtimer.et.HPET2.flags: 3 >>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>>> kern.eventtimer.et.HPET2.quality: 450 >>>>> kern.eventtimer.et.i8254.flags: 1 >>>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>>> kern.eventtimer.et.i8254.quality: 100 >>>>> kern.eventtimer.et.RTC.flags: 17 >>>>> kern.eventtimer.et.RTC.frequency: 32768 >>>>> kern.eventtimer.et.RTC.quality: 0 >>>>> kern.eventtimer.periodic: 0 >>>>> kern.eventtimer.timer: HPET >>>> >>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> Changing this to "i8254" seems to have resolved the stalls. >>>> I'm running buildworld -j12 without issue. =C2=A0More than willing >>>> to test out a patch or two against head if anyone's still >>>> interested, otherwise I've thrown the change into loader.conf >>>> and will move along quietly. >>> >>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HP= ET >>> timer driver. That makes me think it is strange at least. Can you try >>> also >>> LAPIC timer and do alike experiments with kern.timeocunter? >> >> My problems with 8.2-RELEASE may have been network based. =C2=A0I don't = recall >> precisely if the clock was stalling there, my guess is no based on >> what you wrote. >> >> I'll test LAPIC next ... so far so good. =C2=A0Just so I'm clear, you'd >> like me to tweak >> kern.timecounter.hardware as well? =C2=A0(Currently it's HPET). > > Yes. Instead. Ticking clock depends on both timecounter and eventtimer. Haven't found a combination that hangs my machine other than with the eventtimer at HPET. > >>> Also, please check whether kern.timecounter.tc.X.counter value changes >>> for >>> the selected timercounter and whether you are receiving timer interrupt= s >>> in >>> `vmstat -i` Yep. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:23:34 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B70731065672 for ; Mon, 15 Aug 2011 21:23:34 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44A3C8FC14 for ; Mon, 15 Aug 2011 21:23:33 +0000 (UTC) Received: by fxe4 with SMTP id 4so4972775fxe.13 for ; Mon, 15 Aug 2011 14:23:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LL1JayKJQOHbC7f/VmDjKF9H7bDvZDTLC7bOUPYAWmw=; b=qCgmEcwV+t7xL0c1YRMOdbTxa2A3k+X7+6mMPHQfn3INhFjpl4OjW2Po7Ulr3X1LaF n03VzyUpwFh24S+Pb7CkDzcVVdfy7MQcePIdvUJXJSCgHMwLn08EqadictUTYl4B2nEl Ct0M1TPoJds70NqogtbrK67C2XmSwAjCoGjZg= Received: by 10.223.143.18 with SMTP id s18mr5930090fau.134.1313443413017; Mon, 15 Aug 2011 14:23:33 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id w16sm2223761fah.44.2011.08.15.14.23.25 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 14:23:26 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E498E3D.7050100@FreeBSD.org> Date: Tue, 16 Aug 2011 00:23:09 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110709 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Schaefer References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:23:34 -0000 On 16.08.2011 00:13, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin wrote: >> On 15.08.2011 23:57, Joe Schaefer wrote: >>> >>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin wrote: >>>> >>>> On 15.08.2011 22:18, Joe Schaefer wrote: >>>>> >>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >>>>> wrote: >>>>>> >>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >>>>>> wrote: >>>>>>> >>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>>>> >>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic load >>>>>>>> the clock will stop running periodically until the machine eventually >>>>>>>> completely >>>>>>>> freezes. Note: during these stalls the kernel is still running, the >>>>>>>> machine is still >>>>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>>>> >>>>>>>> I've disabled Turbo mode in the bios and toyed with just about every >>>>>>>> other setting but nothing seems to resolve this problem. Based on >>>>>>>> the >>>>>>>> behavior >>>>>>>> of the machine (just making buildworld will eventually kill it, >>>>>>>> upping >>>>>>>> the -j flag >>>>>>>> just kills it faster), I'm guessing it has something to do with the >>>>>>>> Digi+ VRM features >>>>>>>> but again nothing I've tried modifying in the bios seems to help. >>>>>>>> >>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head now >>>>>>>> with >>>>>>>> a dtrace enabled kernel. >>>>>>>> >>>>>>>> Suggestions? >>>>>>> >>>>>>> On head, start with checking what source is used for driving clocks: >>>>>>> sysctl kern.eventtimer >>>>>> >>>>>> % sysctl kern.eventtimer [master] >>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>>>>> i8254(100) RTC(0) >>>>>> kern.eventtimer.et.LAPIC.flags: 15 >>>>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>>>> kern.eventtimer.et.LAPIC.quality: 400 >>>>>> kern.eventtimer.et.HPET.flags: 3 >>>>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>>>> kern.eventtimer.et.HPET.quality: 450 >>>>>> kern.eventtimer.et.HPET1.flags: 3 >>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>>>> kern.eventtimer.et.HPET1.quality: 450 >>>>>> kern.eventtimer.et.HPET2.flags: 3 >>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>>>> kern.eventtimer.et.HPET2.quality: 450 >>>>>> kern.eventtimer.et.i8254.flags: 1 >>>>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>>>> kern.eventtimer.et.i8254.quality: 100 >>>>>> kern.eventtimer.et.RTC.flags: 17 >>>>>> kern.eventtimer.et.RTC.frequency: 32768 >>>>>> kern.eventtimer.et.RTC.quality: 0 >>>>>> kern.eventtimer.periodic: 0 >>>>>> kern.eventtimer.timer: HPET >>>>> >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> Changing this to "i8254" seems to have resolved the stalls. >>>>> I'm running buildworld -j12 without issue. More than willing >>>>> to test out a patch or two against head if anyone's still >>>>> interested, otherwise I've thrown the change into loader.conf >>>>> and will move along quietly. >>>> >>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET >>>> timer driver. That makes me think it is strange at least. Can you try >>>> also >>>> LAPIC timer and do alike experiments with kern.timeocunter? >>> >>> My problems with 8.2-RELEASE may have been network based. I don't recall >>> precisely if the clock was stalling there, my guess is no based on >>> what you wrote. >>> >>> I'll test LAPIC next ... so far so good. Just so I'm clear, you'd >>> like me to tweak >>> kern.timecounter.hardware as well? (Currently it's HPET). >> >> Yes. Instead. Ticking clock depends on both timecounter and eventtimer. > > Haven't found a combination that hangs my machine other than with the > eventtimer at HPET. I mean trying eventtimer HPET and different timecounters. If changing timecounter won't help, try please this patch: --- acpi_hpet.c.prev 2010-12-25 11:28:45.000000000 +0200 +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 @@ -190,7 +190,7 @@ restart: bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num), t->next); } - if (fdiv < 5000) { + if (1 || fdiv < 5000) { bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num)); now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER); -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:23:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 748D5106566C for ; Mon, 15 Aug 2011 21:23:39 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9AB8FC08 for ; Mon, 15 Aug 2011 21:23:38 +0000 (UTC) Received: by vws18 with SMTP id 18so5623232vws.13 for ; Mon, 15 Aug 2011 14:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rH0bT/H477qOplf98yjEn+9ZSlE+iG7cwpUJiu7u6A4=; b=cbBxwrv6ZZt6uBtqXfFJk7WsWlsR3vw0Ns2IRL7X5go9Gx5/t3YpgnzGOJB0F9Pfav AG9gpvmkBP4gTNzNbOIlg1WKEtBJiRLB4xcu8c8o/FsxYwg820Cl1OSgkahAWZ2uD+PH +/NirRZAYBIa55fvBdPOoC7gs538K28Uj4VVw= MIME-Version: 1.0 Received: by 10.220.96.129 with SMTP id h1mr1107276vcn.104.1313441866079; Mon, 15 Aug 2011 13:57:46 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 13:57:46 -0700 (PDT) In-Reply-To: <4E498326.2060308@FreeBSD.org> References: <4E498326.2060308@FreeBSD.org> Date: Mon, 15 Aug 2011 16:57:46 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:23:39 -0000 On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin wrote: > On 15.08.2011 22:18, Joe Schaefer wrote: >> >> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer =C2=A0w= rote: >>> >>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon =C2=A0wr= ote: >>>> >>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>> >>>>> Brand new machine with a Phenom II X6 1100T and under chronic load >>>>> the clock will stop running periodically until the machine eventually >>>>> completely >>>>> freezes. =C2=A0Note: during these stalls the kernel is still running,= the >>>>> machine is still >>>>> mostly responsive, it's just that the clock is frozen in time. >>>>> >>>>> I've disabled Turbo mode in the bios and toyed with just about every >>>>> other setting but nothing seems to resolve this problem. =C2=A0Based = on the >>>>> behavior >>>>> of the machine (just making buildworld will eventually kill it, uppin= g >>>>> the -j flag >>>>> just kills it faster), I'm guessing it has something to do with the >>>>> Digi+ VRM features >>>>> but again nothing I've tried modifying in the bios seems to help. >>>>> >>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running head = now >>>>> with >>>>> a dtrace enabled kernel. >>>>> >>>>> Suggestions? >>>> >>>> On head, start with checking what source is used for driving clocks: >>>> sysctl kern.eventtimer >>> >>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[m= aster] >>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>> i8254(100) RTC(0) >>> kern.eventtimer.et.LAPIC.flags: 15 >>> kern.eventtimer.et.LAPIC.frequency: 0 >>> kern.eventtimer.et.LAPIC.quality: 400 >>> kern.eventtimer.et.HPET.flags: 3 >>> kern.eventtimer.et.HPET.frequency: 14318180 >>> kern.eventtimer.et.HPET.quality: 450 >>> kern.eventtimer.et.HPET1.flags: 3 >>> kern.eventtimer.et.HPET1.frequency: 14318180 >>> kern.eventtimer.et.HPET1.quality: 450 >>> kern.eventtimer.et.HPET2.flags: 3 >>> kern.eventtimer.et.HPET2.frequency: 14318180 >>> kern.eventtimer.et.HPET2.quality: 450 >>> kern.eventtimer.et.i8254.flags: 1 >>> kern.eventtimer.et.i8254.frequency: 1193182 >>> kern.eventtimer.et.i8254.quality: 100 >>> kern.eventtimer.et.RTC.flags: 17 >>> kern.eventtimer.et.RTC.frequency: 32768 >>> kern.eventtimer.et.RTC.quality: 0 >>> kern.eventtimer.periodic: 0 >>> kern.eventtimer.timer: HPET >> >> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Changing this to "i8254" seems to have resolved the stalls. >> I'm running buildworld -j12 without issue. =C2=A0More than willing >> to test out a patch or two against head if anyone's still >> interested, otherwise I've thrown the change into loader.conf >> and will move along quietly. > > 8.2-RELEASE you've mentioned doesn't have event timers subsystem and HPET > timer driver. That makes me think it is strange at least. Can you try als= o > LAPIC timer and do alike experiments with kern.timeocunter? My problems with 8.2-RELEASE may have been network based. I don't recall precisely if the clock was stalling there, my guess is no based on what you wrote. I'll test LAPIC next ... so far so good. Just so I'm clear, you'd like me to tweak kern.timecounter.hardware as well? (Currently it's HPET). > > Also, please check whether kern.timecounter.tc.X.counter value changes fo= r > the selected timercounter and whether you are receiving timer interrupts = in > `vmstat -i` > > -- > Alexander Motin > From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 21:47:41 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5193D106566B; Mon, 15 Aug 2011 21:47:41 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF8758FC0A; Mon, 15 Aug 2011 21:47:40 +0000 (UTC) Received: by vxh11 with SMTP id 11so5596371vxh.13 for ; Mon, 15 Aug 2011 14:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=h7Z41VeYLSLOYVD590pgl0n+ey9qSjMmh9SIAbzsTW8=; b=xGtHIW7ZUgkmOFz9fQ7CO+Nh+Yl4oGyIx4M/no2jXcZqgVA5YkRVzBbCYQgdeS2vCd F4L9xc5BzdKL3JDGpxRkDHHPPR7ehr/P1jDdjw8g3UclKEjriKhwG/LZ+Qw9q4DBp4ML /N7kEkdPGSm0aMLHsgJxwL3hFRi8fKEQzA+0g= MIME-Version: 1.0 Received: by 10.220.96.129 with SMTP id h1mr1118724vcn.104.1313444859989; Mon, 15 Aug 2011 14:47:39 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 14:47:39 -0700 (PDT) In-Reply-To: <4E498E3D.7050100@FreeBSD.org> References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Mon, 15 Aug 2011 17:47:39 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:47:41 -0000 On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin wrote: > On 16.08.2011 00:13, Joe Schaefer wrote: >> >> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin =C2=A0= wrote: >>> >>> On 15.08.2011 23:57, Joe Schaefer wrote: >>>> >>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin >>>> =C2=A0wrote: >>>>> >>>>> On 15.08.2011 22:18, Joe Schaefer wrote: >>>>>> >>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >>>>>> =C2=A0wrote: >>>>>>> >>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >>>>>>> =C2=A0wrote: >>>>>>>> >>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>>>>> >>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic loa= d >>>>>>>>> the clock will stop running periodically until the machine >>>>>>>>> eventually >>>>>>>>> completely >>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still runn= ing, >>>>>>>>> the >>>>>>>>> machine is still >>>>>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>>>>> >>>>>>>>> I've disabled Turbo mode in the bios and toyed with just about >>>>>>>>> every >>>>>>>>> other setting but nothing seems to resolve this problem. =C2=A0Ba= sed on >>>>>>>>> the >>>>>>>>> behavior >>>>>>>>> of the machine (just making buildworld will eventually kill it, >>>>>>>>> upping >>>>>>>>> the -j flag >>>>>>>>> just kills it faster), I'm guessing it has something to do with t= he >>>>>>>>> Digi+ VRM features >>>>>>>>> but again nothing I've tried modifying in the bios seems to help. >>>>>>>>> >>>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running h= ead now >>>>>>>>> with >>>>>>>>> a dtrace enabled kernel. >>>>>>>>> >>>>>>>>> Suggestions? >>>>>>>> >>>>>>>> On head, start with checking what source is used for driving clock= s: >>>>>>>> sysctl kern.eventtimer >>>>>>> >>>>>>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[master] >>>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>>>>>> i8254(100) RTC(0) >>>>>>> kern.eventtimer.et.LAPIC.flags: 15 >>>>>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>>>>> kern.eventtimer.et.LAPIC.quality: 400 >>>>>>> kern.eventtimer.et.HPET.flags: 3 >>>>>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>>>>> kern.eventtimer.et.HPET.quality: 450 >>>>>>> kern.eventtimer.et.HPET1.flags: 3 >>>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>>>>> kern.eventtimer.et.HPET1.quality: 450 >>>>>>> kern.eventtimer.et.HPET2.flags: 3 >>>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>>>>> kern.eventtimer.et.HPET2.quality: 450 >>>>>>> kern.eventtimer.et.i8254.flags: 1 >>>>>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>>>>> kern.eventtimer.et.i8254.quality: 100 >>>>>>> kern.eventtimer.et.RTC.flags: 17 >>>>>>> kern.eventtimer.et.RTC.frequency: 32768 >>>>>>> kern.eventtimer.et.RTC.quality: 0 >>>>>>> kern.eventtimer.periodic: 0 >>>>>>> kern.eventtimer.timer: HPET >>>>>> >>>>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> Changing this to "i8254" seems to have resolved the stalls. >>>>>> I'm running buildworld -j12 without issue. =C2=A0More than willing >>>>>> to test out a patch or two against head if anyone's still >>>>>> interested, otherwise I've thrown the change into loader.conf >>>>>> and will move along quietly. >>>>> >>>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and >>>>> HPET >>>>> timer driver. That makes me think it is strange at least. Can you try >>>>> also >>>>> LAPIC timer and do alike experiments with kern.timeocunter? >>>> >>>> My problems with 8.2-RELEASE may have been network based. =C2=A0I don'= t >>>> recall >>>> precisely if the clock was stalling there, my guess is no based on >>>> what you wrote. >>>> >>>> I'll test LAPIC next ... so far so good. =C2=A0Just so I'm clear, you'= d >>>> like me to tweak >>>> kern.timecounter.hardware as well? =C2=A0(Currently it's HPET). >>> >>> Yes. Instead. Ticking clock depends on both timecounter and eventtimer. >> >> Haven't found a combination that hangs my machine other than with the >> eventtimer at HPET. > > I mean trying eventtimer HPET and different timecounters. Doesn't seem to help. Eventtimer HPET and timecounter ACPI-fast still stal= ls. > > If changing timecounter won't help, try please this patch: > > --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +0200 > +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 > @@ -190,7 +190,7 @@ restart: > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(sc->me= m_res, HPET_TIMER_COMPARATOR(t->num), > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t->n= ext); > =C2=A0 =C2=A0 =C2=A0 =C2=A0} > - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) { > + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(sc->mem= _res, HPET_TIMER_COMPARATOR(t->num)); > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_read_4= (sc->mem_res, HPET_MAIN_COUNTER); > > -- > Alexander Motin Will do next. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 22:23:47 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 672C21065670; Mon, 15 Aug 2011 22:23:47 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 07D4E8FC08; Mon, 15 Aug 2011 22:23:46 +0000 (UTC) Received: by vxh11 with SMTP id 11so5621717vxh.13 for ; Mon, 15 Aug 2011 15:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+Wn1NN/jIX4kVLMSH9Rk+2Ruqo/wvtwM9autt4rc0L0=; b=GxKREL+ghcIhNbofiJqvLq3KjMe9DS8hXwoeNyoyiSylN+KiHS89ygvXGts3Q2dav4 lC1rIpv0jrHaarFtP0MOVQRslnFxT12S1mt8Wxt0Cq6SLoXiDpZ77aqRYV0QcO/L0bY4 phWfm5P8Pp6yORnJp7MZiLrXvsvF6EJS2/Fuo= MIME-Version: 1.0 Received: by 10.220.150.204 with SMTP id z12mr1134353vcv.34.1313447026051; Mon, 15 Aug 2011 15:23:46 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 15:23:46 -0700 (PDT) In-Reply-To: References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Mon, 15 Aug 2011 18:23:46 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 22:23:47 -0000 On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin wrote: >> On 16.08.2011 00:13, Joe Schaefer wrote: >>> >>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin =C2= =A0wrote: >>>> >>>> On 15.08.2011 23:57, Joe Schaefer wrote: >>>>> >>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin >>>>> =C2=A0wrote: >>>>>> >>>>>> On 15.08.2011 22:18, Joe Schaefer wrote: >>>>>>> >>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >>>>>>> =C2=A0wrote: >>>>>>>> >>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >>>>>>>> =C2=A0wrote: >>>>>>>>> >>>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>>>>>> >>>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic lo= ad >>>>>>>>>> the clock will stop running periodically until the machine >>>>>>>>>> eventually >>>>>>>>>> completely >>>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still run= ning, >>>>>>>>>> the >>>>>>>>>> machine is still >>>>>>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>>>>>> >>>>>>>>>> I've disabled Turbo mode in the bios and toyed with just about >>>>>>>>>> every >>>>>>>>>> other setting but nothing seems to resolve this problem. =C2=A0B= ased on >>>>>>>>>> the >>>>>>>>>> behavior >>>>>>>>>> of the machine (just making buildworld will eventually kill it, >>>>>>>>>> upping >>>>>>>>>> the -j flag >>>>>>>>>> just kills it faster), I'm guessing it has something to do with = the >>>>>>>>>> Digi+ VRM features >>>>>>>>>> but again nothing I've tried modifying in the bios seems to help= . >>>>>>>>>> >>>>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running = head now >>>>>>>>>> with >>>>>>>>>> a dtrace enabled kernel. >>>>>>>>>> >>>>>>>>>> Suggestions? >>>>>>>>> >>>>>>>>> On head, start with checking what source is used for driving cloc= ks: >>>>>>>>> sysctl kern.eventtimer >>>>>>>> >>>>>>>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0[master] >>>>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400) >>>>>>>> i8254(100) RTC(0) >>>>>>>> kern.eventtimer.et.LAPIC.flags: 15 >>>>>>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>>>>>> kern.eventtimer.et.LAPIC.quality: 400 >>>>>>>> kern.eventtimer.et.HPET.flags: 3 >>>>>>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>>>>>> kern.eventtimer.et.HPET.quality: 450 >>>>>>>> kern.eventtimer.et.HPET1.flags: 3 >>>>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>>>>>> kern.eventtimer.et.HPET1.quality: 450 >>>>>>>> kern.eventtimer.et.HPET2.flags: 3 >>>>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>>>>>> kern.eventtimer.et.HPET2.quality: 450 >>>>>>>> kern.eventtimer.et.i8254.flags: 1 >>>>>>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>>>>>> kern.eventtimer.et.i8254.quality: 100 >>>>>>>> kern.eventtimer.et.RTC.flags: 17 >>>>>>>> kern.eventtimer.et.RTC.frequency: 32768 >>>>>>>> kern.eventtimer.et.RTC.quality: 0 >>>>>>>> kern.eventtimer.periodic: 0 >>>>>>>> kern.eventtimer.timer: HPET >>>>>>> >>>>>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>> Changing this to "i8254" seems to have resolved the stalls. >>>>>>> I'm running buildworld -j12 without issue. =C2=A0More than willing >>>>>>> to test out a patch or two against head if anyone's still >>>>>>> interested, otherwise I've thrown the change into loader.conf >>>>>>> and will move along quietly. >>>>>> >>>>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem and >>>>>> HPET >>>>>> timer driver. That makes me think it is strange at least. Can you tr= y >>>>>> also >>>>>> LAPIC timer and do alike experiments with kern.timeocunter? >>>>> >>>>> My problems with 8.2-RELEASE may have been network based. =C2=A0I don= 't >>>>> recall >>>>> precisely if the clock was stalling there, my guess is no based on >>>>> what you wrote. >>>>> >>>>> I'll test LAPIC next ... so far so good. =C2=A0Just so I'm clear, you= 'd >>>>> like me to tweak >>>>> kern.timecounter.hardware as well? =C2=A0(Currently it's HPET). >>>> >>>> Yes. Instead. Ticking clock depends on both timecounter and eventtimer= . >>> >>> Haven't found a combination that hangs my machine other than with the >>> eventtimer at HPET. >> >> I mean trying eventtimer HPET and different timecounters. > > Doesn't seem to help. =C2=A0Eventtimer HPET and timecounter ACPI-fast sti= ll stalls. > >> >> If changing timecounter won't help, try please this patch: >> >> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +0200 >> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 >> @@ -190,7 +190,7 @@ restart: >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(sc->m= em_res, HPET_TIMER_COMPARATOR(t->num), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t->= next); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) { >> + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(sc->me= m_res, HPET_TIMER_COMPARATOR(t->num)); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_read_= 4(sc->mem_res, HPET_MAIN_COUNTER); >> >> -- >> Alexander Motin > > Will do next. > Patch applied. Running with HPET eventtimer and no stalls during make buildworld -j12. From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 15 23:04:37 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBA01065670; Mon, 15 Aug 2011 23:04:37 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 604EA8FC0A; Mon, 15 Aug 2011 23:04:37 +0000 (UTC) Received: by vxh11 with SMTP id 11so5646163vxh.13 for ; Mon, 15 Aug 2011 16:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UzrvvzZNKfn9Zn1m0Q8cAJJDq7zxWuzrj1faAUKOsRk=; b=ZRnZGP6YbcSGuuCcml3F10cxbH2wdg2lWiyw6Njufr5tm+RbjyxiQ2Nonzw4lEvd94 jkTS6RDPPfrmCr9ua34WpPcmSRBMS0sbVcXgnVSErgBuQvBZa6VXU1qIxuGfVp75pIoU 1MpBE9bc3pIt5ZQpCMxTLkEqfjdomH7zwkRC4= MIME-Version: 1.0 Received: by 10.52.175.162 with SMTP id cb2mr3913147vdc.432.1313449476498; Mon, 15 Aug 2011 16:04:36 -0700 (PDT) Received: by 10.220.190.7 with HTTP; Mon, 15 Aug 2011 16:04:36 -0700 (PDT) In-Reply-To: References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Mon, 15 Aug 2011 19:04:36 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 23:04:38 -0000 FWIW here's a patch I needed to get buildworld to complete against head (as of today): Index: secure/libexec/ssh-keysign/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- secure/libexec/ssh-keysign/Makefile (revision 224899) +++ secure/libexec/ssh-keysign/Makefile (working copy) @@ -1,7 +1,7 @@ # $FreeBSD$ PROG=3D ssh-keysign -SRCS=3D ssh-keysign.c readconf.c roaming_dummy.c +SRCS=3D ssh-keysign.c buffer.c readconf.c roaming_dummy.c MAN=3D ssh-keysign.8 CFLAGS+=3D-I${SSHDIR} -include ssh_namespace.h .if defined(ENABLE_SUID_SSH) Index: sys/dev/acpica/acpi_hpet.c On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer wrote: > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer wrote: >> On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin wrote= : >>> On 16.08.2011 00:13, Joe Schaefer wrote: >>>> >>>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin =C2= =A0wrote: >>>>> >>>>> On 15.08.2011 23:57, Joe Schaefer wrote: >>>>>> >>>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin >>>>>> =C2=A0wrote: >>>>>>> >>>>>>> On 15.08.2011 22:18, Joe Schaefer wrote: >>>>>>>> >>>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >>>>>>>> =C2=A0wrote: >>>>>>>>> >>>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >>>>>>>>> =C2=A0wrote: >>>>>>>>>> >>>>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >>>>>>>>>>> >>>>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic l= oad >>>>>>>>>>> the clock will stop running periodically until the machine >>>>>>>>>>> eventually >>>>>>>>>>> completely >>>>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still ru= nning, >>>>>>>>>>> the >>>>>>>>>>> machine is still >>>>>>>>>>> mostly responsive, it's just that the clock is frozen in time. >>>>>>>>>>> >>>>>>>>>>> I've disabled Turbo mode in the bios and toyed with just about >>>>>>>>>>> every >>>>>>>>>>> other setting but nothing seems to resolve this problem. =C2=A0= Based on >>>>>>>>>>> the >>>>>>>>>>> behavior >>>>>>>>>>> of the machine (just making buildworld will eventually kill it, >>>>>>>>>>> upping >>>>>>>>>>> the -j flag >>>>>>>>>>> just kills it faster), I'm guessing it has something to do with= the >>>>>>>>>>> Digi+ VRM features >>>>>>>>>>> but again nothing I've tried modifying in the bios seems to hel= p. >>>>>>>>>>> >>>>>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Running= head now >>>>>>>>>>> with >>>>>>>>>>> a dtrace enabled kernel. >>>>>>>>>>> >>>>>>>>>>> Suggestions? >>>>>>>>>> >>>>>>>>>> On head, start with checking what source is used for driving clo= cks: >>>>>>>>>> sysctl kern.eventtimer >>>>>>>>> >>>>>>>>> % sysctl kern.eventtimer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[master] >>>>>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) LAPIC(400= ) >>>>>>>>> i8254(100) RTC(0) >>>>>>>>> kern.eventtimer.et.LAPIC.flags: 15 >>>>>>>>> kern.eventtimer.et.LAPIC.frequency: 0 >>>>>>>>> kern.eventtimer.et.LAPIC.quality: 400 >>>>>>>>> kern.eventtimer.et.HPET.flags: 3 >>>>>>>>> kern.eventtimer.et.HPET.frequency: 14318180 >>>>>>>>> kern.eventtimer.et.HPET.quality: 450 >>>>>>>>> kern.eventtimer.et.HPET1.flags: 3 >>>>>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >>>>>>>>> kern.eventtimer.et.HPET1.quality: 450 >>>>>>>>> kern.eventtimer.et.HPET2.flags: 3 >>>>>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >>>>>>>>> kern.eventtimer.et.HPET2.quality: 450 >>>>>>>>> kern.eventtimer.et.i8254.flags: 1 >>>>>>>>> kern.eventtimer.et.i8254.frequency: 1193182 >>>>>>>>> kern.eventtimer.et.i8254.quality: 100 >>>>>>>>> kern.eventtimer.et.RTC.flags: 17 >>>>>>>>> kern.eventtimer.et.RTC.frequency: 32768 >>>>>>>>> kern.eventtimer.et.RTC.quality: 0 >>>>>>>>> kern.eventtimer.periodic: 0 >>>>>>>>> kern.eventtimer.timer: HPET >>>>>>>> >>>>>>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>>>> Changing this to "i8254" seems to have resolved the stalls. >>>>>>>> I'm running buildworld -j12 without issue. =C2=A0More than willing >>>>>>>> to test out a patch or two against head if anyone's still >>>>>>>> interested, otherwise I've thrown the change into loader.conf >>>>>>>> and will move along quietly. >>>>>>> >>>>>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem an= d >>>>>>> HPET >>>>>>> timer driver. That makes me think it is strange at least. Can you t= ry >>>>>>> also >>>>>>> LAPIC timer and do alike experiments with kern.timeocunter? >>>>>> >>>>>> My problems with 8.2-RELEASE may have been network based. =C2=A0I do= n't >>>>>> recall >>>>>> precisely if the clock was stalling there, my guess is no based on >>>>>> what you wrote. >>>>>> >>>>>> I'll test LAPIC next ... so far so good. =C2=A0Just so I'm clear, yo= u'd >>>>>> like me to tweak >>>>>> kern.timecounter.hardware as well? =C2=A0(Currently it's HPET). >>>>> >>>>> Yes. Instead. Ticking clock depends on both timecounter and eventtime= r. >>>> >>>> Haven't found a combination that hangs my machine other than with the >>>> eventtimer at HPET. >>> >>> I mean trying eventtimer HPET and different timecounters. >> >> Doesn't seem to help. =C2=A0Eventtimer HPET and timecounter ACPI-fast st= ill stalls. >> >>> >>> If changing timecounter won't help, try please this patch: >>> >>> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +0200 >>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 >>> @@ -190,7 +190,7 @@ restart: >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(sc->= mem_res, HPET_TIMER_COMPARATOR(t->num), >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t-= >next); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>> - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) { >>> + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) { >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(sc->m= em_res, HPET_TIMER_COMPARATOR(t->num)); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_read= _4(sc->mem_res, HPET_MAIN_COUNTER); >>> >>> -- >>> Alexander Motin >> >> Will do next. >> > > Patch applied. Running with HPET eventtimer and no stalls during > make buildworld -j12. > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 10:54:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB681065672 for ; Tue, 16 Aug 2011 10:54:55 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 237678FC12 for ; Tue, 16 Aug 2011 10:54:54 +0000 (UTC) Received: by fxe4 with SMTP id 4so5350664fxe.13 for ; Tue, 16 Aug 2011 03:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4Obz9CSQtIpUEKOlxI8A1cE5PLb1MaXpSBKHoomQTA4=; b=lS/zJcLGNmCS1I68f0AQUGdTjqDmSiy5kUupS+hWFxvrpyN7fKVokIuH26mmMs/9bH hafdR89OMBMJRcH7uMueHXtqWscnl1ealmXgN+u+AKvGXjnT9k+LqBlyDzrbKUjNK+5X 9ga6YaLxti6gJyAVrQr3uU5YvRpK986gh7cI8= MIME-Version: 1.0 Received: by 10.223.30.214 with SMTP id v22mr6952642fac.108.1313492093791; Tue, 16 Aug 2011 03:54:53 -0700 (PDT) Received: by 10.223.159.68 with HTTP; Tue, 16 Aug 2011 03:54:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 16:24:53 +0530 Message-ID: From: Shrikanth Kamath To: ambrosehuang ambrose Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: DTrace unable to dump typedef'ed argument X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 10:54:55 -0000 Nice. I checked that, things are looking more interesting now :) Thanks Ambrose. On Mon, Aug 15, 2011 at 6:29 AM, ambrosehuang ambrose wrote: > it has been fixed by > kern/159064: [dtrace] MFC request for dtrace to fix "invalid probe > specifier" > > 2011/8/14 ambrosehuang ambrose >> >> same problem on 8.2-stable >> >> 2011/8/10 Shrikanth Kamath >>> >>> I found this on a FreeBSD 8.1 box... >>> >>> %dtrace -l -f rtalloc_fib -v >>> >>> ... >>> Argument Types >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0args[0]: struct route * >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0args[1]: (unknown) >>> >>> The function defined in sys/net/route.c: void rtalloc_fib(struct route >>> *ro, u_int fibnum) >>> u_int is typedef unsigned int >>> >>> I checked the ctfdump for /boot/kernel/kernel and found u_int is a >>> resolved type. >>> >>> [14077] FUNC (rtalloc_fib) returns: 29 args: (1335, 5) >>> >>> Checking the CTF table "5" is found to be a resolved typedef. >>> >>> <4> INTEGER unsigned int encoding=3D0x0 offset=3D0 bits=3D32 >>> <5> TYPEDEF u_int refers to 4 >>> >>> But since it shows unknown with dtrace -l -f o/p, one cannot directly >>> use args[1]. >>> >>> Is this a known problem, any fix or workaround? >>> >>> >>> -- >>> Shrikanth R K >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> > > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 12:04:13 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 519291065672 for ; Tue, 16 Aug 2011 12:04:13 +0000 (UTC) (envelope-from ambrosehua@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id F314C8FC17 for ; Tue, 16 Aug 2011 12:04:12 +0000 (UTC) Received: by qwc9 with SMTP id 9so3851270qwc.13 for ; Tue, 16 Aug 2011 05:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ye+SJSIl7gpvBr2aT0wQSuxcItmQ3GSIbQoFu4cjkYU=; b=benu7YfLhw8781jhdhAoHD2FBGp0UdV5fpyWHpkhMH1DXdO7NdoCzHpcwGmoJTdr2f Duxv/VSC095QS4lJtzlrHmrDsiEB1N29aA8lLbazvGvDwcZpLbdKj/DLiT7P4Gg3sA5O a4F2dXKOhcSONpsrRK711tIWHzi5JXkLk1Rqs= MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr3250208qci.223.1313494767353; Tue, 16 Aug 2011 04:39:27 -0700 (PDT) Received: by 10.229.30.5 with HTTP; Tue, 16 Aug 2011 04:39:27 -0700 (PDT) In-Reply-To: References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Tue, 16 Aug 2011 19:39:27 +0800 Message-ID: From: ambrosehuang ambrose To: Joe Schaefer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Alexander Motin , hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 12:04:13 -0000 2011/8/16 Joe Schaefer > FWIW here's a patch I needed to get buildworld to complete against head > (as of today): > > Index: secure/libexec/ssh-keysign/Makefile > =================================================================== > --- secure/libexec/ssh-keysign/Makefile (revision 224899) > +++ secure/libexec/ssh-keysign/Makefile (working copy) > @@ -1,7 +1,7 @@ > # $FreeBSD$ > > PROG= ssh-keysign > -SRCS= ssh-keysign.c readconf.c roaming_dummy.c > +SRCS= ssh-keysign.c buffer.c readconf.c roaming_dummy.c > MAN= ssh-keysign.8 > CFLAGS+=-I${SSHDIR} -include ssh_namespace.h > .if defined(ENABLE_SUID_SSH) > Index: sys/dev/acpica/acpi_hpet.c > > > On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer wrote: > > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer wrote: > >> On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin > wrote: > >>> On 16.08.2011 00:13, Joe Schaefer wrote: > >>>> > >>>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin > wrote: > >>>>> > >>>>> On 15.08.2011 23:57, Joe Schaefer wrote: > >>>>>> > >>>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin > >>>>>> wrote: > >>>>>>> > >>>>>>> On 15.08.2011 22:18, Joe Schaefer wrote: > >>>>>>>> > >>>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: > >>>>>>>>>>> > >>>>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chronic > load > >>>>>>>>>>> the clock will stop running periodically until the machine > >>>>>>>>>>> eventually > >>>>>>>>>>> completely > >>>>>>>>>>> freezes. Note: during these stalls the kernel is still > running, > >>>>>>>>>>> the > >>>>>>>>>>> machine is still > >>>>>>>>>>> mostly responsive, it's just that the clock is frozen in time. > >>>>>>>>>>> > >>>>>>>>>>> I've disabled Turbo mode in the bios and toyed with just about > >>>>>>>>>>> every > >>>>>>>>>>> other setting but nothing seems to resolve this problem. Based > on > >>>>>>>>>>> the > >>>>>>>>>>> behavior > >>>>>>>>>>> of the machine (just making buildworld will eventually kill it, > >>>>>>>>>>> upping > >>>>>>>>>>> the -j flag > >>>>>>>>>>> just kills it faster), I'm guessing it has something to do with > the > >>>>>>>>>>> Digi+ VRM features > >>>>>>>>>>> but again nothing I've tried modifying in the bios seems to > help. > >>>>>>>>>>> > >>>>>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). Running head > now > >>>>>>>>>>> with > >>>>>>>>>>> a dtrace enabled kernel. > >>>>>>>>>>> > >>>>>>>>>>> Suggestions? > >>>>>>>>>> > >>>>>>>>>> On head, start with checking what source is used for driving > clocks: > >>>>>>>>>> sysctl kern.eventtimer > >>>>>>>>> > >>>>>>>>> % sysctl kern.eventtimer > [master] > >>>>>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) > LAPIC(400) > >>>>>>>>> i8254(100) RTC(0) > >>>>>>>>> kern.eventtimer.et.LAPIC.flags: 15 > >>>>>>>>> kern.eventtimer.et.LAPIC.frequency: 0 > >>>>>>>>> kern.eventtimer.et.LAPIC.quality: 400 > >>>>>>>>> kern.eventtimer.et.HPET.flags: 3 > >>>>>>>>> kern.eventtimer.et.HPET.frequency: 14318180 > >>>>>>>>> kern.eventtimer.et.HPET.quality: 450 > >>>>>>>>> kern.eventtimer.et.HPET1.flags: 3 > >>>>>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 > >>>>>>>>> kern.eventtimer.et.HPET1.quality: 450 > >>>>>>>>> kern.eventtimer.et.HPET2.flags: 3 > >>>>>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 > >>>>>>>>> kern.eventtimer.et.HPET2.quality: 450 > >>>>>>>>> kern.eventtimer.et.i8254.flags: 1 > >>>>>>>>> kern.eventtimer.et.i8254.frequency: 1193182 > >>>>>>>>> kern.eventtimer.et.i8254.quality: 100 > >>>>>>>>> kern.eventtimer.et.RTC.flags: 17 > >>>>>>>>> kern.eventtimer.et.RTC.frequency: 32768 > >>>>>>>>> kern.eventtimer.et.RTC.quality: 0 > >>>>>>>>> kern.eventtimer.periodic: 0 > >>>>>>>>> kern.eventtimer.timer: HPET > >>>>>>>> > >>>>>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>>>>> Changing this to "i8254" seems to have resolved the stalls. > >>>>>>>> I'm running buildworld -j12 without issue. More than willing > >>>>>>>> to test out a patch or two against head if anyone's still > >>>>>>>> interested, otherwise I've thrown the change into loader.conf > >>>>>>>> and will move along quietly. > >>>>>>> > >>>>>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem > and > >>>>>>> HPET > >>>>>>> timer driver. That makes me think it is strange at least. Can you > try > >>>>>>> also > >>>>>>> LAPIC timer and do alike experiments with kern.timeocunter? > >>>>>> > >>>>>> My problems with 8.2-RELEASE may have been network based. I don't > >>>>>> recall > >>>>>> precisely if the clock was stalling there, my guess is no based on > >>>>>> what you wrote. > >>>>>> > >>>>>> I'll test LAPIC next ... so far so good. Just so I'm clear, you'd > >>>>>> like me to tweak > >>>>>> kern.timecounter.hardware as well? (Currently it's HPET). > >>>>> > >>>>> Yes. Instead. Ticking clock depends on both timecounter and > eventtimer. > >>>> > >>>> Haven't found a combination that hangs my machine other than with the > >>>> eventtimer at HPET. > >>> > >>> I mean trying eventtimer HPET and different timecounters. > >> > >> Doesn't seem to help. Eventtimer HPET and timecounter ACPI-fast still > stalls. > >> > >>> > >>> If changing timecounter won't help, try please this patch: > >>> > >>> --- acpi_hpet.c.prev 2010-12-25 11:28:45.000000000 +0200 > >>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 > >>> @@ -190,7 +190,7 @@ restart: > >>> bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num), > >>> t->next); > >>> } > >>> - if (fdiv < 5000) { > >>> + if (1 || fdiv < 5000) { > >>> bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num)); > >>> now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER); > >>> > >>> -- > >>> Alexander Motin > >> > >> Will do next. > >> > > > > Patch applied. Running with HPET eventtimer and no stalls during > > make buildworld -j12. > > > it maybe help, I used to come across a bug on Linux with regard to HPET, some northbridge chipset (maybe amd's, where HPET sit on) has a problem, that writes to compatitor regs will not take effect immediately, you need a read to reg to flush it; > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 12:37:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE983106564A for ; Tue, 16 Aug 2011 12:37:33 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 4D79E8FC14 for ; Tue, 16 Aug 2011 12:37:32 +0000 (UTC) Received: (qmail 31396 invoked from network); 16 Aug 2011 12:10:50 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 16 Aug 2011 12:10:50 -0000 Received: (qmail 31388 invoked by uid 599); 16 Aug 2011 12:10:50 -0000 Received: from unknown (HELO icritical.com) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Tue, 16 Aug 2011 13:10:50 +0100 Message-ID: <4E4A5DFC.7010807@icritical.com> Date: Tue, 16 Aug 2011 13:09:32 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110403 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Aug 2011 12:10:47.0575 (UTC) FILETIME=[882AFA70:01CC5C0D] X-Virus-Scanned: by iCritical at mail1.icritical.com Subject: Alternate source trees X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 12:37:34 -0000 I'm trying to setup a box to do automated FreeBSD builds for other hosts from multiple source trees. I have a couple of source trees mounted - for legibility's sake let's say /build/stable and /build/current. I also have a few obj dirs for different targets. The current obj tree is symlinked to /usr/obj, and this works fine. The problem comes when I symlink /usr/src: when I buildworld, I get /usr/obj/build/current/[...] instead of the desired /usr/obj/usr/src/[...] This is presumably fine when installing on the same machine, but it breaks when using it on another host with /usr/src and /usr/obj mounted over nfs. The only way I can see around this is a hack using a nullfs mount of /usr/src instead of a symlink. Am I missing something? An environment variable perhaps? How does the build process know about the non-symlinked path anyway? I can't see where (or understand why) it uses "pwd -P" Thanks. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 13:50:53 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 040021065670; Tue, 16 Aug 2011 13:50:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B7F008FC13; Tue, 16 Aug 2011 13:50:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 70DC446B3B; Tue, 16 Aug 2011 09:50:51 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0E11F8A02F; Tue, 16 Aug 2011 09:50:51 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 16 Aug 2011 09:25:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E3CC033.6070604@rawbw.com> <20110806091127.GA39951@freebsd.org> <4E3D808F.1030101@rawbw.com> In-Reply-To: <4E3D808F.1030101@rawbw.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108160925.20568.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 16 Aug 2011 09:50:51 -0400 (EDT) Cc: Yuri , Alexander Best Subject: Re: top(1) loses process user time count when threads end X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:50:53 -0000 On Saturday, August 06, 2011 1:57:35 pm Yuri wrote: > On 08/06/2011 02:11, Alexander Best wrote: > > On Fri Aug 5 11, Yuri wrote: > >> I have the process that first runs in 3 threads but later two active > >> threads exit. > >> > >> top(1) shows this moment this way (1 sec intervals): > >> 30833 yuri 3 76 0 4729M 4225M nanslp 4 0:32 88.62% app > >> 30833 yuri 3 76 0 4729M 4225M nanslp 6 0:34 90.92% app > >> 30833 yuri 1 96 0 4729M 4225M CPU1 1 0:03 1.17% app > >> 30833 yuri 1 98 0 4729M 4226M CPU1 1 0:04 12.89% app > >> > >> Process time goes down: 0:34 -> 0:03. Also WCPU goes down 90.92% -> > >> 1.17% even though this process is CPU bound and does intense things > >> right after threads exit. > >> > >> getrusage(2) though, called in the process, shows the correct user time. > >> > >> I think this is the major bug in the process time accounting. > > could you check, whether kern/128177 or kern/140892 describe your situation? > > I have ULE scheduler. kern/128177 talks about single thread with ULE > scheduler, and my issue is with threads. So I am not sure if it is > related. There have been no motion on kern/128177 since Feb 9, 2009. > kern/140892 is probably the same as mine. > > In any case, both these PRs have to be fixed since they are very user > visible, not just some obscure issues. You can try this perhaps: Index: kern/kern_thread.c =================================================================== --- kern/kern_thread.c (revision 224879) +++ kern/kern_thread.c (working copy) @@ -381,7 +381,7 @@ void thread_exit(void) { - uint64_t new_switchtime; + uint64_t runtime, new_switchtime; struct thread *td; struct thread *td2; struct proc *p; @@ -410,15 +410,6 @@ */ cpu_thread_exit(td); /* XXXSMP */ - /* Do the same timestamp bookkeeping that mi_switch() would do. */ - new_switchtime = cpu_ticks(); - p->p_rux.rux_runtime += (new_switchtime - PCPU_GET(switchtime)); - PCPU_SET(switchtime, new_switchtime); - PCPU_SET(switchticks, ticks); - PCPU_INC(cnt.v_swtch); - /* Save our resource usage in our process. */ - td->td_ru.ru_nvcsw++; - rucollect(&p->p_ru, &td->td_ru); /* * The last thread is left attached to the process * So that the whole bundle gets recycled. Skip @@ -467,7 +458,21 @@ PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_OUT); #endif PROC_UNLOCK(p); + + /* Do the same timestamp bookkeeping that mi_switch() would do. */ + new_switchtime = cpu_ticks(); + runtime = new_switchtime - PCPU_GET(switchtime); + td->td_runtime += runtime; + td->td_incruntime += runtime; + PCPU_SET(switchtime, new_switchtime); + PCPU_SET(switchticks, ticks); + PCPU_INC(cnt.v_swtch); + + /* Save our resource usage in our process. */ + td->td_ru.ru_nvcsw++; ruxagg(p, td); + rucollect(&p->p_ru, &td->td_ru); + thread_lock(td); PROC_SUNLOCK(p); td->td_state = TDS_INACTIVE; -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 13:59:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F03106564A; Tue, 16 Aug 2011 13:59:39 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD988FC18; Tue, 16 Aug 2011 13:59:38 +0000 (UTC) Received: by vxh11 with SMTP id 11so6204158vxh.13 for ; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6WUt/WSgWlmuqbdbVdiqYpapTTFdLcrmBeKSz9tbHW8=; b=obz6zlizDg0wdW+BTl2gRqSfoG7t3CGy9utNr/+pd/WKhoIDCQI+KVWM3wjGMWFC5w MkxnwQ+xL6p2v0cNfMCFWPPSIR7CBqojPf+QCYwB7uu2uKj4IzHk6B5KhGMZHMVp1iqv gMCIeNFppC4xPPzrkwUJQhPv6ObNwY1hM9d0E= MIME-Version: 1.0 Received: by 10.220.107.12 with SMTP id z12mr529082vco.129.1313503178417; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) Received: by 10.220.186.10 with HTTP; Tue, 16 Aug 2011 06:59:38 -0700 (PDT) In-Reply-To: References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> Date: Tue, 16 Aug 2011 09:59:38 -0400 Message-ID: From: Joe Schaefer To: ambrosehuang ambrose Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 13:59:39 -0000 On Tue, Aug 16, 2011 at 7:39 AM, ambrosehuang ambrose wrote: > > > 2011/8/16 Joe Schaefer >> >> FWIW here's a patch I needed to get buildworld to complete against head >> (as of today): >> >> Index: secure/libexec/ssh-keysign/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- secure/libexec/ssh-keysign/Makefile (revision 224899) >> +++ secure/libexec/ssh-keysign/Makefile (working copy) >> @@ -1,7 +1,7 @@ >> =C2=A0# $FreeBSD$ >> >> =C2=A0PROG=3D =C2=A0ssh-keysign >> -SRCS=3D =C2=A0ssh-keysign.c readconf.c roaming_dummy.c >> +SRCS=3D =C2=A0ssh-keysign.c buffer.c readconf.c roaming_dummy.c >> =C2=A0MAN=3D =C2=A0 ssh-keysign.8 >> =C2=A0CFLAGS+=3D-I${SSHDIR} -include ssh_namespace.h >> =C2=A0.if defined(ENABLE_SUID_SSH) >> Index: sys/dev/acpica/acpi_hpet.c >> >> >> On Mon, Aug 15, 2011 at 6:23 PM, Joe Schaefer wrote: >> > On Mon, Aug 15, 2011 at 5:47 PM, Joe Schaefer wrot= e: >> >> On Mon, Aug 15, 2011 at 5:23 PM, Alexander Motin >> >> wrote: >> >>> On 16.08.2011 00:13, Joe Schaefer wrote: >> >>>> >> >>>> On Mon, Aug 15, 2011 at 5:00 PM, Alexander Motin >> >>>> =C2=A0wrote: >> >>>>> >> >>>>> On 15.08.2011 23:57, Joe Schaefer wrote: >> >>>>>> >> >>>>>> On Mon, Aug 15, 2011 at 4:35 PM, Alexander Motin >> >>>>>> =C2=A0wrote: >> >>>>>>> >> >>>>>>> On 15.08.2011 22:18, Joe Schaefer wrote: >> >>>>>>>> >> >>>>>>>> On Mon, Aug 15, 2011 at 9:31 AM, Joe Schaefer >> >>>>>>>> =C2=A0wrote: >> >>>>>>>>> >> >>>>>>>>> On Mon, Aug 15, 2011 at 8:32 AM, Andriy Gapon >> >>>>>>>>> =C2=A0wrote: >> >>>>>>>>>> >> >>>>>>>>>> on 13/08/2011 20:16 Joe Schaefer said the following: >> >>>>>>>>>>> >> >>>>>>>>>>> Brand new machine with a Phenom II X6 1100T and under chroni= c >> >>>>>>>>>>> load >> >>>>>>>>>>> the clock will stop running periodically until the machine >> >>>>>>>>>>> eventually >> >>>>>>>>>>> completely >> >>>>>>>>>>> freezes. =C2=A0Note: during these stalls the kernel is still >> >>>>>>>>>>> running, >> >>>>>>>>>>> the >> >>>>>>>>>>> machine is still >> >>>>>>>>>>> mostly responsive, it's just that the clock is frozen in tim= e. >> >>>>>>>>>>> >> >>>>>>>>>>> I've disabled Turbo mode in the bios and toyed with just abo= ut >> >>>>>>>>>>> every >> >>>>>>>>>>> other setting but nothing seems to resolve this problem. >> >>>>>>>>>>> =C2=A0Based on >> >>>>>>>>>>> the >> >>>>>>>>>>> behavior >> >>>>>>>>>>> of the machine (just making buildworld will eventually kill >> >>>>>>>>>>> it, >> >>>>>>>>>>> upping >> >>>>>>>>>>> the -j flag >> >>>>>>>>>>> just kills it faster), I'm guessing it has something to do >> >>>>>>>>>>> with the >> >>>>>>>>>>> Digi+ VRM features >> >>>>>>>>>>> but again nothing I've tried modifying in the bios seems to >> >>>>>>>>>>> help. >> >>>>>>>>>>> >> >>>>>>>>>>> I've tried both 8.2-RELEASE and FreeBSD 9 (head). =C2=A0Runn= ing >> >>>>>>>>>>> head now >> >>>>>>>>>>> with >> >>>>>>>>>>> a dtrace enabled kernel. >> >>>>>>>>>>> >> >>>>>>>>>>> Suggestions? >> >>>>>>>>>> >> >>>>>>>>>> On head, start with checking what source is used for driving >> >>>>>>>>>> clocks: >> >>>>>>>>>> sysctl kern.eventtimer >> >>>>>>>>> >> >>>>>>>>> % sysctl kern.eventtimer >> >>>>>>>>> =C2=A0[master] >> >>>>>>>>> kern.eventtimer.choice: HPET(450) HPET1(450) HPET2(450) >> >>>>>>>>> LAPIC(400) >> >>>>>>>>> i8254(100) RTC(0) >> >>>>>>>>> kern.eventtimer.et.LAPIC.flags: 15 >> >>>>>>>>> kern.eventtimer.et.LAPIC.frequency: 0 >> >>>>>>>>> kern.eventtimer.et.LAPIC.quality: 400 >> >>>>>>>>> kern.eventtimer.et.HPET.flags: 3 >> >>>>>>>>> kern.eventtimer.et.HPET.frequency: 14318180 >> >>>>>>>>> kern.eventtimer.et.HPET.quality: 450 >> >>>>>>>>> kern.eventtimer.et.HPET1.flags: 3 >> >>>>>>>>> kern.eventtimer.et.HPET1.frequency: 14318180 >> >>>>>>>>> kern.eventtimer.et.HPET1.quality: 450 >> >>>>>>>>> kern.eventtimer.et.HPET2.flags: 3 >> >>>>>>>>> kern.eventtimer.et.HPET2.frequency: 14318180 >> >>>>>>>>> kern.eventtimer.et.HPET2.quality: 450 >> >>>>>>>>> kern.eventtimer.et.i8254.flags: 1 >> >>>>>>>>> kern.eventtimer.et.i8254.frequency: 1193182 >> >>>>>>>>> kern.eventtimer.et.i8254.quality: 100 >> >>>>>>>>> kern.eventtimer.et.RTC.flags: 17 >> >>>>>>>>> kern.eventtimer.et.RTC.frequency: 32768 >> >>>>>>>>> kern.eventtimer.et.RTC.quality: 0 >> >>>>>>>>> kern.eventtimer.periodic: 0 >> >>>>>>>>> kern.eventtimer.timer: HPET >> >>>>>>>> >> >>>>>>>> =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >>>>>>>> Changing this to "i8254" seems to have resolved the stalls. >> >>>>>>>> I'm running buildworld -j12 without issue. =C2=A0More than will= ing >> >>>>>>>> to test out a patch or two against head if anyone's still >> >>>>>>>> interested, otherwise I've thrown the change into loader.conf >> >>>>>>>> and will move along quietly. >> >>>>>>> >> >>>>>>> 8.2-RELEASE you've mentioned doesn't have event timers subsystem >> >>>>>>> and >> >>>>>>> HPET >> >>>>>>> timer driver. That makes me think it is strange at least. Can yo= u >> >>>>>>> try >> >>>>>>> also >> >>>>>>> LAPIC timer and do alike experiments with kern.timeocunter? >> >>>>>> >> >>>>>> My problems with 8.2-RELEASE may have been network based. =C2=A0I= don't >> >>>>>> recall >> >>>>>> precisely if the clock was stalling there, my guess is no based o= n >> >>>>>> what you wrote. >> >>>>>> >> >>>>>> I'll test LAPIC next ... so far so good. =C2=A0Just so I'm clear,= you'd >> >>>>>> like me to tweak >> >>>>>> kern.timecounter.hardware as well? =C2=A0(Currently it's HPET). >> >>>>> >> >>>>> Yes. Instead. Ticking clock depends on both timecounter and >> >>>>> eventtimer. >> >>>> >> >>>> Haven't found a combination that hangs my machine other than with t= he >> >>>> eventtimer at HPET. >> >>> >> >>> I mean trying eventtimer HPET and different timecounters. >> >> >> >> Doesn't seem to help. =C2=A0Eventtimer HPET and timecounter ACPI-fast= still >> >> stalls. >> >> >> >>> >> >>> If changing timecounter won't help, try please this patch: >> >>> >> >>> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +020= 0 >> >>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 >> >>> @@ -190,7 +190,7 @@ restart: >> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(s= c->mem_res, HPET_TIMER_COMPARATOR(t->num), >> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0t->next); >> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >> >>> - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) { >> >>> + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) { >> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(sc= ->mem_res, HPET_TIMER_COMPARATOR(t->num)); >> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_r= ead_4(sc->mem_res, HPET_MAIN_COUNTER); >> >>> >> >>> -- >> >>> Alexander Motin >> >> >> >> Will do next. >> >> >> > >> > Patch applied. Running with HPET eventtimer and no stalls during >> > make buildworld -j12. >> > > > it maybe help, I used to come across a bug on Linux with regard to HPET, > some northbridge chipset (maybe amd's, where > HPET sit on)=C2=A0has a problem, that writes to =C2=A0compatitor regs wil= l not take > effect immediately, you need a read to reg to flush it; So far the patch performs flawlessly for me. I'm tempted to reenable turbo mode just for kicks (someday, not today- delighted with the uptime!) From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 14:42:57 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE1031065677 for ; Tue, 16 Aug 2011 14:42:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEEE8FC0C for ; Tue, 16 Aug 2011 14:42:56 +0000 (UTC) Received: by bkat8 with SMTP id t8so4915697bka.13 for ; Tue, 16 Aug 2011 07:42:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=CQEA4ShoiTiogCAeKOK7eURUrZqglN8wHSuYUsWGKg8=; b=vb83Ti8DJl2JAgZsUOtdfQtSc3y9EnNsUpmByGyxot9BKd2BIaGMtGCiN/1uCaowQx +nW6Z+0RX5fTfGU03fJl/E5GQ3mG0DahwvTm4oUFmz75tizgie1PDP/oRR3JjW9ouUVh C4JLnaR1D5YzpFfweGRwv2inZJzaHuRF5ThCU= Received: by 10.204.182.1 with SMTP id ca1mr1191976bkb.328.1313505776216; Tue, 16 Aug 2011 07:42:56 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p12sm43894bkp.1.2011.08.16.07.42.52 (version=SSLv3 cipher=OTHER); Tue, 16 Aug 2011 07:42:53 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E4A81DD.3030202@FreeBSD.org> Date: Tue, 16 Aug 2011 17:42:37 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Joe Schaefer References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:42:58 -0000 Joe Schaefer wrote: >>>>>> If changing timecounter won't help, try please this patch: >>>>>> >>>>>> --- acpi_hpet.c.prev 2010-12-25 11:28:45.000000000 +0200 >>>>>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 >>>>>> @@ -190,7 +190,7 @@ restart: >>>>>> bus_write_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num), >>>>>> t->next); >>>>>> } >>>>>> - if (fdiv < 5000) { >>>>>> + if (1 || fdiv < 5000) { >>>>>> bus_read_4(sc->mem_res, HPET_TIMER_COMPARATOR(t->num)); >>>>>> now = bus_read_4(sc->mem_res, HPET_MAIN_COUNTER); >>>>>> >>>>>> -- >>>>>> Alexander Motin >>>>> Will do next. >>>>> >>>> Patch applied. Running with HPET eventtimer and no stalls during >>>> make buildworld -j12. >>>> >> it maybe help, I used to come across a bug on Linux with regard to HPET, >> some northbridge chipset (maybe amd's, where >> HPET sit on) has a problem, that writes to compatitor regs will not take >> effect immediately, you need a read to reg to flush it; > > So far the patch performs flawlessly for me. I'm tempted to reenable turbo > mode just for kicks (someday, not today- delighted with the uptime!) I am going to commit following patch: http://people.freebsd.org/~mav/hpet.paranoid.patch . It uses same assumptions as Linux. Try it please. -- Alexander Motin From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 16:04:03 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59844106566C; Tue, 16 Aug 2011 16:04:03 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EC4728FC15; Tue, 16 Aug 2011 16:04:02 +0000 (UTC) Received: by vxh11 with SMTP id 11so60881vxh.13 for ; Tue, 16 Aug 2011 09:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OTFixKda/ANkZKbhy/r1i9eX9aWpomzXbUaPl7evfrY=; b=Ku+8gHPUCA3yxaZaFCb9HQyGd5uS0UUUgNQE0b2YjuOf8Xhz2/gXzmsZ8oGkDISf0m 6O1q1D8/cae2wIIxqdrS6YGdIgoKQOqrTE31mbh+cIVib/3HSqvQ9H0R/u9FaKTv/Hi+ jP0L35CEhmrzDA7c118lZ7CNCO4tXWiR/tptw= MIME-Version: 1.0 Received: by 10.220.107.12 with SMTP id z12mr575386vco.129.1313510642194; Tue, 16 Aug 2011 09:04:02 -0700 (PDT) Received: by 10.220.186.10 with HTTP; Tue, 16 Aug 2011 09:04:02 -0700 (PDT) In-Reply-To: <4E4A81DD.3030202@FreeBSD.org> References: <4E498326.2060308@FreeBSD.org> <4E4988F0.7060000@FreeBSD.org> <4E498E3D.7050100@FreeBSD.org> <4E4A81DD.3030202@FreeBSD.org> Date: Tue, 16 Aug 2011 12:04:02 -0400 Message-ID: From: Joe Schaefer To: Alexander Motin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hackers@freebsd.org Subject: Re: Clock stalls on Sabertooth 990FX X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:04:03 -0000 On Tue, Aug 16, 2011 at 10:42 AM, Alexander Motin wrote: > Joe Schaefer wrote: >>>>>>> If changing timecounter won't help, try please this patch: >>>>>>> >>>>>>> --- acpi_hpet.c.prev =C2=A0 =C2=A02010-12-25 11:28:45.000000000 +02= 00 >>>>>>> +++ acpi_hpet.c 2011-05-11 14:30:59.000000000 +0300 >>>>>>> @@ -190,7 +190,7 @@ restart: >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_write_4(= sc->mem_res, HPET_TIMER_COMPARATOR(t->num), >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0t->next); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0} >>>>>>> - =C2=A0 =C2=A0 =C2=A0 if (fdiv < 5000) { >>>>>>> + =C2=A0 =C2=A0 =C2=A0 if (1 || fdiv < 5000) { >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bus_read_4(s= c->mem_res, HPET_TIMER_COMPARATOR(t->num)); >>>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0now =3D bus_= read_4(sc->mem_res, HPET_MAIN_COUNTER); >>>>>>> >>>>>>> -- >>>>>>> Alexander Motin >>>>>> Will do next. >>>>>> >>>>> Patch applied. Running with HPET eventtimer and no stalls during >>>>> make buildworld -j12. >>>>> >>> it maybe help, I used to come across a bug on Linux with regard to HPET= , >>> some northbridge chipset (maybe amd's, where >>> HPET sit on) has a problem, that writes to =C2=A0compatitor regs will n= ot take >>> effect immediately, you need a read to reg to flush it; >> >> So far the patch performs flawlessly for me. =C2=A0I'm tempted to reenab= le turbo >> mode just for kicks (someday, not today- delighted with the uptime!) > > I am going to commit following patch: > http://people.freebsd.org/~mav/hpet.paranoid.patch > . It uses same assumptions as Linux. Try it please. +1 to apply: (tested with buildworld -j18) -------------------------------------------------------------- >>> World build completed on Tue Aug 16 12:02:20 EDT 2011 -------------------------------------------------------------- 5255.533u 2443.815s 30:28.62 421.0% 6535+4429k 0+0io 223826pf+0w sextant# uname -a FreeBSD sextant.sunstarsys.com 9.0-BETA1 FreeBSD 9.0-BETA1 #1 r224899M: Tue Aug 16 10:55:12 EDT 2011 joe@sextant.sunstarsys.com:/usr/obj/usr/src/sys/DTRACE amd64 sextant# uptime 12:02PM up 32 mins, 3 users, load averages: 6.90, 12.58, 10.64 > > -- > Alexander Motin > From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 18:14:31 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EC51065672 for ; Tue, 16 Aug 2011 18:14:31 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id EE4E98FC18 for ; Tue, 16 Aug 2011 18:14:30 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p7GHpo1J015618; Tue, 16 Aug 2011 19:51:50 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Tue, 16 Aug 2011 19:51:47 +0200 User-Agent: KMail/1.9.10 References: <4E4A5DFC.7010807@icritical.com> In-Reply-To: <4E4A5DFC.7010807@icritical.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201108161951.48553.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Matt Burke Subject: Re: Alternate source trees X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 18:14:31 -0000 On Tuesday 16 August 2011 14:09:32 Matt Burke wrote: > I'm trying to setup a box to do automated FreeBSD builds for other hosts > from multiple source trees. > > I have a couple of source trees mounted - for legibility's sake let's say > /build/stable and /build/current. I also have a few obj dirs for different > targets. The current obj tree is symlinked to /usr/obj, and this works > fine. > > The problem comes when I symlink /usr/src: when I buildworld, I get > /usr/obj/build/current/[...] instead of the desired /usr/obj/usr/src/[...] > This is presumably fine when installing on the same machine, but it breaks > when using it on another host with /usr/src and /usr/obj mounted over nfs. > > The only way I can see around this is a hack using a nullfs mount of > /usr/src instead of a symlink. > > Am I missing something? An environment variable perhaps? > > How does the build process know about the non-symlinked path anyway? I > can't see where (or understand why) it uses "pwd -P" If you use make installworld && make installkernel on the client, then you must recreate the exact directories on the client as used on the build server. So you would probably need to mount /build as well on the client. Note that you can also do the installworld/installkernel part on the build server, by using DESTDIR to point to the client's (NFS mounted) root directory. This method has the advantage that it works regardless of the state of the client (NFS still has to work of course). - Pieter From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 20:37:00 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDEA31065670 for ; Tue, 16 Aug 2011 20:37:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8DE8FC0C for ; Tue, 16 Aug 2011 20:37:00 +0000 (UTC) Received: by fxe4 with SMTP id 4so322855fxe.13 for ; Tue, 16 Aug 2011 13:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.62.76 with SMTP id w12mr135918fah.123.1313525414576; Tue, 16 Aug 2011 13:10:14 -0700 (PDT) Received: by 10.223.74.143 with HTTP; Tue, 16 Aug 2011 13:10:14 -0700 (PDT) X-Originating-IP: [216.223.13.122] Date: Tue, 16 Aug 2011 16:10:14 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: glabel on 9-BETA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 20:37:01 -0000 All I was testing out an old bug and I am not sure if there is any known work-around on 9-BETA/HEAD Here is the issue. Install a new server , have it boot into multi-user mode. Then attempt to use glabel to label the root slice root@blindness:~# glabel label rootfs ada0p4 glabel: Can't store metadata on ada0p4: Operation not permitted. In 7.2 and prior there was a sysctl that could be tweaked to allow for this to work , kern.geom.debugflag set to 16 would allow this to work. So my question is this. Should there be any reason why "glabel label name device" on the root slice cause an issue when the slice is mounted rw ? Is this a bug ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 21:01:41 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41E1F1065674 for ; Tue, 16 Aug 2011 21:01:41 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1C758FC12 for ; Tue, 16 Aug 2011 21:01:40 +0000 (UTC) Received: by fxe4 with SMTP id 4so339211fxe.13 for ; Tue, 16 Aug 2011 14:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=CS8TI2dhDdtTlrXUTbaLqGsHEw0mDvhZOcuesagC7s4=; b=IfDv9QaJtl4XJ934HNyh8wIJuTofukTYGwdeGtG0aE7/54qdfbDX3ov+Skw1vIcno0 nFYvd/lyV4PVvVwJ9sj7aERYnu5NdqvD5SKoKbhs6OCKaUBB8kgdGagx3+w0k4f/lUJc z0ASrBw86BOEbtMV80ICmvsLwL1J+9qVlbFZc= Received: by 10.223.149.199 with SMTP id u7mr196642fav.129.1313528499601; Tue, 16 Aug 2011 14:01:39 -0700 (PDT) Received: from localhost (tor-exit.no-ip.org [80.79.23.92]) by mx.google.com with ESMTPS id f12sm343308fai.1.2011.08.16.14.01.37 (version=SSLv3 cipher=OTHER); Tue, 16 Aug 2011 14:01:39 -0700 (PDT) From: Test Rat To: Mark Saad References: Date: Wed, 17 Aug 2011 01:01:28 +0400 In-Reply-To: (Mark Saad's message of "Tue, 16 Aug 2011 16:10:14 -0400") Message-ID: <86wred136f.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Re: glabel on 9-BETA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:01:41 -0000 Mark Saad writes: > All > I was testing out an old bug and I am not sure if there is any known > work-around on 9-BETA/HEAD > > Here is the issue. Install a new server , have it boot into > multi-user mode. Then attempt to use glabel to label the root slice > > root@blindness:~# glabel label rootfs ada0p4 > glabel: Can't store metadata on ada0p4: Operation not permitted. > > In 7.2 and prior there was a sysctl that could be tweaked to allow for > this to work , kern.geom.debugflag set to 16 would allow this to work. > > So my question is this. Should there be any reason why "glabel label > name device" on the root slice cause an issue > when the slice is mounted rw ? > > Is this a bug ? It's a known feature[1], see geom(4) or try below diff. [1] http://lists.freebsd.org/pipermail/freebsd-fs/2010-April/008290.html %% Index: sys/geom/geom_subr.c =================================================================== --- sys/geom/geom_subr.c (revision 224657) +++ sys/geom/geom_subr.c (working copy) @@ -807,7 +819,7 @@ g_access(struct g_consumer *cp, int dcr, int dcw, pp, pp->name); /* If foot-shooting is enabled, any open on rank#1 is OK */ - if ((g_debugflags & 16) && pp->geom->rank == 1) + if ((g_debugflags & 16)) ; /* If we try exclusive but already write: fail */ else if (dce > 0 && pw > 0) %% From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 21:15:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43B211065675 for ; Tue, 16 Aug 2011 21:15:22 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB4728FC1F for ; Tue, 16 Aug 2011 21:15:21 +0000 (UTC) Received: by fxe4 with SMTP id 4so347745fxe.13 for ; Tue, 16 Aug 2011 14:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.62.76 with SMTP id w12mr213995fah.123.1313529320770; Tue, 16 Aug 2011 14:15:20 -0700 (PDT) Received: by 10.223.74.143 with HTTP; Tue, 16 Aug 2011 14:15:20 -0700 (PDT) X-Originating-IP: [216.223.13.122] In-Reply-To: <86wred136f.fsf@gmail.com> References: <86wred136f.fsf@gmail.com> Date: Tue, 16 Aug 2011 17:15:20 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: glabel on 9-BETA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 21:15:22 -0000 On Tue, Aug 16, 2011 at 5:01 PM, Test Rat wrote: > Mark Saad writes: > >> All >> =C2=A0I was testing out an old bug and I am not sure if there is any kno= wn >> work-around on 9-BETA/HEAD >> >> Here is the =C2=A0issue. =C2=A0Install a new server , have it boot into >> multi-user mode. Then attempt to use glabel to label the root slice >> >> root@blindness:~# glabel label rootfs ada0p4 >> glabel: Can't store metadata on ada0p4: Operation not permitted. >> >> In 7.2 and prior there was a sysctl that could be tweaked to allow for >> this to work , kern.geom.debugflag set to 16 would allow this to work. >> >> So my question is this. Should there be any reason why "glabel label >> name device" on the root slice cause an issue >> when the slice is mounted rw ? >> >> Is this a bug ? > > It's a known feature[1], see geom(4) or try below diff. > > [1] http://lists.freebsd.org/pipermail/freebsd-fs/2010-April/008290.html > > %% > Index: sys/geom/geom_subr.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/geom/geom_subr.c =C2=A0 =C2=A0 =C2=A0 =C2=A0(revision 224657) > +++ sys/geom/geom_subr.c =C2=A0 =C2=A0 =C2=A0 =C2=A0(working copy) > @@ -807,7 +819,7 @@ g_access(struct g_consumer *cp, int dcr, int dcw, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pp, pp->name); > > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If foot-shooting is enabled, any open on ra= nk#1 is OK */ > - =C2=A0 =C2=A0 =C2=A0 if ((g_debugflags & 16) && pp->geom->rank =3D=3D 1= ) > + =C2=A0 =C2=A0 =C2=A0 if ((g_debugflags & 16)) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; > =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If we try exclusive but already write: fail= */ > =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (dce > 0 && pw > 0) > %% > Ok so I am not using glabel as it was originally designed or intended but I was / am using in it in production to label slices. IMHO it works very well for doing this. Here is an example from a 7.3-RELEASE servers of how I am using it. [root@wfmu2~]# glabel list Geom name: da1s1 Providers: 1. Name: label/mysql/data Mediasize: 146778668544 (137G) Sectorsize: 512 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 286677087 length: 146778668544 index: 0 Consumers: 1. Name: da1s1 Mediasize: 146778669056 (137G) Sectorsize: 512 Mode: r1w1e2 Geom name: da0s1a Providers: 1. Name: label/rootfs Mediasize: 140336217600 (131G) Sectorsize: 512 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 274094175 length: 140336217600 index: 0 Consumers: 1. Name: da0s1a Mediasize: 140336218112 (131G) Sectorsize: 512 Mode: r1w1e2 Geom name: da0s1b Providers: 1. Name: label/SWAP Mediasize: 2147483136 (2.0G) Sectorsize: 512 Mode: r1w1e0 secoffset: 0 offset: 0 seclength: 4194303 length: 2147483136 index: 0 Consumers: 1. Name: da0s1b Mediasize: 2147483648 (2.0G) Sectorsize: 512 Mode: r1w1e1 Geom name: da0s1d Providers: 1. Name: label/var Mediasize: 4294966784 (4.0G) Sectorsize: 512 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 8388607 length: 4294966784 index: 0 Consumers: 1. Name: da0s1d Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e2 So what I am getting at is in 9 I can not label the system in the same way. So this may be a limitation of GPT but I am not sure . The reason why I was doing this is to use a standard format for fstab . Every server gets the same starting point Here is the fstab from the same server # Device Mountpoint FStype Options Dump Pas= s# /dev/label/rootfs / ufs rw 1 1 /dev/label/var /var ufs rw 2 2 /dev/label/SWAP none swap sw 0 0 /dev/label/mysql/data /usr/local/mysql ufs rw 1 1 Is there any reason I can not do this in 9, is it just GPT thats preventing this ? --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 22:01:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C156A106566B for ; Tue, 16 Aug 2011 22:01:08 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 844598FC08 for ; Tue, 16 Aug 2011 22:01:08 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p7GLojXT023036 for ; Tue, 16 Aug 2011 14:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1313531445; bh=IOc6uHKvTWmi1lFkej8yRgW1wKsn3XQQIMwpghXQneo=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version: Content-Transfer-Encoding; b=EF9OSDpkuA28nM7gjFLOkzgq95wrOw7KDlTk0TBuGQFon3lfHRUg37l8r4Ww7uzfV xKvADlwv3Xypk979r6HlRNOe3CwguOsg1bdhPZc7B/69/3pJaabvOPNYEewlNEU7yz 04orH0DpyOmY9KsKgYVDc4aQCmYv+DHGtqiaE+Go= From: Sean Bruno To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Tue, 16 Aug 2011 14:50:45 -0700 Message-ID: <1313531445.3828.1.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Subject: building my own release images from -CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:01:08 -0000 Just trying some hackery with building my own release images from -CURRENT today. I've built world and my kernel, when I enter release and "make memstick" I get the following: ** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to the temproot environment *** Error code 1 Stop in /dumpster/scratch/sbruno-scratch/test/release. From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 22:15:47 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74E6E1065672 for ; Tue, 16 Aug 2011 22:15:47 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 07B018FC08 for ; Tue, 16 Aug 2011 22:15:46 +0000 (UTC) Received: by fxe4 with SMTP id 4so382766fxe.13 for ; Tue, 16 Aug 2011 15:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=G3LAFvV72j2ScvMOtcdANiJq5bnT7TwZE0ig6t7Sg88=; b=XuTkIkzLh1/kKN/r4ilGMbWHVS5qApqSLxrairCefbJJxTz5o1J14Z2+TMX4utx59B 0jaKNrd2BaJ6hSLA+HH+OSBa+lmmMtJ5tV6Rb89713puMI7Eh9hdUXiODLhWpsGb6F+g buhFGnXR2i7MCN35CDsntBFKfdaB4db9c1pfA= Received: by 10.223.2.139 with SMTP id 11mr302258faj.102.1313532945923; Tue, 16 Aug 2011 15:15:45 -0700 (PDT) Received: from localhost (tor-exit-router36-readme.formlessnetworking.net [199.48.147.36]) by mx.google.com with ESMTPS id b14sm380083fab.43.2011.08.16.15.15.42 (version=SSLv3 cipher=OTHER); Tue, 16 Aug 2011 15:15:45 -0700 (PDT) From: Test Rat To: Sean Bruno References: <1313531445.3828.1.camel@hitfishpass-lx.corp.yahoo.com> Date: Wed, 17 Aug 2011 02:15:27 +0400 In-Reply-To: <1313531445.3828.1.camel@hitfishpass-lx.corp.yahoo.com> (Sean Bruno's message of "Tue, 16 Aug 2011 14:50:45 -0700") Message-ID: <86y5yt0zr4.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: "freebsd-hackers@freebsd.org" Subject: Re: building my own release images from -CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:15:47 -0000 Sean Bruno writes: > Just trying some hackery with building my own release images from > -CURRENT today. > > I've built world and my kernel, when I enter release and "make memstick" > I get the following: > > ** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot > > > *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to > the temproot environment > > *** Error code 1 > > Stop in /dumpster/scratch/sbruno-scratch/test/release. Where points /usr/src? Have you tried the patch in misc/159666 ? From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 16 22:56:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10406106566B for ; Tue, 16 Aug 2011 22:56:52 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCD2C8FC18 for ; Tue, 16 Aug 2011 22:56:51 +0000 (UTC) Received: by vxh11 with SMTP id 11so510841vxh.13 for ; Tue, 16 Aug 2011 15:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=CP9qcADbxHgHYobsjVJIutLzobDqdMQ34MIE+WeVZw0=; b=EKM15bfcQPJGoAMTEQd6sEgl1XbdJmAbnJW3WHD41c4dhscVF/olFzRAWMdnkEQtuw Bp8g/+DjtZlAD6gtx6mZ4Qtir6K7xPg56ZqDJEbaEkIAwRKgFk14FJ69qgy1kdotFrWY Cj2ZQvIVbc2xSzPEhRKc1RudK1X5JeLlV9sz4= Received: by 10.220.25.206 with SMTP id a14mr85340vcc.98.1313535410376; Tue, 16 Aug 2011 15:56:50 -0700 (PDT) Received: from localhost (UNCLE-ENZO.MIT.EDU [18.238.1.85]) by mx.google.com with ESMTPS id fp6sm372025vcb.6.2011.08.16.15.56.47 (version=SSLv3 cipher=OTHER); Tue, 16 Aug 2011 15:56:49 -0700 (PDT) From: Test Rat To: Zhihao Yuan References: Date: Wed, 17 Aug 2011 02:56:43 +0400 In-Reply-To: (Zhihao Yuan's message of "Sun, 14 Aug 2011 15:06:00 -0500") Message-ID: <868vqt0xuc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: freebsd-hackers@freebsd.org Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:56:52 -0000 Zhihao Yuan writes: > On Sun, Aug 14, 2011 at 10:39 AM, Zhihao Yuan wrote: >> Hi, hackers: >> >> My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for >> testing. The proposal of the project is here: >> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 [...] > Let me try to ``quickly'' explain how to involve into the testing. > > First, download the patch from > https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-14.diff.gz It breaks buildworld for me, e.g. $ make all -C share/termcap gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder Error: stderr: Inappropriate ioctl for device script, 3: Destination line is inside move range *** Error code 1 and crashes when no WITH_ICONV is defined. Can you confirm? Starting program: /usr/bin/ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder Program received signal SIGSEGV, Segmentation fault. 0x0000000800be7760 in ?? () (gdb) bt #0 0x0000000800be7760 in ?? () #1 0x000000000044092b in ex_writefp (sp=0x801106800, name=0x801103148 "termcap", fp=0x800e51d90, fm=0x801007ca8, tm=0x801007cb8, nlno=0x7fffffffc808, nch=0x7fffffffc800, silent=0) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:321 #2 0x000000000040bfb2 in file_write (sp=0x801106800, fm=0x801007ca8, tm=0x801007cb8, name=0x801103148 "termcap", flags=21) at /usr/src/usr.bin/vi/../../contrib/nvi2/common/exf.c:924 #3 0x0000000000440739 in exwr (sp=0x801106800, cmdp=0x801007be8, cmd=WRITE) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:264 #4 0x00000000004400d2 in ex_write (sp=0x801106800, cmdp=0x801007be8) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:91 #5 0x0000000000422b78 in ex_cmd (sp=0x801106800) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex.c:1375 #6 0x000000000041f788 in ex (spp=0x7fffffffd040) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex.c:133 #7 0x0000000000412377 in editor (gp=0x801007b00, argc=1, argv=0x7fffffffd268) at /usr/src/usr.bin/vi/../../contrib/nvi2/common/main.c:424 #8 0x000000000040513f in main (argc=3, argv=0x7fffffffd258) at /usr/src/usr.bin/vi/../../contrib/nvi2/cl/cl_main.c:123 (gdb) bt f #0 0x0000000800be7760 in ?? () No symbol table info available. #1 0x000000000044092b in ex_writefp (sp=0x801106800, name=0x801103148 "termcap", fp=0x800e51d90, fm=0x801007ca8, tm=0x801007cb8, nlno=0x7fffffffc808, nch=0x7fffffffc800, silent=0) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:321 sb = { st_dev = 4294955600, st_ino = 32767, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 1944, st_rdev = 0, st_atim = { tv_sec = 3, tv_nsec = 34377892735 }, st_mtim = { tv_sec = 6798080, tv_nsec = 4096 }, st_ctim = { tv_sec = 0, tv_nsec = 34366769152 }, st_size = 4, st_blocks = 140737488343672, st_blksize = 3, st_flags = 0, st_gen = 4294954160, st_lspare = 32767, st_birthtim = { tv_sec = 34366543277, tv_nsec = 582 } } gp = (GS *) 0x801007b00 ccnt = 0 fline = 1 tline = 4666 lcnt = 0 len = 140737488340496 rval = -11656 msg = 0x46f540 "253|Writing..." p = (CHAR_T *) 0xb f = 0x800c0981f "H\211A^]\017\037\204" flen = 140737488340168 isutf16 = 0 #2 0x000000000040bfb2 in file_write (sp=0x801106800, fm=0x801007ca8, tm=0x801007cb8, name=0x801103148 "termcap", flags=21) at /usr/src/usr.bin/vi/../../contrib/nvi2/common/exf.c:924 mtype = OLDFILE sb = { st_dev = 745804815, st_ino = 70073, st_mode = 33188, st_nlink = 1, st_uid = 1001, st_gid = 1001, st_rdev = 4294967295, st_atim = { tv_sec = 1313534959, tv_nsec = 905174484 }, st_mtim = { tv_sec = 1313535150, tv_nsec = 420174354 }, st_ctim = { tv_sec = 1313535150, tv_nsec = 420174354 }, st_size = 0, st_blocks = 1, st_blksize = 131072, st_flags = 0, st_gen = 0, st_lspare = 0, st_birthtim = { tv_sec = 1313535150, tv_nsec = 420174354 } } ep = (EXF *) 0x801031180 fp = (FILE *) 0x800e51d90 frp = (FREF *) 0x80112f040 from = { lno = 4294953320, cno = 140737488341984 } to = { lno = 17842464, cno = 140737488341096 } len = 1 nlno = 0 nch = 0 fd = 11 nf = 18607849 noname = 0 oflags = 1537 rval = 0 p = 0x800b87f54 "»\001" s = 0x7fffffffc830 "" t = 0x80118b240 "" buf = "\000»g\000\000\000\000\000q000\b\000\000\000«\002\000\000\000\000\000\000\001\b\000\000\000\000\000\000\004\000\000\000\000\000\000\000h»g\000\000\000\000\000\033\001\000\000\000\000\000`\004\000\000\000\000\000\000»g\000\000\000\000\000\001\000\000\000\000\000\000\000\000°*\001\b\000\000\000\000»g\000\000\000\000\000\000`\004\000\000\000\000\000\000(\000\000\000\000\000\000\020ÿÿ\177\000\000\227000\b\000\000\000h»g", '\0' , "\020ÿÿ\177\000\000[\214À\000\b\000\000\000\000 !\001\b\000\000\000( !\001\b\000\000\000\000\017\023\001\b\000\000\000  !\001\b\000\000\000@ÿÿ\177\000\000\036wÀ"... msgstr = 0x2 #3 0x0000000000440739 in exwr (sp=0x801106800, cmdp=0x801007be8, cmd=WRITE) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:264 rm = { lno = 17846452, cno = 4 } flags = 21 name = 0x801103148 "termcap" p = (CHAR_T *) 0x801103088 "termcap" nlen = 8 n = 0x801103140 "termcap" rc = 4260867 #4 0x00000000004400d2 in ex_write (sp=0x801106800, cmdp=0x801007be8) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:91 No locals. #5 0x0000000000422b78 in ex_cmd (sp=0x801106800) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex.c:1375 nret = 17852416 exp = (EX_PRIVATE *) 0x8010f3600 ecp = (EXCMD *) 0x801007be8 gp = (GS *) 0x801007b00 cur = { lno = 185, cno = 0 } lno = 1 arg1_len = 0 discard = 0 len = 140737488342608 flags = 0 ltmp = 1 at_found = 0 gv_found = 24 cnt = 8 delim = 16808704 isaddr = 1 namelen = 1 newscreen = 0 notempty = 0 tmp = 0 vi_address = 1 arg1 = (CHAR_T *) 0x0 s = (CHAR_T *) 0x801153143 "termcap" p = (CHAR_T *) 0x80115314b "-m'a" t = (CHAR_T *) 0x7fffffffd250 "\003" ch = 112 'p' n = (CHAR_T *) 0x7 np = 0x46a8b9 "s" #6 0x000000000041f788 in ex (spp=0x7fffffffd040) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex.c:133 exp = (EX_PRIVATE *) 0x8010f3600 gp = (GS *) 0x801007b00 mp = (MSGS *) 0x0 sp = (SCR *) 0x801106800 tp = (TEXT *) 0x801151080 flags = 2592 space = 32 ' ' #7 0x0000000000412377 in editor (gp=0x801007b00, argc=1, argv=0x7fffffffd268) at /usr/src/usr.bin/vi/../../contrib/nvi2/common/main.c:424 p = 0x7fffffff037f "" ev = { q = { tqe_next = 0x40150c, tqe_prev = 0x7fffffffd008 }, e_event = 98, _u_event = { _e_ch = { c = 58 ':', value = K_NOTUSED, flags = 58 ':' }, _e_mark = { lno1 = 4201018, cno1 = 4201018, lno2 = 226154414, cno2 = 34366783664 }, _e_str = { asp = 0x401a3a "sigaction", csp = 0x401a3a "sigaction", len = 226154414 } } } frp = (FREF *) 0x80112f040 sp = (SCR *) 0x801106800 len = 0 flags = 1 ch = -1 flagchk = 0 lflag = 0 secure = 0 startup = 1 readonly = 0 rval = 6813300 silent = 1 tag_f = 0x0 wsizearg = 0x0 path = "xÿÿ\177\000\000\003\000\000\000\000\000\000\000Pÿÿ\177\000\000­\000\b\000\000\000\000»g\000\000\000\000\000\000P\004\001\b\000\000\000\000\020\000\000\000\000\000\000\000\020\000\000\000\000\000\000\001\000\000\000\000\000\000\0000ÿÿ\177\00---Type to continue, or q to quit--- 0\000\0005000\b\000\000\000204\002\001\b", '\0' , "\006\002\000\000\000\000\000\000\000»g\000\000\000\000\000\000@k\000\b\000\000\000222À\000\b\000\000\000\017W@\000\000\000\000\000°ºg\000\000\000\000\000@\000\000\000\000\000H\205\002\001\b\000\000\000\000P\004\001\034\000\000\000@", '\0' , "\b\000\000\000\220ÿÿ\177\000\000"... w = (CHAR_T *) 0x7fffffffcff8 "g" wlen = 34366767104 #8 0x000000000040513f in main (argc=3, argv=0x7fffffffd258) at /usr/src/usr.bin/vi/../../contrib/nvi2/cl/cl_main.c:123 clp = (CL_PRIVATE *) 0x801028300 gp = (GS *) 0x801007b00 rows = 24 cols = 132 rval = 32767 p_av = (char **) 0x7fffffffd270 t_av = (char **) 0x7fffffffd270 ttype = 0x7fffffffd6ab "screen-256color" reenter = 1 From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 04:17:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C2201065672 for ; Wed, 17 Aug 2011 04:17:17 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [IPv6:2a02:6b8:0:801::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB388FC0A for ; Wed, 17 Aug 2011 04:17:16 +0000 (UTC) Received: from smtp12.mail.yandex.net (smtp12.mail.yandex.net [95.108.131.191]) by forward11.mail.yandex.net (Yandex) with ESMTP id 02F54E80AC1; Wed, 17 Aug 2011 08:17:13 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1313554634; bh=/QuO3Uz/0TmnD4/cR8vw3SSrfayYBdJdx3qh8uBHPhA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Mbm/p0ddEyV1uNw5WlmRm9/0BIPsK1nZDTY7ay3iBd7C9Fdzni3A4/sG0LGIa6uGD Adh9vuhwKKmveMskoFaEAHE/8rPUTFYEicTjdUOX7KpmvSXxpbiCytcijOv0XkXuWn S2ZUi7xb+bK7JwHt17aCNHq8lnzunZNs1+O3qc4c= Received: from smtp12.mail.yandex.net (localhost [127.0.0.1]) by smtp12.mail.yandex.net (Yandex) with ESMTP id DF06616A03AD; Wed, 17 Aug 2011 08:17:13 +0400 (MSD) Received: from mail.kirov.so-ups.ru (mail.kirov.so-ups.ru [178.74.170.1]) by smtp12.mail.yandex.net (nwsmtp/Yandex) with ESMTP id HDwmiCDX; Wed, 17 Aug 2011 08:17:13 +0400 X-Yandex-Spam: 1 Message-ID: <4E4B40C4.6080608@yandex.ru> Date: Wed, 17 Aug 2011 08:17:08 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Mark Saad References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig53ED216EFC659D8746029286" Cc: freebsd-hackers@freebsd.org Subject: Re: glabel on 9-BETA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 04:17:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53ED216EFC659D8746029286 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 17.08.2011 0:10, Mark Saad wrote: > root@blindness:~# glabel label rootfs ada0p4 > glabel: Can't store metadata on ada0p4: Operation not permitted. >=20 > In 7.2 and prior there was a sysctl that could be tweaked to allow for > this to work , kern.geom.debugflag set to 16 would allow this to work. >=20 > So my question is this. Should there be any reason why "glabel label > name device" on the root slice cause an issue > when the slice is mounted rw ? >=20 > Is this a bug ? No. It isn't. When you are doing `glabel label` you overwriting last sector of given device with glabel's metadata. So you potentially can destroy some data in it. Using kern.geom.debugflags=3D16 is a bad practice. The right way i= s creating label before creation of file system and installing OS. Also you can use UFS labels (see tunefs(8)). --=20 WBR, Andrey V. Elsukov --------------enig53ED216EFC659D8746029286 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJOS0DKAAoJEAHF6gQQyKF6EHQH/jVhZ3GncKOl4111ct1o8NCh RSWezNT+7yjLK82U5NmXjq3hrhS3fLPDtBnwANngIGriXpiheBncE/6fj/HGvMsJ IZBIlAyJIgAQXQ8DS0Z19YSLKwq5fFNYh1wYMLXyhTt+5Q62cbX/ceRkppFbsxVt kjUM9aDnTGQZdlfFvhOsU6YOIP/53iv0d8eNGhUyOh2Dc7PIZnq8wyrr7j7+cSGX YjAd9S22UrX4tWt4svsnAP5eThTk4QP4Aj93SrDS/jj2pCfEt3z4s5SujzyPSPvx BJKNqmihy72UhTJ2hppgx3qVnvDtIaM9Jza2VHks4o+SXlFbUvdwMi7/4T2PifI= =0U0U -----END PGP SIGNATURE----- --------------enig53ED216EFC659D8746029286-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 05:37:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC6C106566B for ; Wed, 17 Aug 2011 05:37:06 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from hosted.gothic.net.au (eth1539.vic.adsl.internode.on.net [150.101.217.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDFC8FC0C for ; Wed, 17 Aug 2011 05:37:06 +0000 (UTC) Received: from hosted.gothic.net.au (localhost [127.0.0.1]) by hosted.gothic.net.au (Postfix) with ESMTP id 3B8118DF425; Wed, 17 Aug 2011 15:18:57 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from hosted.gothic.net.au ([127.0.0.1]) by hosted.gothic.net.au (hosted.gothic.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZNyMHf0qPsk; Wed, 17 Aug 2011 15:18:09 +1000 (EST) Received: from queen.gothic.net.au (eth1540.vic.adsl.internode.on.net [150.101.217.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean@gothic.net.au) by hosted.gothic.net.au (Postfix) with ESMTPSA id 2985A8DF423; Wed, 17 Aug 2011 15:18:09 +1000 (EST) Date: Wed, 17 Aug 2011 15:18:09 +1000 (EST) From: Sean To: "Andrey V. Elsukov" In-Reply-To: <4E4B40C4.6080608@yandex.ru> Message-ID: References: <4E4B40C4.6080608@yandex.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Mark Saad Subject: Re: glabel on 9-BETA1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 05:37:06 -0000 On Wed, 17 Aug 2011, Andrey V. Elsukov wrote: > On 17.08.2011 0:10, Mark Saad wrote: >> root@blindness:~# glabel label rootfs ada0p4 >> glabel: Can't store metadata on ada0p4: Operation not permitted. >> >> In 7.2 and prior there was a sysctl that could be tweaked to allow for >> this to work , kern.geom.debugflag set to 16 would allow this to work. >> >> So my question is this. Should there be any reason why "glabel label >> name device" on the root slice cause an issue >> when the slice is mounted rw ? >> >> Is this a bug ? > > No. It isn't. > When you are doing `glabel label` you overwriting last sector of given > device with glabel's metadata. So you potentially can destroy some data > in it. Using kern.geom.debugflags=16 is a bad practice. The right way is > creating label before creation of file system and installing OS. > Also you can use UFS labels (see tunefs(8)). > > Or in this case, GPT labels, which are more flexible in that they can apply to non-UFS partitions as well, such as swap. 'gpart show -l' and 'gpart modify' ... /dev/gpt/ is where the labels show up. From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 08:21:49 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A27A7106566C for ; Wed, 17 Aug 2011 08:21:49 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB748FC08 for ; Wed, 17 Aug 2011 08:21:49 +0000 (UTC) Received: by pzk33 with SMTP id 33so1141909pzk.18 for ; Wed, 17 Aug 2011 01:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y/len3GEVXL/W7F+K1gKKz5pWrrmeX8RtuDd3FrEhiw=; b=Oh8HNHAw2Kc3XJFBouVdZ7xBDRtBf7pFfN1OLL/bbvo62l15LQ8yRMmYw1F4eHr39Z /++ZBfQ8zSgxlzxd6K/BDxTFQ/Pd1d591YLMgTidSEdnukNwmAE0VKeQJkOtg1mxI9bX jZrs+gdBJN1fV+P9HxSEvr4ZwSTxn3ErJFZKc= MIME-Version: 1.0 Received: by 10.142.150.13 with SMTP id x13mr359005wfd.417.1313569308891; Wed, 17 Aug 2011 01:21:48 -0700 (PDT) Received: by 10.142.218.13 with HTTP; Wed, 17 Aug 2011 01:21:48 -0700 (PDT) In-Reply-To: <868vqt0xuc.fsf@gmail.com> References: <868vqt0xuc.fsf@gmail.com> Date: Wed, 17 Aug 2011 03:21:48 -0500 Message-ID: From: Zhihao Yuan To: Test Rat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 08:21:49 -0000 I totally hate gmail's reply -- I enabled "Reply to all" by default but I still got things wrong. Anyway, for short, the problem is caused by the lack of a widechar enabled regex. I ported the one used by nvi-devel-1.8x. A new patch is uploaded, https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-17.diff.gz and I tested it with make buildworld. Note that this version sets WARNS=3D1 in vi's Makefile, since it's warning free with clang and gcc. And there is change to `rescue`'s compilation: now it links to libcursesw if WITH_ICONV is on. On Tue, Aug 16, 2011 at 5:56 PM, Test Rat wrote: > Zhihao Yuan writes: > >> On Sun, Aug 14, 2011 at 10:39 AM, Zhihao Yuan wrote: >>> Hi, hackers: >>> >>> My GSoC2011 project, "Multibyte Encoding Support in Nvi" is ready for >>> testing. The proposal of the project is here: >>> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 > [...] >> Let me try to ``quickly'' explain how to involve into the testing. >> >> First, download the patch from >> https://github.com/downloads/lichray/nvi2/nvi2-freebsd-2011-08-14.diff.g= z > > It breaks buildworld for me, e.g. > > =C2=A0$ make all -C share/termcap > =C2=A0gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > =C2=A0TERM=3Ddumb TERMCAP=3Ddumb: ex - /usr/src/share/termcap/termcap.src= < /usr/src/share/termcap/reorder > =C2=A0Error: stderr: Inappropriate ioctl for device > =C2=A0script, 3: Destination line is inside move range > =C2=A0*** Error code 1 > > and crashes when no WITH_ICONV is defined. Can you confirm? > > =C2=A0Starting program: /usr/bin/ex - /usr/src/share/termcap/termcap.src = < /usr/src/share/termcap/reorder > > =C2=A0Program received signal SIGSEGV, Segmentation fault. > =C2=A00x0000000800be7760 in ?? () > =C2=A0(gdb) bt > =C2=A0#0 =C2=A00x0000000800be7760 in ?? () > =C2=A0#1 =C2=A00x000000000044092b in ex_writefp (sp=3D0x801106800, name= =3D0x801103148 "termcap", fp=3D0x800e51d90, fm=3D0x801007ca8, tm=3D0x801007= cb8, > =C2=A0 =C2=A0 =C2=A0nlno=3D0x7fffffffc808, nch=3D0x7fffffffc800, silent= =3D0) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:321 > =C2=A0#2 =C2=A00x000000000040bfb2 in file_write (sp=3D0x801106800, fm=3D0= x801007ca8, tm=3D0x801007cb8, name=3D0x801103148 "termcap", flags=3D21) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/common/exf.= c:924 > =C2=A0#3 =C2=A00x0000000000440739 in exwr (sp=3D0x801106800, cmdp=3D0x801= 007be8, cmd=3DWRITE) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write= .c:264 > =C2=A0#4 =C2=A00x00000000004400d2 in ex_write (sp=3D0x801106800, cmdp=3D0= x801007be8) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:91 > =C2=A0#5 =C2=A00x0000000000422b78 in ex_cmd (sp=3D0x801106800) at /usr/sr= c/usr.bin/vi/../../contrib/nvi2/ex/ex.c:1375 > =C2=A0#6 =C2=A00x000000000041f788 in ex (spp=3D0x7fffffffd040) at /usr/sr= c/usr.bin/vi/../../contrib/nvi2/ex/ex.c:133 > =C2=A0#7 =C2=A00x0000000000412377 in editor (gp=3D0x801007b00, argc=3D1, = argv=3D0x7fffffffd268) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/common/main= .c:424 > =C2=A0#8 =C2=A00x000000000040513f in main (argc=3D3, argv=3D0x7fffffffd25= 8) at /usr/src/usr.bin/vi/../../contrib/nvi2/cl/cl_main.c:123 > =C2=A0(gdb) bt f > =C2=A0#0 =C2=A00x0000000800be7760 in ?? () > =C2=A0No symbol table info available. > =C2=A0#1 =C2=A00x000000000044092b in ex_writefp (sp=3D0x801106800, name= =3D0x801103148 "termcap", fp=3D0x800e51d90, fm=3D0x801007ca8, tm=3D0x801007= cb8, > =C2=A0 =C2=A0 =C2=A0nlno=3D0x7fffffffc808, nch=3D0x7fffffffc800, silent= =3D0) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:321 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sb =3D { > =C2=A0 =C2=A0st_dev =3D 4294955600, > =C2=A0 =C2=A0st_ino =3D 32767, > =C2=A0 =C2=A0st_mode =3D 0, > =C2=A0 =C2=A0st_nlink =3D 0, > =C2=A0 =C2=A0st_uid =3D 0, > =C2=A0 =C2=A0st_gid =3D 1944, > =C2=A0 =C2=A0st_rdev =3D 0, > =C2=A0 =C2=A0st_atim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 3, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 34377892735 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_mtim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 6798080, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 4096 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_ctim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 0, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 34366769152 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_size =3D 4, > =C2=A0 =C2=A0st_blocks =3D 140737488343672, > =C2=A0 =C2=A0st_blksize =3D 3, > =C2=A0 =C2=A0st_flags =3D 0, > =C2=A0 =C2=A0st_gen =3D 4294954160, > =C2=A0 =C2=A0st_lspare =3D 32767, > =C2=A0 =C2=A0st_birthtim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 34366543277, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 582 > =C2=A0 =C2=A0} > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gp =3D (GS *) 0x801007b00 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ccnt =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fline =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tline =3D 4666 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lcnt =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0len =3D 140737488340496 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rval =3D -11656 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0msg =3D 0x46f540 "253|Writing..." > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D (CHAR_T *) 0xb > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D 0x800c0981f "H\211A^]\017\037\204= " > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flen =3D 140737488340168 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isutf16 =3D 0 > =C2=A0#2 =C2=A00x000000000040bfb2 in file_write (sp=3D0x801106800, fm=3D0= x801007ca8, tm=3D0x801007cb8, name=3D0x801103148 "termcap", flags=3D21) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/common/exf.= c:924 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mtype =3D OLDFILE > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sb =3D { > =C2=A0 =C2=A0st_dev =3D 745804815, > =C2=A0 =C2=A0st_ino =3D 70073, > =C2=A0 =C2=A0st_mode =3D 33188, > =C2=A0 =C2=A0st_nlink =3D 1, > =C2=A0 =C2=A0st_uid =3D 1001, > =C2=A0 =C2=A0st_gid =3D 1001, > =C2=A0 =C2=A0st_rdev =3D 4294967295, > =C2=A0 =C2=A0st_atim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 1313534959, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 905174484 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_mtim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 1313535150, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 420174354 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_ctim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 1313535150, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 420174354 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0st_size =3D 0, > =C2=A0 =C2=A0st_blocks =3D 1, > =C2=A0 =C2=A0st_blksize =3D 131072, > =C2=A0 =C2=A0st_flags =3D 0, > =C2=A0 =C2=A0st_gen =3D 0, > =C2=A0 =C2=A0st_lspare =3D 0, > =C2=A0 =C2=A0st_birthtim =3D { > =C2=A0 =C2=A0 =C2=A0tv_sec =3D 1313535150, > =C2=A0 =C2=A0 =C2=A0tv_nsec =3D 420174354 > =C2=A0 =C2=A0} > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ep =3D (EXF *) 0x801031180 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fp =3D (FILE *) 0x800e51d90 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frp =3D (FREF *) 0x80112f040 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from =3D { > =C2=A0 =C2=A0lno =3D 4294953320, > =C2=A0 =C2=A0cno =3D 140737488341984 > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to =3D { > =C2=A0 =C2=A0lno =3D 17842464, > =C2=A0 =C2=A0cno =3D 140737488341096 > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0len =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nlno =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nch =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fd =3D 11 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nf =3D 18607849 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0noname =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oflags =3D 1537 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rval =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D 0x800b87f54 "=C2=BB\001" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s =3D 0x7fffffffc830 "" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t =3D 0x80118b240 "" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0buf =3D "\000=C2=BBg\000\000\000\000\00= 0q000\b\000\000\000=C2=AB\002\000\000\000\000\000\000\001\b\000\000\000\000= \000\000\004\000\000\000\000\000\000\000h=C2=BBg\000\000\000\000\000\033\00= 1\000\000\000\000\000`\004\000\000\000\000\000\000=C2=BBg\000\000\000\000\0= 00\001\000\000\000\000\000\000\000\000=C2=B0*\001\b\000\000\000\000=C2=BBg\= 000\000\000\000\000\000`\004\000\000\000\000\000\000(\000\000\000\000\000\0= 00\020=C3=BF=C3=BF\177\000\000\227000\b\000\000\000h=C2=BBg", '\0' , "\020=C3=BF=C3=BF\177\000\000[\214=C3=80\000\b\000\000\000\000= =C2=A0!\001\b\000\000\000(=C2=A0!\001\b\000\000\000\000\017\023\001\b\000\0= 00\000 =C2=A0!\001\b\000\000\000@=C3=BF=C3=BF\177\000\000\036w=C3=80"... > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0msgstr =3D 0x2 > =C2=A0#3 =C2=A00x0000000000440739 in exwr (sp=3D0x801106800, cmdp=3D0x801= 007be8, cmd=3DWRITE) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write= .c:264 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rm =3D { > =C2=A0 =C2=A0lno =3D 17846452, > =C2=A0 =C2=A0cno =3D 4 > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flags =3D 21 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name =3D 0x801103148 "termcap" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D (CHAR_T *) 0x801103088 "termcap" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nlen =3D 8 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n =3D 0x801103140 "termcap" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rc =3D 4260867 > =C2=A0#4 =C2=A00x00000000004400d2 in ex_write (sp=3D0x801106800, cmdp=3D0= x801007be8) at /usr/src/usr.bin/vi/../../contrib/nvi2/ex/ex_write.c:91 > =C2=A0No locals. > =C2=A0#5 =C2=A00x0000000000422b78 in ex_cmd (sp=3D0x801106800) at /usr/sr= c/usr.bin/vi/../../contrib/nvi2/ex/ex.c:1375 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nret =3D 17852416 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exp =3D (EX_PRIVATE *) 0x8010f3600 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ecp =3D (EXCMD *) 0x801007be8 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gp =3D (GS *) 0x801007b00 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cur =3D { > =C2=A0 =C2=A0lno =3D 185, > =C2=A0 =C2=A0cno =3D 0 > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lno =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg1_len =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discard =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0len =3D 140737488342608 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flags =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ltmp =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at_found =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gv_found =3D 24 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cnt =3D 8 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0delim =3D 16808704 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isaddr =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0namelen =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0newscreen =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0notempty =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tmp =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vi_address =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg1 =3D (CHAR_T *) 0x0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s =3D (CHAR_T *) 0x801153143 "termcap" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D (CHAR_T *) 0x80115314b "-m'a" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t =3D (CHAR_T *) 0x7fffffffd250 "\003" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ch =3D 112 'p' > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n =3D (CHAR_T *) 0x7 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0np =3D 0x46a8b9 "s" > =C2=A0#6 =C2=A00x000000000041f788 in ex (spp=3D0x7fffffffd040) at /usr/sr= c/usr.bin/vi/../../contrib/nvi2/ex/ex.c:133 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exp =3D (EX_PRIVATE *) 0x8010f3600 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gp =3D (GS *) 0x801007b00 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mp =3D (MSGS *) 0x0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D (SCR *) 0x801106800 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tp =3D (TEXT *) 0x801151080 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flags =3D 2592 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0space =3D 32 ' ' > =C2=A0#7 =C2=A00x0000000000412377 in editor (gp=3D0x801007b00, argc=3D1, = argv=3D0x7fffffffd268) > =C2=A0 =C2=A0 =C2=A0at /usr/src/usr.bin/vi/../../contrib/nvi2/common/main= .c:424 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p =3D 0x7fffffff037f "" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ev =3D { > =C2=A0 =C2=A0q =3D { > =C2=A0 =C2=A0 =C2=A0tqe_next =3D 0x40150c, > =C2=A0 =C2=A0 =C2=A0tqe_prev =3D 0x7fffffffd008 > =C2=A0 =C2=A0}, > =C2=A0 =C2=A0e_event =3D 98, > =C2=A0 =C2=A0_u_event =3D { > =C2=A0 =C2=A0 =C2=A0_e_ch =3D { > =C2=A0 =C2=A0 =C2=A0 =C2=A0c =3D 58 ':', > =C2=A0 =C2=A0 =C2=A0 =C2=A0value =3D K_NOTUSED, > =C2=A0 =C2=A0 =C2=A0 =C2=A0flags =3D 58 ':' > =C2=A0 =C2=A0 =C2=A0}, > =C2=A0 =C2=A0 =C2=A0_e_mark =3D { > =C2=A0 =C2=A0 =C2=A0 =C2=A0lno1 =3D 4201018, > =C2=A0 =C2=A0 =C2=A0 =C2=A0cno1 =3D 4201018, > =C2=A0 =C2=A0 =C2=A0 =C2=A0lno2 =3D 226154414, > =C2=A0 =C2=A0 =C2=A0 =C2=A0cno2 =3D 34366783664 > =C2=A0 =C2=A0 =C2=A0}, > =C2=A0 =C2=A0 =C2=A0_e_str =3D { > =C2=A0 =C2=A0 =C2=A0 =C2=A0asp =3D 0x401a3a "sigaction", > =C2=A0 =C2=A0 =C2=A0 =C2=A0csp =3D 0x401a3a "sigaction", > =C2=A0 =C2=A0 =C2=A0 =C2=A0len =3D 226154414 > =C2=A0 =C2=A0 =C2=A0} > =C2=A0 =C2=A0} > =C2=A0} > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0frp =3D (FREF *) 0x80112f040 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sp =3D (SCR *) 0x801106800 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0len =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flags =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ch =3D -1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flagchk =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lflag =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0startup =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0readonly =3D 0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rval =3D 6813300 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0silent =3D 1 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tag_f =3D 0x0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wsizearg =3D 0x0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path =3D "x=C3=BF=C3=BF\177\000\000\003= \000\000\000\000\000\000\000P=C3=BF=C3=BF\177\000\000=C2=AD\000\b\000\000\0= 00\000=C2=BBg\000\000\000\000\000\000P\004\001\b\000\000\000\000\020\000\00= 0\000\000\000\000\000\020\000\000\000\000\000\000\001\000\000\000\000\000\0= 00\0000=C3=BF=C3=BF\177\00---Type to continue, or q to qu= it--- > =C2=A00\000\0005000\b\000\000\000204\002\001\b", '\0' ,= "\006\002\000\000\000\000\000\000\000=C2=BBg\000\000\000\000\000\000@k\000= \b\000\000\000222=C3=80\000\b\000\000\000\017W@\000\000\000\000\000=C2=B0= =C2=BAg\000\000\000\000\000@\000\000\000\000\000H\205\002\001\b\000\000\000= \000P\004\001\034\000\000\000@", '\0' , "\b\000\000\000\2= 20=C3=BF=C3=BF\177\000\000"... > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0w =3D (CHAR_T *) 0x7fffffffcff8 "g" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wlen =3D 34366767104 > =C2=A0#8 =C2=A00x000000000040513f in main (argc=3D3, argv=3D0x7fffffffd25= 8) at /usr/src/usr.bin/vi/../../contrib/nvi2/cl/cl_main.c:123 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clp =3D (CL_PRIVATE *) 0x801028300 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gp =3D (GS *) 0x801007b00 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rows =3D 24 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cols =3D 132 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rval =3D 32767 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p_av =3D (char **) 0x7fffffffd270 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t_av =3D (char **) 0x7fffffffd270 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ttype =3D 0x7fffffffd6ab "screen-256col= or" > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0reenter =3D 1 > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 16:31:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7C21065675; Wed, 17 Aug 2011 16:31:10 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 663578FC18; Wed, 17 Aug 2011 16:31:10 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p7HGUqRv064110; Wed, 17 Aug 2011 09:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1313598652; bh=rPmj0dOowNXeFm7xliak42pzDeG0kB6r86IeZAtmijg=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Sd0AZ4HpyAV43yCGGVaF6NzJdCRaWA1TGNAqNP+DLAv7rbmLZqdsnSbuqX1FyIDcV /fypWoU7mPU5E3+nj90grZ4VV78KCc538xek+iaExfwG+Iv2oKKEBkIRuJKt3S3qqI F7WoWBOeTLb263dQJgmO+zCMHs2jY31zzuENiYZ4= From: Sean Bruno To: Test Rat In-Reply-To: <86y5yt0zr4.fsf@gmail.com> References: <1313531445.3828.1.camel@hitfishpass-lx.corp.yahoo.com> <86y5yt0zr4.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 17 Aug 2011 09:30:51 -0700 Message-ID: <1313598652.2593.0.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" , re@freebsd.org Subject: Re: building my own release images from -CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 16:31:10 -0000 On Tue, 2011-08-16 at 15:15 -0700, Test Rat wrote: > Sean Bruno writes: > > > Just trying some hackery with building my own release images from > > -CURRENT today. > > > > I've built world and my kernel, when I enter release and "make memstick" > > I get the following: > > > > ** Creating the temporary root environment in /var/tmp/temproot > > *** /var/tmp/temproot ready for use > > *** Creating and populating directory structure in /var/tmp/temproot > > > > > > *** FATAL ERROR: Cannot 'cd' to /usr/src and install files to > > the temproot environment > > > > *** Error code 1 > > > > Stop in /dumpster/scratch/sbruno-scratch/test/release. > > Where points /usr/src? Have you tried the patch in misc/159666 ? Well, wow. Ok, misc/159666 does indeed fix this problem. I'm very confused by the fact that it has not come up before. Let me cc re@freebsd.org and see if we can get a commit for this. Sean From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 20:21:48 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4E8106567A; Wed, 17 Aug 2011 20:21:47 +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 339038FC20; Wed, 17 Aug 2011 20:21:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA00935; Wed, 17 Aug 2011 23:21:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QtmcR-000Du9-7E; Wed, 17 Aug 2011 23:21:43 +0300 Message-ID: <4E4C22D6.6070407@FreeBSD.org> Date: Wed, 17 Aug 2011 23:21:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110817 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-jail@FreeBSD.org, freebsd-hackers@FreeBSD.org References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org> <4E43E272.1060204@FreeBSD.org> <62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk> <4E440865.1040500@FreeBSD.org> <6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk> <4E441314.6060606@FreeBSD.org> <2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk> <4E48D967.9060804@FreeBSD.org> <9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk> <4E490DAF.1080009@FreeBSD.org> <796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk> <4E491D01.1090902@FreeBSD.org> <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> <4E4AD35C.7020504@FreeBSD.org> <6A7238AED44542A880B082A40304D940@multiplay.co.uk> <4E4BA21F.6010805@FreeBSD.org> <581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk> <4E4BBA7F.30907@FreeBSD.org> <88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> In-Reply-To: <88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> X-Enigmail-Version: 1.2.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Steven Hartland Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 20:21:48 -0000 Thanks to the debug that Steven provided and to the help that I received from Kostik, I think that now I understand the basic mechanics of this panic, but, unfortunately, not the details of its root cause. It seems like everything starts with some kind of a race between terminating processes in a jail and termination of the jail itself. This is where the details are very thin so far. What we see is that a process (http) is in exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT flag is set and even past the place where p_limit is freed and reset to NULL. At that place the thread calls prison_proc_free(), which calls prison_deref(). Then, we see that in prison_deref() the thread gets a page fault because of what seems like a NULL pointer dereference. That's just the start of the problem and its root cause. Then, trap_pfault() gets invoked and, because addresses close to NULL look like userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes on to call vm_map_growstack. First thing that vm_map_growstack does is a call to lim_cur(), but because p_limit is already NULL, that call results in a NULL pointer dereference and a page fault. Goto the beginning of this paragraph. So we get this recursion of sorts, which only ends when a stack is exhausted and a CPU generates a double-fault. So, of course, Steven is interested in finding and fixing the root cause. I hope we will get to that with some help from the "prison guards" :-) But I also would like to use this opportunity to discuss how we can make it easier to debug such issue as this. I think that this problem demonstrates that when we treat certain junk in kernel address value as a userland address value, we throw additional heaps of irrelevant stuff on top of an actual problem. One solution could be to use a special flag that would mark all actual attempts to access userland address (e.g. setting the flag on entrance to copyin and clearing it upon return), so that in the page fault handler we could distinguish actual faults on userland addresses from faults on garbage kernel addresses. I am sure that there could be other clever techniques to catch such garbage addresses early. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 21:10:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8105106566C; Wed, 17 Aug 2011 21:10:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 454A08FC16; Wed, 17 Aug 2011 21:10:53 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p7HLAnic075382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2011 00:10:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p7HLAm2E007269; Thu, 18 Aug 2011 00:10:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p7HLAmDw007268; Thu, 18 Aug 2011 00:10:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Aug 2011 00:10:48 +0300 From: Kostik Belousov To: Andriy Gapon Message-ID: <20110817211048.GZ17489@deviant.kiev.zoral.com.ua> References: <796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk> <4E491D01.1090902@FreeBSD.org> <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> <4E4AD35C.7020504@FreeBSD.org> <6A7238AED44542A880B082A40304D940@multiplay.co.uk> <4E4BA21F.6010805@FreeBSD.org> <581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk> <4E4BBA7F.30907@FreeBSD.org> <88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MPHowW9WJBu+8Ajw" Content-Disposition: inline In-Reply-To: <4E4C22D6.6070407@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, freebsd-jail@freebsd.org, Steven Hartland , freebsd-stable@freebsd.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 21:10:54 -0000 --MPHowW9WJBu+8Ajw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2011 at 11:21:42PM +0300, Andriy Gapon wrote: [skip] > But I also would like to use this opportunity to discuss how we can > make it easier to debug such issue as this. I think that this problem > demonstrates that when we treat certain junk in kernel address value > as a userland address value, we throw additional heaps of irrelevant > stuff on top of an actual problem. One solution could be to use a > special flag that would mark all actual attempts to access userland > address (e.g. setting the flag on entrance to copyin and clearing it > upon return), so that in the page fault handler we could distinguish > actual faults on userland addresses from faults on garbage kernel > addresses. I am sure that there could be other clever techniques to > catch such garbage addresses early. We already have such mechanism, the kernel code aware of the usermode page access sets pcb_onfault. See the end of trap_pfault() handler. In fact, we can catch it earlier, before even calling vm_fault(). BTW, I think this is esp. useful in the combination with the support for the SMEP in recent Intel CPUs. commit 2e1b36fa93f9499e37acf04a66ff0646d4f13536 Author: Konstantin Belousov Date: Thu Aug 18 00:08:50 2011 +0300 Assert that the exiting process does not return to usermode. On x86, do not call vm_fault() when the kernel is not prepared to handle unsuccessful page fault. diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c index 4e5f8b8..55e1e5a 100644 --- a/sys/amd64/amd64/trap.c +++ b/sys/amd64/amd64/trap.c @@ -674,6 +674,19 @@ trap_pfault(frame, usermode) goto nogo; =20 map =3D &vm->vm_map; + + /* + * When accessing a usermode address, kernel must be + * ready to accept the page fault, and provide a + * handling routine. Since accessing the address + * without the handler is a bug, do not try to handle + * it normally, and panic immediately. + */ + if (!usermode && (td->td_intr_nesting_level !=3D 0 || + PCPU_GET(curpcb)->pcb_onfault =3D=3D NULL)) { + trap_fatal(frame, eva); + return (-1); + } } =20 /* diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c index 5a8016c..e6d2b5a 100644 --- a/sys/i386/i386/trap.c +++ b/sys/i386/i386/trap.c @@ -831,6 +831,11 @@ trap_pfault(frame, usermode, eva) goto nogo; =20 map =3D &vm->vm_map; + if (!usermode && (td->td_intr_nesting_level !=3D 0 || + PCPU_GET(curpcb)->pcb_onfault =3D=3D NULL)) { + trap_fatal(frame, eva); + return (-1); + } } =20 /* diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 3527ed1..a69b7b8 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -99,6 +99,8 @@ userret(struct thread *td, struct trapframe *frame) =20 CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid, td->td_name); + KASSERT((p->p_flag & P_WEXIT) =3D=3D 0, + ("Exiting process returns to usermode")); #if 0 #ifdef DIAGNOSTIC /* Check that we called signotify() enough. */ --MPHowW9WJBu+8Ajw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5MLlgACgkQC3+MBN1Mb4hyewCgpKYy+yhG+S3bXm5A324n/C8+ 6lIAoPRTszmVWdyBQqw5vhJUnpNbhluY =i6E1 -----END PGP SIGNATURE----- --MPHowW9WJBu+8Ajw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 17 23:26:40 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58841106566C; Wed, 17 Aug 2011 23:26:40 +0000 (UTC) (envelope-from prvs=1210f20b9f=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4928FC17; Wed, 17 Aug 2011 23:26:39 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 00:15:17 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 00:15:17 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014640704.msg; Thu, 18 Aug 2011 00:15:16 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1210f20b9f=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <4019027648B5493AAC4B654BD821DE88@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , , References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org><4E43E272.1060204@FreeBSD.org><62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk><4E440865.1040500@FreeBSD.org><6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk><4E441314.6060606@FreeBSD.org><2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk><4E48D967.9060804@FreeBSD.org><9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk><4E490DAF.1080009@FreeBSD.org><796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk><4E491D01.1090902@FreeBSD.org><570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk><4E4AD35C.7020504@FreeBSD.org><6A7238AED44542A880B082A40304D940@multiplay.co.uk><4E4BA21F.6010805@FreeBSD.org><581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk><4E4BBA7F.30907@FreeBSD.org><88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> Date: Thu, 18 Aug 2011 00:15:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 23:26:40 -0000 ----- Original Message ----- From: "Andriy Gapon" > Thanks to the debug that Steven provided and to the help that I received from > Kostik, I think that now I understand the basic mechanics of this panic, but, > unfortunately, not the details of its root cause. > > It seems like everything starts with some kind of a race between terminating > processes in a jail and termination of the jail itself. This is where the > details are very thin so far. What we see is that a process (http) is in > exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT > flag is set and even past the place where p_limit is freed and reset to NULL. > At that place the thread calls prison_proc_free(), which calls prison_deref(). > Then, we see that in prison_deref() the thread gets a page fault because of what > seems like a NULL pointer dereference. That's just the start of the problem and > its root cause. Thats interesting, are you using http as an example or is that something thats been gleaned from the debugging of our output? I ask as there's only one process running in each of our jails and thats a single java process. Now given your description there may be something I can add that may help clarify what the cause could be. In a nutshell the jail manager we're using will attempt to resurrect the jail from a dieing state in a few specific scenarios. Here's an exmaple:- 1. jail restart requested 2. jail is stopped, so the java processes is killed off, but active tcp sessions may prevent the timely full shutdown of the jail. 3. if an existing jail is detected, i.e. a dieing jail from #2, instead of starting a new jail we attach to the old one and exec the new java process. 4. if an existing jail isnt detected, i.e. where there where not hanging tcp sessions and #2 cleanly shutdown the jail, a new jail is created, attached to and the java exec'ed. The system uses static jailid's so its possible to determine if an existing jail for this "service" exists or not. This prevents duplicate services as well as making services easy to identify by their jailid. So what we could be seeing is a race between the jail shutdown and the attach of the new process? Now man 2 jail seems to indicate this is a valid use case for jail_set, as it documents its support for JAIL_DYING as a valid option for flags, but I suspect its something quite out of the ordinary to actually do, which may be why this panic hasnt been seen before now. As some background the reason we use static jailid's is to ensure only one instance of the jailed service is running, and the reason we re-attach to the dieing jail is so that jails can be restarted in a timely manor. Without using the re-attach we would need to wait of all tcp sessions which have been aborted to timeout. > So, of course, Steven is interested in finding and fixing the root cause. I > hope we will get to that with some help from the "prison guards" :-) Does the above potentially explain how we're getting to the situation which generates the panic? If so we can certainly look at using alternatives to the current design to workaround this issue. Flagging the jail as permanent and using manual process management and additional external locking to prevent duplicates, is what instantly springs to mind. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 09:21:21 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CABC9106566C; Thu, 18 Aug 2011 09:21:21 +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 AB12E8FC22; Thu, 18 Aug 2011 09:21:20 +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 MAA10730; Thu, 18 Aug 2011 12:21:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4CD98C.1000301@FreeBSD.org> Date: Thu, 18 Aug 2011 12:21:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org><4E43E272.1060204@FreeBSD.org><62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk><4E440865.1040500@FreeBSD.org><6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk><4E441314.6060606@FreeBSD.org><2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk><4E48D967.9060804@FreeBSD.org><9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk><4E490DAF.1080009@FreeBSD.org><796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk><4E491D01.1090902@FreeBSD.org><570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk><4E4AD35C.7020504@FreeBSD.org><6A7238AED44542A880B082A40304D940@multiplay.co.uk><4E4BA21F.6010805@FreeBSD.org><581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk><4E4BBA7F.30907@FreeBSD.org><88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> <4019027648B5493AAC4B654BD821DE88@multiplay.co.! uk> In-Reply-To: <4019027648B5493AAC4B654BD821DE88@multiplay.co.uk> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 09:21:21 -0000 on 18/08/2011 02:15 Steven Hartland said the following: > ----- Original Message ----- From: "Andriy Gapon" > >> Thanks to the debug that Steven provided and to the help that I received from >> Kostik, I think that now I understand the basic mechanics of this panic, but, >> unfortunately, not the details of its root cause. >> >> It seems like everything starts with some kind of a race between terminating >> processes in a jail and termination of the jail itself. This is where the >> details are very thin so far. What we see is that a process (http) is in >> exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT >> flag is set and even past the place where p_limit is freed and reset to NULL. >> At that place the thread calls prison_proc_free(), which calls prison_deref(). >> Then, we see that in prison_deref() the thread gets a page fault because of what >> seems like a NULL pointer dereference. That's just the start of the problem and >> its root cause. > > Thats interesting, are you using http as an example or is that something thats > been gleaned from the debugging of our output? I ask as there's only one process > running in each of our jails and thats a single java process. It's from the debug data: p_comm = "httpd" I also would like to ask you to revert the last patch that I sent you (with tf_rip comparisons) and try the patch from Kostik instead. Given what we suspect about the problem, can please also try to provoke the problem by e.g. doing frequent jail restarts or something else that supposedly should hit the bug. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 10:47:04 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC10106566C; Thu, 18 Aug 2011 10:47:04 +0000 (UTC) (envelope-from prvs=12111cb08a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 312988FC18; Thu, 18 Aug 2011 10:47:02 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 11:35:21 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 11:35:21 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014645776.msg; Thu, 18 Aug 2011 11:35:20 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=12111cb08a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andriy Gapon" References: uk> <4E4CD98C.1000301@FreeBSD.org> Date: Thu, 18 Aug 2011 11:35:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-hackers@FreeBSD.org, freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 10:47:04 -0000 ----- Original Message ----- From: "Andriy Gapon" >> Thats interesting, are you using http as an example or is that something thats >> been gleaned from the debugging of our output? I ask as there's only one process >> running in each of our jails and thats a single java process. > > > It's from the debug data: p_comm = "httpd" Hmm, there's only one httpd thats ever run on the machine and thats not in the jail its on the raw machine. > I also would like to ask you to revert the last patch that I sent you (with tf_rip > comparisons) and try the patch from Kostik instead. Sure. > Given what we suspect about the problem, can please also try to provoke the > problem by e.g. doing frequent jail restarts or something else that supposedly > should hit the bug. I've tried doing this for quite some days on the test machine, but I've been unable to provoke it, will continue to try. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 10:45:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77AEE1065670 for ; Thu, 18 Aug 2011 10:45:45 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 522B68FC18 for ; Thu, 18 Aug 2011 10:45:45 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Qtzrw-0005Fv-KA for freebsd-hackers@freebsd.org; Thu, 18 Aug 2011 03:30:36 -0700 Date: Thu, 18 Aug 2011 03:30:36 -0700 (PDT) From: timp To: freebsd-hackers@freebsd.org Message-ID: <1313663436600-4711635.post@n5.nabble.com> In-Reply-To: References: <868vqt0xuc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Aug 2011 11:09:08 +0000 Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 10:45:45 -0000 Hi! I just tried you patch on latest current with clang. [root@current64 /usr/src]# uname -a FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK 2011 mox@current64:/usr/obj/usr/src/sys/GENERIC amd64 [root@current64 /usr/src]# patch < ~/nvi2-freebsd-2011-08-17.diff [root@current64 /usr/src]# make WITH_ICONV=1 buildworld ....loooong time..... .......................... ===> usr.bin/vgrind (depend) rm -f .depend CC='clang' mkdep -f .depend -a /usr/src/usr.bin/vgrind/regexp.c /usr/src/usr .bin/vgrind/vfontedpr.c echo vfontedpr: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend ===> usr.bin/vi (depend) make: don't know how to make cl_bsd.c. Stop *** Error code 2 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Maybe do I something wrong? -- View this message in context: http://freebsd.1045724.n5.nabble.com/nvi-iconv-Call-for-test-tp4698373p4711635.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 11:11:08 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E58106566C; Thu, 18 Aug 2011 11:11:08 +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 21EA88FC1B; Thu, 18 Aug 2011 11:11:06 +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 OAA12584; Thu, 18 Aug 2011 14:11:04 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4CF347.6030908@FreeBSD.org> Date: Thu, 18 Aug 2011 14:11:03 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: uk> <4E4CD98C.1000301@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:11:08 -0000 on 18/08/2011 13:35 Steven Hartland said the following: > ----- Original Message ----- From: "Andriy Gapon" >>> Thats interesting, are you using http as an example or is that something thats >>> been gleaned from the debugging of our output? I ask as there's only one process >>> running in each of our jails and thats a single java process. >> >> >> It's from the debug data: p_comm = "httpd" > > Hmm, there's only one httpd thats ever run on the machine and thats not in the jail > its on the raw machine. Probably I have mistakenly assumed that the 'prison' in prison_derefer() has something to do with an actual jail, while it could have been just prison0 where all non-jailed processes belong. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 11:26:06 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17692106566C; Thu, 18 Aug 2011 11:26:06 +0000 (UTC) (envelope-from prvs=12111cb08a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 08B508FC16; Thu, 18 Aug 2011 11:26:04 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 12:24:30 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 18 Aug 2011 12:24:30 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014646198.msg; Thu, 18 Aug 2011 12:24:29 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=12111cb08a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Andriy Gapon" References: uk> <4E4CD98C.1000301@FreeBSD.org> <4E4CF347.6030908@FreeBSD.org> Date: Thu, 18 Aug 2011 12:25:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-hackers@FreeBSD.org, freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 11:26:06 -0000 ----- Original Message ----- From: "Andriy Gapon" > Probably I have mistakenly assumed that the 'prison' in prison_derefer() has > something to do with an actual jail, while it could have been just prison0 where > all non-jailed processes belong. That makes sense as this particular panic was caused by a machine reboot, which is slightly different from the more common jail panic we're seeing. Doesn't help with our reproduction scenario though unfortunately. If we don't have any joy reproducing on our single test machine I'll have this kernel rolled out across a portion of the farm, which should mean we see the panic results in a few days time. I understand there's a risk involved in this but, its important for us to determine the cause and get a confirmed fix, as well as being able to prove that the panic fix works which will help everyone in the long run. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 14:31:28 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2C4F106566B; Thu, 18 Aug 2011 14:31:28 +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 B50648FC1F; Thu, 18 Aug 2011 14:31:27 +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 RAA15396; Thu, 18 Aug 2011 17:31:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4D222E.2090802@FreeBSD.org> Date: Thu, 18 Aug 2011 17:31:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland , freebsd-jail@FreeBSD.org References: uk> <4E4CD98C.1000301@FreeBSD.org> <4E4CF347.6030908@FreeBSD.org> In-Reply-To: <4E4CF347.6030908@FreeBSD.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:31:29 -0000 on 18/08/2011 14:11 Andriy Gapon said the following: > Probably I have mistakenly assumed that the 'prison' in prison_derefer() has > something to do with an actual jail, while it could have been just prison0 where > all non-jailed processes belong. So, indeed: (kgdb) p $2->p_ucred->cr_prison $10 = (struct prison *) 0xffffffff807d5080 (kgdb) p &prison0 $11 = (struct prison *) 0xffffffff807d5080 (kgdb) p *$2->p_ucred->cr_prison $12 = {pr_list = {tqe_next = 0x0, tqe_prev = 0x0}, pr_id = 0, pr_ref = 398, pr_uref = 0, pr_flags = 386, pr_children = {lh_first = 0x0}, pr_sibling = {le_next = 0x0, le_prev = 0x0}, pr_parent = 0x0, pr_mtx = {lock_object = {lo_name = 0xffffffff8063007c "jail mutex", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, pr_task = {ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0, ta_context = 0x0}, pr_osd = {osd_nslots = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, pr_cpuset = 0xffffff0012d65dc8, pr_vnet = 0x0, pr_root = 0xffffff00166ebce8, pr_ip4s = 0, pr_ip6s = 0, pr_ip4 = 0x0, pr_ip6 = 0x0, pr_sparep = {0x0, 0x0, 0x0, 0x0}, pr_childcount = 0, pr_childmax = 999999, pr_allow = 127, pr_securelevel = -1, pr_enforce_statfs = 0, pr_spare = {0, 0, 0, 0, 0}, pr_hostid = 3251597242, pr_name = "0", '\0' , pr_path = "/", '\0' , pr_hostname = "censored", '\0' , pr_domainname = '\0' , pr_hostuuid = "54443842-0054-2500-902c-0025902c3cb0", '\0' } Also, let's consider this code: if (flags & PD_DEUREF) { for (tpr = pr;; tpr = tpr->pr_parent) { if (tpr != pr) mtx_lock(&tpr->pr_mtx); if (--tpr->pr_uref > 0) break; KASSERT(tpr != &prison0, ("prison0 pr_uref=0")); mtx_unlock(&tpr->pr_mtx); } /* Done if there were only user references to remove. */ if (!(flags & PD_DEREF)) { mtx_unlock(&tpr->pr_mtx); if (flags & PD_LIST_SLOCKED) sx_sunlock(&allprison_lock); else if (flags & PD_LIST_XLOCKED) sx_xunlock(&allprison_lock); return; } if (tpr != pr) { mtx_unlock(&tpr->pr_mtx); mtx_lock(&pr->pr_mtx); } } The most suspicious thing is that pr_uref is zero in the debug data. With INVARIANTS we would hit the "prison0 pr_uref=0" KASSERT. Then, because this is prison0 and because pr_uref reached zero, tpr gets assigned to NULL. And then because tpr != pr we try to execute mtx_unlock(&tpr->pr_mtx). That's where the NULL pointer deref happens. So, now the big question is how/why we reached pr_uref == 0. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 16:55:59 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A84F6106564A for ; Thu, 18 Aug 2011 16:55:59 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8AA8FC12 for ; Thu, 18 Aug 2011 16:55:59 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p7IGswFv020489; Thu, 18 Aug 2011 09:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1313686499; bh=NQ6Np//PYAzSkVJB7DWytu2ZF1zijyKS0O0FUjp7FTo=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=sPjjzPB8aKlnMzultB9IzGSW7d3RfQtYHGxkojf9Vo7Vst4cfYskQfj3MILl3/CRH 8O0jgqLCmOsPkdMaQMtAiY+/NAHqm0mX4h001mOWFGo+fLKPFEcsIWK+JWbqe7KvvZ abnySfGLjzf/kvRnuqpGv2eH9nbpJSDnCXsdIszo= From: Sean Bruno To: Test Rat In-Reply-To: <86y5yt0zr4.fsf@gmail.com> References: <1313531445.3828.1.camel@hitfishpass-lx.corp.yahoo.com> <86y5yt0zr4.fsf@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 18 Aug 2011 09:54:58 -0700 Message-ID: <1313686498.2586.2.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "freebsd-hackers@freebsd.org" Subject: Re: building my own release images from -CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:55:59 -0000 On Tue, 2011-08-16 at 15:15 -0700, Test Rat wrote: > Have you tried the patch in misc/159666 ? Committed to -current svn R 224978. thanks for the patch! Sean From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 17:50:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C6581065678 for ; Thu, 18 Aug 2011 17:50:06 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 72BA08FC28 for ; Thu, 18 Aug 2011 17:50:06 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id p7IHo5jC041343 for ; Thu, 18 Aug 2011 10:50:06 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4E4D50CD.5080806@rawbw.com> Date: Thu, 18 Aug 2011 10:50:05 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ZFS installs on HD with 4k physical blocks without any warning as on 512 block size device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:50:06 -0000 Some latest hard drives have logical sectors of 512 byte when they actually have 4k physical sectors. Here is the document describing what to do in such case: http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html . For UFS: newfs -U -f 4096 /dev/da0 For ZFS: gnop create -S 4096 /dev/da0 && zpool create data /dev/da0.nop I am sure most people just install such hard drive without doing this and potentially get suboptimal performance since they aren't aware about this. Shouldn't UFS and ZFS drivers be able to either read the right sector size from the underlying device or at least issue a warning? Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 19:08:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C091065670 for ; Thu, 18 Aug 2011 19:08:36 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 971988FC0A for ; Thu, 18 Aug 2011 19:08:36 +0000 (UTC) Received: by yxn22 with SMTP id 22so906712yxn.13 for ; Thu, 18 Aug 2011 12:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hVq83yQpYgG7R/NGO4qw1wIaPCZ7S/0knct80fznj2k=; b=eUs5IWAYDumqhn0iZcSr8TGGW/w2wbOjnZvHNaLHeChWI+8XTzJ0TWDscLtgSmPCOg Pzb5SngxtPc0+YRl2F4JjpQH/Yn77AzH8tE0DdT/t2WSyeG6YLapMvsvpVjWRL+mm8SF xxpnPM9lpUcyZkvHNmlTAaZlls0K2FGZC4T7U= MIME-Version: 1.0 Received: by 10.42.144.65 with SMTP id a1mr1060148icv.190.1313694515740; Thu, 18 Aug 2011 12:08:35 -0700 (PDT) Received: by 10.231.14.68 with HTTP; Thu, 18 Aug 2011 12:08:35 -0700 (PDT) In-Reply-To: <1313663436600-4711635.post@n5.nabble.com> References: <868vqt0xuc.fsf@gmail.com> <1313663436600-4711635.post@n5.nabble.com> Date: Thu, 18 Aug 2011 14:08:35 -0500 Message-ID: From: Zhihao Yuan To: timp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:08:36 -0000 Em... I can't reproduce this. Can you post your make.conf and src.conf? On Thu, Aug 18, 2011 at 5:30 AM, timp wrote: > Hi! > I just tried you patch on latest current with clang. > > [root@current64 /usr/src]# uname -a > FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK > 2011 =C2=A0 =C2=A0 mox@current64:/usr/obj/usr/src/sys/GENERIC =C2=A0amd64 > > [root@current64 /usr/src]# patch < ~/nvi2-freebsd-2011-08-17.diff > > [root@current64 /usr/src]# make WITH_ICONV=3D1 buildworld > ....loooong time..... > .......................... > =3D=3D=3D> usr.bin/vgrind (depend) > rm -f .depend > CC=3D'clang' mkdep -f .depend -a =C2=A0 =C2=A0 /usr/src/usr.bin/vgrind/re= gexp.c > /usr/src/usr > .bin/vgrind/vfontedpr.c > echo vfontedpr: /usr/obj/usr/src/tmp/usr/lib/libc.a =C2=A0>> .depend > =3D=3D=3D> usr.bin/vi (depend) > make: don't know how to make cl_bsd.c. Stop > *** Error code 2 > > Stop in /usr/src/usr.bin. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > Maybe do I something wrong? > > -- > View this message in context: http://freebsd.1045724.n5.nabble.com/nvi-ic= onv-Call-for-test-tp4698373p4711635.html > Sent from the freebsd-hackers mailing list archive at Nabble.com. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 20:09:38 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 807AB1065672; Thu, 18 Aug 2011 20:09:38 +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 786778FC0A; Thu, 18 Aug 2011 20:09:37 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA18855; Thu, 18 Aug 2011 23:09:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qu8uF-000H9C-QY; Thu, 18 Aug 2011 23:09:35 +0300 Message-ID: <4E4D717F.3090802@FreeBSD.org> Date: Thu, 18 Aug 2011 23:09:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110817 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org> <4E43E272.1060204@FreeBSD.org> <62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk> <4E440865.1040500@FreeBSD.org> <6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk> <4E441314.6060606@FreeBSD.org> <2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk> <4E48D967.9060804@FreeBSD.org> <9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk> <4E490DAF.1080009@FreeBSD.org> <796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk> <4E491D01.1090902@FreeBSD.org> <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> <4E4AD35C.7020504@FreeBSD.org> <6A7238AED44542A880B082A40304D940@multiplay.co.uk> <4E4BA21F.6010805@FreeBSD.org> <581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk> <4E4BBA7F.30907@FreeBSD.org> <88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> In-Reply-To: <4E4C22D6.6070407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:09:38 -0000 on 17/08/2011 23:21 Andriy Gapon said the following: > It seems like everything starts with some kind of a race between terminating > processes in a jail and termination of the jail itself. This is where the > details are very thin so far. What we see is that a process (http) is in > exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT > flag is set and even past the place where p_limit is freed and reset to NULL. > At that place the thread calls prison_proc_free(), which calls prison_deref(). > Then, we see that in prison_deref() the thread gets a page fault because of what > seems like a NULL pointer dereference. That's just the start of the problem and > its root cause. > > Then, trap_pfault() gets invoked and, because addresses close to NULL look like > userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes > on to call vm_map_growstack. First thing that vm_map_growstack does is a call > to lim_cur(), but because p_limit is already NULL, that call results in a NULL > pointer dereference and a page fault. Goto the beginning of this paragraph. > > So we get this recursion of sorts, which only ends when a stack is exhausted and > a CPU generates a double-fault. BTW, does anyone has an idea why the thread in question would "disappear" from the kgdb's point of view? (kgdb) p cpuid_to_pcpu[2]->pc_curthread->td_tid $3 = 102057 (kgdb) tid 102057 invalid tid info threads also doesn't list the thread. Is it because the panic happened while the thread was somewhere in exit1()? is there an easy way to examine its stack in this case? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 20:43:19 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C8D2106564A for ; Thu, 18 Aug 2011 20:43:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3D768FC08 for ; Thu, 18 Aug 2011 20:43:18 +0000 (UTC) Received: by yxn22 with SMTP id 22so981822yxn.13 for ; Thu, 18 Aug 2011 13:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mJIC3dzSZFEfm+d2PPNPw14QLDbIUvhvYDXvpi+2xIs=; b=EEnO+Rzf3v4M5H2oK39bX1ICVx+TjHgVcpuYSLAx7JdLCTGDefHPWI0jZsA+SGiDeR MVd0NLPHbR9Mxtwh0kMu4xwL7Nc80S8M92vIzSpVhjYHmPsI8j/83BEQxriB/Qlw6Df4 sAFhZWoqMqR6hQ2w1rPVGiCptnAIxMw0m1YEA= MIME-Version: 1.0 Received: by 10.236.143.5 with SMTP id k5mr1139332yhj.9.1313698305236; Thu, 18 Aug 2011 13:11:45 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.236.108.33 with HTTP; Thu, 18 Aug 2011 13:11:44 -0700 (PDT) In-Reply-To: <4E4D717F.3090802@FreeBSD.org> References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk> <4E4380C0.7070908@FreeBSD.org> <4E43E272.1060204@FreeBSD.org> <62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk> <4E440865.1040500@FreeBSD.org> <6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk> <4E441314.6060606@FreeBSD.org> <2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk> <4E48D967.9060804@FreeBSD.org> <9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk> <4E490DAF.1080009@FreeBSD.org> <796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk> <4E491D01.1090902@FreeBSD.org> <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> <4E4AD35C.7020504@FreeBSD.org> <6A7238AED44542A880B082A40304D940@multiplay.co.uk> <4E4BA21F.6010805@FreeBSD.org> <581C95046B0948FC82D6F2E86948F87B@multiplay.co.uk> <4E4BBA7F.30907@FreeBSD.org> <88A6CE3E8B174E0694A3A9A5283479B4@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> <4E4D717F.3090802@FreeBSD.org> Date: Thu, 18 Aug 2011 22:11:44 +0200 X-Google-Sender-Auth: i75Ofelh7IObcWFwDsnjQQzRudA Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:43:19 -0000 2011/8/18 Andriy Gapon : > on 17/08/2011 23:21 Andriy Gapon said the following: >> >> It seems like everything starts with some kind of a race between >> terminating >> processes in a jail and termination of the jail itself. =C2=A0This is wh= ere the >> details are very thin so far. =C2=A0What we see is that a process (http)= is in >> exit(2) syscall, in exit1() function actually, and past the place where >> P_WEXIT >> flag is set and even past the place where p_limit is freed and reset to >> NULL. >> At that place the thread calls prison_proc_free(), which calls >> prison_deref(). >> Then, we see that in prison_deref() the thread gets a page fault because >> of what >> seems like a NULL pointer dereference. =C2=A0That's just the start of th= e >> problem and >> its root cause. >> >> Then, trap_pfault() gets invoked and, because addresses close to NULL lo= ok >> like >> userspace addresses, vm_fault/vm_fault_hold gets called, which in its tu= rn >> goes >> on to call vm_map_growstack. =C2=A0First thing that vm_map_growstack doe= s is a >> call >> to lim_cur(), but because p_limit is already NULL, that call results in = a >> NULL >> pointer dereference and a page fault. =C2=A0Goto the beginning of this >> paragraph. >> >> So we get this recursion of sorts, which only ends when a stack is >> exhausted and >> a CPU generates a double-fault. > > BTW, does anyone has an idea why the thread in question would "disappear" > from > the kgdb's point of view? > > (kgdb) p cpuid_to_pcpu[2]->pc_curthread->td_tid > $3 =3D 102057 > (kgdb) tid 102057 > invalid tid > > info threads also doesn't list the thread. > > Is it because the panic happened while the thread was somewhere in exit1(= )? > is there an easy way to examine its stack in this case? Yes it is likely it. 'tid' command should lookup the tid_to_thread() table (or similar name) which returns NULL, which means the thread has past beyond the point it was in the lookup table. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Aug 18 21:30:35 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58BC41065673 for ; Thu, 18 Aug 2011 21:30:35 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E363B8FC0A for ; Thu, 18 Aug 2011 21:30:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Ce3t3CtqWnZjAVJeSjWQ9jY8JYOkD2y9mo5BIdrcKp8=; b=B7Vme87m2pDFF3d8uzqnR4r2BMfxcYpiJHOm/HBZ4TulcF/RtIBqW5X/vzI99UpbCFfPEErXv/JEhHoJOaIDvQ1y9tj2NlfrTzKfinIbBHdO8Mcphb1/O1RRVO7d0I4dQDhFSbq3m71JdcIbMxdRCTN8PA4hJZsOmYqTPTM0CBhr0lbsnMf37HgFSsjCXzRMdHuKQHlXEIVcOAB9WQJ9IFy6Tet/pPSj5u35q4CMR+JCUP9ZdOeNKHndMoJNzLG2mEiu6ufnsff59CvEAQcyhE5UQy4wdgJrKT2P9Ztr7ZvK7Y3kutLnp8ynnj4UajZOM5jbGwx+Kzq5RNyB3kkrFg==; Received: from phoenix.codelabs.ru (ppp91-77-176-196.pppoe.mtu-net.ru [91.77.176.196]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1QuAAa-000LW4-Sv; Fri, 19 Aug 2011 01:30:33 +0400 Date: Fri, 19 Aug 2011 01:30:30 +0400 From: Eygene Ryabinkin To: Matt Burke Message-ID: References: <4E4A5DFC.7010807@icritical.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Oiv9uiLrevHtW1RS" Content-Disposition: inline In-Reply-To: <4E4A5DFC.7010807@icritical.com> Sender: rea@codelabs.ru Cc: freebsd-hackers@freebsd.org Subject: Re: Alternate source trees X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:30:35 -0000 --Oiv9uiLrevHtW1RS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Tue, Aug 16, 2011 at 01:09:32PM +0100, Matt Burke wrote: > How does the build process know about the non-symlinked path anyway? > I can't see where (or understand why) it uses "pwd -P" Make(1)'s .OBJDIR is used: {{{ .OBJDIR A path to the directory where the targets are built. = At startup, make searches for an alternate directory to place target files. It will attempt to change into th= is special directory and will search this directory for makefiles not found in the current directory. The fol- lowing directories are tried in order: 1. ${MAKEOBJDIRPREFIX}/`pwd` 2. ${MAKEOBJDIR} 3. obj.${MACHINE} 4. obj 5. /usr/obj/`pwd` The first directory that make successfully changes into is used. If either MAKEOBJDIRPREFIX or MAKEOBJDIR is = set in the environment but make is unable to change into t= he corresponding directory, then the current directory is used without checking the remainder of the list. If t= hey are undefined and make is unable to change into any of the remaining three directories, then the current dire= c- tory is used. Note, that MAKEOBJDIRPREFIX and MAKEOBJ= DIR must be environment variables and should not be set on make's command line. The make utility sets .OBJDIR to the canonical path gi= ven by getcwd(3). }}} getcwd(3) always fully resolves current path, so symlinking won't be taken into account. > I'm trying to setup a box to do automated FreeBSD builds for other hosts > from multiple source trees. >=20 > I have a couple of source trees mounted - for legibility's sake let's say > /build/stable and /build/current. I also have a few obj dirs for different > targets. The current obj tree is symlinked to /usr/obj, and this works fi= ne. >=20 > The problem comes when I symlink /usr/src: when I buildworld, I get > /usr/obj/build/current/[...] instead of the desired /usr/obj/usr/src/[...] > This is presumably fine when installing on the same machine, but it breaks > when using it on another host with /usr/src and /usr/obj mounted over nfs. Hmm, current Makefile system for src sets MAKEOBJDIRPREFIX via ?=3D, so you're out of luck with symlinking on the build machine. May be you can mount /build/stable or /build/current on the target machine via NFS (and, of course, /usr/obj or other directory that you can choose with the MAKEOBJPREFIX, this leaves room for multi-architecture object trees on the same build host) and invoke make from the relevant directory? Another possibility, if for some reason you want /usr/src to point to the correct place at your "destination" machines, to always mount /build across hosts where you're installing the stuff and to symlink /usr/src to the proper location inside the /build. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --Oiv9uiLrevHtW1RS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iF4EAREIAAYFAk5NhHYACgkQFq+eroFS7PtavgD/UnTX8SK1QnKL948YH9rJK89M gUNKktxD2fCHHAwZAlEA/iBTJ3laLeXgguN/KwNtc+pL8zv08uLkWrUw7MOmN11u =8T5P -----END PGP SIGNATURE----- --Oiv9uiLrevHtW1RS-- From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 02:26:30 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 874D9106566B for ; Fri, 19 Aug 2011 02:26:30 +0000 (UTC) (envelope-from ttsestt@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0CC8D8FC0C for ; Fri, 19 Aug 2011 02:26:29 +0000 (UTC) Received: by bkat8 with SMTP id t8so2536719bka.13 for ; Thu, 18 Aug 2011 19:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=tHXmEldQxu9lCBEdhSBnDzmdbfULpclVQ+AkRD1YwBo=; b=efffWxPhEfqw42A+6IZQlSjA2UwCPglSyMUTR+PPU8GQk3hyFGHc6V6gvulZygIDDM Xi0tqDJPHw7q6/V5gC6P8n4nkbS1+gxbjHE+nBtqgQoazjyNh/xN/MNL3d/yO6tNO4Bf m1iuPz2RE3a+JMw9Itlk8F0HOwojo9X3yrzIw= Received: by 10.204.148.205 with SMTP id q13mr77232bkv.179.1313720788819; Thu, 18 Aug 2011 19:26:28 -0700 (PDT) Received: from localhost (tor1.spider007.net [194.145.200.128]) by mx.google.com with ESMTPS id n11sm893994bkd.14.2011.08.18.19.26.20 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 19:26:25 -0700 (PDT) From: Test Rat To: timp References: <868vqt0xuc.fsf@gmail.com> <1313663436600-4711635.post@n5.nabble.com> Date: Fri, 19 Aug 2011 06:26:18 +0400 In-Reply-To: <1313663436600-4711635.post@n5.nabble.com> (timp's message of "Thu, 18 Aug 2011 03:30:36 -0700 (PDT)") Message-ID: <86hb5euofp.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:26:30 -0000 timp writes: > Hi! > I just tried you patch on latest current with clang. > > [root@current64 /usr/src]# uname -a > FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MSK > 2011 mox@current64:/usr/obj/usr/src/sys/GENERIC amd64 > > [root@current64 /usr/src]# patch < ~/nvi2-freebsd-2011-08-17.diff [...] > ===> usr.bin/vi (depend) > make: don't know how to make cl_bsd.c. Stop > *** Error code 2 Use `-p0' otherwise new directories won't be created. This is documented in patch(1). And cl_bsd.c ended up in current directory (/usr/src) $ diffstat ~/nvi2-freebsd-2011-08-17.diff.gz | fgrep cl_bsd.c contrib/nvi2/cl/cl_bsd.c | 346 +++ Zhihao Yuan writes: > The patch will create contrib/nvi2, and it will not remove the unused > contrib/nvi (patch(1) can not really remove files anyway). patch(1) can remove *empty* files with `-E', e.g. $ svn rm UPDATING $ svn di UPDATING | patch -E -d /usr/src From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 03:15:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88DAE106566B for ; Fri, 19 Aug 2011 03:15:48 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 60C708FC08 for ; Fri, 19 Aug 2011 03:15:48 +0000 (UTC) Received: by pzk33 with SMTP id 33so6742925pzk.18 for ; Thu, 18 Aug 2011 20:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=O+IqUffeWdfd3VKM8iueoFf3UjgyP1HqdWlrdnclzZQ=; b=K6V1unb9odSKrhm+N2NDXfwbPtWfTx12mHY9CRYx0a/6SPmrq7URa5QwsT9g926ufV Dt7SImBp6MoMXmK++rCyOiw0KUVxvZ5zS4pcZoT59Gwbig6ruCdgNs5PE7UEJ+2NV4Me XGolhxZvXxPfytZx/LWckPMMu8dqjogzZRUgw= MIME-Version: 1.0 Received: by 10.142.14.8 with SMTP id 8mr739656wfn.189.1313723747885; Thu, 18 Aug 2011 20:15:47 -0700 (PDT) Received: by 10.142.180.10 with HTTP; Thu, 18 Aug 2011 20:15:47 -0700 (PDT) In-Reply-To: <86hb5euofp.fsf@gmail.com> References: <868vqt0xuc.fsf@gmail.com> <1313663436600-4711635.post@n5.nabble.com> <86hb5euofp.fsf@gmail.com> Date: Thu, 18 Aug 2011 22:15:47 -0500 Message-ID: From: Zhihao Yuan To: Test Rat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, timp Subject: Re: [nvi-iconv]Call for test X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 03:15:48 -0000 On Thu, Aug 18, 2011 at 9:26 PM, Test Rat wrote: > timp writes: > >> Hi! >> I just tried you patch on latest current with clang. >> >> [root@current64 /usr/src]# uname -a >> FreeBSD current64 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Aug 18 03:56:45 MS= K >> 2011 =C2=A0 =C2=A0 mox@current64:/usr/obj/usr/src/sys/GENERIC =C2=A0amd6= 4 >> >> [root@current64 /usr/src]# patch < ~/nvi2-freebsd-2011-08-17.diff > [...] >> =3D=3D=3D> usr.bin/vi (depend) >> make: don't know how to make cl_bsd.c. Stop >> *** Error code 2 > > Use `-p0' otherwise new directories won't be created. This is documented > in patch(1). And cl_bsd.c ended up in current directory (/usr/src) > > =C2=A0$ diffstat ~/nvi2-freebsd-2011-08-17.diff.gz | fgrep cl_bsd.c > =C2=A0 contrib/nvi2/cl/cl_bsd.c =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| =C2=A0346 +++ zzz... I always use -p0 but I did not know what it does... > > Zhihao Yuan writes: >> The patch will create contrib/nvi2, and it will not remove the unused >> contrib/nvi (patch(1) can not really remove files anyway). > > patch(1) can remove *empty* files with `-E', e.g. > > =C2=A0$ svn rm UPDATING > =C2=A0$ svn di UPDATING | patch -E -d /usr/src Got it. But removing contrib/nvi with patch will just double the patch size anyway. A svn rm will do it if some day the patch got committed. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 10:45:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40144106566C for ; Fri, 19 Aug 2011 10:45:04 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id F1D768FC17 for ; Fri, 19 Aug 2011 10:45:03 +0000 (UTC) Received: by vws18 with SMTP id 18so2991212vws.13 for ; Fri, 19 Aug 2011 03:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GcRrTTgJggLYJ9hMR3AwhaE7AghTbL3HWVpS6N59P4A=; b=CwRXh24ls/0mHSMlWo7zIC1OXDG+DD2RfKGx/7gUj7RL8VAA9eQoSjVtOn1Th6P/4v 5S1XDzRiAbPx7jJZEQTy3uu1neTx/EEwyoUCqmJWYnpafvj5wnFZOtyFQGws24ZaBkvQ 0uyYuDNRNgQDBVKLRljw8ogWEFT9LZAubuu/s= MIME-Version: 1.0 Received: by 10.52.182.165 with SMTP id ef5mr1899978vdc.346.1313748930344; Fri, 19 Aug 2011 03:15:30 -0700 (PDT) Received: by 10.52.162.73 with HTTP; Fri, 19 Aug 2011 03:15:30 -0700 (PDT) In-Reply-To: <4E4D50CD.5080806@rawbw.com> References: <4E4D50CD.5080806@rawbw.com> Date: Fri, 19 Aug 2011 11:15:30 +0100 Message-ID: From: Tom Evans To: Yuri Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: ZFS installs on HD with 4k physical blocks without any warning as on 512 block size device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 10:45:04 -0000 On Thu, Aug 18, 2011 at 6:50 PM, Yuri wrote: > Some latest hard drives have logical sectors of 512 byte when they actually > have 4k physical sectors. Here is the document describing what to do in such > case: > http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html . > For UFS: newfs -U -f 4096 /dev/da0 > For ZFS: gnop create -S 4096 /dev/da0 && zpool create data /dev/da0.nop > > I am sure most people just install such hard drive without doing this and > potentially get suboptimal performance since they aren't aware about this. > Shouldn't UFS and ZFS drivers be able to either read the right sector size > from the underlying device or at least issue a warning? > > Yuri The device never reports the actual sector size, so unless FreeBSD keeps a database of 4k sector hard drives that report as 512 byte sector hard drives, there is nothing that can be done. Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 11:03:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B2B1065670 for ; Fri, 19 Aug 2011 11:03:01 +0000 (UTC) (envelope-from aboutbus@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6597E8FC08 for ; Fri, 19 Aug 2011 11:03:01 +0000 (UTC) Received: by gyd10 with SMTP id 10so2441760gyd.13 for ; Fri, 19 Aug 2011 04:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=XkMngYPZ8uyEzpPqYAZFFkBpWKusZDoFnRFbjfItezQ=; b=HNRWKabsyffoMpuSh6CdM+TQwrdQy9Ueh3wydapwD/AhTW6GyOvHjDZAsjADYo7YAs zuO+hteU+PftLEPO+i+M+syPkVPYvTpOXgv9CbaRzVlX9SK7rKNxduwHrn2vW74admwn TS2vcq7gTgxFL5b72st5lm4EPGGEIzSQtwTi0= MIME-Version: 1.0 Received: by 10.236.195.73 with SMTP id o49mr6404706yhn.23.1313750005356; Fri, 19 Aug 2011 03:33:25 -0700 (PDT) Received: by 10.236.110.9 with HTTP; Fri, 19 Aug 2011 03:33:25 -0700 (PDT) Date: Fri, 19 Aug 2011 13:33:25 +0300 Message-ID: From: about bus To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kqueue + Libevent X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 11:03:01 -0000 Hello! I've got some interesting problem with my own server which use Libevent and Kqueue. Kqueue holds some sockets for a long time (while reading data) and gives it back to application when another side closes connection. I have server with FreeBSD 7.2 which serves several thousands requests per second. Nginx -> statical requests, images -> backend for dynamical requests: Libevent based http server written on C Sometimes, about 0.1% of request, Nginx displays error: "Operation timed out while reading response from upstream." Switching Libevent from Kqueue to Poll in my http server fixes the problem. Poll works fine without errors in Nginx log file. Debug output for timeouted requests from Libevent: 1) Libevent accepts incoming connection from Nginx. 2) Libevent adds socket to Kqueue for waiting incoming data with HTTP request. 3) No events on socket for 60 seconds, no received data. (60 - timeout value in Nginx config) 4) On the another side Nginx closes connection and displays timeout error. 5) At the same time Kqueue reports about incoming data and returns socket to Libevent. 6) Libevent reads correct HTTP request from socket and passes it to my handler. Why Kqueue does not reports about read event for so long time? Why Kqueue do it only when another side closes connection? It is strange, because Poll does not have such problems. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 11:39:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F11A7106564A for ; Fri, 19 Aug 2011 11:39:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B10098FC13 for ; Fri, 19 Aug 2011 11:39:38 +0000 (UTC) Received: by gwb15 with SMTP id 15so1822668gwb.13 for ; Fri, 19 Aug 2011 04:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UKvonWTlHXKEur35X5so4XmRmZQEq/lXluS5tsAk7Sw=; b=aRo1+iMKH9Ogdeo6IMKZonlgY/ysZYhdxyrRR5r99BWgNZo4c/+vEBVhNfKcDYG069 5PaoERl383juEe/NxjWyqFytNsdOnVPUncnpfVTL/hQmZ0/rH3TQtnU72U9UqSsw08VV h2/1K95LOx0Gs6Hqc1CJHSTej4MuJLRfJRe5Q= MIME-Version: 1.0 Received: by 10.151.12.1 with SMTP id p1mr2187421ybi.272.1313752251894; Fri, 19 Aug 2011 04:10:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Fri, 19 Aug 2011 04:10:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 19:10:51 +0800 X-Google-Sender-Auth: Bu4-lmxmkl9x7uz4v4CkBbf8Pp8 Message-ID: From: Adrian Chadd To: about bus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kqueue + Libevent X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 11:39:39 -0000 I've not seen this happen before, are you sure that libevent's kqueue code is properly removing all the pending events for a given FD when it's closed? Adrian On 19 August 2011 18:33, about bus wrote: > Hello! > > I've got some interesting problem with my own server which use Libevent a= nd > Kqueue. > Kqueue holds some sockets for a long time (while reading data) and gives = it > back to application when another side closes connection. > > I have server with FreeBSD 7.2 which serves several thousands requests pe= r > second. > Nginx -> statical requests, images > =A0 =A0 =A0 =A0 -> backend for dynamical requests: Libevent based http se= rver > written on C > > Sometimes, about 0.1% of request, Nginx displays error: "Operation timed = out > while reading response from upstream." > Switching Libevent from Kqueue to Poll in my http server fixes the proble= m. > Poll works fine without errors in Nginx log file. > > Debug output for timeouted requests from Libevent: > 1) Libevent accepts incoming connection from Nginx. > 2) Libevent adds socket to Kqueue for waiting incoming data with HTTP > request. > 3) No events on socket for 60 seconds, no received data. (60 - timeout va= lue > in Nginx config) > 4) On the another side Nginx closes connection and displays timeout error= . > 5) At the same time Kqueue reports about incoming data and returns socket= to > Libevent. > 6) Libevent reads correct HTTP request from socket and passes it to my > handler. > > Why Kqueue does not reports about read event for so long time? > Why Kqueue do it only when another side closes connection? > It is strange, because Poll does not have such problems. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 12:14:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE108106566B; Fri, 19 Aug 2011 12:14:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C011E8FC12; Fri, 19 Aug 2011 12:14:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 69FD446B35; Fri, 19 Aug 2011 08:14:02 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E7B738A02F; Fri, 19 Aug 2011 08:14:01 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 19 Aug 2011 08:14:00 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> <4E4D717F.3090802@FreeBSD.org> In-Reply-To: <4E4D717F.3090802@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108190814.00885.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 19 Aug 2011 08:14:02 -0400 (EDT) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 12:14:03 -0000 On Thursday, August 18, 2011 4:09:35 pm Andriy Gapon wrote: > on 17/08/2011 23:21 Andriy Gapon said the following: > > It seems like everything starts with some kind of a race between terminating > > processes in a jail and termination of the jail itself. This is where the > > details are very thin so far. What we see is that a process (http) is in > > exit(2) syscall, in exit1() function actually, and past the place where P_WEXIT > > flag is set and even past the place where p_limit is freed and reset to NULL. > > At that place the thread calls prison_proc_free(), which calls prison_deref(). > > Then, we see that in prison_deref() the thread gets a page fault because of what > > seems like a NULL pointer dereference. That's just the start of the problem and > > its root cause. > > > > Then, trap_pfault() gets invoked and, because addresses close to NULL look like > > userspace addresses, vm_fault/vm_fault_hold gets called, which in its turn goes > > on to call vm_map_growstack. First thing that vm_map_growstack does is a call > > to lim_cur(), but because p_limit is already NULL, that call results in a NULL > > pointer dereference and a page fault. Goto the beginning of this paragraph. > > > > So we get this recursion of sorts, which only ends when a stack is exhausted and > > a CPU generates a double-fault. > > BTW, does anyone has an idea why the thread in question would "disappear" from > the kgdb's point of view? > > (kgdb) p cpuid_to_pcpu[2]->pc_curthread->td_tid > $3 = 102057 > (kgdb) tid 102057 > invalid tid > > info threads also doesn't list the thread. > > Is it because the panic happened while the thread was somewhere in exit1()? Yes, it is a bug in kgdb that it only walks allproc and not zombproc. Try this: Index: kthr.c =================================================================== --- kthr.c (revision 224879) +++ kthr.c (working copy) @@ -73,11 +73,52 @@ kgdb_thr_first(void) return (first); } +static void +kgdb_thr_add_procs(uintptr_t paddr) +{ + struct proc p; + struct thread td; + struct kthr *kt; + CORE_ADDR addr; + + while (paddr != 0) { + if (kvm_read(kvm, paddr, &p, sizeof(p)) != sizeof(p)) { + warnx("kvm_read: %s", kvm_geterr(kvm)); + break; + } + addr = (uintptr_t)TAILQ_FIRST(&p.p_threads); + while (addr != 0) { + if (kvm_read(kvm, addr, &td, sizeof(td)) != + sizeof(td)) { + warnx("kvm_read: %s", kvm_geterr(kvm)); + break; + } + kt = malloc(sizeof(*kt)); + kt->next = first; + kt->kaddr = addr; + if (td.td_tid == dumptid) + kt->pcb = dumppcb; + else if (td.td_state == TDS_RUNNING && stoppcbs != 0 && + CPU_ISSET(td.td_oncpu, &stopped_cpus)) + kt->pcb = (uintptr_t)stoppcbs + + sizeof(struct pcb) * td.td_oncpu; + else + kt->pcb = (uintptr_t)td.td_pcb; + kt->kstack = td.td_kstack; + kt->tid = td.td_tid; + kt->pid = p.p_pid; + kt->paddr = paddr; + kt->cpu = td.td_oncpu; + first = kt; + addr = (uintptr_t)TAILQ_NEXT(&td, td_plist); + } + paddr = (uintptr_t)LIST_NEXT(&p, p_list); + } +} + struct kthr * kgdb_thr_init(void) { - struct proc p; - struct thread td; long cpusetsize; struct kthr *kt; CORE_ADDR addr; @@ -113,37 +154,11 @@ kgdb_thr_init(void) stoppcbs = kgdb_lookup("stoppcbs"); - while (paddr != 0) { - if (kvm_read(kvm, paddr, &p, sizeof(p)) != sizeof(p)) { - warnx("kvm_read: %s", kvm_geterr(kvm)); - break; - } - addr = (uintptr_t)TAILQ_FIRST(&p.p_threads); - while (addr != 0) { - if (kvm_read(kvm, addr, &td, sizeof(td)) != - sizeof(td)) { - warnx("kvm_read: %s", kvm_geterr(kvm)); - break; - } - kt = malloc(sizeof(*kt)); - kt->next = first; - kt->kaddr = addr; - if (td.td_tid == dumptid) - kt->pcb = dumppcb; - else if (td.td_state == TDS_RUNNING && stoppcbs != 0 && - CPU_ISSET(td.td_oncpu, &stopped_cpus)) - kt->pcb = (uintptr_t) stoppcbs + sizeof(struct pcb) * td.td_oncpu; - else - kt->pcb = (uintptr_t)td.td_pcb; - kt->kstack = td.td_kstack; - kt->tid = td.td_tid; - kt->pid = p.p_pid; - kt->paddr = paddr; - kt->cpu = td.td_oncpu; - first = kt; - addr = (uintptr_t)TAILQ_NEXT(&td, td_plist); - } - paddr = (uintptr_t)LIST_NEXT(&p, p_list); + kgdb_thr_add_procs(paddr); + addr = kgdb_lookup("zombproc"); + if (addr != 0) { + kvm_read(kvm, addr, &paddr, sizeof(paddr)); + kgdb_thr_add_procs(paddr); } curkthr = kgdb_thr_lookup_tid(dumptid); if (curkthr == NULL) > is there an easy way to examine its stack in this case? Hmm, you can use something like this from my kgdb macros. For amd64: # Do a backtrace given %rip and %rbp as args define bt set $_rip = $arg0 set $_rbp = $arg1 set $i = 0 while ($_rbp != 0 || $_rip != 0) printf "%2d: pc ", $i if ($_rip != 0) x/1i $_rip else printf "\n" end if ($_rbp == 0) set $_rip = 0 else set $fr = (struct amd64_frame *)$_rbp set $_rbp = $fr->f_frame set $_rip = $fr->f_retaddr set $i = $i + 1 end end end document bt Given values for %rip and %rbp, perform a manual backtrace. end define btf bt $arg0.tf_rip $arg0.tf_rbp end document btf Do a manual backtrace from a specified trapframe. end For i386: # Do a backtrace given %eip and %ebp as args define bt set $_eip = $arg0 set $_ebp = $arg1 set $i = 0 while ($_ebp != 0 || $_eip != 0) printf "%2d: pc ", $i if ($_eip != 0) x/1i $_eip else printf "\n" end if ($_ebp == 0) set $_eip = 0 else set $fr = (struct i386_frame *)$_ebp set $_ebp = $fr->f_frame set $_eip = $fr->f_retaddr set $i = $i + 1 end end end document bt Given values for %eip and %ebp, perform a manual backtrace. end define btf bt $arg0.tf_eip $arg0.tf_ebp end document btf Do a manual backtrace from a specified trapframe. end -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 12:17:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF37B1065670 for ; Fri, 19 Aug 2011 12:17:55 +0000 (UTC) (envelope-from pdegoeje@service2media.com) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 30AD98FC08 for ; Fri, 19 Aug 2011 12:17:54 +0000 (UTC) Received: from pieter-dev.localnet (lux.student.utwente.nl [130.89.161.112]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p7JBwnCY015547; Fri, 19 Aug 2011 13:58:49 +0200 From: Pieter de Goeje Organization: Service2Media To: freebsd-hackers@freebsd.org Date: Fri, 19 Aug 2011 13:58:49 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; ) References: <4E4D50CD.5080806@rawbw.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201108191358.49285.pdegoeje@service2media.com> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pdegoeje@service2media.com X-Spam-Status: No X-Mailman-Approved-At: Fri, 19 Aug 2011 12:28:09 +0000 Cc: Tom Evans , Yuri Subject: Re: ZFS installs on HD with 4k physical blocks without any warning as on 512 block size device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 12:17:55 -0000 On Friday, August 19, 2011 12:15:30 PM Tom Evans wrote: > On Thu, Aug 18, 2011 at 6:50 PM, Yuri wrote: > > Some latest hard drives have logical sectors of 512 byte when they > > actually have 4k physical sectors. Here is the document describing what > > to do in such case: > > http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html . > > For UFS: newfs -U -f 4096 /dev/da0 > > For ZFS: gnop create -S 4096 /dev/da0 && zpool create data /dev/da0.nop > > > > I am sure most people just install such hard drive without doing this and > > potentially get suboptimal performance since they aren't aware about > > this. Shouldn't UFS and ZFS drivers be able to either read the right > > sector size from the underlying device or at least issue a warning? > > > > Yuri > > The device never reports the actual sector size, so unless FreeBSD > keeps a database of 4k sector hard drives that report as 512 byte > sector hard drives, there is nothing that can be done. > > Cheers > > Tom In -current at least there is a quirk table for these drives - the stripe size is set to 4K. Other tools use this size to align stuff on. Also, the default fragment size of UFS was increased to 4K. - Pieter From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 12:50:40 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE3F106566C for ; Fri, 19 Aug 2011 12:50:40 +0000 (UTC) (envelope-from aled.w.morris@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 863388FC15 for ; Fri, 19 Aug 2011 12:50:40 +0000 (UTC) Received: by vws18 with SMTP id 18so3089187vws.13 for ; Fri, 19 Aug 2011 05:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vPB9J7+cQLw0PeYFgrHvZcteaQOD4QHQFgekazFQjYA=; b=pbYZsNJKBpj2qxxZGTj8o3W69gNk6Sacl2cCJ3t+OEybt09s0z6tgN77mczu3NubNG pKG6pk6aVgj7SkQa9H2/2is6ABqxKLwmsjlC0KmDNUdBuE9v/bkV30TKoR/rXPHcdzn0 dfa0KfAnyk84BCoez9fc1r1nNVGXcOWD5nN14= MIME-Version: 1.0 Received: by 10.52.19.133 with SMTP id f5mr1993387vde.210.1313756460776; Fri, 19 Aug 2011 05:21:00 -0700 (PDT) Sender: aled.w.morris@googlemail.com Received: by 10.52.188.196 with HTTP; Fri, 19 Aug 2011 05:21:00 -0700 (PDT) In-Reply-To: References: <4E4D50CD.5080806@rawbw.com> Date: Fri, 19 Aug 2011 13:21:00 +0100 X-Google-Sender-Auth: iF3hnL331Pk_tgT2iKb_e2T_FRo Message-ID: From: Aled Morris To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: ZFS installs on HD with 4k physical blocks without any warning as on 512 block size device X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 12:50:41 -0000 On 19 August 2011 11:15, Tom Evans wrote: > On Thu, Aug 18, 2011 at 6:50 PM, Yuri wrote: > > Some latest hard drives have logical sectors of 512 byte when they > actually > > have 4k physical sectors. > ... > Shouldn't UFS and ZFS drivers be able to either read the right sector size > > from the underlying device or at least issue a warning? > > The device never reports the actual sector size, so unless FreeBSD > keeps a database of 4k sector hard drives that report as 512 byte > sector hard drives, there is nothing that can be done. > > At what point should we change the default in newfs/zfs to 4k? I guess formatting the filesystem for 4k sectors on a 512b drive would still work but it would be suboptimal. What would the performance penalty be in reality? Aled From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 16:15:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEFB41065670 for ; Fri, 19 Aug 2011 16:15:02 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF4318FC17 for ; Fri, 19 Aug 2011 16:15:02 +0000 (UTC) Received: by gyd10 with SMTP id 10so2692601gyd.13 for ; Fri, 19 Aug 2011 09:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hj1FoYsRF5kKfXQapezFwCuXz/6SB6lr2ySwX7HlfRY=; b=oWr5oq5f9maw6bOo1WBsLO+aXsdWz1j0AnD7ln7TQHbONBMIvn62HcOmPFt6mpzzX6 Up6HXEeqM+6LqCDt4xutEc7CNHhbDh6J00YOY4Sykics3ZQP+tZhqaL5vsZbIse7/PV5 gsRq+o0hV+cqiB7xMItWTQZO5tSzF4xRAz4cQ= MIME-Version: 1.0 Received: by 10.236.152.4 with SMTP id c4mr8961927yhk.52.1313770501906; Fri, 19 Aug 2011 09:15:01 -0700 (PDT) Received: by 10.231.14.68 with HTTP; Fri, 19 Aug 2011 09:15:01 -0700 (PDT) Date: Fri, 19 Aug 2011 11:15:01 -0500 Message-ID: From: Zhihao Yuan To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: snd_hda does no output to headphones X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:15:03 -0000 Hi, I think I must get this problem resolved. I work at night, so without the headphones support, I can listen to music or watch video at that time. The machine is HP Elitebook 8540w. ~> uname -a FreeBSD compaq.yuetime 8.2-STABLE FreeBSD 8.2-STABLE #6 r224860: Sun Aug 14 15:17:57 CDT 2011 lichray@compaq.yuetime:/usr/obj/home/lichray/devel/freebsd-stable/sys/HOUKA= GO amd64 I have already set up the default_unit: ~> cat /dev/sndstat FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) Installed devices: pcm0: (play) pcm1: (play) pcm2: (play) pcm3: (play) pcm4: (play/rec) default pcm5: (play) pindump: hdac1: Dumping AFG cad=3D0 nid=3D1 pins: hdac1: =C2=A0nid 10 0x2121101f as =C2=A01 seq 15 =C2=A0 =C2=A0Headphones = =C2=A0Jack jack =C2=A01 loc 33 color =C2=A0 Black misc 0 hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT HP =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sense: 0x00000000 hdac1: =C2=A0nid 11 0x03a1102e as =C2=A02 seq 14 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Mic =C2=A0Jack jack =C2=A01 loc =C2=A03 color =C2=A0 Black misc 0 hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 VREF Sense: 0x00000000 hdac1: =C2=A0nid 12 0x90a70120 as =C2=A02 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Mic Fixed jack =C2=A07 loc 16 color Unknown misc 1 hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 VREF Sense: 0x00000000 hdac1: =C2=A0nid 13 0x90170110 as =C2=A01 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = Speaker Fixed jack =C2=A07 loc 16 color Unknown misc 1 hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sense: 0x00000000 hdac1: =C2=A0nid 14 0x21811040 as =C2=A04 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = Line-in =C2=A0Jack jack =C2=A01 loc 33 color =C2=A0 Black misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 VREF Sense: 0x00000000 hdac1: =C2=A0nid 15 0x03211030 as =C2=A03 seq =C2=A00 =C2=A0 =C2=A0Headphon= es =C2=A0Jack jack =C2=A01 loc =C2=A03 color =C2=A0 Black misc 0 hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sense: 0x00000000 hdac1: =C2=A0nid 20 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN OUT hdac1: =C2=A0nid 24 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN hdac1: =C2=A0nid 25 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN hdac1: =C2=A0nid 30 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT hdac1: =C2=A0nid 31 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0EAPD hdac1: =C2=A0nid 32 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other =C2=A0None jack =C2=A00 loc =C2=A00 color Unknown misc 0 [DISABLED] hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT hdac1: NumGPIO=3D8 NumGPO=3D0 NumGPI=3D0 GPIWake=3D1 GPIUnsol=3D1 hdac1: GPIO: data=3D0x00000000 enable=3D0x00000000 direction=3D0x00000000 hdac1: =C2=A0 =C2=A0 =C2=A0 wake=3D0x00000000 =C2=A0unsol=3D0x00000000 =C2= =A0 =C2=A0sticky=3D0x00000000 A full boot dmesg is availiable at here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-August/012389.ht= ml The sound comes from the internal speaker, and the internal record works. But the sound does not work on the headphones. I read many posts and the snd_hda(4), and I know I need to bind the headphones and the internal speaker to the same as, and I need to do the same on output. I think there must be some people who knows how to configure this here. Please give me some instructions. Thanks. --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 16:28:08 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82BE3106566C; Fri, 19 Aug 2011 16:28:08 +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 609F08FC17; Fri, 19 Aug 2011 16:28:06 +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 TAA02123; Fri, 19 Aug 2011 19:28:05 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E4E8F15.5030301@FreeBSD.org> Date: Fri, 19 Aug 2011 19:28:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk> <4E4C22D6.6070407@FreeBSD.org> <4E4D717F.3090802@FreeBSD.org> <201108190814.00885.jhb@freebsd.org> In-Reply-To: <201108190814.00885.jhb@freebsd.org> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:28:08 -0000 on 19/08/2011 15:14 John Baldwin said the following: > Yes, it is a bug in kgdb that it only walks allproc and not zombproc. Try this: The patch worked perfectly well for me, thank you! > Index: kthr.c > =================================================================== > --- kthr.c (revision 224879) > +++ kthr.c (working copy) > @@ -73,11 +73,52 @@ kgdb_thr_first(void) > return (first); > } > > +static void > +kgdb_thr_add_procs(uintptr_t paddr) > +{ > + struct proc p; > + struct thread td; > + struct kthr *kt; > + CORE_ADDR addr; > + > + while (paddr != 0) { > + if (kvm_read(kvm, paddr, &p, sizeof(p)) != sizeof(p)) { > + warnx("kvm_read: %s", kvm_geterr(kvm)); > + break; > + } > + addr = (uintptr_t)TAILQ_FIRST(&p.p_threads); > + while (addr != 0) { > + if (kvm_read(kvm, addr, &td, sizeof(td)) != > + sizeof(td)) { > + warnx("kvm_read: %s", kvm_geterr(kvm)); > + break; > + } > + kt = malloc(sizeof(*kt)); > + kt->next = first; > + kt->kaddr = addr; > + if (td.td_tid == dumptid) > + kt->pcb = dumppcb; > + else if (td.td_state == TDS_RUNNING && stoppcbs != 0 && > + CPU_ISSET(td.td_oncpu, &stopped_cpus)) > + kt->pcb = (uintptr_t)stoppcbs + > + sizeof(struct pcb) * td.td_oncpu; > + else > + kt->pcb = (uintptr_t)td.td_pcb; > + kt->kstack = td.td_kstack; > + kt->tid = td.td_tid; > + kt->pid = p.p_pid; > + kt->paddr = paddr; > + kt->cpu = td.td_oncpu; > + first = kt; > + addr = (uintptr_t)TAILQ_NEXT(&td, td_plist); > + } > + paddr = (uintptr_t)LIST_NEXT(&p, p_list); > + } > +} > + > struct kthr * > kgdb_thr_init(void) > { > - struct proc p; > - struct thread td; > long cpusetsize; > struct kthr *kt; > CORE_ADDR addr; > @@ -113,37 +154,11 @@ kgdb_thr_init(void) > > stoppcbs = kgdb_lookup("stoppcbs"); > > - while (paddr != 0) { > - if (kvm_read(kvm, paddr, &p, sizeof(p)) != sizeof(p)) { > - warnx("kvm_read: %s", kvm_geterr(kvm)); > - break; > - } > - addr = (uintptr_t)TAILQ_FIRST(&p.p_threads); > - while (addr != 0) { > - if (kvm_read(kvm, addr, &td, sizeof(td)) != > - sizeof(td)) { > - warnx("kvm_read: %s", kvm_geterr(kvm)); > - break; > - } > - kt = malloc(sizeof(*kt)); > - kt->next = first; > - kt->kaddr = addr; > - if (td.td_tid == dumptid) > - kt->pcb = dumppcb; > - else if (td.td_state == TDS_RUNNING && stoppcbs != 0 && > - CPU_ISSET(td.td_oncpu, &stopped_cpus)) > - kt->pcb = (uintptr_t) stoppcbs + sizeof(struct pcb) * td.td_oncpu; > - else > - kt->pcb = (uintptr_t)td.td_pcb; > - kt->kstack = td.td_kstack; > - kt->tid = td.td_tid; > - kt->pid = p.p_pid; > - kt->paddr = paddr; > - kt->cpu = td.td_oncpu; > - first = kt; > - addr = (uintptr_t)TAILQ_NEXT(&td, td_plist); > - } > - paddr = (uintptr_t)LIST_NEXT(&p, p_list); > + kgdb_thr_add_procs(paddr); > + addr = kgdb_lookup("zombproc"); > + if (addr != 0) { > + kvm_read(kvm, addr, &paddr, sizeof(paddr)); > + kgdb_thr_add_procs(paddr); > } > curkthr = kgdb_thr_lookup_tid(dumptid); > if (curkthr == NULL) > >> is there an easy way to examine its stack in this case? > > Hmm, you can use something like this from my kgdb macros. Oh, I completely forgot about them. I hope I will remember where to search for the tricks next time I need them :-) Thank you again! > For amd64: > > # Do a backtrace given %rip and %rbp as args > define bt > set $_rip = $arg0 > set $_rbp = $arg1 > set $i = 0 > while ($_rbp != 0 || $_rip != 0) > printf "%2d: pc ", $i > if ($_rip != 0) > x/1i $_rip > else > printf "\n" > end > if ($_rbp == 0) > set $_rip = 0 > else > set $fr = (struct amd64_frame *)$_rbp > set $_rbp = $fr->f_frame > set $_rip = $fr->f_retaddr > set $i = $i + 1 > end > end > end > > document bt > Given values for %rip and %rbp, perform a manual backtrace. > end > > define btf > bt $arg0.tf_rip $arg0.tf_rbp > end > > document btf > Do a manual backtrace from a specified trapframe. > end > > For i386: > > # Do a backtrace given %eip and %ebp as args > define bt > set $_eip = $arg0 > set $_ebp = $arg1 > set $i = 0 > while ($_ebp != 0 || $_eip != 0) > printf "%2d: pc ", $i > if ($_eip != 0) > x/1i $_eip > else > printf "\n" > end > if ($_ebp == 0) > set $_eip = 0 > else > set $fr = (struct i386_frame *)$_ebp > set $_ebp = $fr->f_frame > set $_eip = $fr->f_retaddr > set $i = $i + 1 > end > end > end > > document bt > Given values for %eip and %ebp, perform a manual backtrace. > end > > define btf > bt $arg0.tf_eip $arg0.tf_ebp > end > > document btf > Do a manual backtrace from a specified trapframe. > end > -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 18:43:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9821065674; Fri, 19 Aug 2011 18:43:56 +0000 (UTC) (envelope-from aboutbus@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9FC88FC13; Fri, 19 Aug 2011 18:43:55 +0000 (UTC) Received: by yxn22 with SMTP id 22so1695352yxn.13 for ; Fri, 19 Aug 2011 11:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0fcTRmii/3+bnjkHOM6rK8xlYkxKk5SkKGs+TzFe3k=; b=wuAVrrwOIBK3jeQ1jnm39VRdKCqUAHlg69JKIcNFYvDcrJ1Dv1ADfWYXdnjkRD7u3b VdpwjaqYaxjM0jzy2PpB3rtjsHXjOZ3OFDYnH0fiV2H0NM+wVjqVAP9m6yhQH7Z0do/i dNXmV4RVw/rtDS2+SHLk/Q3E+mtyhCgR5iIu8= MIME-Version: 1.0 Received: by 10.236.195.73 with SMTP id o49mr621147yhn.23.1313779435156; Fri, 19 Aug 2011 11:43:55 -0700 (PDT) Received: by 10.236.110.9 with HTTP; Fri, 19 Aug 2011 11:43:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 21:43:55 +0300 Message-ID: From: about bus To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Kqueue + Libevent X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 18:43:56 -0000 I've added some debug output in libevent, before and after kevent function call. ### good one request 21:30:05 evhttp_get_request_connection: fd: 196 new request from 127.0.0.1:60010 21:30:05 kq_dispatch: fd: 196 set kevent filter: EVFILT_READ flags: EV_ADD 21:30:05 kq_dispatch: fd: 196 return kevent filter: EVFILT_READ flags: 0 data: 729 21:30:05 kq_dispatch: fd: 196 set kevent filter: EVFILT_READ flags: EV_DELETE 21:30:05 kq_dispatch: fd: 196 set kevent filter: EVFILT_WRITE flags: EV_ADD 21:30:05 kq_dispatch: fd: 196 return kevent filter: EVFILT_WRITE flags: 0 data: 28672 21:30:05 kq_dispatch: fd: 196 set kevent filter: EVFILT_WRITE flags: EV_DELETE 21:30:05 kq_dispatch: fd: 196 return kevent filter: EVFILT_WRITE flags: EV_ERROR data: 9 (EBADF) ### timeouted request 21:30:06 evhttp_get_request_connection: fd: 196 new request from 127.0.0.1:64308 21:30:06 kq_dispatch: fd: 196 set kevent filter: EVFILT_READ flags: EV_ADD 21:30:36 kq_dispatch: fd: 196 return kevent filter: EVFILT_READ flags: EV_EOF data: 450 21:30:36 kq_dispatch: fd: 196 set kevent filter: EVFILT_READ flags: EV_DELETE 21:30:36 kq_dispatch: fd: 196 set kevent filter: EVFILT_WRITE flags: EV_ADD 21:30:36 kq_dispatch: fd: 196 return kevent filter: EVFILT_WRITE flags: 0 data: 28672 21:30:36 kq_dispatch: fd: 196 set kevent filter: EVFILT_WRITE flags: EV_DELETE 21:30:36 kq_dispatch: fd: 196 return kevent filter: EVFILT_WRITE flags: EV_ERROR data: 9 (EBADF) There is problem between 21:30:06 and 21:30:36 timestamps. Libevent received socket from Kqueue with EV_EOF flag when nginx has closed connection. There is 30 seconds timeout value in nginx config file. On Fri, Aug 19, 2011 at 2:10 PM, Adrian Chadd wrote: > I've not seen this happen before, are you sure that libevent's kqueue > code is properly removing all the pending events for a given FD when > it's closed? > > > On 19 August 2011 18:33, about bus wrote: > > Hello! > > > > I've got some interesting problem with my own server which use Libevent > and > > Kqueue. > > Kqueue holds some sockets for a long time (while reading data) and gives > it > > back to application when another side closes connection. > > > > I have server with FreeBSD 7.2 which serves several thousands requests > per > > second. > > Nginx -> statical requests, images > > -> backend for dynamical requests: Libevent based http server > > written on C > > > > Sometimes, about 0.1% of request, Nginx displays error: "Operation timed > out > > while reading response from upstream." > > Switching Libevent from Kqueue to Poll in my http server fixes the > problem. > > Poll works fine without errors in Nginx log file. > > > > Debug output for timeouted requests from Libevent: > > 1) Libevent accepts incoming connection from Nginx. > > 2) Libevent adds socket to Kqueue for waiting incoming data with HTTP > > request. > > 3) No events on socket for 60 seconds, no received data. (60 - timeout > value > > in Nginx config) > > 4) On the another side Nginx closes connection and displays timeout > error. > > 5) At the same time Kqueue reports about incoming data and returns socket > to > > Libevent. > > 6) Libevent reads correct HTTP request from socket and passes it to my > > handler. > > > > Why Kqueue does not reports about read event for so long time? > > Why Kqueue do it only when another side closes connection? > > It is strange, because Poll does not have such problems. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 20:20:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5515B1065672 for ; Fri, 19 Aug 2011 20:20:23 +0000 (UTC) (envelope-from lichray@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 22BEE8FC16 for ; Fri, 19 Aug 2011 20:20:22 +0000 (UTC) Received: by iye7 with SMTP id 7so11359989iye.17 for ; Fri, 19 Aug 2011 13:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gQ0Rwjm1u94lH3NDynEcQ/ZiMH0hyzut9ciY5SUGomc=; b=sbvxPHvv6FflKm8R6OlLhbSdPQZ09lVcCy2NNaQdbVQ1aSHiGhLKPb4XFyBPA3fy7O sUCDwgydLs4oNWyCc+dVTJhzTJzPCOfD9fttie6/5TLu6pEyPWwxhukc4JO9uEmQMbPJ B2vjJfPQhlcfDrw9+MlVuxinwO5vT6U2dhQzA= MIME-Version: 1.0 Received: by 10.231.28.33 with SMTP id k33mr276292ibc.81.1313785222536; Fri, 19 Aug 2011 13:20:22 -0700 (PDT) Received: by 10.231.14.68 with HTTP; Fri, 19 Aug 2011 13:20:22 -0700 (PDT) In-Reply-To: <4E4EBF6D.3030709@gmail.com> References: <4E4EBF6D.3030709@gmail.com> Date: Fri, 19 Aug 2011 15:20:22 -0500 Message-ID: From: Zhihao Yuan To: Matt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: snd_hda does no output to headphones X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:20:23 -0000 On Fri, Aug 19, 2011 at 2:54 PM, Matt wrote: > On 08/19/11 09:15, Zhihao Yuan wrote: >> >> Hi, >> >> I think I must get this problem resolved. I work at night, so without >> the headphones support, I can listen to music or watch video at that >> time. >> >> The machine is HP Elitebook 8540w. >> >> ~> =C2=A0uname -a >> FreeBSD compaq.yuetime 8.2-STABLE FreeBSD 8.2-STABLE #6 r224860: Sun >> Aug 14 15:17:57 CDT 2011 >> >> lichray@compaq.yuetime:/usr/obj/home/lichray/devel/freebsd-stable/sys/HO= UKAGO >> =C2=A0amd64 >> >> I have already set up the default_unit: >> >> ~> =C2=A0cat /dev/sndstat >> FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) >> Installed devices: >> pcm0: =C2=A0(play) >> pcm1: =C2=A0(play) >> pcm2: =C2=A0(play) >> pcm3: =C2=A0(play) >> pcm4: =C2=A0(play/rec) default >> pcm5: =C2=A0(play) >> >> >> pindump: >> >> hdac1: Dumping AFG cad=3D0 nid=3D1 pins: >> hdac1: =C2=A0nid 10 0x2121101f as =C2=A01 seq 15 =C2=A0 =C2=A0Headphones= =C2=A0Jack jack =C2=A01 loc >> 33 color =C2=A0 Black misc 0 >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT HP =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Sense: 0x00000000 >> hdac1: =C2=A0nid 11 0x03a1102e as =C2=A02 seq 14 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Mic =C2=A0Jack jack =C2=A01 loc >> =C2=A03 color =C2=A0 Black misc 0 >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 VREF Sense: 0x00000000 >> hdac1: =C2=A0nid 12 0x90a70120 as =C2=A02 seq =C2=A00 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Mic Fixed jack =C2=A07 loc >> 16 color Unknown misc 1 >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 VREF Sense: 0x00000000 >> hdac1: =C2=A0nid 13 0x90170110 as =C2=A01 seq =C2=A00 =C2=A0 =C2=A0 =C2= =A0 Speaker Fixed jack =C2=A07 loc >> 16 color Unknown misc 1 >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sense: 0x00000000 >> hdac1: =C2=A0nid 14 0x21811040 as =C2=A04 seq =C2=A00 =C2=A0 =C2=A0 =C2= =A0 Line-in =C2=A0Jack jack =C2=A01 loc >> 33 color =C2=A0 Black misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 VREF Sense: 0x00000000 >> hdac1: =C2=A0nid 15 0x03211030 as =C2=A03 seq =C2=A00 =C2=A0 =C2=A0Headp= hones =C2=A0Jack jack =C2=A01 loc >> =C2=A03 color =C2=A0 Black misc 0 >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sense: 0x00000000 >> hdac1: =C2=A0nid 20 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN OUT >> hdac1: =C2=A0nid 24 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN >> hdac1: =C2=A0nid 25 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: IN >> hdac1: =C2=A0nid 30 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT >> hdac1: =C2=A0nid 31 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT =C2=A0 =C2=A0EA= PD >> hdac1: =C2=A0nid 32 0x40f000f0 as 15 seq =C2=A00 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Other =C2=A0None jack =C2=A00 loc >> =C2=A00 color Unknown misc 0 [DISABLED] >> hdac1: =C2=A0 =C2=A0 =C2=A0 =C2=A0Caps: =C2=A0 =C2=A0OUT >> hdac1: NumGPIO=3D8 NumGPO=3D0 NumGPI=3D0 GPIWake=3D1 GPIUnsol=3D1 >> hdac1: GPIO: data=3D0x00000000 enable=3D0x00000000 direction=3D0x0000000= 0 >> hdac1: =C2=A0 =C2=A0 =C2=A0 wake=3D0x00000000 =C2=A0unsol=3D0x00000000 = =C2=A0 =C2=A0sticky=3D0x00000000 >> >> >> A full boot dmesg is availiable at here: >> >> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-August/012389= .html >> >> The sound comes from the internal speaker, and the internal record >> works. But the sound does not work on the headphones. >> >> I read many posts and the snd_hda(4), and I know I need to bind the >> headphones and the internal speaker to the same as, and I need to do >> the same on output. I think there must be some people who knows how to >> configure this here. Please give me some instructions. Thanks. > > It's been a while, but it looks like you have two headphones (nid10 & > nid15)? I would try disabling the first one and setting the as and seq fo= r > the second one to match what the first one (nid10) have. > Oh, my... you must be a genius at troubleshooting. I swapped them with hint.hdac.1.cad0.nid10.config=3D"as=3D3 seq=3D0" hint.hdac.1.cad0.nid15.config=3D"as=3D1 seq=3D15" and everything work. Thanks! --=20 Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___________________________________________________ 4BSD -- http://4bsd.biz/ From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 20:24:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323ED1065672 for ; Fri, 19 Aug 2011 20:24:28 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 087B18FC14 for ; Fri, 19 Aug 2011 20:24:27 +0000 (UTC) Received: by pzk33 with SMTP id 33so8985034pzk.18 for ; Fri, 19 Aug 2011 13:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bs7fHDMwndGEwtfWttm/eIugUCsfZs+WGujxn2rIteo=; b=KvOA0aDsQppvhMwIscDGH2sO44EzGdTMsBPVk5DIyBwlYAUdUj6M8wWz88o/CB33q4 b8JQqOjhOEplIOSX4QEZwABGwDZr4BC87W9eSHE65Y4F7frU0vEFChkcHDLKmUDjI95u eZz4plF2+UGbPYfToSHSgYlfGJSMe8RUm8UNE= Received: by 10.142.221.2 with SMTP id t2mr57868wfg.334.1313783660761; Fri, 19 Aug 2011 12:54:20 -0700 (PDT) Received: from sidhe.local (adsl-67-118-230-86.dsl.pltn13.pacbell.net [67.118.230.86]) by mx.google.com with ESMTPS id d4sm2566746pbe.84.2011.08.19.12.54.17 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 12:54:19 -0700 (PDT) Message-ID: <4E4EBF6D.3030709@gmail.com> Date: Fri, 19 Aug 2011 12:54:21 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: Zhihao Yuan References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: snd_hda does no output to headphones X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:24:28 -0000 On 08/19/11 09:15, Zhihao Yuan wrote: > Hi, > > I think I must get this problem resolved. I work at night, so without > the headphones support, I can listen to music or watch video at that > time. > > The machine is HP Elitebook 8540w. > > ~> uname -a > FreeBSD compaq.yuetime 8.2-STABLE FreeBSD 8.2-STABLE #6 r224860: Sun > Aug 14 15:17:57 CDT 2011 > lichray@compaq.yuetime:/usr/obj/home/lichray/devel/freebsd-stable/sys/HOUKAGO > amd64 > > I have already set up the default_unit: > > ~> cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) > Installed devices: > pcm0: (play) > pcm1: (play) > pcm2: (play) > pcm3: (play) > pcm4: (play/rec) default > pcm5: (play) > > > pindump: > > hdac1: Dumping AFG cad=0 nid=1 pins: > hdac1: nid 10 0x2121101f as 1 seq 15 Headphones Jack jack 1 loc > 33 color Black misc 0 > hdac1: Caps: OUT HP Sense: 0x00000000 > hdac1: nid 11 0x03a1102e as 2 seq 14 Mic Jack jack 1 loc > 3 color Black misc 0 > hdac1: Caps: IN VREF Sense: 0x00000000 > hdac1: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc > 16 color Unknown misc 1 > hdac1: Caps: IN VREF Sense: 0x00000000 > hdac1: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc > 16 color Unknown misc 1 > hdac1: Caps: OUT Sense: 0x00000000 > hdac1: nid 14 0x21811040 as 4 seq 0 Line-in Jack jack 1 loc > 33 color Black misc 0 [DISABLED] > hdac1: Caps: IN VREF Sense: 0x00000000 > hdac1: nid 15 0x03211030 as 3 seq 0 Headphones Jack jack 1 loc > 3 color Black misc 0 > hdac1: Caps: OUT Sense: 0x00000000 > hdac1: nid 20 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: IN OUT > hdac1: nid 24 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: IN > hdac1: nid 25 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: IN > hdac1: nid 30 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: OUT > hdac1: nid 31 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: OUT EAPD > hdac1: nid 32 0x40f000f0 as 15 seq 0 Other None jack 0 loc > 0 color Unknown misc 0 [DISABLED] > hdac1: Caps: OUT > hdac1: NumGPIO=8 NumGPO=0 NumGPI=0 GPIWake=1 GPIUnsol=1 > hdac1: GPIO: data=0x00000000 enable=0x00000000 direction=0x00000000 > hdac1: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 > > > A full boot dmesg is availiable at here: > http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-August/012389.html > > The sound comes from the internal speaker, and the internal record > works. But the sound does not work on the headphones. > > I read many posts and the snd_hda(4), and I know I need to bind the > headphones and the internal speaker to the same as, and I need to do > the same on output. I think there must be some people who knows how to > configure this here. Please give me some instructions. Thanks. It's been a while, but it looks like you have two headphones (nid10 & nid15)? I would try disabling the first one and setting the as and seq for the second one to match what the first one (nid10) have. From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 20:25:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1759D1065674 for ; Fri, 19 Aug 2011 20:25:29 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C745C8FC1F for ; Fri, 19 Aug 2011 20:25:28 +0000 (UTC) Received: by gyd10 with SMTP id 10so2876870gyd.13 for ; Fri, 19 Aug 2011 13:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GWsFT/GzOUKX0tImig9G8exXjtafca/yElHAZoxe5II=; b=nhyRQDCwJxW635IpzOOyARB3zx3EdiyCjG4/bArdtyML19tWMp1mPQaamesEibiCeE lSiSY5OCI64sbSbc0uK2/dBHFvoNBGCTLztabz3yomBn+jS/6HYJYZxR8ZodrDZ4aIdW 25jsmSY68caMJ3TNWw0T+3pPn3rXHAmNmqIKw= Received: by 10.142.196.19 with SMTP id t19mr85754wff.3.1313785527815; Fri, 19 Aug 2011 13:25:27 -0700 (PDT) Received: from sidhe.local ([75.101.87.90]) by mx.google.com with ESMTPS id p7sm2592220pbn.1.2011.08.19.13.25.25 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 13:25:26 -0700 (PDT) Message-ID: <4E4EC6BC.8070806@gmail.com> Date: Fri, 19 Aug 2011 13:25:32 -0700 From: Matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110716 Thunderbird/5.0 MIME-Version: 1.0 To: Zhihao Yuan References: <4E4EBF6D.3030709@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: snd_hda does no output to headphones X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 20:25:29 -0000 On 08/19/11 13:20, Zhihao Yuan wrote: > On Fri, Aug 19, 2011 at 2:54 PM, Matt wrote: >> On 08/19/11 09:15, Zhihao Yuan wrote: >>> Hi, >>> >>> I think I must get this problem resolved. I work at night, so without >>> the headphones support, I can listen to music or watch video at that >>> time. >>> >>> The machine is HP Elitebook 8540w. >>> >>> ~> uname -a >>> FreeBSD compaq.yuetime 8.2-STABLE FreeBSD 8.2-STABLE #6 r224860: Sun >>> Aug 14 15:17:57 CDT 2011 >>> >>> lichray@compaq.yuetime:/usr/obj/home/lichray/devel/freebsd-stable/sys/HOUKAGO >>> amd64 >>> >>> I have already set up the default_unit: >>> >>> ~> cat /dev/sndstat >>> FreeBSD Audio Driver (newpcm: 64bit 2009061500/amd64) >>> Installed devices: >>> pcm0: (play) >>> pcm1: (play) >>> pcm2: (play) >>> pcm3: (play) >>> pcm4: (play/rec) default >>> pcm5: (play) >>> >>> >>> pindump: >>> >>> hdac1: Dumping AFG cad=0 nid=1 pins: >>> hdac1: nid 10 0x2121101f as 1 seq 15 Headphones Jack jack 1 loc >>> 33 color Black misc 0 >>> hdac1: Caps: OUT HP Sense: 0x00000000 >>> hdac1: nid 11 0x03a1102e as 2 seq 14 Mic Jack jack 1 loc >>> 3 color Black misc 0 >>> hdac1: Caps: IN VREF Sense: 0x00000000 >>> hdac1: nid 12 0x90a70120 as 2 seq 0 Mic Fixed jack 7 loc >>> 16 color Unknown misc 1 >>> hdac1: Caps: IN VREF Sense: 0x00000000 >>> hdac1: nid 13 0x90170110 as 1 seq 0 Speaker Fixed jack 7 loc >>> 16 color Unknown misc 1 >>> hdac1: Caps: OUT Sense: 0x00000000 >>> hdac1: nid 14 0x21811040 as 4 seq 0 Line-in Jack jack 1 loc >>> 33 color Black misc 0 [DISABLED] >>> hdac1: Caps: IN VREF Sense: 0x00000000 >>> hdac1: nid 15 0x03211030 as 3 seq 0 Headphones Jack jack 1 loc >>> 3 color Black misc 0 >>> hdac1: Caps: OUT Sense: 0x00000000 >>> hdac1: nid 20 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: IN OUT >>> hdac1: nid 24 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: IN >>> hdac1: nid 25 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: IN >>> hdac1: nid 30 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: OUT >>> hdac1: nid 31 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: OUT EAPD >>> hdac1: nid 32 0x40f000f0 as 15 seq 0 Other None jack 0 loc >>> 0 color Unknown misc 0 [DISABLED] >>> hdac1: Caps: OUT >>> hdac1: NumGPIO=8 NumGPO=0 NumGPI=0 GPIWake=1 GPIUnsol=1 >>> hdac1: GPIO: data=0x00000000 enable=0x00000000 direction=0x00000000 >>> hdac1: wake=0x00000000 unsol=0x00000000 sticky=0x00000000 >>> >>> >>> A full boot dmesg is availiable at here: >>> >>> http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-August/012389.html >>> >>> The sound comes from the internal speaker, and the internal record >>> works. But the sound does not work on the headphones. >>> >>> I read many posts and the snd_hda(4), and I know I need to bind the >>> headphones and the internal speaker to the same as, and I need to do >>> the same on output. I think there must be some people who knows how to >>> configure this here. Please give me some instructions. Thanks. >> It's been a while, but it looks like you have two headphones (nid10& >> nid15)? I would try disabling the first one and setting the as and seq for >> the second one to match what the first one (nid10) have. >> > Oh, my... you must be a genius at troubleshooting. I swapped them with > > hint.hdac.1.cad0.nid10.config="as=3 seq=0" > hint.hdac.1.cad0.nid15.config="as=1 seq=15" > > and everything work. Thanks! > Glad it worked! Matt