From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 01:29:53 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169381065670; Sun, 21 Aug 2011 01:29:53 +0000 (UTC) (envelope-from prvs=12149e54fe=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 F2CF18FC15; Sun, 21 Aug 2011 01:29:51 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 21 Aug 2011 02:18:43 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 21 Aug 2011 02:18:43 +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 md50014678950.msg; Sun, 21 Aug 2011 02:18:41 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=12149e54fe=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <3D52B19B71CA49A4BB3BCCDF25961F46@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" , References: eBSD.org><82E865FBA30747078AF6EE3C1701F973@multiplay.co.uk><4E4FE55A.9000101@FreeBSD.org> <4E501A6A.3030801@FreeBSD.org> Date: Sun, 21 Aug 2011 02:19: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-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 01:29:53 -0000 ----- Original Message ----- From: "Andriy Gapon" > on 20/08/2011 23:24 Steven Hartland said the following: >> ----- Original Message ----- From: "Steven Hartland" >>> Looking through the code I believe I may have noticed a scenario which could >>> trigger the problem. >>> >>> Given the following code:- >>> >>> static void >>> prison_deref(struct prison *pr, int flags) >>> { >>> struct prison *ppr, *tpr; >>> int vfslocked; >>> >>> if (!(flags & PD_LOCKED)) >>> mtx_lock(&pr->pr_mtx); >>> /* Decrement the user references in a separate loop. */ >>> 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); >>> } >>> } >>> >>> If you take a scenario of a simple one level prison setup running a single >>> process >>> where a prison has just been stopped. >>> >>> In the above code pr_uref of the processes prison is decremented. As this is the >>> last process then pr_uref will hit 0 and the loop continues instead of breaking >>> early. >>> >>> Now at the end of the loop iteration the mtx is unlocked so other process can >>> now manipulate the jail, this is where I think the problem may be. >>> >>> If we now have another process come in and attach to the jail but then instantly >>> exit, this process may allow another kernel thread to hit this same bit of code >>> and so two process for the same prison get into the section which decrements >>> prison0's pr_uref, instead of only one. >>> >>> In essence I think we can get the following flow where 1# = process1 >>> and 2# = process2 >>> 1#1. prison1.pr_uref = 1 (single process jail) >>> 1#2. prison_deref( prison1,... >>> 1#3. prison1.pr_uref-- (prison1.pr_uref = 0) >>> 1#3. prison1.mtx_unlock <-- this now allows others to change prison1.pr_uref >>> 1#3. prison0.pr_uref-- >>> 2#1. process1.attach( prison1 ) (prison1.pr_uref = 1) >>> 2#2. process1.exit >>> 2#3. prison_deref( prison1,... >>> 2#4. prison1.pr_uref-- (prison1.pr_uref = 0) >>> 2#5. prison1.mtx_unlock <-- this now allows others to change prison1.pr_uref >>> 2#5. prison0.pr_uref-- (prison1.pr_ref has now been decremented twice by prison1) >>> >>> It seems like the action on the parent prison to decrement the pr_uref is >>> happening too early, while the jail can still be used and without the lock on >>> the child jails mtx, so causing a race condition. >>> >>> I think the fix is to the move the decrement of parent prison pr_uref's down >>> so it only takes place if the jail is "really" being removed. Either that or >>> to change the locking semantics so that once the lock is aquired in this >>> prison_deref its not unlocked until the function completes. >>> >>> What do people think? >> >> After reviewing the changes to prison_deref in commit which added hierarchical >> jails, the removal of the lock by the inital loop on the passed in prison may >> be unintentional. >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_jail.c.diff?r1=1.101;r2=1.102;f=h >> >> >> If so the following may be all that's needed to fix this issue:- >> >> diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c >> --- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100 >> +++ sys/kern/kern_jail.c 2011-08-20 21:18:35.307201425 +0100 >> @@ -2455,7 +2455,8 @@ >> if (--tpr->pr_uref > 0) >> break; >> KASSERT(tpr != &prison0, ("prison0 pr_uref=0")); >> - mtx_unlock(&tpr->pr_mtx); >> + if (tpr != pr) >> + mtx_unlock(&tpr->pr_mtx); >> } >> /* Done if there were only user references to remove. */ >> if (!(flags & PD_DEREF)) { > > Not sure if this would fly as is - please double check the later block where > pr->pr_mtx is re-locked. Your right, and its actually more complex than that. Although changing it to not unlock in the middle of prison_deref fixes that race condition it doesn't prevent pr_uref being incorrectly decremented each time the jail gets into the dying state, which is really the problem we are seeing. If hierarchical prisons are used there seems to be an additional problem where the counter of all prisons in the hierarchy are decremented, but as far as I can tell only the immediate parent is ever incremented, so another reference problem there as well I think. The following patch I believe fixes both of these issues. I've testing with debug added and confirmed prison0's pr_uref is maintained correctly even when a jail hits dying state multiple times. It essentially reverts the changes to the "if (flags & PD_DEUREF)" by 192895 and moves it to after the jail has been actually removed. diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c --- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100 +++ sys/kern/kern_jail.c 2011-08-21 01:56:58.429894825 +0100 @@ -2449,27 +2449,16 @@ mtx_lock(&pr->pr_mtx); /* Decrement the user references in a separate loop. */ 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); - } + pr->pr_uref--; /* Done if there were only user references to remove. */ if (!(flags & PD_DEREF)) { - mtx_unlock(&tpr->pr_mtx); + mtx_unlock(&pr->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); - } } for (;;) { @@ -2525,6 +2514,8 @@ /* Removing a prison frees a reference on its parent. */ pr = ppr; mtx_lock(&pr->pr_mtx); + /* Ensure user reference added on create is removed */ + pr->pr_uref--; flags = PD_DEREF; } } Jamie from what I can tell you where the original committer of hierarchical prisons and this in the following svn change set so would really appreciate your feedback on this. http://svnweb.freebsd.org/base?view=revision&revision=192895 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-stable@FreeBSD.ORG Sun Aug 21 02:13:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68D771065670 for ; Sun, 21 Aug 2011 02:13:19 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 452768FC13 for ; Sun, 21 Aug 2011 02:13:19 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7L2DH8v092487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Aug 2011 19:13:18 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7L2DHoJ092486; Sat, 20 Aug 2011 19:13:17 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA20887; Sat, 20 Aug 11 19:00:55 PDT Date: Sun, 21 Aug 2011 02:00:33 -0700 From: perryh@pluto.rain.com To: freebsd@jdc.parodius.com Message-Id: <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> In-Reply-To: <20110820183456.GA38317@icarus.home.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ml@os2.kiev.ua, freebsd-stable@freebsd.org, dan@langille.org Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 02:13:19 -0000 Jeremy Chadwick wrote: > ... using dd to find the bad LBAs is the only choice he has. or sysutils/diskcheckd. It uses a 64KB blocksize, falling back to 512 -- to identify the bad LBA(s) -- after getting a failure when reading a large block, and IME it runs something like 10x faster than dd with bs=64k. It would be advisable to check syslog configuration before using diskcheckd, since that is how it reports and there is reason to suspect that the as-shipped syslog.conf may discard at least some of diskcheckd's messages. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 05:00:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5ED106566B for ; Sun, 21 Aug 2011 05:00:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 10B8E8FC12 for ; Sun, 21 Aug 2011 05:00:55 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Nt0C1h0021HpZEsA9t0r5N; Sun, 21 Aug 2011 05:00:51 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id Nt0s1h00T1t3BNj8at0tYg; Sun, 21 Aug 2011 05:00:55 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C932A102C1A; Sat, 20 Aug 2011 22:00:51 -0700 (PDT) Date: Sat, 20 Aug 2011 22:00:51 -0700 From: Jeremy Chadwick To: perryh@pluto.rain.com Message-ID: <20110821050051.GA47415@icarus.home.lan> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ml@os2.kiev.ua, freebsd-stable@freebsd.org, dan@langille.org, utisoft@gmail.com Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 05:00:56 -0000 On Sun, Aug 21, 2011 at 02:00:33AM -0700, perryh@pluto.rain.com wrote: > Jeremy Chadwick wrote: > > > ... using dd to find the bad LBAs is the only choice he has. > > or sysutils/diskcheckd. It uses a 64KB blocksize, falling back to > 512 -- to identify the bad LBA(s) -- after getting a failure when > reading a large block, and IME it runs something like 10x faster > than dd with bs=64k. > > It would be advisable to check syslog configuration before using > diskcheckd, since that is how it reports and there is reason to > suspect that the as-shipped syslog.conf may discard at least some > of diskcheckd's messages. That software has a major problem where it runs constantly, rather than periodically. I know because I'm the one who opened the PR on it: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 There's a discussion about this port/issue from a few days ago (how sweet!): http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069276.html With comments from you stating that the software is behaving as designed and that I misread the man page, but also stating point blank that "either way the software runs continuously" (which is what the PR was about in the first place): http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069321.html I closed the PR because when I left as a committer I no longer wanted to deal with the issue. I probably should have marked the PR as suspended, but either way it's an ordeal that needs to get dealt with; it absolutely should be re-opened in some way. Then there's this PR, which I fully agree should have *nothing* to do with gmirror, so I'm not even sure how to interpret what's written. Furthermore, the author of this PR commented in PR 115853 stating something completely different (read the first few lines very carefully/slowly -- it seems to indicate he agrees with my PR, but then opened up a separate PR with different wording): http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566 Back to my PR. I state that I set up diskcheckd.conf using the option you describe as "a length of time over which to spread each pass", yet what happened was that it did as much I/O as it could (read the entire disk in 45 minutes) then proceeded to do it again (no sleep()). That is not the same thing as "do I/O over the course of 7 days". Furthermore, the man page example gives this: EXAMPLES To check all of /dev/ad0 for errors once every two weeks, use this entry in diskcheckd.conf: /dev/ad0 * 14 * Which is no different than what I specified in my PR other than that I used a value of 7 and the example uses 14. So what about the rest of the man page? The second format consists of four white space separated fields, which are the full pathname of the disk device, the size of that disk, the frequency in days at which to check that disk, and the rate in kilo- bytes per second at which to check this disk. Naturally, it would be contradictory to specify both the frequency and the rate, so only one of these should be specified. Additionally, the size of the disk should not be specified if the rate is specified, as this information is unneces- sary. I did not misread the man page, especially given what's in EXAMPLES. It's a bug somewhere -- either in the man page or the software itself. This software will burn through your drive constantly, unless you use the rate-in-kilobytes-per-second field. The frequency field doesn't work as advertised. And besides, such a utility really shouldn't be a daemon anyway but a periodic(8)-called utility with appropriate locks put in place to ensure more than one instance can't be run at once. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 07:26:40 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 151C5106564A; Sun, 21 Aug 2011 07:26:40 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id 9E7F68FC08; Sun, 21 Aug 2011 07:26:39 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-133-59.hsd1.ut.comcast.net [174.52.133.59]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id p7L73YLe078411; Sun, 21 Aug 2011 01:03:34 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4E50ADC5.6050403@FreeBSD.org> Date: Sun, 21 Aug 2011 01:03:33 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101110 Thunderbird/3.1.6 MIME-Version: 1.0 To: Steven Hartland References: eBSD.org><82E865FBA30747078AF6EE3C1701F973@multiplay.co.uk><4E4FE55A.9000101@FreeBSD.org> <4E501A6A.3030801@FreeBSD.org> <3D52B19B71CA49A4BB3BCCDF25961F46@multiplay.co.uk> In-Reply-To: <3D52B19B71CA49A4BB3BCCDF25961F46@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org, Andriy Gapon Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 07:26:40 -0000 On 08/20/11 19:19, Steven Hartland wrote: > ----- Original Message ----- From: "Andriy Gapon" > >> on 20/08/2011 23:24 Steven Hartland said the following: >>> ----- Original Message ----- From: "Steven Hartland" >>>> Looking through the code I believe I may have noticed a scenario >>>> which could >>>> trigger the problem. >>>> >>>> Given the following code:- >>>> >>>> static void >>>> prison_deref(struct prison *pr, int flags) >>>> { >>>> struct prison *ppr, *tpr; >>>> int vfslocked; >>>> >>>> if (!(flags & PD_LOCKED)) >>>> mtx_lock(&pr->pr_mtx); >>>> /* Decrement the user references in a separate loop. */ >>>> 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); >>>> } >>>> } >>>> >>>> If you take a scenario of a simple one level prison setup running a >>>> single >>>> process >>>> where a prison has just been stopped. >>>> >>>> In the above code pr_uref of the processes prison is decremented. As >>>> this is the >>>> last process then pr_uref will hit 0 and the loop continues instead >>>> of breaking >>>> early. >>>> >>>> Now at the end of the loop iteration the mtx is unlocked so other >>>> process can >>>> now manipulate the jail, this is where I think the problem may be. >>>> >>>> If we now have another process come in and attach to the jail but >>>> then instantly >>>> exit, this process may allow another kernel thread to hit this same >>>> bit of code >>>> and so two process for the same prison get into the section which >>>> decrements >>>> prison0's pr_uref, instead of only one. >>>> >>>> In essence I think we can get the following flow where 1# = process1 >>>> and 2# = process2 >>>> 1#1. prison1.pr_uref = 1 (single process jail) >>>> 1#2. prison_deref( prison1,... >>>> 1#3. prison1.pr_uref-- (prison1.pr_uref = 0) >>>> 1#3. prison1.mtx_unlock <-- this now allows others to change >>>> prison1.pr_uref >>>> 1#3. prison0.pr_uref-- >>>> 2#1. process1.attach( prison1 ) (prison1.pr_uref = 1) >>>> 2#2. process1.exit >>>> 2#3. prison_deref( prison1,... >>>> 2#4. prison1.pr_uref-- (prison1.pr_uref = 0) >>>> 2#5. prison1.mtx_unlock <-- this now allows others to change >>>> prison1.pr_uref >>>> 2#5. prison0.pr_uref-- (prison1.pr_ref has now been decremented >>>> twice by prison1) >>>> >>>> It seems like the action on the parent prison to decrement the >>>> pr_uref is >>>> happening too early, while the jail can still be used and without >>>> the lock on >>>> the child jails mtx, so causing a race condition. >>>> >>>> I think the fix is to the move the decrement of parent prison >>>> pr_uref's down >>>> so it only takes place if the jail is "really" being removed. Either >>>> that or >>>> to change the locking semantics so that once the lock is aquired in >>>> this >>>> prison_deref its not unlocked until the function completes. >>>> >>>> What do people think? >>> >>> After reviewing the changes to prison_deref in commit which added >>> hierarchical >>> jails, the removal of the lock by the inital loop on the passed in >>> prison may >>> be unintentional. >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_jail.c.diff?r1=1.101;r2=1.102;f=h >>> >>> >>> >>> If so the following may be all that's needed to fix this issue:- >>> >>> diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c >>> --- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100 >>> +++ sys/kern/kern_jail.c 2011-08-20 21:18:35.307201425 +0100 >>> @@ -2455,7 +2455,8 @@ >>> if (--tpr->pr_uref > 0) >>> break; >>> KASSERT(tpr != &prison0, ("prison0 pr_uref=0")); >>> - mtx_unlock(&tpr->pr_mtx); >>> + if (tpr != pr) >>> + mtx_unlock(&tpr->pr_mtx); >>> } >>> /* Done if there were only user references to remove. */ >>> if (!(flags & PD_DEREF)) { >> >> Not sure if this would fly as is - please double check the later block >> where >> pr->pr_mtx is re-locked. > > Your right, and its actually more complex than that. Although changing > it to > not unlock in the middle of prison_deref fixes that race condition it > doesn't > prevent pr_uref being incorrectly decremented each time the jail gets into > the dying state, which is really the problem we are seeing. > > If hierarchical prisons are used there seems to be an additional problem > where the counter of all prisons in the hierarchy are decremented, but as > far as I can tell only the immediate parent is ever incremented, so another > reference problem there as well I think. > > The following patch I believe fixes both of these issues. > > I've testing with debug added and confirmed prison0's pr_uref is maintained > correctly even when a jail hits dying state multiple times. > > It essentially reverts the changes to the "if (flags & PD_DEUREF)" by > 192895 and moves it to after the jail has been actually removed. > > diff -u sys/kern/kern_jail.c.orig sys/kern/kern_jail.c > --- sys/kern/kern_jail.c.orig 2011-08-20 21:17:14.856618854 +0100 > +++ sys/kern/kern_jail.c 2011-08-21 01:56:58.429894825 +0100 > @@ -2449,27 +2449,16 @@ > mtx_lock(&pr->pr_mtx); > /* Decrement the user references in a separate loop. */ > 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); > - } > + pr->pr_uref--; > /* Done if there were only user references to remove. */ > if (!(flags & PD_DEREF)) { > - mtx_unlock(&tpr->pr_mtx); > + mtx_unlock(&pr->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); > - } > } > > for (;;) { > @@ -2525,6 +2514,8 @@ > /* Removing a prison frees a reference on its parent. */ > pr = ppr; > mtx_lock(&pr->pr_mtx); > + /* Ensure user reference added on create is removed */ > + pr->pr_uref--; > flags = PD_DEREF; > } > } > > Jamie from what I can tell you where the original committer of hierarchical > prisons and this in the following svn change set so would really appreciate > your feedback on this. > http://svnweb.freebsd.org/base?view=revision&revision=192895 The problem isn't with the conditional locking of tpr in prison_deref. That locking is actually correct, and there's no race condition. The trouble lies in the resurrection of dead jails, as Andriy has noted (though not just attaching, but also by setting its persist flag causes the same problem). There are two possible fixes to this. One is the patch you've given, which only decrements a parent jail's pr_uref when the child jail completely goes away (as opposed to when it loses its last uref). This provides symmetry with the current way pr_uref is incremented on the parent, which is only when a jail is created. The other fix is to increment a parent's pr_uref when a jail is resurrected, which will match the current logic in prison_deref. I like the external semantics of this solution: a jail isn't visible if it is not persistent and has no processes and no *visible* sub-jails, as opposed to having no sub-jails at all. But this solution ends up pretty complicated - there are a few places where pr_uref is incremented, where I might need to increment parent jails' pr_uref as well, much like the current tpr loop in prison_deref decrements them. Your solution removes code instead of adding it, which is generally a good thing. While it does change the semantics of pr_uref in the hierarchical case at least from what I thought it was, those semantics haven't been working properly anyway. Bjoern, I'm adding you to the CC list for this because the whole pr_uref thing was your idea (though it was pr_nprocs at the time), so you might care about the hierarchical semantics of it - or you may not. Also, this is a panic-inducing bug in current and may interest you for that reason. - Jamie From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 10:05:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85E6D106564A for ; Sun, 21 Aug 2011 10:05:59 +0000 (UTC) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from krusty.dt.e-technik.tu-dortmund.de (krusty.dt.E-Technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.freebsd.org (Postfix) with ESMTP id 47ACA8FC08 for ; Sun, 21 Aug 2011 10:05:59 +0000 (UTC) Received: from [192.168.0.4] (f055048121.adsl.alicedsl.de [78.55.48.121]) by mail.dt.e-technik.tu-dortmund.de (Postfix) with ESMTPSA id 27D629C2D3 for ; Sun, 21 Aug 2011 11:48:34 +0200 (CEST) Message-ID: <4E50D470.4090800@dt.e-technik.uni-dortmund.de> Date: Sun, 21 Aug 2011 11:48:32 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Mnenhy/0.8.3 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> In-Reply-To: <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 10:05:59 -0000 Am 20.08.2011 19:34, schrieb Dan Langille: > This is an older system. I suspect insufficient ventilation. I'll look at getting > a new case fan, if not some HDD fans. The answer is quite simple, get new drives. They have gone for some 24000 hours, IOW, at least 3 years (assuming 24x7), and at around 50 °C, they're worn. After three years, at the slightest hitch, replace drives, before Something Bad[tm] happens. You'll get faster replacements anyhow :) On a related note, since this is about gmirror: Linux has a similar subsystem in place called the drive mapper (dm), with user-space tools mdadm. The whole rig (kernel + user space) supports various RAID levels through modules, the gmirror equivalent being raid1 -- and that module somewhat recently acquired an interesting *feature:* it can automatically rewrite broken sectors. Meaning that when it sees a read error on one drive, it will read the block from the intact other drive and re-write it on the faulty drive so that it gets reallocated (assuming nobody turned the drive's ARWE feature off). Perhaps that's a useful feature for gmirror, too. > 2848980992 bytes transferred in 127.128503 secs (22410246 bytes/sec) Eek, someone should fix dd to use proper units and not confuse seconds (s) with the secans function (sec). Anyways, that's pretty low by today's standards. My I/O speeds even on lowly Samsung 5400/min drives are in excess of 100 MBytes/s, and that's talking about drives made in 2009. From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 10:40:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD80106564A for ; Sun, 21 Aug 2011 10:40:46 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id DAA8F8FC0C for ; Sun, 21 Aug 2011 10:40:45 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7LAeh91036325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 Aug 2011 03:40:44 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7LAehxE036324; Sun, 21 Aug 2011 03:40:43 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA22266; Sun, 21 Aug 11 03:35:47 PDT Date: Sun, 21 Aug 2011 10:35:25 -0700 From: perryh@pluto.rain.com To: freebsd@jdc.parodius.com Message-Id: <4e5141dd.mmh6t9R/knnc8Jll%perryh@pluto.rain.com> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> <20110821050051.GA47415@icarus.home.lan> In-Reply-To: <20110821050051.GA47415@icarus.home.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, ml@os2.kiev.ua, dan@langille.org, utisoft@gmail.com Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 10:40:46 -0000 Jeremy Chadwick wrote: > On Sun, Aug 21, 2011 at 02:00:33AM -0700, perryh@pluto.rain.com > wrote: > > Jeremy Chadwick wrote: > > > ... using dd to find the bad LBAs is the only choice he has. > > or sysutils/diskcheckd ... > That software has a major problem where it runs constantly, rather > than periodically. Even in light of the discussion below, I would not think that a problem for the particular purpose under discussion, where it's presumably going to be terminated after completing a single pass. The "dd" approach is also going to soak the drive for the duration. > I know because I'm the one who opened the PR on it: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 > There's a discussion about this port/issue from a few days ago > (how sweet!): > http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069276.html > With comments from you stating that the software is behaving as > designed and that I misread the man page, but also stating point > blank that "either way the software runs continuously" (which is > what the PR was about in the first place): > http://lists.freebsd.org/pipermail/freebsd-ports/2011-August/069321.html > ... > Back to my PR. > I state that I set up diskcheckd.conf using the option you > describe as "a length of time over which to spread each pass", > yet what happened was that it did as much I/O as it could > (read the entire disk in 45 minutes) then proceeded to do > it again (no sleep()) ... Agreed, that is not what is supposed to happen. What I see as a misreading of the manpage is reflected in your assertion, in the closing comment on 7/1/2008, that "the code does not do what the manpage says (or vice-versa)." Having looked at both the code and the manpage, I don't agree with that assessment. As I read it, the manpage sentence Naturally, it would be contradictory to specify both the frequency and the rate, so only one of these should be specified. has to mean that the "days" (frequency) setting is simply an alternative way of specifying the rate. Is there some other interpretation that I'm missing? Based on the code, it looks to me as if diskcheckd is supposed to read 64KB checking for errors, then sleep for a calculated length of time before reading the next 64KB, so as to average out to the (directly or indirectly) specified rate. Thus it is intended to run "continuously" in the sense that its I/O load is supposed to be as uniform as possible, consistent with reading 64KB at a time, rather than imposing a heavier load for some period of time and then pausing for the balance of the specified number of days. This is entirely consistent with my understanding of the manpage. Given that 115853 was closed (which AFAIK is supposed to mean "no longer considered a problem"), and seemed to have involved a misunderstanding of how diskcheckd was intended to operate, I decided to investigate the open 143566 instead -- and 143566 explicitly stated that "diskcheckd runs fine when gmirror is not involved ..." So I've been running diskcheckd on a gmirrored system and it seems to be working. As to what is actually going on: Earlier this evening I started looking into the failure to call updateproctitle() as mentioned in 115853's closing comment, which I had also noticed in my own testing, and it seems that this _is_ related to the now-clarified problem of diskcheckd running flat-out instead of pausing between each 64KB read. When the specified or calculated rate exceeds 64KB/sec, the required sleep interval between 64KB chunks is less than one second. Since diskcheckd calculates the interval in whole seconds -- because it calls sleep() rather than usleep() or nanosleep() -- an interval of less than one second is calculated as zero. That zero "interval" gets passed to sleep(), which dutifully returns immediately or nearly so, and the same zero is also used to "increment" the counter that is supposed to cause updateproctitle() to be called every 300 seconds. I suspect the fix will be to calculate in microseconds, and call usleep() instead of sleep(). And yes, I am planning to fix it -- and clarify the manpage -- but not tonight. > ... and besides, such a utility really shouldn't be a daemon > anyway but a periodic(8)-called utility with appropriate locks put > in place to ensure more than one instance can't be run at once. I suppose that can be argued either way. It's not obvious to me that using, say, 7x as much bandwidth for one day and then taking 6 days off is somehow better than spreading the testing over an entire week. Furthermore, using periodic(8) could get _really_ messy if checking multiple drives using different frequencies -- unless one wanted to run a separate instance of the program for each drive (and then we would have to prevent multiple simultaneous instances for any one drive, while allowing simultaneous checking of multiple drives). From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 11:00:58 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73F3E1065670; Sun, 21 Aug 2011 11:00:58 +0000 (UTC) (envelope-from prvs=12149e54fe=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 3388E8FC13; Sun, 21 Aug 2011 11:00:56 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 21 Aug 2011 12:00:22 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 21 Aug 2011 12:00:22 +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 md50014681961.msg; Sun, 21 Aug 2011 12:00:21 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=12149e54fe=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: "Jamie Gritton" References: eBSD.org><82E865FBA30747078AF6EE3C1701F973@multiplay.co.uk><4E4FE55A.9000101@FreeBSD.org> <4E501A6A.3030801@FreeBSD.org> <3D52B19B71CA49A4BB3BCCDF25961F46@multiplay.co.uk> <4E50ADC5.6050403@FreeBSD.org> Date: Sun, 21 Aug 2011 12:01:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: "Bjoern A. Zeeb" , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org, Andriy Gapon Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 11:00:58 -0000 ----- Original Message ----- From: "Jamie Gritton" >>>>> In essence I think we can get the following flow where 1# = process1 >>>>> and 2# = process2 >>>>> 1#1. prison1.pr_uref = 1 (single process jail) >>>>> 1#2. prison_deref( prison1,... >>>>> 1#3. prison1.pr_uref-- (prison1.pr_uref = 0) >>>>> 1#3. prison1.mtx_unlock <-- this now allows others to change >>>>> prison1.pr_uref >>>>> 1#3. prison0.pr_uref-- >>>>> 2#1. process1.attach( prison1 ) (prison1.pr_uref = 1) >>>>> 2#2. process1.exit >>>>> 2#3. prison_deref( prison1,... >>>>> 2#4. prison1.pr_uref-- (prison1.pr_uref = 0) >>>>> 2#5. prison1.mtx_unlock <-- this now allows others to change >>>>> prison1.pr_uref >>>>> 2#5. prison0.pr_uref-- (prison1.pr_ref has now been decremented >>>>> twice by prison1) First off thanks for the feedback Jamie most appreciated :) > The problem isn't with the conditional locking of tpr in prison_deref. > That locking is actually correct, and there's no race condition. Are you sure? I do think that unlocking the mtx half way through the call allows the above scenario to create a race condition, all be it very briefly, when ignoring the overriding issue. In addition if the code where changed to so that the pr_uref++ also maintained the parents uref this would definitely lead to a potential problems in my mind, especially if you had more than one child prison, of a given parent, entering the dying state at any one time. In this case I believe you would have to acquire the locks of all the parent prisons before it would be safe to precede. > The trouble lies in the resurrection of dead jails, as Andriy has noted > (though not just attaching, but also by setting its persist flag causes > the same problem). I not sure that persistent prisons actually suffer from this in any different way tbh, as they have an additional uref increment so would never hit this case unless they have been actively removed and hence unpersisted first. > There are two possible fixes to this. One is the patch you've given, > which only decrements a parent jail's pr_uref when the child jail > completely goes away (as opposed to when it loses its last uref). This > provides symmetry with the current way pr_uref is incremented on the > parent, which is only when a jail is created. > > The other fix is to increment a parent's pr_uref when a jail is > resurrected, which will match the current logic in prison_deref. I like > the external semantics of this solution: a jail isn't visible if it is > not persistent and has no processes and no *visible* sub-jails, as > opposed to having no sub-jails at all. But this solution ends up pretty > complicated - there are a few places where pr_uref is incremented, where > I might need to increment parent jails' pr_uref as well, much like the > current tpr loop in prison_deref decrements them. Ahh yes in the hierarchical case my patch would indeed mean that none persistent parent jails would remain visible even when its last child jail is in a dying state. As you say making this not the case would likely require replacing all instances of pr_uref++ with a prison_uref method that implements the opposite of the loop in prison_dref should the prisons pr_uref be 0 when called. > Your solution removes code instead of adding it, which is generally a > good thing. While it does change the semantics of pr_uref in the > hierarchical case at least from what I thought it was, those semantics > haven't been working properly anyway. Good to know my interpretation was correct, even if I was missing the visibility factor in the hierarchical case :) > Bjoern, I'm adding you to the CC list for this because the whole pr_uref > thing was your idea (though it was pr_nprocs at the time), so you might > care about the hierarchical semantics of it - or you may not. Also, this > is a panic-inducing bug in current and may interest you for that reason. >From an admin perspective the current jail dying state does cause confusion when your not aware of its existence. You ask a jail to stop it appears to have completed that request, but really hasn't, an generally due to just a lingering tcp connection. With the introduction of hierarchical jails that gets a little worse where a whole series of jails could disappear from normal view only to be resurrected shortly after. Something to bear in mind when deciding which solution of the two presented to use. 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-stable@FreeBSD.ORG Sun Aug 21 14:01:17 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C923106566B for ; Sun, 21 Aug 2011 14:01:17 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1C84D8FC0A for ; Sun, 21 Aug 2011 14:01:17 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 5CD7E153434 for ; Sun, 21 Aug 2011 16:01:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tefn9TvOkbr8 for ; Sun, 21 Aug 2011 16:01:14 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:1d6a:c449:c682:7195] (unknown [IPv6:2001:4cb8:3:1:1d6a:c449:c682:7195]) by mail.digiware.nl (Postfix) with ESMTP id 7AA85153433 for ; Sun, 21 Aug 2011 16:01:14 +0200 (CEST) Message-ID: <4E510FA6.20100@digiware.nl> Date: Sun, 21 Aug 2011 16:01:10 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Unknown Re0 Hardware version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 14:01:17 -0000 Hi, I'm assembling a few system with a ASUS P8 H161-MLE motherboard which was supposed to have a 'RealtekŪ 8112L, 1 x Gigabit LAN Controller(s)' onboard. And to be honestly I never expected that version not to be supported. Just booted 8.2-RELEASE on it, and the Installer crashed when I wanted it to config the ehternet. Rebooted, and re0 kicks in. But gives a HW revision not supported. It claims HW revision 0x2c800000. Is this supported in later 8.2-Stable??? Or in 9.x?? I'm willing to tinker with the code to recompile the re0 driver. --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 16:19:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A2A106564A for ; Sun, 21 Aug 2011 16:19:17 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 813398FC15 for ; Sun, 21 Aug 2011 16:19:16 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7LFgn99052117 for ; Sun, 21 Aug 2011 17:42:49 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7LFgnO0052116 for freebsd-stable@freebsd.org; Sun, 21 Aug 2011 17:42:49 +0200 (CEST) (envelope-from byshenknet) Date: Sun, 21 Aug 2011 17:42:49 +0200 From: Greg Byshenk To: freebsd-stable@freebsd.org Message-ID: <20110821154249.GE92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Subject: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 16:19:17 -0000 Not sure if -stable is the right place for this, but I'll give it a shot; if it's not, then a pointer in the right direction would be much appreciated. I'm having a problem with a StarTech PEX2S952 dual-port serial card. I believe that it should be supported, as it has this entry in pucdata.c [...] { 0x1415, 0xc158, 0xffff, 0, "Oxford Semiconductor OXPCIe952 UARTs", DEFAULT_RCLK * 0x22, PUC_PORT_NONSTANDARD, 0x10, 0, -1, .config_function = puc_config_oxford_pcie }, [...] And, while it is recognized at boot -- after adding device puc options COM_MULTIPORT to my kernel, it doesn't seem to be working. The devices '/dev/cuau2' and '/dev/cuau3' show up, and I can connect to them, but they don't seem to pass any traffic. If I connect to the serial console of another machine (one that I know for certain is working), I get nothing at all. I suspect (?) that it may not be recognized as the proper card. Boot and pciconf messages are: puc0: mem 0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq 30 at device 0.0 on pci4 puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415 rev=0x00 hdr=0x00 vendor = 'Oxford Semiconductor Ltd' class = simple comms subclass = UART bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled bar [14] = type Memory, range 32, base 0xfa000000, size 2097152, enabled bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152, enabled The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite 'STABLE' yet, but I don't think that this should matter. Any advice would be much appreciated. The machine is still in test phase, so I can mess around with it as necessary. Thanks. -- greg byshenk - freebsd@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 16:49:55 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95B0C1065672; Sun, 21 Aug 2011 16:49:55 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [64.34.175.71]) by mx1.freebsd.org (Postfix) with ESMTP id 605D68FC08; Sun, 21 Aug 2011 16:49:54 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-133-59.hsd1.ut.comcast.net [174.52.133.59]) (authenticated bits=0) by m2.gritton.org (8.14.4/8.14.4) with ESMTP id p7LGnrL7082438; Sun, 21 Aug 2011 10:49:53 -0600 (MDT) (envelope-from jamie@FreeBSD.org) Message-ID: <4E51372F.1020606@FreeBSD.org> Date: Sun, 21 Aug 2011 10:49:51 -0600 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101110 Thunderbird/3.1.6 MIME-Version: 1.0 To: Steven Hartland References: eBSD.org><82E865FBA30747078AF6EE3C1701F973@multiplay.co.uk><4E4FE55A.9000101@FreeBSD.org> <4E501A6A.3030801@FreeBSD.org> <3D52B19B71CA49A4BB3BCCDF25961F46@multiplay.co.uk> <4E50ADC5.6050403@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org, Andriy Gapon Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 16:49:55 -0000 On 08/21/11 05:01, Steven Hartland wrote: > ----- Original Message ----- From: "Jamie Gritton" >> The problem isn't with the conditional locking of tpr in prison_deref. >> That locking is actually correct, and there's no race condition. > > Are you sure? I do think that unlocking the mtx half way through the > call allows the above scenario to create a race condition, all be it > very briefly, when ignoring the overriding issue. > > In addition if the code where changed to so that the pr_uref++ also > maintained the parents uref this would definitely lead to a potential > problems in my mind, especially if you had more than one child prison, > of a given parent, entering the dying state at any one time. > > In this case I believe you would have to acquire the locks of all > the parent prisons before it would be safe to precede. Lock order requires that I unlock the child if I want to lock the parent. While that does allow periods where neither is locked, it's safe in this case. There may be multiple processes dying in one jail, or in multiple children of a single jail. But as long as a parent jail is locked while decrementing pr_uref, then only one of these simultaneous prison_deref calls would set pr_uref to zero and continue in the loop to that prison's parent. This might be mixed with pr_uref being incremented elsewhere, but that's not a problem either as long as the jail in question is locked. >> The trouble lies in the resurrection of dead jails, as Andriy has noted >> (though not just attaching, but also by setting its persist flag causes >> the same problem). > > I not sure that persistent prisons actually suffer from this in any > different way tbh, as they have an additional uref increment so would > never hit this case unless they have been actively removed and hence > unpersisted first. Right - both the attach and persist cases are only a problem when a jail has disappeared. There are various ways for a jail to be removed, potentially to be kept around but in the dying state, but only two related ways for it to be resurrected: attaching a new process or setting the persist flag, both via jail_set with the JAIL_DYING flag passed. >> There are two possible fixes to this. One is the patch you've given, >> which only decrements a parent jail's pr_uref when the child jail >> completely goes away (as opposed to when it loses its last uref). This >> provides symmetry with the current way pr_uref is incremented on the >> parent, which is only when a jail is created. >> >> The other fix is to increment a parent's pr_uref when a jail is >> resurrected, which will match the current logic in prison_deref. I like >> the external semantics of this solution: a jail isn't visible if it is >> not persistent and has no processes and no *visible* sub-jails, as >> opposed to having no sub-jails at all. But this solution ends up pretty >> complicated - there are a few places where pr_uref is incremented, where >> I might need to increment parent jails' pr_uref as well, much like the >> current tpr loop in prison_deref decrements them. > > Ahh yes in the hierarchical case my patch would indeed mean that none > persistent parent jails would remain visible even when its last child > jail is in a dying state. > > As you say making this not the case would likely require replacing all > instances of pr_uref++ with a prison_uref method that implements the > opposite of the loop in prison_dref should the prisons pr_uref be 0 when > called. Yes, that's the problem. Maybe not all instances, but at least most have enough times a jail is unlocked that we can't assume the pr_uref hasn't been set to zero somewhere else, and so we need to do that loop. >> Your solution removes code instead of adding it, which is generally a >> good thing. While it does change the semantics of pr_uref in the >> hierarchical case at least from what I thought it was, those semantics >> haven't been working properly anyway. > > Good to know my interpretation was correct, even if I was missing the > visibility factor in the hierarchical case :) > >> Bjoern, I'm adding you to the CC list for this because the whole pr_uref >> thing was your idea (though it was pr_nprocs at the time), so you might >> care about the hierarchical semantics of it - or you may not. Also, this >> is a panic-inducing bug in current and may interest you for that reason. > > From an admin perspective the current jail dying state does cause > confusion when your not aware of its existence. You ask a jail to stop it > appears to have completed that request, but really hasn't, an generally > due to just a lingering tcp connection. > > With the introduction of hierarchical jails that gets a little worse > where a whole series of jails could disappear from normal view only to > be resurrected shortly after. Something to bear in mind when deciding > which solution of the two presented to use. The good news is that the only time a jail (or perhaps a whole set of jails) can only come back from the dead when the administrator makes a concerted effort to do so. So it at least shouldn't surprise the administrator who did that. To any other program/person that's watching, it just looks like jails were removed and then other jails with the same ID were created, the same as could happen when there are no dying-state issues, i.e. no outstanding TCP connections. One drawback to the suggested patch is that in the hierarchical case, an administrator that is naive to the JAIL_DYING flag could remove a jail and then continue to see it existing for a while anyway. In the typical single-level jail case, removing a jail always makes it go away, except to the eyes of the JAIL_DYING search. Preserving those semantics may be enough to want to go with the more complicated solution of adding a matching prison_ref call. So ... not necessarily decided on this issue after all. - Jamie From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 17:30:04 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18CEA106566B; Sun, 21 Aug 2011 17:30:04 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) by mx1.freebsd.org (Postfix) with ESMTP id 061028FC13; Sun, 21 Aug 2011 17:30:03 +0000 (UTC) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) by mx5.roble.com (Postfix) with ESMTP id A806867895; Sun, 21 Aug 2011 10:30:03 -0700 (PDT) Date: Sun, 21 Aug 2011 10:30:03 -0700 (PDT) From: Roger Marquis To: Steven Hartland In-Reply-To: References: <82E865FBA30747078AF6EE3C1701F973@multiplay.co.uk> <20110820182330.C6852106566B@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-Id: <20110821173004.18CEA106566B@hub.freebsd.org> Cc: freebsd-jail@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 17:30:04 -0000 On Sat, 20 Aug 2011, Steven Hartland wrote: > Are you seeing a double fault panic? We're seeing both. At least one double (or more) fault finishing with "Fatal Trap 12: page fault while in kernel mode". Subsequent panics have been single fault (all visible on the IPMI console) "Fatal Trap 9: general protection fault while in kernel mode". Could well be unrelated. The system is undergoing hardware diags now. Roger Marquis From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 21:01:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42FC3106564A for ; Sun, 21 Aug 2011 21:01:54 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id E7F518FC0A for ; Sun, 21 Aug 2011 21:01:53 +0000 (UTC) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 5B7E321F33; Sun, 21 Aug 2011 21:45:57 +0100 (BST) Received: from argon.wood2.org.uk (HELO argon.wood2.org.uk) (82.71.104.124) (smtp-auth username wood, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Sun, 21 Aug 2011 21:45:57 +0100 Message-ID: Date: Sun, 21 Aug 2011 21:44:41 +0100 To: Greg Byshenk From: David Wood References: <20110821154249.GE92605@core.byshenk.net> In-Reply-To: <20110821154249.GE92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+nhRuLNS5oZIqwOH7WWZxwfp$O>) X-Gradwell-MongoId: 4e516e85.7791-6eb1-1 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: wood Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 21:01:54 -0000 Hi Greg, I wrote and contributed the support code for the OXPCIe95x serial chips - and just happened to notice your report. In message <20110821154249.GE92605@core.byshenk.net>, Greg Byshenk writes >I'm having a problem with a StarTech PEX2S952 dual-port serial >card. > >I believe that it should be supported, as it has this entry in >pucdata.c > >[...] > { 0x1415, 0xc158, 0xffff, 0, > "Oxford Semiconductor OXPCIe952 UARTs", > DEFAULT_RCLK * 0x22, > PUC_PORT_NONSTANDARD, 0x10, 0, -1, > .config_function = puc_config_oxford_pcie > }, >[...] It should be supported. The OXPCIe952 is more awkward to support than the OXPCIe954 and OXPCIe958 because it can be configured in so many different ways by the board manufacturer. However, 0xc158 is configuration that is identical in arrangement as the larger chips, so is the configuration I'm most confident of. I've just double-checked the data sheets, and can't see any relevant differences between 0xc158 OXPCIe952 and the OXPCIe954 I tested the code with. I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports from other OXPCIe954 and OXPCIe958 board users (including someone with a 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x on my hardware. >And, while it is recognized at boot -- after adding > > device puc > options COM_MULTIPORT I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4) code - I certainly don't need it on 8.x. Does it make any difference if you delete that line and just leave "device puc"? >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2' >and '/dev/cuau3' show up, and I can connect to them, but they don't >seem to pass any traffic. If I connect to the serial console of >another machine (one that I know for certain is working), I get >nothing at all. Have you remembered to set the speed (and other relevant options) on the .init devices? This is a feature (or is it a quirk) of the uart(4) driver that catches many people out. Setting options on the base device is normally a no-op. For example, if the remote device on /dev/cuau2 operates at 115200 bps with hardware handshaking, try: stty -f /dev/cuau2.init speed 115200 crtscts One frustrating aspect of adding puc(4) support for many devices is that you can't be certain of the clock rate multiplier - the same device can crop up on a different manufacturer's board with a different multiplier. This problem doesn't occur with the OXPCIe95x devices as they derive their 62.5MHz UART clock from the PCI Express clock. Consequently, the problem can't be that your board inadvertently operating the UARTs at the wrong speed. >I suspect (?) that it may not be recognized as the proper card. Boot >and pciconf messages are: > >puc0: mem >0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq >30 at device 0.0 on pci4 That is correct. Are there any more lines afterwards - especially one giving the number of UARTs detected? That line is crucial, as, on these chips, the number of UARTs has to be read from configuration space because you can slave two chips together. My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64): puc0: mem 0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18 at device 0.0 on pci8 puc0: 4 UARTs detected puc0: [FILTER] uart2: <16950 or compatible> on puc0 uart2: [FILTER] uart3: <16950 or compatible> on puc0 uart3: [FILTER] uart4: <16950 or compatible> on puc0 uart4: [FILTER] uart5: <16950 or compatible> on puc0 uart5: [FILTER] >puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415 >rev=0x00 hdr=0x00 > vendor = 'Oxford Semiconductor Ltd' > class = simple comms > subclass = UART > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled > bar [14] = type Memory, range 32, base 0xfa000000, size 2097152, enabled > bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152, enabled That is correct. >The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite >'STABLE' yet, but I don't think that this should matter. > >Any advice would be much appreciated. The machine is still in >test phase, so I can mess around with it as necessary. Hopefully this gets your Startech board working. I look forward to your feedback. If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954 board, offering four ports via a breakout cable, and is normally pretty cheap direct from lindy.com (quite possibly cheaper than your two port Startech board!). However, this recommendation comes with the proviso that I haven't yet tried it with FreeBSD 9.x. With best wishes, David -- David Wood david@wood2.org.uk From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 22:18:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D48106564A for ; Sun, 21 Aug 2011 22:18:47 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0203B8FC12 for ; Sun, 21 Aug 2011 22:18:46 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7LMKYO2053827; Mon, 22 Aug 2011 00:20:34 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7LMKX3E053826; Mon, 22 Aug 2011 00:20:33 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 22 Aug 2011 00:20:33 +0200 From: Greg Byshenk To: David Wood Message-ID: <20110821222033.GH92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: freebsd-stable@freebsd.org, Greg Byshenk Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 22:18:47 -0000 On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote: > I wrote and contributed the support code for the OXPCIe95x serial chips > - and just happened to notice your report. Thanks for the response. > In message <20110821154249.GE92605@core.byshenk.net>, Greg Byshenk > writes > >I'm having a problem with a StarTech PEX2S952 dual-port serial > >card. > > > >I believe that it should be supported, as it has this entry in > >pucdata.c > > > >[...] > > { 0x1415, 0xc158, 0xffff, 0, > > "Oxford Semiconductor OXPCIe952 UARTs", > > DEFAULT_RCLK * 0x22, > > PUC_PORT_NONSTANDARD, 0x10, 0, -1, > > .config_function = puc_config_oxford_pcie > > }, > >[...] > > It should be supported. The OXPCIe952 is more awkward to support than > the OXPCIe954 and OXPCIe958 because it can be configured in so many > different ways by the board manufacturer. However, 0xc158 is > configuration that is identical in arrangement as the larger chips, so > is the configuration I'm most confident of. I've just double-checked the > data sheets, and can't see any relevant differences between 0xc158 > OXPCIe952 and the OXPCIe954 I tested the code with. > > I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports > from other OXPCIe954 and OXPCIe958 board users (including someone with a > 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x > on my hardware. > > > >And, while it is recognized at boot -- after adding > > > > device puc > > options COM_MULTIPORT > > I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4) > code - I certainly don't need it on 8.x. Does it make any difference if > you delete that line and just leave "device puc"? I will rebuild my kernel and try. > >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2' > >and '/dev/cuau3' show up, and I can connect to them, but they don't > >seem to pass any traffic. If I connect to the serial console of > >another machine (one that I know for certain is working), I get > >nothing at all. > > Have you remembered to set the speed (and other relevant options) on the > .init devices? This is a feature (or is it a quirk) of the uart(4) > driver that catches many people out. Setting options on the base device > is normally a no-op. > > For example, if the remote device on /dev/cuau2 operates at 115200 bps > with hardware handshaking, try: > > stty -f /dev/cuau2.init speed 115200 crtscts Interestingly, it -is- a no-op on the device, which I hadn't noticed. But trying to set it on the .init fails: # stty -f /dev/cuau2.init speed 115200 stty: /dev/cuau2.init isn't a terminal crtscts # > One frustrating aspect of adding puc(4) support for many devices is that > you can't be certain of the clock rate multiplier - the same device can > crop up on a different manufacturer's board with a different multiplier. > This problem doesn't occur with the OXPCIe95x devices as they derive > their 62.5MHz UART clock from the PCI Express clock. Consequently, the > problem can't be that your board inadvertently operating the UARTs at > the wrong speed. > > > >I suspect (?) that it may not be recognized as the proper card. Boot > >and pciconf messages are: > > > >puc0: mem > >0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq > >30 at device 0.0 on pci4 > > That is correct. Are there any more lines afterwards - especially one > giving the number of UARTs detected? That line is crucial, as, on these > chips, the number of UARTs has to be read from configuration space > because you can slave two chips together. > > My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64): > > puc0: mem > 0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18 > at device 0.0 on pci8 > puc0: 4 UARTs detected > puc0: [FILTER] > uart2: <16950 or compatible> on puc0 > uart2: [FILTER] > uart3: <16950 or compatible> on puc0 > uart3: [FILTER] > uart4: <16950 or compatible> on puc0 > uart4: [FILTER] > uart5: <16950 or compatible> on puc0 > uart5: [FILTER] puc0: mem 0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq 30 at device 0.0 on pci4 puc0: 2 UARTs detected uart2: <16950 or compatible> at port 1 on puc0 uart3: <16950 or compatible> at port 2 on puc0 > >puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415 > >rev=0x00 hdr=0x00 > > vendor = 'Oxford Semiconductor Ltd' > > class = simple comms > > subclass = UART > > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled > > bar [14] = type Memory, range 32, base 0xfa000000, size 2097152, > > enabled > > bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152, > > enabled > > That is correct. > > >The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite > >'STABLE' yet, but I don't think that this should matter. > > > >Any advice would be much appreciated. The machine is still in > >test phase, so I can mess around with it as necessary. > > Hopefully this gets your Startech board working. I look forward to your > feedback. > > If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954 > board, offering four ports via a breakout cable, and is normally pretty > cheap direct from lindy.com (quite possibly cheaper than your two port > Startech board!). However, this recommendation comes with the proviso > that I haven't yet tried it with FreeBSD 9.x. I'm rebuilding the kernel, and will try tomorrow with the new version. I think I'll also try setting the speed on the other end to 9600 (which is what stty reports as the speed) to see if that makes any difference. I'll follow up tomorrow. Thanks. -- greg byshenk - freebsd@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 23:15:13 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D81A41065673 for ; Sun, 21 Aug 2011 23:15:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 73FE28FC12 for ; Sun, 21 Aug 2011 23:15:13 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 7A172153434; Mon, 22 Aug 2011 01:15:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gItRNbQiDogm; Mon, 22 Aug 2011 01:15:10 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:1d6a:c449:c682:7195] (unknown [IPv6:2001:4cb8:3:1:1d6a:c449:c682:7195]) by mail.digiware.nl (Postfix) with ESMTP id C67D6153438; Mon, 22 Aug 2011 01:15:09 +0200 (CEST) Message-ID: <4E519179.10907@digiware.nl> Date: Mon, 22 Aug 2011 01:15:05 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4E510FA6.20100@digiware.nl> <20110821230119.GA1755@michelle.cdnetworks.com> In-Reply-To: <20110821230119.GA1755@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "stable@freebsd.org" Subject: Re: Unknown Re0 Hardware version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 23:15:13 -0000 On 2011-08-22 1:01, YongHyeon PYUN wrote: > On Sun, Aug 21, 2011 at 04:01:10PM +0200, Willem Jan Withagen wrote: >> Hi, >> >> I'm assembling a few system with a ASUS P8 H161-MLE motherboard >> which was supposed to have a 'RealtekŪ 8112L, 1 x Gigabit LAN >> Controller(s)' onboard. >> >> And to be honestly I never expected that version not to be supported. >> Just booted 8.2-RELEASE on it, and the Installer crashed when I wanted >> it to config the ehternet. >> >> Rebooted, and re0 kicks in. But gives a HW revision not supported. >> It claims HW revision 0x2c800000. >> >> Is this supported in later 8.2-Stable??? Or in 9.x?? >> >> I'm willing to tinker with the code to recompile the re0 driver. >> > > Your controller looks like RTL8168E VL and support for the > controller was added after 8.2-RELEASE. > Either update your source to stable/8 or patch your source tree > with back-ported re(4) driver for 8.2-RELEASE like the following. > > 1. Fetch http://people.freebsd.org/~yongari/re/8.2R/if_re.c and > copy it to /usr/src/sys/dev/re directory. > 2. Fetch http://people.freebsd.org/~yongari/re/8.2R/if_rlreg.h and > copy it /usr/src/sys/pci directory. > And rebuild your kernel and your controller should be recognized in > next boot. Hi YongHyeon PYUN, Oke, that would mean I temporarily have to insert another ether card to get things onboard. Or use the sneaker network. :) I did check the 9.x stuff, but there the revision number was not in /usr/src/sys/pci/if_rlreg.h .... And you are right, they are in 8.2-STABLE. Thanx for the files and pointers --WjW From owner-freebsd-stable@FreeBSD.ORG Sun Aug 21 23:23:12 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFB42106566B for ; Sun, 21 Aug 2011 23:23:12 +0000 (UTC) (envelope-from pyunyh@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 9A4B38FC0C for ; Sun, 21 Aug 2011 23:23:12 +0000 (UTC) Received: by iye7 with SMTP id 7so17995804iye.17 for ; Sun, 21 Aug 2011 16:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ac9hAwXoBItkgHtb6qOSeDwePhxRH1LJ8I08qxkIXFQ=; b=vbvtsfQCvqKSwtLo3WxTokIJuMGW1LCEVH17lLp48pJO2whBx/2mThpJXAKpRLuMTp qBwy8GEgAW3vuhSsyKj9iKDtJqPC88zu0xpuYiU9G+ddRJPJRD1ZtDHHoj3F1b7ant9e cTQd+AEHfrMW0SYUlECzTOqLTQebs0rs1cIm4= Received: by 10.231.60.69 with SMTP id o5mr4501006ibh.65.1313967683410; Sun, 21 Aug 2011 16:01:23 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y14sm3039597ibf.11.2011.08.21.16.01.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Aug 2011 16:01:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 21 Aug 2011 16:01:19 -0700 From: YongHyeon PYUN Date: Sun, 21 Aug 2011 16:01:19 -0700 To: Willem Jan Withagen Message-ID: <20110821230119.GA1755@michelle.cdnetworks.com> References: <4E510FA6.20100@digiware.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E510FA6.20100@digiware.nl> User-Agent: Mutt/1.4.2.3i Cc: "stable@freebsd.org" Subject: Re: Unknown Re0 Hardware version X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 23:23:12 -0000 On Sun, Aug 21, 2011 at 04:01:10PM +0200, Willem Jan Withagen wrote: > Hi, > > I'm assembling a few system with a ASUS P8 H161-MLE motherboard > which was supposed to have a 'RealtekŪ 8112L, 1 x Gigabit LAN > Controller(s)' onboard. > > And to be honestly I never expected that version not to be supported. > Just booted 8.2-RELEASE on it, and the Installer crashed when I wanted > it to config the ehternet. > > Rebooted, and re0 kicks in. But gives a HW revision not supported. > It claims HW revision 0x2c800000. > > Is this supported in later 8.2-Stable??? Or in 9.x?? > > I'm willing to tinker with the code to recompile the re0 driver. > Your controller looks like RTL8168E VL and support for the controller was added after 8.2-RELEASE. Either update your source to stable/8 or patch your source tree with back-ported re(4) driver for 8.2-RELEASE like the following. 1. Fetch http://people.freebsd.org/~yongari/re/8.2R/if_re.c and copy it to /usr/src/sys/dev/re directory. 2. Fetch http://people.freebsd.org/~yongari/re/8.2R/if_rlreg.h and copy it /usr/src/sys/pci directory. And rebuild your kernel and your controller should be recognized in next boot. > --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 06:39:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DED92106566B for ; Mon, 22 Aug 2011 06:39:53 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD4C8FC14 for ; Mon, 22 Aug 2011 06:39:52 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail26.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7M6dnPt022633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 16:39:50 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p7M6dnQN048091; Mon, 22 Aug 2011 16:39:49 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p7M6dmHQ048090; Mon, 22 Aug 2011 16:39:48 +1000 (EST) (envelope-from peter) Date: Mon, 22 Aug 2011 16:39:47 +1000 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20110822063947.GA47945@server.vk2pj.dyndns.org> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20110820032438.GA21925@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: bad sector in gmirror HDD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 06:39:53 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Aug-19 20:24:38 -0700, Jeremy Chadwick w= rote: >The reallocated LBA cannot be dealt with aside from re-creating the >filesystem and telling it not to use the LBA. I see no flags in >newfs(8) that indicate a way to specify LBAs to avoid. And we don't >know what LBA it is so we can't refer to it right now anyway. > >As I said previously, I have no idea how UFS/FFS deals with this. It doesn't. UFS/FFS and ZFS expect and assume "perfect" media. It's up to the drive to transparently remap faulty sectors. UFS used to have support for visible bad sectors (and Solaris UFS still reserves space for this, though I don't know if it still works) but the code was removed from FreeBSD long ago. AFAIR, wd(4) supported bad sectors but it was removed long ago. --=20 Peter Jeremy --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk5R+bMACgkQ/opHv/APuIcr+QCfdoAHKdGbslWCHdxMK0NjSvLk a1gAn2vu2KSaN229Xi+eSK/vkbWlKlQC =WoHk -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 07:49:55 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03E2B106566C; Mon, 22 Aug 2011 07:49:55 +0000 (UTC) (envelope-from yampresss@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 662618FC18; Mon, 22 Aug 2011 07:49:54 +0000 (UTC) Received: by fxe4 with SMTP id 4so4148697fxe.13 for ; Mon, 22 Aug 2011 00:49:53 -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:subject :content-type:content-transfer-encoding; bh=PKwoLGeFdzdY0Zng5rWlV6m4fHhAwRrJlzuas9ZYXAs=; b=iTkk9t2GYfYFVYcGgKWQ4E1HkwoejzsmT/n1QP4j4waP+OHQJCR5LIGOQeV6v8HmIj ySuCjv2UvkPYnoFPzYzgovRFZfKF2VwabkmW+0Y4Y0PZ6ovT5Qjj7XsbtxJic2rX+wcZ zJ1GsonqqbIff7LBJzJs9bnqxAiqTPtUMSKmw= Received: by 10.223.14.146 with SMTP id g18mr3266106faa.3.1313997947040; Mon, 22 Aug 2011 00:25:47 -0700 (PDT) Received: from [10.0.1.3] ([91.218.158.195]) by mx.google.com with ESMTPS id 16sm4884379faw.42.2011.08.22.00.25.46 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 00:25:46 -0700 (PDT) Message-ID: <4E5204B4.106@gmail.com> Date: Mon, 22 Aug 2011 09:26:44 +0200 From: Yampress User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110704 Icedove/3.0.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org, mailto:freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: installer freebsd9 bata1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 07:49:55 -0000 Welcome I installed freebsd 9bata1 and noticed the installer does not create a user account's home directory. Have to manually create after installation. Greet From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 08:05:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E467106566B for ; Mon, 22 Aug 2011 08:05:06 +0000 (UTC) (envelope-from Holger.Kipp@alogis.com) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF618FC15 for ; Mon, 22 Aug 2011 08:05:05 +0000 (UTC) Received: from msx3.exchange.alogis.com (msx3exchange.alogis.com [10.1.1.6] (may be forged)) by alogis.com (8.13.4/8.13.1) with ESMTP id p7M854KP049634; Mon, 22 Aug 2011 10:05:04 +0200 (CEST) (envelope-from Holger.Kipp@alogis.com) Received: from MSX3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61]) by msx3.exchange.alogis.com ([fe80::c8ed:428a:a157:b61%13]) with mapi id 14.01.0255.000; Mon, 22 Aug 2011 10:06:43 +0200 From: Holger Kipp To: Yampress Thread-Topic: installer freebsd9 beta1 Thread-Index: AQHMYKJttrrW7dH2AkC4Y1hLb9w2Ag== Date: Mon, 22 Aug 2011 08:06:42 +0000 Message-ID: <44483776-78EB-44D6-879A-BBE278D8E838@alogis.com> References: <4E5204B4.106@gmail.com> In-Reply-To: <4E5204B4.106@gmail.com> Accept-Language: en-GB, de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" , FreeBSD-STABLE Mailing List Subject: Re: installer freebsd9 beta1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 08:05:06 -0000 Hello *, I'll just add a 'me too'. Had not posted to the list because I wasn't sure if it wasn't because of me :-) Best regards, Holger Am 22.08.2011 um 09:26 schrieb Yampress: > Welcome > I installed freebsd 9bata1 and noticed the installer does not create a us= er account's home directory. > Have to manually create after installation. > Greet > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.kipp@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com ---------------------------------------------------------- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 08:31:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78171065676 for ; Mon, 22 Aug 2011 08:31:48 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5C00A8FC1D for ; Mon, 22 Aug 2011 08:31:47 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7M8Xbsk058071; Mon, 22 Aug 2011 10:33:37 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7M8XaOa058070; Mon, 22 Aug 2011 10:33:36 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 22 Aug 2011 10:33:36 +0200 From: Greg Byshenk To: freebsd-stable@freebsd.org Message-ID: <20110822083336.GI92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110821222033.GH92605@core.byshenk.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: David Wood Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 08:31:49 -0000 On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote: > On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote: > > > I wrote and contributed the support code for the OXPCIe95x serial chips > > - and just happened to notice your report. > > Thanks for the response. > > > > In message <20110821154249.GE92605@core.byshenk.net>, Greg Byshenk > > writes > > >I'm having a problem with a StarTech PEX2S952 dual-port serial > > >card. > > > > > >I believe that it should be supported, as it has this entry in > > >pucdata.c > > > > > >[...] > > > { 0x1415, 0xc158, 0xffff, 0, > > > "Oxford Semiconductor OXPCIe952 UARTs", > > > DEFAULT_RCLK * 0x22, > > > PUC_PORT_NONSTANDARD, 0x10, 0, -1, > > > .config_function = puc_config_oxford_pcie > > > }, > > >[...] > > > > It should be supported. The OXPCIe952 is more awkward to support than > > the OXPCIe954 and OXPCIe958 because it can be configured in so many > > different ways by the board manufacturer. However, 0xc158 is > > configuration that is identical in arrangement as the larger chips, so > > is the configuration I'm most confident of. I've just double-checked the > > data sheets, and can't see any relevant differences between 0xc158 > > OXPCIe952 and the OXPCIe954 I tested the code with. > > > > I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports > > from other OXPCIe954 and OXPCIe958 board users (including someone with a > > 16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x > > on my hardware. > > > > > > >And, while it is recognized at boot -- after adding > > > > > > device puc > > > options COM_MULTIPORT > > > > I'm 99% certain that "options COM_MULTIPORT" relates to the old sio(4) > > code - I certainly don't need it on 8.x. Does it make any difference if > > you delete that line and just leave "device puc"? > > I will rebuild my kernel and try. > > > > >to my kernel, it doesn't seem to be working. The devices '/dev/cuau2' > > >and '/dev/cuau3' show up, and I can connect to them, but they don't > > >seem to pass any traffic. If I connect to the serial console of > > >another machine (one that I know for certain is working), I get > > >nothing at all. > > > > Have you remembered to set the speed (and other relevant options) on the > > .init devices? This is a feature (or is it a quirk) of the uart(4) > > driver that catches many people out. Setting options on the base device > > is normally a no-op. > > > > For example, if the remote device on /dev/cuau2 operates at 115200 bps > > with hardware handshaking, try: > > > > stty -f /dev/cuau2.init speed 115200 crtscts > > Interestingly, it -is- a no-op on the device, which I hadn't noticed. > But trying to set it on the .init fails: > > # stty -f /dev/cuau2.init speed 115200 > stty: /dev/cuau2.init isn't a terminal crtscts > # > > > > One frustrating aspect of adding puc(4) support for many devices is that > > you can't be certain of the clock rate multiplier - the same device can > > crop up on a different manufacturer's board with a different multiplier. > > This problem doesn't occur with the OXPCIe95x devices as they derive > > their 62.5MHz UART clock from the PCI Express clock. Consequently, the > > problem can't be that your board inadvertently operating the UARTs at > > the wrong speed. > > > > > > >I suspect (?) that it may not be recognized as the proper card. Boot > > >and pciconf messages are: > > > > > >puc0: mem > > >0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq > > >30 at device 0.0 on pci4 > > > > That is correct. Are there any more lines afterwards - especially one > > giving the number of UARTs detected? That line is crucial, as, on these > > chips, the number of UARTs has to be read from configuration space > > because you can slave two chips together. > > > > My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64): > > > > puc0: mem > > 0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18 > > at device 0.0 on pci8 > > puc0: 4 UARTs detected > > puc0: [FILTER] > > uart2: <16950 or compatible> on puc0 > > uart2: [FILTER] > > uart3: <16950 or compatible> on puc0 > > uart3: [FILTER] > > uart4: <16950 or compatible> on puc0 > > uart4: [FILTER] > > uart5: <16950 or compatible> on puc0 > > uart5: [FILTER] > > puc0: mem 0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq 30 at device 0.0 on pci4 > puc0: 2 UARTs detected > uart2: <16950 or compatible> at port 1 on puc0 > uart3: <16950 or compatible> at port 2 on puc0 > > > > >puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415 > > >rev=0x00 hdr=0x00 > > > vendor = 'Oxford Semiconductor Ltd' > > > class = simple comms > > > subclass = UART > > > bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled > > > bar [14] = type Memory, range 32, base 0xfa000000, size 2097152, > > > enabled > > > bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152, > > > enabled > > > > That is correct. > > > > >The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite > > >'STABLE' yet, but I don't think that this should matter. > > > > > >Any advice would be much appreciated. The machine is still in > > >test phase, so I can mess around with it as necessary. > > > > Hopefully this gets your Startech board working. I look forward to your > > feedback. > > > > If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954 > > board, offering four ports via a breakout cable, and is normally pretty > > cheap direct from lindy.com (quite possibly cheaper than your two port > > Startech board!). However, this recommendation comes with the proviso > > that I haven't yet tried it with FreeBSD 9.x. > > I'm rebuilding the kernel, and will try tomorrow with the new version. > I think I'll also try setting the speed on the other end to 9600 > (which is what stty reports as the speed) to see if that makes any > difference. > > I'll follow up tomorrow. Thanks. Following up: It appears that indeed, the "options COM_MULTIPORT" is unnecessary for 9-BETA; I've rebuilt the kernel without it, and the card is still recognized, along with the ports. But all it not as it should be. I still can't set the speed on the card. > # stty -f /dev/cuau2.init speed 115200 crtscts > stty: /dev/cuau2.init isn't a terminal > # And setting speed on the device itself remains a no-op: # stty -f /dev/cuau2 speed 115200 crtscts 9600 # That said, the card -does- seem to work, at least at some level. With the speed issue pointed out, I set the connection on the other end to 9600, and then it works. But I'd really like it to be faster than that (it's just a serial console, so we could probably live with 9600, though we wouldn't like it). If there is reason to think that this could be a 9.x issue, then I could try going to 8.x. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 09:24:43 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E45A11065670 for ; Mon, 22 Aug 2011 09:24:43 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7A44A8FC16 for ; Mon, 22 Aug 2011 09:24:43 +0000 (UTC) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 070092209B; Mon, 22 Aug 2011 10:24:42 +0100 (BST) Received: from argon.wood2.org.uk (HELO argon.wood2.org.uk) (82.71.104.124) (smtp-auth username wood, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Mon, 22 Aug 2011 10:24:41 +0100 Message-ID: Date: Mon, 22 Aug 2011 10:23:14 +0100 To: Greg Byshenk From: David Wood References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> In-Reply-To: <20110822083336.GI92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+nsRuL5S5oJLqwOHrGUZxwfdB4>) X-Gradwell-MongoId: 4e522059.16b51-3b22-1 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: wood Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:24:44 -0000 Hi Greg, In message <20110822083336.GI92605@core.byshenk.net>, Greg Byshenk writes >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote: >> puc0: mem >>0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq >>30 at device 0.0 on pci4 >> puc0: 2 UARTs detected >> uart2: <16950 or compatible> at port 1 on puc0 >> uart3: <16950 or compatible> at port 2 on puc0 This indicates that the puc(4) code is working correctly - it recognises the board, reads via one of the BARs to confirm there are two UARTs, initialises both UARTs to 16950 mode, then hands off these ports to uart(4). >> I'll follow up tomorrow. Thanks. > >Following up: > >It appears that indeed, the "options COM_MULTIPORT" is unnecessary >for 9-BETA; I've rebuilt the kernel without it, and the card is >still recognized, along with the ports. That's what I expected. The only line needed is "device puc". I have no idea why this can't be included in GENERIC, especially as puc(4) doesn't work as a module (no drivers are attached to the ports on the puc board). >But all it not as it should be. I still can't set the speed on the >card. > >> # stty -f /dev/cuau2.init speed 115200 crtscts >> stty: /dev/cuau2.init isn't a terminal >> # > >And setting speed on the device itself remains a no-op: > > # stty -f /dev/cuau2 speed 115200 crtscts > 9600 > # > >That said, the card -does- seem to work, at least at some level. >With the speed issue pointed out, I set the connection on the >other end to 9600, and then it works. But I'd really like it to >be faster than that (it's just a serial console, so we could >probably live with 9600, though we wouldn't like it). > >If there is reason to think that this could be a 9.x issue, >then I could try going to 8.x. My earlier instructions omitted mention of the lock, which is really needed if you want to force a particular speed On 8.2: [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 115200 crtscts' ; stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; stty -f ${PORT}.lock 1 ; stty -f ${PORT} speed 115200 baud; lflags: echoe echoke echoctl oflags: tab0 cflags: cs8 -parenb crtscts [root@manganese ~]# cu -l cuau5 Connected ATI4 U.S. Robotics 56K FAX EXT Settings... B0 E1 F1 L2 M1 Q0 V1 X4 Y1 SPEED=115200 PARITY=N WORDLEN=8 DIAL=TONE OFF LINE CID=1 &A3 &B1 &C1 &D2 &H2 &I2 &K1 &M4 &N0 &R1 &S0 &T5 &U0 &Y1 S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 S41=004 S42=000 LAST DIALLED #: OK ~ [EOT] [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 38400 crtscts' ; stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; stty -f ${PORT}.lock 1 ; stty -f ${PORT} speed 38400 baud; lflags: echoe echoke echoctl oflags: tab0 cflags: cs8 -parenb crtscts [root@manganese ~]# cu -l cuau5 Connected ATI4 U.S. Robotics 56K FAX EXT Settings... B0 E1 F1 L2 M1 Q0 V1 X4 Y1 SPEED=38400 PARITY=N WORDLEN=8 DIAL=TONE OFF LINE CID=1 &A3 &B1 &C1 &D2 &H2 &I2 &K1 &M4 &N0 &R1 &S0 &T5 &U0 &Y1 S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 S41=004 S42=000 LAST DIALLED #: OK ~ [EOT] This is one of my OXPCIe954 ports - the modem on that port identifies the speed it is being talked to in the ATI4 output. If this is a 9.x issue, it seems more likely to be in the uart(4) code - though I haven't been following development. If you are getting nowhere with 9.x, can you try with 8.x? stable/8 might be the best choice, as the necessary pucdata.c changes postdates 8.2-RELEASE. That said, I patch 8.2-RELEASE on my machine, choosing to keep things conservative. I look forward to your feedback. With best wishes, David -- David Wood david@wood2.org.uk From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 09:46:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74DB0106566C for ; Mon, 22 Aug 2011 09:46:08 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id C8EFB8FC0C for ; Mon, 22 Aug 2011 09:46:07 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7M9lvQc058458; Mon, 22 Aug 2011 11:47:57 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7M9lv5i058457; Mon, 22 Aug 2011 11:47:57 +0200 (CEST) (envelope-from byshenknet) Date: Mon, 22 Aug 2011 11:47:56 +0200 From: Greg Byshenk To: David Wood Message-ID: <20110822094756.GJ92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 09:46:08 -0000 On Mon, Aug 22, 2011 at 10:23:14AM +0100, David Wood wrote: > In message <20110822083336.GI92605@core.byshenk.net>, Greg Byshenk > writes > >On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote: > >>puc0: mem > >>0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq > >>30 at device 0.0 on pci4 > >>puc0: 2 UARTs detected > >>uart2: <16950 or compatible> at port 1 on puc0 > >>uart3: <16950 or compatible> at port 2 on puc0 > > This indicates that the puc(4) code is working correctly - it recognises > the board, reads via one of the BARs to confirm there are two UARTs, > initialises both UARTs to 16950 mode, then hands off these ports to > uart(4). > > >>I'll follow up tomorrow. Thanks. > > > >Following up: > > > >It appears that indeed, the "options COM_MULTIPORT" is unnecessary > >for 9-BETA; I've rebuilt the kernel without it, and the card is > >still recognized, along with the ports. > > That's what I expected. The only line needed is "device puc". I have no > idea why this can't be included in GENERIC, especially as puc(4) doesn't > work as a module (no drivers are attached to the ports on the puc > board). > > > >But all it not as it should be. I still can't set the speed on the > >card. > > > >> # stty -f /dev/cuau2.init speed 115200 crtscts > >> stty: /dev/cuau2.init isn't a terminal > >> # > > > >And setting speed on the device itself remains a no-op: > > > > # stty -f /dev/cuau2 speed 115200 crtscts > > 9600 > > # > > > >That said, the card -does- seem to work, at least at some level. > >With the speed issue pointed out, I set the connection on the > >other end to 9600, and then it works. But I'd really like it to > >be faster than that (it's just a serial console, so we could > >probably live with 9600, though we wouldn't like it). > > > >If there is reason to think that this could be a 9.x issue, > >then I could try going to 8.x. > > My earlier instructions omitted mention of the lock, which is really > needed if you want to force a particular speed > > > On 8.2: > > [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 115200 crtscts' ; > stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; > stty -f ${PORT}.lock 1 ; stty -f ${PORT} > speed 115200 baud; > lflags: echoe echoke echoctl > oflags: tab0 > cflags: cs8 -parenb crtscts > [root@manganese ~]# cu -l cuau5 > Connected > ATI4 > U.S. Robotics 56K FAX EXT Settings... > > B0 E1 F1 L2 M1 Q0 V1 X4 Y1 > SPEED=115200 PARITY=N WORDLEN=8 > DIAL=TONE OFF LINE CID=1 > > &A3 &B1 &C1 &D2 &H2 &I2 &K1 > &M4 &N0 &R1 &S0 &T5 &U0 &Y1 > > S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 > S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 > S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 > S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 > S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 > S41=004 S42=000 > > LAST DIALLED #: > > OK > ~ > [EOT] > [root@manganese ~]# PORT='/dev/cuau5' ; OPTIONS='speed 38400 crtscts' ; > stty -f ${PORT}.lock 0 ; stty -f ${PORT}.init ${OPTIONS} > /dev/null ; > stty -f ${PORT}.lock 1 ; stty -f ${PORT} > speed 38400 baud; > lflags: echoe echoke echoctl > oflags: tab0 > cflags: cs8 -parenb crtscts > [root@manganese ~]# cu -l cuau5 > Connected > ATI4 > U.S. Robotics 56K FAX EXT Settings... > > B0 E1 F1 L2 M1 Q0 V1 X4 Y1 > SPEED=38400 PARITY=N WORDLEN=8 > DIAL=TONE OFF LINE CID=1 > > &A3 &B1 &C1 &D2 &H2 &I2 &K1 > &M4 &N0 &R1 &S0 &T5 &U0 &Y1 > > S00=000 S01=000 S02=043 S03=013 S04=010 S05=008 S06=004 > S07=060 S08=002 S09=006 S10=014 S11=072 S12=050 S13=000 > S15=000 S16=000 S18=000 S19=000 S21=010 S22=017 S23=019 > S25=005 S27=001 S28=008 S29=020 S30=000 S31=128 S32=002 > S33=000 S34=000 S35=000 S36=014 S38=000 S39=012 S40=000 > S41=004 S42=000 > > LAST DIALLED #: > > OK > ~ > [EOT] > > > This is one of my OXPCIe954 ports - the modem on that port identifies > the speed it is being talked to in the ATI4 output. > > If this is a 9.x issue, it seems more likely to be in the uart(4) code - > though I haven't been following development. If you are getting nowhere > with 9.x, can you try with 8.x? stable/8 might be the best choice, as > the necessary pucdata.c changes postdates 8.2-RELEASE. That said, I > patch 8.2-RELEASE on my machine, choosing to keep things conservative. > > I look forward to your feedback. It doesn't seem to matter; both cuau?.lock and cuau?.init produce the error (for both ports), and cuau? itself remains a no-op. Now that I can see that the card is working (at least minimally), it begins to look as if there might be a problem somewhere in 9.x. I'll try to install 8.x and see if the results are different. I'll followup again when I have something to report. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 11:00:32 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542B21065698 for ; Mon, 22 Aug 2011 11:00:32 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 739138FC29 for ; Mon, 22 Aug 2011 11:00:30 +0000 (UTC) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id E9DBF21F4F; Mon, 22 Aug 2011 12:00:28 +0100 (BST) Received: from argon.wood2.org.uk (HELO argon.wood2.org.uk) (82.71.104.124) (smtp-auth username wood, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Mon, 22 Aug 2011 12:00:28 +0100 Message-ID: Date: Mon, 22 Aug 2011 11:59:11 +0100 To: Greg Byshenk From: David Wood References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <20110822094756.GJ92605@core.byshenk.net> In-Reply-To: <20110822094756.GJ92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+qjRu$Ny5oZMMwOHzWbZxwrhOW>) X-Gradwell-MongoId: 4e5236cc.13184-36e6-1 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: wood Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 11:00:32 -0000 Dear Greg, In message <20110822094756.GJ92605@core.byshenk.net>, Greg Byshenk writes >It doesn't seem to matter; both cuau?.lock and cuau?.init produce the >error (for both ports), and cuau? itself remains a no-op. You could try hint.uart.2.baud="115200" in /boot/device.hints - making the relevant changes to port number and speed according to your needs. >Now that I can see that the card is working (at least minimally), it >begins to look as if there might be a problem somewhere in 9.x. I'll >try to install 8.x and see if the results are different. It will be interesting to see if there is a difference between 8.x and 9.x. >I'll followup again when I have something to report. I look forward to further feedback. With best wishes, David -- David Wood david@wood2.org.uk From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 12:40:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E46681065673 for ; Mon, 22 Aug 2011 12:40:38 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9FF558FC17 for ; Mon, 22 Aug 2011 12:40:38 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QvTnw-0004lh-Tu for freebsd-stable@freebsd.org; Mon, 22 Aug 2011 14:40:36 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Aug 2011 14:40:36 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Aug 2011 14:40:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 22 Aug 2011 14:40:22 +0200 Lines: 23 Message-ID: References: <4E4CD19E.5070108@rawbw.com> <20110818091727.GA61715@icarus.home.lan> <4E4CE199.8030104@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4E4CE199.8030104@rawbw.com> X-Enigmail-Version: 1.1.2 Subject: Re: WD Advanced Format: do I need to do something special? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:40:39 -0000 On 18/08/2011 11:55, Yuri wrote: > On 08/18/2011 02:17, Jeremy Chadwick wrote: >> The below advice still applies. Do not skim the page, read it. >> >> http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html >> >> You will therefore have to go through some manual rigmarole (preferably >> with gpart(8)) to ensure performance. If you plan on using the disks in >> ZFS, you get to go through some extra rigmarole. > > I didn't know about such extra actions that are required and just > created ZFS pool. > zdb -C shows ashift as 9. I read it as meaning that sector size > if 512bytes (wrong!). > > But I tested the 25GB file writing/reading speed on the middle tracks > and it seems reasonable: > WR 55MB/s > RD 107MB/s > > So can I get even better speeds if it was aware of 4k sector? Yes, read and write speeds on modern drives should be almost equal. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 22 12:45:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E9A7106564A for ; Mon, 22 Aug 2011 12:45:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 30A8E8FC14 for ; Mon, 22 Aug 2011 12:45:07 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QvTsI-0006Qb-3J for freebsd-stable@freebsd.org; Mon, 22 Aug 2011 14:45:06 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Aug 2011 14:45:06 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Aug 2011 14:45:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 22 Aug 2011 14:43:57 +0200 Lines: 24 Message-ID: References: <4E4CD19E.5070108@rawbw.com> <4E4DBC24.1070007@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4E4DBC24.1070007@rawbw.com> X-Enigmail-Version: 1.1.2 Subject: Re: WD Advanced Format: do I need to do something special? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:45:07 -0000 On 19/08/2011 03:28, Yuri wrote: > Following instructions here > (http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html) I > destroyed my previous ZFS pool with 512 byte sectors and did this: > gnop create -S 4096 /dev/ad4 > zpool create mypool /dev/ad4.nop > zpol create mypool/mydir > zpool export mypool > gnop destroy /dev/ad4.nop > zpool import mypool > > Now this command 'zdb -C data | grep ashift' shows ashift=12 (4096 byte > sectors). > > However, when I begin to copy a lot of files files into /mypool/mydir > online radio player gets severely affected. Sound get interrupted all > the time. Itrettuptions stop after 1-2 secs after I stop copying. > This didn't happen with sector size 512 bytes. > > What is wrong? Which version of FreeBSD are you doing this on? Do you have any non-default tuning? From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 00:12:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83D43106566C for ; Tue, 23 Aug 2011 00:12:28 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 13D048FC08 for ; Tue, 23 Aug 2011 00:12:27 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7N0CN6Y015409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Aug 2011 10:12:25 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p7N0CM3T029417; Tue, 23 Aug 2011 10:12:22 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p7N0CL09029416; Tue, 23 Aug 2011 10:12:21 +1000 (EST) (envelope-from peter) Date: Tue, 23 Aug 2011 10:12:21 +1000 From: Peter Jeremy To: "Alexander V. Chernikov" Message-ID: <20110823001221.GA29336@server.vk2pj.dyndns.org> References: <4E4143A6.6030307@digsys.bg> <935F8EC2-88E0-45A3-BE8B-7210BE223BC5@mac.com> <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> <4E4CCA6C.8020408@ipfw.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <4E4CCA6C.8020408@ipfw.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: 32GB limit per swap device? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:12:28 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Aug-18 12:16:44 +0400, "Alexander V. Chernikov" = wrote: >The code should look like this: =2E.. >(move pages recalculation before b-list check) I notice a very similar patch has been applied to -current as r225076. For the archives, I've done some testing with this patch on a Sun V890 with 64GB RAM and two 64GB swap partitions. Prior to this patch, each swap partition was truncated to 32GB. With this patch, I have 128GB swap. I've tried filling the swap space to over 80GB and I am not seeing any corruption (allocate lots of memory and fill with a known pseudo-random pattern and then verify). --=20 Peter Jeremy --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk5S8GUACgkQ/opHv/APuIf+ZACfVEsTiGjoLcGBrnUw+gQJjbAd LmoAoI9RavQ3lOOQFYLkFs1X1StMR9cj =Xifn -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 02:47:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B498F1065672 for ; Tue, 23 Aug 2011 02:47:48 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [69.163.100.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9181B8FC12 for ; Tue, 23 Aug 2011 02:47:48 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.5/8.14.4) with ESMTP id p7N2amWC040698; Mon, 22 Aug 2011 19:36:48 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.5/8.14.4/Submit) id p7N2akxB040696; Mon, 22 Aug 2011 19:36:46 -0700 (PDT) Date: Mon, 22 Aug 2011 19:36:46 -0700 (PDT) From: Matthew Dillon Message-Id: <201108230236.p7N2akxB040696@apollo.backplane.com> To: freebsd-stable@freebsd.org, Alan Cox References: <4E4143A6.6030307@digsys.bg> <935F8EC2-88E0-45A3-BE8B-7210BE223BC5@mac.com> <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> <4E4CCA6C.8020408@ipfw.ru> <20110820174147.GW17489@deviant.kiev.zoral.com.ua> <4E4FFAD3.4090706@rice.edu> <4E500014.6030800@ipfw.ru> <20110820191726.GY17489@deviant.kiev.zoral.com.ua> Cc: Subject: Re: 32GB limit per swap device? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 02:47:48 -0000 The limitation was ONLY due to a *minor* 32-bit integer overflow in one or two *intermediate* calculations in the radix tree code, which I long ago fixed in DragonFly. Just find the changes in the DFly codebase and determine if they need to be applied. The swap space radix code (which I wrote long ago) is in page-sized blocks, so you actually probably want to keep using a 32-bit integer for the block number there to keep the physical memory reservation required for the radix tree low. If you just pop the base block id up to 64 bits without adjusting the radix code to overlay a 64 bit bitmap on it you waste a lot of physical memory for the same amount of swap reservation. This is NOT where the limitation lies. It was strictly an intermediate calculation that caused the original limitation. With 32 bit block numbers stored in the radix tree nodes in the swap code the physical limitation is something like 1 to 4 TB of total swap. I forget exactly but it is at least 1TB. I've tested 1TB swap partitions on DragonFly with just the minor fixes to the original radix tree code. -- Also note that I believe FreeBSD has done away with the interleaved swap. I'm not sure why, I guess geom can interleave the swap for you but I've always thought that it would be easier to just specify and add the partitions separately so one has the flexibility to swapon and swapoff the individual partitions on a live system. Interleaving is important because you get an almost perfect performance multiplier. You don't want to just append the swap partitions after each other. -- One last thing: The amount of wired physical memory required is still on the order of ~1MB per ~1GB of swap. A 32-bit kernel is thus still limited by available KVM, effectively limiting you to around ~32G of swap depending on various factors if you do not want to run the system out of KVM. I've run upwards of 128G of swap on 32-bit systems but it really pushed the KVM use and I would not recommend it. A 64-bit kernel is *NOT* limited by KVM. Swap is effectively limited to ~1TB or ~2TB using the original radix code with the one or two intermediate overflow fixes applied. The daddr_t in the original radix code can remain 32-bits (in DragonFly I typedef'd another name so I could explicitly make it 32-bits regardless of daddr_t). Large amounts of swap space are becoming important as things like tmpfs (and swapcache in DragonFly as well) can really make use of it. Swap performance (the ability to interleave the swap space) is also important for the same reason. Interleaved swap on two SATA-III SSDs is just insane... gives you something like 800MB/sec of aggregate read bandwidth. -Matt From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 07:21:01 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A127D1065675 for ; Tue, 23 Aug 2011 07:21:01 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [69.163.100.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5BBAB8FC1B for ; Tue, 23 Aug 2011 07:21:01 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.5/8.14.4) with ESMTP id p7N7L0ru042199; Tue, 23 Aug 2011 00:21:00 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.5/8.14.4/Submit) id p7N7L0qH042198; Tue, 23 Aug 2011 00:21:00 -0700 (PDT) Date: Tue, 23 Aug 2011 00:21:00 -0700 (PDT) From: Matthew Dillon Message-Id: <201108230721.p7N7L0qH042198@apollo.backplane.com> To: freebsd-stable@freebsd.org, Alan Cox References: <4E4143A6.6030307@digsys.bg> <935F8EC2-88E0-45A3-BE8B-7210BE223BC5@mac.com> <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> <4E4CCA6C.8020408@ipfw.ru> <20110820174147.GW17489@deviant.kiev.zoral.com.ua> <4E4FFAD3.4090706@rice.edu> <4E500014.6030800@ipfw.ru> <20110820191726.GY17489@deviant.kiev.zoral.com.ua> <201108230236.p7N2akxB040696@apollo.backplane.com> Cc: Subject: Re: 32GB limit per swap device? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 07:21:01 -0000 Two additional pieces of information. The original limitation was more related to DEV_BSIZE calculations for the buf/bio, which is now 64-bits and thus not applicable, though you probably need some preemptive casts to ensure the multiplication is done in 64-bits. There was also another intermediate calculation overflow in the swap radix-tree code which had to be fixed to be able to use the full range... I think w/simple casts. I haven't looked it up but there should be a few commits in the DFly codebase that can be referenced. Second item: The main physical memory use is not the radix tree bitmap code for the swap code, but instead the auxillary data structure used to store the swapblk information which is associated with the vm_object structure. This structure contains a short array of swap block assignments (as a memory optimization to reduce header overhead) and it is these fields which you really want to keep 32-bits (unless you want the ~1MB per ~1GB of swap to become ~2MB per ~1GB of swap in physical memory overhead). The block number is in page-sized chunks so the practical limit is still ~4TB, with a further caveat below. The further caveat is that the actual limitation for the radix tree is 0x40000000 blocks, which is 1/4 the full range or ~1TB, so the actual limitation for the (fixed) original radix tree code is ~1TB rather than ~4TB. This restricted range is due to some shift << >> operators used in the radix tree code that I didn't want to make more complicated. So, my recommendation is to fix the intermediate calculations and keep the swapblk related blockno fields 32 bits. The preallocation for the vm_object's auxillary structure must be large enough to actually be able to fill up swap and assign all the swap blocks. This is what eats the physical memory (4 bytes per 4K = 1024x storage factor). The radix tree bitmap itself winds up eating only around 2 bits per swap block in total overhead. So the auxillary structure is the main culprit. You definitely want to keep those block number fields in the aux structure 32 bits. The practical limit of ~1TB of swap requires ~1GB of preallocated physical memory with a 32 bit block number field. That would become ~2GB of preallocated memory if 64 bit block numbers were used instead, for no gain other than wasting physical memory. Ok, nobody is likely to actually need that much swap but people might be surprised, there are a lot of modern-day uses for swap space that don't involve heavy paging of anonymous memory. -Matt From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 07:30:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73393106564A for ; Tue, 23 Aug 2011 07:30:42 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7C48FC1B for ; Tue, 23 Aug 2011 07:30:41 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 76B6B29041D; Tue, 23 Aug 2011 02:30:40 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id zTgIgcwvFW69; Tue, 23 Aug 2011 02:30:40 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 109FF29040A; Tue, 23 Aug 2011 02:30:39 -0500 (CDT) Message-ID: <4E53571F.2080701@rice.edu> Date: Tue, 23 Aug 2011 02:30:39 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Matthew Dillon References: <4E4143A6.6030307@digsys.bg> <935F8EC2-88E0-45A3-BE8B-7210BE223BC5@mac.com> <4e42a0c0.e2t/9MF98O3HFjb1%perryh@pluto.rain.com> <4E4CCA6C.8020408@ipfw.ru> <20110820174147.GW17489@deviant.kiev.zoral.com.ua> <4E4FFAD3.4090706@rice.edu> <4E500014.6030800@ipfw.ru> <20110820191726.GY17489@deviant.kiev.zoral.com.ua> <201108230236.p7N2akxB040696@apollo.backplane.com> In-Reply-To: <201108230236.p7N2akxB040696@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 32GB limit per swap device? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 07:30:42 -0000 On 08/22/2011 21:36, Matthew Dillon wrote: > The limitation was ONLY due to a *minor* 32-bit integer overflow in one > or two *intermediate* calculations in the radix tree code, which I > long ago fixed in DragonFly. > > Just find the changes in the DFly codebase and determine if they need > to be applied. > > The swap space radix code (which I wrote long ago) is in page-sized > blocks, so you actually probably want to keep using a 32-bit integer for > the block number there to keep the physical memory reservation required > for the radix tree low. If you just pop the base block id up to 64 bits > without adjusting the radix code to overlay a 64 bit bitmap on it you > waste a lot of physical memory for the same amount of swap reservation. Unfortunately, in FreeBSD, when daddr_t was increased to 64 bits a few years ago, the bitmap size was not increased. So, we have been wasting about half the space used by the blist structure for some time now. I expect that we'll fix this after the current code freeze ends. However, as Alexander observed, the primary reason for the 32GB limit on the size of a swap partition was artificial. The limit was being implemented in the wrong place. It was being performed before the conversion from 512 byte blocks to 4KB pages. Since a blist is managing swap space at the granularity of pages and the limit is imposed by the blist code, the check should come after the conversion. Just by moving the check to its proper place, the effective limit can be increased from 32GB to 256GB. Kostik committed such a change earlier today. Alan From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 07:43:10 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F41C106564A for ; Tue, 23 Aug 2011 07:43:10 +0000 (UTC) (envelope-from nbeck@hobsoft.com.mt) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5CFD68FC17 for ; Tue, 23 Aug 2011 07:43:10 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QvlNj-0003bW-82 for freebsd-stable@freebsd.org; Tue, 23 Aug 2011 00:26:43 -0700 Date: Tue, 23 Aug 2011 00:26:43 -0700 (PDT) From: noel beck To: freebsd-stable@freebsd.org Message-ID: <1314084403216-4725801.post@n5.nabble.com> In-Reply-To: <201103092015.p29KFd0U077849@dave.dignus.com> References: <201103092015.p29KFd0U077849@dave.dignus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: -m32 on freeBSD 8.2r amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 07:43:10 -0000 We are trying to compile i386 on a FreeBSD 8.2r amd64. we are getting an error stating that libstdc++.so.6, is missing. COMPACT6x and COMPACT7x have been installed. But this does not solve the problem. Is it possible to compile i386 on and amd64 system? -- View this message in context: http://freebsd.1045724.n5.nabble.com/bin-139146-still-not-right-in-FreeBSD-8-2-m32-on-amd64-tp3965590p4725801.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 08:08:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA50E106566B for ; Tue, 23 Aug 2011 08:08:19 +0000 (UTC) (envelope-from sodynet1@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 89D618FC17 for ; Tue, 23 Aug 2011 08:08:19 +0000 (UTC) Received: by iye7 with SMTP id 7so23315774iye.17 for ; Tue, 23 Aug 2011 01:08:19 -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=jeLK5WWaPYyxvIVOVknB9hW64R1XNNevP3srSaaywVg=; b=TvvFIOeUDkqzxoKZiBtmBgBfcf0Cpn0HnOhRVOmeLLQN7mecb4DibEtxT4zwExfoOp r2JUF2yDGDfC5q1tdvBGD783ca3TM67DJQ4e+BjP6uTT6g4FvRU9PjHciQqc0+yzjLZ6 hu3VJ9u69zq3j5i/IkIJXrFqkIYzyyYThaIyM= MIME-Version: 1.0 Received: by 10.231.48.11 with SMTP id p11mr7197733ibf.57.1314085180123; Tue, 23 Aug 2011 00:39:40 -0700 (PDT) Received: by 10.231.208.70 with HTTP; Tue, 23 Aug 2011 00:39:40 -0700 (PDT) Date: Tue, 23 Aug 2011 10:39:40 +0300 Message-ID: From: Sami Halabi To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 10G Inter adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 08:08:19 -0000 Hi everyone, i have a 82599EB network card. the ixgbe driver on 8* supports 82598 cards, although it identified my card but i'm not sure it will work fine and won't make kernel panics, since its a production server i want to put a good driver that will work without problems. I just found this from the Intel website. Looks like they have added support for the 82598 and 82599 which isn't on the ixgbe driver on 8 stable/release. * http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=14688&lang=eng * is it safe to dowload and put the files of this driver in /sys/dev/ixgbe and then install it? is it simply: *make && make install && make clean*? i guess i need to recompile the kernel also because ixgbe is on the GENERIC kernel. what do you advise me? -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 08:11:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFAF7106564A for ; Tue, 23 Aug 2011 08:11:48 +0000 (UTC) (envelope-from edho@myconan.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 793178FC12 for ; Tue, 23 Aug 2011 08:11:48 +0000 (UTC) Received: by yxn22 with SMTP id 22so3482632yxn.13 for ; Tue, 23 Aug 2011 01:11:47 -0700 (PDT) Received: by 10.42.132.194 with SMTP id e2mr3582745ict.127.1314085601095; Tue, 23 Aug 2011 00:46:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.184.5 with HTTP; Tue, 23 Aug 2011 00:46:11 -0700 (PDT) In-Reply-To: <1314084403216-4725801.post@n5.nabble.com> References: <201103092015.p29KFd0U077849@dave.dignus.com> <1314084403216-4725801.post@n5.nabble.com> From: Edho Arief Date: Tue, 23 Aug 2011 14:46:11 +0700 Message-ID: To: noel beck Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: -m32 on freeBSD 8.2r amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 08:11:48 -0000 On Tue, Aug 23, 2011 at 2:26 PM, noel beck wrote: > We are trying to compile i386 on a FreeBSD 8.2r amd64. > we are getting an error stating that libstdc++.so.6, is missing. > COMPACT6x and COMPACT7x have been installed. But this does not solve the > problem. > Is it possible to compile i386 on and amd64 system? > I believe compiler flags to /lib32 is required (-L/usr/lib32 or something) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 18:33:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65454106567B for ; Tue, 23 Aug 2011 18:33:57 +0000 (UTC) (envelope-from jfvogel@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 1F0778FC1D for ; Tue, 23 Aug 2011 18:33:56 +0000 (UTC) Received: by vxh11 with SMTP id 11so452399vxh.13 for ; Tue, 23 Aug 2011 11:33:56 -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=jRGiY0GHvLYeFiSsGX1qWr9HryNDcr67JJBweh135lQ=; b=FGBccLbav3lKOb9Fx3hKDRam/XbvdY2zB4pkV9uz0AKOGsWqbPA14Vggcq2Qt4NDaW wpJLCy/bAhXdyp5eicx2fnLcKLrPQqRxIAHHqFke8/uNjaaK0WvjsAD8vJNrTC62Xf8P e2lQOtctnD0u2BB2287vfYVCWag2ix+lah+/g= MIME-Version: 1.0 Received: by 10.52.23.198 with SMTP id o6mr4116401vdf.269.1314122724841; Tue, 23 Aug 2011 11:05:24 -0700 (PDT) Received: by 10.52.113.8 with HTTP; Tue, 23 Aug 2011 11:05:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Aug 2011 11:05:21 -0700 Message-ID: From: Jack Vogel To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 10G Inter adapter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:33:57 -0000 What OS release are you going to be using, 8.2 ? The driver in HEAD is the latest code, the internal tarball goes thru release machinery so it is lagging a bit (2.3.8 vs 2.3.11), you should be OK in either case, but I'd recommend the newer. Jack On Tue, Aug 23, 2011 at 12:39 AM, Sami Halabi wrote: > Hi everyone, > i have a 82599EB network card. > the ixgbe driver on 8* supports 82598 cards, although it identified my card > but i'm not sure it will work fine and won't make kernel panics, since its > a > production server i want to put a good driver that will work without > problems. > > I just found this from the Intel website. > Looks like they have added support for the 82598 and 82599 which isn't on > the ixgbe driver on 8 stable/release. > > * > > http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=14688&lang=eng > * > > is it safe to dowload and put the files of this driver in /sys/dev/ixgbe > and > then install it? > > is it simply: *make && make install && make clean*? > i guess i need to recompile the kernel also because ixgbe is on the GENERIC > kernel. > > what do you advise me? > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 20:06:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79405106566B for ; Tue, 23 Aug 2011 20:06:47 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (unknown [IPv6:2001:470:1f08:19f2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A92F8FC16 for ; Tue, 23 Aug 2011 20:06:47 +0000 (UTC) Received: from fuzz.geek.sh (c213-100-159-170.swipnet.se [213.100.159.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id BA3273A3A4 for ; Tue, 23 Aug 2011 22:06:44 +0200 (SAST) Message-ID: <4E540817.4080102@phat.za.net> Date: Tue, 23 Aug 2011 22:05:43 +0200 From: Aragon Gouveia User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110710 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: reproducible panic on 8.2-RELEASE, but no core file X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:06:47 -0000 Hi, I'm experiencing a reproducible kernel panic that would be really nice to debug, but unfortunately no core file is getting generated. I don't have console access either. All I can get so far is this, from syslog: Aug 23 19:51:38 estranged kernel: Aug 23 19:51:38 estranged kernel: Fatal double fault: Aug 23 19:51:38 estranged kernel: eip = 0xc0593b2e Aug 23 19:51:38 estranged kernel: esp = 0xe5583fe4 Aug 23 19:51:38 estranged kernel: ebp = 0xe5584010 Aug 23 19:51:38 estranged kernel: cpuid = 0; apic id = 00 Aug 23 19:51:38 estranged kernel: panic: double fault Aug 23 19:51:38 estranged kernel: cpuid = 0 Aug 23 19:51:38 estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 estranged kernel: cpuid = 0 Aug 23 19:51:38 estranged kernel: panic: 0xc4263b40 must be migratable Aug 23 19:51:38 estranged kernel: cpuid = 0 [SNIP - above two lines repeated alot] Aug 23 19:51:38 estranged kernel: cpuid = 0kernel trap 12 with interrupts disabled Aug 23 19:51:38 estranged kernel: panic: Aug 23 19:51:38 estranged kernel: 0xc4263b40 must be migratablekernel trap 12 with interrupts disabled Aug 23 19:51:38 estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 estranged kernel: cpuid = 0 Aug 23 19:51:38 estranged kernel: kernel trap 12 with interrupts disabled Aug 23 19:51:38 estranged kernel: panic: My dumpdev is set: $ ls -l /dev/dumpdev lrwxr-xr-x 1 root wheel 11 Aug 23 19:56 /dev/dumpdev@ -> /dev/ad4s1b But savecore reports: Aug 23 19:56:34 estranged kernel: No core dumps found. Any advice for getting a core file? :) Thanks, Aragon From owner-freebsd-stable@FreeBSD.ORG Tue Aug 23 21:08:33 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9F94106564A for ; Tue, 23 Aug 2011 21:08:32 +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 201A08FC14 for ; Tue, 23 Aug 2011 21:08:31 +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 AAA03177; Wed, 24 Aug 2011 00:08:24 +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 1QvyCt-0007nW-RS; Wed, 24 Aug 2011 00:08:23 +0300 Message-ID: <4E5416C4.8090207@FreeBSD.org> Date: Wed, 24 Aug 2011 00:08:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110819 Thunderbird/6.0 MIME-Version: 1.0 To: Aragon Gouveia References: <4E540817.4080102@phat.za.net> In-Reply-To: <4E540817.4080102@phat.za.net> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: reproducible panic on 8.2-RELEASE, but no core file X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:08:33 -0000 on 23/08/2011 23:05 Aragon Gouveia said the following: > Hi, > > I'm experiencing a reproducible kernel panic that would be really nice to debug, > but unfortunately no core file is getting generated. I don't have console > access either. All I can get so far is this, from syslog: > > Aug 23 19:51:38 estranged kernel: > Aug 23 19:51:38 estranged kernel: Fatal double fault: > Aug 23 19:51:38 estranged kernel: eip = 0xc0593b2e > Aug 23 19:51:38 estranged kernel: esp = 0xe5583fe4 > Aug 23 19:51:38 estranged kernel: ebp = 0xe5584010 > Aug 23 19:51:38 estranged kernel: cpuid = 0; apic id = 00 > Aug 23 19:51:38 estranged kernel: panic: double fault > Aug 23 19:51:38 estranged kernel: cpuid = 0 > Aug 23 19:51:38 estranged kernel: panic: 0xc4263b40 must be migratable > Aug 23 19:51:38 estranged kernel: cpuid = 0 > Aug 23 19:51:38 estranged kernel: panic: 0xc4263b40 must be migratable > Aug 23 19:51:38 estranged kernel: cpuid = 0 > [SNIP - above two lines repeated alot] > Aug 23 19:51:38 estranged kernel: cpuid = 0kernel trap 12 with > interrupts disabled > Aug 23 19:51:38 estranged kernel: panic: > Aug 23 19:51:38 estranged kernel: 0xc4263b40 must be > migratablekernel trap 12 with interrupts disabled > Aug 23 19:51:38 estranged kernel: kernel trap 12 with interrupts > disabled > Aug 23 19:51:38 estranged kernel: cpuid = 0 > Aug 23 19:51:38 estranged kernel: kernel trap 12 with interrupts > disabled > Aug 23 19:51:38 estranged kernel: panic: > > My dumpdev is set: > > $ ls -l /dev/dumpdev > lrwxr-xr-x 1 root wheel 11 Aug 23 19:56 /dev/dumpdev@ -> /dev/ad4s1b > > But savecore reports: > > Aug 23 19:56:34 estranged kernel: No core dumps found. > > Any advice for getting a core file? :) Not sure about the core file - I think that we do not attempt to do a dump when we get a doublefault which is what you have, but not sure about this. Also, those secondary panics might be coming from the sched_bind() call at the start of boot() function in sys/kern/kern_shutdown.c. For a start you can try adding DDB to your kernel config and capturing a stack trace of the panic from the ddb prompt. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 07:06:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE2B6106566C for ; Wed, 24 Aug 2011 07:06:33 +0000 (UTC) (envelope-from byshenknet@byshenk.net) Received: from core.byshenk.net (core.byshenk.net [62.58.73.230]) by mx1.freebsd.org (Postfix) with ESMTP id 507A38FC14 for ; Wed, 24 Aug 2011 07:06:32 +0000 (UTC) Received: from core.byshenk.net (localhost [127.0.0.1]) by core.byshenk.net (8.14.4/8.14.4) with ESMTP id p7O78Q0C082011; Wed, 24 Aug 2011 09:08:27 +0200 (CEST) (envelope-from byshenknet@core.byshenk.net) Received: (from byshenknet@localhost) by core.byshenk.net (8.14.4/8.14.4/Submit) id p7O78QfX082010; Wed, 24 Aug 2011 09:08:26 +0200 (CEST) (envelope-from byshenknet) Date: Wed, 24 Aug 2011 09:08:26 +0200 From: Greg Byshenk To: David Wood Message-ID: <20110824070826.GK92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <20110822094756.GJ92605@core.byshenk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on core.byshenk.net Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 07:06:33 -0000 On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > In message <20110822094756.GJ92605@core.byshenk.net>, Greg Byshenk > writes > >It doesn't seem to matter; both cuau?.lock and cuau?.init produce the > >error (for both ports), and cuau? itself remains a no-op. > > You could try > hint.uart.2.baud="115200" > > in /boot/device.hints - making the relevant changes to port number and > speed according to your needs. This does not help; speed remains set to 9600. > >Now that I can see that the card is working (at least minimally), it > >begins to look as if there might be a problem somewhere in 9.x. I'll > >try to install 8.x and see if the results are different. > > It will be interesting to see if there is a difference between 8.x and > 9.x. Yes, there is. Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, the controller works as expected. It defaults to 9600, but setting the speed on the cuaa?.lock and cuaa?.init devices works. Interestingly, setting the speed in device.hints does _not_ work. So, it appears that there is something wrong (or at least different) with 9.x Doing some poking around, I see that, in 9.x, termios.h is not included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While it is included under 8.x. If I look at the 8.x .c files, they want #include ... which appears to no longer be used. But adding either that, or #include ... produces errors: /usr/src/sys/dev/uart/uart_core.c:47:21: error: termios.h: No such file or directory /usr/src/sys/dev/uart/uart_tty.c:42:21: error: termios.h: No such file or directory mkdep: compile failed *** Error code 1 Though a fresh build of world seems to produce termios.h: # find /usr/obj/ |grep termios.h /usr/obj/usr/src/lib32/usr/include/sys/termios.h /usr/obj/usr/src/lib32/usr/include/sys/_termios.h /usr/obj/usr/src/lib32/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/termios.h /usr/obj/usr/src/tmp/usr/include/sys/termios.h /usr/obj/usr/src/tmp/usr/include/sys/_termios.h # But I may be completely confused here, as I don't pretend to be familiar with all of the details of the build process. Does this look like a bug with 9.x, or something that should be done differently? -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 08:31:53 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E073106566B; Wed, 24 Aug 2011 08:31:53 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 36AF68FC08; Wed, 24 Aug 2011 08:31:53 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p7O8VqmL015456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Aug 2011 01:31:52 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p7O8Vqf3015455; Wed, 24 Aug 2011 01:31:52 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA06034; Wed, 24 Aug 11 01:14:31 PDT Date: Wed, 24 Aug 2011 08:14:06 -0700 From: perryh@pluto.rain.com To: vincepoy@gmail.com, freebsd@jdc.parodius.com Message-Id: <4e55153e.Tj16zX3SskfuVesE%perryh@pluto.rain.com> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> <20110821050051.GA47415@icarus.home.lan> <4e5141dd.mmh6t9R/knnc8Jll%perryh@pluto.rain.com> In-Reply-To: <4e5141dd.mmh6t9R/knnc8Jll%perryh@pluto.rain.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4e55153e.L1trZsjhfo2jeiv2tq66KJ/nqbPar7gh7CvMeIrYte3j0fod" Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org, utisoft@gmail.com Subject: ports/sysutils/diskcheckd (Re: bad sector in gmirror HDD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:31:53 -0000 This is a multi-part message in MIME format. --=_4e55153e.L1trZsjhfo2jeiv2tq66KJ/nqbPar7gh7CvMeIrYte3j0fod Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline > When the specified or calculated rate exceeds 64KB/sec, the > required sleep interval between 64KB chunks is less than one > second. Since diskcheckd calculates the interval in whole seconds > -- because it calls sleep() rather than usleep() or nanosleep() > -- an interval of less than one second is calculated as zero ... > I suspect the fix will be to calculate in microseconds, and call > usleep() instead of sleep(). I think I may have this fixed. Could one of you try the attached patch? I'm especially interested to see if this also clears up the issues reported as connected with gmirror (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566), since I haven't been able to reproduce that part here. Summary of changes: * Calculate delays in microseconds, so that delays of less than one second between reads (needed to implement rates exceeding 64KB/sec) do not get rounded down to zero. * Fix a reinitialization problem when handling SIGHUP. * Additional debug messages (only with -d). * Comment and manpage improvememts. --=_4e55153e.L1trZsjhfo2jeiv2tq66KJ/nqbPar7gh7CvMeIrYte3j0fod Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="2011-0823.test.diff" diff -ruN diskcheckd.old/files/diskcheckd.8 diskcheckd.new/files/diskcheckd.8 --- diskcheckd.old/files/diskcheckd.8 2001-08-28 22:16:22.000000000 -0700 +++ diskcheckd.new/files/diskcheckd.8 2011-08-24 07:09:16.000000000 -0700 @@ -58,15 +58,16 @@ The second format consists of four white space separated fields, which are the full pathname of the disk device, -the size of that disk, -the frequency in days at which to check that disk, +the size of this disk, +the frequency in days at which to check this disk, and the rate in kilobytes per second at which to check this disk. -Naturally, -it would be contradictory to specify both the frequency and the rate, -so only one of these should be specified. -Additionally, -the size of the disk should not be specified if the rate is specified, -as this information is unnecessary. +.Pp +Either the frequency or the rate should be specified, not both, +since a specified frequency will be internally converted to whatever +rate will result in the disk being scanned at (approximately) that +frequency. +The size of the disk should not be specified if the rate is specified, +since the size is used only to convert a specified frequency into a rate. .Pp If the disk is specified as .Dq * , @@ -89,7 +90,7 @@ Note that .Nm always reads data from the disk in 64KB blocks, -so the rate your specify may not be the exact rate at which the disk is +so the rate you specify may not be the exact rate at which the disk is actually checked. Similarly, if you specify the third field (days for complete scan) it is unlikely @@ -132,8 +133,14 @@ If this flag is specified, .Nm will not fork into the background and detach from its controlling terminal -to become a daemon. -This flag is primarily used for debugging. +to become a daemon, +and it will duplicate its system log messages on its standard error output. +.Pp +This flag is primarily used for debugging, +and may be specified more than once. +Additional instances will result in additional +debugging messages on standard error; +these added messages will not be written to the system log. .It Fl f Specify the configuration file to use, instead of the default @@ -143,6 +150,13 @@ instead of the default .Pa /var/db/diskcheckd.offsets . .El +.Sh PROGRESS REPORTING +After every 5 minutes or so of sleep time between reads +(not including time spent waiting for the reads themselves to complete), +.Nm +will update its command parameter space to show its progress +in scanning each disk. This report can be viewed using +.Xr ps 1 . .Sh FILES .Bl -tag -width /var/db/diskcheckd.offsets -compact .It Pa /usr/local/etc/diskcheckd.conf @@ -188,3 +202,6 @@ .Sh BUGS .Nm assumes all disks have 512 byte sectors. +.Pp +The code that attempts to identify and report which slice and partition +contain a detected error does not understand GPT partitions. diff -ruN diskcheckd.old/files/diskcheckd.c diskcheckd.new/files/diskcheckd.c --- diskcheckd.old/files/diskcheckd.c 2004-10-27 22:18:33.000000000 -0700 +++ diskcheckd.new/files/diskcheckd.c 2011-08-24 07:05:00.000000000 -0700 @@ -63,10 +63,12 @@ char *device; off_t size; int secsize; - int days, rate, errors, interval, next; + int days, rate, errors; + long long interval, next; }; volatile sig_atomic_t got_sighup = 0, got_sigterm = 0; +volatile int debug = 0; char **getdisknames(char **, int); off_t dseek(struct disk *, off_t, int); @@ -85,9 +87,11 @@ main(int argc, char *argv[]) { char *buf; struct disk *disks, *dp; - int ch, ok, minwait, nextwait; + int ch, ok; + long long minwait, nextwait; struct sigaction sa; - int counter, debug; + long long counter; + int initial_debug; const char *conf_file, *save_file; conf_file = _PATH_CONF; @@ -97,7 +101,10 @@ while ((ch = getopt(argc, argv, "df:o:")) != -1) switch (ch) { case 'd': - debug = 1; + if (debug) + debug *= 2; + else + debug = 1; break; case 'f': conf_file = optarg; @@ -116,7 +123,9 @@ if (argc != 0) usage(); - openlog("diskcheckd", LOG_CONS|LOG_PID, LOG_DAEMON); + initial_debug = debug; + + openlog("diskcheckd", LOG_CONS|LOG_PID|(debug?LOG_PERROR:0), LOG_DAEMON); if (!debug && daemon(0, 0) < 0) { syslog(LOG_NOTICE, "daemon failure: %m"); @@ -150,20 +159,24 @@ * each disk's 'next' field, and when that reaches zero, * that disk is read again. */ - counter = 0; - minwait = 0; + counter = 0LL; + minwait = 0LL; while (!got_sigterm) { ok = 0; - nextwait = INT_MAX; + nextwait = LLONG_MAX; for (dp = disks; dp->device != NULL; dp++) if (dp->fd != -1) { + if (debug > 1) + fprintf(stderr, + "%s: next(%qd) -= %qd\n", + dp->device, dp->next, minwait); if ((dp->next -= minwait) == 0) { ok = 1; readchunk(dp, buf); } /* XXX debugging */ - if (dp->next < 0) { + if (dp->next < 0LL) { syslog(LOG_NOTICE, "dp->next < 0 for %s", dp->device); abort(); @@ -178,14 +191,33 @@ exit(EXIT_FAILURE); } - if (counter >= 300) { + /* 300 seconds => 5 minutes */ + if (counter >= 300000000LL) { + if (debug) + fprintf(stderr, "counter rollover %qd => 0\n", + counter); updateproctitle(disks); writeoffsets(disks, save_file); - counter = 0; + counter = 0LL; } minwait = nextwait; - sleep(minwait); + if (debug > 1) { + --debug; + fprintf(stderr, "sleep %qd, counter %qd\n", + minwait, counter); + } + + /* + * Handle whole seconds and usec separately to avoid overflow + * when calling usleep -- useconds_t is only 32 bits on at + * least some architectures, and minwait (being long long) + * may exceed INT_MAX. + */ + if (minwait > 1000000LL) + sleep((unsigned int)(minwait / 1000000)); + if ((minwait % 1000000) > 0) + usleep((useconds_t)(minwait % 1000000)); counter += minwait; if (got_sighup) { @@ -194,6 +226,11 @@ * memory used for the disk structures, and then * re-read the config file and the disk offsets. */ + if (debug) { + fprintf(stderr, "got SIGHUP, counter == %qd\n", + counter); + debug = initial_debug; + } writeoffsets(disks, save_file); for (dp = disks; dp->device != NULL; dp++) { free(dp->device); @@ -202,10 +239,14 @@ free(disks); disks = readconf(conf_file); readoffsets(disks, save_file); + minwait = 0LL; got_sighup = 0; } } + if (debug) + fprintf(stderr, "got %s, counter == %qd\n", + got_sigterm==SIGTERM?"SIGTERM":"SIGINT", counter); writeoffsets(disks, save_file); return (EXIT_SUCCESS); } @@ -384,6 +425,9 @@ char *space, buf[1024]; if ((fp = fopen(save_file, "r")) == NULL) { + if (debug > 1 && errno == ENOENT) + fprintf(stderr, "open %s failed: %s [continuing]\n", + save_file, strerror(errno)); if (errno != ENOENT) syslog(LOG_NOTICE, "open %s failed: %m", save_file); return; @@ -398,10 +442,15 @@ dp->device != NULL && strcmp(dp->device, buf) != 0; dp++) ; /* nothing */ - if (dp->device != NULL) + if (dp->device != NULL) { + if (debug) + fprintf(stderr, "%s: seek %s", buf, space + 1); dseek(dp, (off_t)strtoq(space + 1, NULL, 0), SEEK_SET); + } } fclose(fp); + if (debug) + fprintf(stderr, "readoffsets: done\n"); } /* @@ -418,10 +467,21 @@ return; } + if (debug) + fprintf(stderr, + "#\tposition/size\tdays\trate\terrors\tintvl\tnext\n"); for (dp = disks; dp->device != NULL; dp++) - if (strcmp(dp->device, "*") != 0) + if (strcmp(dp->device, "*") != 0) { fprintf(fp, "%s %qd\n", dp->device, (quad_t)dseek(dp, 0, SEEK_CUR)); + if (debug) { + fprintf(stderr, "%s %qd\n", dp->device, + (quad_t)dseek(dp, 0, SEEK_CUR)); + fprintf(stderr, "#\t%qd\t%d\t%d\t%d\t%qd\t%qd\n", + (quad_t)dp->size, dp->days, dp->rate, + dp->errors, dp->interval, dp->next); + } + } fclose(fp); } @@ -577,8 +637,8 @@ dp->fd = -1; dp->rate = -1; dp->size = -1; - dp->interval = -1; - dp->next = 0; + dp->interval = -1LL; + dp->next = 0LL; break; case 1: /* size */ @@ -688,7 +748,7 @@ disks[numdisks].size = dp->size; disks[numdisks].days = dp->days; disks[numdisks].interval = dp->interval; - disks[numdisks].next = 0; + disks[numdisks].next = 0LL; disks[numdisks].device = *np; numdisks++; } @@ -727,13 +787,20 @@ if (dp->size < 0) getdisksize(dp); if (dp->rate < 0) - dp->rate = dp->size / (dp->days * 86400); + dp->rate = (dp->size + dp->days * 43200) + / (dp->days * 86400); + /* * 1000000 => convert seconds to usec */ if (dp->rate == 0) /* paranoia, should never really happen */ - dp->interval = READ_SIZE; + dp->interval = (long long)READ_SIZE * 1000000; else - dp->interval = READ_SIZE / dp->rate; + dp->interval = ((long long)READ_SIZE * 1000000) + / dp->rate; + + if (debug > 1) + fprintf(stderr, "%s: rate %d intvl %qd next %qd\n", + dp->device, dp->rate, dp->interval, dp->next); } if (numdisks == 0) { @@ -873,8 +940,7 @@ void sigterm(int sig) { - sig = sig; - got_sigterm = 1; + got_sigterm = sig; } void --=_4e55153e.L1trZsjhfo2jeiv2tq66KJ/nqbPar7gh7CvMeIrYte3j0fod-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 09:02:17 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF09106564A for ; Wed, 24 Aug 2011 09:02:17 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 30D2A8FC13 for ; Wed, 24 Aug 2011 09:02:16 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.4/8.14.4) with ESMTP id p7O926Eq019003 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 12:02:13 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4E54BE0D.5000608@digsys.bg> Date: Wed, 24 Aug 2011 12:02:05 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110822 Thunderbird/6.0 MIME-Version: 1.0 To: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: CARP up at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 09:02:17 -0000 I am trying to use a CARP/HAST setup for redundancy and reply on devd for the carp up/down events to trigger role switch for the nodes. What is interesting is that upon reboot, the CARP interface always first comes up, like this: carp0: link state changed to UP carp0: MASTER -> BACKUP (more frequent advertisement received) carp0: link state changed to DOWN This causes devd to execute the event scripts as 'master' first, then shortly after execute the script as 'backup'. This may cause undesired writing to the hast providers and possibly split-brain condition. What is worse, on two hosts with the same advskew value if you reboot the BACKUP server, it would become MASTER. This results in all services teardown and starting them again on the new master. I understand that for routers, which is the original design goal for CARP it does not matter much if roles switch from time to time, but for high-latency startup systems, this is not desirable. It is best when a node becomes MASTER it stays MASTER until failure and not change state when the other node is rebooted. Perhaps CARP and devd are not the best tool, but it will help if at least the carp interface does not start as MASTER and if it waits longer, before requesting to become MASTER after reboot. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 11:07:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AD441065670 for ; Wed, 24 Aug 2011 11:07:49 +0000 (UTC) (envelope-from tonymaher@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id B48DB8FC13 for ; Wed, 24 Aug 2011 11:07:48 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7O91vRA031794 for ; Wed, 24 Aug 2011 19:01:57 +1000 Received: from zen.home (c211-30-203-136.thorn2.nsw.optusnet.com.au [211.30.203.136]) (authenticated sender tonymaher) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7O91sqx013751 for ; Wed, 24 Aug 2011 19:01:54 +1000 Message-ID: <4E54BE01.6030408@optusnet.com.au> Date: Wed, 24 Aug 2011 19:01:53 +1000 From: Tony Maher User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110711 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: xterm - truetype fonts and missing underscore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 11:07:49 -0000 Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers -- Tony Maher email: tonymaher@optusnet.com.au From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 11:14:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83EF0106564A for ; Wed, 24 Aug 2011 11:14:51 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by mx1.freebsd.org (Postfix) with ESMTP id 1DE238FC17 for ; Wed, 24 Aug 2011 11:14:50 +0000 (UTC) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id CA6DF21F48; Wed, 24 Aug 2011 12:14:49 +0100 (BST) Received: from argon.wood2.org.uk (HELO argon.wood2.org.uk) (82.71.104.124) (smtp-auth username wood, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Wed, 24 Aug 2011 12:14:49 +0100 Message-ID: Date: Wed, 24 Aug 2011 12:13:08 +0100 To: Greg Byshenk From: David Wood References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <20110822094756.GJ92605@core.byshenk.net> <20110824070826.GK92605@core.byshenk.net> In-Reply-To: <20110824070826.GK92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+nnRuLdy5oZJowOHjWWZxwfxn9>) X-Gradwell-MongoId: 4e54dd29.10079-390d-1 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: wood Cc: freebsd-stable@freebsd.org Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 11:14:51 -0000 Hi Greg, In message <20110824070826.GK92605@core.byshenk.net>, Greg Byshenk writes >On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > >> In message <20110822094756.GJ92605@core.byshenk.net>, Greg Byshenk >> writes >> >It doesn't seem to matter; both cuau?.lock and cuau?.init produce the >> >error (for both ports), and cuau? itself remains a no-op. >> >> You could try >> hint.uart.2.baud="115200" >> >> in /boot/device.hints - making the relevant changes to port number and >> speed according to your needs. > >This does not help; speed remains set to 9600. It was worth a go. >> >Now that I can see that the card is working (at least minimally), it >> >begins to look as if there might be a problem somewhere in 9.x. I'll >> >try to install 8.x and see if the results are different. >> >> It will be interesting to see if there is a difference between 8.x and >> 9.x. > >Yes, there is. > >Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, >the controller works as expected. It defaults to 9600, but setting >the speed on the cuaa?.lock and cuaa?.init devices works. > >Interestingly, setting the speed in device.hints does _not_ work. It could be that setting speed in /boot/device.hints only works with ports directly handled by uart(4), not ports that uart(4) handles via puc(4). As 8-STABLE works, the support code I wrote and contributed works for your card, which is encouraging. >So, it appears that there is something wrong (or at least different) >with 9.x The best course of action is likely to be bringing up this problem on freebsd-current (as 9.x is not yet -stable) and filing a PR, noting the regression between 8-STABLE and 9-BETA. I'm fairly sure that the problem is likely to be in uart(4) or in something on which uart(4) rests, such as the tty layer. Even in 9-BETA puc(4) appears to be doing its job of identifying and configuring the ports before invoking uart(4) - so puc(4) doesn't appear to be to blame. >Doing some poking around, I see that, in 9.x, termios.h is not >included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While >it is included under 8.x. The commit logs for HEAD show that the inclusion of termios headers was removed as unnecessary (see r199872). I doubt that the problem is merely a missing header, not least as missing headers normally result in compilation failure. The "isn't a terminal" error you are getting indicates that the attempt to call tcgetaddr(3) on a file descriptor opened on the device is failing. Unfortunately, I am not familiar enough with the tty code to understand why that call is failing on 9.x. If posting on freebsd-current and filing a PR don't produce an answer, ed@ or kib@ may be able to throw some light. Those two committers are responsible for most of the relevant code, especially the tty layer. It may also be interesting to try 9.x on a machine with a serial port that operates directly with uart(4). Does stty(4) throw up "isn't a terminal" errors against the .init and .lock devices relating to those ports? I would try this myself, but am very short of time at present. Though there is probably little more that I can add, please keep me cc'd on all relevant e-mails, especially as I do not follow freebsd-current. With best wishes, David -- David Wood david@wood2.org.uk From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 12:00:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15C6106564A for ; Wed, 24 Aug 2011 12:00:00 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 91D698FC08 for ; Wed, 24 Aug 2011 12:00:00 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id QBwM1h0031swQuc59C008a; Wed, 24 Aug 2011 12:00:00 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id QBzy1h00W1t3BNj3bBzyTh; Wed, 24 Aug 2011 12:00:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D63BB102C36; Wed, 24 Aug 2011 04:59:56 -0700 (PDT) Date: Wed, 24 Aug 2011 04:59:56 -0700 From: Jeremy Chadwick To: David Wood Message-ID: <20110824115956.GA35240@icarus.home.lan> References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <20110822094756.GJ92605@core.byshenk.net> <20110824070826.GK92605@core.byshenk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcel@xcllnt.net, freebsd-stable@freebsd.org, Greg Byshenk Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:00:01 -0000 On Wed, Aug 24, 2011 at 12:13:08PM +0100, David Wood wrote: > Hi Greg, > > In message <20110824070826.GK92605@core.byshenk.net>, Greg Byshenk > writes > >On Mon, Aug 22, 2011 at 11:59:11AM +0100, David Wood wrote: > > > >>In message <20110822094756.GJ92605@core.byshenk.net>, Greg Byshenk > >> writes > >>>It doesn't seem to matter; both cuau?.lock and cuau?.init produce the > >>>error (for both ports), and cuau? itself remains a no-op. > >> > >>You could try > >>hint.uart.2.baud="115200" > >> > >>in /boot/device.hints - making the relevant changes to port number and > >>speed according to your needs. > > > >This does not help; speed remains set to 9600. > > It was worth a go. > > > >>>Now that I can see that the card is working (at least minimally), it > >>>begins to look as if there might be a problem somewhere in 9.x. I'll > >>>try to install 8.x and see if the results are different. > >> > >>It will be interesting to see if there is a difference between 8.x and > >>9.x. > > > >Yes, there is. > > > >Using 8-STABLE (with sources from 17 August 2011) and inbuilt puc, > >the controller works as expected. It defaults to 9600, but setting > >the speed on the cuaa?.lock and cuaa?.init devices works. > > > >Interestingly, setting the speed in device.hints does _not_ work. > > It could be that setting speed in /boot/device.hints only works with > ports directly handled by uart(4), not ports that uart(4) handles > via puc(4). > > As 8-STABLE works, the support code I wrote and contributed works > for your card, which is encouraging. > > > >So, it appears that there is something wrong (or at least different) > >with 9.x > > The best course of action is likely to be bringing up this problem > on freebsd-current (as 9.x is not yet -stable) and filing a PR, > noting the regression between 8-STABLE and 9-BETA. > > I'm fairly sure that the problem is likely to be in uart(4) or in > something on which uart(4) rests, such as the tty layer. Even in > 9-BETA puc(4) appears to be doing its job of identifying and > configuring the ports before invoking uart(4) - so puc(4) doesn't > appear to be to blame. > > > >Doing some poking around, I see that, in 9.x, termios.h is not > >included in dev/uart/uart_core.c and dev/uart/uart_tty.c. While > >it is included under 8.x. > > The commit logs for HEAD show that the inclusion of termios headers > was removed as unnecessary (see r199872). I doubt that the problem > is merely a missing header, not least as missing headers normally > result in compilation failure. > > The "isn't a terminal" error you are getting indicates that the > attempt to call tcgetaddr(3) on a file descriptor opened on the > device is failing. Unfortunately, I am not familiar enough with the > tty code to understand why that call is failing on 9.x. > > > If posting on freebsd-current and filing a PR don't produce an > answer, ed@ or kib@ may be able to throw some light. Those two > committers are responsible for most of the relevant code, especially > the tty layer. > > It may also be interesting to try 9.x on a machine with a serial > port that operates directly with uart(4). Does stty(4) throw up > "isn't a terminal" errors against the .init and .lock devices > relating to those ports? I would try this myself, but am very short > of time at present. > > > Though there is probably little more that I can add, please keep me > cc'd on all relevant e-mails, especially as I do not follow > freebsd-current. I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help assist in this matter and shed some light on the above comments. If there's a quirk or bug there, I'm certain he'll assist in helping. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 12:44:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C657B1065672 for ; Wed, 24 Aug 2011 12:44:44 +0000 (UTC) (envelope-from benzene@arcor.de) Received: from fh-dortmund.de (fhdo-2.dvz.fh-dortmund.de [193.25.16.6]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAD48FC1B for ; Wed, 24 Aug 2011 12:44:44 +0000 (UTC) Received: from gatekeeper.informatik.fh-dortmund.de (gatekeeper.informatik.FH-Dortmund.DE [193.25.22.84]) by fh-dortmund.de (Switch-3.3.0/Switch-3.3.0) with ESMTP id p7OC8jw5004149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 14:08:54 +0200 (MEST) Received: from custos.hw1.fb4.fh (n43.informatik.FH-Dortmund.DE [193.25.22.43]) by gatekeeper.informatik.fh-dortmund.de (8.12.10/8.12.10) with ESMTP id p7OBBB5x029895 for ; Wed, 24 Aug 2011 13:11:46 +0200 From: Michael Hoffmann To: freebsd-stable@freebsd.org Date: Wed, 24 Aug 2011 13:11:11 +0200 User-Agent: KMail/1.9.10 References: <201103092015.p29KFd0U077849@dave.dignus.com> <1314084403216-4725801.post@n5.nabble.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201108241311.11319.benzene@arcor.de> Subject: Re: -m32 on freeBSD 8.2r amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:44:44 -0000 Maybe off topic? 1: echo "int main(void) { return 0; }" > t.c 2: setenv LDEMULATION elf_i386_fbsd 3: gcc -c -m32 -o t.o t.c 4: gcc -nostartfiles -o a.out t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o 5: file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped 6: uname -m amd64 2: q.v. info binutils -> Selecting The Target System Maybe there is a more comfortable way. Michael Am Tuesday 23 August 2011 09:46:11 schrieb Edho Arief: > On Tue, Aug 23, 2011 at 2:26 PM, noel beck wrote: > > We are trying to compile i386 on a FreeBSD 8.2r amd64. > > we are getting an error stating that libstdc++.so.6, is missing. > > COMPACT6x and COMPACT7x have been installed. But this does not solve the > > problem. > > Is it possible to compile i386 on and amd64 system? > > I believe compiler flags to /lib32 is required (-L/usr/lib32 or something) > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 12:57:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 213AB106564A for ; Wed, 24 Aug 2011 12:57:04 +0000 (UTC) (envelope-from tevans.uk@googlemail.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 D6A0D8FC17 for ; Wed, 24 Aug 2011 12:57:03 +0000 (UTC) Received: by vxh11 with SMTP id 11so1267770vxh.13 for ; Wed, 24 Aug 2011 05:57: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=pang7Ty7wHVpqVS4bw7SMj2d24y1UDDttOrStiS1PO4=; b=utvew5/+n/YkZ8UwljfeI1CFTTC6qrYMgMQDQyNyN1MvauP9MBfcOXofYt5gaY9Syk miNck4+brWiaxEHLJYEEEy5M+llneN0NUMODviGKNgBsJNRhBIqUe0vkZBbP8uVQmJBc T4H/abUga85av7MIhkqKDx6Ig2wfg/7lhAGsk= MIME-Version: 1.0 Received: by 10.52.92.102 with SMTP id cl6mr2424027vdb.11.1314190622942; Wed, 24 Aug 2011 05:57:02 -0700 (PDT) Received: by 10.52.162.73 with HTTP; Wed, 24 Aug 2011 05:57:02 -0700 (PDT) In-Reply-To: <201108241311.11319.benzene@arcor.de> References: <201103092015.p29KFd0U077849@dave.dignus.com> <1314084403216-4725801.post@n5.nabble.com> <201108241311.11319.benzene@arcor.de> Date: Wed, 24 Aug 2011 13:57:02 +0100 Message-ID: From: Tom Evans To: Michael Hoffmann Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: -m32 on freeBSD 8.2r amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:57:04 -0000 On Wed, Aug 24, 2011 at 12:11 PM, Michael Hoffmann wrote: > Maybe off topic? > > 1: echo "int main(void) { return 0; }" > t.c > > 2: setenv LDEMULATION elf_i386_fbsd > > 3: gcc -c -m32 -o t.o t.c > > 4: gcc -nostartfiles -o a.out > t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o > > 5: file a.out > a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped > > 6: uname -m > amd64 > > 2: q.v. info binutils -> Selecting The Target System > > Maybe there is a more comfortable way. > Michael > You don't need to go to all that effort: $ uname -m amd64 $ echo "int main(void) { return 0; }" > t.c $ gcc -c -m32 -o t.o t.c $ gcc -m32 -o t t.o -B/usr/lib32 $ file t t: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2 (802510), not stripped Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 13:01:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91BC31065673 for ; Wed, 24 Aug 2011 13:01:50 +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 0D1B98FC14 for ; Wed, 24 Aug 2011 13:01:49 +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 p7OD1gaj048817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 16:01:42 +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 p7OD1gJx065214; Wed, 24 Aug 2011 16:01:42 +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 p7OD1g4w065213; Wed, 24 Aug 2011 16:01:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 16:01:42 +0300 From: Kostik Belousov To: Tom Evans Message-ID: <20110824130142.GO17489@deviant.kiev.zoral.com.ua> References: <201103092015.p29KFd0U077849@dave.dignus.com> <1314084403216-4725801.post@n5.nabble.com> <201108241311.11319.benzene@arcor.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gzCQSLRtB/T+Q+ea" Content-Disposition: inline In-Reply-To: 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-stable@freebsd.org, Michael Hoffmann Subject: Re: -m32 on freeBSD 8.2r amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 13:01:50 -0000 --gzCQSLRtB/T+Q+ea Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 01:57:02PM +0100, Tom Evans wrote: > On Wed, Aug 24, 2011 at 12:11 PM, Michael Hoffmann wro= te: > > Maybe off topic? > > > > 1: echo "int main(void) { return 0; }" > t.c > > > > 2: setenv LDEMULATION elf_i386_fbsd > > > > 3: gcc -c -m32 -o t.o t.c > > > > 4: gcc -nostartfiles -o a.out > > t.o -L/usr/lib32 /usr/lib32/crt1.o /usr/lib32/crti.o > > > > 5: file a.out > > a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > > dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped > > > > 6: uname -m > > amd64 > > > > 2: q.v. info binutils -> Selecting The Target System > > > > Maybe there is a more comfortable way. > > Michael > > >=20 > You don't need to go to all that effort: >=20 > $ uname -m > amd64 > $ echo "int main(void) { return 0; }" > t.c > $ gcc -c -m32 -o t.o t.c > $ gcc -m32 -o t t.o -B/usr/lib32 > $ file t > t: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), for FreeBSD 8.2 (802510), not > stripped Well-known problem is that /usr/include/machine/*.h still contains amd64 arch definitions. The resulting binary is broken in the quite subtle ways. --gzCQSLRtB/T+Q+ea Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5U9jYACgkQC3+MBN1Mb4gbJQCdEAEVzNoppt0KkUWbXWXb+aok VicAn3vDgk2hP3gnyz+VvpQ1ztjG2rC2 =NZYe -----END PGP SIGNATURE----- --gzCQSLRtB/T+Q+ea-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 15:56:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA97D106564A for ; Wed, 24 Aug 2011 15:56:36 +0000 (UTC) (envelope-from c.kworr@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 6E3708FC08 for ; Wed, 24 Aug 2011 15:56:36 +0000 (UTC) Received: by fxe4 with SMTP id 4so1414048fxe.13 for ; Wed, 24 Aug 2011 08:56:35 -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=jDFz41utC4uHi4yDtmi4SWbe5rFr1KYEZBX6xXcSS6M=; b=N7unZEBYNOiDYmkKa2YkN45tn+7lCICtpxlqggc4ZdLIyxsfWFMpc4YT7nDubEmyb/ yU+PIge+xzxJExQgWoz6ikntl18w/TSKKv/wrCacBzZEa+liky9dAlBiHnCXr0+1KzBw BGmPOPq4Xw2d8QOI0Qbxv2IUEivlf/XiDPWTg= Received: by 10.223.89.2 with SMTP id c2mr7485219fam.50.1314199666930; Wed, 24 Aug 2011 08:27:46 -0700 (PDT) Received: from limbo.lan ([195.225.157.86]) by mx.google.com with ESMTPS id p11sm918972faa.22.2011.08.24.08.27.42 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 08:27:44 -0700 (PDT) Message-ID: <4E551869.9090709@gmail.com> Date: Wed, 24 Aug 2011 18:27:37 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:6.0) Gecko/20110822 Thunderbird/6.0 MIME-Version: 1.0 To: Tony Maher References: <4E54BE01.6030408@optusnet.com.au> In-Reply-To: <4E54BE01.6030408@optusnet.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: xterm - truetype fonts and missing underscore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 15:56:36 -0000 24.08.2011 12:01, Tony Maher wrote: > Hello, > > recently (not sure exactly when) my xterms no longer showed the > underscore character. > In my .Xresources I had (and have had this setting for years): > > XTerm*faceName: Monospace > XTerm*faceSize: 10 > > I noticed when experimenting and modifying values that for one choice > the bottom part of letters like 'g' was missing. > So changed faceSize to 11 and all is good. > > In gnome-terminal with Monospace/10 font underscores showed up fine > (and was ok in gnome font selector). So it appears to be xterm specific. > > Has anyone else experienced this? +1 from me http://lists.nongnu.org/archive/html/freetype/2011-08/msg00020.html -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 16:13:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9850A106564A for ; Wed, 24 Aug 2011 16:13:42 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 59D378FC16 for ; Wed, 24 Aug 2011 16:13:41 +0000 (UTC) Received: by ywo32 with SMTP id 32so1150144ywo.13 for ; Wed, 24 Aug 2011 09:13:41 -0700 (PDT) Received: by 10.52.67.4 with SMTP id j4mr4946875vdt.333.1314200643706; Wed, 24 Aug 2011 08:44:03 -0700 (PDT) Received: from www.palm.com (253.sub-97-15-38.myvzw.com [97.15.38.253]) by mx.google.com with ESMTPS id em6sm787918vdb.10.2011.08.24.08.43.59 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 08:44:01 -0700 (PDT) Message-ID: <4e551c41.0663340a.0d3b.3005@mx.google.com> Date: Wed, 24 Aug 2011 11:43:56 -0400 From: "Mark Saad" To: "Tony Maher" , "freebsd-stable@freebsd.org" In-Reply-To: <4E54BE01.6030408@optusnet.com.au> X-Mailer: Palm webOS v1.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: xterm - truetype fonts and missing underscore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mark Saad List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 16:13:42 -0000 Tony   What else is in you .Xresources file . Also have you tried usin= g xft formated font names . Ie xft:luxi mono:size=3D10 ? -- Mark Saad Mark.saad@longcount.orgOn Aug 24, 2011 7:08 AM, Tony Maher <tonymaher@op= tusnet.com.au> wrote:=20 Hello, recently (not sure exactly when) my xterms no longer showed the underscore= character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers --=20 Tony Maher email: tonymaher@optusnet.com.au _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 17:31:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2D7106566B for ; Wed, 24 Aug 2011 17:31:16 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 73E6F8FC14 for ; Wed, 24 Aug 2011 17:31:16 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id DF768EA9E; Wed, 24 Aug 2011 10:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1314207076; bh=iPaqkrOhIzej3043EZU0jdEFoLMP8ww98KMbJxA4pfg=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gNM99oHPedCWkemjyiRl1CDWLQrTwDy3czMRIpbndjUHzt2g58b7cm0e/VmYQ7m8g bq/ay8DCkqEP4INw2Src1bj5AbwBCF2JAisfY4FIcL707FCf0rOfrMEAHqK000VXTI 7EKzCHWzF4U7VZSssrYKOwxFNOFaC5xYdIbwlsJQ= Message-ID: <4E553562.90907@delphij.net> Date: Wed, 24 Aug 2011 10:31:14 -0700 From: Xin LI Organization: The FreeBSD Project MIME-Version: 1.0 To: Daniel Kalchev References: <4E54BE0D.5000608@digsys.bg> In-Reply-To: <4E54BE0D.5000608@digsys.bg> OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: CARP up at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:31:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/24/11 02:02, Daniel Kalchev wrote: > I am trying to use a CARP/HAST setup for redundancy and reply on > devd for the carp up/down events to trigger role switch for the > nodes. Is this something at least at, or newer than 8.2-RELEASE? I think it's actually important for the devd script to make sure (wait, then check) that the state is stabilized before doing any action for use with HAST by the way. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOVTViAAoJEATO+BI/yjfB4ekIANBDTmvCgh+I60ZSXmf0ut+/ OPcZfgKwGrp66QQQdp9t6uePRnmYDYcqsjvGj2FeihB33sKgIMz+Jrw2cgoTlPDs VClE8kDkrxt3CH6B99SOnEY4oNI7Hepq+83PkQ5JDAqnqYCUq1ciWVbRLk8xXGZP tnlo6fGRc9grZWbSFPE+zbqPw74q3yQ1H9kjU87pu61xR5Bmt+5CIRy9yRHXTmrg O8fOIAlRoyqsTJhsV4acffD67llXlHeTv1wKFnvuuZ84ZIqMNmbuurlMYXBSrfxv QmwJcSkLTFOqFUzQ7ZJTZi8R6+vIYaAAIrNRCW8hxoL6lrebs09SJ5VZIt5h6go= =JqLT -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 18:29:07 2011 Return-Path: Delivered-To: stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D01D1065673; Wed, 24 Aug 2011 18:29:07 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 00E228FC1F; Wed, 24 Aug 2011 18:29:06 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.4/8.14.2) with ESMTP id p7OHo31Q058670; Wed, 24 Aug 2011 13:50:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.4/8.14.2/Submit) id p7OHo34r058669; Wed, 24 Aug 2011 13:50:03 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 24 Aug 2011 13:50:03 -0400 From: David Schultz To: "Dr. A. Haakh" Message-ID: <20110824175003.GA58601@zim.MIT.EDU> Mail-Followup-To: "Dr. A. Haakh" , Oliver Pinter , freebsd-bugs@freebsd.org, stable@freebsd.org References: <4E1C5107.2030500@Haakh.de> <4E1D41FB.2080202@Haakh.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E1D41FB.2080202@Haakh.de> Cc: freebsd-bugs@FreeBSD.ORG, stable@FreeBSD.ORG, Oliver Pinter Subject: Re: stable/7/lib/msun/src/e_log2.c missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:29:07 -0000 On Wed, Jul 13, 2011, Dr. A. Haakh wrote: > Oliver Pinter schrieb: > >On 7/12/11, Dr. A. Haakh wrote: > > > >>log2() log2f have been MFCd to 8-STABLE (r216210 and r216210) but are > >>still missing in 7-STABLE. > >> > >>See > >>http://www.freebsd.org/cgi/getmsg.cgi?fetch=24955+47747+/usr/local/www/db/text/2011/freebsd-ports/20110612.freebsd-ports > >> > >>This breaks several ports. Any plans? [...] > would be nice if it could be done. Given that 9.0-RELEASE is imminent and no further 7.X releases are expected, I wasn't planning on MFCing new functionality to 7-STABLE. But if it makes life easier for porters, I can look into it. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 18:34:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD2DA106566C for ; Wed, 24 Aug 2011 18:34:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC688FC18 for ; Wed, 24 Aug 2011 18:34:13 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwI2d-000IqY-TS for freebsd-stable@freebsd.org; Wed, 24 Aug 2011 22:19:07 +0400 Date: Wed, 24 Aug 2011 22:19:07 +0400 From: Slawa Olhovchenkov To: freebsd-stable@freebsd.org Message-ID: <20110824181907.GA48394@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Subject: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 18:34:13 -0000 System is 8.2-RELEASE (GENERIC), amd64. Application -- i386 for freebsd7. In ktrace dump I find some strange result: 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) 22951 100556 kas-milter RET sigwait 4 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 RET sigwait 4 confused me, and, I think, confused application too. man sigwait: ERRORS The sigwait() system call will fail if: [EINVAL] The set argument specifies one or more invalid signal numbers. [EFAULT] Any arguments point outside the allocated address space or there is a memory protection fault. How sigwait can return '4'? May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must be called with timeout == NULL... From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:07:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5001106566B for ; Wed, 24 Aug 2011 19:07:07 +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 6481A8FC0A for ; Wed, 24 Aug 2011 19:07:06 +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 p7OJ73WO072245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 22:07:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p7OJ73wN078683; Wed, 24 Aug 2011 22:07:03 +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 p7OJ73l3078682; Wed, 24 Aug 2011 22:07:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 22:07:03 +0300 From: Kostik Belousov To: Slawa Olhovchenkov Message-ID: <20110824190703.GY17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8hWk1bP476InP7gd" Content-Disposition: inline In-Reply-To: <20110824181907.GA48394@zxy.spb.ru> 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-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:07:07 -0000 --8hWk1bP476InP7gd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: > System is 8.2-RELEASE (GENERIC), amd64. > Application -- i386 for freebsd7. >=20 > In ktrace dump I find some strange result: >=20 > 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) > 22951 100556 kas-milter RET sigwait 4 > 22951 100556 kas-milter PSIG SIGUSR2 caught handler=3D0x804c0f0 mask=3D= 0x4003 code=3D0x0 >=20 > RET sigwait 4 confused me, and, I think, confused application too. >=20 > man sigwait: >=20 > ERRORS > The sigwait() system call will fail if: >=20 > [EINVAL] The set argument specifies one or more invalid si= gnal > numbers. >=20 > [EFAULT] Any arguments point outside the allocated address > space or there is a memory protection fault. >=20 >=20 > How sigwait can return '4'? > May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait= must=20 > be called with timeout =3D=3D NULL... >=20 What should the system do for a delivered signal not present in the set ? I guess this is the case of your ktrace. Looking at the SUSv4, I see no mention of the situation, but in Oracle SunOS 5.10 man page for sigwait(2), it is said explicitely EINTR The wait was interrupted by an unblocked, caught signal. So I think that we have a bug in the man page. diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..b462201 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -94,6 +94,8 @@ The .Fn sigwait system call will fail if: .Bl -tag -width Er +.It Bq Er EINTR +The system call was interrupted by an unblocked, caught signal. .It Bq Er EINVAL The .Fa set --8hWk1bP476InP7gd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5VS9YACgkQC3+MBN1Mb4jiVACgr3FuAcrc2hblZhSSOh+uRgLB TysAoMcyZCl0Q1QZfFu5iPKnMMKUD01a =3+IN -----END PGP SIGNATURE----- --8hWk1bP476InP7gd-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:24:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26136106566B for ; Wed, 24 Aug 2011 19:24:36 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 876E08FC13 for ; Wed, 24 Aug 2011 19:24:35 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwJ4A-000JKR-7r; Wed, 24 Aug 2011 23:24:46 +0400 Date: Wed, 24 Aug 2011 23:24:46 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824192446.GB48394@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824190703.GY17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:24:36 -0000 On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: > > System is 8.2-RELEASE (GENERIC), amd64. > > Application -- i386 for freebsd7. > > > > In ktrace dump I find some strange result: > > > > 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) > > 22951 100556 kas-milter RET sigwait 4 > > 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 > > > > RET sigwait 4 confused me, and, I think, confused application too. > > > > man sigwait: > > > > ERRORS > > The sigwait() system call will fail if: > > > > [EINVAL] The set argument specifies one or more invalid signal > > numbers. > > > > [EFAULT] Any arguments point outside the allocated address > > space or there is a memory protection fault. > > > > > > How sigwait can return '4'? > > May be EINTR, converted from ERESTART? But kern_sigtimedwait from sigwait must > > be called with timeout == NULL... > > > > What should the system do for a delivered signal not present in the set ? > I guess this is the case of your ktrace. > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > SunOS 5.10 man page for sigwait(2), it is said explicitely > EINTR The wait was interrupted by an unblocked, caught signal. I don't think you right in this case. This is kas-milter and in this thread (this is multi-thread application) kas-milter wait for USR2 for reload config. System return from sigwait only on USR2, but not each return w/ non-zero return code. On freebsd7 this application don't complain about sigwait's return value. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:32:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1062B106566C for ; Wed, 24 Aug 2011 19:32:06 +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 A25CC8FC1D for ; Wed, 24 Aug 2011 19:32:05 +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 p7OJW29u074072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 22:32:02 +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 p7OJW2BU079604; Wed, 24 Aug 2011 22:32:02 +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 p7OJW21o079603; Wed, 24 Aug 2011 22:32:02 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 22:32:02 +0300 From: Kostik Belousov To: Slawa Olhovchenkov Message-ID: <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HObwSN71pq3vUoaj" Content-Disposition: inline In-Reply-To: <20110824192446.GB48394@zxy.spb.ru> 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-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:32:06 -0000 --HObwSN71pq3vUoaj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 11:24:46PM +0400, Slawa Olhovchenkov wrote: > On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: >=20 > > On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: > > > System is 8.2-RELEASE (GENERIC), amd64. > > > Application -- i386 for freebsd7. > > >=20 > > > In ktrace dump I find some strange result: > > >=20 > > > 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) > > > 22951 100556 kas-milter RET sigwait 4 > > > 22951 100556 kas-milter PSIG SIGUSR2 caught handler=3D0x804c0f0 mas= k=3D0x4003 code=3D0x0 > > >=20 > > > RET sigwait 4 confused me, and, I think, confused application too. > > >=20 > > > man sigwait: > > >=20 > > > ERRORS > > > The sigwait() system call will fail if: > > >=20 > > > [EINVAL] The set argument specifies one or more invali= d signal > > > numbers. > > >=20 > > > [EFAULT] Any arguments point outside the allocated add= ress > > > space or there is a memory protection fault. > > >=20 > > >=20 > > > How sigwait can return '4'? > > > May be EINTR, converted from ERESTART? But kern_sigtimedwait from sig= wait must=20 > > > be called with timeout =3D=3D NULL... > > >=20 > >=20 > > What should the system do for a delivered signal not present in the set= ? > > I guess this is the case of your ktrace. > >=20 > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > EINTR The wait was interrupted by an unblocked, caught signal. >=20 > I don't think you right in this case. > This is kas-milter and in this thread (this is multi-thread > application) kas-milter wait for USR2 for reload config. >=20 > System return from sigwait only on USR2, but not each return w/ > non-zero return code. >=20 > On freebsd7 this application don't complain about sigwait's return value. Could it be that some other thread has the signal unblocked ? (You can verify this with procstat -j). Can you write the self-contained test case that demonstrates the behaviour ? --HObwSN71pq3vUoaj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5VUbIACgkQC3+MBN1Mb4ji3ACfUNBxLk0D8CypSdqePKjYZd/O PKIAoK+vnfxFTMMG+iBPjeOGz2GdGNq1 =IHXv -----END PGP SIGNATURE----- --HObwSN71pq3vUoaj-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:42:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A92A21065674 for ; Wed, 24 Aug 2011 19:42:21 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id B67968FC1E for ; Wed, 24 Aug 2011 19:42:20 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwJLJ-000JT3-V2; Wed, 24 Aug 2011 23:42:29 +0400 Date: Wed, 24 Aug 2011 23:42:29 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824194229.GC48394@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:42:21 -0000 On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: > > > What should the system do for a delivered signal not present in the set ? > > > I guess this is the case of your ktrace. > > > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > EINTR The wait was interrupted by an unblocked, caught signal. > > > > I don't think you right in this case. > > This is kas-milter and in this thread (this is multi-thread > > application) kas-milter wait for USR2 for reload config. > > > > System return from sigwait only on USR2, but not each return w/ > > non-zero return code. > > > > On freebsd7 this application don't complain about sigwait's return value. > > Could it be that some other thread has the signal unblocked ? > (You can verify this with procstat -j). > > Can you write the self-contained test case that demonstrates the behaviour ? This is closed-source software. # procstat -j PID TID COMM SIG FLAGS 1395 100199 kas-milter HUP -B 1395 100199 kas-milter INT -B 1395 100199 kas-milter QUIT -- 1395 100199 kas-milter ILL -- 1395 100199 kas-milter TRAP -- 1395 100199 kas-milter ABRT -- 1395 100199 kas-milter EMT -- 1395 100199 kas-milter FPE -- 1395 100199 kas-milter KILL -- 1395 100199 kas-milter BUS -- 1395 100199 kas-milter SEGV -- 1395 100199 kas-milter SYS -- 1395 100199 kas-milter PIPE -- 1395 100199 kas-milter ALRM -- 1395 100199 kas-milter TERM -B 1395 100199 kas-milter URG -- 1395 100199 kas-milter STOP -- 1395 100199 kas-milter TSTP -- 1395 100199 kas-milter CONT -- 1395 100199 kas-milter CHLD -- 1395 100199 kas-milter TTIN -- 1395 100199 kas-milter TTOU -- 1395 100199 kas-milter IO -- 1395 100199 kas-milter XCPU -- 1395 100199 kas-milter XFSZ -- 1395 100199 kas-milter VTALRM -- 1395 100199 kas-milter PROF -- 1395 100199 kas-milter WINCH -- 1395 100199 kas-milter INFO -- 1395 100199 kas-milter USR1 -- 1395 100199 kas-milter USR2 -- 1395 100199 kas-milter 32 -- 1395 100199 kas-milter 33 -- 1395 100199 kas-milter 34 -- 1395 100199 kas-milter 35 -- 1395 100199 kas-milter 36 -- 1395 100199 kas-milter 37 -- 1395 100199 kas-milter 38 -- 1395 100199 kas-milter 39 -- 1395 100199 kas-milter 40 -- 1395 100199 kas-milter 41 -- 1395 100199 kas-milter 42 -- 1395 100199 kas-milter 43 -- 1395 100199 kas-milter 44 -- 1395 100199 kas-milter 45 -- 1395 100199 kas-milter 46 -- 1395 100199 kas-milter 47 -- 1395 100199 kas-milter 48 -- 1395 100199 kas-milter 49 -- 1395 100199 kas-milter 50 -- 1395 100199 kas-milter 51 -- 1395 100199 kas-milter 52 -- 1395 100199 kas-milter 53 -- 1395 100199 kas-milter 54 -- 1395 100199 kas-milter 55 -- 1395 100199 kas-milter 56 -- 1395 100199 kas-milter 57 -- 1395 100199 kas-milter 58 -- 1395 100199 kas-milter 59 -- 1395 100199 kas-milter 60 -- 1395 100199 kas-milter 61 -- 1395 100199 kas-milter 62 -- 1395 100199 kas-milter 63 -- 1395 100199 kas-milter 64 -- 1395 100199 kas-milter 65 -- 1395 100199 kas-milter 66 -- 1395 100199 kas-milter 67 -- 1395 100199 kas-milter 68 -- 1395 100199 kas-milter 69 -- 1395 100199 kas-milter 70 -- 1395 100199 kas-milter 71 -- 1395 100199 kas-milter 72 -- 1395 100199 kas-milter 73 -- 1395 100199 kas-milter 74 -- 1395 100199 kas-milter 75 -- 1395 100199 kas-milter 76 -- 1395 100199 kas-milter 77 -- 1395 100199 kas-milter 78 -- 1395 100199 kas-milter 79 -- 1395 100199 kas-milter 80 -- 1395 100199 kas-milter 81 -- 1395 100199 kas-milter 82 -- 1395 100199 kas-milter 83 -- 1395 100199 kas-milter 84 -- 1395 100199 kas-milter 85 -- 1395 100199 kas-milter 86 -- 1395 100199 kas-milter 87 -- 1395 100199 kas-milter 88 -- 1395 100199 kas-milter 89 -- 1395 100199 kas-milter 90 -- 1395 100199 kas-milter 91 -- 1395 100199 kas-milter 92 -- 1395 100199 kas-milter 93 -- 1395 100199 kas-milter 94 -- 1395 100199 kas-milter 95 -- 1395 100199 kas-milter 96 -- 1395 100199 kas-milter 97 -- 1395 100199 kas-milter 98 -- 1395 100199 kas-milter 99 -- 1395 100199 kas-milter 100 -- 1395 100199 kas-milter 101 -- 1395 100199 kas-milter 102 -- 1395 100199 kas-milter 103 -- 1395 100199 kas-milter 104 -- 1395 100199 kas-milter 105 -- 1395 100199 kas-milter 106 -- 1395 100199 kas-milter 107 -- 1395 100199 kas-milter 108 -- 1395 100199 kas-milter 109 -- 1395 100199 kas-milter 110 -- 1395 100199 kas-milter 111 -- 1395 100199 kas-milter 112 -- 1395 100199 kas-milter 113 -- 1395 100199 kas-milter 114 -- 1395 100199 kas-milter 115 -- 1395 100199 kas-milter 116 -- 1395 100199 kas-milter 117 -- 1395 100199 kas-milter 118 -- 1395 100199 kas-milter 119 -- 1395 100199 kas-milter 120 -- 1395 100199 kas-milter 121 -- 1395 100199 kas-milter 122 -- 1395 100199 kas-milter 123 -- 1395 100199 kas-milter 124 -- 1395 100199 kas-milter 125 -- 1395 100199 kas-milter 126 -- 1395 100199 kas-milter 127 -- 1395 100199 kas-milter 128 -- 1395 100232 kas-milter HUP -- 1395 100232 kas-milter INT -- 1395 100232 kas-milter QUIT -- 1395 100232 kas-milter ILL -- 1395 100232 kas-milter TRAP -- 1395 100232 kas-milter ABRT -- 1395 100232 kas-milter EMT -- 1395 100232 kas-milter FPE -- 1395 100232 kas-milter KILL -- 1395 100232 kas-milter BUS -- 1395 100232 kas-milter SEGV -- 1395 100232 kas-milter SYS -- 1395 100232 kas-milter PIPE -- 1395 100232 kas-milter ALRM -- 1395 100232 kas-milter TERM -- 1395 100232 kas-milter URG -- 1395 100232 kas-milter STOP -- 1395 100232 kas-milter TSTP -- 1395 100232 kas-milter CONT -- 1395 100232 kas-milter CHLD -- 1395 100232 kas-milter TTIN -- 1395 100232 kas-milter TTOU -- 1395 100232 kas-milter IO -- 1395 100232 kas-milter XCPU -- 1395 100232 kas-milter XFSZ -- 1395 100232 kas-milter VTALRM -- 1395 100232 kas-milter PROF -- 1395 100232 kas-milter WINCH -- 1395 100232 kas-milter INFO -- 1395 100232 kas-milter USR1 -- 1395 100232 kas-milter USR2 -- 1395 100232 kas-milter 32 -- 1395 100232 kas-milter 33 -- 1395 100232 kas-milter 34 -- 1395 100232 kas-milter 35 -- 1395 100232 kas-milter 36 -- 1395 100232 kas-milter 37 -- 1395 100232 kas-milter 38 -- 1395 100232 kas-milter 39 -- 1395 100232 kas-milter 40 -- 1395 100232 kas-milter 41 -- 1395 100232 kas-milter 42 -- 1395 100232 kas-milter 43 -- 1395 100232 kas-milter 44 -- 1395 100232 kas-milter 45 -- 1395 100232 kas-milter 46 -- 1395 100232 kas-milter 47 -- 1395 100232 kas-milter 48 -- 1395 100232 kas-milter 49 -- 1395 100232 kas-milter 50 -- 1395 100232 kas-milter 51 -- 1395 100232 kas-milter 52 -- 1395 100232 kas-milter 53 -- 1395 100232 kas-milter 54 -- 1395 100232 kas-milter 55 -- 1395 100232 kas-milter 56 -- 1395 100232 kas-milter 57 -- 1395 100232 kas-milter 58 -- 1395 100232 kas-milter 59 -- 1395 100232 kas-milter 60 -- 1395 100232 kas-milter 61 -- 1395 100232 kas-milter 62 -- 1395 100232 kas-milter 63 -- 1395 100232 kas-milter 64 -- 1395 100232 kas-milter 65 -- 1395 100232 kas-milter 66 -- 1395 100232 kas-milter 67 -- 1395 100232 kas-milter 68 -- 1395 100232 kas-milter 69 -- 1395 100232 kas-milter 70 -- 1395 100232 kas-milter 71 -- 1395 100232 kas-milter 72 -- 1395 100232 kas-milter 73 -- 1395 100232 kas-milter 74 -- 1395 100232 kas-milter 75 -- 1395 100232 kas-milter 76 -- 1395 100232 kas-milter 77 -- 1395 100232 kas-milter 78 -- 1395 100232 kas-milter 79 -- 1395 100232 kas-milter 80 -- 1395 100232 kas-milter 81 -- 1395 100232 kas-milter 82 -- 1395 100232 kas-milter 83 -- 1395 100232 kas-milter 84 -- 1395 100232 kas-milter 85 -- 1395 100232 kas-milter 86 -- 1395 100232 kas-milter 87 -- 1395 100232 kas-milter 88 -- 1395 100232 kas-milter 89 -- 1395 100232 kas-milter 90 -- 1395 100232 kas-milter 91 -- 1395 100232 kas-milter 92 -- 1395 100232 kas-milter 93 -- 1395 100232 kas-milter 94 -- 1395 100232 kas-milter 95 -- 1395 100232 kas-milter 96 -- 1395 100232 kas-milter 97 -- 1395 100232 kas-milter 98 -- 1395 100232 kas-milter 99 -- 1395 100232 kas-milter 100 -- 1395 100232 kas-milter 101 -- 1395 100232 kas-milter 102 -- 1395 100232 kas-milter 103 -- 1395 100232 kas-milter 104 -- 1395 100232 kas-milter 105 -- 1395 100232 kas-milter 106 -- 1395 100232 kas-milter 107 -- 1395 100232 kas-milter 108 -- 1395 100232 kas-milter 109 -- 1395 100232 kas-milter 110 -- 1395 100232 kas-milter 111 -- 1395 100232 kas-milter 112 -- 1395 100232 kas-milter 113 -- 1395 100232 kas-milter 114 -- 1395 100232 kas-milter 115 -- 1395 100232 kas-milter 116 -- 1395 100232 kas-milter 117 -- 1395 100232 kas-milter 118 -- 1395 100232 kas-milter 119 -- 1395 100232 kas-milter 120 -- 1395 100232 kas-milter 121 -- 1395 100232 kas-milter 122 -- 1395 100232 kas-milter 123 -- 1395 100232 kas-milter 124 -- 1395 100232 kas-milter 125 -- 1395 100232 kas-milter 126 -- 1395 100232 kas-milter 127 -- 1395 100232 kas-milter 128 -- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:50:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A28D1065670 for ; Wed, 24 Aug 2011 19:50:48 +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 A98B18FC14 for ; Wed, 24 Aug 2011 19:50:47 +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 p7OJoZq7075404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 22:50:35 +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 p7OJoZLQ080304; Wed, 24 Aug 2011 22:50:35 +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 p7OJoZHW080303; Wed, 24 Aug 2011 22:50:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Aug 2011 22:50:35 +0300 From: Kostik Belousov To: Slawa Olhovchenkov Message-ID: <20110824195035.GA17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WA7H3kVYsfCLkbZb" Content-Disposition: inline In-Reply-To: <20110824194229.GC48394@zxy.spb.ru> 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-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:50:48 -0000 --WA7H3kVYsfCLkbZb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: >=20 > > > > What should the system do for a delivered signal not present in the= set ? > > > > I guess this is the case of your ktrace. > > > >=20 > > > > Looking at the SUSv4, I see no mention of the situation, but in Ora= cle > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > > EINTR The wait was interrupted by an unblocked, caught signal. > > >=20 > > > I don't think you right in this case. > > > This is kas-milter and in this thread (this is multi-thread > > > application) kas-milter wait for USR2 for reload config. > > >=20 > > > System return from sigwait only on USR2, but not each return w/ > > > non-zero return code. > > >=20 > > > On freebsd7 this application don't complain about sigwait's return va= lue. > >=20 > > Could it be that some other thread has the signal unblocked ? > > (You can verify this with procstat -j). > >=20 > > Can you write the self-contained test case that demonstrates the behavi= our ? >=20 > This is closed-source software. How is this statement related to the creation of the standalone test case ? > # procstat -j > PID TID COMM SIG FLAGS > 1395 100199 kas-milter USR2 -- > 1395 100232 kas-milter USR2 -- Both threads have the signal not blocked. This is not definitive, since signal must be blocked during the call to sigwait(2). Note that the SUSv4 says that "The signals defined by set shall have been blocked at the time of the call to sigwait(); otherwise, the behavior is undefined." --WA7H3kVYsfCLkbZb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5VVgoACgkQC3+MBN1Mb4gSqgCg1EVAlsC1UQ7Suy7UIvitzv7G rloAoJesCMp4Fi6zmv2QcMhc60WqLtfm =cFkN -----END PGP SIGNATURE----- --WA7H3kVYsfCLkbZb-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:53:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076451065676 for ; Wed, 24 Aug 2011 19:53:05 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id CD0978FC14 for ; Wed, 24 Aug 2011 19:53:03 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwJVj-000JXR-9z; Wed, 24 Aug 2011 23:53:15 +0400 Date: Wed, 24 Aug 2011 23:53:15 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824195315.GD48394@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824194229.GC48394@zxy.spb.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:53:05 -0000 On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: > > > > > What should the system do for a delivered signal not present in the set ? > > > > I guess this is the case of your ktrace. > > > > > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > > EINTR The wait was interrupted by an unblocked, caught signal. > > > > > > I don't think you right in this case. > > > This is kas-milter and in this thread (this is multi-thread > > > application) kas-milter wait for USR2 for reload config. > > > > > > System return from sigwait only on USR2, but not each return w/ > > > non-zero return code. > > > > > > On freebsd7 this application don't complain about sigwait's return value. > > > > Could it be that some other thread has the signal unblocked ? > > (You can verify this with procstat -j). > > > > Can you write the self-contained test case that demonstrates the behaviour ? > > This is closed-source software. > # procstat -j > PID TID COMM SIG FLAGS > 1395 100199 kas-milter HUP -B > 1395 100199 kas-milter INT -B > 1395 100199 kas-milter QUIT -- > 1395 100199 kas-milter ILL -- > 1395 100199 kas-milter TRAP -- > 1395 100199 kas-milter ABRT -- > 1395 100199 kas-milter EMT -- > 1395 100199 kas-milter FPE -- > 1395 100199 kas-milter KILL -- > 1395 100199 kas-milter BUS -- > 1395 100199 kas-milter SEGV -- > 1395 100199 kas-milter SYS -- > 1395 100199 kas-milter PIPE -- > 1395 100199 kas-milter ALRM -- > 1395 100199 kas-milter TERM -B > 1395 100199 kas-milter URG -- > 1395 100199 kas-milter STOP -- > 1395 100199 kas-milter TSTP -- > 1395 100199 kas-milter CONT -- > 1395 100199 kas-milter CHLD -- > 1395 100199 kas-milter TTIN -- > 1395 100199 kas-milter TTOU -- > 1395 100199 kas-milter IO -- > 1395 100199 kas-milter XCPU -- > 1395 100199 kas-milter XFSZ -- > 1395 100199 kas-milter VTALRM -- > 1395 100199 kas-milter PROF -- > 1395 100199 kas-milter WINCH -- > 1395 100199 kas-milter INFO -- > 1395 100199 kas-milter USR1 -- > 1395 100199 kas-milter USR2 -- > 1395 100199 kas-milter 32 -- > 1395 100199 kas-milter 33 -- > 1395 100199 kas-milter 34 -- > 1395 100199 kas-milter 35 -- > 1395 100199 kas-milter 36 -- > 1395 100199 kas-milter 37 -- > 1395 100199 kas-milter 38 -- > 1395 100199 kas-milter 39 -- > 1395 100199 kas-milter 40 -- > 1395 100199 kas-milter 41 -- > 1395 100199 kas-milter 42 -- > 1395 100199 kas-milter 43 -- > 1395 100199 kas-milter 44 -- > 1395 100199 kas-milter 45 -- > 1395 100199 kas-milter 46 -- > 1395 100199 kas-milter 47 -- > 1395 100199 kas-milter 48 -- > 1395 100199 kas-milter 49 -- > 1395 100199 kas-milter 50 -- > 1395 100199 kas-milter 51 -- > 1395 100199 kas-milter 52 -- > 1395 100199 kas-milter 53 -- > 1395 100199 kas-milter 54 -- > 1395 100199 kas-milter 55 -- > 1395 100199 kas-milter 56 -- > 1395 100199 kas-milter 57 -- > 1395 100199 kas-milter 58 -- > 1395 100199 kas-milter 59 -- > 1395 100199 kas-milter 60 -- > 1395 100199 kas-milter 61 -- > 1395 100199 kas-milter 62 -- > 1395 100199 kas-milter 63 -- > 1395 100199 kas-milter 64 -- > 1395 100199 kas-milter 65 -- > 1395 100199 kas-milter 66 -- > 1395 100199 kas-milter 67 -- > 1395 100199 kas-milter 68 -- > 1395 100199 kas-milter 69 -- > 1395 100199 kas-milter 70 -- > 1395 100199 kas-milter 71 -- > 1395 100199 kas-milter 72 -- > 1395 100199 kas-milter 73 -- > 1395 100199 kas-milter 74 -- > 1395 100199 kas-milter 75 -- > 1395 100199 kas-milter 76 -- > 1395 100199 kas-milter 77 -- > 1395 100199 kas-milter 78 -- > 1395 100199 kas-milter 79 -- > 1395 100199 kas-milter 80 -- > 1395 100199 kas-milter 81 -- > 1395 100199 kas-milter 82 -- > 1395 100199 kas-milter 83 -- > 1395 100199 kas-milter 84 -- > 1395 100199 kas-milter 85 -- > 1395 100199 kas-milter 86 -- > 1395 100199 kas-milter 87 -- > 1395 100199 kas-milter 88 -- > 1395 100199 kas-milter 89 -- > 1395 100199 kas-milter 90 -- > 1395 100199 kas-milter 91 -- > 1395 100199 kas-milter 92 -- > 1395 100199 kas-milter 93 -- > 1395 100199 kas-milter 94 -- > 1395 100199 kas-milter 95 -- > 1395 100199 kas-milter 96 -- > 1395 100199 kas-milter 97 -- > 1395 100199 kas-milter 98 -- > 1395 100199 kas-milter 99 -- > 1395 100199 kas-milter 100 -- > 1395 100199 kas-milter 101 -- > 1395 100199 kas-milter 102 -- > 1395 100199 kas-milter 103 -- > 1395 100199 kas-milter 104 -- > 1395 100199 kas-milter 105 -- > 1395 100199 kas-milter 106 -- > 1395 100199 kas-milter 107 -- > 1395 100199 kas-milter 108 -- > 1395 100199 kas-milter 109 -- > 1395 100199 kas-milter 110 -- > 1395 100199 kas-milter 111 -- > 1395 100199 kas-milter 112 -- > 1395 100199 kas-milter 113 -- > 1395 100199 kas-milter 114 -- > 1395 100199 kas-milter 115 -- > 1395 100199 kas-milter 116 -- > 1395 100199 kas-milter 117 -- > 1395 100199 kas-milter 118 -- > 1395 100199 kas-milter 119 -- > 1395 100199 kas-milter 120 -- > 1395 100199 kas-milter 121 -- > 1395 100199 kas-milter 122 -- > 1395 100199 kas-milter 123 -- > 1395 100199 kas-milter 124 -- > 1395 100199 kas-milter 125 -- > 1395 100199 kas-milter 126 -- > 1395 100199 kas-milter 127 -- > 1395 100199 kas-milter 128 -- > 1395 100232 kas-milter HUP -- > 1395 100232 kas-milter INT -- > 1395 100232 kas-milter QUIT -- > 1395 100232 kas-milter ILL -- > 1395 100232 kas-milter TRAP -- > 1395 100232 kas-milter ABRT -- > 1395 100232 kas-milter EMT -- > 1395 100232 kas-milter FPE -- > 1395 100232 kas-milter KILL -- > 1395 100232 kas-milter BUS -- > 1395 100232 kas-milter SEGV -- > 1395 100232 kas-milter SYS -- > 1395 100232 kas-milter PIPE -- > 1395 100232 kas-milter ALRM -- > 1395 100232 kas-milter TERM -- > 1395 100232 kas-milter URG -- > 1395 100232 kas-milter STOP -- > 1395 100232 kas-milter TSTP -- > 1395 100232 kas-milter CONT -- > 1395 100232 kas-milter CHLD -- > 1395 100232 kas-milter TTIN -- > 1395 100232 kas-milter TTOU -- > 1395 100232 kas-milter IO -- > 1395 100232 kas-milter XCPU -- > 1395 100232 kas-milter XFSZ -- > 1395 100232 kas-milter VTALRM -- > 1395 100232 kas-milter PROF -- > 1395 100232 kas-milter WINCH -- > 1395 100232 kas-milter INFO -- > 1395 100232 kas-milter USR1 -- > 1395 100232 kas-milter USR2 -- > 1395 100232 kas-milter 32 -- > 1395 100232 kas-milter 33 -- > 1395 100232 kas-milter 34 -- > 1395 100232 kas-milter 35 -- > 1395 100232 kas-milter 36 -- > 1395 100232 kas-milter 37 -- > 1395 100232 kas-milter 38 -- > 1395 100232 kas-milter 39 -- > 1395 100232 kas-milter 40 -- > 1395 100232 kas-milter 41 -- > 1395 100232 kas-milter 42 -- > 1395 100232 kas-milter 43 -- > 1395 100232 kas-milter 44 -- > 1395 100232 kas-milter 45 -- > 1395 100232 kas-milter 46 -- > 1395 100232 kas-milter 47 -- > 1395 100232 kas-milter 48 -- > 1395 100232 kas-milter 49 -- > 1395 100232 kas-milter 50 -- > 1395 100232 kas-milter 51 -- > 1395 100232 kas-milter 52 -- > 1395 100232 kas-milter 53 -- > 1395 100232 kas-milter 54 -- > 1395 100232 kas-milter 55 -- > 1395 100232 kas-milter 56 -- > 1395 100232 kas-milter 57 -- > 1395 100232 kas-milter 58 -- > 1395 100232 kas-milter 59 -- > 1395 100232 kas-milter 60 -- > 1395 100232 kas-milter 61 -- > 1395 100232 kas-milter 62 -- > 1395 100232 kas-milter 63 -- > 1395 100232 kas-milter 64 -- > 1395 100232 kas-milter 65 -- > 1395 100232 kas-milter 66 -- > 1395 100232 kas-milter 67 -- > 1395 100232 kas-milter 68 -- > 1395 100232 kas-milter 69 -- > 1395 100232 kas-milter 70 -- > 1395 100232 kas-milter 71 -- > 1395 100232 kas-milter 72 -- > 1395 100232 kas-milter 73 -- > 1395 100232 kas-milter 74 -- > 1395 100232 kas-milter 75 -- > 1395 100232 kas-milter 76 -- > 1395 100232 kas-milter 77 -- > 1395 100232 kas-milter 78 -- > 1395 100232 kas-milter 79 -- > 1395 100232 kas-milter 80 -- > 1395 100232 kas-milter 81 -- > 1395 100232 kas-milter 82 -- > 1395 100232 kas-milter 83 -- > 1395 100232 kas-milter 84 -- > 1395 100232 kas-milter 85 -- > 1395 100232 kas-milter 86 -- > 1395 100232 kas-milter 87 -- > 1395 100232 kas-milter 88 -- > 1395 100232 kas-milter 89 -- > 1395 100232 kas-milter 90 -- > 1395 100232 kas-milter 91 -- > 1395 100232 kas-milter 92 -- > 1395 100232 kas-milter 93 -- > 1395 100232 kas-milter 94 -- > 1395 100232 kas-milter 95 -- > 1395 100232 kas-milter 96 -- > 1395 100232 kas-milter 97 -- > 1395 100232 kas-milter 98 -- > 1395 100232 kas-milter 99 -- > 1395 100232 kas-milter 100 -- > 1395 100232 kas-milter 101 -- > 1395 100232 kas-milter 102 -- > 1395 100232 kas-milter 103 -- > 1395 100232 kas-milter 104 -- > 1395 100232 kas-milter 105 -- > 1395 100232 kas-milter 106 -- > 1395 100232 kas-milter 107 -- > 1395 100232 kas-milter 108 -- > 1395 100232 kas-milter 109 -- > 1395 100232 kas-milter 110 -- > 1395 100232 kas-milter 111 -- > 1395 100232 kas-milter 112 -- > 1395 100232 kas-milter 113 -- > 1395 100232 kas-milter 114 -- > 1395 100232 kas-milter 115 -- > 1395 100232 kas-milter 116 -- > 1395 100232 kas-milter 117 -- > 1395 100232 kas-milter 118 -- > 1395 100232 kas-milter 119 -- > 1395 100232 kas-milter 120 -- > 1395 100232 kas-milter 121 -- > 1395 100232 kas-milter 122 -- > 1395 100232 kas-milter 123 -- > 1395 100232 kas-milter 124 -- > 1395 100232 kas-milter 125 -- > 1395 100232 kas-milter 126 -- > 1395 100232 kas-milter 127 -- > 1395 100232 kas-milter 128 -- hmmm. not complete cut-paste: 1395 100281 kas-milter HUP -B 1395 100281 kas-milter INT -B 1395 100281 kas-milter QUIT -- 1395 100281 kas-milter ILL -- 1395 100281 kas-milter TRAP -- 1395 100281 kas-milter ABRT -- 1395 100281 kas-milter EMT -- 1395 100281 kas-milter FPE -- 1395 100281 kas-milter KILL -- 1395 100281 kas-milter BUS -- 1395 100281 kas-milter SEGV -- 1395 100281 kas-milter SYS -- 1395 100281 kas-milter PIPE -- 1395 100281 kas-milter ALRM -- 1395 100281 kas-milter TERM -B 1395 100281 kas-milter URG -- 1395 100281 kas-milter STOP -- 1395 100281 kas-milter TSTP -- 1395 100281 kas-milter CONT -- 1395 100281 kas-milter CHLD -- 1395 100281 kas-milter TTIN -- 1395 100281 kas-milter TTOU -- 1395 100281 kas-milter IO -- 1395 100281 kas-milter XCPU -- 1395 100281 kas-milter XFSZ -- 1395 100281 kas-milter VTALRM -- 1395 100281 kas-milter PROF -- 1395 100281 kas-milter WINCH -- 1395 100281 kas-milter INFO -- 1395 100281 kas-milter USR1 -- 1395 100281 kas-milter USR2 -- 1395 100281 kas-milter 32 -- 1395 100281 kas-milter 33 -- 1395 100281 kas-milter 34 -- 1395 100281 kas-milter 35 -- 1395 100281 kas-milter 36 -- 1395 100281 kas-milter 37 -- 1395 100281 kas-milter 38 -- 1395 100281 kas-milter 39 -- 1395 100281 kas-milter 40 -- 1395 100281 kas-milter 41 -- 1395 100281 kas-milter 42 -- 1395 100281 kas-milter 43 -- 1395 100281 kas-milter 44 -- 1395 100281 kas-milter 45 -- 1395 100281 kas-milter 46 -- 1395 100281 kas-milter 47 -- 1395 100281 kas-milter 48 -- 1395 100281 kas-milter 49 -- 1395 100281 kas-milter 50 -- 1395 100281 kas-milter 51 -- 1395 100281 kas-milter 52 -- 1395 100281 kas-milter 53 -- 1395 100281 kas-milter 54 -- 1395 100281 kas-milter 55 -- 1395 100281 kas-milter 56 -- 1395 100281 kas-milter 57 -- 1395 100281 kas-milter 58 -- 1395 100281 kas-milter 59 -- 1395 100281 kas-milter 60 -- 1395 100281 kas-milter 61 -- 1395 100281 kas-milter 62 -- 1395 100281 kas-milter 63 -- 1395 100281 kas-milter 64 -- 1395 100281 kas-milter 65 -- 1395 100281 kas-milter 66 -- 1395 100281 kas-milter 67 -- 1395 100281 kas-milter 68 -- 1395 100281 kas-milter 69 -- 1395 100281 kas-milter 70 -- 1395 100281 kas-milter 71 -- 1395 100281 kas-milter 72 -- 1395 100281 kas-milter 73 -- 1395 100281 kas-milter 74 -- 1395 100281 kas-milter 75 -- 1395 100281 kas-milter 76 -- 1395 100281 kas-milter 77 -- 1395 100281 kas-milter 78 -- 1395 100281 kas-milter 79 -- 1395 100281 kas-milter 80 -- 1395 100281 kas-milter 81 -- 1395 100281 kas-milter 82 -- 1395 100281 kas-milter 83 -- 1395 100281 kas-milter 84 -- 1395 100281 kas-milter 85 -- 1395 100281 kas-milter 86 -- 1395 100281 kas-milter 87 -- 1395 100281 kas-milter 88 -- 1395 100281 kas-milter 89 -- 1395 100281 kas-milter 90 -- 1395 100281 kas-milter 91 -- 1395 100281 kas-milter 92 -- 1395 100281 kas-milter 93 -- 1395 100281 kas-milter 94 -- 1395 100281 kas-milter 95 -- 1395 100281 kas-milter 96 -- 1395 100281 kas-milter 97 -- 1395 100281 kas-milter 98 -- 1395 100281 kas-milter 99 -- 1395 100281 kas-milter 100 -- 1395 100281 kas-milter 101 -- 1395 100281 kas-milter 102 -- 1395 100281 kas-milter 103 -- 1395 100281 kas-milter 104 -- 1395 100281 kas-milter 105 -- 1395 100281 kas-milter 106 -- 1395 100281 kas-milter 107 -- 1395 100281 kas-milter 108 -- 1395 100281 kas-milter 109 -- 1395 100281 kas-milter 110 -- 1395 100281 kas-milter 111 -- 1395 100281 kas-milter 112 -- 1395 100281 kas-milter 113 -- 1395 100281 kas-milter 114 -- 1395 100281 kas-milter 115 -- 1395 100281 kas-milter 116 -- 1395 100281 kas-milter 117 -- 1395 100281 kas-milter 118 -- 1395 100281 kas-milter 119 -- 1395 100281 kas-milter 120 -- 1395 100281 kas-milter 121 -- 1395 100281 kas-milter 122 -- 1395 100281 kas-milter 123 -- 1395 100281 kas-milter 124 -- 1395 100281 kas-milter 125 -- 1395 100281 kas-milter 126 -- 1395 100281 kas-milter 127 -- 1395 100281 kas-milter 128 -- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 19:54:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D9AD1065673 for ; Wed, 24 Aug 2011 19:54:14 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCAA8FC0C for ; Wed, 24 Aug 2011 19:54:12 +0000 (UTC) Received: from sa-nc-common-23.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id p7OJT55V083878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Aug 2011 12:29:09 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20110824115956.GA35240@icarus.home.lan> Date: Wed, 24 Aug 2011 12:29:05 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20110821154249.GE92605@core.byshenk.net> <20110821222033.GH92605@core.byshenk.net> <20110822083336.GI92605@core.byshenk.net> <20110822094756.GJ92605@core.byshenk.net> <20110824070826.GK92605@core.byshenk.net> <20110824115956.GA35240@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1244.3) Cc: Greg Byshenk , freebsd-stable@freebsd.org, David Wood Subject: Re: Serial multiport error Oxford/Startech PEX2S952 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:54:14 -0000 On Aug 24, 2011, at 4:59 AM, Jeremy Chadwick wrote: >> >> It may also be interesting to try 9.x on a machine with a serial >> port that operates directly with uart(4). Does stty(4) throw up >> "isn't a terminal" errors against the .init and .lock devices >> relating to those ports? I would try this myself, but am very short >> of time at present. >> >> >> Though there is probably little more that I can add, please keep me >> cc'd on all relevant e-mails, especially as I do not follow >> freebsd-current. > > I'm CC'ing Marcel Moolenaar here, who's the author of uart(4), to help > assist in this matter and shed some light on the above comments. If > there's a quirk or bug there, I'm certain he'll assist in helping. There's no obvious problem in uart(4). The handling of *.init and *.lock is all unified in the TTY layer. Note that the typical scenario for uart(4) to not respect the baud rate setting is when the UART port is a system device (i.e. serial console or debug port). Make sure there's no difference between 8.x and 9.x with respect to which ports are declared as system ports. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 20:04:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434EA1065673 for ; Wed, 24 Aug 2011 20:04:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id F25888FC16 for ; Wed, 24 Aug 2011 20:04:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwJh2-000Jbp-Mh; Thu, 25 Aug 2011 00:04:56 +0400 Date: Thu, 25 Aug 2011 00:04:56 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824200456.GE48394@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> <20110824195035.GA17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824195035.GA17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:04:46 -0000 On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: > > > > > > > What should the system do for a delivered signal not present in the set ? > > > > > I guess this is the case of your ktrace. > > > > > > > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > > > EINTR The wait was interrupted by an unblocked, caught signal. > > > > > > > > I don't think you right in this case. > > > > This is kas-milter and in this thread (this is multi-thread > > > > application) kas-milter wait for USR2 for reload config. > > > > > > > > System return from sigwait only on USR2, but not each return w/ > > > > non-zero return code. > > > > > > > > On freebsd7 this application don't complain about sigwait's return value. > > > > > > Could it be that some other thread has the signal unblocked ? > > > (You can verify this with procstat -j). > > > > > > Can you write the self-contained test case that demonstrates the behaviour ? > > > > This is closed-source software. > How is this statement related to the creation of the standalone test case ? I don't know what testing. > > # procstat -j > > PID TID COMM SIG FLAGS > > 1395 100199 kas-milter USR2 -- > > 1395 100232 kas-milter USR2 -- > > Both threads have the signal not blocked. This is not definitive, > since signal must be blocked during the call to sigwait(2). Note that > the SUSv4 says that "The signals defined by set shall have been > blocked at the time of the call to sigwait(); otherwise, the behavior is > undefined." This is not suitable to return '4'. And where root of this '4'? In /sys/kern/kern_sig.c:sigwait we call error = kern_sigtimedwait(td, set, &ksi, NULL); --- no timeout. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 20:41:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9B351065673 for ; Wed, 24 Aug 2011 20:41:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 433118FC15 for ; Wed, 24 Aug 2011 20:41:34 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwKGf-000Jr2-Uk; Thu, 25 Aug 2011 00:41:45 +0400 Date: Thu, 25 Aug 2011 00:41:45 +0400 From: Slawa Olhovchenkov To: Kostik Belousov Message-ID: <20110824204145.GA75535@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824192446.GB48394@zxy.spb.ru> <20110824193202.GZ17489@deviant.kiev.zoral.com.ua> <20110824194229.GC48394@zxy.spb.ru> <20110824195035.GA17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824195035.GA17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:41:35 -0000 On Wed, Aug 24, 2011 at 10:50:35PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 11:42:29PM +0400, Slawa Olhovchenkov wrote: > > On Wed, Aug 24, 2011 at 10:32:02PM +0300, Kostik Belousov wrote: > > > > > > > What should the system do for a delivered signal not present in the set ? > > > > > I guess this is the case of your ktrace. > > > > > > > > > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > > > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > > > > EINTR The wait was interrupted by an unblocked, caught signal. > > > > > > > > I don't think you right in this case. > > > > This is kas-milter and in this thread (this is multi-thread > > > > application) kas-milter wait for USR2 for reload config. > > > > > > > > System return from sigwait only on USR2, but not each return w/ > > > > non-zero return code. > > > > > > > > On freebsd7 this application don't complain about sigwait's return value. > > > > > > Could it be that some other thread has the signal unblocked ? > > > (You can verify this with procstat -j). > > > > > > Can you write the self-contained test case that demonstrates the behaviour ? > > > > This is closed-source software. > How is this statement related to the creation of the standalone test case ? > > > # procstat -j > > PID TID COMM SIG FLAGS > > 1395 100199 kas-milter USR2 -- > > 1395 100232 kas-milter USR2 -- > > Both threads have the signal not blocked. This is not definitive, > since signal must be blocked during the call to sigwait(2). Note that > the SUSv4 says that "The signals defined by set shall have been > blocked at the time of the call to sigwait(); otherwise, the behavior is > undefined." I see some strange in debug: # kdump -H -f /ktrace.out | grep sigw 1396 100228 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) # ktrdump | grep sigw 738 syscall: td=0xffffff002549d900 pid 1396 sigwait (0xffdfdf80, 0xffdfdf7c, 0xffffff8117827bf0) 666 syscall: td=0xffffff000c3d9900 pid 1286 sigwait (0x7fffffbfef70, 0x7fffffbfef8c, 0) 660 syscall: td=0xffffff00251ed900 pid 1277 sigwait (0x7ffffddeff70, 0x7ffffddeff8c, 0) 51 syscall: td=0xffffff0004ac5000 pid 787 sigwait (0x7fffffffebb0, 0x7fffffffebdc, 0) now I see 3'th non-zero argument from pid 1396. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 20:56:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26CF41065672 for ; Wed, 24 Aug 2011 20:56:13 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id BD0878FC0C for ; Wed, 24 Aug 2011 20:56:12 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id CF07C3593B2; Wed, 24 Aug 2011 22:56:09 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id BDB35173CB; Wed, 24 Aug 2011 22:56:09 +0200 (CEST) Date: Wed, 24 Aug 2011 22:56:09 +0200 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20110824205609.GA96070@stack.nl> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824190703.GY17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Slawa Olhovchenkov Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:56:13 -0000 On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: > > System is 8.2-RELEASE (GENERIC), amd64. > > Application -- i386 for freebsd7. > > In ktrace dump I find some strange result: > > 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) > > 22951 100556 kas-milter RET sigwait 4 > > 22951 100556 kas-milter PSIG SIGUSR2 caught handler=0x804c0f0 mask=0x4003 code=0x0 > > RET sigwait 4 confused me, and, I think, confused application too. > > man sigwait: > > ERRORS > > The sigwait() system call will fail if: > > [EINVAL] The set argument specifies one or more invalid signal > > numbers. > > [EFAULT] Any arguments point outside the allocated address > > space or there is a memory protection fault. > > How sigwait can return '4'? > > May be EINTR, converted from ERESTART? But kern_sigtimedwait from > > sigwait must be called with timeout == NULL... > What should the system do for a delivered signal not present in the set ? > I guess this is the case of your ktrace. > Looking at the SUSv4, I see no mention of the situation, but in Oracle > SunOS 5.10 man page for sigwait(2), it is said explicitely > EINTR The wait was interrupted by an unblocked, caught signal. > So I think that we have a bug in the man page. > diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 > index 8c00cf4..b462201 100644 > --- a/lib/libc/sys/sigwait.2 > +++ b/lib/libc/sys/sigwait.2 > @@ -27,7 +27,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd November 11, 2005 > +.Dd August 24, 2011 > .Dt SIGWAIT 2 > .Os > .Sh NAME > @@ -94,6 +94,8 @@ The > .Fn sigwait > system call will fail if: > .Bl -tag -width Er > +.It Bq Er EINTR > +The system call was interrupted by an unblocked, caught signal. > .It Bq Er EINVAL > The > .Fa set This patch would be wrong, except to document existing behaviour in -stable branches. sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed up in r219709). The discussion started at http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html Solaris is simply wrong in the same way we were wrong. Although POSIX may not be as clear on this as one may like, its intention is clear and additionally not returning EINTR reduces subtle portability problems. Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART applies to sigwaitinfo() but not to sigtimedwait() (because the timeout cannot be restarted). -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 21:09:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C14C7106564A for ; Wed, 24 Aug 2011 21:09:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3508FC12 for ; Wed, 24 Aug 2011 21:09:56 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QwKi6-000K3Y-TK; Thu, 25 Aug 2011 01:10:06 +0400 Date: Thu, 25 Aug 2011 01:10:06 +0400 From: Slawa Olhovchenkov To: Jilles Tjoelker Message-ID: <20110824211006.GB75535@zxy.spb.ru> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824205609.GA96070@stack.nl> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Kostik Belousov , freebsd-stable@freebsd.org Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:09:56 -0000 On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > up in r219709). The discussion started at > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html As I see this revisions not MFCed. No plans to fix this in 8-STABLE? > Solaris is simply wrong in the same way we were wrong. Although POSIX > may not be as clear on this as one may like, its intention is clear and > additionally not returning EINTR reduces subtle portability problems. > > Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART > applies to sigwaitinfo() but not to sigtimedwait() (because the timeout > cannot be restarted). > > -- > Jilles Tjoelker > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 21:29:33 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF641106566B for ; Wed, 24 Aug 2011 21:29:33 +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 8CC528FC12 for ; Wed, 24 Aug 2011 21:29:33 +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 p7OLTTkg082390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 00:29:29 +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 p7OLTT8G084425; Thu, 25 Aug 2011 00:29:29 +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 p7OLTTfB084424; Thu, 25 Aug 2011 00:29:29 +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, 25 Aug 2011 00:29:29 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20110824212929.GC17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+oWXwP+znI39+mKE" Content-Disposition: inline In-Reply-To: <20110824205609.GA96070@stack.nl> 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-stable@freebsd.org, Slawa Olhovchenkov Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 21:29:34 -0000 --+oWXwP+znI39+mKE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > On Wed, Aug 24, 2011 at 10:07:03PM +0300, Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 10:19:07PM +0400, Slawa Olhovchenkov wrote: > > > System is 8.2-RELEASE (GENERIC), amd64. > > > Application -- i386 for freebsd7. >=20 > > > In ktrace dump I find some strange result: >=20 > > > 22951 100556 kas-milter CALL sigwait(0xffdfdf80,0xffdfdf7c) > > > 22951 100556 kas-milter RET sigwait 4 > > > 22951 100556 kas-milter PSIG SIGUSR2 caught handler=3D0x804c0f0 mas= k=3D0x4003 code=3D0x0 >=20 > > > RET sigwait 4 confused me, and, I think, confused application too. >=20 > > > man sigwait: >=20 > > > ERRORS > > > The sigwait() system call will fail if: >=20 > > > [EINVAL] The set argument specifies one or more invali= d signal > > > numbers. >=20 > > > [EFAULT] Any arguments point outside the allocated add= ress > > > space or there is a memory protection fault. >=20 > > > How sigwait can return '4'? > > > May be EINTR, converted from ERESTART? But kern_sigtimedwait from > > > sigwait must be called with timeout =3D=3D NULL... >=20 > > What should the system do for a delivered signal not present in the set= ? > > I guess this is the case of your ktrace. >=20 > > Looking at the SUSv4, I see no mention of the situation, but in Oracle > > SunOS 5.10 man page for sigwait(2), it is said explicitely > > EINTR The wait was interrupted by an unblocked, caught signal. >=20 > > So I think that we have a bug in the man page. >=20 > > diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 > > index 8c00cf4..b462201 100644 > > --- a/lib/libc/sys/sigwait.2 > > +++ b/lib/libc/sys/sigwait.2 > > @@ -27,7 +27,7 @@ > > .\" > > .\" $FreeBSD$ > > .\" > > -.Dd November 11, 2005 > > +.Dd August 24, 2011 > > .Dt SIGWAIT 2 > > .Os > > .Sh NAME > > @@ -94,6 +94,8 @@ The > > .Fn sigwait > > system call will fail if: > > .Bl -tag -width Er > > +.It Bq Er EINTR > > +The system call was interrupted by an unblocked, caught signal. > > .It Bq Er EINVAL > > The > > .Fa set >=20 > This patch would be wrong, except to document existing behaviour in > -stable branches. >=20 > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > up in r219709). The discussion started at > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.= html >=20 > Solaris is simply wrong in the same way we were wrong. Although POSIX > may not be as clear on this as one may like, its intention is clear and > additionally not returning EINTR reduces subtle portability problems. Can you, please, describe why do you consider the behaviour prohibiting return of EINTR reasonable ? I do consider that the Solaris behaviour is useful. Since we went the other route, the addition to sigwait(2) manpage that clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, the sentence "the sigwaitinfo() function is equivalent to sigwait() ..." in the sigwaitinfo(2) is not complete, due to EINTR. >=20 > Note that sigwaitinfo() and sigtimedwait() may return EINTR. SA_RESTART > applies to sigwaitinfo() but not to sigtimedwait() (because the timeout > cannot be restarted). >=20 > --=20 > Jilles Tjoelker --+oWXwP+znI39+mKE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5VbTkACgkQC3+MBN1Mb4gAFgCgslcOs6OWdhYZlTA8YiwVnqpd EuUAnjiAwCV4Hc/Zx9FUFDHV+kGG8GYc =Zpjf -----END PGP SIGNATURE----- --+oWXwP+znI39+mKE-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 24 22:12:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F5A0106564A for ; Wed, 24 Aug 2011 22:12:26 +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 F205A8FC12 for ; Wed, 24 Aug 2011 22:12:25 +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 p7OMCMc4085254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 01:12:22 +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 p7OMCMTU086285; Thu, 25 Aug 2011 01:12:22 +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 p7OMCMoQ086284; Thu, 25 Aug 2011 01:12:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 25 Aug 2011 01:12:22 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20110824221222.GE17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> <20110824212929.GC17489@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n/5ZWAgLgY6CQBJc" Content-Disposition: inline In-Reply-To: <20110824212929.GC17489@deviant.kiev.zoral.com.ua> 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-stable@freebsd.org, Slawa Olhovchenkov Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 22:12:26 -0000 --n/5ZWAgLgY6CQBJc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: > > Solaris is simply wrong in the same way we were wrong. Although POSIX > > may not be as clear on this as one may like, its intention is clear and > > additionally not returning EINTR reduces subtle portability problems. > Can you, please, describe why do you consider the behaviour prohibiting > return of EINTR reasonable ? I do consider that the Solaris behaviour is > useful. >=20 > Since we went the other route, the addition to sigwait(2) manpage that > clarifies this looks useful. And, sigwait(2) shall be sigwait(3). Also, > the sentence "the sigwaitinfo() function is equivalent to sigwait() ..." > in the sigwaitinfo(2) is not complete, due to EINTR. Like this (svn cp to be applied). diff --git a/lib/libc/sys/sigwait.2 b/lib/libc/sys/sigwait.2 index 8c00cf4..a9e605c 100644 --- a/lib/libc/sys/sigwait.2 +++ b/lib/libc/sys/sigwait.2 @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGWAIT 2 .Os .Sh NAME @@ -82,6 +82,14 @@ selected, it will be the lowest numbered one. The selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. +.Sh IMPLEMENTATION NOTES +The +.Fn sigwait +function is implemented as a wrapper around the +.Fn __sys_sigwait +system call, which retries the call on +.Er EINTR +error. .Sh RETURN VALUES If successful, .Fn sigwait diff --git a/lib/libc/sys/sigwaitinfo.2 b/lib/libc/sys/sigwaitinfo.2 index 41be9e2..a83de06 100644 --- a/lib/libc/sys/sigwaitinfo.2 +++ b/lib/libc/sys/sigwaitinfo.2 @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd November 11, 2005 +.Dd August 24, 2011 .Dt SIGTIMEDWAIT 2 .Os .Sh NAME @@ -116,6 +116,16 @@ except that the selected signal number shall be stored= in the member, and the cause of the signal shall be stored in the .Va si_code member. +Besides this, the +.Fn sigwaitinfo +and +.Fn sigtimedwait +system calls may return +.Er EINTR +if interrupted by signal, which is not allowed for the +.Fn sigwait +function. +.Pp If any value is queued to the selected signal, the first such queued value is dequeued and, if the info argument is .Pf non- Dv NULL , --n/5ZWAgLgY6CQBJc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5Vd0YACgkQC3+MBN1Mb4gBnQCgsdPM135ib5x5OM0Fj0KyZRNY FmwAnig6jM9oSBXuH8O5NnHe+JuRA+zS =fag8 -----END PGP SIGNATURE----- --n/5ZWAgLgY6CQBJc-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 07:47:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76E0D1065670 for ; Thu, 25 Aug 2011 07:47:09 +0000 (UTC) (envelope-from tonymaher@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id EC91C8FC19 for ; Thu, 25 Aug 2011 07:47:08 +0000 (UTC) Received: from zen.home (c211-30-203-136.thorn2.nsw.optusnet.com.au [211.30.203.136]) (authenticated sender tonymaher) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7P7l66N029187; Thu, 25 Aug 2011 17:47:06 +1000 Message-ID: <4E55FDFA.5000104@optusnet.com.au> Date: Thu, 25 Aug 2011 17:47:06 +1000 From: Tony Maher User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110825 Thunderbird/6.0 MIME-Version: 1.0 To: Volodymyr Kostyrko References: <4E54BE01.6030408@optusnet.com.au> <4E551869.9090709@gmail.com> In-Reply-To: <4E551869.9090709@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: xterm - truetype fonts and missing underscore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 07:47:09 -0000 On 08/25/11 01:27, Volodymyr Kostyrko wrote: > 24.08.2011 12:01, Tony Maher wrote: >> Hello, >> >> recently (not sure exactly when) my xterms no longer showed the >> underscore character. >> In my .Xresources I had (and have had this setting for years): >> >> XTerm*faceName: Monospace >> XTerm*faceSize: 10 >> >> I noticed when experimenting and modifying values that for one choice >> the bottom part of letters like 'g' was missing. >> So changed faceSize to 11 and all is good. >> >> In gnome-terminal with Monospace/10 font underscores showed up fine >> (and was ok in gnome font selector). So it appears to be xterm specific. >> >> Has anyone else experienced this? > > +1 from me > > http://lists.nongnu.org/archive/html/freetype/2011-08/msg00020.html Ok. Thanks for the link. cheers -- Tony Maher email: tonymaher@optusnet.com.au From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 08:59:37 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87B43106567A; Thu, 25 Aug 2011 08:59:37 +0000 (UTC) (envelope-from bugReporter@Haakh.de) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id B71228FC16; Thu, 25 Aug 2011 08:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1314262774; l=849; s=domk; d=haakh.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=JBOBMaQmXUXxdbLJaU15nPSbFSI=; b=uDumOeGYQ+gBPac/4RMdWkyHeUSF/EUDLr2xKWKlw2JWPuAysLHc1vzrxURsJZx1FV5 Q6TWeletsez/lwKNxtXDJukceqc7MhOD62JofJiOkDoQSGC3wu1s/eGTi8dvRCZE90R4n 1IjsBfFjhXQU0XB7PGawUXhfGgfgRzXQy2I= X-RZG-AUTH: :LWQcbViwW/e6OTbW0dHzwKkCepY3+zAQY9KdRPw9VcHc3bN9H/X+W1m08A== X-RZG-CLASS-ID: mo00 Received: from abaton.Haakh.de (p57A71147.dip.t-dialin.net [87.167.17.71]) by smtp.strato.de (klopstock mo30) (RZmta 26.2) with ESMTPA id n0075an7P75xYt ; Thu, 25 Aug 2011 10:59:02 +0200 (MEST) Received: from Crabberio.Haakh.de (crabberio.haakh.de [IPv6:2001:5c0:1508:1500:213:d4ff:fed0:bb7f]) by abaton.Haakh.de (8.14.5/8.14.4) with ESMTP id p7P8wxdA017758; Thu, 25 Aug 2011 10:58:59 +0200 (CEST) (envelope-from bugReporter@Haakh.de) Message-ID: <4E560ED3.6050202@Haakh.de> Date: Thu, 25 Aug 2011 10:58:59 +0200 From: "Dr. A. Haakh" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de; rv:1.9.1.19) Gecko/20110818 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Oliver Pinter , freebsd-bugs@freebsd.org, stable@freebsd.org References: <4E1C5107.2030500@Haakh.de> <4E1D41FB.2080202@Haakh.de> <20110824175003.GA58601@zim.MIT.EDU> In-Reply-To: <20110824175003.GA58601@zim.MIT.EDU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_HK_NAME_DR, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on abaton.Haakh.de Cc: Subject: Re: stable/7/lib/msun/src/e_log2.c missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 08:59:37 -0000 David Schultz wrote: > On Wed, Jul 13, 2011, Dr. A. Haakh wrote: > >> Oliver Pinter schrieb: >> >>> On 7/12/11, Dr. A. Haakh wrote: >>> >>> >>>> log2() log2f have been MFCd to 8-STABLE (r216210 and r216210) but are >>>> still missing in 7-STABLE. >>>> >>>> See >>>> http://www.freebsd.org/cgi/getmsg.cgi?fetch=24955+47747+/usr/local/www/db/text/2011/freebsd-ports/20110612.freebsd-ports >>>> >>>> This breaks several ports. Any plans? >>>> > [...] > >> would be nice if it could be done. >> > Given that 9.0-RELEASE is imminent and no further 7.X releases are > expected, I wasn't planning on MFCing new functionality to 7-STABLE. > But if it makes life easier for porters, I can look into it. > As isdn has been removed from 8.x I have to keep 7.x for a while... I would appreciate log2 being MFCd From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 09:07:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3111106564A for ; Thu, 25 Aug 2011 09:07:12 +0000 (UTC) (envelope-from tonymaher@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 773378FC1A for ; Thu, 25 Aug 2011 09:07:12 +0000 (UTC) Received: from zen.home (c211-30-203-136.thorn2.nsw.optusnet.com.au [211.30.203.136]) (authenticated sender tonymaher) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p7P9788I026646; Thu, 25 Aug 2011 19:07:09 +1000 Message-ID: <4E5610BC.6070706@optusnet.com.au> Date: Thu, 25 Aug 2011 19:07:08 +1000 From: Tony Maher User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110825 Thunderbird/6.0 MIME-Version: 1.0 To: Mark Saad References: <4e551c41.0663340a.0d3b.3005@mx.google.com> In-Reply-To: <4e551c41.0663340a.0d3b.3005@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: xterm - truetype fonts and missing underscore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 09:07:13 -0000 On 08/25/11 01:43, Mark Saad wrote: > What else is in you .Xresources file. I removed it entirely and problem remains. > Also have you tried using xft formated font names. Ie xft:luxi mono:size=10 ? xterm -fa 'xft:luxi mono:size=10' produces an xterm which display correctly xterm -fa 'xft:Monospace:size=10' produces an xterm that displays incorrectly. The linkVolodymyr Kostyrko explains the problem. cheers -- Tony Maher email: tonymaher@optusnet.com.au From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 10:02:15 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D648C1065678 for ; Thu, 25 Aug 2011 10:02:15 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id B0C658FC14 for ; Thu, 25 Aug 2011 10:02:15 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QwWLg-000LqO-Um; Thu, 25 Aug 2011 02:35:45 -0700 Message-ID: <4E56176A.70706@sippysoft.com> Date: Thu, 25 Aug 2011 02:35:38 -0700 From: Maxim Sobolev Organization: Sippy Software User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jack Vogel , stable@freebsd.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-ssp-trusted: yes Cc: Subject: 8-stable panics in igb(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:02:15 -0000 Hi, We have observed what appears to be a crash in what appears to be the interrupt thread for the igb(8) driver on one of our systems. This machine runs May 22's 8.2-STABLE. For some reason the IP of the crash (0xffffffff806d6399) points to the key_sendup0() function, however we never had IPsec configured on that box, so I suspect it is not accurate. http://sobomax.sippysoft.com/ScreenShot833.png Any ideas of what could be wrong there are appreciated. Thanks! -Maxim From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 10:02:16 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6382106566C for ; Thu, 25 Aug 2011 10:02:16 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 838588FC1E for ; Thu, 25 Aug 2011 10:02:16 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QwWRh-000Lr0-U9; Thu, 25 Aug 2011 02:41:58 -0700 Message-ID: <4E5618DF.6090909@FreeBSD.org> Date: Thu, 25 Aug 2011 02:41:51 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Jack Vogel , stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: Subject: 8-stable panics in igb(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:02:16 -0000 Hi, We have observed what appears to be a crash in the interrupt thread for the igb(8) driver on one of our systems. This machine runs May 22's 8.2-STABLE. For some reason the IP of the crash (0xffffffff806d6399) points to the key_sendup0() function, however we never had IPsec configured on that box, so I suspect it is not accurate. http://sobomax.sippysoft.com/ScreenShot833.png Any ideas of what could be wrong there are appreciated. Thanks! -Maxim From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 10:26:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1791065670 for ; Thu, 25 Aug 2011 10:26:21 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 00E2C8FC0A for ; Thu, 25 Aug 2011 10:26:20 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.4/8.14.4) with ESMTP id p7PAFrsR008653 for ; Thu, 25 Aug 2011 12:15:55 +0200 Received: from pmp.uni-hannover.de (unknown [130.75.117.3]) by www.pmp.uni-hannover.de (Postfix) with SMTP id C6C942B3 for ; Thu, 25 Aug 2011 12:15:53 +0200 (CEST) Date: Thu, 25 Aug 2011 12:15:53 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20110825121553.53e8f728.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.25.100314 Subject: Fw: zfs snapshot: Bad file descriptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gerrit.kuehn@aei.mpg.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:26:21 -0000 Sorry for crossposting, but I got no answer at all from freebsd-fs. Anyone in here having any ideas/suggestions on this? cu Gerrit Begin forwarded message: Date: Tue, 23 Aug 2011 17:02:55 +0200 From: Gerrit K=FChn To: freebsd-fs@freebsd.org Subject: zfs snapshot: Bad file descriptor Hi all, since upgrading some of my storage machines to recent 8.2-stable and zfs-v28 I see the following on some filesystems after some time of operation: --- mclane# ll /tank/home/pt/.zfs ls: snapshot: Bad file descriptor total 0 --- I make quite heavy use of snapshots on all my machines and use rsync to backup snapshots to other machines. Googleing around I found several people reporting similar problems, but no real solution (apart from rebooting, which is not really a thing you want to do every time you run into this). Is there any knowledge/ideas available over the list here how to improve this situation? Am I just one of the few unlucky people who see this, or is there an actual reason for this happening that could be fixed or circumvented? cu Gerrit _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 10:31:01 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF05A106566B; Thu, 25 Aug 2011 10:31:01 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2A08F8FC16; Thu, 25 Aug 2011 10:31:00 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id p7PAUvUA026260; Thu, 25 Aug 2011 17:30:57 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E56245C.6030704@rdtc.ru> Date: Thu, 25 Aug 2011 17:30:52 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Maxim Sobolev References: <4E5618DF.6090909@FreeBSD.org> In-Reply-To: <4E5618DF.6090909@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jack Vogel Subject: Re: 8-stable panics in igb(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 10:31:01 -0000 25.08.2011 16:41, Maxim Sobolev ÐÉÛÅÔ: > Hi, > > We have observed what appears to be a crash in the interrupt thread for > the igb(8) driver on one of our systems. This machine runs May 22's > 8.2-STABLE. For some reason the IP of the crash (0xffffffff806d6399) > points to the key_sendup0() function, however we never had IPsec > configured on that box, so I suspect it is not accurate. > > http://sobomax.sippysoft.com/ScreenShot833.png > > Any ideas of what could be wrong there are appreciated. It would be nice to see KDB backtrace with symbols: options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options DDB_NUMSYM and "options KDB_UNATTENDED" if you wish. For next crash, of course :-) Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 11:10:35 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E026106566B for ; Thu, 25 Aug 2011 11:10:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail.sippysoft.com (mail.sippysoft.com [4.59.13.245]) by mx1.freebsd.org (Postfix) with ESMTP id 499B18FC24 for ; Thu, 25 Aug 2011 11:10:35 +0000 (UTC) Received: from s0106005004e13421.vs.shawcable.net ([70.71.175.212] helo=[192.168.1.79]) by mail.sippysoft.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QwXpQ-000MCT-Jq; Thu, 25 Aug 2011 04:10:33 -0700 Message-ID: <4E562DA1.1010902@FreeBSD.org> Date: Thu, 25 Aug 2011 04:10:25 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Eugene Grosbein References: <4E5618DF.6090909@FreeBSD.org> <4E56245C.6030704@rdtc.ru> In-Reply-To: <4E56245C.6030704@rdtc.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: sobomax@sippysoft.com X-ssp-trusted: yes Cc: stable@freebsd.org, Jack Vogel Subject: Re: 8-stable panics in igb(8) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 11:10:35 -0000 On 8/25/2011 3:30 AM, Eugene Grosbein wrote: > It would be nice to see KDB backtrace with symbols: > > options KDB > options KDB_TRACE > options KDB_UNATTENDED > options DDB > options DDB_NUMSYM > > and "options KDB_UNATTENDED" if you wish. > > For next crash, of course:-) Added, thanks for the tip. -Maxim From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 13:28:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9FA71065704 for ; Thu, 25 Aug 2011 13:28:19 +0000 (UTC) (envelope-from nbeck@hobsoft.com.mt) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id B895A8FC1D for ; Thu, 25 Aug 2011 13:28:19 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1QwZyk-0005Ke-Qf for freebsd-stable@freebsd.org; Thu, 25 Aug 2011 06:28:18 -0700 Date: Thu, 25 Aug 2011 06:28:18 -0700 (PDT) From: noel beck To: freebsd-stable@freebsd.org Message-ID: <1314278898818-4734497.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: FreeBSD 8.2r amd 64 problem when compiling 32bit applications X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:28:19 -0000 I installed FreeBSD 8.2 release on a 64-bit machine (amd64) and it has gcc 4.2.1 built in. The library directories are lib, lib32 and lib64. When I compiled for 64-bit the compilation was successful. However, the problem is when I am compiling for 32-bit on this 64-bit machine. We are getting an error stating that libstdc++.so.6 is missing. Other forums state that if you install compact6x or compact7x, the missing libraries will be installed. I installed these but it did not solve my problem. The following is the example of when compiling in 64-bit: [gsaid@Bruno ~]$ ls MyDocuments hello.c [gsaid@Bruno ~]$ gcc -o hello hello.c [gsaid@Bruno ~]$ ls MyDocuments hello hello.c [gsaid@Bruno ~]$ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, not stripped [gsaid@Bruno ~]$ ./hello Hello, World! The following is the example of the error when compiling in 32-bit on a 64-bit machine: [gsaid@Bruno ~]$ gcc -m32 -o hello hello.c /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc This is my Hello World script: [gsaid@Bruno ~]$ cat hello.c #include int main(int argc, char **argv) { printf("Hello, World!\n"); return 0; } I have also tried adding "WITH_LIB32=yes" to /etc/make.conf and compiled and installed the kernel again. When I locate for libgcc.a to see if there is a one for 32-bit, only one is found and it is of 64-bit [gsaid@Bruno /]$ locate libgcc.a /usr/lib/libgcc.a [gsaid@Bruno /]$ nm /usr/lib/libgcc.a __gcc_bcmp.o: 0000000000000000 T __gcc_bcmp -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-8-2r-amd-64-problem-when-compiling-32bit-applications-tp4734497p4734497.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 13:42:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6217106566B for ; Thu, 25 Aug 2011 13:42:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 622DE8FC0C for ; Thu, 25 Aug 2011 13:42:55 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QwaCr-0006fX-Ig for freebsd-stable@freebsd.org; Thu, 25 Aug 2011 15:42:53 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Aug 2011 15:42:53 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Aug 2011 15:42:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 25 Aug 2011 15:42:41 +0200 Lines: 9 Message-ID: References: <1314278898818-4734497.post@n5.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <1314278898818-4734497.post@n5.nabble.com> X-Enigmail-Version: 1.1.2 Subject: Re: FreeBSD 8.2r amd 64 problem when compiling 32bit applications X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:42:57 -0000 On 25/08/2011 15:28, noel beck wrote: > The following is the example of the error when compiling in 32-bit on a > 64-bit machine: > > [gsaid@Bruno ~]$ gcc -m32 -o hello hello.c I don't think "-m32" is supported at all. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 13:55:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 877001065670 for ; Thu, 25 Aug 2011 13:55:06 +0000 (UTC) (envelope-from tevans.uk@googlemail.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 363ED8FC1C for ; Thu, 25 Aug 2011 13:55:05 +0000 (UTC) Received: by vxh11 with SMTP id 11so2219075vxh.13 for ; Thu, 25 Aug 2011 06:55:05 -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:content-transfer-encoding; bh=s5CczyCTYnd+t4IeUvgEetOX8oV1v3vftTlq76qwzdU=; b=vg16o+qkppH2zOexKklJFf7RzD4fm1uFGLZg4qXvKRwJ5VUVAmIZXioaxwMxglbbk6 +Ge4d0B/6Vt8conLYWeAQ8Gx4+Br9Li5dMw6+aOPUnBmKOE9w7FFJBUi6YsNiKe3Jv9V rxHG2ba8eczoBeznfVcZT0laAqFvu9n7x2L0g= MIME-Version: 1.0 Received: by 10.52.112.3 with SMTP id im3mr2981012vdb.212.1314280505338; Thu, 25 Aug 2011 06:55:05 -0700 (PDT) Received: by 10.52.162.73 with HTTP; Thu, 25 Aug 2011 06:55:05 -0700 (PDT) In-Reply-To: <1314278898818-4734497.post@n5.nabble.com> References: <1314278898818-4734497.post@n5.nabble.com> Date: Thu, 25 Aug 2011 14:55:05 +0100 Message-ID: From: Tom Evans To: noel beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2r amd 64 problem when compiling 32bit applications X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:55:06 -0000 On Thu, Aug 25, 2011 at 2:28 PM, noel beck wrote: > I installed FreeBSD 8.2 release on a 64-bit machine (amd64) and it has gc= c > 4.2.1 built in. =C2=A0The library directories are lib, lib32 and lib64. = =C2=A0When I > compiled for 64-bit the compilation was successful. > > However, the problem is when I am compiling for 32-bit on this 64-bit > machine. =C2=A0We are getting an error stating that libstdc++.so.6 is mis= sing. > Other forums state that if you install compact6x or compact7x, the missin= g > libraries will be installed. =C2=A0I installed these but it did not solve= my > problem. Didn't you ask the precise same question yesterday? My reply to that question, and Kostik's explanation of why even that will not work properly are relevant here. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 14:07:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F2A1065687 for ; Thu, 25 Aug 2011 14:07:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 80C1E8FC1A for ; Thu, 25 Aug 2011 14:07:34 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id QdyZ1h00216LCl05Ce7bQ9; Thu, 25 Aug 2011 14:07:35 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta06.westchester.pa.mail.comcast.net with comcast id Qe7Z1h01i1t3BNj3Se7aUN; Thu, 25 Aug 2011 14:07:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2B512102C36; Thu, 25 Aug 2011 07:07:32 -0700 (PDT) Date: Thu, 25 Aug 2011 07:07:32 -0700 From: Jeremy Chadwick To: noel beck Message-ID: <20110825140732.GA59487@icarus.home.lan> References: <1314278898818-4734497.post@n5.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1314278898818-4734497.post@n5.nabble.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.2r amd 64 problem when compiling 32bit applications X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 14:07:39 -0000 On Thu, Aug 25, 2011 at 06:28:18AM -0700, noel beck wrote: > I installed FreeBSD 8.2 release on a 64-bit machine (amd64) and it has gcc > 4.2.1 built in. The library directories are lib, lib32 and lib64. When I > compiled for 64-bit the compilation was successful. > > However, the problem is when I am compiling for 32-bit on this 64-bit > machine. We are getting an error stating that libstdc++.so.6 is missing. > Other forums state that if you install compact6x or compact7x, the missing > libraries will be installed. I installed these but it did not solve my > problem. > > The following is the example of when compiling in 64-bit: > [gsaid@Bruno ~]$ ls > MyDocuments hello.c > [gsaid@Bruno ~]$ gcc -o hello hello.c > [gsaid@Bruno ~]$ ls > MyDocuments hello hello.c > [gsaid@Bruno ~]$ file hello > hello: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically > linked (uses shared libs), for FreeBSD 8.2, not stripped > [gsaid@Bruno ~]$ ./hello > Hello, World! > > The following is the example of the error when compiling in 32-bit on a > 64-bit machine: > > [gsaid@Bruno ~]$ gcc -m32 -o hello hello.c > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for > -lgcc > /usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for > -lgcc > /usr/bin/ld: cannot find -lgcc > > This is my Hello World script: > > [gsaid@Bruno ~]$ cat hello.c > #include > > int main(int argc, char **argv) > { > printf("Hello, World!\n"); > return 0; > } > > I have also tried adding "WITH_LIB32=yes" to /etc/make.conf and compiled and > installed the kernel again. > > When I locate for libgcc.a to see if there is a one for 32-bit, only one is > found and it is of 64-bit > > [gsaid@Bruno /]$ locate libgcc.a > /usr/lib/libgcc.a > [gsaid@Bruno /]$ nm /usr/lib/libgcc.a > > __gcc_bcmp.o: > 0000000000000000 T __gcc_bcmp Please see this thread from March: http://lists.freebsd.org/pipermail/freebsd-stable/2011-March/thread.html#61846 Though I believe you already have. Why do I say that? Because you started a thread a couple days ago which was actually a *reply* to the aforementioned thread in March (and all you did was change the Subject line). Here's how I know that: 1186 03/09 15:15 Thomas David Rivers (1.0K) bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)? 1187 03/09 12:52 Josh Carroll (0.8K) |-> 1188 03/09 22:44 Matthias Andree (1.0K) | `-> 1189 03/09 14:55 Mark Linimon (0.5K) |-> 1190 03/09 16:08 Thomas David Rivers (0.4K) | `-> 1191 03/15 00:16 Dimitry Andric (1.1K) |-> 1192 08/23 00:26 noel beck (0.7K) `->-m32 on freeBSD 8.2r amd64 1193 08/23 14:46 Edho Arief (0.6K) `-> 1194 08/24 13:11 Michael Hoffmann (1.4K) `-> 1195 08/24 13:57 Tom Evans (1.1K) `-> 1196 s 08/24 16:01 Kostik Belousov (1.6K) `-> Your mail on 08/23 has these lines in it, which act as validation that you replied to an earlier thread (from March) and tried to start your own: >> In-Reply-To: <201103092015.p29KFd0U077849@dave.dignus.com> >> References: <201103092015.p29KFd0U077849@dave.dignus.com> Anyway, did you read any of the replies from Edho, Michael, Tom, and Kostik? They all provide insights and answers to your question. Next: there is no WITH_LIB32. There is only WITHOUT_LIB32. Furthermore, that setting goes in /etc/src.conf not /etc/make.conf. Yes there is a difference (you need to familiarise yourself with 8.x and later; take the time. :-) ). man src.conf. Next, yet related: even if there was a WITH_LIB32, rebuilding the **kernel** would not solve anything. You would need to build world. But again, there is no WITH_LIB32. If you build world on amd64 it will, by default, attempt to build 32-bit versions of libraries so that you can compile i386 binaries on amd64. The kernel shims for 32-bit support on amd64 is a kernel option in your kernel config called COMPAT_FREEBSD32. This would allow the kernel to support 32-bit applications; it doesn't have anything to do with userland libraries (32-bit libc, etc.). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 18:26:08 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E751106566B for ; Thu, 25 Aug 2011 18:26:08 +0000 (UTC) (envelope-from utisoft@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 179B28FC0A for ; Thu, 25 Aug 2011 18:26:07 +0000 (UTC) Received: by gwb15 with SMTP id 15so2372884gwb.13 for ; Thu, 25 Aug 2011 11:26: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pozPNoH1XiQgXNdivUqHKBD/U+PK1eG2NrDU34NBzyw=; b=bFalVIq8x5jFh/ZYSk075g/QJ8CsSYm9OinAxNF95o6oQ5LD6B9nZSs+VXluvwzY+N wOFS2rTuNN+LofN6myL99GGOgbq7bM3UXAQl/4gD6WG0JH/WOHFmwTO04DkQ9zfitZ6R k1Ym1I7QeR/V/aFBWgeK68I0UTkhlyDwv0rfE= Received: by 10.231.4.3 with SMTP id 3mr38975ibp.72.1314294914113; Thu, 25 Aug 2011 10:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.42.4 with HTTP; Thu, 25 Aug 2011 10:54:43 -0700 (PDT) In-Reply-To: <4e55153e.Tj16zX3SskfuVesE%perryh@pluto.rain.com> References: <1B4FC0D8-60E6-49DA-BC52-688052C4DA51@langille.org> <20110819232125.GA4965@icarus.home.lan> <20110820032438.GA21925@icarus.home.lan> <4774BC00-F32B-4BF4-A955-3728F885CAA1@langille.org> <4E4FF4D6.1090305@os2.kiev.ua> <20110820183456.GA38317@icarus.home.lan> <4e50c931.gCNlQFqn5sVQXXax%perryh@pluto.rain.com> <20110821050051.GA47415@icarus.home.lan> <4e5141dd.mmh6t9R/knnc8Jll%perryh@pluto.rain.com> <4e55153e.Tj16zX3SskfuVesE%perryh@pluto.rain.com> From: Chris Rees Date: Thu, 25 Aug 2011 18:54:43 +0100 Message-ID: To: perryh@pluto.rain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vincepoy@gmail.com, freebsd-stable@freebsd.org, freebsd-ports@freebsd.org, freebsd@jdc.parodius.com Subject: Re: ports/sysutils/diskcheckd (Re: bad sector in gmirror HDD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 18:26:08 -0000 On 24 August 2011 16:14, wrote: >> When the specified or calculated rate exceeds 64KB/sec, the >> required sleep interval between 64KB chunks is less than one >> second. =A0Since diskcheckd calculates the interval in whole seconds >> -- because it calls sleep() rather than usleep() or nanosleep() >> -- an interval of less than one second is calculated as zero ... >> I suspect the fix will be to calculate in microseconds, and call >> usleep() instead of sleep(). > > I think I may have this fixed. > > Could one of you try the attached patch? =A0I'm especially interested > to see if this also clears up the issues reported as connected with > gmirror (http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/143566), > since I haven't been able to reproduce that part here. > > Summary of changes: > > * Calculate delays in microseconds, so that delays of less than > =A0one second between reads (needed to implement rates exceeding > =A064KB/sec) do not get rounded down to zero. > > * Fix a reinitialization problem when handling SIGHUP. > > * Additional debug messages (only with -d). > > * Comment and manpage improvememts. > Hi Perry, The changes look good, so if there's no response for a few days I'll commit the changes. Thanks for rescuing the port :) Chris --=20 Chris Rees =A0 =A0 =A0 =A0 =A0| FreeBSD Developer crees@FreeBSD.org =A0 | http://people.freebsd.org/~crees From owner-freebsd-stable@FreeBSD.ORG Thu Aug 25 23:35:50 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC173106564A for ; Thu, 25 Aug 2011 23:35:50 +0000 (UTC) (envelope-from lists@hurricane-ridge.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 8DEA58FC08 for ; Thu, 25 Aug 2011 23:35:50 +0000 (UTC) Received: by pzk33 with SMTP id 33so7561933pzk.18 for ; Thu, 25 Aug 2011 16:35:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.141.19 with SMTP id o19mr160612wfd.225.1314313454862; Thu, 25 Aug 2011 16:04:14 -0700 (PDT) Received: by 10.68.48.103 with HTTP; Thu, 25 Aug 2011 16:04:14 -0700 (PDT) X-Originating-IP: [24.16.138.126] In-Reply-To: <20110825121553.53e8f728.gerrit@pmp.uni-hannover.de> References: <20110825121553.53e8f728.gerrit@pmp.uni-hannover.de> Date: Thu, 25 Aug 2011 16:04:14 -0700 Message-ID: From: Andrew Leonard To: gerrit.kuehn@aei.mpg.de, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Fw: zfs snapshot: Bad file descriptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 23:35:50 -0000 2011/8/25 Gerrit K=FChn > Sorry for crossposting, but I got no answer at all from freebsd-fs. Anyon= e > in here having any ideas/suggestions on this? Is this the same thing as kern/156781? -Andy > > Begin forwarded message: > > Date: Tue, 23 Aug 2011 17:02:55 +0200 > From: Gerrit K=FChn > To: freebsd-fs@freebsd.org > Subject: zfs snapshot: Bad file descriptor > > > Hi all, > > since upgrading some of my storage machines to recent 8.2-stable and > zfs-v28 I see the following on some filesystems after some time of > operation: > > --- > mclane# ll /tank/home/pt/.zfs > ls: snapshot: Bad file descriptor > total 0 > --- > > > I make quite heavy use of snapshots on all my machines and use rsync to > backup snapshots to other machines. > Googleing around I found several people reporting similar problems, but n= o > real solution (apart from rebooting, which is not really a thing you want > to do every time you run into this). > Is there any knowledge/ideas available over the list here how to improve > this situation? Am I just one of the few unlucky people who see this, or = is > there an actual reason for this happening that could be fixed or > circumvented? > > > cu > =A0Gerrit > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 04:51:04 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BAEA106566B for ; Sat, 27 Aug 2011 04:51:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 215708FC18 for ; Sat, 27 Aug 2011 04:51:03 +0000 (UTC) Received: by ywo32 with SMTP id 32so4107118ywo.13 for ; Fri, 26 Aug 2011 21:51:03 -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=j0B7ulgdCWEoO5c2nBWNJrF1RkFTSr7xq7FW9ieHdoc=; b=sK8sVqrDDpNob6EEUbpwV8tD6lB/UZ3HaJQ/LexPYG1J8KDXoZaIQC6vNHsDM9PVVQ gJ3f/6bc/LKj/QavMzgsBoBmUmVZqXLX/i6wMyUIPV6HYGJl0PNk3uGxO4CaNntPapu1 Y7cAsJUn8C68qASK3CYbGkDo21676YzZDbsxg= MIME-Version: 1.0 Received: by 10.231.48.11 with SMTP id p11mr3982276ibf.57.1314420663209; Fri, 26 Aug 2011 21:51:03 -0700 (PDT) Received: by 10.231.149.204 with HTTP; Fri, 26 Aug 2011 21:51:02 -0700 (PDT) Date: Fri, 26 Aug 2011 21:51:02 -0700 Message-ID: From: Kevin Oberman To: "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=ISO-8859-1 Subject: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 04:51:04 -0000 I've run into an odd problem with dismounting file systems on a Seagate Expansion portable USB drive. Running 8-stable on an amd64 system and with two FAT32 (msdosfs) file systems on the drive. The drive is "green" and spins down when idle. If an attempt is made to shutdown the system while the drive is spun down, the system goes through the usual shutdown including flushing all buffer out to disk, but when the final disk access to mark the file systems as clean, the drive never spins up and the system hangs until it is powered down. I've found no way to avoid this other then to remember to access the disk and cause it to spin up before shutting down. If I attempt to unmount the file systems when the drive is shut down. the same thing happens, but I can recover as the second file system is still mounted and an ls(1) to that file system will cause the disk to spin up and everything is fine. This looks like a bug, but I don't see why the unmounting of an msdosfs system does not spin up the drive. It's clearly hanging on some operation that is not spinning up the drive, but does block. Any ideas what is going on? Possible fix? -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 06:19:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1FD106564A for ; Sat, 27 Aug 2011 06:19:57 +0000 (UTC) (envelope-from ulf@alameda.net) Received: from mail.alameda.net (mail.alameda.net [194.55.105.10]) by mx1.freebsd.org (Postfix) with ESMTP id 353458FC08 for ; Sat, 27 Aug 2011 06:19:56 +0000 (UTC) Received: by mail.alameda.net (Postfix, from userid 1000) id D74151CC70; Fri, 26 Aug 2011 22:49:28 -0700 (PDT) Date: Fri, 26 Aug 2011 22:49:28 -0700 From: Ulf Zimmermann To: Kevin Oberman Message-ID: <20110827054928.GF19016@evil.alameda.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 5.5-PRERELEASE X-ANI-MailScanner-Information: Please contact the ISP for more information X-ANI-MailScanner-ID: D74151CC70.A494F X-ANI-MailScanner: Found to be clean X-ANI-MailScanner-From: ulf@alameda.net Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ulf@Alameda.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 06:19:57 -0000 On Fri, Aug 26, 2011 at 09:51:02PM -0700, Kevin Oberman wrote: > I've run into an odd problem with dismounting file systems on a > Seagate Expansion portable > USB drive. Running 8-stable on an amd64 system and with two FAT32 > (msdosfs) file systems > on the drive. > > The drive is "green" and spins down when idle. If an attempt is made > to shutdown the > system while the drive is spun down, the system goes through the usual > shutdown including > flushing all buffer out to disk, but when the final disk access to > mark the file systems as > clean, the drive never spins up and the system hangs until it is > powered down. I've found no > way to avoid this other then to remember to access the disk and cause > it to spin up before > shutting down. > > If I attempt to unmount the file systems when the drive is shut down. > the same thing > happens, but I can recover as the second file system is still mounted > and an ls(1) to that file > system will cause the disk to spin up and everything is fine. > > This looks like a bug, but I don't see why the unmounting of an > msdosfs system does not > spin up the drive. It's clearly hanging on some operation that is not > spinning up the drive, > but does block. > > Any ideas what is going on? Possible fix? > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6558@gmail.com Have a script, which gets run at shutdown as one of the first ones, which would do a ls on the filesystem to wake the drive up. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 07:00:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC231065670 for ; Sat, 27 Aug 2011 07:00:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33A758FC16 for ; Sat, 27 Aug 2011 07:00:14 +0000 (UTC) Received: by gxk28 with SMTP id 28so4176185gxk.13 for ; Sat, 27 Aug 2011 00:00:14 -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=3RNhurGEqvYFJ4TeJ9NfcVuhs+UT37G4KsLU1oLnEIA=; b=jcZBv6dPScfFhVIxvlNsb67tcEsj/wXNmHKNQVhbbAUu85U1FPIJTaPBUYNyuHe5Fy 8CgA6nHwKP8RhGZ70zmKwij0SluEhva8AwwQHK7omC8bzdaFx+YN40gr+8KFcOLYk38j /FwxwT6O3845OTw4n4YeQxGwpjMxBjxAkRzL0= MIME-Version: 1.0 Received: by 10.150.238.17 with SMTP id l17mr2856802ybh.144.1314428414505; Sat, 27 Aug 2011 00:00:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.145.21 with HTTP; Sat, 27 Aug 2011 00:00:14 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Aug 2011 15:00:14 +0800 X-Google-Sender-Auth: Vc-NKcX3qAwOVyNkP6oXEvhv8kE Message-ID: From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 07:00:15 -0000 This sounds like a "create PR and make noise until it's fixed" issue. :-) green drives are only going to get more prevalent.. Adrian On 27 August 2011 12:51, Kevin Oberman wrote: > I've run into an odd problem with dismounting file systems on a > Seagate Expansion portable > USB drive. Running 8-stable on an amd64 system and with two FAT32 > (msdosfs) file systems > on the drive. > > The drive is "green" and spins down when idle. =A0If an attempt is made > to shutdown the > system while the drive is spun down, the system goes through the usual > shutdown including > flushing all buffer out to disk, but when the final disk access to > mark the file systems as > clean, the drive never spins up and the system hangs until it is > powered down. I've found no > way to avoid this other then to remember to access the disk and cause > it to spin up before > shutting down. > > If I attempt to unmount the file systems when the drive is shut down. > the same thing > happens, but I can recover as the second file system is still mounted > and an ls(1) to that file > system will cause the disk to spin up and everything is fine. > > This looks like a bug, but I don't see why the unmounting of an > msdosfs system does not > spin up the drive. It's clearly hanging on some operation that is not > spinning up the drive, > but does block. > > Any ideas what is going on? Possible fix? > -- > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6558@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 14:25:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13F5C1065673 for ; Sat, 27 Aug 2011 14:25:38 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id A9D418FC15 for ; Sat, 27 Aug 2011 14:25:37 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 0CC801DD761; Sat, 27 Aug 2011 16:25:37 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id EA72317496; Sat, 27 Aug 2011 16:25:36 +0200 (CEST) Date: Sat, 27 Aug 2011 16:25:36 +0200 From: Jilles Tjoelker To: Kostik Belousov Message-ID: <20110827142536.GA66167@stack.nl> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> <20110824212929.GC17489@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110824212929.GC17489@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Slawa Olhovchenkov Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 14:25:38 -0000 On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: > On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > > up in r219709). The discussion started at > > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004892.html > > > > Solaris is simply wrong in the same way we were wrong. Although POSIX > > may not be as clear on this as one may like, its intention is clear and > > additionally not returning EINTR reduces subtle portability problems. > Can you, please, describe why do you consider the behaviour prohibiting > return of EINTR reasonable ? I do consider that the Solaris behaviour is > useful. Applications need to cope with EINTR returns (usually by retrying the call); if they do not do this, bugs arise in uncommon cases. In the case of sigwait(), applications do not really need EINTR: they can include the respective signal into the signal set and do the work inline that was originally in the signal handler. This might require additional pthread_sigmask() calls. This also fixes the race condition almost always associated with EINTR. Historically, this is because sigwait() came with POSIX threads, which also explains why it returns an error number rather than setting errno. The threads group considered EINTR errors not useful enough, given that they may lead to subtle bugs. This is fully standardized for functions like pthread_cond_wait() and pthread_mutex_lock(). In the case of sigwait(), it also plays a role that glibc has decided not to return EINTR, so that returning EINTR may lead to subtle bugs appearing on FreeBSD in software originally written for GNU/Linux. The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime and therefore follow different conventions. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 15:11:09 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DEE106567A for ; Sat, 27 Aug 2011 15:11:09 +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 5A38F8FC0C for ; Sat, 27 Aug 2011 15:11:08 +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 p7RF7Jqf003192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2011 18:07:19 +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 p7RF7JVB034676; Sat, 27 Aug 2011 18:07:19 +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 p7RF7JBd034675; Sat, 27 Aug 2011 18:07:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 27 Aug 2011 18:07:19 +0300 From: Kostik Belousov To: Jilles Tjoelker Message-ID: <20110827150719.GJ17489@deviant.kiev.zoral.com.ua> References: <20110824181907.GA48394@zxy.spb.ru> <20110824190703.GY17489@deviant.kiev.zoral.com.ua> <20110824205609.GA96070@stack.nl> <20110824212929.GC17489@deviant.kiev.zoral.com.ua> <20110827142536.GA66167@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5HcqcVqIBwN2S5gT" Content-Disposition: inline In-Reply-To: <20110827142536.GA66167@stack.nl> 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 Cc: freebsd-stable@freebsd.org, Slawa Olhovchenkov Subject: Re: sigwait return 4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 15:11:10 -0000 --5HcqcVqIBwN2S5gT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2011 at 04:25:36PM +0200, Jilles Tjoelker wrote: > On Thu, Aug 25, 2011 at 12:29:29AM +0300, Kostik Belousov wrote: > > On Wed, Aug 24, 2011 at 10:56:09PM +0200, Jilles Tjoelker wrote: > > > sigwait() was fixed not to return EINTR in 9-current in r212405 (fixed > > > up in r219709). The discussion started at > > > http://lists.freebsd.org/pipermail/freebsd-threads/2010-September/004= 892.html > > >=20 > > > Solaris is simply wrong in the same way we were wrong. Although POSIX > > > may not be as clear on this as one may like, its intention is clear a= nd > > > additionally not returning EINTR reduces subtle portability problems. >=20 > > Can you, please, describe why do you consider the behaviour prohibiting > > return of EINTR reasonable ? I do consider that the Solaris behaviour is > > useful. >=20 > Applications need to cope with EINTR returns (usually by retrying the > call); if they do not do this, bugs arise in uncommon cases. >=20 > In the case of sigwait(), applications do not really need EINTR: they > can include the respective signal into the signal set and do the work > inline that was originally in the signal handler. This might require > additional pthread_sigmask() calls. This also fixes the race condition > almost always associated with EINTR. >=20 > Historically, this is because sigwait() came with POSIX threads, which > also explains why it returns an error number rather than setting errno. > The threads group considered EINTR errors not useful enough, given that > they may lead to subtle bugs. This is fully standardized for functions > like pthread_cond_wait() and pthread_mutex_lock(). >=20 > In the case of sigwait(), it also plays a role that glibc has decided > not to return EINTR, so that returning EINTR may lead to subtle bugs > appearing on FreeBSD in software originally written for GNU/Linux. >=20 > The functions sigwaitinfo() and sigtimedwait() came with POSIX realtime > and therefore follow different conventions. I think I finally realized what was the problem Slawa searched the fix for. The fix from r212405 indeed does not allow EINTR to be returned from the sigwait() for new libc, but it still leaves the compat libc and libthr with EINTR. Below is the patch that I provided to Slawa to handle EINTR condition in kernel. The meat is in kern_sig.c two lines, everything else is the r212405 revert. diff --git a/lib/libc/sys/Makefile.inc b/lib/libc/sys/Makefile.inc index fe5061d..aa0959b 100644 --- a/lib/libc/sys/Makefile.inc +++ b/lib/libc/sys/Makefile.inc @@ -24,9 +24,6 @@ SRCS+=3D ${SYSCALL_COMPAT_SRCS} NOASM+=3D ${SYSCALL_COMPAT_SRCS:S/.c/.o/} PSEUDO+=3D _fcntl.o .endif -SRCS+=3D sigwait.c -NOASM+=3D sigwait.o -PSEUDO+=3D _sigwait.o =20 # Add machine dependent asm sources: SRCS+=3D${MDASM} diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map index 095751a..2ba1f8f 100644 --- a/lib/libc/sys/Symbol.map +++ b/lib/libc/sys/Symbol.map @@ -937,7 +937,6 @@ FBSDprivate_1.0 { _sigtimedwait; __sys_sigtimedwait; _sigwait; - __sigwait; __sys_sigwait; _sigwaitinfo; __sys_sigwaitinfo; diff --git a/lib/libc/sys/sigwait.c b/lib/libc/sys/sigwait.c deleted file mode 100644 index 2fdffdd..0000000 --- a/lib/libc/sys/sigwait.c +++ /dev/null @@ -1,46 +0,0 @@ -/*- - * Copyright (c) 2010 davidxu@freebsd.org - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * 1. Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * 2. Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP= OSE - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT= IAL - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR= ICT - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W= AY - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF - * SUCH DAMAGE. - */ - -#include -__FBSDID("$FreeBSD$"); - -#include -#include - -int __sys_sigwait(const sigset_t * restrict, int * restrict); - -__weak_reference(__sigwait, sigwait); - -int -__sigwait(const sigset_t * restrict set, int * restrict sig) -{ - int ret; - - /* POSIX does not allow EINTR to be returned */ - do { - ret =3D __sys_sigwait(set, sig); - } while (ret =3D=3D EINTR); - return (ret); -} diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c index 66358db..daf1871 100644 --- a/lib/libthr/thread/thr_sig.c +++ b/lib/libthr/thread/thr_sig.c @@ -67,7 +67,7 @@ int _sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec * timeout); int __sigwaitinfo(const sigset_t *set, siginfo_t *info); int _sigwaitinfo(const sigset_t *set, siginfo_t *info); -int ___sigwait(const sigset_t *set, int *sig); +int __sigwait(const sigset_t *set, int *sig); int _sigwait(const sigset_t *set, int *sig); int __sigsuspend(const sigset_t *sigmask); int _sigaction(int, const struct sigaction *, struct sigaction *); @@ -628,7 +628,7 @@ __sigsuspend(const sigset_t * set) return (ret); } =20 -__weak_reference(___sigwait, sigwait); +__weak_reference(__sigwait, sigwait); __weak_reference(__sigtimedwait, sigtimedwait); __weak_reference(__sigwaitinfo, sigwaitinfo); =20 @@ -702,17 +702,15 @@ _sigwait(const sigset_t *set, int *sig) * it is not canceled. */=20 int -___sigwait(const sigset_t *set, int *sig) +__sigwait(const sigset_t *set, int *sig) { struct pthread *curthread =3D _get_curthread(); sigset_t newset; int ret; =20 - do { - _thr_cancel_enter(curthread); - ret =3D __sys_sigwait(thr_remove_thr_signals(set, &newset), sig); - _thr_cancel_leave(curthread, (ret !=3D 0)); - } while (ret =3D=3D EINTR); + _thr_cancel_enter(curthread); + ret =3D __sys_sigwait(thr_remove_thr_signals(set, &newset), sig); + _thr_cancel_leave(curthread, (ret !=3D 0)); return (ret); } =20 diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 26ef0d7..4655246 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -1094,6 +1094,8 @@ sigwait(struct thread *td, struct sigwait_args *uap) =20 error =3D kern_sigtimedwait(td, set, &ksi, NULL); if (error) { + if (error =3D=3D EINTR) + error =3D ERESTART; if (error =3D=3D ERESTART) return (error); td->td_retval[0] =3D error; --5HcqcVqIBwN2S5gT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk5ZCCYACgkQC3+MBN1Mb4hAywCeJRxVlNjJccjxcpeoJaP3R/Vx RP8Anj0Gwn+W1hc2WKdYs0kWewzfypcU =mEV+ -----END PGP SIGNATURE----- --5HcqcVqIBwN2S5gT-- From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 16:21:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 953291065672 for ; Sat, 27 Aug 2011 16:21:47 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.freebsd.org (Postfix) with ESMTP id 541D28FC12 for ; Sat, 27 Aug 2011 16:21:47 +0000 (UTC) Received: from [212.182.167.131] (helo=sjakie.klop.ws) by smtp-out2.tiscali.nl with esmtp (Exim) (envelope-from ) id 1QxLdi-0007OV-Br for freebsd-stable@freebsd.org; Sat, 27 Aug 2011 18:21:46 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id B18483822 for ; Sat, 27 Aug 2011 18:21:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Sat, 27 Aug 2011 18:21:43 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/11.50 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: portsnap doesn't update INDEX-9? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:21:47 -0000 Hi, I just upgraded to -CURRENT two weeks ago (and did a clean install at wor= k =20 last week). Is it normal if /usr/ports/INDEX-9 doesn't update after =20 running portsnap? INDEX-7 and INDEX-8 are updated automatically. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 16:42:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2348B1065672 for ; Sat, 27 Aug 2011 16:42:44 +0000 (UTC) (envelope-from dart@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 007D58FC08 for ; Sat, 27 Aug 2011 16:42:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=es.net; h=message-id : date : from : reply-to : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=es.net; bh=3/PaNLOtVlO33rhmIaPe/TdUoRLD/1YqGGJj6Ll/h/U=; b=IJCWM2GktfPYyAyrb9r1DKS4Hxx9L+yvQ+nEyAM85nZVymv8M94ww8frRO5ZwvBx0ONY CuH88HXq9rxePbxHmJi6NPxXQjVf9vrEITUsB8GYODhavVo1aJI8FnD/gtut4sIO7TkN 5DvuepVcXXNMkWQG9iBlqxoCaBykOCl/3y4= Received: from MacBook-Pro-1597.local (c-24-6-230-73.hsd1.ca.comcast.net [24.6.230.73]) (authenticated bits=0) by mailgw.es.net (8.14.5/8.14.5) with ESMTP id p7RGggwA008756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Aug 2011 09:42:43 -0700 Message-ID: <4E591E81.7040801@es.net> Date: Sat, 27 Aug 2011 09:42:41 -0700 From: Eli Dart Organization: Energy Sciences Network User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Kevin Oberman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-26_06:2011-08-27, 2011-08-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108270170 Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Unable to shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dart@es.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:42:44 -0000 This sounds like it may have the same underlying cause as an issue I've been experiencing. Steps to reproduce: 1) Mount filesystem (Seagate 2TB USB disk) 2) wait a while, so the drive spins down 3) cd to a directory off the root of the mount point (the thing we're looking for here is a directory that is already in the filesystem buffer cache because of the filesystem mount). We want a directory that is not empty. 4) ls 5) ls will hang for a while as the drive spins up (this is to be expected) 6) ls returns nothing We now have a problem. The kernel thinks the directory is empty, even when its not. The drive is spun up now, and the rest of the filesystem will function normally, but that one directory will be considered empty by the kernel until it has reason to interact with disk (which means writing to the directory). Once the directory is written, its now corrupt. My guess is that there is something in the USB subsystem that doesn't deal well with the longer times necessary for bigger drives to spin back up (this is not a problem on 1TB drives). A workaround is to have little script that does a dd from the raw device to /dev/null before attempting to access the drive - this will ensure that its spun up. Needless to say, this doesn't work at all well for some production operations (e.g. rsync backup to USB disk), where disk I/O can cease for long enough for the drive to spin down in the middle of the job. --eli On 8/26/11 9:51 PM, Kevin Oberman wrote: > I've run into an odd problem with dismounting file systems on a > Seagate Expansion portable > USB drive. Running 8-stable on an amd64 system and with two FAT32 > (msdosfs) file systems > on the drive. > > The drive is "green" and spins down when idle. If an attempt is made > to shutdown the > system while the drive is spun down, the system goes through the usual > shutdown including > flushing all buffer out to disk, but when the final disk access to > mark the file systems as > clean, the drive never spins up and the system hangs until it is > powered down. I've found no > way to avoid this other then to remember to access the disk and cause > it to spin up before > shutting down. > > If I attempt to unmount the file systems when the drive is shut down. > the same thing > happens, but I can recover as the second file system is still mounted > and an ls(1) to that file > system will cause the disk to spin up and everything is fine. > > This looks like a bug, but I don't see why the unmounting of an > msdosfs system does not > spin up the drive. It's clearly hanging on some operation that is not > spinning up the drive, > but does block. > > Any ideas what is going on? Possible fix? -- Eli Dart NOC: (510) 486-7600 ESnet Network Engineering Group (AS293) (800) 333-7638 Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From owner-freebsd-stable@FreeBSD.ORG Sat Aug 27 16:43:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4DB61065670 for ; Sat, 27 Aug 2011 16:43:47 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out0.tiscali.nl (smtp-out0.tiscali.nl [195.241.79.175]) by mx1.freebsd.org (Postfix) with ESMTP id 724368FC27 for ; Sat, 27 Aug 2011 16:43:47 +0000 (UTC) Received: from [212.182.167.131] (helo=sjakie.klop.ws) by smtp-out0.tiscali.nl with esmtp (Exim) (envelope-from ) id 1QxLz0-0003bc-Cz for freebsd-stable@freebsd.org; Sat, 27 Aug 2011 18:43:46 +0200 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 9D75F38E2 for ; Sat, 27 Aug 2011 18:43:43 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: Date: Sat, 27 Aug 2011 18:43:43 +0200 MIME-Version: 1.0 From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (FreeBSD) Content-Transfer-Encoding: quoted-printable Subject: Re: portsnap doesn't update INDEX-9? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:43:47 -0000 On Sat, 27 Aug 2011 18:21:43 +0200, Ronald Klop =20 wrote: > Hi, > > I just upgraded to -CURRENT two weeks ago (and did a clean install at =20 > work last week). Is it normal if /usr/ports/INDEX-9 doesn't update afte= r =20 > running portsnap? > INDEX-7 and INDEX-8 are updated automatically. > > Ronald. http://www.freebsd.org/cgi/query-pr.cgi?pr=3D149232 --- Crap. First search, then search again, then post to the mailinglist. Not = =20 the other way around.