From owner-freebsd-hackers@freebsd.org Sun Aug 2 00:09:46 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 969EC9B1860 for ; Sun, 2 Aug 2015 00:09:46 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 607351AF7 for ; Sun, 2 Aug 2015 00:09:45 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t7209jk6078206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 17:09:45 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t7209jsv078205; Sat, 1 Aug 2015 17:09:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 1 Aug 2015 17:09:45 -0700 From: John-Mark Gurney To: Patrick Mooney Cc: freebsd-hackers@freebsd.org Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Message-ID: <20150802000945.GL78154@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 01 Aug 2015 17:09:45 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 00:09:46 -0000 Patrick Mooney wrote this message on Fri, Jul 31, 2015 at 13:20 -0500: > I have been researching differences in recvmsg() behavior across platforms > (namely Illumos and Linux) with respect to MSG_PEEK and 0-length buffers. > Certain Linux software I am attempting to run under Illumos makes a recvmsg() > call with a 0-length iovec and flags set to MSG_PEEK in order to interrogate > the size of a queued dgram. On native Linux, recvmsg() returns the size of the > queued dgram (with the MSG_TRUNC flag set). On both Illumos and FreeBSD, a > size of 0 is returned (with MSG_TRUNC set as well). In reading the POSIX spec > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html), it is > not clear that returning 0 in this case is correct behavior. I agree... These two statements conflict with each other in this case: The recvmsg() function shall return the total length of the message. For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the entire message shall be read in a single operation. If you can't read an entire message (since MSG_PEEK is set, and we can't discard the bytes) per second statement, and excess bytes are not allowed to be discard per next sentence, returning zero seems correct, since you aren't reading a message... Though the return values and errno list doesn't specify this type of return... Feel free to ask the opengroup. They have forums to clarify unclear parts of the spec... Probing to find out how large a message is is bad programming practice.. You should choose a buffer that is large enough for most messages, and increase when it doesn't work... If you do this every time, you're now doing 2x syscalls which will have performance/battery life impacts as you're doing more work than is necessary... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Sun Aug 2 01:10:49 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E781F9A546A for ; Sun, 2 Aug 2015 01:10:48 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D165CD3 for ; Sun, 2 Aug 2015 01:10:48 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from [10.20.30.64] (75-101-82-48.static.sonic.net [75.101.82.48]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSF00K6ZKLDOU00@nk11p03mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Sun, 02 Aug 2015 01:10:28 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-01_02:2015-07-31,2015-08-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508020018 References: <20150802000945.GL78154@funkthat.com> In-reply-to: <20150802000945.GL78154@funkthat.com> MIME-version: 1.0 (1.0) Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=utf-8 Message-id: <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> Cc: Patrick Mooney , "freebsd-hackers@freebsd.org" X-Mailer: iPad Mail (12H143) From: Jordan Hubbard Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Date: Sat, 01 Aug 2015 18:10:24 -0700 To: John-Mark Gurney X-Mailman-Approved-At: Sun, 02 Aug 2015 01:42:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 01:10:49 -0000 One obvious approach might be to run Patrick's test case on a OS X system, s= ince it's one of the very few remaining (still living) UNIX=E2=84=A2 platfor= ms that has to pass the official (and really large) Unix Conformance test su= ite. Whatever OS X's behavior is, arguably right or wrong, you'll at least k= now that TOG signed off on it. - Jordan=20 Sent from my iPad > On Aug 1, 2015, at 17:09, John-Mark Gurney wrote: >=20 > Patrick Mooney wrote this message on Fri, Jul 31, 2015 at 13:20 -0500: >> I have been researching differences in recvmsg() behavior across platform= s >> (namely Illumos and Linux) with respect to MSG_PEEK and 0-length buffers.= >> Certain Linux software I am attempting to run under Illumos makes a recvm= sg() >> call with a 0-length iovec and flags set to MSG_PEEK in order to interrog= ate >> the size of a queued dgram. On native Linux, recvmsg() returns the size o= f the >> queued dgram (with the MSG_TRUNC flag set). On both Illumos and FreeBSD,= a >> size of 0 is returned (with MSG_TRUNC set as well). In reading the POSIX= spec >> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html),= it is >> not clear that returning 0 in this case is correct behavior. >=20 > I agree... These two statements conflict with each other in this case: > The recvmsg() function shall return the total length of the message. > For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the > entire message shall be read in a single operation. >=20 > If you can't read an entire message (since MSG_PEEK is set, and we can't > discard the bytes) per second statement, and excess bytes are not allowed > to be discard per next sentence, returning zero seems correct, since you > aren't reading a message... Though the return values and errno list > doesn't specify this type of return... >=20 > Feel free to ask the opengroup. They have forums to clarify unclear > parts of the spec... >=20 > Probing to find out how large a message is is bad programming practice.. > You should choose a buffer that is large enough for most messages, > and increase when it doesn't work... If you do this every time, you're > now doing 2x syscalls which will have performance/battery life impacts > as you're doing more work than is necessary... >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Sun Aug 2 03:49:47 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21B569AF2CB for ; Sun, 2 Aug 2015 03:49:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC6CBAED for ; Sun, 2 Aug 2015 03:49:46 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t723nktq081107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 20:49:46 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t723njF4081106; Sat, 1 Aug 2015 20:49:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 1 Aug 2015 20:49:45 -0700 From: John-Mark Gurney To: Jordan Hubbard Cc: Patrick Mooney , "freebsd-hackers@freebsd.org" Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Message-ID: <20150802034945.GN78154@funkthat.com> References: <20150802000945.GL78154@funkthat.com> <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 01 Aug 2015 20:49:46 -0700 (PDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 03:49:47 -0000 Jordan Hubbard wrote this message on Sat, Aug 01, 2015 at 18:10 -0700: > One obvious approach might be to run Patrick's test case on a OS X system, since it's one of the very few remaining (still living) UNIX??? platforms that has to pass the official (and really large) Unix Conformance test suite. Whatever OS X's behavior is, arguably right or wrong, you'll at least know that TOG signed off on it. Ok, I know it's a bit old, but MacOSX 10.7.5: $./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 and NetBSD 6.1.5: # ./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 and OpenBSD 5.7: # ./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 > > On Aug 1, 2015, at 17:09, John-Mark Gurney wrote: > > > > Patrick Mooney wrote this message on Fri, Jul 31, 2015 at 13:20 -0500: > >> I have been researching differences in recvmsg() behavior across platforms > >> (namely Illumos and Linux) with respect to MSG_PEEK and 0-length buffers. > >> Certain Linux software I am attempting to run under Illumos makes a recvmsg() > >> call with a 0-length iovec and flags set to MSG_PEEK in order to interrogate > >> the size of a queued dgram. On native Linux, recvmsg() returns the size of the > >> queued dgram (with the MSG_TRUNC flag set). On both Illumos and FreeBSD, a > >> size of 0 is returned (with MSG_TRUNC set as well). In reading the POSIX spec > >> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html), it is > >> not clear that returning 0 in this case is correct behavior. > > > > I agree... These two statements conflict with each other in this case: > > The recvmsg() function shall return the total length of the message. > > For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the > > entire message shall be read in a single operation. > > > > If you can't read an entire message (since MSG_PEEK is set, and we can't > > discard the bytes) per second statement, and excess bytes are not allowed > > to be discard per next sentence, returning zero seems correct, since you > > aren't reading a message... Though the return values and errno list > > doesn't specify this type of return... > > > > Feel free to ask the opengroup. They have forums to clarify unclear > > parts of the spec... > > > > Probing to find out how large a message is is bad programming practice.. > > You should choose a buffer that is large enough for most messages, > > and increase when it doesn't work... If you do this every time, you're > > now doing 2x syscalls which will have performance/battery life impacts > > as you're doing more work than is necessary... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@freebsd.org Sun Aug 2 04:15:56 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1693D9AF88D for ; Sun, 2 Aug 2015 04:15:56 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 003D11DD6 for ; Sun, 2 Aug 2015 04:15:55 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from [10.20.30.61] (75-101-82-48.static.sonic.net [75.101.82.48]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSF00BR1T5X8510@nk11p03mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Sun, 02 Aug 2015 04:15:39 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-01_02:2015-07-31,2015-08-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508020073 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Interpretation of POSIX.1-2008 for recvmsg From: Jordan Hubbard In-reply-to: <20150802034945.GN78154@funkthat.com> Date: Sat, 01 Aug 2015 21:15:28 -0700 Cc: "freebsd-hackers@freebsd.org" , Patrick Mooney Content-transfer-encoding: quoted-printable Message-id: <337118A1-5F96-4E7F-A62F-9D586025AE0A@icloud.com> References: <20150802000945.GL78154@funkthat.com> <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> <20150802034945.GN78154@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.2104) X-Mailman-Approved-At: Sun, 02 Aug 2015 11:05:51 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 04:15:56 -0000 > On Aug 1, 2015, at 8:49 PM, John-Mark Gurney wrote: >=20 > Ok, I know it's a bit old, but MacOSX 10.7.5: > $./peektest=20 > peek len: 0 errno: 0 flags: 12 > recv len: 20 errno: 0 flags: 0 I missed Patrick=E2=80=99s reference to his peektest.c program the first = time - whoops - or I=E2=80=99d have just run it myself! On version 10.10.5, x86_64 architecture: jkh@katana-> ./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 So yep, that=E2=80=99s the =E2=80=9Creasonable behavior=E2=80=9D from a = UNIX2003 conformance perspective. - Jordan From owner-freebsd-hackers@freebsd.org Sun Aug 2 11:32:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 279879B17DD for ; Sun, 2 Aug 2015 11:32:04 +0000 (UTC) (envelope-from saper@saper.info) Received: from m.saper.info (m.saper.info [IPv6:2a01:4f8:a0:7383::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "m.saper.info", Issuer "Marcin Cieslak 2011" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B663B1A34 for ; Sun, 2 Aug 2015 11:32:03 +0000 (UTC) (envelope-from saper@saper.info) Received: from m.saper.info (saper@m.saper.info [IPv6:2a01:4f8:a0:7383::]) by m.saper.info (8.14.9/8.14.9) with ESMTP id t72BVxMH029324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Aug 2015 11:31:59 GMT (envelope-from saper@saper.info) Received: from localhost (saper@localhost) by m.saper.info (8.14.9/8.14.9/Submit) with ESMTP id t72BVxVl029262; Sun, 2 Aug 2015 11:31:59 GMT (envelope-from saper@saper.info) X-Authentication-Warning: m.saper.info: saper owned process doing -bs Date: Sun, 2 Aug 2015 11:31:59 +0000 From: Marcin Cieslak To: John-Mark Gurney cc: Jordan Hubbard , "freebsd-hackers@freebsd.org" , Patrick Mooney Subject: Re: Interpretation of POSIX.1-2008 for recvmsg In-Reply-To: <20150802034945.GN78154@funkthat.com> Message-ID: References: <20150802000945.GL78154@funkthat.com> <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> <20150802034945.GN78154@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 11:32:04 -0000 On Sat, 1 Aug 2015, John-Mark Gurney wrote: > Jordan Hubbard wrote this message on Sat, Aug 01, 2015 at 18:10 -0700: > > One obvious approach might be to run Patrick's test case on a OS X system, since it's one of the very few remaining (still living) UNIX??? platforms that has to pass the official (and really large) Unix Conformance test suite. Whatever OS X's behavior is, arguably right or wrong, you'll at least know that TOG signed off on it. > > Ok, I know it's a bit old, but MacOSX 10.7.5: > $./peektest > peek len: 0 errno: 0 flags: 12 > recv len: 20 errno: 0 flags: 0 > > and NetBSD 6.1.5: > # ./peektest > peek len: 0 errno: 0 flags: 12 > recv len: 20 errno: 0 flags: 0 > > and OpenBSD 5.7: > # ./peektest > peek len: 0 errno: 0 flags: 12 > recv len: 20 errno: 0 flags: 0 The results are correct: the peektest.c tries to use a Linux-only extension to recvmsg() - giving MSG_PEEK | MSG_TRUNC as the input flag. ~Marcin From owner-freebsd-hackers@freebsd.org Mon Aug 3 00:14:51 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6678E9B1C49 for ; Mon, 3 Aug 2015 00:14:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3349C1FDA for ; Mon, 3 Aug 2015 00:14:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioea135 with SMTP id a135so129958014ioe.1 for ; Sun, 02 Aug 2015 17:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=cwYWxr0yRyzIs+f1Giamlkgwj2WtvpWCqvXgML6zj10=; b=j4dOT2vzcMdG9ns2P6FIKECZh5jurrJrn1lIcUSPCjYmM55XRp2rXZdl8tcxRyXnkF Ba3a5vsizAIKssWBqErkksA1cyCIhzAuluqJpEJB6H8uLPyYMt6RiS4eFApfitgpCeAS wQB4rM/M7WBZtOnus7St3Tum1hQtCHlSZopM2ARi9CQpCI9NbdwYCph7+NCr1kbKglGO naRi5pbtauUSyY+GGORyadhds3M+prJ1OMzlBHuWQEV9Xd3j0o5Dy9+Cqwitv7XVCgdP 6hfHwBR5D4p1x+bpNwRZxPQTyLAiOXKcjDpzYnmX/Pd7uOYdO9xGlhX8oycbBEUYKIcA PSQQ== MIME-Version: 1.0 X-Received: by 10.107.169.138 with SMTP id f10mr16767156ioj.75.1438560890594; Sun, 02 Aug 2015 17:14:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Sun, 2 Aug 2015 17:14:50 -0700 (PDT) In-Reply-To: <20150613092704.GA37870@brick.home> References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> <20150613092704.GA37870@brick.home> Date: Sun, 2 Aug 2015 17:14:50 -0700 X-Google-Sender-Auth: S4rUOCIkPNcwQlM3XoKhJPkrNqQ Message-ID: Subject: Re: pivot_root() and FreeBSD From: Adrian Chadd To: Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 00:14:51 -0000 Hi, pivotroot would be nice. I'd like to be able to mount an mfs to free up the rootfs on embedded devices, so I can re-write the kernel/rootfs that we booted from. +1, let's get this going. -a On 13 June 2015 at 02:27, Edward Tomasz Napiera=C5=82a = wrote: > On 0303T1751, Dirk-Willem van Gulik wrote: >> I am trying to do, in effect an PXE boot/install on a local volume - and= would like the machine to cut over into normal running without a reboot*. >> >> So effectively I would like to do the equivalent of pivot_root() and per= haps something special for init(8), and then jettison md, nfs and what not. >> >> Is there any way to do this on 10.1 or -current ? Or has anyone recently= done work on Adrian Steinmann his 'Pivot Root for BSD=E2=80=99** ? > > I have something similar in purpose in the works: > > https://reviews.freebsd.org/D2698 > > Perhaps you could take a look to see if it fits your use case? The code > needs a rewrite, but the usage should stay the same. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@freebsd.org Mon Aug 3 03:49:13 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF019B265E for ; Mon, 3 Aug 2015 03:49:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 79314D6B for ; Mon, 3 Aug 2015 03:49:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t733n0K5087120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 2 Aug 2015 20:49:05 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: pivot_root() and FreeBSD To: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> From: Julian Elischer Message-ID: <55BEE4A5.40107@freebsd.org> Date: Mon, 3 Aug 2015 11:48:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 03:49:13 -0000 On 3/4/15 12:51 AM, Dirk-Willem van Gulik wrote: > I am trying to do, in effect an PXE boot/install on a local volume - and would like the machine to cut over into normal running without a reboot*. > > So effectively I would like to do the equivalent of pivot_root() and perhaps something special for init(8), and then jettison md, nfs and what not. > > Is there any way to do this on 10.1 or -current ? Or has anyone recently done work on Adrian Steinmann his 'Pivot Root for BSD’** ? > > Thanks, there is SOME work going on on a similar thing.. It was in the recent project status. https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Root-Remount Also have you tried simply using a small memory filesystem loaded with the kernel? > > Dw. > > > *: the scenario is a set of tests and generation scripts during which there should be no reliance on the network - and where we’d like to avoid a reboot given the state we are bringing the disks and a USB device into.. Thus precluding an NFS mounted install during the test -and- precluding a reboot post install. Yet it is very desirable to have a powercycle use PXE to create a known baseline. > **: http://www.netbsd.org/gallery/presentations/ast/2012_EuroBSDCon/Talk_PivotRoot4BSD.pdf > 2012-10-17: Pivot Root (Kernel Module for NetBSD 6.x 20121017) / http://www.netbsd.org/~ast/patches/pivot_root.tbz_20121017 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > From owner-freebsd-hackers@freebsd.org Mon Aug 3 07:11:56 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A52379B22CC for ; Mon, 3 Aug 2015 07:11:56 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E2141BD3; Mon, 3 Aug 2015 07:11:56 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wicgj17 with SMTP id gj17so91389430wic.1; Mon, 03 Aug 2015 00:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=c5o6VJcLXQeioAdE8RPGveza3rwFwQOmrGPSp/bDqfU=; b=fLcFl0GjcUDTBoeJ6KPZuicm8ECi5PQyO6zSTUh9VSA3jXENJFFvP21aLXrC0NuvUK L0L7LjDbhEulHKdhsN4wxVNZyVgD2DdDDdQCOzKfxw9RCObB2iUgIyZto3R0E5NtLXgu 62S4t9vlTVdYJ/D7dhX8Jlzst+a4ij22ApONaY2f/IiZmr9MzBQSzM7Lkjr++e+tR8Ws XlJBb0Ao2dk/uJv0hEmalgc26ynuxgFLFltYCNj1MGF9KSlg5ZXzVGfgPsvicriYszq6 /gbhqlAJSP7+kPfAKgANzqbgsyyRcNpKQiQThc9WynjHMUL8v/g48g8xno4Ft+DYVJq/ LzZg== X-Received: by 10.180.19.65 with SMTP id c1mr30074893wie.15.1438585914688; Mon, 03 Aug 2015 00:11:54 -0700 (PDT) Received: from brick.home (abpz208.neoplus.adsl.tpnet.pl. [83.8.67.208]) by smtp.gmail.com with ESMTPSA id l2sm12012186wib.11.2015.08.03.00.11.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 00:11:53 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 3 Aug 2015 09:11:50 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Julian Elischer Cc: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org Subject: Re: pivot_root() and FreeBSD Message-ID: <20150803071150.GA6116@brick.home> Mail-Followup-To: Julian Elischer , Dirk-Willem van Gulik , freebsd-hackers@freebsd.org References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> <55BEE4A5.40107@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55BEE4A5.40107@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 07:11:56 -0000 On 0803T1148, Julian Elischer wrote: > On 3/4/15 12:51 AM, Dirk-Willem van Gulik wrote: > > I am trying to do, in effect an PXE boot/install on a local volume - and would like the machine to cut over into normal running without a reboot*. > > > > So effectively I would like to do the equivalent of pivot_root() and perhaps something special for init(8), and then jettison md, nfs and what not. > > > > Is there any way to do this on 10.1 or -current ? Or has anyone recently done work on Adrian Steinmann his 'Pivot Root for BSD’** ? > > > > Thanks, > there is SOME work going on on a similar thing.. It was in the recent > project status. > > https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Root-Remount > > Also have you tried simply using a small memory filesystem loaded with > the kernel? Note that this functionality is kind of broken as well: https://reviews.freebsd.org/D3204 From owner-freebsd-hackers@freebsd.org Mon Aug 3 09:45:18 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E785B9B195D for ; Mon, 3 Aug 2015 09:45:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFB541859 for ; Mon, 3 Aug 2015 09:45:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t739jCDf088372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 3 Aug 2015 02:45:16 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: pivot_root() and FreeBSD To: Adrian Chadd , Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> <55BEE4A5.40107@freebsd.org> <20150803071150.GA6116@brick.home> From: Julian Elischer Message-ID: <55BF3822.7030405@freebsd.org> Date: Mon, 3 Aug 2015 17:45:06 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 09:45:19 -0000 On 8/3/15 3:13 PM, Adrian Chadd wrote: > .. and it won't work for upgrading routers, as the MIPS things don't use loader. it can also be compiled into the kernel... I've done that... a picobsd filesystem linked into the kernel grub can also handle it if grub works on mips. > > On 3 August 2015 at 00:11, Edward Tomasz NapieraÅ‚a wrote: >> On 0803T1148, Julian Elischer wrote: >>> On 3/4/15 12:51 AM, Dirk-Willem van Gulik wrote: >>>> I am trying to do, in effect an PXE boot/install on a local volume - and would like the machine to cut over into normal running without a reboot*. >>>> >>>> So effectively I would like to do the equivalent of pivot_root() and perhaps something special for init(8), and then jettison md, nfs and what not. >>>> >>>> Is there any way to do this on 10.1 or -current ? Or has anyone recently done work on Adrian Steinmann his 'Pivot Root for BSD’** ? >>>> >>>> Thanks, >>> there is SOME work going on on a similar thing.. It was in the recent >>> project status. >>> >>> https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Root-Remount >>> >>> Also have you tried simply using a small memory filesystem loaded with >>> the kernel? >> Note that this functionality is kind of broken as well: >> >> https://reviews.freebsd.org/D3204 >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Aug 3 10:01:55 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A595D9B1DEE for ; Mon, 3 Aug 2015 10:01:55 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 412B37A6; Mon, 3 Aug 2015 10:01:55 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wibud3 with SMTP id ud3so106571821wib.0; Mon, 03 Aug 2015 03:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=N3qkauMJE8xsDFYqo5OlC3QQUxxrP923ZTYU33ry10g=; b=YnUgEw4EKxAIrd1aiASnIFEgkWbsrRlaXkQ1/r9RyMh1IJ5w/wXCePMDGkY0n8uCvJ 8bi0Ni2RAEgpgIeeyfpTg3up3QHtxMM1cR52qsn4w+p0oaqb/mbDKYRqIcgCpd/0YrlU Qd1QG3xBYeBFvbqJhZSB7ITDJ/pV6bp0WdQeVnfquaxhJWQyyS+PPiYdxhtMpglqo+j4 ryOS60cZgsKVoLD89MZxOO8vzbkPpKtluCE3IwkRB98QmcqwOmTAwPFPzObPf/i2jlJH el4y7eiKfN1EQulhFEtuVGa1ZqQilxwEq+eipZiuCpMVDTIXeXd9WqeJ7RLJmjUMUIW5 zp6g== X-Received: by 10.180.84.230 with SMTP id c6mr32349295wiz.32.1438596113330; Mon, 03 Aug 2015 03:01:53 -0700 (PDT) Received: from brick.home (ehz47.neoplus.adsl.tpnet.pl. [83.21.115.47]) by smtp.gmail.com with ESMTPSA id ev2sm12713547wib.21.2015.08.03.03.01.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2015 03:01:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 3 Aug 2015 12:01:48 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Julian Elischer Cc: Adrian Chadd , Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" Subject: Re: pivot_root() and FreeBSD Message-ID: <20150803100148.GA6807@brick.home> Mail-Followup-To: Julian Elischer , Adrian Chadd , Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> <55BEE4A5.40107@freebsd.org> <20150803071150.GA6116@brick.home> <55BF3822.7030405@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55BF3822.7030405@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 10:01:55 -0000 On 0803T1745, Julian Elischer wrote: > On 8/3/15 3:13 PM, Adrian Chadd wrote: > > .. and it won't work for upgrading routers, as the MIPS things don't use loader. > > it can also be compiled into the kernel... > I've done that... a picobsd filesystem linked into the kernel Would be better to just make it work for MIPS :-) How do MIPS machines boot? Are they able to load the kernel and modules? If so, making it load md image shouldn't be that hard - it's just like loading modules, just marking them as non-kld type. From owner-freebsd-hackers@freebsd.org Mon Aug 3 07:13:12 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4D989B2329 for ; Mon, 3 Aug 2015 07:13:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 729DD1D25; Mon, 3 Aug 2015 07:13:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioeg141 with SMTP id g141so136784953ioe.3; Mon, 03 Aug 2015 00:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=GRY8czZpWS6a+RrPoXRPMsc9WyFl5tyubp6Qtn0rlqE=; b=T+C9SPmKXSFRFl9Zu1lOCuApzeACuBoKvCHcHvwfanvTTI4jjG3pqTMqIyX7zP4+OM bKyjBmu5hmcq7+cvmCsG/RD3czZUUV6+11BIGiN/vV6zAiyAt6PkWo9NwANHQAzS4CVW UhqELFOSWlSn6X1XhhzdxzehQe/aCWpisOxVLgC7KKHWzXLUQdseLTzlp3JlARHW5kd0 E/VhtDwlxPjOBd9/CBTdCGZWLJFHbmX0jTjuaxs3ljXRVlyVVc3uidXRJJgd8NDiyxlU m6Z8MDyZFqDFw8tJW49IwblkGBP/D+iKBDB+suLFD4nM2z3ehlmHy2sY5okeN2OEPpgb x/UA== MIME-Version: 1.0 X-Received: by 10.107.134.83 with SMTP id i80mr17736988iod.123.1438585991842; Mon, 03 Aug 2015 00:13:11 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Mon, 3 Aug 2015 00:13:11 -0700 (PDT) In-Reply-To: <20150803071150.GA6116@brick.home> References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> <55BEE4A5.40107@freebsd.org> <20150803071150.GA6116@brick.home> Date: Mon, 3 Aug 2015 00:13:11 -0700 Message-ID: Subject: Re: pivot_root() and FreeBSD From: Adrian Chadd To: Julian Elischer , Dirk-Willem van Gulik , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 03 Aug 2015 11:06:18 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 07:13:12 -0000 .. and it won't work for upgrading routers, as the MIPS things don't use lo= ader. On 3 August 2015 at 00:11, Edward Tomasz Napiera=C5=82a = wrote: > On 0803T1148, Julian Elischer wrote: >> On 3/4/15 12:51 AM, Dirk-Willem van Gulik wrote: >> > I am trying to do, in effect an PXE boot/install on a local volume - a= nd would like the machine to cut over into normal running without a reboot*= . >> > >> > So effectively I would like to do the equivalent of pivot_root() and p= erhaps something special for init(8), and then jettison md, nfs and what no= t. >> > >> > Is there any way to do this on 10.1 or -current ? Or has anyone recent= ly done work on Adrian Steinmann his 'Pivot Root for BSD=E2=80=99** ? >> > >> > Thanks, >> there is SOME work going on on a similar thing.. It was in the recent >> project status. >> >> https://www.freebsd.org/news/status/report-2015-04-2015-06.html#Root-Rem= ount >> >> Also have you tried simply using a small memory filesystem loaded with >> the kernel? > > Note that this functionality is kind of broken as well: > > https://reviews.freebsd.org/D3204 > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@freebsd.org Mon Aug 3 14:48:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 201C39B2D56 for ; Mon, 3 Aug 2015 14:48:27 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from 1.mo174.mail-out.ovh.net (1.mo174.mail-out.ovh.net [178.33.109.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE9DFC3 for ; Mon, 3 Aug 2015 14:48:26 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from MBX002.OVH.local (corp.ovh.com [5.196.251.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mo174.mail-out.ovh.net (Postfix) with ESMTPS id 774C7FF808F; Mon, 3 Aug 2015 15:32:45 +0200 (CEST) Received: from desk533202.ovh.net (5.196.2.34) by MBX002.OVH.local (172.16.2.2) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 3 Aug 2015 15:32:27 +0200 From: Ganael Laplanche Organization: OVH To: Eric McCorkle Subject: Boot loader arguments (was: ZFS support for EFI) Date: Mon, 3 Aug 2015 15:32:44 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) CC: MIME-Version: 1.0 Message-ID: <201508031532.44478.ganael.laplanche@corp.ovh.com> X-Originating-IP: [5.196.2.34] X-ClientProxiedBy: cas01.OVH.local (172.16.1.1) To MBX002.OVH.local (172.16.2.2) X-Ovh-Tracer-Id: 7889462125500152538 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrudegucdltddurdefkedvrddttddmucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:48:27 -0000 Hi Eric, I am replying to this -quite old now- post : https://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047486.html > More importantly, the EFI loader doesn't seem to make use of its > command-line arguments at all. But a ZFS-enabled loader would really > need the ability to take arguments from boot1 (or grub, or whatever > else). where you were suggesting it would be interesting for the EFI loader to mak= e=20 use of its arguments, which is still not the case. We've faced a similar problem here, where we needed the EFI loader be able = to=20 locally override the root-path offered through BOOTP. A quick fix would hav= e=20 been to hardcode the root-path but instead we chose to pass it through an=20 argument to the loader (which then sets a new environment variable :=20 dhcp.root-path.override). =46ind attached the two -simple- patches that allow such an operation. I do= n't=20 know if they can be interesting for you or for upstream inclusion (though t= hey=20 are probably *not* ready for direct inclusion yet). Best regards, =2D-=20 Gana=EBl LAPLANCHE From owner-freebsd-hackers@freebsd.org Mon Aug 3 18:40:17 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01D269B2C42 for ; Mon, 3 Aug 2015 18:40:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id D824D1196 for ; Mon, 3 Aug 2015 18:40:16 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 3 Aug 2015 18:40:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t73IeDFn016331; Mon, 3 Aug 2015 12:40:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1438627213.70393.19.camel@freebsd.org> Subject: Re: Boot loader arguments (was: ZFS support for EFI) From: Ian Lepore To: Ganael Laplanche Cc: Eric McCorkle , freebsd-hackers@freebsd.org Date: Mon, 03 Aug 2015 12:40:13 -0600 In-Reply-To: <201508031532.44478.ganael.laplanche@corp.ovh.com> References: <201508031532.44478.ganael.laplanche@corp.ovh.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 18:40:17 -0000 On Mon, 2015-08-03 at 15:32 +0200, Ganael Laplanche wrote: > Hi Eric, > > I am replying to this -quite old now- post : > > https://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047486.html > > > More importantly, the EFI loader doesn't seem to make use of its > > command-line arguments at all. But a ZFS-enabled loader would really > > need the ability to take arguments from boot1 (or grub, or whatever > > else). > > where you were suggesting it would be interesting for the EFI loader to make > use of its arguments, which is still not the case. > > We've faced a similar problem here, where we needed the EFI loader be able to > locally override the root-path offered through BOOTP. A quick fix would have > been to hardcode the root-path but instead we chose to pass it through an > argument to the loader (which then sets a new environment variable : > dhcp.root-path.override). > > Find attached the two -simple- patches that allow such an operation. I don't > know if they can be interesting for you or for upstream inclusion (though they > are probably *not* ready for direct inclusion yet). > > Best regards, > It looks like your patches got scrubbed off somehow. I recently tweaked loader(8) to make it easier for the data normally gathered from bootp/dhcp to be provided "from the environment" -- whatever that may mean for a given flavor of loader. The network code already had some provisions for setting the required variables before the first attempt to do network access, my changes just shuffled things around a bit to make it easier to parse a "rootpath" var formatted as "rootserverip:/path/stuff" into the existing global vars. See r283062 for those changes, and r283066 for an example of obtaining the values from "somewhere" (in this case the u-boot environment) and setting the corresponding global vars for netbooting. The comments in r283066 might be a useful guide to implementing the same kind of thing based on parsing an EFI command line. It may be that my changes didn't cover all situations and more tweaking is needed, especially if the situation is that some data should come from bootp/dhcp and other data should be overridden from the command line. -- Ian From owner-freebsd-hackers@freebsd.org Tue Aug 4 07:30:04 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE0299B3B62 for ; Tue, 4 Aug 2015 07:30:04 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from 5.mo175.mail-out.ovh.net (5.mo175.mail-out.ovh.net [46.105.41.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82F841399 for ; Tue, 4 Aug 2015 07:30:03 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from MBX002.OVH.local (corp.ovh.com [5.196.251.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mo175.mail-out.ovh.net (Postfix) with ESMTPS id AB40AFF8268; Tue, 4 Aug 2015 08:11:35 +0200 (CEST) Received: from desk533202.ovh.net (5.196.2.34) by MBX002.OVH.local (172.16.2.2) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 4 Aug 2015 08:11:16 +0200 From: Ganael Laplanche Organization: OVH To: Ian Lepore Subject: Re: Boot loader arguments (was: ZFS support for EFI) Date: Tue, 4 Aug 2015 08:11:34 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) CC: Eric McCorkle , References: <201508031532.44478.ganael.laplanche@corp.ovh.com> <1438627213.70393.19.camel@freebsd.org> In-Reply-To: <1438627213.70393.19.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <201508040811.34730.ganael.laplanche@corp.ovh.com> X-Originating-IP: [5.196.2.34] X-ClientProxiedBy: cas02.OVH.local (172.16.1.2) To MBX002.OVH.local (172.16.2.2) X-Ovh-Tracer-Id: 6311513404948789978 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -92 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrudeiucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegfrhhlucfvnfffucdlkedm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 07:30:04 -0000 On Monday, August 03, 2015 08:40:13 PM Ian Lepore wrote: Hi Ian, > It looks like your patches got scrubbed off somehow. Yes, sorry, here they are, inline : This one sets the environment reading argv[] : 8<--------------------------------->8 =2D-- sys/boot/efi/loader/main.c.orig 2015-07-28 09:31:08.648856000 +02= 00 +++ sys/boot/efi/loader/main.c 2015-07-30 09:02:42.695337864 +0200 @@ -67,7 +67,10 @@ char vendor[128]; EFI_LOADED_IMAGE *img; EFI_GUID *guid; =2D int i; + int i, j; + +#define MAX_ARG_LEN 128 + char var[MAX_ARG_LEN]; =20 /* * XXX Chicken-and-egg problem; we want to have console output @@ -83,6 +86,17 @@ } =20 /* + * Initialize environment using argv[] after converting from UCS-2 = to=20 ASCII + */ + for (i =3D 1; i < argc; i++) { + for(j =3D 0; ((char)argv[i][j] !=3D 0) && (j < (MAX_ARG_LEN= - 1));=20 j++) + var[j] =3D (char)argv[i][j]; + var[j] =3D 0; + putenv(var); + /* printf("main: added environment variable: %s\n", var); */ + } + + /* * March through the device switch probing for things. */ for (i =3D 0; devsw[i] !=3D NULL; i++) 8<--------------------------------->8 and this one overrides the BOOTP root-path if dhcp.root-path.override is se= t : 8<--------------------------------->8 =2D-- lib/libstand/bootp.c.orig 2015-07-29 08:38:28.970379976 +0200 +++ lib/libstand/bootp.c 2015-07-29 09:08:59.747891922 +0200 @@ -383,8 +383,20 @@ bcopy(cp, &rootip.s_addr, sizeof(swapip.s_addr)); } if (tag =3D=3D TAG_ROOTPATH) { =2D strncpy(rootpath, (char *)cp, sizeof(rootpath)); =2D rootpath[size] =3D '\0'; + /* + * XXX Set dhcp.root-path.override to force rootpath + * locally and ignore BOOTP vendor tag 17 (root-pat= h) + */ + char *rootpath_o =3D getenv("dhcp.root-path.overrid= e"); + if (rootpath_o =3D=3D NULL) { + strncpy(rootpath, (char *)cp,=20 sizeof(rootpath)); + rootpath[size] =3D '\0'; + /* printf("vend_rfc1048: rootpath set from= =20 BOOTP: %s\n", rootpath); */ + } + else { + strcpy(rootpath, rootpath_o); + /* printf("vend_rfc1048: rootpath set to:=20 %s\n", rootpath); */ + } } if (tag =3D=3D TAG_HOSTNAME) { strncpy(hostname, (char *)cp, sizeof(hostname)); 8<--------------------------------->8 Again, those patches would probably need improvements, as there is (for=20 example) no sanitization done before setenv(). Anyway, this allows to chainload the loader and pass your root-path (and an= y=20 other variable) this way (e.g. with iPXE) : #!ipxe chain http://path.to/loader.efi dhcp.root- path.override=3Dserver_ip:/path/to/root some_other_var=3Dvalue > I recently tweaked loader(8) to make it easier for the data normally > gathered from bootp/dhcp to be provided "from the environment" -- > whatever that may mean for a given flavor of loader. The network code > already had some provisions for setting the required variables before > the first attempt to do network access, my changes just shuffled things > around a bit to make it easier to parse a "rootpath" var formatted as > "rootserverip:/path/stuff" into the existing global vars. >=20 > See r283062 for those changes, and r283066 for an example of obtaining > the values from "somewhere" (in this case the u-boot environment) and > setting the corresponding global vars for netbooting. Interesting, thanks for the pointers. U-boot might be useful here, I have t= o=20 check that. > The comments in r283066 might be a useful guide to implementing the same > kind of thing based on parsing an EFI command line. Yep, that would probably be a cleaner way to go. > It may be that my changes didn't cover all situations and more tweaking > is needed, especially if the situation is that some data should come > from bootp/dhcp and other data should be overridden from the command > line. Yes, that's *exactly* the case we are facing, where the root-path given by= =20 BOOTP cannot always be used :/ Best regards, =2D-=20 Gana=EBl LAPLANCHE From owner-freebsd-hackers@freebsd.org Tue Aug 4 13:29:53 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC42B9B2A2F for ; Tue, 4 Aug 2015 13:29:53 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 9352DA3B for ; Tue, 4 Aug 2015 13:29:53 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038] (unknown [IPv6:2001:470:1f11:617:5ef7:830:9e60:2038]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id A971DDC2; Tue, 4 Aug 2015 13:29:52 +0000 (UTC) Subject: Re: Boot loader arguments (was: ZFS support for EFI) To: Ganael Laplanche , Eric McCorkle References: <201508031532.44478.ganael.laplanche@corp.ovh.com> Cc: freebsd-hackers@freebsd.org From: Eric McCorkle Message-ID: <55C0BE53.4080406@metricspace.net> Date: Tue, 4 Aug 2015 09:29:55 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <201508031532.44478.ganael.laplanche@corp.ovh.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5Kl2dHXOuk2lmK1MPHMgfsTaW8jfmhrpM" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 13:29:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5Kl2dHXOuk2lmK1MPHMgfsTaW8jfmhrpM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I had thought it would be necessary in order to point the loader at the correct ZFS partition (linux does require this), but apparently loader figures out what partition it should be dealing with just fine. I don't doubt it would be a good change, and loader could use some refactoring IMO, but I'd like to keep the changesets as small as possible= =2E On 08/03/2015 09:32 AM, Ganael Laplanche wrote: > Hi Eric, >=20 > I am replying to this -quite old now- post : >=20 > https://lists.freebsd.org/pipermail/freebsd-hackers/2015-March/047486.h= tml >=20 >> More importantly, the EFI loader doesn't seem to make use of its >> command-line arguments at all. But a ZFS-enabled loader would really >> need the ability to take arguments from boot1 (or grub, or whatever >> else). >=20 > where you were suggesting it would be interesting for the EFI loader to= make=20 > use of its arguments, which is still not the case. >=20 > We've faced a similar problem here, where we needed the EFI loader be a= ble to=20 > locally override the root-path offered through BOOTP. A quick fix would= have=20 > been to hardcode the root-path but instead we chose to pass it through = an=20 > argument to the loader (which then sets a new environment variable :=20 > dhcp.root-path.override). >=20 > Find attached the two -simple- patches that allow such an operation. I = don't=20 > know if they can be interesting for you or for upstream inclusion (thou= gh they=20 > are probably *not* ready for direct inclusion yet). >=20 > Best regards, >=20 --5Kl2dHXOuk2lmK1MPHMgfsTaW8jfmhrpM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVwL5YAAoJECuREQPg1IcEGMsP/jdA8HT0haLvP3+VTdguQDLw CTRP8VTCrRxDT2mqCXVZN7Fx+wVUEfUKdU3nEsj4YYfLF0TR5uq5OVMKFwblmNE+ UausvlTvD7XHfgqrDjpzScwvMxSXHZeVEEwQ9cbJooEvn1tJq7EVGI/KKBk+LF5K wSeFezbbbLYY9xnt8IVGRPkH6YPsckJtyS5m1PMOgX0Kjvi6rCMbte5a4GkY/pVD 3OfFX3mKXoIdnIBm1DuS60JfquQbsz/Pt7ntKZmILqAbseFFG2kiOsSqFaxAFHND +ZpcbGjJi+LdCAD2Xnp3JMQtPKjqHnODXH4qz9ciUielXH15qYhfZhYafY0l/RAM bMm2NEWNW+bh6nDuXBejmWLNA7i849eamHvTraT6v9YBFnJB/1Stp7mu5B/DPg2n MApqC79VKtd4oZws+Y9H7D0tbo7xYETPhP/xejjj9cXaD9izIqbRiI01tFSNm3Kx tSpFSLJDvfEnLa03fgLOsFFxjAyZNpHEaBsYMW017a7M7StBSRw3V3zA9DXXWt4f 64BrASDiTBV62YJG+EwcK0ADbtAhHAW6G7Yss3SPH1XTqfq+gDb6W7MOq+SFeb4i 2FEh41MIFbh+biat6dbU9AemCRtYSDTct6NFpHvitaLvmgGhm3FPLjL7/XGtZlEF +gdquBfPp5dBvkt838l7 =Mvzu -----END PGP SIGNATURE----- --5Kl2dHXOuk2lmK1MPHMgfsTaW8jfmhrpM-- From owner-freebsd-hackers@freebsd.org Tue Aug 4 19:52:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 670CD9B37A2 for ; Tue, 4 Aug 2015 19:52:20 +0000 (UTC) (envelope-from patrick.mooney@joyent.com) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 367F8863 for ; Tue, 4 Aug 2015 19:52:19 +0000 (UTC) (envelope-from patrick.mooney@joyent.com) Received: by oip136 with SMTP id 136so8799964oip.1 for ; Tue, 04 Aug 2015 12:52:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=BeoEbB96V4uOJdmXeObMnqdM8Tp8r1fwh2UmPHu7+gg=; b=JHkJvVHPdwQlxNnFMwqsar8zfE+p+2oJ6u1YWcCi/yueHSGBXuOJIfQRB5EnddvZeT x8mFDh7HNlHwjtNZaCG4csZc74iM19O5/uiKJp11tbBO8Uukw2BgfeftqHy6L4R9dIyK PKWLoT8JbIFCrztxiaS1mMrkZWU8kJAIcFEX3FLypToozbANwDtvndsv/THYGGxRklJU rW1VTYBZt0PVjUeyyAC5qpy9pJhbFtpALwDNiqgmja62qMxx6J4SGMSEAE3qp0i/9I1K Yf56JSrWjqB+Z0hWfQitCM4AZHFpsdYf/ap3skW1wGMCjubgMi79Q3VRP4u/zgwoqBF/ VZow== X-Gm-Message-State: ALoCoQlnSvmW93/Nr64BQVPT/jO1O+6qbPmKtZ0I2r/89pG5Slpzj7ZE7Ph3lI2Rv/xGUpxOB6wX MIME-Version: 1.0 X-Received: by 10.202.219.195 with SMTP id s186mr4286103oig.25.1438717932983; Tue, 04 Aug 2015 12:52:12 -0700 (PDT) Received: by 10.202.206.17 with HTTP; Tue, 4 Aug 2015 12:52:12 -0700 (PDT) In-Reply-To: References: <20150802000945.GL78154@funkthat.com> <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> <20150802034945.GN78154@funkthat.com> Date: Tue, 4 Aug 2015 14:52:12 -0500 Message-ID: Subject: Re: Interpretation of POSIX.1-2008 for recvmsg From: Patrick Mooney To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:52:20 -0000 OK. It seems clear, given the consensus in behavior across the BSDs as well as OSX. We'll find a separate way to enable the Linux-y behavior in our emulation. Thanks for your time. On 2 August 2015 at 06:31, Marcin Cieslak wrote: > On Sat, 1 Aug 2015, John-Mark Gurney wrote: > >> Jordan Hubbard wrote this message on Sat, Aug 01, 2015 at 18:10 -0700: >> > One obvious approach might be to run Patrick's test case on a OS X sys= tem, since it's one of the very few remaining (still living) UNIX??? platfo= rms that has to pass the official (and really large) Unix Conformance test = suite. Whatever OS X's behavior is, arguably right or wrong, you'll at lea= st know that TOG signed off on it. >> >> Ok, I know it's a bit old, but MacOSX 10.7.5: >> $./peektest >> peek len: 0 errno: 0 flags: 12 >> recv len: 20 errno: 0 flags: 0 >> >> and NetBSD 6.1.5: >> # ./peektest >> peek len: 0 errno: 0 flags: 12 >> recv len: 20 errno: 0 flags: 0 >> >> and OpenBSD 5.7: >> # ./peektest >> peek len: 0 errno: 0 flags: 12 >> recv len: 20 errno: 0 flags: 0 > > The results are correct: the peektest.c tries > to use a Linux-only extension to recvmsg() > - giving MSG_PEEK | MSG_TRUNC as the input flag. > > ~Marcin From owner-freebsd-hackers@freebsd.org Tue Aug 4 22:47:29 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C1FB9B3260 for ; Tue, 4 Aug 2015 22:47:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2001A8BB for ; Tue, 4 Aug 2015 22:47:29 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacgq8 with SMTP id gq8so18781580pac.3 for ; Tue, 04 Aug 2015 15:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=zVk1JQd6YK6PIf8qI8j2dcVpsZHJnue7vAhAQwacFQ8=; b=sDzboqEFOzLtjPNEjq/tbLyXBVqVvWkG2uOMBinRCfB5qGs50k52ZS26KYODXgp+Jt eBw+q9/lLC2++1ZwPeCeoMWq1euqWwJ7V43g8RLtK8ZFmeAV7mBtAop/Em2FUIBmEBV4 2WpTPuen9AxKeQsRDws06gtuUoTB1jVTNI9AsO8bUFJC3fauxJ6tQQ1SOF3eG3rbJcej C379uzvu6QRl3ITdzXmxK58J/JecK0r1A2W+uaFH5Ep6Gce+CuHq4SErX2W4hqVRJ/OF FCukjwLb6XUU+IEfI1bvgAhMzJYZMhl9XnDifei28QA7tQAR8hmhRReQO08iPEY+GwEh ciUA== X-Received: by 10.68.104.67 with SMTP id gc3mr12638348pbb.103.1438728448571; Tue, 04 Aug 2015 15:47:28 -0700 (PDT) Received: from ?IPv6:2601:601:801:23c0:dd0d:e229:403b:2498? ([2601:601:801:23c0:dd0d:e229:403b:2498]) by smtp.gmail.com with ESMTPSA id fk4sm480499pbd.12.2015.08.04.15.47.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Aug 2015 15:47:27 -0700 (PDT) From: Garrett Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: When and when not to use CTLFLAG_MPSAFE with the SYSCTL macros..? Date: Tue, 4 Aug 2015 15:47:26 -0700 Message-Id: Cc: Hans Petter Selasky To: freebsd-hackers Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 22:47:29 -0000 Hi, I=92ve been trying to figure out (because sysctl(9) is lacking) = when to use CTLFLAG_MPSAFE. Is it strictly when dealing with SYSCTL_PROC = handlers that do proper locking of shared resources, or are there other = nuances that need to be handled? I=92m also asking because SYSCTL_UQUAD, for instance, explicitly = uses CTLFLAG_MPSAFE in the handler, which is a bit confusing. Thanks! -NGie= From owner-freebsd-hackers@freebsd.org Wed Aug 5 00:04:27 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26F909B37B9 for ; Wed, 5 Aug 2015 00:04:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 010F010CA for ; Wed, 5 Aug 2015 00:04:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 14D09B999; Tue, 4 Aug 2015 20:04:26 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Mario Lobo , "Herbert J. Skuhra" Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Date: Tue, 04 Aug 2015 13:18:21 -0700 Message-ID: <1678045.UlXctAKXAD@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150712152321.51b8407c@Papi> References: <20150710213752.473cb831@Papi> <20150711135006.GB41680@oslo.ath.cx> <20150712152321.51b8407c@Papi> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Aug 2015 20:04:26 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 00:04:27 -0000 On Sunday, July 12, 2015 03:23:21 PM Mario Lobo wrote: > On Sat, 11 Jul 2015 15:50:06 +0200 > "Herbert J. Skuhra" wrote: >=20 > > On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote: > > > Hi; > > >=20 > > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to th= e > > > latest version but the problem also showed with the previous > > > version. > > >=20 > > > Here is my amd64 10-STABLE setup: > > >=20 > > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT 2015= > > > amd64 > > >=20 > > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class CPU)= > > > Origin=3D"AuthenticAMD" Id=3D0x600f20 Family=3D0x15 Model=3D= 0x2 > > > Stepping=3D0 > > > Features=3D0x178bfbff > > > Features2=3D0x3e98320b > > > AMD Features=3D0x2e500800 AMD > > > Features2=3D0x1ebbfff > > > Structured Extended Features=3D0x8 > > > SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=3D65536 > > > TSC: P-state invariant, performance statistics > > > real memory =3D 17179869184 (16384 MB) > > > [snip] > > > ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has > > > zero address or length: 0x0000000000000000/0x1 (20150515/tbfadt-6= 73) > > > [snip] > > > hpet0: iomem 0xfed00000-0xfed003ff o= n > > > acpi0 > > >=20 > > > The problem: > > >=20 > > > powerd: no cpufreq(4) support -- aborting: No such file or direct= ory > > > /etc/rc: WARNING: failed to start powerd > >=20 > > Could this be your problem: > >=20 > > r276986 | nwhitehorn | 2015-01-11 18:10:07 +0100 (s=F8n, 11 jan 201= 5) | > > 8 lines > >=20 > > MFC r265329: > > Disable ACPI and P4TCC throttling by default, following discussion = on > > freebsd-current. These CPU speed control techniques are usually > > unhelpful at best. For now, continue building the relevant code int= o > > GENERIC so that it can trivially be re-enabled at runtime if anyone= > > wants it. > >=20 > > Relnotes: yes > >=20 > > % svnlite diff -c 276986 sys/amd64/conf/GENERIC.hints=20 > > Index: sys/amd64/conf/GENERIC.hints > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/amd64/conf/GENERIC.hints (revision 276985) > > +++ sys/amd64/conf/GENERIC.hints (revision 276986) > > @@ -31,3 +31,5 @@ > > hint.attimer.0.port=3D"0x40" > > hint.attimer.0.irq=3D"0" > > hint.wbwd.0.at=3D"isa" > > +hint.acpi_throttle.0.disabled=3D"1" > > +hint.p4tcc.0.disabled=3D"1" > >=20 > > Does it work if your unset or remove those lines > > from /boot/device.hints? > >=20 >=20 > YEEESSS ! Thanks for pointing that out! >=20 > I have these commented on my loader.conf but I didn't know they were > active somewhere else. >=20 > As far as cpufreq/powerd goes, it's working now and frequencies are > being throttled but still no cool'n'quiet/hwpstate0 showing on dmesg.= > acpi_throttle attaches to cpu0 but not to the others. The acpi_throttle isn't really that helpful though. You probably want to try to add support for your CPU to the hwpstate driver instead and leave acpi_throttle disabled. Can you run 'kgdb' as root and get the output of 'p amd_pminfo'? Hmm, do you have an acpi_perf0 device? If not, then your CPU isn't supported without BIOS help. First check to see if there are any BIOS options to control CPU throttling that are currently disabled. --=20 John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 5 00:04:30 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 056E79B37CD for ; Wed, 5 Aug 2015 00:04:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D89A61127 for ; Wed, 5 Aug 2015 00:04:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EE098B9A9; Tue, 4 Aug 2015 20:04:28 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Dieter BSD Subject: Re: Realtime process CPU starvation Date: Tue, 04 Aug 2015 12:55:47 -0700 Message-ID: <3169076.CIxh6P9lj2@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Aug 2015 20:04:29 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 00:04:30 -0000 On Saturday, June 20, 2015 11:20:38 AM Dieter BSD wrote: > For those who care, I'm running > kern.sched.name: ULE > > My (feeble) understanding is that the scheduler mostly looks at cpu > time, and processes doing i/o actually get a bump *up* in priority, > since because of the way hardware worked in the late 1970s-early 1980s > (PDP-11, VAX, ...) the i/o got useful work done while using very little > cpu time. As a result, jobs that do a lot of i/o can receive more > than their fair share of cpu time. And nice(1) (even rtprio and idprio) > may not have much effect on jobs that are i/o bound. Some form of > ionice is sorely needed. Realtime priorities in 8. and later are higher than the I/O bump. Only ithreads are higher than realtime in modern versions. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 5 00:04:28 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A72DA9B37BC for ; Wed, 5 Aug 2015 00:04:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80B5C110B for ; Wed, 5 Aug 2015 00:04:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7B72BB99B; Tue, 4 Aug 2015 20:04:27 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Philippe Jalaber Subject: Re: adaptive rwlock deadlock Date: Tue, 04 Aug 2015 13:10:50 -0700 Message-ID: <2768515.JZVZhYiQVE@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 04 Aug 2015 20:04:27 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 00:04:28 -0000 On Tuesday, July 07, 2015 12:10:19 PM Philippe Jalaber wrote: > Hi, > > I am facing a strange problem using the network stack and adaptive rwlocks > running Freebsd 9.3. > Basically I can reproduce the problem with 3 threads: > > 1) thread 1 has taken the rwlock of structure inpcb in exclusive mode in > tcp_input.c. This thread also runs my own code and repeatedly takes a > rwlock (called g_rwlock) in shared mode and releases it, until a shared > object is marked not "busy" any more: > > rwlock(inp_lock); > .... > do { // thread is active waiting in the loop > rlock(g_rwlock); > o = find(); > if ( o == NULL ) > break; > busy = o.busy; > if (o != NULL && busy) > runlock(g_rwlock); > } while ( busy ); > > if ( o != NULL ) > { > // do something with o > .... > } > runlock(g_rwlock); > .... > > 2) thread 2 wants to set the shared object as "ready". So it tries to take > g_rwlock in exclusive mode and is blocked in _rw_wlock_hard@kern_rwlock.c:815 > "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because thread 1 has > already taken it in shared mode: > > wlock(g_rwlock); > o = find(); > if ( o != NULL ) > o.busy = 1; > wunlock(g_rwlock); > > // o is busy so work on it without any lock > .... > > wlock(g_rwlock); // thread is blocked here > o.busy = 0; > maybe_delete(o); > wunlock(g_rwlock); > > 3) thread 3 spins on the same inpcb rwlock than thread 1 in > _rw_wlock_hard@kern_rwlock.c:721 "while ((struct > thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " > > > My target machine has two cpus. > Thread 1 is pinned to cpu 0. > Thread 2 and Thread 3 are pinned to cpu 1. > Thread 1 and Thread 2 have a priority of 28. > Thread 3 has a priority of 127 > > Now what seems to happen is that when thread 1 calls runlock(g_rwlock), it > calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never regains > control because thread 3 is spinning on the inpcb rwlock. Also the > condition TD_IS_RUNNING(owner) is always true because thread 1 is active > waiting in a loop. So the 3 threads deadlock. > Note that if I compile the kernel without adaptive rwlocks it works without > any problem. > A workaround is to add a call to "sched_relinquish(curthread)" in thread 1 > in the loop just after the call to runlock. It sounds like we are not forcing a preemption on CPU 1 in this case via sched_add(). For SCHED_4BSD you could try the 'FULL_PREEMPTION' kernel option. For ULE you can adjust 'preempt_thresh' on the fly, though I think the default setting should actually still work. Can you use KTR or some such to determine if IPI_PREEMPT is being sent by CPU 0 to CPU 1 in this case? > I am also wondering about the code in _rw_runlock after > "turnstile_broadcast(ts, queue)". Isn't the flag RW_LOCK_WRITE_WAITERS > definitely lost if the other thread which is blocked in turnstile_wait > never regains control ? All the write waiters are awakened by a broadcast (as opposed to a signal operation). They are on the run queue, not on the turnstile queue anymore, so there aren't any write waiters left (the bit only tracks if there are waiters on the turnstile). -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 5 06:36:50 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4752B9B4E86 for ; Wed, 5 Aug 2015 06:36:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C6D2C7F for ; Wed, 5 Aug 2015 06:36:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 327941FE023; Wed, 5 Aug 2015 08:36:48 +0200 (CEST) Message-ID: <55C1AF5A.1080601@selasky.org> Date: Wed, 05 Aug 2015 08:38:18 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Garrett Cooper , freebsd-hackers Subject: Re: When and when not to use CTLFLAG_MPSAFE with the SYSCTL macros..? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 06:36:50 -0000 On 08/05/15 00:47, Garrett Cooper wrote: > Hi, > I’ve been trying to figure out (because sysctl(9) is lacking) when to use CTLFLAG_MPSAFE. Is it strictly when dealing with SYSCTL_PROC handlers that do proper locking of shared resources, or are there other nuances that need to be handled? > I’m also asking because SYSCTL_UQUAD, for instance, explicitly uses CTLFLAG_MPSAFE in the handler, which is a bit confusing. > Thanks! > -NGie Hi, This flag decides if you have Giant automatically locked or not around the sysctl proc. Your functions should have their own locks basically. I believe it is a leftover from many years ago, when the FreeBSD kernel was going multi threaded. --HPS From owner-freebsd-hackers@freebsd.org Wed Aug 5 08:15:16 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B1779B49F5 for ; Wed, 5 Aug 2015 08:15:16 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from 2.mo175.mail-out.ovh.net (2.mo175.mail-out.ovh.net [178.33.255.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4E9D38C for ; Wed, 5 Aug 2015 08:15:15 +0000 (UTC) (envelope-from ganael.laplanche@corp.ovh.com) Received: from MBX002.OVH.local (corp.ovh.com [5.196.251.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mo175.mail-out.ovh.net (Postfix) with ESMTPS id 02785FF826B; Wed, 5 Aug 2015 09:56:06 +0200 (CEST) Received: from desk533202.ovh.net (5.196.2.34) by MBX002.OVH.local (172.16.2.2) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 5 Aug 2015 09:55:46 +0200 From: Ganael Laplanche Organization: OVH To: Eric McCorkle Subject: Re: Boot loader arguments (was: ZFS support for EFI) Date: Wed, 5 Aug 2015 09:56:06 +0200 User-Agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) CC: Eric McCorkle , References: <201508031532.44478.ganael.laplanche@corp.ovh.com> <55C0BE53.4080406@metricspace.net> In-Reply-To: <55C0BE53.4080406@metricspace.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-ID: <201508050956.06261.ganael.laplanche@corp.ovh.com> X-Originating-IP: [5.196.2.34] X-ClientProxiedBy: cas01.OVH.local (172.16.1.1) To MBX002.OVH.local (172.16.2.2) X-Ovh-Tracer-Id: 13949618375014333146 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekfedrudelucetufdoteggucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 08:15:16 -0000 On Tuesday, August 04, 2015 03:29:55 PM Eric McCorkle wrote: Hi Eric, > I don't doubt it would be a good change, and loader could use some > refactoring IMO, but I'd like to keep the changesets as small as possible. OK. For the record, I've just filed a PR here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D202098 Best regards, =2D-=20 Gana=EBl LAPLANCHE From owner-freebsd-hackers@freebsd.org Wed Aug 5 12:43:25 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13A4B9B3F24; Wed, 5 Aug 2015 12:43:25 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD513166; Wed, 5 Aug 2015 12:43:24 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: by labgo9 with SMTP id go9so27681526lab.3; Wed, 05 Aug 2015 05:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=PV05UybVq5VM83iSOuvs2nAXb5lAXwMVtWp5uJ78Buo=; b=TfEB6BDd+6KV/0BcE2n1NfZQDrWZ3IaXhAcVvBUAWM9v6TD61D+VZzVlf6plzX0NhB jphOf6KT2FVnaTLNOAm+843jZF+JhyYitZVGdSQ1PasnRTBIZikjC73IwuIQFFpwsSbs H2eA1Kq5ZfungBbur8B2aLIMWUmQNcGMuixfPpgi1/a1RdXYg56VU10ssquYQhP4aN4i akZEqZG0S73WldEVYhgaaGcTLTWte6tNvp0PgpKA4V2ym/ijSzAD6r8zoXMYKq1wRtvU /CuOOyz0MmV+7/TvaO5RCnd/dNxOYeDKWSL3EMfAWfG0yjcH95o2hqEgZoucbXgIqY1/ qlbg== X-Received: by 10.152.7.206 with SMTP id l14mr9057719laa.3.1438778602557; Wed, 05 Aug 2015 05:43:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.194 with HTTP; Wed, 5 Aug 2015 05:43:03 -0700 (PDT) From: Pratik Singhal Date: Wed, 5 Aug 2015 18:13:03 +0530 Message-ID: Subject: Compilation error due to header not found To: freebsd-hackers , FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:43:25 -0000 Hello all, I have used the file "dev/sound/pcm/sound.h" in a kernel driver made for ac97 codec for Allwinner A10. This file further includes the file "dev/sound/pcm/channel.h" which further includes the file "channel_if.h". I have checked in ~HEAD and the file channel_if.h doesn't exist in that particular directory and as a result, I am getting a compilation error when I compile the kernel complaining about the missing file "channel_if.h" . How can I resolve this error ? Regards, Pratik Singhal From owner-freebsd-hackers@freebsd.org Wed Aug 5 12:59:29 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C21F29B42D7 for ; Wed, 5 Aug 2015 12:59:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76F68B83 for ; Wed, 5 Aug 2015 12:59:29 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by qgeh16 with SMTP id h16so28574946qge.3 for ; Wed, 05 Aug 2015 05:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type:content-transfer-encoding; bh=oMxI2guj1qVZZP6GdtQof2eolV2nBau07YI7iUQWl5c=; b=CxVp7+r03bILCQxh4WcBOlyVeTdZf8+0Y8ABWLqps0t0FhU+FDCVndP2CBnHhpZ6jL ba0Q6xBSqkhbIFQJg6Lhvp5A6tRYo5SbX4Nd8zD4Rk9mUReNsok+Z0vP7w10nCMsE6SD rj0CjyBlN3T07b0PQL4WP+1VYhjJLOTvjYNJ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-type :content-transfer-encoding; bh=oMxI2guj1qVZZP6GdtQof2eolV2nBau07YI7iUQWl5c=; b=JRQbA3VOxbfAL3PUMKkDKYLvm/6bjuf7wraGNPK8STc9jeT34V4O4SJvf0f4aMnyqJ tUdDwFDk8hcZOVcKVrxEEs4oHQWIntbP9YyLb9WcJCSpawisGuS6YvbH7oA62fSfob4F yGGRH7+c8VpNH0iy4oX+mut/rssJOfa7SmoQAA5Ue+RrrAqoCyFUBi5VVNIfYer7RQEK oXQ0BST8AqPdcXH9ySo/Lm4usVSyM0zdRFVCkHt+NAh0zj3VIlAaa2yVegkYZWkEyerN v32TCHUFA3Vu8YY3anhk97MZivn8/LKRKY4yJtcaiEg4MgrsyGIXzKTZ6HE8Pfx9ufDC D94Q== X-Gm-Message-State: ALoCoQlyB4W7JQc5vPuDQxrs9w8oULSqE9pxzEk54aw6FpllrRuzPpknJoN97vwxWblR7bKg2ry5 X-Received: by 10.141.28.6 with SMTP id f6mr17774978qhe.64.1438779568520; Wed, 05 Aug 2015 05:59:28 -0700 (PDT) Received: from Papi ([177.98.27.21]) by smtp.gmail.com with ESMTPSA id l11sm1319673qga.43.2015.08.05.05.59.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 05:59:28 -0700 (PDT) Date: Wed, 5 Aug 2015 10:04:01 -0300 From: Mario Lobo To: John Baldwin Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150805100401.265ca50f@Papi> In-Reply-To: <1678045.UlXctAKXAD@ralph.baldwin.cx> References: <20150710213752.473cb831@Papi> <20150711135006.GB41680@oslo.ath.cx> <20150712152321.51b8407c@Papi> <1678045.UlXctAKXAD@ralph.baldwin.cx> Organization: BSD X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:59:29 -0000 On Tue, 04 Aug 2015 13:18:21 -0700 John Baldwin wrote: > On Sunday, July 12, 2015 03:23:21 PM Mario Lobo wrote: > > On Sat, 11 Jul 2015 15:50:06 +0200 > > "Herbert J. Skuhra" wrote: > >=20 > > > On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote: > > > > Hi; > > > >=20 > > > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to > > > > the latest version but the problem also showed with the previous > > > > version. > > > >=20 > > > > Here is my amd64 10-STABLE setup: > > > >=20 > > > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT > > > > 2015 amd64 > > > >=20 > > > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class > > > > CPU) Origin=3D"AuthenticAMD" Id=3D0x600f20 Family=3D0x15 Model= =3D0x2 > > > > Stepping=3D0 > > > > Features=3D0x178bfbff > > > > Features2=3D0x3e98320b > > > > AMD > > > > Features=3D0x2e500800 > > > > AMD > > > > Features2=3D0x1ebbfff > > > > Structured Extended Features=3D0x8 SVM: > > > > NP,NRIP,VClean,AFlush,DAssist,NAsids=3D65536 TSC: P-state > > > > invariant, performance statistics real memory =3D 17179869184 > > > > (16384 MB) [snip] ACPI BIOS Warning (bug): Optional FADT field > > > > Pm2ControlBlock has zero address or length: > > > > 0x0000000000000000/0x1 (20150515/tbfadt-673) [snip] > > > > hpet0: iomem 0xfed00000-0xfed003ff > > > > on acpi0 > > > >=20 > > > > The problem: > > > >=20 > > > > powerd: no cpufreq(4) support -- aborting: No such file or > > > > directory /etc/rc: WARNING: failed to start powerd > > >=20 > > > Could this be your problem: > > >=20 > > > r276986 | nwhitehorn | 2015-01-11 18:10:07 +0100 (s=F8n, 11 jan > > > 2015) | 8 lines > > >=20 > > > MFC r265329: > > > Disable ACPI and P4TCC throttling by default, following > > > discussion on freebsd-current. These CPU speed control techniques > > > are usually unhelpful at best. For now, continue building the > > > relevant code into GENERIC so that it can trivially be re-enabled > > > at runtime if anyone wants it. > > >=20 > > > Relnotes: yes > > >=20 > > > % svnlite diff -c 276986 sys/amd64/conf/GENERIC.hints=20 > > > Index: sys/amd64/conf/GENERIC.hints > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --- sys/amd64/conf/GENERIC.hints (revision 276985) > > > +++ sys/amd64/conf/GENERIC.hints (revision 276986) > > > @@ -31,3 +31,5 @@ > > > hint.attimer.0.port=3D"0x40" > > > hint.attimer.0.irq=3D"0" > > > hint.wbwd.0.at=3D"isa" > > > +hint.acpi_throttle.0.disabled=3D"1" > > > +hint.p4tcc.0.disabled=3D"1" > > >=20 > > > Does it work if your unset or remove those lines > > > from /boot/device.hints? > > >=20 > >=20 > > YEEESSS ! Thanks for pointing that out! > >=20 > > I have these commented on my loader.conf but I didn't know they were > > active somewhere else. > >=20 > > As far as cpufreq/powerd goes, it's working now and frequencies are > > being throttled but still no cool'n'quiet/hwpstate0 showing on > > dmesg. acpi_throttle attaches to cpu0 but not to the others. >=20 > The acpi_throttle isn't really that helpful though. You probably want > to try to add support for your CPU to the hwpstate driver instead and > leave acpi_throttle disabled. >=20 > Can you run 'kgdb' as root and get the output of 'p amd_pminfo'? (kgdb) p amd_pminfo $1 =3D 2009 > Hmm, do you have an acpi_perf0 device? If not, then your CPU isn't > supported without BIOS help. No acpi_perf0 device present > First check to see if there are any BIOS > options to control CPU throttling that are currently disabled. The only BIOS option that deals with throttling is Cool'n'Quiet, which is enabled. I get this though: [~]>dmesg -a | grep acpi_ =20 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_button0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 acpi_throttle4: on cpu4 acpi_throttle4: failed to attach P_CNT device_attach: acpi_throttle4 attach returned 6 acpi_throttle5: on cpu5 acpi_throttle5: failed to attach P_CNT device_attach: acpi_throttle5 attach returned 6 acpi_throttle6: on cpu6 acpi_throttle6: failed to attach P_CNT device_attach: acpi_throttle6 attach returned 6 acpi_throttle7: on cpu7 acpi_throttle7: failed to attach P_CNT device_attach: acpi_throttle7 attach returned 6 Only acpi_throttle0 gets hooked dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.acpi_throttle.0.%parent: cpu0 dev.acpi_throttle.0.%pnpinfo:=20 dev.acpi_throttle.0.%location:=20 dev.acpi_throttle.0.%driver: acpi_throttle dev.acpi_throttle.0.%desc: ACPI CPU Throttling dev.acpi_throttle.%parent And frequencies ARE getting throttled: dev.cpufreq.0.%parent: cpu0 dev.cpufreq.0.%pnpinfo:=20 dev.cpufreq.0.%location:=20 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%desc:=20 dev.cpufreq.%parent:=20 dev.acpi_throttle.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1=20 dev.cpu.0.freq_levels: 3214/-1 2812/-1 2410/-1 2008/-1 1607/-1 1205/-1 803/-1 dev.cpu.0.freq: 1607 dev.cpu.0.freq: 2008 dev.cpu.0.freq: 2410 dev.cpu.0.freq: 3214 dev.cpu.0.freq: 1205 dev.cpu.0.freq: 803 --=20 Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] =20 "UNIX was not designed to stop you from doing stupid things,=20 because that would also stop you from doing clever things." From owner-freebsd-hackers@freebsd.org Wed Aug 5 14:11:53 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03C439B2279; Wed, 5 Aug 2015 14:11:53 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7E761C5B; Wed, 5 Aug 2015 14:11:52 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by pabxd6 with SMTP id xd6so19523841pab.2; Wed, 05 Aug 2015 07:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=eDIP0CHkI8/ess4po80AqZxKQq2xmOvGr2GmWQaAcpE=; b=JIqPtlHUra+JzXunFSxc+e7/JWu+QNnot16VSNzaE/lx9Jiienfx/iab4+wrf0sHmD X7wlPCbWa23FyCG2ty+LS0n2M22nWInCqy3bxeubgXtwJ4Fo4GbGRvZJHv+pjEZXe7ST kYLd4a4ORYm3X+Z5Yzauw7rVr//UsWs+tgeor3szuZsqEHUwHJOqgzjFHU5z2UPo84Xs DMllKxObHlubng0+TRdQCHzzAzf5p20rKi0L1+wH780N9Tz1ihbEvjhgOdwhGcAUih73 boIPSmvy8kVeyv//tZSVWZ+tWLnNfEYY0V20o/K/44w1Zqw365GyGLTAn66zRYT+Hoyc 3Wvw== X-Received: by 10.68.203.195 with SMTP id ks3mr19681437pbc.123.1438783912369; Wed, 05 Aug 2015 07:11:52 -0700 (PDT) Received: from ox ([2601:641:c000:600:3c6d:108a:30a4:3887]) by smtp.gmail.com with ESMTPSA id ya3sm3063732pbb.71.2015.08.05.07.11.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 07:11:51 -0700 (PDT) Date: Wed, 5 Aug 2015 07:11:45 -0700 From: Navdeep Parhar To: Pratik Singhal Cc: freebsd-hackers , FreeBSD Questions Subject: Re: Compilation error due to header not found Message-ID: <20150805141145.GA21009@ox> Mail-Followup-To: Pratik Singhal , freebsd-hackers , FreeBSD Questions References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 14:11:53 -0000 On Wed, Aug 05, 2015 at 06:13:03PM +0530, Pratik Singhal wrote: > Hello all, I have used the file "dev/sound/pcm/sound.h" in a kernel driver > made for ac97 codec for Allwinner A10. This file further includes the file > "dev/sound/pcm/channel.h" which further includes the file "channel_if.h". > > I have checked in ~HEAD and the file channel_if.h doesn't exist in that > particular directory and as a result, I am getting a compilation error when > I compile the kernel complaining about the missing file "channel_if.h" . > > How can I resolve this error ? There is a channel_if.m in the tree. The build system should be able to create channel_if.h from that if you list channel_if.h in SRCS in your Makefile. Regards, Navdeep From owner-freebsd-hackers@freebsd.org Wed Aug 5 14:27:54 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D38A29B274C for ; Wed, 5 Aug 2015 14:27:54 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED9A396; Wed, 5 Aug 2015 14:27:54 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: by qgeu79 with SMTP id u79so30897757qge.1; Wed, 05 Aug 2015 07:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TLgDtLOiRw0BuAHrc4tyKCfnn1piKVf+ZSNDY3hkz24=; b=nTwbXH05Bcjv+CKKBKILWrJ4qKqPFUxnCw7/LUZhNWfbOcWtmR+Vwx2a0RTP7VkfcN G5qceFwvnZITeTJskBRWfLhQyIuEU4d1vq2o2R8OnIMVVo/YdAkyMVhrdcdknjsAlOeO ccQQUZICMYYjEleP3NALhcNTbkhgFrRylv+rLxFLXUGgPhcDHEfVMQ11aL7x1omxDPA8 BFsq/E3otEnrDbLy5oFmCY5MEG0a/d5fYRvvOYT0zpVoeMi0DHT4tus4YQc/HpZa/Zgb we/ZYlu4aiLguowlt2G3w3bNhGimx147Z47Rum39wQdXQypKmPhki7783w5TKhX5JzdD T7kg== MIME-Version: 1.0 X-Received: by 10.140.232.200 with SMTP id d191mr18774141qhc.87.1438784873611; Wed, 05 Aug 2015 07:27:53 -0700 (PDT) Received: by 10.140.92.247 with HTTP; Wed, 5 Aug 2015 07:27:53 -0700 (PDT) In-Reply-To: <2768515.JZVZhYiQVE@ralph.baldwin.cx> References: <2768515.JZVZhYiQVE@ralph.baldwin.cx> Date: Wed, 5 Aug 2015 16:27:53 +0200 Message-ID: Subject: Re: adaptive rwlock deadlock From: Philippe Jalaber To: John Baldwin Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 14:27:55 -0000 2015-08-04 22:10 GMT+02:00 John Baldwin : > On Tuesday, July 07, 2015 12:10:19 PM Philippe Jalaber wrote: > > Hi, > > > > I am facing a strange problem using the network stack and adaptive > rwlocks > > running Freebsd 9.3. > > Basically I can reproduce the problem with 3 threads: > > > > 1) thread 1 has taken the rwlock of structure inpcb in exclusive mode in > > tcp_input.c. This thread also runs my own code and repeatedly takes a > > rwlock (called g_rwlock) in shared mode and releases it, until a shared > > object is marked not "busy" any more: > > > > rwlock(inp_lock); > > .... > > do { // thread is active waiting in the loop > > rlock(g_rwlock); > > o = find(); > > if ( o == NULL ) > > break; > > busy = o.busy; > > if (o != NULL && busy) > > runlock(g_rwlock); > > } while ( busy ); > > > > if ( o != NULL ) > > { > > // do something with o > > .... > > } > > runlock(g_rwlock); > > .... > > > > 2) thread 2 wants to set the shared object as "ready". So it tries to > take > > g_rwlock in exclusive mode and is blocked in _rw_wlock_hard@kern_rwlock.c > :815 > > "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because thread 1 > has > > already taken it in shared mode: > > > > wlock(g_rwlock); > > o = find(); > > if ( o != NULL ) > > o.busy = 1; > > wunlock(g_rwlock); > > > > // o is busy so work on it without any lock > > .... > > > > wlock(g_rwlock); // thread is blocked here > > o.busy = 0; > > maybe_delete(o); > > wunlock(g_rwlock); > > > > 3) thread 3 spins on the same inpcb rwlock than thread 1 in > > _rw_wlock_hard@kern_rwlock.c:721 "while ((struct > > thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " > > > > > > My target machine has two cpus. > > Thread 1 is pinned to cpu 0. > > Thread 2 and Thread 3 are pinned to cpu 1. > > Thread 1 and Thread 2 have a priority of 28. > > Thread 3 has a priority of 127 > > > > Now what seems to happen is that when thread 1 calls runlock(g_rwlock), > it > > calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never regains > > control because thread 3 is spinning on the inpcb rwlock. Also the > > condition TD_IS_RUNNING(owner) is always true because thread 1 is active > > waiting in a loop. So the 3 threads deadlock. > > Note that if I compile the kernel without adaptive rwlocks it works > without > > any problem. > > A workaround is to add a call to "sched_relinquish(curthread)" in thread > 1 > > in the loop just after the call to runlock. > > It sounds like we are not forcing a preemption on CPU 1 in this case via > sched_add(). > > For SCHED_4BSD you could try the 'FULL_PREEMPTION' kernel option. > For ULE you can adjust 'preempt_thresh' on the fly, though I think the > default setting should actually still work. > > Can you use KTR or some such to determine if IPI_PREEMPT is being sent by > CPU 0 to CPU 1 in this case? > > > I am also wondering about the code in _rw_runlock after > > "turnstile_broadcast(ts, queue)". Isn't the flag RW_LOCK_WRITE_WAITERS > > definitely lost if the other thread which is blocked in turnstile_wait > > never regains control ? > > All the write waiters are awakened by a broadcast (as opposed to a signal > operation). They are on the run queue, not on the turnstile queue anymore, > so there aren't any write waiters left (the bit only tracks if there are > waiters on the turnstile). > > -- > John Baldwin > I Use ULE scheduler. Here's the KTR output using ktrdump on a vmcore after watchdog. 75447 ipi_selected: cpu: 1 ipi: fc 75446 stop_cpus() with 252 type 75445 ipi_cpu: cpu: 1 ipi: 2 75444 ipi_cpu: cpu: 1 ipi: 2 75443 ipi_cpu: cpu: 1 ipi: 2 75442 ipi_cpu: cpu: 1 ipi: 2 75441 ipi_cpu: cpu: 1 ipi: 2 .... 3862 ipi_cpu: cpu: 1 ipi: 2 3861 ipi_cpu: cpu: 1 ipi: 2 3860 ipi_cpu: cpu: 1 ipi: 2 3859 ipi_cpu: cpu: 1 ipi: 2 3858 ipi_cpu: cpu: 1 ipi: 2 3857 ipi_selected: cpu: 1 ipi: f3 3856 ipi_cpu: cpu: 1 ipi: 2 3855 ipi_cpu: cpu: 1 ipi: 2 3854 ipi_cpu: cpu: 1 ipi: 2 3853 ipi_selected: cpu: 0 ipi: f3 3852 ipi_cpu: cpu: 1 ipi: 2 3851 ipi_selected: cpu: 1 ipi: f3 3850 ipi_cpu: cpu: 1 ipi: 2 3849 ipi_cpu: cpu: 1 ipi: 2 3848 ipi_selected: cpu: 0 ipi: f3 3847 ipi_cpu: cpu: 1 ipi: 2 3846 ipi_cpu: cpu: 1 ipi: 2 3845 ipi_cpu: cpu: 1 ipi: 2 3844 ipi_cpu: cpu: 1 ipi: 2 3843 ipi_cpu: cpu: 1 ipi: 2 3842 ipi_cpu: cpu: 1 ipi: 2 3841 ipi_cpu: cpu: 1 ipi: 2 3840 ipi_cpu: cpu: 1 ipi: 2 3839 ipi_cpu: cpu: 1 ipi: 2 3838 ipi_cpu: cpu: 1 ipi: 2 3837 ipi_cpu: cpu: 1 ipi: 2 3836 ipi_cpu: cpu: 1 ipi: 2 3835 ipi_cpu: cpu: 0 ipi: 1 3834 ipi_cpu: cpu: 0 ipi: 1 3833 ipi_cpu: cpu: 0 ipi: 1 3832 ipi_cpu: cpu: 0 ipi: 1 3831 ipi_cpu: cpu: 0 ipi: 1 3830 ipi_cpu: cpu: 0 ipi: 1 From owner-freebsd-hackers@freebsd.org Wed Aug 5 14:59:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9E9B9B2F43; Wed, 5 Aug 2015 14:59:14 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4318518A8; Wed, 5 Aug 2015 14:59:14 +0000 (UTC) (envelope-from ps06756@gmail.com) Received: by lbbpo9 with SMTP id po9so26204565lbb.2; Wed, 05 Aug 2015 07:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=PM00mkPveCgBYximDxpxiA7Y6asNaVazdJsE/iAQuDA=; b=R86e0uJKo14LwcnPtFQXoL6+A+3NvaqzehYSFlJTYlegMPYWc3JUtyNnfClOTGL24S 0jYmj/dy32JqZLCtkU/2YLmr4R5gq6TFuQBmh/9opI9Wdl4VOuBKllMaVQPfQq8XP0WM sE6gcSyDEWt0yF76wGV/WONAn9CAxzun3nlkDikidtQvI+7HW7mWFpbDuv5MAjz0fq4n 4D2CGNM028CJcSCzzr3oRkAR5kNvgwhHvYY6dWCw3M2kqdax1tP/jRbdzTjCzX2eJnoN zCcn79pTQZ1PZG30I9i+XfqRaSFJAUq7FHwrWROS4Jg4fNrIUEYmk/AK5lltuFhr6i/D 3E8g== X-Received: by 10.112.159.162 with SMTP id xd2mr9478257lbb.67.1438786752297; Wed, 05 Aug 2015 07:59:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.194 with HTTP; Wed, 5 Aug 2015 07:58:52 -0700 (PDT) In-Reply-To: <20150805141145.GA21009@ox> References: <20150805141145.GA21009@ox> From: Pratik Singhal Date: Wed, 5 Aug 2015 20:28:52 +0530 Message-ID: Subject: Re: Compilation error due to header not found To: Pratik Singhal , freebsd-hackers , FreeBSD Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 14:59:14 -0000 Thanks a lot! for the hint! Although, I didn't make any direct changes in SRCS in Makefile, I used "device sound" in the config file used to compile the kernel and the channel_if.h file was generated. Thanks, Pratik Singhal On Wed, Aug 5, 2015 at 7:41 PM, Navdeep Parhar wrote: > On Wed, Aug 05, 2015 at 06:13:03PM +0530, Pratik Singhal wrote: > > Hello all, I have used the file "dev/sound/pcm/sound.h" in a kernel > driver > > made for ac97 codec for Allwinner A10. This file further includes the > file > > "dev/sound/pcm/channel.h" which further includes the file "channel_if.h". > > > > I have checked in ~HEAD and the file channel_if.h doesn't exist in that > > particular directory and as a result, I am getting a compilation error > when > > I compile the kernel complaining about the missing file "channel_if.h" . > > > > How can I resolve this error ? > > There is a channel_if.m in the tree. The build system should be able to > create channel_if.h from that if you list channel_if.h in SRCS in your > Makefile. > > Regards, > Navdeep > -- Regards, Pratik Singhal From owner-freebsd-hackers@freebsd.org Wed Aug 5 15:01:32 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 624F79B40EB for ; Wed, 5 Aug 2015 15:01:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) by mx1.freebsd.org (Postfix) with SMTP id 44A031C1D for ; Wed, 5 Aug 2015 15:01:31 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 5 Aug 2015 14:59:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t75F1TLU020651; Wed, 5 Aug 2015 09:01:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1438786889.70393.149.camel@freebsd.org> Subject: Re: Compilation error due to header not found From: Ian Lepore To: Navdeep Parhar Cc: Pratik Singhal , freebsd-hackers , FreeBSD Questions Date: Wed, 05 Aug 2015 09:01:29 -0600 In-Reply-To: <20150805141145.GA21009@ox> References: <20150805141145.GA21009@ox> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:01:32 -0000 On Wed, 2015-08-05 at 07:11 -0700, Navdeep Parhar wrote: > On Wed, Aug 05, 2015 at 06:13:03PM +0530, Pratik Singhal wrote: > > Hello all, I have used the file "dev/sound/pcm/sound.h" in a kernel driver > > made for ac97 codec for Allwinner A10. This file further includes the file > > "dev/sound/pcm/channel.h" which further includes the file "channel_if.h". > > > > I have checked in ~HEAD and the file channel_if.h doesn't exist in that > > particular directory and as a result, I am getting a compilation error when > > I compile the kernel complaining about the missing file "channel_if.h" . > > > > How can I resolve this error ? > > There is a channel_if.m in the tree. The build system should be able to > create channel_if.h from that if you list channel_if.h in SRCS in your > Makefile. > > Regards, > Navdeep That's the solution if it's a module build that's failing. If the driver is compiled into the kernel, maybe you just need to add "device sound" to your config. -- Ian From owner-freebsd-hackers@freebsd.org Wed Aug 5 15:54:31 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 603829B4B4B for ; Wed, 5 Aug 2015 15:54:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DA9616D8 for ; Wed, 5 Aug 2015 15:54:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 46D7FB94F; Wed, 5 Aug 2015 11:54:30 -0400 (EDT) From: John Baldwin To: Mario Lobo Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Date: Wed, 05 Aug 2015 08:39:11 -0700 Message-ID: <2167403.C3gzAhEsMN@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150805100401.265ca50f@Papi> References: <20150710213752.473cb831@Papi> <1678045.UlXctAKXAD@ralph.baldwin.cx> <20150805100401.265ca50f@Papi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Aug 2015 11:54:30 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:54:31 -0000 On Wednesday, August 05, 2015 10:04:01 AM Mario Lobo wrote: > On Tue, 04 Aug 2015 13:18:21 -0700 > John Baldwin wrote: > > > On Sunday, July 12, 2015 03:23:21 PM Mario Lobo wrote: > > > On Sat, 11 Jul 2015 15:50:06 +0200 > > > "Herbert J. Skuhra" wrote: > > > > > > > On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote: > > > > > Hi; > > > > > > > > > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS to > > > > > the latest version but the problem also showed with the previous > > > > > version. > > > > > > > > > > Here is my amd64 10-STABLE setup: > > > > > > > > > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT > > > > > 2015 amd64 > > > > > > > > > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class > > > > > CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 Model=0x2 > > > > > Stepping=0 > > Can you run 'kgdb' as root and get the output of 'p amd_pminfo'? > > (kgdb) p amd_pminfo > $1 = 2009 Ok, AMDPM_HW_PSTATE is set. > > Hmm, do you have an acpi_perf0 device? If not, then your CPU isn't > > supported without BIOS help. > > No acpi_perf0 device present Ok, in that case the hwpstate driver doesn't know how to handle your CPU. It only has a manual fall back for older CPUs: static int hwpstate_get_info_from_msr(device_t dev) { ... switch(family) { case 0x11: /* fid/did to frequency */ hwpstate_set[i].freq = 100 * (fid + 0x08) / (1 << did); break; case 0x10: /* fid/did to frequency */ hwpstate_set[i].freq = 100 * (fid + 0x10) / (1 << did); break; default: HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD family %d CPU's are not implemented yet. sorry.\n", family); return (ENXIO); break; } ... } (Your CPU is family 0x15 as you can see from dmesg.) > > First check to see if there are any BIOS > > options to control CPU throttling that are currently disabled. > > The only BIOS option that deals with throttling is Cool'n'Quiet, which > is enabled. You might try checking if C1E is enabled. Also, if you have done any overclocking you might try disabling that. It might also be that your BIOS is not telling us about Cool N Quiet for some other reason. Can you get an ACPI dump? > I get this though: > > [~]>dmesg -a | grep acpi_ > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > acpi_button0: on acpi0 > acpi_throttle0: on cpu0 As I mentioned previously, acpi_throttle is useless for you. Yes, it does slow your CPU down, but it doesn't save you very much power (if any). -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 5 15:54:29 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1E529B4B48 for ; Wed, 5 Aug 2015 15:54:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CC30F16D7 for ; Wed, 5 Aug 2015 15:54:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DF89CB91E; Wed, 5 Aug 2015 11:54:28 -0400 (EDT) From: John Baldwin To: Philippe Jalaber Cc: freebsd-hackers@freebsd.org Subject: Re: adaptive rwlock deadlock Date: Wed, 05 Aug 2015 08:41:15 -0700 Message-ID: <1902697.ny7xAkAVI4@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <2768515.JZVZhYiQVE@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 05 Aug 2015 11:54:29 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 15:54:30 -0000 On Wednesday, August 05, 2015 04:27:53 PM Philippe Jalaber wrote: > 2015-08-04 22:10 GMT+02:00 John Baldwin : > > > On Tuesday, July 07, 2015 12:10:19 PM Philippe Jalaber wrote: > > > Hi, > > > > > > I am facing a strange problem using the network stack and adaptive > > rwlocks > > > running Freebsd 9.3. > > > Basically I can reproduce the problem with 3 threads: > > > > > > 1) thread 1 has taken the rwlock of structure inpcb in exclusive mode in > > > tcp_input.c. This thread also runs my own code and repeatedly takes a > > > rwlock (called g_rwlock) in shared mode and releases it, until a shared > > > object is marked not "busy" any more: > > > > > > rwlock(inp_lock); > > > .... > > > do { // thread is active waiting in the loop > > > rlock(g_rwlock); > > > o = find(); > > > if ( o == NULL ) > > > break; > > > busy = o.busy; > > > if (o != NULL && busy) > > > runlock(g_rwlock); > > > } while ( busy ); > > > > > > if ( o != NULL ) > > > { > > > // do something with o > > > .... > > > } > > > runlock(g_rwlock); > > > .... > > > > > > 2) thread 2 wants to set the shared object as "ready". So it tries to > > take > > > g_rwlock in exclusive mode and is blocked in _rw_wlock_hard@kern_rwlock.c > > :815 > > > "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because thread 1 > > has > > > already taken it in shared mode: > > > > > > wlock(g_rwlock); > > > o = find(); > > > if ( o != NULL ) > > > o.busy = 1; > > > wunlock(g_rwlock); > > > > > > // o is busy so work on it without any lock > > > .... > > > > > > wlock(g_rwlock); // thread is blocked here > > > o.busy = 0; > > > maybe_delete(o); > > > wunlock(g_rwlock); > > > > > > 3) thread 3 spins on the same inpcb rwlock than thread 1 in > > > _rw_wlock_hard@kern_rwlock.c:721 "while ((struct > > > thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " > > > > > > > > > My target machine has two cpus. > > > Thread 1 is pinned to cpu 0. > > > Thread 2 and Thread 3 are pinned to cpu 1. > > > Thread 1 and Thread 2 have a priority of 28. > > > Thread 3 has a priority of 127 > > > > > > Now what seems to happen is that when thread 1 calls runlock(g_rwlock), > > it > > > calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never regains > > > control because thread 3 is spinning on the inpcb rwlock. Also the > > > condition TD_IS_RUNNING(owner) is always true because thread 1 is active > > > waiting in a loop. So the 3 threads deadlock. > > > Note that if I compile the kernel without adaptive rwlocks it works > > without > > > any problem. > > > A workaround is to add a call to "sched_relinquish(curthread)" in thread > > 1 > > > in the loop just after the call to runlock. > > > > It sounds like we are not forcing a preemption on CPU 1 in this case via > > sched_add(). > > > > For SCHED_4BSD you could try the 'FULL_PREEMPTION' kernel option. > > For ULE you can adjust 'preempt_thresh' on the fly, though I think the > > default setting should actually still work. > > > > Can you use KTR or some such to determine if IPI_PREEMPT is being sent by > > CPU 0 to CPU 1 in this case? > > > > > I am also wondering about the code in _rw_runlock after > > > "turnstile_broadcast(ts, queue)". Isn't the flag RW_LOCK_WRITE_WAITERS > > > definitely lost if the other thread which is blocked in turnstile_wait > > > never regains control ? > > > > All the write waiters are awakened by a broadcast (as opposed to a signal > > operation). They are on the run queue, not on the turnstile queue anymore, > > so there aren't any write waiters left (the bit only tracks if there are > > waiters on the turnstile). > > > > -- > > John Baldwin > > > > I Use ULE scheduler. > Here's the KTR output using ktrdump on a vmcore after watchdog. > > 75447 ipi_selected: cpu: 1 ipi: fc > 75446 stop_cpus() with 252 type > 75445 ipi_cpu: cpu: 1 ipi: 2 > 75444 ipi_cpu: cpu: 1 ipi: 2 > 75443 ipi_cpu: cpu: 1 ipi: 2 > 75442 ipi_cpu: cpu: 1 ipi: 2 > 75441 ipi_cpu: cpu: 1 ipi: 2 > .... > 3862 ipi_cpu: cpu: 1 ipi: 2 > 3861 ipi_cpu: cpu: 1 ipi: 2 > 3860 ipi_cpu: cpu: 1 ipi: 2 > 3859 ipi_cpu: cpu: 1 ipi: 2 > 3858 ipi_cpu: cpu: 1 ipi: 2 > 3857 ipi_selected: cpu: 1 ipi: f3 > 3856 ipi_cpu: cpu: 1 ipi: 2 > 3855 ipi_cpu: cpu: 1 ipi: 2 > 3854 ipi_cpu: cpu: 1 ipi: 2 > 3853 ipi_selected: cpu: 0 ipi: f3 > 3852 ipi_cpu: cpu: 1 ipi: 2 > 3851 ipi_selected: cpu: 1 ipi: f3 > 3850 ipi_cpu: cpu: 1 ipi: 2 > 3849 ipi_cpu: cpu: 1 ipi: 2 > 3848 ipi_selected: cpu: 0 ipi: f3 > 3847 ipi_cpu: cpu: 1 ipi: 2 > 3846 ipi_cpu: cpu: 1 ipi: 2 > 3845 ipi_cpu: cpu: 1 ipi: 2 > 3844 ipi_cpu: cpu: 1 ipi: 2 > 3843 ipi_cpu: cpu: 1 ipi: 2 > 3842 ipi_cpu: cpu: 1 ipi: 2 > 3841 ipi_cpu: cpu: 1 ipi: 2 > 3840 ipi_cpu: cpu: 1 ipi: 2 > 3839 ipi_cpu: cpu: 1 ipi: 2 > 3838 ipi_cpu: cpu: 1 ipi: 2 > 3837 ipi_cpu: cpu: 1 ipi: 2 > 3836 ipi_cpu: cpu: 1 ipi: 2 > 3835 ipi_cpu: cpu: 0 ipi: 1 > 3834 ipi_cpu: cpu: 0 ipi: 1 > 3833 ipi_cpu: cpu: 0 ipi: 1 > 3832 ipi_cpu: cpu: 0 ipi: 1 > 3831 ipi_cpu: cpu: 0 ipi: 1 > 3830 ipi_cpu: cpu: 0 ipi: 1 Unfortunately this has a lot of other noise. Can you add some traces specifically in sched_ule in tdq_notify to note that it is deciding to notify a CPU due to scheduling a thread? -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 5 19:10:35 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CCD59B4BF6 for ; Wed, 5 Aug 2015 19:10:35 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 411431CE2 for ; Wed, 5 Aug 2015 19:10:35 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: by obbfr1 with SMTP id fr1so2430518obb.1 for ; Wed, 05 Aug 2015 12:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=u8CHkRJDB8BLn6fLIeBcwOyB9Z77cBMa29QuSjZTR8I=; b=Yj45Xe6HedKjkj7/K4Dtmqx9h32cWGxRy8WD3f0a7Nysm3OYQjXBnok2is9/o1Gm9P REKzaOYd4bTXSvmaMcAe7MJ8k2Gpmb4hmlUCIPA6/IyFCbsLXQCYTfoRR2sWHfpSC84c Mvv0FoNevdmArRopX7lq2SxFWjYeFguuAtLrM5M/9MOJgrww9BdyBFPJ6Ow00Qdeey1h u0tHChK67SNNLaoSwDNXC4bspMrewVx6Lcp/fuwfvG540HEzLfx4huHDO1qezX87GjFz vYYmEay3xwc2yf25HnfrqhmYO6A7ex8GUXXZX5QRB+zbhS1ewzqnE9Aif52Of7+bD8h+ aiyg== MIME-Version: 1.0 X-Received: by 10.182.153.228 with SMTP id vj4mr9772761obb.83.1438801834393; Wed, 05 Aug 2015 12:10:34 -0700 (PDT) Received: by 10.202.129.139 with HTTP; Wed, 5 Aug 2015 12:10:34 -0700 (PDT) Date: Wed, 5 Aug 2015 14:10:34 -0500 Message-ID: Subject: Sparc64 support From: Bill Sorenson To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 05 Aug 2015 20:13:35 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 19:10:35 -0000 I have been advised to post this in this list. I was going to rewrite this a bit but I'm not sure what parts people will be interested. Anyway: I'm one of probably a few users of FreeBSD and OpenBSD on multiple platforms left and I thought I'd share some of my experience with BSD on some of the lesser used platforms. I manage a fair number of systems, most of them running FreeBSD on 64-bit Intel, but I probably have more sparc64 and powerpc systems running now than on i386. I have made it a bit of a specialty of mine to make use of BSD on existing equipment owned by a customer in a Solaris or OS X (or some other, older Unix...) environment and migrating their special sauce to run on it (or it could be as simple as setting up a FreeBSD Samba server on an existing G5 Mac they own). There are a lot of old SunFire servers running Solaris out there that will take years to die, and a lot of companies aren't excited about buying a lot of new hardware and porting their code over to Linux (thank goodness). When they start to run into software support and management issues, I've found FreeBSD to be a relatively easy sell. They get an up to date modern OS with modern ports available and usually migrating their C code or perl isn't much of an issue. They get to hold off on buying hardware until there is a direct need (accounting really loves this). The advantage for me is that when these companies start looking at new hardware with the latest Xeon, they're already running FreeBSD 9.3 or 10.1. Their code is already ported, the software they're now using is already available and works. When they move, its basically a recompile and its good to go. These customers stick to BSD and forget about Linux or paying Oracle more money. Everything just works and they couldn't be happier. I've always been interested in the older and more unusual hardware, its a big part of how I found a niche in supporting it on a professional level. Personally I run a sparc64 server, a powerpc G5 Xserve, a Alpha based DS20L running OpenBSD and an old 68k Mac running NetBSD, partly for fun and partly to make sure I can support my clients (ok, the 68k Mac is purely for fun). I've found a lot of value in FreeBSD's support for older platforms for getting my foot in the door with a lot of customers. Yes sparc64 isn't the future for FreeBSD but I still think it is very much the present. Its not dead yet, there are a lot of users of this old gear out there if you know where to look. For a company that has never heard of FreeBSD to adopt it because it will extend the life of their hardware I think that is a very powerful thing. -Bill Sorenson From owner-freebsd-hackers@freebsd.org Wed Aug 5 22:02:30 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE8CF9B4697 for ; Wed, 5 Aug 2015 22:02:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [66.135.54.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9500E14C4 for ; Wed, 5 Aug 2015 22:02:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 034A35606D; Wed, 5 Aug 2015 17:02:23 -0500 (CDT) Date: Wed, 5 Aug 2015 17:02:23 -0500 From: Mark Linimon To: Bill Sorenson Cc: freebsd-hackers@freebsd.org Subject: Re: Sparc64 support Message-ID: <20150805220223.GA18373@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Wed, 05 Aug 2015 22:30:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:02:30 -0000 I'm glad to see I'm not alone in tier-2 interest :-) The v215/v245 type machines are becoming available for very cheap now. I have one of each. The v210/v240 type machines are mostly heading for scrap, however. Everything before that generation already is. FWIW, the v215 I have been running very hard on 10.2PRE as a poudriere machine. It is quite stable. The sun4v machines are becoming available a little less cheap. A couple of people have expressed an interest in trying to resurrect FreeBSD/sun4v but I don't think anything has happened yet. I'm still staring at this IBM 7029 I can't get to boot properly. Every once in a while I poke at it. I have a powermac G5 up and going on 10.2PRE but it doesn not seem stable. I do not know if this is hardware or software. The Xserve G5 is currently powered down. I intend to re-test the bits on it at some point. mcl From owner-freebsd-hackers@freebsd.org Wed Aug 5 22:54:13 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 74D179B4832; Wed, 5 Aug 2015 22:54:13 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 059DB165; Wed, 5 Aug 2015 22:54:12 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B2272CF.dip0.t-ipconnect.de [91.34.114.207]) (authenticated bits=128) by slim.berklix.org (8.14.5/8.14.5) with ESMTP id t75MvQHe040082; Thu, 6 Aug 2015 00:57:26 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id t75MsBIx062976; Thu, 6 Aug 2015 00:54:11 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id t75Mrrru040232; Thu, 6 Aug 2015 00:54:05 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201508052254.t75Mrrru040232@fire.js.berklix.net> To: advocacy@freebsd.org cc: freebsd-hackers@freebsd.org, Bill Sorenson Subject: Re: Sparc64 support From: "Julian H. Stacey" Organization: http://berklix.com BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Wed, 05 Aug 2015 14:10:34 -0500." Date: Thu, 06 Aug 2015 00:53:53 +0200 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:54:13 -0000 Hi advocacy@freebsd.org An interesting concluding point on hackers@ ... > For a company that has never heard of FreeBSD to adopt it > because it will extend the life of their hardware I think that is a very > powerful thing. > > -Bill Sorenson Thread here: http://lists.freebsd.org/pipermail/freebsd-hackers/2015-August/048090.html Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Reply after previous text, like a play - Not before, which looses context. Indent previous text with "> " Insert new lines before 80 chars. Send plain text, Not quoted-printable, Not HTML, Not ms.doc, Not base64. Subsidise contraception V. Global warming, pollution, famine, migration. From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:07:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6B879B4C5C for ; Wed, 5 Aug 2015 23:07:39 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AE62D8C for ; Wed, 5 Aug 2015 23:07:38 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by qgeh16 with SMTP id h16so41506612qge.3 for ; Wed, 05 Aug 2015 16:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type; bh=U2HLjhp56JBMGLWJYJa6KFyo/4vNRvP2B9CtIQs5TUQ=; b=CtyWK4Gvb5+c7UyfmdKtafZvLCPlN4Y6ksetAqE7+/QM84GqKwsXeMMyaTUiFMJhac QoyzjJJHS8QFA8kdWAMTtVyriz4dRk8eUhSMkTryEx0fmAWh44PtCfj+6IhXDGo6a0Gz vWbmwCk4dr/5Psu8xEqxPHsvTjQt2ntVsarbw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-type; bh=U2HLjhp56JBMGLWJYJa6KFyo/4vNRvP2B9CtIQs5TUQ=; b=cwQXED/Z6nJOBs4XdAw59/c4al+iE2JwLb7wwRTpOjo0tfsr1d/nOlFZoqEGg21Ebt V83d4+q21sfnv2KVlUpxCnro0WwUmvl3PiDU5cYFJWqUZ5JhGtILm8zNMmlmkEA/L+PU FvVz2pOctsD6Lz4S1J6osRGVF3BuYG1CYQpNdSLhXD4cstciIZh3vRXJ8IeVdlJgLOkx 6XU8Sb6BbmB9GZ6tazvUJAyRcYjv+VopXMVYn/DRqWc8l/uS7OjC9r4PKO/mqh+/A+xV T6DjgM97D3MI9+/0ZUWfGG0oHLfcCe1O4BqpJEl3nY0qMtaq5oDjkBxGGWLJktOh5w0D s4OA== X-Gm-Message-State: ALoCoQnNPjUzjBqtmb4qfvIeNRoP2YBwMpnlM+CqNKtn0jeyQTj/rlnpXY3cNaYfwazTsIrmB+CX X-Received: by 10.140.233.9 with SMTP id e9mr22632725qhc.71.1438816057033; Wed, 05 Aug 2015 16:07:37 -0700 (PDT) Received: from Papi ([177.98.27.21]) by smtp.gmail.com with ESMTPSA id f4sm2210131qga.5.2015.08.05.16.06.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 16:07:35 -0700 (PDT) Date: Wed, 5 Aug 2015 20:10:52 -0300 From: Mario Lobo To: John Baldwin Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150805201052.4ed76a4e@Papi> In-Reply-To: <2167403.C3gzAhEsMN@ralph.baldwin.cx> References: <20150710213752.473cb831@Papi> <1678045.UlXctAKXAD@ralph.baldwin.cx> <20150805100401.265ca50f@Papi> <2167403.C3gzAhEsMN@ralph.baldwin.cx> Organization: BSD X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Aug 2015 23:45:41 +0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:07:40 -0000 On Wed, 05 Aug 2015 08:39:11 -0700 John Baldwin wrote: > On Wednesday, August 05, 2015 10:04:01 AM Mario Lobo wrote: > > On Tue, 04 Aug 2015 13:18:21 -0700 > > John Baldwin wrote: > > > > > On Sunday, July 12, 2015 03:23:21 PM Mario Lobo wrote: > > > > On Sat, 11 Jul 2015 15:50:06 +0200 > > > > "Herbert J. Skuhra" wrote: > > > > > > > > > On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote: > > > > > > Hi; > > > > > > > > > > > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS > > > > > > to the latest version but the problem also showed with the > > > > > > previous version. > > > > > > > > > > > > Here is my amd64 10-STABLE setup: > > > > > > > > > > > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT > > > > > > 2015 amd64 > > > > > > > > > > > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class > > > > > > CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15 > > > > > > Model=0x2 Stepping=0 John; First of all, thanks for looking into this. > > > Can you run 'kgdb' as root and get the output of 'p amd_pminfo'? > > > > (kgdb) p amd_pminfo > > $1 = 2009 > > Ok, AMDPM_HW_PSTATE is set. Yes! > > > > Hmm, do you have an acpi_perf0 device? If not, then your CPU > > > isn't supported without BIOS help. > > > > No acpi_perf0 device present > > Ok, in that case the hwpstate driver doesn't know how to handle your > CPU. It only has a manual fall back for older CPUs: > > static int > hwpstate_get_info_from_msr(device_t dev) > { > ... > switch(family) { > case 0x11: > /* fid/did to frequency */ > hwpstate_set[i].freq = 100 * (fid + 0x08) / > (1 << did); break; > case 0x10: > /* fid/did to frequency */ > hwpstate_set[i].freq = 100 * (fid + 0x10) / > (1 << did); break; > default: > HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD > family %d CPU's are not implemented yet. sorry.\n", family); return > (ENXIO); break; > } > ... > } > > (Your CPU is family 0x15 as you can see from dmesg.) > Yeah :(. Ok. > > > First check to see if there are any BIOS > > > options to control CPU throttling that are currently disabled. > > > > The only BIOS option that deals with throttling is Cool'n'Quiet, > > which is enabled. > > You might try checking if C1E is enabled. Also, if you have done any > overclocking you might try disabling that. C1E is enable and so is C6. But, good news! [~]>dmesg -a | grep hwpstate hwpstate0: on cpu0 dev.hwpstate.0.freq_settings: 3200/10235 2800/8393 2300/6221 1800/4471 1400/3135 dev.cpu.0.freq_levels: 3200/10235 2800/8393 2300/6221 1800/4471 1400/3135 There was an option in the BIOS called HPC, which stands for High Power Ccomputing (whatever that means) that, as soon as I disabled it, hwpstate showed up. I disabled acpi_throttle and the frequencies are still being throttled. I must point out that the lowest frequency with acpi_throttle enabled was 875 and now is 1400. But you were right! With hwpstate, I can see that the temperature of the CPU is much lower, despite the fact that the lowest frequency is higher that before, which means that hwpstate is really more efficient. I don't know if the list will allow it but I'm attaching a BIOS picture. > > It might also be that your BIOS is not telling us about Cool N Quiet > for some other reason. Can you get an ACPI dump? Also attaching a zipped output of acpidump. I'll send both attachments privately just in case the list dumps them. > > > I get this though: > > > > [~]>dmesg -a | grep acpi_ > > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > acpi_button0: on acpi0 > > acpi_throttle0: on cpu0 > > As I mentioned previously, acpi_throttle is useless for you. Yes, it > does slow your CPU down, but it doesn't save you very much power (if > any). > Indeed !! Again, thanks for helping ! -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio.... YET!!] "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:48:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53ED19B4544 for ; Wed, 5 Aug 2015 23:48:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EF9F1DD2 for ; Wed, 5 Aug 2015 23:48:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by iodb91 with SMTP id b91so5363957iod.1 for ; Wed, 05 Aug 2015 16:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kX9wETTdX0GDncJG5uSkFBnUU9kHndsn+874SKHuWVk=; b=kRJOfnCWKc/Xhq+iSvvo4rnWYZ7AiX128S5FEr2wKIuHQ98PZuIvXtkVjXNrXo2e6Q CGgjGsEDznSTePR3WXg4qtFuSeyKnvowwbeTtlh8eiFloVjmqNBuc1ENHo3QFv5x+s/4 NNNyA97qgh+mZ8c/B9eRHUTjA4YNH4BuaTfFqpp/DQAXGm84B6XBi91+0TZBkppD7bHR GBYe1+qzDEMXBtv+E2AupGaTMniVCEXOxGYGayUcddIY8eaEr2wFm7tg0YqukXdssjk8 SzJSBsCSa/6u+nESkdk2XwVp5NNk5XLnMnUyBDqqZShSX80K7bNotQBYuTSNpdD5fS99 dWog== MIME-Version: 1.0 X-Received: by 10.107.157.133 with SMTP id g127mr681874ioe.102.1438818493520; Wed, 05 Aug 2015 16:48:13 -0700 (PDT) Received: by 10.107.169.94 with HTTP; Wed, 5 Aug 2015 16:48:13 -0700 (PDT) Date: Wed, 5 Aug 2015 19:48:13 -0400 Message-ID: Subject: vm_lowmem is prevented every 2**31 ticks From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:48:14 -0000 Currently vm_pageout_scan() uses a calculation on ticks to rate-limit the number of vm_lowmem() events. The calculation that it uses is: if (vmd == &vm_dom[0] && pass > 0 && (ticks - lowmem_ticks) / hz >= lowmem_period) The problem with this code is that there is no guarantee that vm_pageout_scan() will be called with pass > 0 within any time period. This can mean that (for example) lowmem_ticks could have been 0 an arbitrarily long time ago, and if ticks happens to be negative when we are running low on memory, the result of ticks - lowmem_ticks will be negative and the condition will not be true until ticks goes positive again. A coworker suggested casting the result of the subtraction to a u_int. This narrows the window considerably (down to 2 * lowmem_period seconds), but it's not possible to eliminate the problem entirely as long as we use ticks. I am tempted to just call getbintime() instead. Low memory events should be infrequent enough that calling getbintime() should be ok. Unless somebody has an objection or an alternate solution, I'll put together a patch using getbintime() and get that into phabricator. From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:59:33 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78E579B49D1 for ; Wed, 5 Aug 2015 23:59:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id 5910635E for ; Wed, 5 Aug 2015 23:59:33 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 5 Aug 2015 23:59:42 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t75NxU1e021561; Wed, 5 Aug 2015 17:59:30 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1438819170.70393.227.camel@freebsd.org> Subject: Re: vm_lowmem is prevented every 2**31 ticks From: Ian Lepore To: Ryan Stone Cc: "freebsd-hackers@freebsd.org" Date: Wed, 05 Aug 2015 17:59:30 -0600 In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:59:33 -0000 On Wed, 2015-08-05 at 19:48 -0400, Ryan Stone wrote: > Currently vm_pageout_scan() uses a calculation on ticks to rate-limit the > number of vm_lowmem() events. The calculation that it uses is: > > if (vmd == &vm_dom[0] && pass > 0 && > (ticks - lowmem_ticks) / hz >= lowmem_period) > > > The problem with this code is that there is no guarantee that > vm_pageout_scan() will be called with pass > 0 within any time period. > This can mean that (for example) lowmem_ticks could have been 0 an > arbitrarily long time ago, and if ticks happens to be negative when we are > running low on memory, the result of ticks - lowmem_ticks will be negative > and the condition will not be true until ticks goes positive again. > > A coworker suggested casting the result of the subtraction to a u_int. > This narrows the window considerably (down to 2 * lowmem_period seconds), > but it's not possible to eliminate the problem entirely as long as we use > ticks. I am tempted to just call getbintime() instead. Low memory events > should be infrequent enough that calling getbintime() should be ok. > > Unless somebody has an objection or an alternate solution, I'll put > together a patch using getbintime() and get that into phabricator. If you're measuring elapsed time, please use getbinuptime() rather than the time of day clock (which can be stepped arbitrarily). Hey wait a sec... if it's currently some_ticks/hz it's counting seconds, right? So no need to mess with bintimes, if whole seconds are good enough just use the global time_uptime. -- Ian From owner-freebsd-hackers@freebsd.org Thu Aug 6 05:00:41 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB5C49B4301 for ; Thu, 6 Aug 2015 05:00:41 +0000 (UTC) (envelope-from joel@vnode.se) Received: from smtp.vnode.se (smtp.vnode.se [IPv6:2001:67c:40c:e3aa::5]) by mx1.freebsd.org (Postfix) with ESMTP id 8F5AA112D for ; Thu, 6 Aug 2015 05:00:41 +0000 (UTC) (envelope-from joel@vnode.se) Received: from ymer.vnode.se (h71n10-th-c-d4.ias.bredband.telia.com [81.234.63.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.vnode.se (Postfix) with ESMTPSA id CDF97100A4; Thu, 6 Aug 2015 07:00:37 +0200 (CEST) Date: Thu, 6 Aug 2015 07:00:37 +0200 From: Joel Dahl To: Bill Sorenson Cc: freebsd-hackers@freebsd.org Subject: Re: Sparc64 support Message-ID: <20150806050037.GA29982@ymer.vnode.se> Mail-Followup-To: Bill Sorenson , freebsd-hackers@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 05:00:41 -0000 On Wed, Aug 05, 2015 at 02:10:34PM -0500, Bill Sorenson wrote: > I have been advised to post this in this list. I was going to rewrite this > a bit but I'm not sure what parts people will be interested. Anyway: If you want to help with sparc64, add yourself here: https://wiki.freebsd.org/FreeBSD/sparc64/Volunteers FWIW, I'm in a similar situation as you. I have several sparc64 and powerpc machines in a data center running FreeBSD. -- Joel From owner-freebsd-hackers@freebsd.org Thu Aug 6 08:09:52 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3F489B5F87 for ; Thu, 6 Aug 2015 08:09:52 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 847FB1CAC; Thu, 6 Aug 2015 08:09:52 +0000 (UTC) (envelope-from pjalaber@gmail.com) Received: by qged69 with SMTP id d69so47725918qge.0; Thu, 06 Aug 2015 01:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dFOICkh4lmpElbmqui5QFgO7Q//PF0osY1MDQ4zgQw0=; b=KUWDo9pWz+WX1blF/kF+PR+hfLH0dmS+p2NDq4XzVFsBFykPeDwlv8hWNJU21e6nSb wfg20alWwIjK7+YI5oMH8Rz/mFw2vvg5AtFfsj5sF0eCkSvuN0vbJCDYy0UaxIXGPhC0 ZZqK+56zQJmZZrkxOy3CgJzaICEuAJcJ+mtkgFCzHWE0fupKl7IunN9euvAeiT3mWaNO IR3u3ObiZkLOhUyD5gVdPvJfNwVL3ZjgSOGcOwZTaZUI14d+LIy/e306ivgypeaPu00H O98k2JtTvO16C+SZCymzm4q9pC2Y1OXhLn8S/I023tZY19vY3Q6mudPvuN9lKamxxuuv AM8w== MIME-Version: 1.0 X-Received: by 10.140.31.74 with SMTP id e68mr646021qge.95.1438848591626; Thu, 06 Aug 2015 01:09:51 -0700 (PDT) Received: by 10.140.92.247 with HTTP; Thu, 6 Aug 2015 01:09:51 -0700 (PDT) In-Reply-To: <1902697.ny7xAkAVI4@ralph.baldwin.cx> References: <2768515.JZVZhYiQVE@ralph.baldwin.cx> <1902697.ny7xAkAVI4@ralph.baldwin.cx> Date: Thu, 6 Aug 2015 10:09:51 +0200 Message-ID: Subject: Re: adaptive rwlock deadlock From: Philippe Jalaber To: John Baldwin Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 08:09:52 -0000 2015-08-05 17:41 GMT+02:00 John Baldwin : > On Wednesday, August 05, 2015 04:27:53 PM Philippe Jalaber wrote: > > 2015-08-04 22:10 GMT+02:00 John Baldwin : > > > > > On Tuesday, July 07, 2015 12:10:19 PM Philippe Jalaber wrote: > > > > Hi, > > > > > > > > I am facing a strange problem using the network stack and adaptive > > > rwlocks > > > > running Freebsd 9.3. > > > > Basically I can reproduce the problem with 3 threads: > > > > > > > > 1) thread 1 has taken the rwlock of structure inpcb in exclusive > mode in > > > > tcp_input.c. This thread also runs my own code and repeatedly takes a > > > > rwlock (called g_rwlock) in shared mode and releases it, until a > shared > > > > object is marked not "busy" any more: > > > > > > > > rwlock(inp_lock); > > > > .... > > > > do { // thread is active waiting in the loop > > > > rlock(g_rwlock); > > > > o = find(); > > > > if ( o == NULL ) > > > > break; > > > > busy = o.busy; > > > > if (o != NULL && busy) > > > > runlock(g_rwlock); > > > > } while ( busy ); > > > > > > > > if ( o != NULL ) > > > > { > > > > // do something with o > > > > .... > > > > } > > > > runlock(g_rwlock); > > > > .... > > > > > > > > 2) thread 2 wants to set the shared object as "ready". So it tries to > > > take > > > > g_rwlock in exclusive mode and is blocked in > _rw_wlock_hard@kern_rwlock.c > > > :815 > > > > "turnstile_wait(ts, rw_owner(rw), TS_EXCLUSIVE_QUEUE)" because > thread 1 > > > has > > > > already taken it in shared mode: > > > > > > > > wlock(g_rwlock); > > > > o = find(); > > > > if ( o != NULL ) > > > > o.busy = 1; > > > > wunlock(g_rwlock); > > > > > > > > // o is busy so work on it without any lock > > > > .... > > > > > > > > wlock(g_rwlock); // thread is blocked here > > > > o.busy = 0; > > > > maybe_delete(o); > > > > wunlock(g_rwlock); > > > > > > > > 3) thread 3 spins on the same inpcb rwlock than thread 1 in > > > > _rw_wlock_hard@kern_rwlock.c:721 "while ((struct > > > > thread*)RW_OWNER(rw->rw_lock) == owner && TD_IS_RUNNING(owner)) " > > > > > > > > > > > > My target machine has two cpus. > > > > Thread 1 is pinned to cpu 0. > > > > Thread 2 and Thread 3 are pinned to cpu 1. > > > > Thread 1 and Thread 2 have a priority of 28. > > > > Thread 3 has a priority of 127 > > > > > > > > Now what seems to happen is that when thread 1 calls > runlock(g_rwlock), > > > it > > > > calls turnstile_broadcast@kern_rwlock.c:650, but thread 2 never > regains > > > > control because thread 3 is spinning on the inpcb rwlock. Also the > > > > condition TD_IS_RUNNING(owner) is always true because thread 1 is > active > > > > waiting in a loop. So the 3 threads deadlock. > > > > Note that if I compile the kernel without adaptive rwlocks it works > > > without > > > > any problem. > > > > A workaround is to add a call to "sched_relinquish(curthread)" in > thread > > > 1 > > > > in the loop just after the call to runlock. > > > > > > It sounds like we are not forcing a preemption on CPU 1 in this case > via > > > sched_add(). > > > > > > For SCHED_4BSD you could try the 'FULL_PREEMPTION' kernel option. > > > For ULE you can adjust 'preempt_thresh' on the fly, though I think the > > > default setting should actually still work. > > > > > > Can you use KTR or some such to determine if IPI_PREEMPT is being sent > by > > > CPU 0 to CPU 1 in this case? > > > > > > > I am also wondering about the code in _rw_runlock after > > > > "turnstile_broadcast(ts, queue)". Isn't the flag > RW_LOCK_WRITE_WAITERS > > > > definitely lost if the other thread which is blocked in > turnstile_wait > > > > never regains control ? > > > > > > All the write waiters are awakened by a broadcast (as opposed to a > signal > > > operation). They are on the run queue, not on the turnstile queue > anymore, > > > so there aren't any write waiters left (the bit only tracks if there > are > > > waiters on the turnstile). > > > > > > -- > > > John Baldwin > > > > > > > I Use ULE scheduler. > > Here's the KTR output using ktrdump on a vmcore after watchdog. > > > > 75447 ipi_selected: cpu: 1 ipi: fc > > 75446 stop_cpus() with 252 type > > 75445 ipi_cpu: cpu: 1 ipi: 2 > > 75444 ipi_cpu: cpu: 1 ipi: 2 > > 75443 ipi_cpu: cpu: 1 ipi: 2 > > 75442 ipi_cpu: cpu: 1 ipi: 2 > > 75441 ipi_cpu: cpu: 1 ipi: 2 > > .... > > 3862 ipi_cpu: cpu: 1 ipi: 2 > > 3861 ipi_cpu: cpu: 1 ipi: 2 > > 3860 ipi_cpu: cpu: 1 ipi: 2 > > 3859 ipi_cpu: cpu: 1 ipi: 2 > > 3858 ipi_cpu: cpu: 1 ipi: 2 > > 3857 ipi_selected: cpu: 1 ipi: f3 > > 3856 ipi_cpu: cpu: 1 ipi: 2 > > 3855 ipi_cpu: cpu: 1 ipi: 2 > > 3854 ipi_cpu: cpu: 1 ipi: 2 > > 3853 ipi_selected: cpu: 0 ipi: f3 > > 3852 ipi_cpu: cpu: 1 ipi: 2 > > 3851 ipi_selected: cpu: 1 ipi: f3 > > 3850 ipi_cpu: cpu: 1 ipi: 2 > > 3849 ipi_cpu: cpu: 1 ipi: 2 > > 3848 ipi_selected: cpu: 0 ipi: f3 > > 3847 ipi_cpu: cpu: 1 ipi: 2 > > 3846 ipi_cpu: cpu: 1 ipi: 2 > > 3845 ipi_cpu: cpu: 1 ipi: 2 > > 3844 ipi_cpu: cpu: 1 ipi: 2 > > 3843 ipi_cpu: cpu: 1 ipi: 2 > > 3842 ipi_cpu: cpu: 1 ipi: 2 > > 3841 ipi_cpu: cpu: 1 ipi: 2 > > 3840 ipi_cpu: cpu: 1 ipi: 2 > > 3839 ipi_cpu: cpu: 1 ipi: 2 > > 3838 ipi_cpu: cpu: 1 ipi: 2 > > 3837 ipi_cpu: cpu: 1 ipi: 2 > > 3836 ipi_cpu: cpu: 1 ipi: 2 > > 3835 ipi_cpu: cpu: 0 ipi: 1 > > 3834 ipi_cpu: cpu: 0 ipi: 1 > > 3833 ipi_cpu: cpu: 0 ipi: 1 > > 3832 ipi_cpu: cpu: 0 ipi: 1 > > 3831 ipi_cpu: cpu: 0 ipi: 1 > > 3830 ipi_cpu: cpu: 0 ipi: 1 > > Unfortunately this has a lot of other noise. Can you add some > traces specifically in sched_ule in tdq_notify to note that it > is deciding to notify a CPU due to scheduling a thread? > > -- > John Baldwin > OK. Here's the patch I have used in tdq_notify on Freebsd 9.3: --- kern/sched_ule.c 2015-08-06 09:03:49.000000000 +0200 +++ kern/sched_ule.c 2015-08-06 09:03:38.000000000 +0200 @@ -1020,6 +1020,7 @@ return; } tdq->tdq_ipipending = 1; + CTR3(KTR_SMP, "%s: cpu: %d IPI_PREEMPT=%x", __func__, cpu, IPI_PREEMPT); ipi_cpu(cpu, IPI_PREEMPT); } Please find the output of ktrdump in attachment. The last IPI_PREEMPT sent is at index #9424. Hope it helps. From owner-freebsd-hackers@freebsd.org Thu Aug 6 10:06:20 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B7509B5724 for ; Thu, 6 Aug 2015 10:06:20 +0000 (UTC) (envelope-from tjmaillists@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3D49AF7 for ; Thu, 6 Aug 2015 10:06:19 +0000 (UTC) (envelope-from tjmaillists@gmx.com) Received: from [151.28.139.29] by 3capp-mailcom-bs01.server.lan (via HTTP); Thu, 6 Aug 2015 12:06:11 +0200 Message-ID: From: "TJ Lee" To: freebsd-hackers@freebsd.org Subject: Trying to understand kernel trap code Date: Thu, 6 Aug 2015 12:06:11 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:aIQgE0H/grILEESyTr/+fzuY12FQtaCJG8fqTA7410E se4w3Fj//5bm/1EaRQM35fdfcTBHhIlwAlnwGpvMXQEq7vc+gd vFfxR3AbVtRDLjeIK5OJbU4vGCeCwfZcpa0ICMf3cegK/rkJgD S0QiGJ5wSkxDWWFaKQ1HGkpN/+GA6Y+ERPOfJ+dPx8nD6gqGuq JGntLq6Pm52VKxd6T29PMpir8FSYx9iUu1MjkuqC3GfyBLOPsG LYuBFZwYqwip/9AokQTJjaU/u2W45IX+YbOV2/yXl2YTsNF8GO MyKQ46JpFceakF89kknI8c70l/O X-UI-Out-Filterresults: notjunk:1;V01:K0:dbkQuL09wgs=:wl2k0Rv5KtlWWsovdEUmLe luXw9d3z9lEuxN4N7+L6iC29q/PBZuz8RkYVJuLHmGJBiaMpx9qL6wAaTmmP5nwvBQ1Ieo48c GpTf3Io2PgJHeut+8I4MN4yGVzPMmTM+Be3fWys6BL8Dg0A1nAH7ykVI/VStF2zCvrz+TJY2e aVFUUJblGUfXGaU8qnPH+u4PsYBnpJMrtJURo+x5TvWcRCCXE8Jmi6myRV2Qcjf+VTmxE1VeO 7+Wljs+JQqFvRqI1aFUqfLeRWxxKFNDRRc1Hfk8UpieRx929GW7trIzOrdngNGEUzvIzQjD1o R23KWPE56QWXLk5qaW1rfhsRf1IvlB0IMDbqSj9hB1BnG21Fjr+lKHnPYXcBCFdYk9vG0bnp4 1cpP1aEXAOoxow399X6WXs6y11AZfs0eyO9T8OchLsXOvYW4E2eINM8Ue95sN0eyOLc/383CC YnymIzYOJA== MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:06:20 -0000 From owner-freebsd-hackers@freebsd.org Thu Aug 6 10:09:13 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F73D9B5887 for ; Thu, 6 Aug 2015 10:09:13 +0000 (UTC) (envelope-from tjmaillists@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD526C94 for ; Thu, 6 Aug 2015 10:09:12 +0000 (UTC) (envelope-from tjmaillists@gmx.com) Received: from [151.28.139.29] by 3capp-mailcom-bs01.server.lan (via HTTP); Thu, 6 Aug 2015 12:09:05 +0200 MIME-Version: 1.0 Message-ID: From: "TJ Lee" To: freebsd-hackers@freebsd.org Subject: Trying to understand kernel trap code Content-Type: text/plain; charset=UTF-8 Date: Thu, 6 Aug 2015 12:09:05 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:2TKzMijC80nKhwspf2dY2MgICiKb9Q9Slf9hvr9hvVd JaGH1kWr3bT9/PdJ+HpQWWRVZdP1CfVr5K0S5eFOQ9ubJgxJiV pdmPLEflzvnGKoqhq/Oojf+3goQ1k3NyQO0KmdsQ6e/Hz0OPsV Hrxm+yPM7oDBHke22yvVamF++OtpprKkpLQc4VyPfJvdJbwiw2 TZ6or8+3D8vNKEP2G+t7rY2bVhpSoIWCo9PyE6XpgRCWXFrW1z POz5SJiA4doiNqYkpnXlnpNA6K31E8I5YunCCvVC0+8VknSuOF yHc2/KZO8/Ay/j3EwMHvD2NA9kZ X-UI-Out-Filterresults: notjunk:1;V01:K0:jw4fzeKIEDg=:2dQTyGBKbYSHMxrYkD8ume DpfcTpRsHImgQbi+hUy5Okco28uZu762hPORqG/ChTP/JT32GW5qi+2MyDOe3UGbJG8KL0tJN gYxvV/LAeE8uooE+JpCAB5kYFh7FIVotQ+R7ND2Z9C7BiafYnmHrRdbiRwj3B6e6uF0WspWLs Y2Cdtm0ZcaLTcaNaU9d34abs06+GUC4Nc8iZ2yX8b5CWD/PN2qr3yrgTE0oh4la8vhOeFZSBp GXddLFiUqNnmdl2RnEKUwxHiluKwKTbRIbwsP+u/SFXTuXqOIVHR0WQgMVLLWgc12/L9U1nBn CGjlTTL2hEnIT7nBbw0U7QLxogqE4D1Jv69nX5IOPysZOVpoE0dslXWGGHSgKQ293FS/I42J8 Vv7Owh4njXCKJz7q/B8vyARIbZjIeffRg5dBVH+S2rPRpXleQjPMQ5V0vcCmomLXlLtNvnpeO p6lM7ucg1A== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:09:13 -0000 Hi, I just started looking at FreeBSD kernel code in more detail and want to understand the low-level entry points into the kernel on a x86-64 CPU. What I'd like to know is precisely what happens when I execute a "syscall" instruction in user-land. More specifically, what instruction in what assembly source file is RIP/CS loaded with on executing syscall? Also where in the source code do we load the MSRs with these values? - tj From owner-freebsd-hackers@freebsd.org Thu Aug 6 10:22:10 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0F7D9B5C0F for ; Thu, 6 Aug 2015 10:22:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4D5014DC; Thu, 6 Aug 2015 10:22:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C99A91FE023; Thu, 6 Aug 2015 12:22:06 +0200 (CEST) Message-ID: <55C335A7.8020503@selasky.org> Date: Thu, 06 Aug 2015 12:23:35 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andriy Gapon , Konstantin Belousov CC: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> <558175FA.4040106@FreeBSD.org> <20150617165331.GA2080@kib.kiev.ua> <5582CCF1.8010505@FreeBSD.org> In-Reply-To: <5582CCF1.8010505@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:22:11 -0000 On 06/18/15 15:51, Andriy Gapon wrote: > On 17/06/2015 19:53, Konstantin Belousov wrote: >> AFAIR it was about 'sufficiently smart compiler' and the fact that the >> functions are not on the hottest paths. > > It seems that sufficiently smart compilers still do not exist :-) > At least as far as compilers that are used for compiling FreeBSD are considered. > > [Offtopic] my impression is that lately smartness of compilers is mostly being > improved by various tricks and shortcuts (undefined behavior, etc), rather than > by recognizing patterns in the C code that could be turned into more efficient > machine code. > Hi, Has there been any further thoughts on this topic during the summer? It sounds fair to me that "Sean Eron Anderson's Bit Twiddling Hacks" can be used in our code instead of a for() loop for the ffs() function, given that a 2-clause BSD license is fine by Sean. Typically the compilers can expand for loops using -O3, but I've never seen a compiler yet that convert for loops into a simpler functions where no constants are involved. For sake of readability I would leave the old implementation under "#if 0" so that readers not familiar with binary tricks can understand the code. Any strong objections? --HPS From owner-freebsd-hackers@freebsd.org Thu Aug 6 10:24:39 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63A5A9B5CE0 for ; Thu, 6 Aug 2015 10:24:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBB9E1659 for ; Thu, 6 Aug 2015 10:24:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t76AOYXT096861 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 6 Aug 2015 13:24:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t76AOYXT096861 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t76AOYTs096860; Thu, 6 Aug 2015 13:24:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 6 Aug 2015 13:24:34 +0300 From: Konstantin Belousov To: TJ Lee Cc: freebsd-hackers@freebsd.org Subject: Re: Trying to understand kernel trap code Message-ID: <20150806102434.GH2072@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:24:39 -0000 On Thu, Aug 06, 2015 at 12:09:05PM +0200, TJ Lee wrote: > Hi, > > I just started looking at FreeBSD kernel code in more detail and > want to understand the low-level entry points into the kernel on a > x86-64 CPU. What I'd like to know is precisely what happens when I > execute a "syscall" instruction in user-land. More specifically, what > instruction in what assembly source file is RIP/CS loaded with on > executing syscall? Also where in the source code do we load the MSRs > with these values? > Read the sys/amd64/amd64/exception.S, fast_syscall entry point. Grep for MSR_*STAR msr names to see how syscall MSRs are configured, in particular, on BSP in hammer_time(), on AP in init_secondary(). You need to read the IA32 manual about syscall instruction to understand how it all plays together. From owner-freebsd-hackers@freebsd.org Thu Aug 6 10:38:24 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43D699B5ECC for ; Thu, 6 Aug 2015 10:38:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3121BA1 for ; Thu, 6 Aug 2015 10:38:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 24E49B918; Thu, 6 Aug 2015 06:38:22 -0400 (EDT) From: John Baldwin To: Mario Lobo Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Date: Thu, 06 Aug 2015 03:29:27 -0700 Message-ID: <3449300.xgGQFUj9M8@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150805201052.4ed76a4e@Papi> References: <20150710213752.473cb831@Papi> <2167403.C3gzAhEsMN@ralph.baldwin.cx> <20150805201052.4ed76a4e@Papi> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 06 Aug 2015 06:38:22 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 10:38:24 -0000 On Wednesday, August 05, 2015 08:10:52 PM Mario Lobo wrote: > On Wed, 05 Aug 2015 08:39:11 -0700 > John Baldwin wrote: > > > > First check to see if there are any BIOS > > > > options to control CPU throttling that are currently disabled. > > > > > > The only BIOS option that deals with throttling is Cool'n'Quiet, > > > which is enabled. > > > > You might try checking if C1E is enabled. Also, if you have done any > > overclocking you might try disabling that. > > C1E is enable and so is C6. But, good news! > > [~]>dmesg -a | grep > hwpstate hwpstate0: on cpu0 > > dev.hwpstate.0.freq_settings: 3200/10235 2800/8393 2300/6221 1800/4471 > 1400/3135 dev.cpu.0.freq_levels: 3200/10235 2800/8393 2300/6221 > 1800/4471 1400/3135 > > There was an option in the BIOS called HPC, which stands for High Power > Ccomputing (whatever that means) that, as soon as I disabled it, > hwpstate showed up. I disabled acpi_throttle and the frequencies are > still being throttled. Ok, that definitely sounds like the solution then. -- John Baldwin From owner-freebsd-hackers@freebsd.org Fri Aug 7 20:32:36 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 743929B67A8 for ; Fri, 7 Aug 2015 20:32:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 525C1CCE for ; Fri, 7 Aug 2015 20:32:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B9250B926; Fri, 7 Aug 2015 16:32:34 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Bill Sorenson Subject: Re: Sparc64 support Date: Fri, 07 Aug 2015 12:53:11 -0700 Message-ID: <7311511.ISQt3RZVgq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Aug 2015 16:32:34 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:32:36 -0000 On Wednesday, August 05, 2015 02:10:34 PM Bill Sorenson wrote: > I'm one of probably a few users of FreeBSD and OpenBSD on multiple > platforms left and I thought I'd share some of my experience with BSD on > some of the lesser used platforms. Realistically, the major potential bump in the road for sparc64 is the toolchain. GCC 4.2.1 is getting really long in the tooth and as a Project we want to drop it as our system compiler. I can't tell you when that will happen, but it will eventually. That means that all of our supported platforms will either have to work with clang, or they will need to use an external GCC toolchain (of more recent vintage). Ensuring that one of these routes work for sparc64 will make it much easier for sparc64 to stay in the tree without inhibiting other work. My understanding is that the most recent clang in HEAD can at least build and install on sparc64, but that programs built with it might segfault, etc. If you are up for debugging those issues then that is one approach. I do think that clang works on Linux/sparc64, so that these should be FreeBSD bugs moreso than clang/llvm bugs (but I can't promise that). In theory we have bits in our build system to use an external toolchain for building a system. I haven't worked with them but I have seen others talk about them (e.g. imp@ and bapt@). Getting the recipe down for how to do it and testing that the system works with recent versions of GCC is what is missing there I think (so that there are instructions of 'install port foo', 'stick this in /etc/make.conf', or 'put this on the command line to buildworld', etc.). Of course, testing that the resulting binaries also work correctly would also be good. :) -- John Baldwin From owner-freebsd-hackers@freebsd.org Fri Aug 7 20:32:38 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31B5F9B67BD for ; Fri, 7 Aug 2015 20:32:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FCB4CDA for ; Fri, 7 Aug 2015 20:32:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (75-48-78-19.lightspeed.cncrca.sbcglobal.net [75.48.78.19]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0A81EB98E; Fri, 7 Aug 2015 16:32:37 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Cc: Hans Petter Selasky , Garrett Cooper Subject: Re: When and when not to use CTLFLAG_MPSAFE with the SYSCTL macros..? Date: Fri, 07 Aug 2015 12:41:55 -0700 Message-ID: <2324251.0KSjbGaFFg@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <55C1AF5A.1080601@selasky.org> References: <55C1AF5A.1080601@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 07 Aug 2015 16:32:37 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:32:38 -0000 On Wednesday, August 05, 2015 08:38:18 AM Hans Petter Selasky wrote: > On 08/05/15 00:47, Garrett Cooper wrote: > > Hi, > > =09I=E2=80=99ve been trying to figure out (because sysctl(9) is lac= king) when to use CTLFLAG_MPSAFE. Is it strictly when dealing with SYSC= TL_PROC handlers that do proper locking of shared resources, or are the= re other nuances that need to be handled? > > =09I=E2=80=99m also asking because SYSCTL_UQUAD, for instance, expl= icitly uses CTLFLAG_MPSAFE in the handler, which is a bit confusing. > > Thanks! > > -NGie >=20 > Hi, >=20 > This flag decides if you have Giant automatically locked or not aroun= d=20 > the sysctl proc. Your functions should have their own locks basically= . I=20 > believe it is a leftover from many years ago, when the FreeBSD kernel= =20 > was going multi threaded. It's only about 2-3 years old actually. To answer your question Garrett: yes it is really only for SYSCTL_PROC handlers. The existing "simple" handlers like sysctl_handle_int are as atomic as they can be regardless of Giant, so they don't need Giant.= If you have a variable that you want to control access to via locking y= ou need to use a custom handler, even if it is a simple int. --=20 John Baldwin From owner-freebsd-hackers@freebsd.org Fri Aug 7 20:53:52 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA0A69B6B9E for ; Fri, 7 Aug 2015 20:53:52 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70B5A1915 for ; Fri, 7 Aug 2015 20:53:52 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by wibxm9 with SMTP id xm9so75111684wib.0 for ; Fri, 07 Aug 2015 13:53:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bh1wPDUftZiAkoZyqDVQwKTuwWGn9S5P7+jUQJRFW0o=; b=acMkP/pYsaNZbhuKil/zoCZWZpjht//SjJHZQXinhbvu4R7ZWXd184t4f5w/IXA6Bw wl+V00arZK4ahiomq2mA930Xfs7J6HT15ASeozHVQjAP4kTK1DdjpE8smOjL1BNkCgR4 WJGCZUoXJ9U7/CZ/M5Xkllz5l5iuhVKC138t/Y9QyjnQSu/kE4Cs1h7rjjOQMu5uiGwb +Tnlf1gYyhWpz6sQFAvbk6VaHAWMy6Ta4zEO1aoTy/B48oLeWOU1QZdtnu/uNJL19cFS uIA5JTuYWkF/KLyyGavST30+BJRuqSSQZ2genB/jMUzv5oujOntnuMJIFfAWYpBpPtY5 t8ZQ== X-Gm-Message-State: ALoCoQlg/wt62cx1d4aUrDxyoh0Oe1PGx8OxXOWm5Bp/JSgKtWzMpFRpQjBp5mx6Tu3gXYs+j7IP MIME-Version: 1.0 X-Received: by 10.180.39.65 with SMTP id n1mr165332wik.59.1438980825102; Fri, 07 Aug 2015 13:53:45 -0700 (PDT) Received: by 10.194.73.6 with HTTP; Fri, 7 Aug 2015 13:53:45 -0700 (PDT) In-Reply-To: <2324251.0KSjbGaFFg@ralph.baldwin.cx> References: <55C1AF5A.1080601@selasky.org> <2324251.0KSjbGaFFg@ralph.baldwin.cx> Date: Fri, 7 Aug 2015 22:53:45 +0200 Message-ID: Subject: Re: When and when not to use CTLFLAG_MPSAFE with the SYSCTL macros..? From: Oliver Pinter To: John Baldwin Cc: freebsd-hackers@freebsd.org, Hans Petter Selasky , Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 20:53:52 -0000 On 8/7/15, John Baldwin wrote: > On Wednesday, August 05, 2015 08:38:18 AM Hans Petter Selasky wrote: >> On 08/05/15 00:47, Garrett Cooper wrote: >> > Hi, >> > I=E2=80=99ve been trying to figure out (because sysctl(9) is lacking)= when to >> > use CTLFLAG_MPSAFE. Is it strictly when dealing with SYSCTL_PROC >> > handlers that do proper locking of shared resources, or are there othe= r >> > nuances that need to be handled? >> > I=E2=80=99m also asking because SYSCTL_UQUAD, for instance, explicitl= y uses >> > CTLFLAG_MPSAFE in the handler, which is a bit confusing. >> > Thanks! >> > -NGie >> >> Hi, >> >> This flag decides if you have Giant automatically locked or not around >> the sysctl proc. Your functions should have their own locks basically. I >> believe it is a leftover from many years ago, when the FreeBSD kernel >> was going multi threaded. > > It's only about 2-3 years old actually. > > To answer your question Garrett: yes it is really only for SYSCTL_PROC > handlers. The existing "simple" handlers like sysctl_handle_int are > as atomic as they can be regardless of Giant, so they don't need Giant. For the basic types the CTLFLAG_MPSAFE flag are always added: https://github.com/freebsd/freebsd/blob/master/sys/sys/sysctl.h#L322 . > > If you have a variable that you want to control access to via locking you > need to use a custom handler, even if it is a simple int. > > -- > John Baldwin > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@freebsd.org Fri Aug 7 23:54:48 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C84779B68A9 for ; Fri, 7 Aug 2015 23:54:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96F402D8; Fri, 7 Aug 2015 23:54:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by ioeg141 with SMTP id g141so125877674ioe.3; Fri, 07 Aug 2015 16:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KAH91azMyi/GgQIrmk93njp7YSpfFah9BUR/G9q/cOw=; b=gs/0hbTamhg4S7agGG9UvQKZPP5oZi/L0XKkCqIrb3XwhuxErtm4rV7y4UH0y0LIJY fZFBEP2QgCpTqHqseqZ5v+X4TFDJZTHF9QKAsrhj8mLtBkRtUkZxXeOQnGk6ixtXYhZV YfmOmlmf7WPZ6rTq3r01kkKG+G/ncKIr6EkJnKn8NfaKX9x0vIIs9m8Ic2+6nIWt+JWk Z4b/TXjma/7d2Cp4oaJEldiFL1ZZzlkLjRJR1+tAYkUARRFYE2fgt/ysYc9zktcvu16c 0Z3YQnCkepUUOXB2O0CZI2PCZo2QM6Q8P5zgBZplT7aCESKz6AmJEddbUOpol4kp2ip5 59zQ== MIME-Version: 1.0 X-Received: by 10.107.164.103 with SMTP id n100mr3457067ioe.123.1438991686603; Fri, 07 Aug 2015 16:54:46 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Fri, 7 Aug 2015 16:54:46 -0700 (PDT) In-Reply-To: <7311511.ISQt3RZVgq@ralph.baldwin.cx> References: <7311511.ISQt3RZVgq@ralph.baldwin.cx> Date: Fri, 7 Aug 2015 16:54:46 -0700 Message-ID: Subject: Re: Sparc64 support From: Adrian Chadd To: John Baldwin Cc: "freebsd-hackers@freebsd.org" , Bill Sorenson Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sat, 08 Aug 2015 00:39:01 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 23:54:48 -0000 Hi, I've tested it with mips/mips64. It works out mostly okay. There are still rough edges, because in the mips world we have different defaults in our base system gcc to what the current toolchain expects. But at least for mips/mips64 it spits out a kernel and binaries that work. What I did to make the MIPS bits call the external toolchain: make NO_WERROR=1 CROSS_TOOLCHAIN=mips-gcc buildworld .. so in theory the sparc64 stuff may just be: pkg install sparc64-gcc sparc64-xtoolchain-gcc make NO_WERROR=1 CROSS_TOOLCHAIN=sparc64-gcc buildworld -adrian From owner-freebsd-hackers@freebsd.org Sat Aug 8 01:56:15 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8303A9B6243 for ; Sat, 8 Aug 2015 01:56:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2970889A; Sat, 8 Aug 2015 01:56:15 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: by wibxm9 with SMTP id xm9so85653804wib.1; Fri, 07 Aug 2015 18:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IlDpThwHfD+69v+gCm5nP3BLWl1IaMIIbbv+t+11NIo=; b=tBWp9IAT7xLx/Sth8AT+NGicFQtUa8JyAAwYVx+gOz5aEg4Bvek2YNiC+OCl4CzwpF 5izcyDSy20DVYJux1bO0O9ms/Fw1ydhPSoj0NgxULX7VUOyiC+TuOcyB8q+F1WzFli06 B2AaTch1jJgLjhUxF3EApnm4LpEUBThyR67shkitzWQb9Hjib2J62vn8R0bxpzpbWa/U dxdgcpFtr6pFarDsS7aKMzA1WYuodegFfO40yMjfdVu/N/1GJ9xO0v6dKcP7/Sxh/xUb CcWaBo3H57pzUWrPckGLbFSefJ2vRc5AKHId3opp34ol5zsq6ilM7Tq6s5mJ6LX5HCph m5TQ== X-Received: by 10.194.58.199 with SMTP id t7mr21596234wjq.45.1438998973616; Fri, 07 Aug 2015 18:56:13 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by smtp.gmail.com with ESMTPSA id gt10sm1545166wib.20.2015.08.07.18.56.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2015 18:56:12 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 8 Aug 2015 03:56:10 +0200 From: Baptiste Daroussin To: Adrian Chadd Cc: John Baldwin , "freebsd-hackers@freebsd.org" , Bill Sorenson Subject: Re: Sparc64 support Message-ID: <20150808015610.GL43782@ivaldir.etoilebsd.net> References: <7311511.ISQt3RZVgq@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xb8pJpF45Qg/t7GZ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 01:56:15 -0000 --Xb8pJpF45Qg/t7GZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 07, 2015 at 04:54:46PM -0700, Adrian Chadd wrote: > Hi, >=20 > I've tested it with mips/mips64. It works out mostly okay. There are > still rough edges, because in the mips world we have different > defaults in our base system gcc to what the current toolchain expects. > But at least for mips/mips64 it spits out a kernel and binaries that > work. >=20 > What I did to make the MIPS bits call the external toolchain: >=20 > make NO_WERROR=3D1 CROSS_TOOLCHAIN=3Dmips-gcc buildwor= ld >=20 > .. so in theory the sparc64 stuff may just be: >=20 > pkg install sparc64-gcc sparc64-xtoolchain-gcc > make NO_WERROR=3D1 CROSS_TOOLCHAIN=3Dsparc64-gcc buildwo= rld >=20 When I added the cross toolchain it was first tested on sparc64 and people reported that it built and run fine with it. This was with gcc 4.9, I haven't tested with 5.2 Bapt --Xb8pJpF45Qg/t7GZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlXFYboACgkQ8kTtMUmk6Ez1fACgmrXzjSFbotisEnvuonWBR7xj k90AoKzSvD6Ow8/q14NrceYZPdYRBXz2 =Llx7 -----END PGP SIGNATURE----- --Xb8pJpF45Qg/t7GZ-- From owner-freebsd-hackers@freebsd.org Sat Aug 8 05:44:22 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F2EC9B6DEE for ; Sat, 8 Aug 2015 05:44:22 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE0A5D73; Sat, 8 Aug 2015 05:44:21 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qkdg63 with SMTP id g63so43836066qkd.0; Fri, 07 Aug 2015 22:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DMJ3JwEvJckp1YCW3GxRK0SYITgiz2suhNprDBr2jqU=; b=btzSSRzSxzq/vJ+Fm6493IklIQz5/3+kKJC0JZ6LzEtIrdmDu8Kc2mqDYJa15uq/Hz JTyaDICEHIh2RJovktNQJ16nY/+Nz4UHGFOhY2qAFeEoONSs9dGImYCLTqayIE0xN15N eTxNrgq+U30cyM9P/Le2WYIHM01WEzaMz5mTYuzB6Y6JvhPjJQW7FFI2tCurcUv8YeuM VfIiXIMwDTnrEs0OYfWsaTNeyReHQyYA9ldw9uj/5S65alUvZk8894g7VXe3KyHYzNvE upV4fjOKGlIiiTFeX4odYZY6uGYxVzlI8p2kc18qi62LjNC1Xs5M6FYmvSw33Ba4W99o eGEQ== MIME-Version: 1.0 X-Received: by 10.55.53.193 with SMTP id c184mr19589041qka.62.1439012660826; Fri, 07 Aug 2015 22:44:20 -0700 (PDT) Received: by 10.140.98.73 with HTTP; Fri, 7 Aug 2015 22:44:20 -0700 (PDT) In-Reply-To: References: <55C1AF5A.1080601@selasky.org> <2324251.0KSjbGaFFg@ralph.baldwin.cx> Date: Fri, 7 Aug 2015 22:44:20 -0700 Message-ID: Subject: Re: When and when not to use CTLFLAG_MPSAFE with the SYSCTL macros..? From: NGie Cooper To: Oliver Pinter Cc: John Baldwin , "freebsd-hackers@freebsd.org" , Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 05:44:22 -0000 On Fri, Aug 7, 2015 at 1:53 PM, Oliver Pinter wrote: > On 8/7/15, John Baldwin wrote: >> On Wednesday, August 05, 2015 08:38:18 AM Hans Petter Selasky wrote: >>> On 08/05/15 00:47, Garrett Cooper wrote: >>> > Hi, >>> > I=E2=80=99ve been trying to figure out (because sysctl(9) is lacki= ng) when to >>> > use CTLFLAG_MPSAFE. Is it strictly when dealing with SYSCTL_PROC >>> > handlers that do proper locking of shared resources, or are there oth= er >>> > nuances that need to be handled? >>> > I=E2=80=99m also asking because SYSCTL_UQUAD, for instance, explic= itly uses >>> > CTLFLAG_MPSAFE in the handler, which is a bit confusing. >>> > Thanks! >>> > -NGie >>> >>> Hi, >>> >>> This flag decides if you have Giant automatically locked or not around >>> the sysctl proc. Your functions should have their own locks basically. = I >>> believe it is a leftover from many years ago, when the FreeBSD kernel >>> was going multi threaded. >> >> It's only about 2-3 years old actually. >> >> To answer your question Garrett: yes it is really only for SYSCTL_PROC >> handlers. The existing "simple" handlers like sysctl_handle_int are >> as atomic as they can be regardless of Giant, so they don't need Giant. > > For the basic types the CTLFLAG_MPSAFE flag are always added: > https://github.com/freebsd/freebsd/blob/master/sys/sys/sysctl.h#L322 . > >> >> If you have a variable that you want to control access to via locking yo= u >> need to use a custom handler, even if it is a simple int. Thank you, all -- I see it now. -NGie From owner-freebsd-hackers@freebsd.org Sat Aug 8 03:19:40 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E8699B525C for ; Sat, 8 Aug 2015 03:19:40 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 506E5ED2 for ; Sat, 8 Aug 2015 03:19:39 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZNufY-0003H5-63 for freebsd-hackers@freebsd.org; Sat, 08 Aug 2015 05:19:36 +0200 Received: from ip24-251-153-29.ph.ph.cox.net ([24.251.153.29]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Aug 2015 05:19:36 +0200 Received: from kevin.bowling by ip24-251-153-29.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 08 Aug 2015 05:19:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Kevin Bowling Subject: Re: Sparc64 support Date: Fri, 7 Aug 2015 20:19:28 -0700 Lines: 67 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip24-251-153-29.ph.ph.cox.net User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: X-Mailman-Approved-At: Sat, 08 Aug 2015 11:14:54 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 03:19:40 -0000 On 8/5/2015 12:10 PM, Bill Sorenson wrote: > I have been advised to post this in this list. I was going to rewrite this > a bit but I'm not sure what parts people will be interested. Anyway: > > > I'm one of probably a few users of FreeBSD and OpenBSD on multiple > platforms left and I thought I'd share some of my experience with BSD on > some of the lesser used platforms. > > I manage a fair number of systems, most of them running FreeBSD on 64-bit > Intel, but I probably have more sparc64 and powerpc systems running now > than on i386. I have made it a bit of a specialty of mine to make use of > BSD on existing equipment owned by a customer in a Solaris or OS X (or some > other, older Unix...) environment and migrating their special sauce to run > on it (or it could be as simple as setting up a FreeBSD Samba server on an > existing G5 Mac they own). > > There are a lot of old SunFire servers running Solaris out there that will > take years to die, and a lot of companies aren't excited about buying a lot > of new hardware and porting their code over to Linux (thank goodness). When > they start to run into software support and management issues, I've found > FreeBSD to be a relatively easy sell. They get an up to date modern OS with > modern ports available and usually migrating their C code or perl isn't > much of an issue. They get to hold off on buying hardware until there is a > direct need (accounting really loves this). > > The advantage for me is that when these companies start looking at new > hardware with the latest Xeon, they're already running FreeBSD 9.3 or 10.1. > Their code is already ported, the software they're now using is already > available and works. When they move, its basically a recompile and its good > to go. These customers stick to BSD and forget about Linux or paying Oracle > more money. Everything just works and they couldn't be happier. > > I've always been interested in the older and more unusual hardware, its a > big part of how I found a niche in supporting it on a professional level. > Personally I run a sparc64 server, a powerpc G5 Xserve, a Alpha based DS20L > running OpenBSD and an old 68k Mac running NetBSD, partly for fun and > partly to make sure I can support my clients (ok, the 68k Mac is purely for > fun). > > I've found a lot of value in FreeBSD's support for older platforms for > getting my foot in the door with a lot of customers. Yes sparc64 isn't the > future for FreeBSD but I still think it is very much the present. Its not > dead yet, there are a lot of users of this old gear out there if you know > where to look. For a company that has never heard of FreeBSD to adopt it > because it will extend the life of their hardware I think that is a very > powerful thing. > > -Bill Sorenson > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > If you look around, you'll find many core committers are quite active on the ARM and MIPS ports. SPARC became solidly niche when Oracle bought Sun. Your business model is commendable, and getting people onto FreeBSD makes me happy. But these businesses are being penny wise, pound foolish. A $1200 Xeon-D server could consolidate (jails) a handful of sun4u systems and pay for itself in electric savings within the year. I would love to see SPARC support continue simply because it's a gauntlet that can eek out bugs. jhb@ gave a good overview of what is needed for the toolchain. sun4v support would be another nice thing.