From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 25 08:54:06 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A71AB16A400 for ; Sun, 25 Mar 2007 08:54:06 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 5695A13C448 for ; Sun, 25 Mar 2007 08:54:06 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 6D1941CC58; Sun, 25 Mar 2007 20:38:05 +1200 (NZST) Date: Sun, 25 Mar 2007 20:38:05 +1200 From: Andrew Thompson To: hackers@freebsd.org Message-ID: <20070325083805.GA68655@heff.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: hash.h warnings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 08:54:06 -0000 Hi, There was a discussion late last year about how to fix the warnings in sys/sys/hash.h. http://lists.freebsd.org/pipermail/freebsd-net/2006-October/012098.html There were a few suggestions put forward but nothing was ever committed. I need to include this file in the kernel for a new driver but do not know enough about this type of warning to fix it. Can anyone recommend the correct fix? @/sys/hash.h: In function `hash32_stre': @/sys/hash.h:97: warning: cast discards qualifiers from pointer target type @/sys/hash.h: In function `hash32_strne': @/sys/hash.h:116: warning: cast discards qualifiers from pointer target type cheers, Andrew From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 25 10:18:45 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45AEF16A400 for ; Sun, 25 Mar 2007 10:18:45 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout4.cac.washington.edu (mxout4.cac.washington.edu [140.142.33.19]) by mx1.freebsd.org (Postfix) with ESMTP id 229D513C455 for ; Sun, 25 Mar 2007 10:18:45 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout4.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2PAIi2M015462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 25 Mar 2007 03:18:44 -0700 X-Auth-Received: from [192.168.10.42] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2PAIh42012613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 25 Mar 2007 03:18:44 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20070325083805.GA68655@heff.fud.org.nz> References: <20070325083805.GA68655@heff.fud.org.nz> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AD42FD0-08D2-4417-B8B4-EEC810B4F3F2@u.washington.edu> Content-Transfer-Encoding: 7bit From: Garrett Cooper Date: Sun, 25 Mar 2007 03:18:42 -0700 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.25.30933 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Subject: Re: hash.h warnings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 10:18:45 -0000 On Mar 25, 2007, at 1:38 AM, Andrew Thompson wrote: > Hi, > > > There was a discussion late last year about how to fix the warnings in > sys/sys/hash.h. > > http://lists.freebsd.org/pipermail/freebsd-net/2006-October/ > 012098.html > > There were a few suggestions put forward but nothing was ever > committed. I > need to include this file in the kernel for a new driver but do not > know > enough about this type of warning to fix it. Can anyone recommend > the correct > fix? > > @/sys/hash.h: In function `hash32_stre': > @/sys/hash.h:97: warning: cast discards qualifiers from pointer > target type > @/sys/hash.h: In function `hash32_strne': > @/sys/hash.h:116: warning: cast discards qualifiers from pointer > target type > > > > cheers, > Andrew After looking at the source it appears that part of the problem stems from the fact that p is an unsigned char pointer, where ep is a signed char double pointer. So you're losing some precision in the process (hence where the error's coming from I believe). So, if you modified buf (the pointer that p is pointing to) or ep to be compatible with one another, you probably wouldn't get this warning.. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 25 13:33:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBEC916A402 for ; Sun, 25 Mar 2007 13:33:49 +0000 (UTC) (envelope-from freeman@vault13.org) Received: from vault13.org (ip246-74.baltnet.ru [217.168.74.246]) by mx1.freebsd.org (Postfix) with ESMTP id C05EB13C4BE for ; Sun, 25 Mar 2007 13:33:46 +0000 (UTC) (envelope-from freeman@vault13.org) Received: from vault.net.vault13.org (ip2-13.net.vault13.org [192.168.2.13]) by vault13.org (8.13.6/8.13.6) with ESMTP id l2PDd98g026028 for ; Sun, 25 Mar 2007 17:39:09 +0400 (MSD) (envelope-from freeman@vault13.org) Received: from ip2-13.net.vault13.org (localhost [127.0.0.1]) by vault.net.vault13.org (8.13.6/8.13.6) with ESMTP id l2PDXHnF014486 for ; Sun, 25 Mar 2007 17:33:17 +0400 (MSD) (envelope-from freeman@ip2-13.net.vault13.org) Received: (from freeman@localhost) by ip2-13.net.vault13.org (8.13.6/8.13.6/Submit) id l2PDXC4Y014485 for freebsd-hackers@freebsd.org; Sun, 25 Mar 2007 17:33:12 +0400 (MSD) (envelope-from freeman) Date: Sun, 25 Mar 2007 17:33:12 +0400 From: banshee To: freebsd-hackers@freebsd.org Message-ID: <20070325133312.GB13279@vault.net.vault13.org> Mail-Followup-To: banshee , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline X-PGP-Key-URL: http://vault13.org/home/gpg-pub-key.asc X-Spam-Status: No, score=-1.4 required=2.0 tests=ALL_TRUSTED autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on vault13.org X-Mailman-Approved-At: Sun, 25 Mar 2007 13:58:42 +0000 Subject: syslog-secure (RFC3164) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 13:33:49 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. That's what i found on freebsd.org/projects/: SYSLOG-SECURE: In August 2001 a standard of syslog was made: RFC3164. This= RFC describes some extensions to add security to syslog. The project start= ed in 2002 is to adapt RFC3164 to FreeBSD version of syslog, and to add som= e security extensions. At least syslog-sign. Both libc and syslogd will be = modified. And optional some tools to verify/manage the security will made. = All help is welcome. Send an email to albert@ons-huis.net for info. I've sent an e-mail to Albert, but didn't get any reply. Is this project s= till alive? I'm thinking to work on this on next week, but actually i don't= know where to start. --=20 Contra vim mortis, non est medicaments... --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iQIVAwUBRgZ6F4klF6acR4MmAQIXvhAAnmE0cGG9Psd5bb2s6CuKx3Y8oSWAXf02 eyzsv1FOpX7x4qrcH4b0BWfwAzWWCZkl+zxzSd1TFqd8dsLJOSQtLhtmM3XLKiSn 8cbhE3msJtnN6QMvlmnbSUjneg7CgRbIn30FetpZKDtcJFjjFpoVrBbZvsxQyh39 iqNAXSTUxIFgz++GzIPEt5dDRwKqDGm/N5F1owk/RD7IA+UcSV5KYrSHb/jEes8r ZwJks6aT9BoUOpce5AOg9L+vRTtNvmsdeyNkp3tlQFpVKi0zI/hMA8aSNjpJ2U31 RPZJmc7gMoVtnZjr2Ek/vMQzoRj7vQxT0W6o9El2x8JXsi96DHN/Q5qalor/4M3b K2tha9FQlu8NXgT8yCbUsG1PXIXUglLMQITR8cQ25dNU9e6XmZhBkVJ+BgN9/Ovx lQvDZju5i+cHTOvXoCzHJmA3K/e9H3gm6GQGYvYx4a2vNC5E2DZlDsSFXJOwU04Z 10B0xgZVSktT8kE/P9WCOrqXcWjAm7uz2Y/EqttL6pk53xaefxaBGnknHMcEpBvb tEg9x3X7N4JkuRyvic+fCTXuVg3PEqV1CFP7ToeJb3hwIP9bhlaRxJ7mdeGgKSd2 i0cGwZJ6cxa5hsw00/GHPRi590IaPuU/mk3g64We+4STfUoq8/wJD8o4OOpUfT5+ QA9/uX4XiNE= =DMln -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 25 20:01:23 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4963616A408 for ; Sun, 25 Mar 2007 20:01:23 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id BF1D513C4AD for ; Sun, 25 Mar 2007 20:01:22 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549a67c8.dip.t-dialin.net [84.154.103.200]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l2PJmSRq061168; Sun, 25 Mar 2007 21:48:34 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l2PJmRZH027634; Sun, 25 Mar 2007 21:48:27 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id l2PJmRrP084218; Sun, 25 Mar 2007 21:48:27 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200703251948.l2PJmRrP084218@fire.jhs.private> To: Alexander Leidinger In-reply-to: <20070324145233.21891248@Magellan.Leidinger.net> References: <20070324145233.21891248@Magellan.Leidinger.net> Comments: In-reply-to Alexander Leidinger message dated "Sat, 24 Mar 2007 14:52:33 +0100." Date: Sun, 25 Mar 2007 21:48:27 +0200 From: "Julian H. Stacey" Cc: freebsd-hackers@freebsd.org, ajay gopalakrishnan Subject: Re: Have people started working on any Google Summer of code 2007 project? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2007 20:01:23 -0000 Alexander Leidinger wrote: > Quoting "ajay gopalakrishnan" (Sat, 24 Mar 2007 15:53:11 +0530): > > > Have people started working on any Google Summer of code 2007 project? I saw > > some project ideas marked as "Suitable for Summer of code" on the project > > ideas web page. But have any of those projects been taken up? > > Proposals are submitted by students to Google and available for rating > in the mentor-interface. No proposal is selected yet and we don't know > yet how many seats for students we have in this SoC. > > I suggest to have a look at the Google SoC pages, they provide a > timeline there. Quoting http://code.google.com/soc/ We've extended the deadline for student applications to Monday, March 26, 2007. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Escape Microsoft 20th April 2007: http://berklix.com/free/talk/ Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 04:19:16 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5CB216A400 for ; Mon, 26 Mar 2007 04:19:16 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: from fallbackmx03.syd.optusnet.com.au (fallbackmx03.syd.optusnet.com.au [211.29.133.136]) by mx1.freebsd.org (Postfix) with ESMTP id 32F2E13C46E for ; Mon, 26 Mar 2007 04:19:15 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by fallbackmx03.syd.optusnet.com.au (8.12.11.20060308/8.12.11) with ESMTP id l2P1wxBW023977 for ; Sun, 25 Mar 2007 11:58:59 +1000 Received: from triptrop.cse.unsw.edu.au (blaax9-a118.dialup.optusnet.com.au [203.164.126.118]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l2P1wqMK020256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Mar 2007 11:58:54 +1000 Received: from triptrop.cse.unsw.edu.au (localhost [127.0.0.1]) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6) with ESMTP id l2P1vIFx000902 for ; Sun, 25 Mar 2007 11:57:19 +1000 (EST) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: (from tbourke@localhost) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6/Submit) id l2P1vHlA000901 for hackers@freebsd.org; Sun, 25 Mar 2007 11:57:17 +1000 (EST) (envelope-from tbourke) Date: Sun, 25 Mar 2007 11:57:17 +1000 From: Timothy Bourke To: hackers@freebsd.org Message-ID: <20070325015717.GA797@triptrop> Mail-Followup-To: hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5I6of5zJg18YgZEa" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.cse.unsw.edu.au/~tbourke/pubkey.txt Cc: Subject: enable/disable in kbd drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 04:19:16 -0000 --5I6of5zJg18YgZEa Content-Type: multipart/mixed; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have almost finished a ppbus-based driver for Super Nintendo controllers. It presents itself as a keyboard to the operating system. I wanted to start and stop the polling thread via, respectively, the kbd_enable_t and kbd_disable_t hooks, but these do not seem to be called properly. Hence this post. The enable and disable functions are identical across the keyboard drivers (atkbd, ukbd, vkbd, kbdmux). Enable calls the KBD_ACTIVATE macro which increments the kb_active count. Disable calls the KBD_DEACTIVATE macro which decrements the kb_active count. It seems reasonable to assume that the two functions should be called in pairs. However, enable is called too many times and disable is never called. In the kbdmux_ioctl routine: KBADDKBD: enable is called via the KBDMUX_ENABLE macro. KBRELKBD: does NOT call disable Taking dev/usb/ukbd.c as an example, the effect can be seen by adding this line to the ukbd_enable function (after the call to KBD_ACTIVATE): printf("ukbd_enable: %d\n", KBD_IS_ACTIVE(kbd)); And similarly for ukbd_disable and then running dmesg or kbdcontrol. Additionally, each kbd driver calls its own enable function when attached. For example, in USB_ATTACH(ukbd): (*sw->enable)(kbd); This would appear to be unnecessary for keyboards connected via kbdmux. I am less certain about those connected directly, but the syscons sccngetch routine does seems to call enable and disable. Perhaps it should also call enable when it first starts? Does the attached patch seem reasonable? It would fix my immediate problem. I could write a patch to remove the calls to enable in the driver init routines but tI don't really understand how syscons works. Tim. --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kbdmux.patch" Content-Transfer-Encoding: quoted-printable --- sys/dev/kbdmux/kbdmux.c.orig Sun Mar 25 11:33:57 2007 +++ sys/dev/kbdmux/kbdmux.c Sun Mar 25 11:36:46 2007 @@ -132,6 +132,9 @@ #define KBDMUX_ENABLE(kbd) \ (*kbdsw[(kbd)->kb_index]->enable)((kbd)) =20 +#define KBDMUX_DISABLE(kbd) \ + (*kbdsw[(kbd)->kb_index]->disable)((kbd)) + #define KBDMUX_POLL(kbd, on) \ (*kbdsw[(kbd)->kb_index]->poll)((kbd), (on)) =20 @@ -1029,6 +1032,7 @@ break; =20 if (k !=3D NULL) { + KBDMUX_DISABLE(k->kbd); error =3D kbd_release(k->kbd, &k->kbd); if (error =3D=3D 0) { SLIST_REMOVE(&state->ks_kbds, k, kbdmux_kbd, next); --DocE+STaALJfprDB-- --5I6of5zJg18YgZEa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFGBdb9tKVK1sFb0ecRAoAfAJ4jPcRes/YX2/vRszKrTrcF0qCgPwCfaCUr VL6Gbe+4v06Rhjr+LRFZLtQ= =MJce -----END PGP SIGNATURE----- --5I6of5zJg18YgZEa-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 13:18:03 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2CDD16A402 for ; Mon, 26 Mar 2007 13:18:03 +0000 (UTC) (envelope-from robe@prodal.telemar.cu) Received: from mail1.fishnavy.inf.cu (mail1.fishnavy.inf.cu [200.55.129.131]) by mx1.freebsd.org (Postfix) with ESMTP id A2C2513C45B for ; Mon, 26 Mar 2007 13:18:00 +0000 (UTC) (envelope-from robe@prodal.telemar.cu) Received: (from uucp@localhost) by mail1.fishnavy.inf.cu (8.11.7/8.11.7) id l2QDjhJ46632 for ; Mon, 26 Mar 2007 08:45:43 -0500 (EST) Received: from UNKNOWN(192.168.38.2), claiming to be "prodal.telemar.cu" via SMTP by mail1.fishnavy.inf.cu, id smtpdolsEW3; Mon Mar 26 13:45:33 2007 Received: from [192.168.200.31] by prodal.telemar.cu (MDaemon.PRO.v8.1.3.R) with ESMTP id md50000065673.msg for ; Mon, 26 Mar 2007 08:45:18 -0500 From: Robe To: freebsd-hackers Content-Type: text/plain Date: Sat, 24 Mar 2007 11:58:33 -0500 Message-Id: <1174755513.5742.10.camel@robe-ubuntu> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Authenticated-Sender: robe@prodal.telemar.cu X-Spam-Processed: prodal.telemar.cu, Mon, 26 Mar 2007 08:45:18 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.200.31 X-Return-Path: robe@prodal.telemar.cu X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org X-MDAV-Processed: prodal.telemar.cu, Mon, 26 Mar 2007 08:45:19 -0500 Subject: Missing library X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 13:18:03 -0000 Hi, I've read the article "libelf by Example" written by " Joseph Koshy". When I try to compile the example with the command he suggest: g++ CodeGenerator.i386.cpp -lelf I get the following error: /tmp/ccpfmJ4D.o: In function `elf_setshstrndx(Elf*, unsigned int)': CodeGenerator.i386.cpp:(.text+0x31): undefined reference to `_libelf_setshstrndx(Elf*, void*, int, unsigned int)' Does anybody know in which library reside that function? Thanx, Robe. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 14:24:18 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8149816A407 for ; Mon, 26 Mar 2007 14:24:18 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id DBE6F13C45D for ; Mon, 26 Mar 2007 14:24:17 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2QDp8Fo086305 for ; Mon, 26 Mar 2007 17:51:08 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2QDp7MG086304 for hackers@freebsd.org; Mon, 26 Mar 2007 17:51:07 +0400 (MSD) (envelope-from yar) Date: Mon, 26 Mar 2007 17:51:07 +0400 From: Yar Tikhiy To: hackers@freebsd.org Message-ID: <20070326135106.GG60831@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 14:24:18 -0000 Hi, Recently noticed that our sed(1) differs from its GNU analog in that in -i mode it considers all files as a single sequence of lines while the latter treats each file independently. The in-line mode isn't in POSIX, so it isn't really clear which way is correct. Here is a couple of practical consequences: - our sed won't act on a numeric range of lines in each file, as in: sed -i '' 2,5d *, which may be counter-intuitive. - our sed's line ranges can span file boundaries in -i mode. If the second feature isn't important, I think we should use a separate line space for each file edited in-line, which is usually desired. Comments? P.S. Attached are a test script and outputs from it for our sed and GNU sed as found in a Linux I have access to. -- Yar %%%%% sed.t %%%%% #!/bin/sh files="1 2 3" lines="1 2 3 4 5" makefiles() { for f in $files; do for n in $lines; do echo $n done > $f done } echo "### Test 1 ###" makefiles sed -i.bak 1,3d $files tail $files echo "### Test 2 ###" makefiles sed -i.bak /5/,/2/d $files tail $files %%%%% output using our sed %%%%% ### Test 1 ### ==> 1 <== 4 5 ==> 2 <== 1 2 3 4 5 ==> 3 <== 1 2 3 4 5 ### Test 2 ### ==> 1 <== 1 2 3 4 ==> 2 <== 3 4 ==> 3 <== 3 4 %%%%% output using GNU sed %%%%% ### Test 1 ### ==> 1 <== 4 5 ==> 2 <== 4 5 ==> 3 <== 4 5 ### Test 2 ### ==> 1 <== 1 2 3 4 ==> 2 <== 1 2 3 4 ==> 3 <== 1 2 3 4 %%%%% END %%%%% From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 15:53:53 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA4CF16A405 for ; Mon, 26 Mar 2007 15:53:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6975D13C468 for ; Mon, 26 Mar 2007 15:53:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so820493wra for ; Mon, 26 Mar 2007 08:53:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VpPlUIz1kpCn5ielOMCCtMQGyVVZK8mKMXKNee2L510IohwOOH4fkrOZ/XdG3ReUsMUT34+S6LyevNCDarjwC+ua2IdwSq5p+XgiB0oh809TFHHMfiXEPXi5+HJJ5OGiTOMHxmIWMrE5R464e63DqKFBktDzVmPsLngloTsshCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=r/BAvZVEWSigQxGD3eU/ryLB2IPjTJ/CpF5jzM2POk9gONLcLnLy3diq2TUSnPCDllBdyPG9X4IWjrrcioGsYTEHYbSXVH7UBMMkVN0b0Nw8Knhzj3/S/MkMf5C1tiilDoR36XtnxrW1LSHyFalvERtLigkVDGqv38Rh6y9GUEw= Received: by 10.114.202.15 with SMTP id z15mr2676124waf.1174922834947; Mon, 26 Mar 2007 08:27:14 -0700 (PDT) Received: by 10.115.23.9 with HTTP; Mon, 26 Mar 2007 08:27:14 -0700 (PDT) Message-ID: <84dead720703260827q29ed7f26hd79dde461fe50d9b@mail.gmail.com> Date: Mon, 26 Mar 2007 20:57:14 +0530 From: "Joseph Koshy" To: "Yar Tikhiy" In-Reply-To: <20070326135106.GG60831@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070326135106.GG60831@comp.chem.msu.su> Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 15:53:53 -0000 > Recently noticed that our sed(1) differs from its GNU > analog in that in -i mode it considers all files as a > single sequence of lines while the latter treats each file > independently. The in-line mode isn't in POSIX, so it isn't > really clear which way is correct. Aren't sed's addresses required to be cumulative across its input files? http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 20:34:32 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59CF516A403; Mon, 26 Mar 2007 20:34:32 +0000 (UTC) (envelope-from jgrosch@juniper.net) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by mx1.freebsd.org (Postfix) with ESMTP id 3931613C458; Mon, 26 Mar 2007 20:34:32 +0000 (UTC) (envelope-from jgrosch@juniper.net) Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 26 Mar 2007 13:06:03 -0700 X-IronPort-AV: i="4.14,330,1170662400"; d="scan'208"; a="676600293:sNHT32287076" Received: from odin.juniper.net ([172.24.115.43]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 13:06:03 -0700 Received: by odin.juniper.net (Postfix, from userid 200) id 500B2A7020; Mon, 26 Mar 2007 13:06:03 -0700 (PDT) Date: Mon, 26 Mar 2007 13:06:03 -0700 From: Josef Grosch To: questions@freebsd.org Message-ID: <20070326200603.GA65215@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Organization: Juniper Networks X-OriginalArrivalTime: 26 Mar 2007 20:06:03.0526 (UTC) FILETIME=[2E68CA60:01C76FE2] Cc: hackers@freebsd.org Subject: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jgrosch@juniper.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:34:32 -0000 I have a Qlogic HBA card (QLA2342) in a machine running FreeBSD 6.2. FreeBSD sees the card and when the HBA is attached to a SAN we are able to see the disk space. The thing we can't seem to get working is a dual path to the same space. Can anyone point me in the correct direction to get this working? Josef -- FreeBSD 6.2 | I mean, if I went 'round saying I was an emperor Josef Grosch | just because some moistened bint had lobbed a jgrosch@juniper.net | scimitar at me, they'd put me away! From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 20:53:11 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BEBF16A403; Mon, 26 Mar 2007 20:53:11 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr14.xs4all.nl (smtp-vbr14.xs4all.nl [194.109.24.34]) by mx1.freebsd.org (Postfix) with ESMTP id 9E66C13C48C; Mon, 26 Mar 2007 20:53:10 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id l2QKdJjF066907; Mon, 26 Mar 2007 22:39:19 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l2QKcrr8056326; Mon, 26 Mar 2007 22:38:53 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l2QKcr8h056321; Mon, 26 Mar 2007 22:38:53 +0200 (CEST) (envelope-from wb) Date: Mon, 26 Mar 2007 22:38:52 +0200 From: Wilko Bulte To: Josef Grosch Message-ID: <20070326203852.GA56287@freebie.xs4all.nl> References: <20070326200603.GA65215@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070326200603.GA65215@juniper.net> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 20:53:11 -0000 On Mon, Mar 26, 2007 at 01:06:03PM -0700, Josef Grosch wrote.. > > I have a Qlogic HBA card (QLA2342) in a machine running FreeBSD > 6.2. FreeBSD sees the card and when the HBA is attached to a SAN we are > able to see the disk space. The thing we can't seem to get working is a > dual path to the same space. Can anyone point me in the correct direction > to get this working? You might want to check geom_fox(4). Note the disclaimer about "light testing" ;^) What FC array do you have btw? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 21:05:13 2007 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0476D16A407; Mon, 26 Mar 2007 21:05:13 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 8C93113C489; Mon, 26 Mar 2007 21:05:11 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (obsolete.xs4all.nl [82.95.250.254]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id l2QL5ASY015100; Mon, 26 Mar 2007 23:05:10 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.8/8.13.3) with ESMTP id l2QL4hDw056601; Mon, 26 Mar 2007 23:04:43 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.8/8.13.6/Submit) id l2QL4hB5056600; Mon, 26 Mar 2007 23:04:43 +0200 (CEST) (envelope-from wb) Date: Mon, 26 Mar 2007 23:04:43 +0200 From: Wilko Bulte To: Alex Dupre Message-ID: <20070326210443.GA56587@freebie.xs4all.nl> References: <20070326200603.GA65215@juniper.net> <20070326203852.GA56287@freebie.xs4all.nl> <460834C3.4090300@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460834C3.4090300@FreeBSD.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: hackers@FreeBSD.org, questions@FreeBSD.org, Josef Grosch Subject: Re: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 21:05:13 -0000 On Mon, Mar 26, 2007 at 11:01:55PM +0200, Alex Dupre wrote.. > Wilko Bulte wrote: > > You might want to check geom_fox(4). Note the disclaimer about "light > > testing" ;^) What FC array do you have btw? > > There is also geom_multipath in -current, in active development. What > are the differences between the twos? I was not aware about geom_multipath so I cannot really comment. Wilko Bulte wilko@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 21:19:18 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1F6B16A405; Mon, 26 Mar 2007 21:19:18 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 76E1913C44B; Mon, 26 Mar 2007 21:19:18 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l2QKeA7A039335; Mon, 26 Mar 2007 15:40:10 -0500 (CDT) (envelope-from anderson@freebsd.org) Message-ID: <46082FAA.8060002@freebsd.org> Date: Mon, 26 Mar 2007 15:40:10 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: jgrosch@juniper.net References: <20070326200603.GA65215@juniper.net> In-Reply-To: <20070326200603.GA65215@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2933/Mon Mar 26 11:26:11 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 21:19:18 -0000 On 03/26/07 15:06, Josef Grosch wrote: > I have a Qlogic HBA card (QLA2342) in a machine running FreeBSD > 6.2. FreeBSD sees the card and when the HBA is attached to a SAN we are > able to see the disk space. The thing we can't seem to get working is a > dual path to the same space. Can anyone point me in the correct direction > to get this working? See geom multipath (gmultipath) in -CURRENT. I think it's going to be MFC'ed at some point.. Eric From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 21:28:38 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2EF5A16A400 for ; Mon, 26 Mar 2007 21:28:38 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from lab.alexdupre.com (lab.alexdupre.com [81.174.31.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7245F13C457 for ; Mon, 26 Mar 2007 21:28:37 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: (qmail 9742 invoked from network); 26 Mar 2007 21:01:56 -0000 Received: from unknown (HELO ?192.168.178.2?) (192.168.178.2) by lab.alexdupre.com with SMTP; 26 Mar 2007 21:01:56 -0000 Message-ID: <460834C3.4090300@FreeBSD.org> Date: Mon, 26 Mar 2007 23:01:55 +0200 From: Alex Dupre User-Agent: Thunderbird 1.5.0.10 (X11/20070310) MIME-Version: 1.0 To: Wilko Bulte References: <20070326200603.GA65215@juniper.net> <20070326203852.GA56287@freebie.xs4all.nl> In-Reply-To: <20070326203852.GA56287@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org, questions@freebsd.org, Josef Grosch Subject: Re: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 21:28:38 -0000 Wilko Bulte wrote: > You might want to check geom_fox(4). Note the disclaimer about "light > testing" ;^) What FC array do you have btw? There is also geom_multipath in -current, in active development. What are the differences between the twos? -- Alex Dupre From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 26 21:33:13 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8789716A402; Mon, 26 Mar 2007 21:33:13 +0000 (UTC) (envelope-from jgrosch@juniper.net) Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE7413C46C; Mon, 26 Mar 2007 21:33:12 +0000 (UTC) (envelope-from jgrosch@juniper.net) Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 26 Mar 2007 14:33:12 -0700 X-IronPort-AV: i="4.14,331,1170662400"; d="scan'208"; a="697119231:sNHT34186672" Received: from odin.juniper.net ([172.24.115.43]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 14:33:11 -0700 Received: by odin.juniper.net (Postfix, from userid 200) id 9D693A7020; Mon, 26 Mar 2007 14:33:11 -0700 (PDT) Date: Mon, 26 Mar 2007 14:33:11 -0700 From: Josef Grosch To: Wilko Bulte Message-ID: <20070326213311.GA65344@juniper.net> References: <20070326200603.GA65215@juniper.net> <20070326203852.GA56287@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070326203852.GA56287@freebie.xs4all.nl> User-Agent: Mutt/1.4.2.2i Organization: Juniper Networks X-OriginalArrivalTime: 26 Mar 2007 21:33:11.0856 (UTC) FILETIME=[5ABCA300:01C76FEE] Cc: hackers@freebsd.org, questions@freebsd.org Subject: Re: Dual Logic with Qlogic card X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jgrosch@juniper.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 21:33:13 -0000 On Mon, Mar 26, 2007 at 10:38:52PM +0200, Wilko Bulte wrote: > On Mon, Mar 26, 2007 at 01:06:03PM -0700, Josef Grosch wrote.. > > > > I have a Qlogic HBA card (QLA2342) in a machine running FreeBSD > > 6.2. FreeBSD sees the card and when the HBA is attached to a SAN we are > > able to see the disk space. The thing we can't seem to get working is a > > dual path to the same space. Can anyone point me in the correct direction > > to get this working? > > You might want to check geom_fox(4). Note the disclaimer about "light > testing" ;^) What FC array do you have btw? We are going to be testing with a Netapp 3050 running Ontap 7.04. Our plan is to got to new Netapp 6030 / Ontap 7.2.1.1. This hooks up throught a Brocade switch. My first test were with a Hitachi something or another. I'll have a look at geom_fox. Josef -- FreeBSD 6.2 | Supreme executive power derives from a mandate Josef Grosch | from the masses, not from some farcical aquatic jgrosch@juniper.net | ceremony. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 03:50:23 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2FF616A408 for ; Tue, 27 Mar 2007 03:50:22 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5CD13C45E for ; Tue, 27 Mar 2007 03:50:22 +0000 (UTC) (envelope-from frank@exit.com) Received: from jill.exit.com (jill.exit.com [206.223.0.4]) by tinker.exit.com (8.13.8/8.13.8) with ESMTP id l2R3N70V027370 for ; Mon, 26 Mar 2007 19:23:07 -0800 (PST) (envelope-from frank@exit.com) Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.13.8/8.13.8) with ESMTP id l2R3N7KE042838 for ; Mon, 26 Mar 2007 19:23:07 -0800 (PST) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.13.8/8.13.8/Submit) id l2R3N7M5042837 for hackers@freebsd.org; Mon, 26 Mar 2007 20:23:07 -0700 (PDT) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: hackers Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Mon, 26 Mar 2007 20:23:06 -0700 Message-Id: <1174965786.42466.3.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV version 0.90.1, clamav-milter version 0.90.1 on tinker.exit.com X-Virus-Status: Clean Cc: Subject: Kerberized NFS work? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 03:50:23 -0000 Is there, by any chance, anyone out there working on kerberized NFS for FreeBSD. That is, the rpcsec_gss support in particular as well as the support in NFS4? I really really want to run FreeBSD on my desktop at work but it needs to talk to kerberized NFS servers... -- Frank Mayhar frank@exit.com http://www.exit.com/ http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 03:58:01 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A7AD16A406 for ; Tue, 27 Mar 2007 03:58:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 589F713C45A for ; Tue, 27 Mar 2007 03:58:01 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 3FB2B1A4D86; Mon, 26 Mar 2007 20:58:01 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3786A513E1; Mon, 26 Mar 2007 23:58:00 -0400 (EDT) Date: Mon, 26 Mar 2007 23:57:59 -0400 From: Kris Kennaway To: Divacky Roman Message-ID: <20070327035759.GA47764@xor.obsecurity.org> References: <20070304141136.GA4935@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070304141136.GA4935@stud.fit.vutbr.cz> User-Agent: Mutt/1.4.2.2i Cc: hackers@freebsd.org Subject: Re: investigation of Giant usage in kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 03:58:01 -0000 On Sun, Mar 04, 2007 at 03:11:36PM +0100, Divacky Roman wrote: > hi > > I looked at where Giant is held in the kernel and I found these interesting things: > > 1) in fs/fifofs/fifo_vnops.c we lock Giant when calling sorecieve()/sosend() > this is a bandaid for fixing a race that doesnt have to exist anymore. ie. > it needs some testing and can be remvoed I have removed this on my test machines and will see if the problem recurs. It is probably not necessary. > 2) in geom/geom_dev.c we lock Giant for: > > 2a) calling make_dev() which seems unecessary because make_dev protects > itself with devmtx > 2b) setting a flag in cdev which I think is unecessary as well I removed this in CVS. > 3) in kern/kern_descrip.c we lock Giant for the whole life of flock() I dont see > a need for this protection becuase > > 3a) access to fp is protected with FILE_LOCK()ing > 3b) otherwise it operates on local variables > 3c) it also calls VOP_* functions but those dont require Giant, right? I am not sure about this one. It might be tied in to 4). > 4) in kern/kern_lockf.c we lock Giant for the whole life of lf_advlock() I dont > think this is necessary because > > 4a) it operates on local variables > 4b) it calls various lf_*lock() functions which seems to either protect > themselves or not needed protection at all There is no synchronization between e.g. the tailq manipulation from different threads, so locking is needed. I have replaced this with a global lockf_mtx in my p4 branch but a finer grained solution is clearly desirable. This will probably involve rewriting or restructuring the code though. > 5) in kern/kern_time.c we lock Giant to protect > > 5a) tc_setclock() call - I dont know if this is necessary or not > 5b) lease_updatetime call which is a function pointer that seems to be > only assigned at one place (line 119 in kern_time.c) to a NOP function. > can this be removed? I guess you are protecting against two threads setting the clock at once. This does not seem to be a big deal, I don't imagine this will ever be in the critical path of anything. > 6) in vm/device_pager.c we lock Giant to (also) protect cdevsw->d_mmap but the device mmap > is either MPSAFE or assigned to giant_mmap (a wrapper that locks GIant and calls the original > d_mmap) so this seems unecessary. I'm not sure about this one either. Kris From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 04:05:19 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53CB916A400 for ; Tue, 27 Mar 2007 04:05:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5B813C458 for ; Tue, 27 Mar 2007 04:05:19 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 23D541A4D93; Mon, 26 Mar 2007 21:05:19 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F1815513EB; Tue, 27 Mar 2007 00:05:17 -0400 (EDT) Date: Tue, 27 Mar 2007 00:05:17 -0400 From: Kris Kennaway To: Ed Schouten Message-ID: <20070327040517.GB47764@xor.obsecurity.org> References: <20070304141136.GA4935@stud.fit.vutbr.cz> <20070304175550.GA18397@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <20070304175550.GA18397@hoeg.nl> User-Agent: Mutt/1.4.2.2i Cc: Divacky Roman , hackers@freebsd.org Subject: Re: investigation of Giant usage in kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 04:05:19 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 04, 2007 at 06:55:50PM +0100, Ed Schouten wrote: > Hello, >=20 > I took a grep on the kernel source and took a look to Giant usage as > well. I too have a question about locking in uipc_domain.c: >=20 > The file has a mutex, dom_mtx, which protects the 'domain list lock', > which could be declared static by the way. The strange thing is that it > isn't used to lock the domain list lock in any way. It is only used to > lock the domain_init_status variable. Wouldn't it be better to rename it > to something better? >=20 > The pf_proto_register() routine locks and unlocks Giant. It looks like > s/Giant/dom_mtx/ would be enough to remove the usage of Giant from > uipc_domain.c. This one doesn't seem to be a big deal because protocol registration is unlikely to happen in a critical path. i.e. a one-time Giant acquisition is completely irrelevant, it's the acquisitions that might happen hundreds or thousands of times a second in certain operational conditions that matter. I have updated the wiki with what seems to be a more or less complete list of the remaining Giant instances in the kernel: http://wiki.freebsd.org/SMPTODO Apart from some subsystems (ttys are the main one), and excluding the items that are being actively worked on (e.g. CAM), there is not much Giant left. Kris --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGCJf9Wry0BWjoQKURArXTAKC5LPaJxFvOKAFe4HUaeOPO9F16FwCfb32G FQ7PY86X2IUNaSTx0FsQMkY= =QgAK -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 07:59:46 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48CF016A403 for ; Tue, 27 Mar 2007 07:59:46 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id C34CE13C448 for ; Tue, 27 Mar 2007 07:59:43 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2R7xbfK011681; Tue, 27 Mar 2007 11:59:37 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2R7xZpV011678; Tue, 27 Mar 2007 11:59:35 +0400 (MSD) (envelope-from yar) Date: Tue, 27 Mar 2007 11:59:34 +0400 From: Yar Tikhiy To: Joseph Koshy Message-ID: <20070327075934.GA10930@comp.chem.msu.su> References: <20070326135106.GG60831@comp.chem.msu.su> <84dead720703260827q29ed7f26hd79dde461fe50d9b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84dead720703260827q29ed7f26hd79dde461fe50d9b@mail.gmail.com> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 07:59:46 -0000 On Mon, Mar 26, 2007 at 08:57:14PM +0530, Joseph Koshy wrote: > >Recently noticed that our sed(1) differs from its GNU > >analog in that in -i mode it considers all files as a > >single sequence of lines while the latter treats each file > >independently. The in-line mode isn't in POSIX, so it isn't > >really clear which way is correct. > > Aren't sed's addresses required to be cumulative across its > input files? > > http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html That makes sense for filter mode because it's equvalent to concatenating the files in advance: cat files ... | sed expression OTOH, in-place mode selected by a -i option can be seen as follows: for f in files ...; do sed expression < $f > $f.tmp && mv $f $f.bak && mv $f.tmp $f done I.e., each file preserves its individuality. This can be at logical conflict with cumulative addresses across all files. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 11:55:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D44BE16A401 for ; Tue, 27 Mar 2007 11:55:22 +0000 (UTC) (envelope-from gurdiga@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id 51C1613C46C for ; Tue, 27 Mar 2007 11:55:22 +0000 (UTC) (envelope-from gurdiga@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so1883523ugh for ; Tue, 27 Mar 2007 04:55:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=YLg5Oy1rKNGRNGCZGnNZ3K/Mc/4W4JhTrZ+MtU+AaeB+pBOO3ON2nc/36lXSGiZqyYBt8vgKHKfchtYQAhnagCM2xnzz85yNzl0mKHF85k8uTBUYpHJUk4C6W6L+Xaaqnnx94r7o9ZkSRR+rYUMyj4ombx50QrSp9edYOAVVopw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=m7YtN9vANXhCgKtnL39IEXUzjMWY2wY27wm7c6i6SOeVANvVZY5iznodr2dCGOAZ7PPULIIQYT4YgC6lRv8l/5XSyAjZUU1My8nixixnuURcyNsMvjWAcWKnWZGjxKedjqzqUXG0lyIBwK4HsYKexGSnROSrJkBPt88O5AVNarA= Received: by 10.67.99.1 with SMTP id b1mr810177ugm.1174994865344; Tue, 27 Mar 2007 04:27:45 -0700 (PDT) Received: by 10.67.25.11 with HTTP; Tue, 27 Mar 2007 04:27:45 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 14:27:45 +0300 From: "Vlad GURDIGA" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15408_6235940.1174994865286" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: IRQ storm X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 11:55:22 -0000 ------=_Part_15408_6235940.1174994865286 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I apologize for repeating post here, but on FreeBSD-questions mailing lists no one gave me an answer. I've changed motherboard recently (now it is Intel DP965LT) and now I have my PC slowed down considerably. vmstat -i shows a huge amount of interrupts on irq17: atapci0: interrupt total rate irq1: atkbd0 12535 4 irq12: psm0 9410 3 irq17: atapci0 189627864 61507 irq19: atapci1+ 391391 126 irq20: em0 29076 9 irq22: pcm0 20557 6 cpu0: timer 6133486 1989 cpu1: timer 6133460 1989 Total 202357779 65636 Since this problem came, my Xorg stopped seeing my PCIE video card. I guess these two could be related. I've tried to boot in safe mode and with ACPI disabled but the problem persists. I've rebuild the kernel with minimal set of options and devices, but it did not help. I've disabled all non-vital devices from BIOS, tried to put my SATA drive in Native and legacy modes, tried with S.M.A.R.T. disabled, disabled USB, FireWire, NIC, serial and parallel ports, floppy controller, but nothing helped. What else should I try? I've attached my dmesg output (with boot_verbose="YES" in loader.conf, that's why it is so large) I do not have atapicam enabled. Here is my kldstat output: # kldstat Id Refs Address Size Name 1 14 0xc0400000 3703a4 kernel 2 1 0xc0771000 6ea8 linprocfs.ko 3 2 0xc0778000 1adb8 linux.ko 4 1 0xc0793000 2364 accf_http.ko 5 1 0xc0796000 aa74 cpufreq.ko 6 1 0xc07a1000 59a50 acpi.ko 7 1 0xc4a7a000 3000 pflog.ko 8 1 0xc4a7d000 2d000 pf.ko I've checked my kernel configuration file and I do not have it there either. What else should I check? After several days of playing in console looking for hardware-related tools, I found that after running this: # atacontrol reinit ata2 the storm was gone. My only HDD in on ata4: # atacontrol info ata4 Master: ad8 Serial ATA II Slave: no device present After this my Xorg is OK again. Now my problem is worked around putting this command (atacontrol reinit ata2) into /etc/rc.local, but what is the cause? Is it a bug? Is there a problem with my hardware? ------=_Part_15408_6235940.1174994865286 Content-Type: text/plain; name=dmesg.log; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ezs97mbs Content-Disposition: attachment; filename="dmesg.log" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItU1RBQkxFICMwOiBTYXQgTWFyIDI0IDA5OjM1 OjMwIEVFVCAyMDA3CiAgICByb290QGtwYXg6L3Vzci9vYmovdXNyL3NyYy9zeXMva3BheApXQVJO SU5HOiBNUFNBRkUgbmV0d29yayBzdGFjayBkaXNhYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9y bWFuY2UuClByZWxvYWRlZCBlbGYga2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGMw Nzk2MDAwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2FjcGkua28iIGF0IDB4 YzA3OTYxZWMuCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MDc2NiBI egpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1c2luZyBkZWZhdWx0 IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxp dHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMjgwMjgxNTk1MyBIegpD UFU6IEludGVsKFIpIFBlbnRpdW0oUikgRCBDUFUgMi44MEdIeiAoMjgwMi44Mi1NSHogNjg2LWNs YXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweGY0NCAgU3RlcHBpbmcg PSA0CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0Us Q1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJ LE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NjQxZDxTU0Uz LFJTVkQyLE1PTixEU19DUEwsQ05UWC1JRCxDWDE2LDxiMTQ+PgogIEFNRCBGZWF0dXJlcz0weDIw MTAwMDAwPE5YLExNPgogIENvcmVzIHBlciBwYWNrYWdlOiAyCnJlYWwgbWVtb3J5ICA9IDEwNTU1 ODAxNjAgKDEwMDYgTUIpClBoeXNpY2FsIG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAx MDAwIC0gMHgwMDAwMDAwMDAwMDhkZmZmLCA1Nzc1MzYgYnl0ZXMgKDE0MSBwYWdlcykKMHgwMDAw MDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAwMDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFn ZXMpCjB4MDAwMDAwMDAwMDgyODAwMCAtIDB4MDAwMDAwMDAzY2NlM2ZmZiwgMTAxMTU5NzMxMiBi eXRlcyAoMjQ2OTcyIHBhZ2VzKQoweDAwMDAwMDAwM2RmNTAwMDAgLSAweDAwMDAwMDAwM2VkZmFm ZmYsIDE1MzgwNDgwIGJ5dGVzICgzNzU1IHBhZ2VzKQoweDAwMDAwMDAwM2VlMDcwMDAgLSAweDAw MDAwMDAwM2VlOWRmZmYsIDYxODQ5NiBieXRlcyAoMTUxIHBhZ2VzKQphdmFpbCBtZW1vcnkgPSAx MDI3Mzc5MjAwICg5NzkgTUIpCk1QIENvbmZpZ3VyYXRpb24gVGFibGUgdmVyc2lvbiAxLjQgZm91 bmQgYXQgMHhjMDBmZTY3MApUYWJsZSAnRkFDUCcgYXQgMHgzZWVmYzAwMApUYWJsZSAnQVBJQycg YXQgMHgzZWVmNjAwMApNQURUOiBGb3VuZCB0YWJsZSBhdCAweDNlZWY2MDAwCkFQSUM6IFVzaW5n IHRoZSBNQURUIGVudW1lcmF0b3IuCk1BRFQ6IEZvdW5kIENQVSBBUElDIElEIDAgQUNQSSBJRCAx OiBlbmFibGVkClNNUDogQWRkZWQgQ1BVIDAgKEFQKQpNQURUOiBGb3VuZCBDUFUgQVBJQyBJRCAx IEFDUEkgSUQgMjogZW5hYmxlZApTTVA6IEFkZGVkIENQVSAxIChBUCkKTUFEVDogRm91bmQgQ1BV IEFQSUMgSUQgMTMwIEFDUEkgSUQgMzogZGlzYWJsZWQKTUFEVDogRm91bmQgQ1BVIEFQSUMgSUQg MTMxIEFDUEkgSUQgNDogZGlzYWJsZWQKSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMCBhcyBhIHRh cmdldApBQ1BJIEFQSUMgVGFibGU6IDxJTlRFTCAgRFA5NjVMVCA+CklOVFI6IEFkZGluZyBsb2Nh bCBBUElDIDEgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBE ZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVApOiBBUElD IElEOiAgMQpwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZmUwZTAKcG5wYmlv czogRW50cnkgPSBmMDAwMDpiMDdmICBSZXYgPSAxLjAKcG5wYmlvczogT0VNIElEIDgyMjQ3NDRl Ck90aGVyIEJJT1Mgc2lnbmF0dXJlcyBmb3VuZDoKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQgMQpB UElDOiBDUFUgMSBoYXMgQUNQSSBJRCAyCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgMiwgSW50ZXJy dXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDIKaW9hcGlj MDogUm91dGluZyBleHRlcm5hbCA4MjU5QSdzIC0+IGludHBpbiAwCk1BRFQ6IEludGVycnVwdCBv dmVycmlkZTogc291cmNlIDAsIGlycSAyCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGlu IDIKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgOSwgaXJxIDkKaW9hcGljMDogaW50 cGluIDkgdHJpZ2dlcjogbGV2ZWwKbGFwaWMwOiBSb3V0aW5nIE5NSSAtPiBMSU5UMQpsYXBpYzE6 IFJvdXRpbmcgTk1JIC0+IExJTlQxCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24g bW90aGVyYm9hcmQKY3B1MCBCU1A6CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNTAw MTQgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxp bnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjog MHgwMDAxMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEw MDAwCm1lbTogPG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbnVsbDog PG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KaW86IDxJL08+CnJhbmRvbTogPGVudHJvcHkgc291 cmNlLCBTb2Z0d2FyZSwgWWFycm93PgpucHgwOiBJTlQgMTYgaW50ZXJmYWNlCmFjcGkwOiA8SU5U RUwgRFA5NjVMVD4gb24gbW90aGVyYm9hcmQKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNB IElSUSA5KSB0byB2ZWN0b3IgNDgKYWNwaTA6IFtNUFNBRkVdCnBjaV9vcGVuKDEpOgltb2RlIDEg YWRkciBwb3J0ICgweDBjZjgpIGlzIDB4ODAwMGZhMTgKcGNpX29wZW4oMWEpOgltb2RlMXJlcz0w eDgwMDAwMDAwICgweDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNjAw MDBdIFtoZHI9MDBdIGlzIHRoZXJlIChpZD0yOWEwODA4NikKcGNpYmlvczogTm8gY2FsbCBlbnRy eSBwb2ludAphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAw CkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMzEgZnVuYyAwCmFjcGlfYnVzX251bWJlcjog cm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAw IGRldiAzMSBmdW5jIDAKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNz dW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDAgZnVuYyAwCmFjcGkwOiBQb3dl ciBCdXR0b24gKGZpeGVkKQphY3BpMDogd2FrZXVwIGNvZGUgdmEgMHhkODYyZjAwMCBwYSAweDhk MDAwCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNw aU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAwIGZ1bmMgMAphY3BpX2J1c19udW1iZXI6IHJvb3Qg YnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYg MCBmdW5jIDAKQUNQSSB0aW1lcjogMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAg MS8wIC0+IDEwClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1 YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9y dCAweDQwOC0weDQwYiBvbiBhY3BpMApwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUg NyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQg NSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNyA5IDEw IDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDkg MTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcg OSAxMCAxMSAxMgpwY2lfbGluazI6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog IEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEy CiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEg MTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAx MSAxMgpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAgMTEgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpw Y2lfbGluazQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgICA5ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlv biAgICAgICAgICAwICAgIDkgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBE aXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGlu azU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgIDEwICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAg ICAgICAwICAgMTAgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazY6ICAg ICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAg ICA5ICAgTiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAw ICAgIDkgICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpwY2lfbGluazc6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAg TiAgICAgMCAgMyA0IDUgNyA5IDEwIDExIDEyCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgMTEg ICBOICAgICAwICAzIDQgNSA3IDkgMTAgMTEgMTIKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDMgNCA1IDcgOSAxMCAxMSAxMgpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmNwdTA6IHN3aXRjaGluZyB0byBnZW5lcmljIEN4IG1vZGUKYWNwaV90aHJvdHRsZTA6IDxBQ1BJ IENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCmFjcGlfdGhyb3R0bGUwOiBQX0NOVCBmcm9tIFBfQkxL IDB4NDEwCmNwdTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90aHJvdHRsZTE6IDxBQ1BJIENQ VSBUaHJvdHRsaW5nPiBvbiBjcHUxCmFjcGlfdGhyb3R0bGUxOiBmYWlsZWQgdG8gYXR0YWNoIFBf Q05UCmRldmljZV9hdHRhY2g6IGFjcGlfdGhyb3R0bGUxIGF0dGFjaCByZXR1cm5lZCA2CmFjcGlf YnV0dG9uMDogPFNsZWVwIEJ1dHRvbj4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMApwY2kwOiBwaHlzaWNhbCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI5 YTAsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwOTAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyOWExLCBy ZXZpZD0weDAyCglidXM9MCwgc2xvdD0xLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBl PTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9 MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgxOCAoNjAwMCBucyks IG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAzICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI5YTQsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTMsIGZ1bmM9 MAoJY2xhc3M9MDctODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwg c3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5z KSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9 MTEKCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRz IDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIDUwMzI1 OTAwLCBzaXplICA0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMuSU5UQQpw Y2liMDogc2xvdCAzIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgpmb3VuZC0+CXZlbmRvcj0weDgw ODYsIGRldj0weDEwNGIsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTI1LCBmdW5jPTAKCWNsYXNz PTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9 MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTkKCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn ZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDUwMzAwMDAwLCBzaXpl IDE3LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDUwMzI0MDAwLCBz aXplIDEyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAzMGMw LCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI1LklOVEEKcGNp YjA6IHNsb3QgMjUgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjgzNCwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MjYsIGZ1bmM9MAoJY2xhc3M9 MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0w eDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCW1hcFsy MF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwYTAsIHNpemUgIDUsIGVuYWJsZWQKcGNp YjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQQpwY2liMDogc2xvdCAyNiBJTlRBIGhhcmR3 aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODM1LCByZXZpZD0w eDAyCglidXM9MCwgc2xvdD0yNiwgZnVuYz0xCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAw LCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3 b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwMzA4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3Ig MC4yNi5JTlRCCnBjaWIwOiBzbG90IDI2IElOVEIgaGFyZHdpcmVkIHRvIElSUSAyMQpmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDI4M2EsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTI2LCBm dW5jPTcKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAw MDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49Yywg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgNTAzMjU0MDAsIHNpemUgMTAsIGVuYWJsZWQKcGNpYjA6 IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQwpwY2liMDogc2xvdCAyNiBJTlRDIGhhcmR3aXJl ZCB0byBJUlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODRiLCByZXZpZD0weDAy CglidXM9MCwgc2xvdD0yNywgZnVuYz0wCgljbGFzcz0wNC0wMy0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29y ZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykKCWludHBpbj1hLCBpcnE9OQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUg MSwgcmFuZ2UgNjQsIGJhc2UgNTAzMjAwMDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMjcuSU5UQQpwY2liMDogc2xvdCAyNyBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMjIKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODNmLCByZXZpZD0weDAyCglidXM9 MCwgc2xvdD0yOCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0x CgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgyODQxLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0yOCwgZnVuYz0xCgljbGFzcz0wNi0w NC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAx MCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1iLCBpcnE9MjU1Cglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3Nh Z2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODQzLCByZXZpZD0weDAyCglidXM9MCwg c2xvdD0yOCwgZnVuYz0yCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0 aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKCWludHBpbj1jLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgyODQ1LCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0yOCwgZnVuYz0zCgljbGFzcz0wNi0wNC0w MCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwg Y2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQg KDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBpcnE9MjU1Cglwb3dlcnNw ZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UK Zm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODQ3LCByZXZpZD0weDAyCglidXM9MCwgc2xv dD0yOCwgZnVuYz00CgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRy ZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK CWludHBpbj1hLCBpcnE9MjU1Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgy ODMwLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0yOSwgZnVuYz0wCgljbGFzcz0wYy0wMy0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJbWFwWzIwXTogdHlwZSA0 LCByYW5nZSAzMiwgYmFzZSAwMDAwMzA2MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hl ZCBlbnRyeSBmb3IgMC4yOS5JTlRBCnBjaWIwOiBzbG90IDI5IElOVEEgaGFyZHdpcmVkIHRvIElS USAyMwpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI4MzEsIHJldmlkPTB4MDIKCWJ1cz0w LCBzbG90PTI5LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAK CWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CglpbnRwaW49YiwgaXJxPTExCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAz MDQwLCBzaXplICA1LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEIK cGNpYjA6IHNsb3QgMjkgSU5UQiBoYXJkd2lyZWQgdG8gSVJRIDE5CmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MjgzMiwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MgoJY2xh c3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNSwgc3RhdHJl Zz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1jLCBpcnE9MTEKCW1h cFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwMjAsIHNpemUgIDUsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQwpwY2liMDogc2xvdCAyOSBJTlRDIGhh cmR3aXJlZCB0byBJUlEgMTgKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODM2LCByZXZp ZD0weDAyCglidXM9MCwgc2xvdD0yOSwgZnVuYz03CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAg KGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxh dD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDUwMzI1MDAw LCBzaXplIDEwLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI5LklOVEEKcGNp YjA6IHNsb3QgMjkgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIzCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MjQ0ZSwgcmV2aWQ9MHhmMgoJYnVzPTAsIHNsb3Q9MzAsIGZ1bmM9MAoJY2xhc3M9 MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDQgKDEwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgyODEwLCByZXZpZD0weDAyCglidXM9MCwgc2xvdD0zMSwgZnVuYz0wCgljbGFzcz0w Ni0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDIxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDI4MjAsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTIKCWNsYXNzPTAxLTAx LThmLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMmIw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMg MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIs IGJhc2UgMDAwMDMxMzgsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgNCwgcmFuZ2Ug MzIsIGJhc2UgMDAwMDMxNGMsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUgNCwgcmFu Z2UgMzIsIGJhc2UgMDAwMDMxMzAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106IHR5cGUgNCwg cmFuZ2UgMzIsIGJhc2UgMDAwMDMxNDgsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxMTAsIHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxMDAsIHNpemUgIDQsIGVuYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQQpwY2liMDogc2xvdCAzMSBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyODNlLCByZXZpZD0weDAyCgli dXM9MCwgc2xvdD0zMSwgZnVuYz0zCgljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMDAzLCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWIsIGlycT0xMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSA1 MDMyNTgwMCwgc2l6ZSAgOCwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFz ZSAwMDAwMzAwMCwgc2l6ZSAgNSwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4z MS5JTlRCCnBjaWIwOiBzbG90IDMxIElOVEIgaGFyZHdpcmVkIHRvIElSUSAyMQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDI4MjUsIHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTMxLCBmdW5j PTUKCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUs IHN0YXRyZWc9MHgwMmIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTExCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5 cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxMjgsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06 IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxNDQsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsx OF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxMjAsIHNpemUgIDMsIGVuYWJsZWQKCW1h cFsxY106IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMxNDAsIHNpemUgIDIsIGVuYWJsZWQK CW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwZjAsIHNpemUgIDQsIGVuYWJs ZWQKCW1hcFsyNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwZTAsIHNpemUgIDQsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMzEuSU5UQQpwY2liMDogc2xvdCAzMSBJ TlRBIGhhcmR3aXJlZCB0byBJUlEgMTkKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBz dWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MjAwMC0weDJm ZmYKcGNpYjE6ICAgbWVtb3J5IGRlY29kZSAgICAgMHg1MDIwMDAwMC0weDUwMmZmZmZmCnBjaWIx OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4NDAwMDAwMDAtMHg0ZmZmZmZmZgpwY2liMTogY291bGQg bm90IGdldCBQQ0kgaW50ZXJydXB0IHJvdXRpbmcgdGFibGUgZm9yIFxcX1NCXy5QQ0kwLlBFR1Ag LSBBRV9OT1RfRk9VTkQKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKcGNpMTogcGh5c2lj YWwgYnVzPTEKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg1YjYzLCByZXZpZD0weDAwCgli dXM9MSwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2 PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQoJaW50cGluPWEsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQz ICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5 cGUgMywgcmFuZ2UgMzIsIGJhc2UgNDAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQKcGNpYjE6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg0MDAwMDAwMC0weDRmZmZmZmZmOiBnb29kCgltYXBbMTRd OiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAyMDAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIx OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4MjAwMC0weDIwZmY6IGluIHJhbmdlCgltYXBbMThdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDUwMjEwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxOiBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4NTAyMTAwMDAtMHg1MDIxZmZmZjogZ29vZApwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEKcGNpYjA6IHNsb3QgMSBJTlRBIGhhcmR3aXJlZCB0 byBJUlEgMTYKcGNpYjE6IHNsb3QgMCBJTlRBIGlzIHJvdXRlZCB0byBpcnEgMTYKZm91bmQtPgl2 ZW5kb3I9MHgxMDAyLCBkZXY9MHg1YjczLCByZXZpZD0weDAwCglidXM9MSwgc2xvdD0wLCBmdW5j PTEKCWNsYXNzPTAzLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdl IDMyLCBiYXNlIDUwMjAwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgbWVt b3J5IHJhbmdlIDB4NTAyMDAwMDAtMHg1MDIwZmZmZjogZ29vZApwY2kxOiA8ZGlzcGxheSwgVkdB PiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTE6IDxkaXNwbGF5PiBhdCBk ZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxzaW1wbGUgY29tbXM+IGF0IGRl dmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0 d29yayBDb25uZWN0aW9uIFZlcnNpb24gLSA2LjIuOT4gcG9ydCAweDMwYzAtMHgzMGRmIG1lbSAw eDUwMzAwMDAwLTB4NTAzMWZmZmYsMHg1MDMyNDAwMC0weDUwMzI0ZmZmIGlycSAyMCBhdCBkZXZp Y2UgMjUuMCBvbiBwY2kwCmVtMDogUmVzZXJ2ZWQgMHgyMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAg dHlwZSAzIGF0IDB4NTAzMDAwMDAKZW0wOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgx OCB0eXBlIDQgYXQgMHgzMGMwCmVtMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDMgYXQgMHg1MDMyNDAwMAplbTA6IGJwZiBhdHRhY2hlZAplbTA6IEV0aGVybmV0IGFk ZHJlc3M6IDAwOjE5OmQxOjA5OmRlOmRlCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIwIChQQ0kg SVJRIDIwKSB0byB2ZWN0b3IgNDkKZW0wOiBbR0lBTlQtTE9DS0VEXQpwY2kwOiA8c2VyaWFsIGJ1 cywgVVNCPiBhdCBkZXZpY2UgMjYuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2VyaWFs IGJ1cywgVVNCPiBhdCBkZXZpY2UgMjYuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8c2Vy aWFsIGJ1cywgVVNCPiBhdCBkZXZpY2UgMjYuNyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8 bXVsdGltZWRpYT4gYXQgZGV2aWNlIDI3LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaWIyOiAgIHNlY29u ZGFyeSBidXMgICAgIDIKcGNpYjI6ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08g ZGVjb2RlICAgICAgICAweGYwMDAtMHhmZmYKcGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAgMHg1 MDQwMDAwMC0weDUwNGZmZmZmCnBjaWIyOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmZmMDAwMDAt MHhmZmZmZgpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBwaHlzaWNhbCBidXM9 MgpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4xIG9uIHBjaTAKcGNp YjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzCnBj aWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MTAwMC0weDFmZmYKcGNpYjM6ICAgbWVtb3J5IGRl Y29kZSAgICAgMHg1MDEwMDAwMC0weDUwMWZmZmZmCnBjaWIzOiAgIHByZWZldGNoZWQgZGVjb2Rl IDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMwpwY2kzOiBw aHlzaWNhbCBidXM9Mwpmb3VuZC0+CXZlbmRvcj0weDExYWIsIGRldj0weDYxMDEsIHJldmlkPTB4 YjEKCWJ1cz0zLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDEtMDEtOGYsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKCW1hcFsxMF06IHR5cGUgNCwg cmFuZ2UgMzIsIGJhc2UgMDAwMDEwMTgsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHgxMDE4LTB4MTAxZjogaW4gcmFuZ2UKCW1hcFsxNF06IHR5cGUgNCwgcmFu Z2UgMzIsIGJhc2UgMDAwMDEwMjQsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJ L08gcmFuZ2UgMHgxMDI0LTB4MTAyNzogaW4gcmFuZ2UKCW1hcFsxOF06IHR5cGUgNCwgcmFuZ2Ug MzIsIGJhc2UgMDAwMDEwMTAsIHNpemUgIDMsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJL08g cmFuZ2UgMHgxMDEwLTB4MTAxNzogaW4gcmFuZ2UKCW1hcFsxY106IHR5cGUgNCwgcmFuZ2UgMzIs IGJhc2UgMDAwMDEwMjAsIHNpemUgIDIsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJL08gcmFu Z2UgMHgxMDIwLTB4MTAyMzogaW4gcmFuZ2UKCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJh c2UgMDAwMDEwMDAsIHNpemUgIDQsIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHgxMDAwLTB4MTAwZjogaW4gcmFuZ2UKCW1hcFsyNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2Ug NTAxMDAwMDAsIHNpemUgIDksIGVuYWJsZWQKcGNpYjM6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2Ug MHg1MDEwMDAwMC0weDUwMTAwMWZmOiBnb29kCnBjaWIzOiBtYXRjaGVkIGVudHJ5IGZvciAzLjAu SU5UQQpwY2liMzogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNwphdGFwY2kwOiA8R0VO RVJJQyBBVEEgY29udHJvbGxlcj4gcG9ydCAweDEwMTgtMHgxMDFmLDB4MTAyNC0weDEwMjcsMHgx MDEwLTB4MTAxNywweDEwMjAtMHgxMDIzLDB4MTAwMC0weDEwMGYgbWVtIDB4NTAxMDAwMDAtMHg1 MDEwMDFmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kzCmF0YXBjaTA6IFJlc2VydmVkIDB4 MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDEwMDAKaW9hcGljMDogcm91dGluZyBp bnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIHZlY3RvciA1MAphdGFwY2kwOiBbTVBTQUZFXQphdGEy OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMg Zm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDEwMTgKYXRhcGNpMDogUmVzZXJ2ZWQgMHg0IGJ5dGVz IGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgxMDI0CmF0YTI6IHJlc2V0IHRwMSBtYXNrPTAzIG9z dGF0MD01MCBvc3RhdDE9MDAKYXRhMjogc3RhdDA9MHgwMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9 MHhlYgphdGEyOiBzdGF0MT0weDAwIGVycj0weDAwIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHJl c2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmF0YTI6 IFtNUFNBRkVdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2Vy dmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTAxMAphdGFwY2kwOiBSZXNl cnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDEwMjAKYXRhMzogcmVzZXQg dHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNi PTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJy PTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0 YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6 IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogc3RhdDA9MHg3ZiBl cnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0w eGZmIG1zYj0weGZmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYK YXRhMzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGEzOiBzdGF0MD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTM6IHN0YXQxPTB4N2YgZXJyPTB4ZmYg bHNiPTB4ZmYgbXNiPTB4ZmYKYXRhMzogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRldmlj ZXM9MHgwCmF0YTM6IFtNUFNBRkVdCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDI4LjIgb24gcGNpMApwY2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1 Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZm CnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4NTA1MDAwMDAtMHg1MDVmZmZmZgpwY2liNDog ICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpNDogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjQKcGNpNDogcGh5c2ljYWwgYnVzPTQKcGNpYjU6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaWI1OiAgIHNlY29uZGFyeSBidXMgICAgIDUK cGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQpwY2liNTogICBJL08gZGVjb2RlICAgICAgICAw eGYwMDAtMHhmZmYKcGNpYjU6ICAgbWVtb3J5IGRlY29kZSAgICAgMHg1MDYwMDAwMC0weDUwNmZm ZmZmCnBjaWI1OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZgpwY2k1OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2k1OiBwaHlzaWNhbCBidXM9NQpwY2liNjogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC40IG9uIHBjaTAKcGNpYjY6ICAgc2Vjb25kYXJ5 IGJ1cyAgICAgNgpwY2liNjogICBzdWJvcmRpbmF0ZSBidXMgICA2CnBjaWI2OiAgIEkvTyBkZWNv ZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liNjogICBtZW1vcnkgZGVjb2RlICAgICAweDUwNzAw MDAwLTB4NTA3ZmZmZmYKcGNpYjY6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZmYwMDAwMC0weGZm ZmZmCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnBjaTY6IHBoeXNpY2FsIGJ1cz02CnBj aTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyOS4wIChubyBkcml2ZXIgYXR0YWNoZWQp CnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyOS4xIChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyOS4yIChubyBkcml2ZXIgYXR0 YWNoZWQpCnBjaTA6IDxzZXJpYWwgYnVzLCBVU0I+IGF0IGRldmljZSAyOS43IChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaWI3OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24g cGNpMApwY2liNzogICBzZWNvbmRhcnkgYnVzICAgICA3CnBjaWI3OiAgIHN1Ym9yZGluYXRlIGJ1 cyAgIDcKcGNpYjc6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWI3OiAgIG1l bW9yeSBkZWNvZGUgICAgIDB4NTAwMDAwMDAtMHg1MDBmZmZmZgpwY2liNzogICBwcmVmZXRjaGVk IGRlY29kZSAweGZmZjAwMDAwLTB4ZmZmZmYKcGNpYjc6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVk IGJyaWRnZS4KcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpNzogcGh5c2ljYWwgYnVz PTcKZm91bmQtPgl2ZW5kb3I9MHgxMDRjLCBkZXY9MHg4MDIzLCByZXZpZD0weDAwCglidXM9Nywg c2xvdD0zLCBmdW5jPTAKCWNsYXNzPTBjLTAwLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNt ZHJlZz0weDAwMTYsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRp bWVyPTB4MjAgKDk2MCBucyksIG1pbmdudD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAw MCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBE MyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSA1MDAwNDAwMCwg c2l6ZSAxMSwgZW5hYmxlZApwY2liNzogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweDUwMDA0MDAw LTB4NTAwMDQ3ZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgNTAwMDAw MDAsIHNpemUgMTQsIGVuYWJsZWQKcGNpYjc6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHg1MDAw MDAwMC0weDUwMDAzZmZmOiBnb29kCnBjaWI3OiBtYXRjaGVkIGVudHJ5IGZvciA3LjMuSU5UQQpw Y2liNzogc2xvdCAzIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxOQpwY2k3OiA8c2VyaWFsIGJ1cywg RmlyZVdpcmU+IGF0IGRldmljZSAzLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0kt SVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNh YjAKYXRhcGNpMTogPEludGVsIElDSDggU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4MzEzOC0w eDMxM2YsMHgzMTRjLTB4MzE0ZiwweDMxMzAtMHgzMTM3LDB4MzE0OC0weDMxNGIsMHgzMTEwLTB4 MzExZiwweDMxMDAtMHgzMTBmIGlycSAxOSBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmF0YXBjaTE6 IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDMxMTAKaW9hcGlj MDogcm91dGluZyBpbnRwaW4gMTkgKFBDSSBJUlEgMTkpIHRvIHZlY3RvciA1MQphdGFwY2kxOiBb TVBTQUZFXQphdGE0OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZl ZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDMxMzgKYXRhcGNpMTogUmVzZXJ2 ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzMTRjCmF0YTQ6IHJlc2V0IHRw MSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhNDogc3RhdDA9MHg1MCBlcnI9MHgwMSBs c2I9MHgwMCBtc2I9MHgwMAphdGE0OiBzdGF0MT0weDAwIGVycj0weDAxIGxzYj0weDAwIG1zYj0w eDAwCmF0YTQ6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFT VEVSPgphdGE0OiBbTVBTQUZFXQphdGE1OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQphdGFw Y2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDMxMzAKYXRh cGNpMTogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzMTQ4CmF0 YTU6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD03ZiBvc3RhdDE9N2YKYXRhNTogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6 IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBl cnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0w eGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYK YXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYg bHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9 MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHN0 YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNTogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTU6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh NTogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE1OiBzdGF0MT0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTU6IHJlc2V0IHRwMiBzdGF0MD1mZiBzdGF0 MT1mZiBkZXZpY2VzPTB4MAphdGE1OiBbTVBTQUZFXQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+ IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YXBjaTI6IDxJbnRlbCBJQ0g4 IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDMxMjgtMHgzMTJmLDB4MzE0NC0weDMxNDcsMHgz MTIwLTB4MzEyNywweDMxNDAtMHgzMTQzLDB4MzBmMC0weDMwZmYsMHgzMGUwLTB4MzBlZiBpcnEg MTkgYXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGFwY2kyOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZv ciByaWQgMHgyMCB0eXBlIDQgYXQgMHgzMGYwCmF0YXBjaTI6IFtNUFNBRkVdCmF0YTY6IDxBVEEg Y2hhbm5lbCAwPiBvbiBhdGFwY2kyCmF0YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Igcmlk IDB4MTAgdHlwZSA0IGF0IDB4MzEyOAphdGFwY2kyOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJp ZCAweDE0IHR5cGUgNCBhdCAweDMxNDQKYXRhNjogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTdm IG9zdGF0MT03ZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0 YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4 ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4 ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6 IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBl cnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0w eGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYK YXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0YXQwPTB4N2YgZXJyPTB4ZmYg bHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9 MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTY6IHN0 YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNjogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE2OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTY6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh NjogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgwCmF0YTY6IFtNUFNBRkVd CmF0YTc6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kyCmF0YXBjaTI6IFJlc2VydmVkIDB4OCBi eXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MzEyMAphdGFwY2kyOiBSZXNlcnZlZCAweDQg Ynl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweDMxNDAKYXRhNzogcmVzZXQgdHAxIG1hc2s9 MDMgb3N0YXQwPTdmIG9zdGF0MT03ZgphdGE3OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmCmF0YTc6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRh Nzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE3OiBzdGF0MD0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTc6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNi PTB4ZmYgbXNiPTB4ZmYKYXRhNzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm ZgphdGE3OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTc6IHN0YXQw PTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNzogc3RhdDA9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE3OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmCmF0YTc6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNzog c3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE3OiBzdGF0MD0weDdmIGVy cj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTc6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4 ZmYgbXNiPTB4ZmYKYXRhNzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgph dGE3OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTc6IHN0YXQwPTB4 N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNzogc3RhdDA9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZgphdGE3OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0w eGZmCmF0YTc6IHN0YXQwPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYgbXNiPTB4ZmYKYXRhNzogc3Rh dDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZgphdGE3OiBzdGF0MD0weDdmIGVycj0w eGZmIGxzYj0weGZmIG1zYj0weGZmCmF0YTc6IHN0YXQxPTB4N2YgZXJyPTB4ZmYgbHNiPTB4ZmYg bXNiPTB4ZmYKYXRhNzogcmVzZXQgdHAyIHN0YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgwCmF0 YTc6IFtNUFNBRkVdCnBzbWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAK YXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAweDYwLDB4NjQgaXJx IDEgb24gYWNwaTAKYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKYXRrYmQ6 IHRoZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY3CmF0a2JkOiBrZXli b2FyZCBJRCAweDQxYWIgKDIpCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQgMTAxLzEw MiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGlu IDEgKElTQSBJUlEgMSkgdG8gdmVjdG9yIDUyCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDog Y3VycmVudCBjb21tYW5kIGJ5dGU6MDA2Nwpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0 a2JkYzAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTIgKElTQSBJUlEgMTIpIHRvIHZlY3RvciA1 Mwpwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBtb2RlbCBJbnRlbGxpTW91c2UsIGRldmljZSBJ RCAzLTAwLCAzIGJ1dHRvbnMKcHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwOCwg cGFja2V0IHNpemU6NApwc20wOiBzeW5jbWFzazowOCwgc3luY2JpdHM6MDAKYXRrYmRjOiBhdGti ZGMwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdApzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBz a2lwcGluZyBpdAp2Z2E6IHZnYTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyMDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDI0MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjgzCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyYzMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDMwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzQzCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDNjMwpQTlAgSWRlbnRpZnkgY29tcGxldGUKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNh YmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2 aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4Y2ZmZmYsMHhk MDAwMC0weGQwZmZmLDB4ZDEwMDAtMHhkMWZmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xl PiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBm bGFncz0weDMwMD4Kc2MwOiBmYjAsIGtiZDAsIHRlcm1pbmFsIGVtdWxhdG9yOiBzYyAoc3lzY29u cyB0ZXJtaW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAphZHYwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK YWhhMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFpYzA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQph dGEwIGF0IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYgaXJxIDE0IG9uIGlzYTAKYXRhMDogcmVzZXQg dHAxIG1hc2s9MDAgb3N0YXQwPWZmIG9zdGF0MT1mZgppb2FwaWMwOiByb3V0aW5nIGludHBpbiAx NCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDU0CmF0YTA6IFtNUFNBRkVdCmF0YTEgYXQgcG9ydCAw eDE3MC0weDE3NywweDM3NiBpcnEgMTUgb24gaXNhMAphdGExOiByZXNldCB0cDEgbWFzaz0wMCBv c3RhdDA9ZmYgb3N0YXQxPWZmCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1 KSB0byB2ZWN0b3IgNTUKYXRhMTogW01QU0FGRV0KYnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkK Y3MwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZWQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKZmRj MCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBv biBpc2EwCmZlMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmllMDogbm90IHByb2JlZCAoZGlzYWJs ZWQpCmxuYzA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpwcGMwIGZhaWxlZCB0byBwcm9iZSBhdCBp cnEgNyBvbiBpc2EwCnNpbzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjggaXJxIDQgb24g aXNhMApzaW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4IGlycSAzIG9uIGlzYTAKc2lv Mjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpzbjA6 IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2dDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQppc2FfcHJv YmVfY2hpbGRyZW46IHByb2JpbmcgUG5QIGRldmljZXMKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmlu aXNoZWQuCnByb2NmcyByZWdpc3RlcmVkCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSAxMDAx MDAyODAgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI4MDI4MTU5NTMgSHogcXVhbGl0 eSAtMTAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKSVBzZWM6IEluaXRpYWxp emVkIFNlY3VyaXR5IEFzc29jaWF0aW9uIFByb2Nlc3NpbmcuCmxvMDogYnBmIGF0dGFjaGVkCnBm bG9nMDogYnBmIGF0dGFjaGVkCnBmc3luYzA6IGJwZiBhdHRhY2hlZAplbTA6IExpbmsgaXMgdXAg MTAwIE1icHMgRnVsbCBEdXBsZXgKYXRhNC1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRt YT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQ4OiAxNTI2MjdNQiA8U2VhZ2F0ZSBTVDMxNjA4MTJB UyAzLkFBRD4gYXQgYXRhNC1tYXN0ZXIgU0FUQTE1MAphZDg6IDMxMjU4MTgwOCBzZWN0b3JzIFsz MTAxMDFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKU01QOiBB UCBDUFUgIzEgTGF1bmNoZWQhCmNwdTEgQVA6CiAgICAgSUQ6IDB4MDEwMDAwMDAgICBWRVI6IDB4 MDAwNTAwMTQgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEw NzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0 aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAw eDAwMDEwMDAwCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDEgdG8gbG9jYWwgQVBJQyAwCmlv YXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDkgdG8gbG9jYWwgQVBJQyAxCmlvYXBpYzA6IEFzc2ln bmluZyBJU0EgSVJRIDEyIHRvIGxvY2FsIEFQSUMgMAppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElS USAxNCB0byBsb2NhbCBBUElDIDEKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMTUgdG8gbG9j YWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE3IHRvIGxvY2FsIEFQSUMgMQpp b2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAxOSB0byBsb2NhbCBBUElDIDAKaW9hcGljMDogQXNz aWduaW5nIFBDSSBJUlEgMjAgdG8gbG9jYWwgQVBJQyAxCkdFT006IG5ldyBkaXNrIGFkOApUcnlp bmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkOHMyYQpzdGFydF9pbml0OiB0cnlpbmcg L3NiaW4vaW5pdApXQVJOSU5HOiAvdXNyIHdhcyBub3QgcHJvcGVybHkgZGlzbW91bnRlZAplbTA6 IExpbmsgaXMgRG93bgplbTA6IExpbmsgaXMgdXAgMTAwIE1icHMgRnVsbCBEdXBsZXgK ------=_Part_15408_6235940.1174994865286-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 15:25:15 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6D7D16A401 for ; Tue, 27 Mar 2007 15:25:15 +0000 (UTC) (envelope-from geek.dwells@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7089613C4DA for ; Tue, 27 Mar 2007 15:25:14 +0000 (UTC) (envelope-from geek.dwells@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so1215908wra for ; Tue, 27 Mar 2007 08:25:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=sWxqxC4hBFGYfZyPn/ux9DS/1h8OzmQqy/RPKHNOnC+qZGw2CQHR+QIEjK8OmkKbJcR8JrZOTMr10AAVqJWNVxXu5JzQNhB9cXIPsjPMrDL57UuEZ2UqB3U2JG9gqJX5xqORl6WGQvAuzq05g+NViIgqnOONpw//cBmpW4r4MpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=YqcKJKwSyNPqMdOjb7N/VkQsQgi45HNaEIyVP9cj5mjY0jf6NhpONkwLTk5jarJjYouF3RIz/fQBdys3u/s4tevSMHtEzVCRO1bg8Qg1bxyw8Zbs3DhbMXbg7SFGjMuAOkxU4KN7oldTKngAKnLNTnpOoxc4gnAyRsx8xYDbeN4= Received: by 10.114.169.2 with SMTP id r2mr3194338wae.1175009109747; Tue, 27 Mar 2007 08:25:09 -0700 (PDT) Received: by 10.115.16.3 with HTTP; Tue, 27 Mar 2007 08:25:09 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 20:55:09 +0530 From: "ajay gopalakrishnan" To: "Julian H. Stacey" , freebsd-hackers@freebsd.org In-Reply-To: <200703251948.l2PJmRrP084218@fire.jhs.private> MIME-Version: 1.0 References: <20070324145233.21891248@Magellan.Leidinger.net> <200703251948.l2PJmRrP084218@fire.jhs.private> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Have people started working on any Google Summer of code 2007 project? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 15:25:16 -0000 Hi, Is FreeBSD restricting non-students from not taking up any project that is 'suitable for summer of code'? For eg. I was planning to take up the 'super tunnel daemon' project some time back. I had done some initial work but now i find that it has also been marked as 'Suitable for summer of code'. I am no longer a student. I am working currently at a firm. So i dont think that i will be eligible for the summer of code. Can i still take up the project or am i forced to take up those that are not marked as 'suitable for summer of code'? Also, if someone has taken a summer of code project can no-one else take it up as a normal project to contribute to FreeBSD ? Awaiting a reply, Ajay. On 3/26/07, Julian H. Stacey wrote: > > Alexander Leidinger wrote: > > Quoting "ajay gopalakrishnan" (Sat, 24 Mar 2007 > 15:53:11 +0530): > > > > > Have people started working on any Google Summer of code 2007 project? > I saw > > > some project ideas marked as "Suitable for Summer of code" on the > project > > > ideas web page. But have any of those projects been taken up? > > > > Proposals are submitted by students to Google and available for rating > > in the mentor-interface. No proposal is selected yet and we don't know > > yet how many seats for students we have in this SoC. > > > > I suggest to have a look at the Google SoC pages, they provide a > > timeline there. > > Quoting http://code.google.com/soc/ > We've extended the deadline for student applications to Monday, March 26, > 2007. > > -- > Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. > http://berklix.com > Escape Microsoft 20th April 2007: http://berklix.com/free/talk/ > Ihr Rauch = mein allergischer Kopfschmerz. > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 27 16:16:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E83A16A413 for ; Tue, 27 Mar 2007 16:16:37 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from thin.berklix.org (thin.berklix.org [194.246.123.68]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA1113C4BD for ; Tue, 27 Mar 2007 16:16:36 +0000 (UTC) (envelope-from jhs@flat.berklix.net) Received: from js.berklix.net (p549A4CC8.dip.t-dialin.net [84.154.76.200]) (authenticated bits=128) by thin.berklix.org (8.12.11/8.12.11) with ESMTP id l2RGGT6q069228; Tue, 27 Mar 2007 18:16:30 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (fire.jhs.private [192.168.91.41]) by js.berklix.net (8.13.6/8.13.6) with ESMTP id l2RGGS2O036314; Tue, 27 Mar 2007 18:16:28 +0200 (CEST) (envelope-from jhs@flat.berklix.net) Received: from fire.jhs.private (localhost.jhs.private [127.0.0.1]) by fire.jhs.private (8.13.6/8.13.6) with ESMTP id l2RGGRJG088685; Tue, 27 Mar 2007 18:16:27 +0200 (CEST) (envelope-from jhs@fire.jhs.private) Message-Id: <200703271616.l2RGGRJG088685@fire.jhs.private> To: "ajay gopalakrishnan" From: "Julian Stacey" Organization: http://berklix.com BSD Unix C Net Consultancy, Munich/Muenchen User-agent: EXMH http://beedub.com/exmh/ on FreeBSD http://freebsd.org X-URL: http://berklix.com X-Fallback: jhs@mail.brierdr.com, jhs@freebsd.org, jhs@berklix.net In-reply-to: Your message of "Tue, 27 Mar 2007 20:55:09 +0530." Date: Tue, 27 Mar 2007 18:16:27 +0200 Sender: jhs@flat.berklix.net Cc: freebsd-hackers@freebsd.org Subject: Re: Have people started working on any Google Summer of code 2007 project? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2007 16:16:37 -0000 Reference: > From: "ajay gopalakrishnan" > Is FreeBSD restricting non-students from not taking up any project that is > 'suitable for summer of code'? > For eg. > I was planning to take up the 'super tunnel daemon' project some time back. > I had done some initial work but now i find that it has also been marked as > 'Suitable for summer of code'. I am no longer a student. I am working > currently at a firm. So i dont think that i will be eligible for the summer > of code. Can i still take up the project or am i forced to take up those > that are not marked as 'suitable for summer of code'? > Also, if someone has taken a summer of code project can no-one else take it > up as a normal project to contribute to FreeBSD ? > > Awaiting a reply, > Ajay. As I'm on To: line. (Though I have no special status other than being last poster), to ensure you get some reply, My 2c. : No can stop anyone working; Be a shame though if 2 people work & one's effort was not used. I suppose as SoC deadline was yesterday it'll take a while for google to publish their sponsoring list. If 2 people develope same thing: whose code will be commited will I suppose be decided on which arrives first &/or seems best code, hopefully independent of status of author eg student V. independent. End of non authoritative 2 cents worth :-) -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Escape Microsoft 20th April 2007: http://berklix.com/free/talk/ Ihr Rauch = mein allergischer Kopfschmerz. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 00:53:49 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A2C416A400 for ; Wed, 28 Mar 2007 00:53:49 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0655D13C45D for ; Wed, 28 Mar 2007 00:53:48 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp126-26.lns2.adl4.internode.on.net [121.44.126.26]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l2S0rfRF016415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2007 10:23:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Steve Watt Date: Wed, 28 Mar 2007 10:23:27 +0930 User-Agent: KMail/1.9.5 References: <200703231617.l2NGHDlu074159@wattres.watt.com> In-Reply-To: <200703231617.l2NGHDlu074159@wattres.watt.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1795497.Prg59siEbL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703281023.35665.doconnor@gsoft.com.au> X-Spam-Score: -2.312 () BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: sendto() giving EPERM outside a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 00:53:49 -0000 --nextPart1795497.Prg59siEbL Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 24 March 2007 02:47, Steve Watt wrote: > >According to my reading of the man page it is not possible to get this > > error unless I'm using jails (which I'm not). The code in question does= =2E. > That's probably a buglet in the man page. I guess it would be nice if the man page(s) mentioned that a firewall could= =20 cause EPERM. I have seen it before with other apps but the sendto() confuse= d=20 me. > >Can someone shed light on what the problem is? The application appears to > > work fine even with this error though. > > man setsockopt, search for SO_BROADCAST. It doesn't say anything about EPERM. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1795497.Prg59siEbL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBGCbyP5ZPcIHs/zowRArn1AKCWAKgABl3I/56NLFdhYcgyIoUPfgCeIQut InJt75uUUZ3W3sn8kyXIKuQ= =R1fq -----END PGP SIGNATURE----- --nextPart1795497.Prg59siEbL-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 01:24:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D868916A400 for ; Wed, 28 Mar 2007 01:24:20 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (wattres.watt.com [66.93.133.130]) by mx1.freebsd.org (Postfix) with ESMTP id BB82213C44B for ; Wed, 28 Mar 2007 01:24:20 +0000 (UTC) (envelope-from steve@Watt.COM) Received: from wattres.watt.com (localhost.watt.com [127.0.0.1]) by wattres.watt.com (8.13.8/8.13.8) with ESMTP id l2S1OF53028862; Tue, 27 Mar 2007 18:24:20 -0700 (PDT) (envelope-from steve@wattres.watt.com) Received: (from steve@localhost) by wattres.watt.com (8.13.8/8.13.8/Submit) id l2S1OFI5028861; Tue, 27 Mar 2007 18:24:15 -0700 (PDT) (envelope-from steve) Message-Id: <200703280124.l2S1OFI5028861@wattres.watt.com> From: steve@Watt.COM (Steve Watt) Date: Tue, 27 Mar 2007 18:24:14 -0700 In-Reply-To: "Daniel O'Connor" "Re: sendto() giving EPERM outside a jail" (Mar 28, 10:23) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Daniel O'Connor" , Steve Watt X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (wattres.watt.com [127.0.0.1]); Tue, 27 Mar 2007 17:24:20 -0800 (PST) X-Archived: 1175045060.258568752@wattres.Watt.COM Cc: freebsd-hackers@freebsd.org Subject: Re: sendto() giving EPERM outside a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 01:24:20 -0000 On Mar 28, 10:23, "Daniel O'Connor" wrote: } Subject: Re: sendto() giving EPERM outside a jail } } On Saturday 24 March 2007 02:47, Steve Watt wrote: } > >According to my reading of the man page it is not possible to get this } > > error unless I'm using jails (which I'm not). The code in question does. } > That's probably a buglet in the man page. } } I guess it would be nice if the man page(s) mentioned that a firewall could } cause EPERM. I have seen it before with other apps but the sendto() confused } me. It's one of those unpleasant interactions between pluggable subsystems, so it's a bit tough to document -- there are various different firewalls available, after all. } > >Can someone shed light on what the problem is? The application appears to } > > work fine even with this error though. } > } > man setsockopt, search for SO_BROADCAST. } } It doesn't say anything about EPERM. If you're sending broadcast broadcast or multicast datagrams, you need to set the SO_BROADCAST socket option, as well. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 09:01:09 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF61C16A403 for ; Wed, 28 Mar 2007 09:01:09 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from smtpout.eastlink.ca (smtpout.eastlink.ca [24.222.0.30]) by mx1.freebsd.org (Postfix) with ESMTP id 774A613C487 for ; Wed, 28 Mar 2007 09:01:09 +0000 (UTC) (envelope-from duane@dwlabs.ca) Received: from ip04.eastlink.ca ([24.222.10.20]) by mta01.eastlink.ca (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JFL003JPUBG37R0@mta01.eastlink.ca> for freebsd-hackers@freebsd.org; Wed, 28 Mar 2007 05:30:52 -0300 (ADT) Received: from blk-224-199-230.eastlink.ca (HELO dwpc.dwlabs.ca) ([24.224.199.230]) by ip04.eastlink.ca with ESMTP; Wed, 28 Mar 2007 05:29:55 -0300 Received: from dwpc.dwlabs.ca (ftp.dwlabs.ca [192.168.0.10]) by dwpc.dwlabs.ca (8.13.8/8.13.8) with ESMTP id l2S8QLJq010736; Wed, 28 Mar 2007 05:26:27 -0300 (ADT envelope-from duane@dwpc.dwlabs.ca) Received: (from duane@localhost) by dwpc.dwlabs.ca (8.13.8/8.13.8/Submit) id l2S8QLca010735; Wed, 28 Mar 2007 05:26:21 -0300 (ADT envelope-from duane) Date: Wed, 28 Mar 2007 05:26:20 -0300 From: Duane Whitty To: freebsd-hackers@freebsd.org Message-id: <20070328082620.GA1052@dwpc.dwlabs.ca> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABzFCUYY4MfmdGdsb2JhbACQAg X-IronPort-AV: i="4.14,339,1170648000"; d="scan'208"; a="167497660:sNHT33283782" X-Virus-Scanned: ClamAV 0.88.6/2945/Tue Mar 27 19:58:50 2007 on dwpc.dwlabs.ca X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on dwpc.dwlabs.ca User-Agent: Mutt/1.4.2.2i X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Cc: Duane Whitty Subject: Locking etc. (Long, boring, redundant, newbie questions) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 09:01:09 -0000 Hello again, I know this is trivial material but I believe I have finally come to an understanding about some things that I have been struggling with. Maybe by putting this in words I can help some other newbies like myself who are hoping to eventually understand more advanced topics and contribute to FreeBSD. But please, correct me if you would on topics I still do not have correct. And thanks in advance for your help and patience! I have been reading non-stop as much as I can on synchronizing code execution. In the FreeBSD docs, and in other docs, there is talk about mutexes that block and mutexes that sleep. But this is not true is it. What is really meant is that depending on the type of mutex a thread is trying to acquire, the thread will either spin or it will sleep waiting for the lock to become available. Am I correct so far? Maybe this method of talking about mutexes happens because we don't manipulate lock structures directly, but rather use routines which acquire these locks for us in a consistent way. So for instance when we call mtx_lock(&some_lock) and the lock is contested, our thread sleeps. It gets put on a sleep queue waiting for the lock to become available so that we can safely access the kernel data structure which this mutex protects. Is this accurate so far? Along the same line as above, if we call mtx_lock_spin(&some_lock), and the lock is contested, our thread trying to acquire the lock spins. This means we go into a tight loop monopolizing whichever CPU we are running on until the mutex becomes available. But, if we spin for so long that we use up our quantum of time scheduled to us, a panic happens, because when we try to acquire a spin mutex, interrupts are turned off and so we can't do a context switch. If a thread slept with interrupts disabled, then interrupts would stay disabled, which must not happen. [insert] I'm not very sure on this point, but is the above the reason why interrupt service routines, also known as Fast ISRs (?), use mtx_lock_spin() mutexes? They are supposed to be as fast as possible, and they don't context switch. As well, isn't it basically agreed upon that Fast ISRs are really the only place to use spin mutexes? Maybe I'm way off here but it sure would be nice finally putting this one away. A somewhat newer (?) type of locking procedure is where a thread will spin when trying to acquire a lock which is contested, for about the same amount of time as it would take to do a context switch. If this time is roughly (approached|exceeded)? then the thread sleeps. The reasoning is that in the time it would take to do a context switch if the thread were to sleep, the lock the thread is trying to acquire may become available. If we get lucky and the lock becomes available while we are spinning then we have been more efficient. I hope I am still on the right track here? Another item in the documentation I had confused as being part of the above issue(s) is that it is permissible for a thread to sleep while holding certain types of locks and that for other types of locks a thread must not sleep. Am I correct in my understanding now that a thread must not sleep while holding a mutex because doing so could lead to a deadlock? Another scenario I have just learned is that a semaphore should not be wrapped inside a mutex, for the same reason; a deadlock. I guess this is just a specific case of not allowing the possibilty of a thread sleeping while holding a mutex, which is what could happen if a thread is waiting on any kind of condition variable? If I am mostly correct (I hope), my enlightenment, if I have any came about when I started working on the System V IPC code. When I started trying to learn about semaphores I found out I needed to learn about a lot of other stuff. And still do. Perhaps the most difficult thing is translating from textbook type examples to real kernel code. Anyhow, I hope this message wasn't too long or unbearable. Please send me any comments that you would like to, on or off list. Thanks again! Duane Whitty P.S. I think I'm just about ready to tackle fixing sysv sems to wakeup just the proper number of processes, now that I think I know what an up'ed semaphore is, what a semaphore set is for, how semops work, and adjust on exit values, and not least, undos. My head hurts :-) From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 09:40:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 542FC16A400 for ; Wed, 28 Mar 2007 09:40:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id E32C613C458 for ; Wed, 28 Mar 2007 09:40:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6B21F47637; Wed, 28 Mar 2007 04:40:58 -0500 (EST) Date: Wed, 28 Mar 2007 10:40:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Duane Whitty In-Reply-To: <20070328082620.GA1052@dwpc.dwlabs.ca> Message-ID: <20070328102027.T1185@fledge.watson.org> References: <20070328082620.GA1052@dwpc.dwlabs.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Locking etc. (Long, boring, redundant, newbie questions) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 09:40:59 -0000 On Wed, 28 Mar 2007, Duane Whitty wrote: > I know this is trivial material but I believe I have finally come to an > understanding about some things that I have been struggling with. Maybe by > putting this in words I can help some other newbies like myself who are > hoping to eventually understand more advanced topics and contribute to > FreeBSD. But please, correct me if you would on topics I still do not have > correct. And thanks in advance for your help and patience! We are working to improve our documentation in this area, but there are a number of issues relating to consistent use of terminology, some of which you are running into. > I have been reading non-stop as much as I can on synchronizing code > execution. In the FreeBSD docs, and in other docs, there is talk about > mutexes that block and mutexes that sleep. But this is not true is it. > What is really meant is that depending on the type of mutex a thread is > trying to acquire, the thread will either spin or it will sleep waiting for > the lock to become available. Am I correct so far? We basically have two kinds of mutexes: mutexes that only spin, and mutexes that may also sleep. The former category is intended for use in synchronizing with fast interrupts and in the scheduler, and are called "spin mutexes". The latter are intended for use in pretty much any other case, and are called "default mutexes". In terms of implementation, the main behaviors are: - Spin mutexes will never sleep, and hence can be used in a borrowed execution context during interrupt delivery, and likewise in the scheduler (such as in implementing sleep). They disable interrupt delivery on the current CPU, and as such, are quite expensive to acquire on some architectures. - Default mutexes may sleep, but by default are "adaptive", meaning that they will try spinning where it makes sense (i.e., when the holder of the lock is executing on another CPU). Unless you are working in the scheduler or synchronizing in/with a fast interrupt handler, do not use spin mutexes. > Maybe this method of talking about mutexes happens because we don't > manipulate lock structures directly, but rather use routines which acquire > these locks for us in a consistent way. So for instance when we call > mtx_lock(&some_lock) and the lock is contested, our thread sleeps. It gets > put on a sleep queue waiting for the lock to become available so that we can > safely access the kernel data structure which this mutex protects. Is this > accurate so far? Yes, although for reasons of optimization, when contending a lock we may spin instead of sleeping if the thread holding the mutex is in the run state. This avoids the overhead of putting the current thread to sleep and then waking it up later. The benefits of this optimization are significant and easily measurable. > Along the same line as above, if we call mtx_lock_spin(&some_lock), and the > lock is contested, our thread trying to acquire the lock spins. This means > we go into a tight loop monopolizing whichever CPU we are running on until > the mutex becomes available. But, if we spin for so long that we use up our > quantum of time scheduled to us, a panic happens, because when we try to > acquire a spin mutex, interrupts are turned off and so we can't do a context > switch. If a thread slept with interrupts disabled, then interrupts would > stay disabled, which must not happen. Pretty much. We disable interrupts for the following reason: as spin mutexes may be acquired in fast interrupt handlers, they may be running on the stack of an existing thread, which may also hold locks. As such, we can't allow the fast handler to acquire any locks that are either already held by the thread, or that might violate the lock order. By restricting fast interrupt handlers to holding only spin locks, and by making spin locks disable interrupts, we prevent that deadlock scenario. "Slow" interrupt handlers run in complete thread contexts, called ithreads, and are, as such, able to acquire default mutexes and sleep in the scheduler. In FreeBSD 7.x, we have moved to a model in which device drivers can register both fast and threaded handlers, whereas in 6.x they had to pick one (and hence if they needed both, they had to pick the fast handler and use a task queue for threaded work). > I'm not very sure on this point, but is the above the reason why interrupt > service routines, also known as Fast ISRs (?), use mtx_lock_spin() mutexes? > They are supposed to be as fast as possible, and they don't context switch. > As well, isn't it basically agreed upon that Fast ISRs are really the only > place to use spin mutexes? Maybe I'm way off here but it sure would be nice > finally putting this one away. Spin locks are, FYI, slower than default mutexes. The reason is that they have to do more work: they not only perform an atomic operation/memory barrier to set the cross-CPU lock state, but they also have to disable interrupts to synchronize with fast interrupt handlers. In general, you are right: you should only use a spin mutex if you are running in a fast handler, or synchronizing with a fast handler. The one general exception is the scheduler itself, which must protect its data structures with spin locks in order to implement sleeping primitives. As such, the scheduler lock and various other low level locks (such as in turnstiles) are implemented with spin locks and not default mutexes. Since default mutexes spin adaptively, the reduced overhead of contention experienced with spin locks (i.e., no scheduler overhead for simple contention cases) is also experienced with default mutexes. > A somewhat newer (?) type of locking procedure is where a thread will spin > when trying to acquire a lock which is contested, for about the same amount > of time as it would take to do a context switch. If this time is roughly > (approached|exceeded)? then the thread sleeps. The reasoning is that in the > time it would take to do a context switch if the thread were to sleep, the > lock the thread is trying to acquire may become available. If we get lucky > and the lock becomes available while we are spinning then we have been more > efficient. I hope I am still on the right track here? This is essentially correct. This technique, called an "adaptive mutex" is used in Solaris and FreeBSD (and probably others). Right now, we use a simple strategy to decide whether to spin or not: we check to see if the thread holding the lock is currently running. If it's not, we assume it will be held for a long time and put the contending thread to sleep, falling back to historic sleep mutex behavior. There has been some investigating of more mature strategies; for example, Solaris uses a back-off scheme, I believe. > Another item in the documentation I had confused as being part of the above > issue(s) is that it is permissible for a thread to sleep while holding > certain types of locks and that for other types of locks a thread must not > sleep. Am I correct in my understanding now that a thread must not sleep > while holding a mutex because doing so could lead to a deadlock? There are really two notions of sleep: bounded, and unbounded. The difference is a bit sketchy if you try to nail it down too precisely, but intuitively (and in practice) it works quite well: - While holding a spin mutex or in a critical section, it is not permitted to perform any activity that might cause the current thread to sleep in any form. - While holding a default mutex or rwlock, it is not permitted to perform any activity that might cause the current thread to sleep in an unbounded way. I.e., you can hold one default mutex and sleep waiting for a second sleep mutex, since the "unbounded" property is considered to propagate back through callers. However, because default mutexes may be acquired in interrupt thread contexts, if a series of locks become dependent on one another due to multiple acquisitions, you could end up with nasty deadlocks not detectable by the lock order checker: an ithread could end up waiting, via mutexes, on a thread that is effectively waiting on the ithread. For example, a storage device driver ithread could be waiting on locks held by a thread sleeping in the file system code waiting on a block read, leading to deadlock. The restriction of not performing unbounded sleeps with a default mutex is conservative: after all, there are certainly mutexes that in principle could be safe to hold across an unbounded sleep as they are never acquired or depended on in an interrupt thread context. Solaris takes the approach of allowing this sort of sleep. One proposal has been to change our mutex definition so that mutexes can be declared as "top half", meaning that they are only ever acquired outside of ithread context, and an unbounded sleep might occur while the mutex is held. The lock order checker can then check that a mutex that is not "top half" is never acquired before a "top half" mutex, which could lead to a deadlock. The FreeBSD approach, however, has generally been to use different lock types for "sleepable" vs "non-sleepable" locks, which can make things a lot easier to inspect and verify. > Another scenario I have just learned is that a semaphore should not be > wrapped inside a mutex, for the same reason; a deadlock. I guess this is > just a specific case of not allowing the possibilty of a thread sleeping > while holding a mutex, which is what could happen if a thread is waiting on > any kind of condition variable? Waiting on a semaphore, a condition variable, or a tsleep/msleep counts as a potentially unbounded wait, and therefore is not allowed while holding a mutex or rwlock. It is allowed using an sx lock, which is "sleepable". Note, btw, that the kernel semaphore implementation (sema(9)) is not the same as the System V IPC sempahore implementation (semctl(2)) or the POSIX semaphore implementation (sem_init(3)). > If I am mostly correct (I hope), my enlightenment, if I have any came about > when I started working on the System V IPC code. When I started trying to > learn about semaphores I found out I needed to learn about a lot of other > stuff. And still do. Perhaps the most difficult thing is translating from > textbook type examples to real kernel code. Anyhow, I hope this message > wasn't too long or unbearable. Please send me any comments that you would > like to, on or off list. In general, we discourage the use of sema(9) synchronization in the kernel; it's in use for a few specific subsystems, but we would prefer that you use default mutexes, rwlocks, sx locks, and condition variables/msleep. These in-kernel facilities can be used to implement user-visible semaphores. Robert N M Watson Computer Laboratory University of Cambridge > > Thanks again! > > Duane Whitty > > P.S. > > I think I'm just about > ready to tackle fixing > sysv sems to wakeup > just the proper number > of processes, now that I > think I know what an > up'ed semaphore is, what > a semaphore set is for, how > semops work, and adjust on > exit values, and not least, > undos. My head hurts :-) > _______________________________________________ > 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 Wed Mar 28 07:58:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79CB516A46F for ; Wed, 28 Mar 2007 07:58:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1A48013C4EA for ; Wed, 28 Mar 2007 07:58:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54a5f07f.dip.t-dialin.net [84.165.240.127]) by redbull.bpaserver.net (Postfix) with ESMTP id 0AC982E22B; Wed, 28 Mar 2007 09:58:23 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 04D235B4817; Wed, 28 Mar 2007 09:58:19 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l2S7wJjh042270; Wed, 28 Mar 2007 09:58:19 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 28 Mar 2007 09:58:19 +0200 Message-ID: <20070328095819.8iute141cokkoo4k@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 28 Mar 2007 09:58:19 +0200 From: Alexander Leidinger To: ajay gopalakrishnan References: <200703271616.l2RGGRJG088685@fire.jhs.private> In-Reply-To: <200703271616.l2RGGRJG088685@fire.jhs.private> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 8, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Wed, 28 Mar 2007 11:31:23 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Have people started working on any Google Summer of code 2007project? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 07:58:34 -0000 Quoting Julian Stacey (from Tue, 27 Mar 2007 =20 18:16:27 +0200): > Reference: >> From:=09=09"ajay gopalakrishnan" > >> Is FreeBSD restricting non-students from not taking up any project that= is >> 'suitable for summer of code'? No. This markup was only done to allow students which want to =20 participate in the SoC to see which ideas are _not_ suitable as a SoC =20 project. When the rating of the submissions is done and projects are =20 taken by students, we will update the ideas page accordingly. >> For eg. >> I was planning to take up the 'super tunnel daemon' project some time bac= k. >> I had done some initial work but now i find that it has also been marked = as >> 'Suitable for summer of code'. I am no longer a student. I am working >> currently at a firm. So i dont think that i will be eligible for the summ= er >> of code. Can i still take up the project or am i forced to take up those >> that are not marked as 'suitable for summer of code'? >> Also, if someone has taken a summer of code project can no-one else take = it >> up as a normal project to contribute to FreeBSD ? As long as there's no interdependency created between you and the =20 student, I see no technical reason to not collaborate. I suggest to =20 talk with the technical contact of the project about it. FYI: There is at least one submission out of ~90 for the super tunnel =20 daemon. IIRC maybe 2. There's no decission made if this project will =20 be selected or not. I try to remember to attach a note to the =20 corresponding applications in the rating interface that you are =20 interested in this project and that a mentor should get in contact =20 with you in case it is selected for the SoC. Feel free to ask me about =20 it at the weekend to make sure I did not forget to add the note. > No can stop anyone working; Be a shame though if 2 people work & > one's effort was not used. I suppose as SoC deadline was yesterday > it'll take a while for google to publish their sponsoring list. It's the deadline for submissions from students. Now we (mentors) have =20 to rate the proposals. There may even be students which get selected =20 somewhere else in the SoC and prefer to work for another organisation =20 instead for us. So we don't know at this point which projects will be =20 taken by students. At =20 http://code.google.com/support/bin/answer.py?answer=3D60325&topic=3D10729 = =20 you can see the timeline. The official announcement of accepted =20 students (and the corresponding proposals) is scheduled for April 11. > If 2 people develope same thing: whose code will be commited will > I suppose be decided on which arrives first &/or seems best code, > hopefully independent of status of author eg student V. independent. I'm sure any judgment will be made based upon quality. Bye, Alexander. --=20 It is not good for a man to be without knowledge, and he who makes haste with his feet misses his way. =09=09-- Proverbs 19:2 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 15:18:33 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55E8D16A400 for ; Wed, 28 Mar 2007 15:18:33 +0000 (UTC) (envelope-from vcrobe@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 17D4013C4C1 for ; Wed, 28 Mar 2007 15:18:32 +0000 (UTC) (envelope-from vcrobe@gmail.com) Received: by py-out-1112.google.com with SMTP id f47so1292167pye for ; Wed, 28 Mar 2007 08:18:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:subject:mime-version:content-type; b=ON4JCKOGRRDwWefIlbCnIAiRyqFoxflESHH3mggDnJ4F+SAz7pTTOn/72PmDDYjgxKsI4GLj7LVUJu16gUvOHi60yKM0Hd+CTjSZK9K8khtiItUb4TE7rIRUmTG0M3JQ5aK9DxWJ3UU+WcKfY1sZu1Cm1XnWDmHdGDKN25MyfeQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:subject:mime-version:content-type; b=UnKfO3a36mk2gg1EvTUTlrqQzQ5+8Vti+LVKUlJK3u5FRE4suAe0ospWmZPvP4VOTRmTEr6UxWF/Oq0bEfzRXU1rDQR3n+TjziTaK9MdMHNNY2HXewVxckRcv5yMZM9lj7zNExWaBVkOGA2BBeriD2c0e7TjaKV8TMPfBhkCjCI= Received: by 10.35.103.1 with SMTP id f1mr16420188pym.1175093430283; Wed, 28 Mar 2007 07:50:30 -0700 (PDT) Received: by 10.35.125.13 with HTTP; Wed, 28 Mar 2007 07:50:30 -0700 (PDT) Message-ID: <221c791e0703280750u553d8e61te88c4b019dd76a08@mail.gmail.com> Date: Wed, 28 Mar 2007 09:50:30 -0500 From: Robe MIME-Version: 1.0 To: undisclosed-recipients:; X-Mailman-Approved-At: Wed, 28 Mar 2007 15:54:06 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help with ELF's ".symtab" section X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 15:18:33 -0000 Hi, Can anybody give me some reference about the ".symtab" section of the ELF file. I've read the "Tool interface standard specification 1.2" but there is very poor information about that section there. I'm doing a code generator and I need to know how exactly that section work= . Thanks, --=20 Robe. Prefiero morir ma=F1ana, que vivir cien a=F1os sin haberte conocido. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 18:41:57 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B11D116A400 for ; Wed, 28 Mar 2007 18:41:57 +0000 (UTC) (envelope-from peter_holmes2003@yahoo.com) Received: from web32901.mail.mud.yahoo.com (web32901.mail.mud.yahoo.com [209.191.69.78]) by mx1.freebsd.org (Postfix) with SMTP id 6265A13C4B7 for ; Wed, 28 Mar 2007 18:41:57 +0000 (UTC) (envelope-from peter_holmes2003@yahoo.com) Received: (qmail 94137 invoked by uid 60001); 28 Mar 2007 18:41:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=jxnLJDwAhiddSknCCAyvT1rFKTT996mTEsty/Suega3sFwepLi9Q+tC7+bBBNQwOpnW1HRnRU9ub7PDbGY73Iw8iFiwKcXgkuCb2F4eaiXjeF7KkpNvfk+311w03qPYe8l4PSU5zrh4Xie08qpwPadcTdFKoK7RCQbnxvmGyfuw=; X-YMail-OSG: aLhkjrMVM1nx0Mr01UiJpvbhx3a1L5qYdv2PUtqHz7hwC74StJZ_zRnE6ymG81A9sU8Bhdk_mQiDmqDb7bXm.nyQzqfKkCuZp3qQm.wfvGuufyXja64g.syZgpbvEg-- Received: from [66.129.224.36] by web32901.mail.mud.yahoo.com via HTTP; Wed, 28 Mar 2007 11:41:56 PDT Date: Wed, 28 Mar 2007 11:41:56 -0700 (PDT) From: Peter Holmes To: fbsd hackers MIME-Version: 1.0 Message-ID: <665184.92983.qm@web32901.mail.mud.yahoo.com> X-Mailman-Approved-At: Wed, 28 Mar 2007 20:12:02 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Pthreads signals X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 18:41:57 -0000 How do signals work with pthreads in FreeBSD. How are process signals delivered? - Peter --------------------------------- Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 28 20:18:40 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D737116A402 for ; Wed, 28 Mar 2007 20:18:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 847F413C44C for ; Wed, 28 Mar 2007 20:18:40 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l2SKIdMo013421; Wed, 28 Mar 2007 16:18:39 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Wed, 28 Mar 2007 16:18:39 -0400 (EDT) Date: Wed, 28 Mar 2007 16:18:39 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Holmes In-Reply-To: <665184.92983.qm@web32901.mail.mud.yahoo.com> Message-ID: References: <665184.92983.qm@web32901.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: fbsd hackers Subject: Re: Pthreads signals X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2007 20:18:40 -0000 On Wed, 28 Mar 2007, Peter Holmes wrote: > How do signals work with pthreads in FreeBSD. How are process signals > delivered? The best explanation of signals and threads in general is in the POSIX spec, or Butenhof's book. http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 06:33:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 630C916A404 for ; Thu, 29 Mar 2007 06:33:01 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id F27C913C465 for ; Thu, 29 Mar 2007 06:33:00 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au ([203.31.81.61]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id l2T6WuMu094115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2007 16:02:56 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Steve Watt Date: Thu, 29 Mar 2007 16:02:53 +0930 User-Agent: KMail/1.9.5 References: <200703280124.l2S1OFI5028861@wattres.watt.com> In-Reply-To: <200703280124.l2S1OFI5028861@wattres.watt.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6090580.xP8Uv5RAEz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703291602.54203.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.58 on 203.31.81.10 Cc: freebsd-hackers@freebsd.org Subject: Re: sendto() giving EPERM outside a jail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 06:33:01 -0000 --nextPart6090580.xP8Uv5RAEz Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 28 March 2007 10:54, Steve Watt wrote: > } I guess it would be nice if the man page(s) mentioned that a firewall > could } cause EPERM. I have seen it before with other apps but the sendto= () > confused } me. > > It's one of those unpleasant interactions between pluggable subsystems, > so it's a bit tough to document -- there are various different firewalls > available, after all. True, but it doesn't matter which firewall you're using, the result is the= =20 same :) > } It doesn't say anything about EPERM. > > If you're sending broadcast broadcast or multicast datagrams, you need > to set the SO_BROADCAST socket option, as well. Ahh, understood. Still, it seems to work without that - the sendto() call works fine now I h= ave=20 explicitly allowed multicast. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart6090580.xP8Uv5RAEz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBGC12W5ZPcIHs/zowRAtM4AJ9s4yo17PLj2zLM1ofKVZ51qvXRtACgqJww lFSyVQQgJSfpoPb8NRuaNM0= =fS8A -----END PGP SIGNATURE----- --nextPart6090580.xP8Uv5RAEz-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 08:59:34 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6492D16A405 for ; Thu, 29 Mar 2007 08:59:34 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-04.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id C1CCD13C469 for ; Thu, 29 Mar 2007 08:59:33 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id l2T8JwV0030644; Thu, 29 Mar 2007 11:19:58 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-04.forthnet.gr (8.13.7/8.13.7) with ESMTP id l2T8JwbA016288; Thu, 29 Mar 2007 11:19:58 +0300 Received: from [192.168.136.22] (ppp121-127.adsl.forthnet.gr [193.92.228.127]) by MX-IN-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l2T8Jueu025762; Thu, 29 Mar 2007 11:19:57 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <460B76A0.5030200@aueb.gr> Date: Thu, 29 Mar 2007 11:19:44 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Yar Tikhiy References: <20070326135106.GG60831@comp.chem.msu.su> In-Reply-To: <20070326135106.GG60831@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 08:59:34 -0000 Yar Tikhiy wrote: > Hi, > > Recently noticed that our sed(1) differs from its GNU analog in > that in -i mode it considers all files as a single sequence of lines > while the latter treats each file independently. The in-line mode > isn't in POSIX, so it isn't really clear which way is correct. > > Here is a couple of practical consequences: > > - our sed won't act on a numeric range of lines in each file, > as in: sed -i '' 2,5d *, which may be counter-intuitive. > - our sed's line ranges can span file boundaries in -i mode. > > If the second feature isn't important, I think we should use > a separate line space for each file edited in-line, which is > usually desired. > > Comments? > > P.S. Attached are a test script and outputs from it for our > sed and GNU sed as found in a Linux I have access to. > I believe the GNU interpretation of lines in -i makes sense. Diomidis - dds@ From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 10:06:48 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4143016A403 for ; Thu, 29 Mar 2007 10:06:48 +0000 (UTC) (envelope-from jmouille.ext@orange-ftgroup.com) Received: from relais-inet.francetelecom.com (relais-inet.francetelecom.com [212.234.67.6]) by mx1.freebsd.org (Postfix) with ESMTP id 9488013C4E8 for ; Thu, 29 Mar 2007 10:06:47 +0000 (UTC) (envelope-from jmouille.ext@orange-ftgroup.com) Received: from prive-Rline3.com ([192.168.1.32] [192.168.1.32]) by Rline3.francetelecom.com with ESMTP for freebsd-hackers@freebsd.org; Thu, 29 Mar 2007 11:55:24 +0200 Received: from PMEXCC41.intranet-paris.francetelecom.fr ([10.196.130.30] [10.196.130.30]) by Rline3.francetelecom.com with ESMTP for freebsd-hackers@freebsd.org; Thu, 29 Mar 2007 11:55:24 +0200 Received: from PMEXCB50.intranet-paris.francetelecom.fr ([10.196.130.29]) by PMEXCC41.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Thu, 29 Mar 2007 11:55:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Mar 2007 11:55:23 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NVIDIA FreeBSD kernel feature requests Thread-Index: Acdx6F6I4yqVT6rvThGEF+p/0PJMig== From: "MOUILLE Jean Pierre Ext OF/DT" To: X-OriginalArrivalTime: 29 Mar 2007 09:55:24.0343 (UTC) FILETIME=[5EFE6470:01C771E8] X-Mailman-Approved-At: Thu, 29 Mar 2007 11:24:27 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 10:06:48 -0000 Hello, =0D Do you plan for a driver for nForce 590sli RAID controller on FreeBSD ? The= disks are recognized but not the RAID arrays.=0D On Motherboard ECS KN3-SLI2, JMicron JMB363 driver is already included in= FreeBSD 6.2 (ar0) but in kernel, it goes up to nForce 4. Perhaps have you got later information ? =0D =0D Jean-Pierre Mouill=E9 ORANGE-FRANCE/DT/DPP/SC 01.55.22.27.57 jmouille.ext@orange-ftgroup.com P please consider the environment - do you really need to print this email?= =0D =0D ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be= liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it= immediately and inform the sender. ******************************** From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 11:54:37 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44AE616A404; Thu, 29 Mar 2007 11:54:37 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 38EA213C468; Thu, 29 Mar 2007 11:54:33 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2TBQCgb077214; Thu, 29 Mar 2007 15:26:12 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2TBQ7W7077210; Thu, 29 Mar 2007 15:26:07 +0400 (MSD) (envelope-from yar) Date: Thu, 29 Mar 2007 15:26:07 +0400 From: Yar Tikhiy To: Robert Watson Message-ID: <20070329112606.GA72497@comp.chem.msu.su> References: <20070328082620.GA1052@dwpc.dwlabs.ca> <20070328102027.T1185@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070328102027.T1185@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: freebsd-hackers@freebsd.org, Duane Whitty Subject: Re: Locking etc. (Long, boring, redundant, newbie questions) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 11:54:37 -0000 On Wed, Mar 28, 2007 at 10:40:58AM +0100, Robert Watson wrote: > > Spin locks are, FYI, slower than default mutexes. The reason is that they > have to do more work: they not only perform an atomic operation/memory > barrier to set the cross-CPU lock state, but they also have to disable > interrupts to synchronize with fast interrupt handlers. In general, you > are right: you should only use a spin mutex if you are running in a fast > handler, or synchronizing with a fast handler. The one general exception > is the scheduler itself, which must protect its data structures with spin > locks in order to implement sleeping primitives. As such, the scheduler > lock and various other low level locks (such as in turnstiles) are > implemented with spin locks and not default mutexes. Since default mutexes > spin adaptively, the reduced overhead of contention experienced with spin > locks (i.e., no scheduler overhead for simple contention cases) is also > experienced with default mutexes. By the way, could the following observation of mine be related to the high cost of spin mutexes? While doing some measurements of the performance of our vlan driver in a router, I found that with RELENG_6 the pps rate through the router degraded considerably (by ~100Kpps) if its physical interfaces used hardware vlan tagging. I attributed that to the overhead of allocating and freeing a mbuf tag for each packet as it entered and then left the router. I used hwpmc and pmcstat to see which kernel functions took most time and found that critical_exit() made top 5 in the list of CPU time eaters if the network interfaces were using hardware vlan tagging. The machine was an UP amd64, but it ran FreeBSD/i386, with an UP kernel. As I can see from the code, critical_exit() may grab and later release a spin mutex. I've got a hazy recollection that our kernel memory allocator uses critical sections to protect its per-CPU structures. That's why I suspect that the effect I observed may have its roots in the behaviour of spin mutexes. Could it be so? Thanks! -- Yar From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 13:13:01 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D35216A401 for ; Thu, 29 Mar 2007 13:13:01 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1EC1013C45D for ; Thu, 29 Mar 2007 13:13:01 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id E93592085; Thu, 29 Mar 2007 15:12:52 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id D3E6A2084; Thu, 29 Mar 2007 15:12:52 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id E2657A1073; Thu, 29 Mar 2007 15:12:52 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: "MOUILLE Jean Pierre Ext OF/DT" References: Date: Thu, 29 Mar 2007 15:12:52 +0200 In-Reply-To: (MOUILLE Jean Pierre Ext's message of "Thu, 29 Mar 2007 11:55:23 +0200") Message-ID: <86k5x042i3.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 13:13:01 -0000 "MOUILLE Jean Pierre Ext OF/DT" writes: > Do you plan for a driver for nForce 590sli RAID controller on > FreeBSD ? The disks are recognized but not the RAID arrays. It's not so much a matter of writing a driver as one of teaching the existing driver (ataraid) to recognize the on-disk configuration data. This is *not* a RAID controller, BTW, merely a SATA controller with a RAID-capable BIOS. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 17:34:31 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D958816A400 for ; Thu, 29 Mar 2007 17:34:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3C713C465 for ; Thu, 29 Mar 2007 17:34:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so236651ana for ; Thu, 29 Mar 2007 10:34:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PMgFDHNnSeGw7az2PY3oFAS6yNQiwzISAsPB4WyocZEUR7CR4TP/KUyBFak84gs+EmYmnw/yRR7oMgqXyYnTCojOgS7RrbQopeMA3zpPLIuerql+pmfYr++RIyViwP5ZJOgKaVHRQucLEalolWXCb39V0qi1cYyUnR7SUT3XgWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dUdu2ALW28s47ClTxdTBqv+ZKq34BCCB0ZmMrSuaY7xPT55/8D5OwLRYD1Xtq3J7AGQEb64uuGMQdOTV6KXua70t5M+g53CrVa/w8ssGkc/fbcgfk4vvFd1J8RSV2pYsP2B3H2U4UiurBqg1QlOkhNlaqwpwKC+k0kD14WJ3ZNY= Received: by 10.100.128.8 with SMTP id a8mr607843and.1175188134849; Thu, 29 Mar 2007 10:08:54 -0700 (PDT) Received: by 10.100.177.10 with HTTP; Thu, 29 Mar 2007 10:08:54 -0700 (PDT) Message-ID: Date: Thu, 29 Mar 2007 09:08:54 -0800 From: "Maksim Yevmenkin" To: "Timothy Bourke" , hackers@freebsd.org In-Reply-To: <20070325015717.GA797@triptrop> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070325015717.GA797@triptrop> Cc: Subject: Re: enable/disable in kbd drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:34:31 -0000 On 3/24/07, Timothy Bourke wrote: > I have almost finished a ppbus-based driver for Super Nintendo > controllers. It presents itself as a keyboard to the operating system. I > wanted to start and stop the polling thread via, respectively, the > kbd_enable_t and kbd_disable_t hooks, but these do not seem to be called > properly. Hence this post. > > The enable and disable functions are identical across the keyboard > drivers (atkbd, ukbd, vkbd, kbdmux). Enable calls the KBD_ACTIVATE macro > which increments the kb_active count. Disable calls the KBD_DEACTIVATE > macro which decrements the kb_active count. It seems reasonable to > assume that the two functions should be called in pairs. > > However, enable is called too many times and disable is never called. > > In the kbdmux_ioctl routine: > KBADDKBD: enable is called via the KBDMUX_ENABLE macro. > KBRELKBD: does NOT call disable > > Taking dev/usb/ukbd.c as an example, the effect can be seen by adding > this line to the ukbd_enable function (after the call to KBD_ACTIVATE): > printf("ukbd_enable: %d\n", KBD_IS_ACTIVE(kbd)); > And similarly for ukbd_disable and then running dmesg or kbdcontrol. > > Additionally, each kbd driver calls its own enable function when > attached. For example, in USB_ATTACH(ukbd): > (*sw->enable)(kbd); > This would appear to be unnecessary for keyboards connected via kbdmux. > I am less certain about those connected directly, but the syscons > sccngetch routine does seems to call enable and disable. Perhaps it > should also call enable when it first starts? > > Does the attached patch seem reasonable? It would fix my immediate > problem. sorry for the delay. i'm not sure about this patch. basically, i do not think that keyboard should be disabled if it is released from kbdmux. it is perfectly fine, imo, to have two (or more) active keyboards attached to the system as long as only one of them is primary. it is possible to use /dev/kbdX interface to talk to non-primary keyboard(s) directly. thanks, max > I could write a patch to remove the calls to enable in the driver init > routines but tI don't really understand how syscons works. > > Tim. > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 29 22:10:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6745916A400 for ; Thu, 29 Mar 2007 22:10:34 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp801.mail.ird.yahoo.com (smtp801.mail.ird.yahoo.com [217.146.188.61]) by mx1.freebsd.org (Postfix) with SMTP id CED6213C4B9 for ; Thu, 29 Mar 2007 22:10:33 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 94738 invoked from network); 29 Mar 2007 21:43:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=vh8EC4FYRDf/vEK9gIg9G2dcZ7SCQGaDmpXO1gjgJIKFN/rpAyO6c8yHrRhdFe7l6U9q9n6u0kOe4QOnW5DQr8Sts4KXw0ryCd/n+PCiWmMuPPGEtg35MPOc7R5kUxgl37IdjktXV59gRKXwoZJ40OKP3WRktQ160hEgbMS/Y8A= ; Received: from unknown (HELO w2fzz0vc03) (thomas.sparrevohn@btinternet.com@81.156.126.54 with login) by smtp801.mail.ird.yahoo.com with SMTP; 29 Mar 2007 21:43:52 -0000 X-YMail-OSG: vBEGBF0VM1noOQ0Xfxf6V4kHTv3s8WLKuHOW39alqdj_.i2SA9PWO8kNFzkEy54gLN8dHz5H39iW9H86sL1byVOYQg8VktMt4T0PSZ5Q7Z1TMG4wh7mCMo22hGU- From: "Thomas Sparrevohn" To: "'MOUILLE Jean Pierre Ext OF/DT'" , References: In-Reply-To: Date: Thu, 29 Mar 2007 22:43:50 +0100 Message-ID: <001b01c7724b$5704e240$050ea6c0$@Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acdx6F6I4yqVT6rvThGEF+p/0PJMigAYmktg Content-Language: en-gb Cc: Subject: RE: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas.Sparrevohn@btinternet.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 22:10:34 -0000 That is puzzling - I running using on a Nvidia Nforce 590 SLI based machine with no problems using Raid - Mind you this Dell implementation uses only Raid0 - What release are you running? - I have had success With both 6.2, 7.0-Current and AMD-6.2 and AMD-7.0 - On the 64bit there was issues with the USB -=20 which has been and there was some issues with SATA CD drives all of which i= s fixed > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of MOUILLE Jean Pierre Ext OF/DT > Sent: 29 March 2007 10:55 > To: freebsd-hackers@freebsd.org > Subject: NVIDIA FreeBSD kernel feature requests >=20 >=20 > Hello, >=20 >=20 > Do you plan for a driver for nForce 590sli RAID controller on FreeBSD ? > The disks are recognized but not the RAID arrays. >=20 > On Motherboard ECS KN3-SLI2, JMicron JMB363 driver is already included > in FreeBSD 6.2 (ar0) but in kernel, it goes up to nForce 4. > Perhaps have you got later information ? >=20 >=20 >=20 >=20 > Jean-Pierre Mouill=E9 > ORANGE-FRANCE/DT/DPP/SC > 01.55.22.27.57 > jmouille.ext@orange-ftgroup.com > P please consider the environment - do you really need to print this > email? >=20 >=20 >=20 >=20 >=20 > ********************************* > This message and any attachments (the "message") are confidential and > intended solely for the addressees. Any unauthorised > use or dissemination is prohibited. > Messages are susceptible to alteration. France Telecom Group shall not > be liable for the message if altered, changed or > falsified. > If you are not the intended addressee of this message, please cancel it > immediately and inform the sender. > ******************************** > _______________________________________________ > 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 Thu Mar 29 22:59:01 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1984616A404 for ; Thu, 29 Mar 2007 22:59:01 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by mx1.freebsd.org (Postfix) with ESMTP id 80D3313C45B for ; Thu, 29 Mar 2007 22:59:00 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: From triptrop.cse.unsw.edu.au ([129.94.175.153]) (for ) By note With Smtp ; Fri, 30 Mar 2007 08:43:45 +1000 Received: from triptrop.cse.unsw.edu.au (localhost [127.0.0.1]) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6) with ESMTP id l2TMg7wj003346 for ; Fri, 30 Mar 2007 08:42:07 +1000 (EST) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: (from tbourke@localhost) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6/Submit) id l2TMg60A003345 for hackers@freebsd.org; Fri, 30 Mar 2007 08:42:06 +1000 (EST) (envelope-from tbourke) From: Timothy Bourke To: hackers@freebsd.org Date: Fri, 30 Mar 2007 08:42:06 +1000 Message-ID: <20070329224205.GA819@triptrop.cse.unsw.EDU.AU> Mail-Followup-To: hackers@freebsd.org References: <20070325015717.GA797@triptrop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.cse.unsw.edu.au/~tbourke/pubkey.txt Cc: Subject: Re: enable/disable in kbd drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 22:59:01 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for responding, Max. On Mar 29 at 09:08 -0800, Maksim Yevmenkin wrote: > On 3/24/07, Timothy Bourke wrote in part: > >However, enable is called too many times and disable is never called. > > > >In the kbdmux_ioctl routine: > > KBADDKBD: enable is called via the KBDMUX_ENABLE macro. > > KBRELKBD: does NOT call disable > > > >Taking dev/usb/ukbd.c as an example, the effect can be seen by adding > >this line to the ukbd_enable function (after the call to KBD_ACTIVATE): > > printf("ukbd_enable: %d\n", KBD_IS_ACTIVE(kbd)); > >And similarly for ukbd_disable and then running dmesg or kbdcontrol. > > > >Additionally, each kbd driver calls its own enable function when > >attached. For example, in USB_ATTACH(ukbd): > > (*sw->enable)(kbd); > >This would appear to be unnecessary for keyboards connected via kbdmux. > >I am less certain about those connected directly, but the syscons > >sccngetch routine does seems to call enable and disable. Perhaps it > >should also call enable when it first starts? > > > >Does the attached patch seem reasonable? It would fix my immediate > >problem. >=20 > sorry for the delay. i'm not sure about this patch. basically, i do > not think that keyboard should be disabled if it is released from > kbdmux. it is perfectly fine, imo, to have two (or more) active > keyboards attached to the system as long as only one of them is > primary. it is possible to use /dev/kbdX interface to talk to > non-primary keyboard(s) directly. It seems that, for the extant drivers: * enable only increments kb_active,=20 * disable only decrements kb_active. With the printf suggested above, one can see that repeating the commands: kbdcontrol -A usb0 < /dev/console kbdcontrol -a usb0 < /dev/console continually increases kb_active. Even with the patch, detaching any of the current kbd drivers will not deactivate them (reduce kb_active to zero) because they all call enable (increment kb_active) when initialized. Which answers one of the other questions. Alternative (not serious) suggestion: since the disable hook seems never to be called, it might as well be removed from the keyboard_switch... Tim. --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFGDEC9tKVK1sFb0ecRAk6HAJ9NvvzHrBRVJNx3Lqo8nSUd6PmyzACfTC4p nB6QMxJ8C0UKcBwbwFSQlU4= =Haie -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 00:20:06 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CA4716A40B for ; Fri, 30 Mar 2007 00:20:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id AA8B313C4B8 for ; Fri, 30 Mar 2007 00:20:05 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so331911ana for ; Thu, 29 Mar 2007 17:20:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kUOIsiEqN+n/DD0841WXspZscMGkcrcUeHBP5WZGFSZEvQDtcK+S/mDAi+cxW5DP/rJvSdIJDCjXGIPKSH2+85lhPScz8d40DrCHn6i9ypTIWnZzO/m9E51tJ9ggma4oFnd/39wnUmyyXrynUYnDfpB5to13t2n65Bgd49W4a08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OKnx9WwW/DIuIustsZKqKH9DSO2gwVntKgWpfvI89bCf7PTVuW5UA2MHo1EfWOONHBOnTVrOUyNFZyyJC2liHBqTULiuh8BA4TezyfLXEkrf4Cc8S5MRkExnEm7NX+VfJawi9tRkFqv4VNFWHmvAgGBQCD6x5Yemf2eF2Z7DJos= Received: by 10.100.109.13 with SMTP id h13mr937595anc.1175214005167; Thu, 29 Mar 2007 17:20:05 -0700 (PDT) Received: by 10.100.191.1 with HTTP; Thu, 29 Mar 2007 17:20:05 -0700 (PDT) Message-ID: <3bbf2fe10703291720yd82045ei66ead6e4f251a20@mail.gmail.com> Date: Fri, 30 Mar 2007 02:20:05 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Yar Tikhiy" In-Reply-To: <20070329112606.GA72497@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070328082620.GA1052@dwpc.dwlabs.ca> <20070328102027.T1185@fledge.watson.org> <20070329112606.GA72497@comp.chem.msu.su> X-Google-Sender-Auth: 0b13788422fe330e Cc: freebsd-hackers@freebsd.org, Robert Watson , Duane Whitty Subject: Re: Locking etc. (Long, boring, redundant, newbie questions) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 00:20:06 -0000 2007/3/29, Yar Tikhiy : > On Wed, Mar 28, 2007 at 10:40:58AM +0100, Robert Watson wrote: > > > > Spin locks are, FYI, slower than default mutexes. The reason is that they > > have to do more work: they not only perform an atomic operation/memory > > barrier to set the cross-CPU lock state, but they also have to disable > > interrupts to synchronize with fast interrupt handlers. In general, you > > are right: you should only use a spin mutex if you are running in a fast > > handler, or synchronizing with a fast handler. The one general exception > > is the scheduler itself, which must protect its data structures with spin > > locks in order to implement sleeping primitives. As such, the scheduler > > lock and various other low level locks (such as in turnstiles) are > > implemented with spin locks and not default mutexes. Since default mutexes > > spin adaptively, the reduced overhead of contention experienced with spin > > locks (i.e., no scheduler overhead for simple contention cases) is also > > experienced with default mutexes. > > By the way, could the following observation of mine be related to > the high cost of spin mutexes? > > While doing some measurements of the performance of our vlan driver > in a router, I found that with RELENG_6 the pps rate through the > router degraded considerably (by ~100Kpps) if its physical interfaces > used hardware vlan tagging. I attributed that to the overhead of > allocating and freeing a mbuf tag for each packet as it entered and > then left the router. I used hwpmc and pmcstat to see which kernel > functions took most time and found that critical_exit() made top 5 > in the list of CPU time eaters if the network interfaces were using > hardware vlan tagging. > > The machine was an UP amd64, but it ran FreeBSD/i386, with an UP > kernel. > > As I can see from the code, critical_exit() may grab and later > release a spin mutex. I've got a hazy recollection that our kernel > memory allocator uses critical sections to protect its per-CPU > structures. That's why I suspect that the effect I observed may > have its roots in the behaviour of spin mutexes. Could it be so? This is not entirely true. What happens is that if you enable preemption in your kernel, critical_exit() holds sched_lock just beacause it needs to perform a mi_switch(), so just another thread will be scheduled to run currently (and, please, note that sched_lock will be dropped by internal functions when context switch will be completed). Otherwise you don't pay the penalty of the sched_lock acquisition. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 00:36:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE26B16A401 for ; Fri, 30 Mar 2007 00:36:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8C66C13C44B for ; Fri, 30 Mar 2007 00:36:14 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so334762ana for ; Thu, 29 Mar 2007 17:36:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Dazh06cIGZdqD1upj50ow7bK8dSKQRENb+goVPzONAsLgeZWzoulFCE30pIo+dFvrvvFM+ChruiqqSNnoLHYKn2LoC4/U5CJLQUFB75/M04IWfEBLgOWVyA5a2sBTQYRh5O7SmhqPexTw+T1mFC2rNxY+J7Dh+woADSgT0eeXSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ergEfu5KwtrjD15ntqB8lcpRwih//GU9EOSsnwZkKIuatu8N+STdCbW51IDyM3h/CySbdln9eP1aecgvEBSoKstiJyhaAxW+3EFptl9UF0pGCcD0epMWyemTiDjiGjMwX8U+UZXoGgGz5Zj6ebXUfKk0xnA5mXz1kgq5J46GTTU= Received: by 10.100.44.13 with SMTP id r13mr926412anr.1175213233253; Thu, 29 Mar 2007 17:07:13 -0700 (PDT) Received: by 10.100.191.1 with HTTP; Thu, 29 Mar 2007 17:07:13 -0700 (PDT) Message-ID: <3bbf2fe10703291707j48c5b9cmdf9b08c8c60dd0ef@mail.gmail.com> Date: Fri, 30 Mar 2007 02:07:13 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Robert Watson" In-Reply-To: <20070328102027.T1185@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070328082620.GA1052@dwpc.dwlabs.ca> <20070328102027.T1185@fledge.watson.org> X-Google-Sender-Auth: 90d9c262ceb6c308 Cc: freebsd-hackers@freebsd.org, Duane Whitty Subject: Re: Locking etc. (Long, boring, redundant, newbie questions) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 00:36:14 -0000 2007/3/28, Robert Watson : > Pretty much. We disable interrupts for the following reason: as spin mutexes > may be acquired in fast interrupt handlers, they may be running on the stack > of an existing thread, which may also hold locks. As such, we can't allow the > fast handler to acquire any locks that are either already held by the thread, > or that might violate the lock order. By restricting fast interrupt handlers > to holding only spin locks, and by making spin locks disable interrupts, we > prevent that deadlock scenario. Really, avoid lock ordering violation is one of the motivations that don't allow usage of sleepable locks in fast handlers. We disable interrupts for spin-locks mainly in order to avoid to be preempted by an interrupt thread (or, however, an higher priority thread) that can contest on the spin-lock we are holding and so can cause a deadlock since we will never have a chance to be executed again (there will always be an attempt to execute first the higher priority thread that cannot start again). You can make this concept more general if you mind what you first stated -- that spinning should not be longer than rr time quantum. If you get preempted by another thread this won't certainly happen however. For this reason, you are not allowed to perform any sort of sleeping (as bounded or unbounded) while holding a spin-lock. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 09:39:22 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7D2316A400 for ; Fri, 30 Mar 2007 09:39:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6507013C468 for ; Fri, 30 Mar 2007 09:39:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1HXDZp-0006yP-22 for freebsd-hackers@freebsd.org; Fri, 30 Mar 2007 12:39:21 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Mar 2007 12:39:20 +0300 From: Danny Braniss Message-ID: Subject: fujitsu/siemens bge/irq256? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 09:39:22 -0000 hi, I'm evaluating a fukitsu/siemens intel box, and it does boot and run freebsd-7.0, but 6.2 gets stuck on boot. somethings are 'wierd': 1- with 7.0, if I enable serial console (boot_multicons="-D"), the boot process will get stuck, but hitting any character on the serial console will unstuck it. ... da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 69618MB (142577664 512 byte sectors: 255H 63S/T 8875C) GEOM_LABEL: Label for provider da0s6 is ext2fs//mopi. Trying to mount root from nfs: bNgFeS0 :R OlOiTn:k 1s3t2a.t6e5 .c1h6a.n1g1e2d: /tdo/ aDOWN bge0: link state changed to UP at this point it's stuck, pinging this host nothing/nada if i now hit any key in the serial console, it will unstuck, bsd> ping fujitsu PING fujitsu.cs.huji.ac.il (132.65.80.2): 56 data bytes --------- stuck, but as soon as I hit any-key: 64 bytes from 132.65.80.2: icmp_seq=0 ttl=63 time=9377.005 ms 64 bytes from 132.65.80.2: icmp_seq=1 ttl=63 time=8360.420 ms --------- probably indicating that the receiver is ok. ... 64 bytes from 132.65.80.2: icmp_seq=23 ttl=63 time=0.291 ms 64 bytes from 132.65.80.2: icmp_seq=24 ttl=63 time=0.283 ms 64 bytes from 132.65.80.2: icmp_seq=25 ttl=63 time=0.158 ms 64 bytes from 132.65.80.2: icmp_seq=26 ttl=63 time=0.160 ms and the boot is now complete. 2- notice irq for bge fujitsu> vmstat -i interrupt total rate irq1: atkbd0 6 0 irq4: sio0 5 0 irq24: mpt0 146 0 cpu0: timer 327600 1997 irq256: bge0 16148 98 cpu1: timer 319629 1948 cpu3: timer 319629 1948 cpu2: timer 319628 1948 Total 1302791 7943 but: fujitsu> dmesg | grep bge bge0: \ mem 0xfc810000-0xfc81ffff,0xfc800000-0xfc80ffff irq 16 at device 4.0 on pci now, if I boot 6.2-stable, no amount of magic will budge it, it's stuck: ... ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 6 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 12 to local APIC 6 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 6 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 6 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 6 ioapic0: Assigning PCI IRQ 22 to local APIC 0 ioapic0: Assigning PCI IRQ 23 to local APIC 6 ioapic1: Assigning PCI IRQ 24 to local APIC 0 Trying to mount root from nfs: DbFgSe 0R:O OlTi:n k1 3s2t.a6t5e. 1c6h.a1n1g2e:d/ dt/o7 OWN tgbeg0e:0 :l ilnikn kU Ps ate changed to UP which translated means: ... bge0: state changed to UP but all is quiet. need some help here. danny From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 08:16:41 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC32F16A401 for ; Fri, 30 Mar 2007 08:16:41 +0000 (UTC) (envelope-from jmouille.ext@orange-ftgroup.com) Received: from relais-inet.francetelecom.com (relais-inet.francetelecom.com [212.234.67.6]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6C413C4B9 for ; Fri, 30 Mar 2007 08:16:41 +0000 (UTC) (envelope-from jmouille.ext@orange-ftgroup.com) Received: from prive-Rline2.com ([192.168.1.22] [192.168.1.22]) by Rline2.francetelecom.com with ESMTP; Fri, 30 Mar 2007 10:16:39 +0200 Received: from PMEXCC11.intranet-paris.francetelecom.fr ([10.196.130.4] [10.196.130.4]) by Rline2.francetelecom.com with ESMTP; Fri, 30 Mar 2007 10:16:39 +0200 Received: from PMEXCB50.intranet-paris.francetelecom.fr ([10.196.130.29]) by PMEXCC11.intranet-paris.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.2499); Fri, 30 Mar 2007 10:16:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2007 10:16:37 +0200 Message-Id: In-Reply-To: <001b01c7724b$5704e240$050ea6c0$@Sparrevohn@btinternet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NVIDIA FreeBSD kernel feature requests Thread-Index: Acdx6F6I4yqVT6rvThGEF+p/0PJMigAYmktgABUh/XA= From: "MOUILLE Jean Pierre Ext OF/DT" To: , X-OriginalArrivalTime: 30 Mar 2007 08:16:38.0939 (UTC) FILETIME=[BD973EB0:01C772A3] X-Mailman-Approved-At: Fri, 30 Mar 2007 11:43:39 +0000 Cc: Subject: RE: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 08:16:42 -0000 Hello, Thank you for your answer. I use a ECS KN3-SLI2 motherboard with AMD 64-X2 4200 Jmicron JMB363 and AMD= nForce 590sli fakeraid controllers. I've build 2 RAID arrays : . 1 RAID 1 for system on Jmicron chip, with 2 maxtor/seagate 80 GB disks=0D . 1 RAID 5 for data on nForce chip, with 3 maxtor/seagate 250 GB disks= (~450 GB data) I tried Vista before, just to see compatibility, all was OK. I installed linux debian etch ok, but impossible to install a boot loader. I installed FreeeBSD 6.2-RELEASE : The install process detects all disks even nForce's ones, but it detects= only Jmicron RAID array as 'ar0'. I suppose that nForce's one would take= the device 'ar1'. (That makes me think that perhaps kernel does recognize only one array at a= time, but I cannot believe that, it's of no sense). I installed FreeBSD on RAID 1 array, it worked perfectly. So I thought I= could compile the kernel to take account of RAID 5 array (the same process= for installing linux), but I didn't see in kernel config a driver for= nForce 590sli and I saw in a faq (perhaps obsolet) that only up to nForce= 4 is supported. I'm a bit out of new solutions. If you have any idea ... =0D Jean-Pierre Mouill=E9 DT/DPP/SC 01.55.22.27.57 jmouille.ext@orange-ftgroup.com P please consider the environment - do you really need to print this email?= =0D -----Message d'origine----- De : Thomas Sparrevohn [mailto:Thomas.Sparrevohn@btinternet.com]=0D Envoy=E9 : jeudi 29 mars 2007 23:44 =C0 : MOUILLE Jean Pierre Ext OF/DT; freebsd-hackers@freebsd.org Objet : RE: NVIDIA FreeBSD kernel feature requests That is puzzling - I running using on a Nvidia Nforce 590 SLI based machine= with no problems using Raid - Mind you this Dell implementation uses only= Raid0 - What release are you running? - I have had success With both 6.2,= 7.0-Current and AMD-6.2 and AMD-7.0 - On the 64bit there was issues with= the USB - which has been and there was some issues with SATA CD drives all= of which is fixed > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-=0D > hackers@freebsd.org] On Behalf Of MOUILLE Jean Pierre Ext OF/DT > Sent: 29 March 2007 10:55 > To: freebsd-hackers@freebsd.org > Subject: NVIDIA FreeBSD kernel feature requests >=0D >=0D > Hello, >=0D >=0D > Do you plan for a driver for nForce 590sli RAID controller on FreeBSD ? > The disks are recognized but not the RAID arrays. >=0D > On Motherboard ECS KN3-SLI2, JMicron JMB363 driver is already included=0D > in FreeBSD 6.2 (ar0) but in kernel, it goes up to nForce 4. > Perhaps have you got later information ? >=0D >=0D >=0D >=0D > Jean-Pierre Mouill=E9 > ORANGE-FRANCE/DT/DPP/SC > 01.55.22.27.57 > jmouille.ext@orange-ftgroup.com > P please consider the environment - do you really need to print this=0D > email? >=0D >=0D >=0D >=0D >=0D > ********************************* > This message and any attachments (the "message") are confidential and=0D > intended solely for the addressees. Any unauthorised use or=0D > dissemination is prohibited. > Messages are susceptible to alteration. France Telecom Group shall not=0D > be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel=0D > it immediately and inform the sender. > ******************************** > _______________________________________________ > freebsd-hackers@freebsd.org mailing list=0D > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-=0D > unsubscribe@freebsd.org" ********************************* This message and any attachments (the "message") are confidential and= intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be= liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it= immediately and inform the sender. ******************************** From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 12:57:31 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B026C16A5FE for ; Fri, 30 Mar 2007 12:57:31 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from optimus.centralmiss.com (ns.centralmiss.com [206.156.254.79]) by mx1.freebsd.org (Postfix) with ESMTP id 8660413C4C4 for ; Fri, 30 Mar 2007 12:57:31 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-072-148-013-213.sip.jan.bellsouth.net [72.148.13.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by optimus.centralmiss.com (Postfix) with ESMTP id 8508A288F8; Fri, 30 Mar 2007 07:57:30 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 16E9F61C41; Fri, 30 Mar 2007 07:57:30 -0500 (CDT) Date: Fri, 30 Mar 2007 07:57:30 -0500 From: "Matthew D. Fuller" To: MOUILLE Jean Pierre Ext OF/DT Message-ID: <20070330125729.GI96961@over-yonder.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.14-fullermd.3 (2007-02-12) Cc: freebsd-hackers@freebsd.org, Thomas.Sparrevohn@btinternet.com Subject: Re: NVIDIA FreeBSD kernel feature requests X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 12:57:31 -0000 On Fri, Mar 30, 2007 at 10:16:37AM +0200 I heard the voice of MOUILLE Jean Pierre Ext OF/DT, and lo! it spake thus: > > . 1 RAID 5 for data on nForce chip, with 3 maxtor/seagate 250 GB > disks (~450 GB data) ataraid(4): CAVEATS RAID5 is not supported at this time. Code exists, but it neither uses nor maintains parity information. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 14:03:29 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2C2E16A402 for ; Fri, 30 Mar 2007 14:03:29 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (wooster.rojer.pp.ru [80.68.246.188]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0AF13C480 for ; Fri, 30 Mar 2007 14:03:29 +0000 (UTC) (envelope-from myself@rojer.pp.ru) Received: from wooster.rojer.pp.ru (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP id 3A916114FD for ; Fri, 30 Mar 2007 17:42:36 +0400 (MSD) X-Spam-Checker-Version: SpamAssassin 3.1.7-rojer (2006-10-05) on wooster.rojer.pp.ru X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7-rojer Received: from [IPv6:::1] (localhost [127.0.0.1]) by wooster.rojer.pp.ru (Postfix) with ESMTP for ; Fri, 30 Mar 2007 17:42:30 +0400 (MSD) Message-ID: <460D13B0.5070500@rojer.pp.ru> Date: Fri, 30 Mar 2007 14:42:08 +0100 From: Deomid Ryabkov User-Agent: Thunderbird 1.5.0.10 (X11/20070313) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: 6.2: reproducible hang on amd64, traced to 24h of commits X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 14:03:29 -0000 ok, now that the machine has been up for 10 days, i am reasonably sure i've close enough to this one. back in january i cvsupped to -STABLE and the box (dual head opteron box) started hanging. and i mean it dies completely. i have all debug options and a working serial console, but still it just dies and both serial and system console are unresponsive. no panic message on either, nothing. pretty sad. the kernel config is vanilla SMP GENERIC, with all debug options i could think of enabled (after it started hanging). so the first thing i did after rebooting the box a couple of times is fall back to kernel.old (6.1-STABLE circa august '06). no hangs. i then started incrementally updating, gradually getting closer to jan 22. long story short, i seem to have isolated the problem to commits made between date=2006.12.28.00.00.00 and date=2006.12.29.00.00.00. last hang i had was when running the 12/29 kernel, now it's 12/28 and the box has been up for 2 weeks already. based on previois experience i'm pretty certain that this is it. with bad kernel the box would never stay up more than a few days, never more than 5. between 12/28 and 12/29 i see some changes to /sys/amd64/ and /sys/pci/, which might've be the cause. i will probably start looking into individual changes, but if anyone more experienced than me could take a look, it'd be appreciated. i am willing to try patches. i confirmed that recent (as of 3 weeks or so) -STABLE still has this problem. thanks in advance. ==== files under /sys that were changed between 12/28 and 12/29: Edit src/sys/amd64/amd64/mptable_pci.c Edit src/sys/amd64/pci/pci_bus.c Edit src/sys/contrib/dev/ath/public/wackelf.c Edit src/sys/dev/acpica/acpi_pci.c Edit src/sys/dev/acpica/acpi_pcib_acpi.c Edit src/sys/dev/acpica/acpi_pcib_pci.c Checkout src/sys/dev/ath/if_ath.c Edit src/sys/dev/cardbus/cardbus.c Edit src/sys/dev/drm/drm_agpsupport.c Edit src/sys/dev/pci/pci.c Edit src/sys/dev/pci/pci_if.m Edit src/sys/dev/pci/pci_pci.c Edit src/sys/dev/pci/pci_private.h Edit src/sys/dev/pci/pcib_private.h Edit src/sys/dev/pci/pcivar.h Edit src/sys/i386/i386/mptable_pci.c Edit src/sys/i386/pci/pci_bus.c Edit src/sys/kern/subr_bus.c Checkout src/sys/netgraph/ng_deflate.h Edit src/sys/pci/agp.c Edit src/sys/pci/agpreg.h Edit src/sys/powerpc/ofw/ofw_pcib_pci.c Edit src/sys/sparc64/pci/apb.c Edit src/sys/sparc64/pci/ofw_pcib.c Edit src/sys/sparc64/pci/ofw_pcibus.c Edit src/sys/sys/param.h ==== kernel configuration used: include GENERIC options SMP options KDB options DDB makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC ==== -- Deomid Ryabkov aka Rojer myself@rojer.pp.ru rojer@sysadmins.ru ICQ: 8025844 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 16:01:30 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C24C16A400 for ; Fri, 30 Mar 2007 16:01:30 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 8D80713C4C2 for ; Fri, 30 Mar 2007 16:01:29 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2UG1PtS003120; Fri, 30 Mar 2007 20:01:25 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2UG1Jag003116; Fri, 30 Mar 2007 20:01:19 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Mar 2007 20:01:19 +0400 From: Yar Tikhiy To: Alex Zbyslaw Message-ID: <20070330160119.GC98431@comp.chem.msu.su> References: <20070326135106.GG60831@comp.chem.msu.su> <84dead720703260827q29ed7f26hd79dde461fe50d9b@mail.gmail.com> <20070327075934.GA10930@comp.chem.msu.su> <4608FBCA.2060302@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4608FBCA.2060302@dial.pipex.com> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 16:01:30 -0000 On Tue, Mar 27, 2007 at 12:11:06PM +0100, Alex Zbyslaw wrote: > Yar Tikhiy wrote: > > >>Aren't sed's addresses required to be cumulative across its > >>input files? > >> > >>http://www.opengroup.org/onlinepubs/009695399/utilities/sed.html > >> > >> > > > >That makes sense for filter mode because it's equvalent to > >concatenating the files in advance: > > > > cat files ... | sed expression > > > >OTOH, in-place mode selected by a -i option can be seen as follows: > > > > for f in files ...; do > > sed expression < $f > $f.tmp && mv $f $f.bak && mv $f.tmp $f > > done > > > >I.e., each file preserves its individuality. This can be at logical > >conflict with cumulative addresses across all files. > > > > > > > As a Joe Random sed user, I'd agree with Yar. The GNU behaviour makes > more sense in most practical examples I can think of. > > Perhaps a touch of feaping creaturism, but we could just add a -I flag > which behaved as -i does now, and make -i behave as GNU. I bet I > *could* construct examples where the current behaviour was what I desired. Thank you for supporting me! I've just looked at the code and it seems to me that it should be rather easy to preserve the current semantics under a -I flag, too. They are too neat to throw them away. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 17:21:39 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E293C16A4D7 for ; Fri, 30 Mar 2007 17:21:39 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1E67813C4BD for ; Fri, 30 Mar 2007 17:21:38 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2UHLYRT004687; Fri, 30 Mar 2007 21:21:34 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2UHLYj6004686; Fri, 30 Mar 2007 21:21:34 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Mar 2007 21:21:33 +0400 From: Yar Tikhiy To: Diomidis Spinellis Message-ID: <20070330172133.GD98431@comp.chem.msu.su> References: <20070326135106.GG60831@comp.chem.msu.su> <460B76A0.5030200@aueb.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460B76A0.5030200@aueb.gr> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 17:21:40 -0000 On Thu, Mar 29, 2007 at 11:19:44AM +0300, Diomidis Spinellis wrote: > Yar Tikhiy wrote: > > > >Recently noticed that our sed(1) differs from its GNU analog in > >that in -i mode it considers all files as a single sequence of lines > >while the latter treats each file independently. The in-line mode > >isn't in POSIX, so it isn't really clear which way is correct. > > > >Here is a couple of practical consequences: > > > >- our sed won't act on a numeric range of lines in each file, > > as in: sed -i '' 2,5d *, which may be counter-intuitive. > >- our sed's line ranges can span file boundaries in -i mode. > > > >If the second feature isn't important, I think we should use > >a separate line space for each file edited in-line, which is > >usually desired. > > > >Comments? > > > >P.S. Attached are a test script and outputs from it for our > >sed and GNU sed as found in a Linux I have access to. > > > > I believe the GNU interpretation of lines in -i makes sense. Hurray! I've got a blessing from the author of BSD sed himself! :-) Thank you! May I take a bit more of your time? I've started playing with the code and noticed another gray area. Namely a `c' command won't print the text if having 2 addresses with the 2nd address beyond the actual end of file. For example: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN $ jot 9 | > sed '6,15c\ > text > ' test 1 2 3 4 5 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END Ditto with RE's, if the 2nd RE doesn't match any line: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN $ jot 9 | sed '/6/,/15/c\ > text > ' test 1 2 3 4 5 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END If we've started to delete the pattern space, we should print the text in place of it because `c' is for `change'. BSD and GNU seds have this bug, but Solaris sed doesn't have it. Do you think we should fix it, too? Thanks! -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 17:31:17 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A4C816A400 for ; Fri, 30 Mar 2007 17:31:17 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id CFC9213C4CC for ; Fri, 30 Mar 2007 17:31:16 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-02.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l2UHVF2F015378; Fri, 30 Mar 2007 20:31:15 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-02.forthnet.gr (8.13.7/8.13.7) with ESMTP id l2UHVFtJ005711; Fri, 30 Mar 2007 20:31:15 +0300 Received: from [192.168.136.22] (ppp121-127.adsl.forthnet.gr [193.92.228.127]) by MX-IN-01.forthnet.gr (8.14.0/8.14.0) with ESMTP id l2UHV6HF002136; Fri, 30 Mar 2007 20:31:07 +0300 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <460D494E.3030106@aueb.gr> Date: Fri, 30 Mar 2007 20:30:54 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Yar Tikhiy References: <20070326135106.GG60831@comp.chem.msu.su> <460B76A0.5030200@aueb.gr> <20070330172133.GD98431@comp.chem.msu.su> In-Reply-To: <20070330172133.GD98431@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 17:31:17 -0000 Yar Tikhiy wrote: > May I take a bit more of your time? > > I've started playing with the code and noticed another gray area. > Namely a `c' command won't print the text if having 2 addresses > with the 2nd address beyond the actual end of file. For example: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN > $ jot 9 | >> sed '6,15c\ >> text >> ' test > 1 > 2 > 3 > 4 > 5 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END > > Ditto with RE's, if the 2nd RE doesn't match any line: > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN > $ jot 9 | sed '/6/,/15/c\ >> text >> ' test > 1 > 2 > 3 > 4 > 5 > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END > > If we've started to delete the pattern space, we should print the > text in place of it because `c' is for `change'. BSD and GNU seds > have this bug, but Solaris sed doesn't have it. Do you think we > should fix it, too? > > Thanks! > Yes, it sounds like a bug to me. Note that a couple of weeks ago I added the regression tests I originally wrote in 1992 to the FreeBSD regression test suite. Given that you are writing test cases it would be very nice to follow the format used in src/tools/regression/usr.bin/sed/regress.t, so that we can add them to the test suite. Diomidis From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 18:07:47 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A93216A409 for ; Fri, 30 Mar 2007 18:07:47 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1885213C4B0 for ; Fri, 30 Mar 2007 18:07:45 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2UI6LmK005476; Fri, 30 Mar 2007 22:06:21 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2UI6LQm005475; Fri, 30 Mar 2007 22:06:21 +0400 (MSD) (envelope-from yar) Date: Fri, 30 Mar 2007 22:06:20 +0400 From: Yar Tikhiy To: Diomidis Spinellis Message-ID: <20070330180620.GE98431@comp.chem.msu.su> References: <20070326135106.GG60831@comp.chem.msu.su> <460B76A0.5030200@aueb.gr> <20070330172133.GD98431@comp.chem.msu.su> <460D494E.3030106@aueb.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460D494E.3030106@aueb.gr> User-Agent: Mutt/1.5.9i Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 18:07:47 -0000 On Fri, Mar 30, 2007 at 08:30:54PM +0300, Diomidis Spinellis wrote: > Yar Tikhiy wrote: > >May I take a bit more of your time? > > > >I've started playing with the code and noticed another gray area. > >Namely a `c' command won't print the text if having 2 addresses > >with the 2nd address beyond the actual end of file. For example: > > > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN > >$ jot 9 | > >>sed '6,15c\ > >>text > >>' test > >1 > >2 > >3 > >4 > >5 > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END > > > >Ditto with RE's, if the 2nd RE doesn't match any line: > > > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BEGIN > >$ jot 9 | sed '/6/,/15/c\ > >>text > >>' test > >1 > >2 > >3 > >4 > >5 > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% END > > > >If we've started to delete the pattern space, we should print the > >text in place of it because `c' is for `change'. BSD and GNU seds > >have this bug, but Solaris sed doesn't have it. Do you think we > >should fix it, too? > > > >Thanks! > > > > Yes, it sounds like a bug to me. Thanks! I hope I'll make a fix for both issues soon, it's in the works already. The issues appear related in the code. > Note that a couple of weeks ago I > added the regression tests I originally wrote in 1992 to the FreeBSD > regression test suite. Given that you are writing test cases it would > be very nice to follow the format used in > src/tools/regression/usr.bin/sed/regress.t, so that we can add them to > the test suite. Thank you for pointing me out at the format! Sorry, I haven't looked at it yet, but I've noticed the tests going into the tree and remembered that I should pay attention to writing new regression tests and running the existing tests if I change sed. Of course, I'll use the standard format. -- Yar From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 18:39:36 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6E6A16A400 for ; Fri, 30 Mar 2007 18:39:36 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 830A013C4AD for ; Fri, 30 Mar 2007 18:39:36 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 81673 invoked by uid 0); 30 Mar 2007 18:12:54 -0000 Received: from 190.55.91.88 (HELO deimos.mars.bsd) (190.55.91.88) by relay03.pair.com with SMTP; 30 Mar 2007 18:12:54 -0000 X-pair-Authenticated: 190.55.91.88 Date: Fri, 30 Mar 2007 15:12:31 -0300 From: Alejandro Pulver To: freebsd-hackers@FreeBSD.org Message-ID: <20070330151231.355bd1da@deimos.mars.bsd> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_elzd4oR.+7mr2Sl4Zl4c9cA; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: Subject: sysutils/fusefs-ntfs: slow reading/writing speed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 18:39:37 -0000 --Sig_elzd4oR.+7mr2Sl4Zl4c9cA Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello. I have tried sysutils/fusefs-ntfs (version 1.0) and had a maximum write speed of 1.2MB/Sec. Reading is a little faster: 2MB/Sec. There were some discussions about this in the ntfs-3g forums, and they said was fixed in the new beta version (now it's stable, see official site), note that by default it uses an option that is not available on FreeBSD's mount_fusefs, so try with "-o no_def_opts". http://forum.ntfs-3g.org/viewtopic.php?p=3D1330&sid=3D8e59dcb7050a15378eb93= d5659c04409 It makes no difference for me. However I found the following which says "the reason for the slow copy on FreeBSD is the lack of buffer cache for block devices which should be solved in FreeBSD 7.0", and mentions "ublio", a library for user space cache which can be used with it, made by the author of fuse4bsd. The rest of the thread is irrelevant for the matter. http://forum.ntfs-3g.org/viewtopic.php?p=3D1153&sid=3Dcde9378447762e86345a8= 9130fd267d5 Unfortunately I couldn't make it work, if someone has time, please take a look. It would be really appreciated. I tried contacting the port maintainer without response. Thanks and Best Regards, Ale P.S.: please CC me as I'm not subscribed. --Sig_elzd4oR.+7mr2Sl4Zl4c9cA Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGDVMPiV05EpRcP2ERAlH6AKCLlH5EHRAJ0TUieZY6s9cL/2SrTgCdE1qu ZhbN56sk9FfWuxRVgpkZFy0= =0TjQ -----END PGP SIGNATURE----- --Sig_elzd4oR.+7mr2Sl4Zl4c9cA-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 30 19:02:10 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23A5E16A406 for ; Fri, 30 Mar 2007 19:02:10 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id C7D4913C480 for ; Fri, 30 Mar 2007 19:02:09 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so588980ana for ; Fri, 30 Mar 2007 12:02:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZSEGSj2Qw4IS+KQrrWgzUbTiXMRLJmGQ9lHdlw3IXHZtUO9Uyfn2qrQdI7q/FPZ3mTXqbe+xReaSDQ0omTP4q330LNxq9H64A4T615l2S5tnfFgQaX5ARCG2ViaDsTf9VsUylEmoh87AX454A9YiLKCEA+RAPTQqaqzCQYhKWgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=trZZ/LlrXY+UiRretmtdHO+IjvnIigGCh89VOsISv+TQgduaAsK2pCbMvaYCl0M7dkEmzpXsd3ZQS0gS9Nt13B4Y/QK4MYhilytd8sWk9yzv8cstvzT6KHkUDH0ZcSLoSOjYtwwv+sPZmgBmqjOOy5nftelnu0mPlJRhuhrNiqk= Received: by 10.100.44.13 with SMTP id r13mr1644924anr.1175281328760; Fri, 30 Mar 2007 12:02:08 -0700 (PDT) Received: by 10.100.177.10 with HTTP; Fri, 30 Mar 2007 12:02:08 -0700 (PDT) Message-ID: Date: Fri, 30 Mar 2007 12:02:08 -0700 From: "Maksim Yevmenkin" To: "Timothy Bourke" , hackers@freebsd.org In-Reply-To: <20070329224205.GA819@triptrop.cse.unsw.EDU.AU> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070325015717.GA797@triptrop> <20070329224205.GA819@triptrop.cse.unsw.EDU.AU> Cc: Subject: Re: enable/disable in kbd drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2007 19:02:10 -0000 On 3/29/07, Timothy Bourke wrote: [...] > > >Does the attached patch seem reasonable? It would fix my immediate > > >problem. > > > > sorry for the delay. i'm not sure about this patch. basically, i do > > not think that keyboard should be disabled if it is released from > > kbdmux. it is perfectly fine, imo, to have two (or more) active > > keyboards attached to the system as long as only one of them is > > primary. it is possible to use /dev/kbdX interface to talk to > > non-primary keyboard(s) directly. > > It seems that, for the extant drivers: > * enable only increments kb_active, > * disable only decrements kb_active. well, yes, if all kbdmux did was call KBD_ACTIVATE/_DEACTIVATE directly, i would not have any problem with it. however, kbdmux calls enable() method and other drivers (such as the one you wrote) may do other things in enable/disable() methods. perhaps the right thing to do to is to have kbdmux check is keyboard is "enabled" and if not - call enable()? thanks, max > With the printf suggested above, one can see that repeating the > commands: > kbdcontrol -A usb0 < /dev/console > kbdcontrol -a usb0 < /dev/console > continually increases kb_active. > > Even with the patch, detaching any of the current kbd drivers will not > deactivate them (reduce kb_active to zero) because they all call > enable (increment kb_active) when initialized. Which answers one of > the other questions. > > Alternative (not serious) suggestion: since the disable hook seems > never to be called, it might as well be removed from the > keyboard_switch... > > Tim. > > > From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 01:55:42 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF26116A402 for ; Sat, 31 Mar 2007 01:55:42 +0000 (UTC) (envelope-from crossd@cs.rpi.edu) Received: from cliffclavin.cs.rpi.edu (cliffclavin.cs.rpi.edu [128.213.1.9]) by mx1.freebsd.org (Postfix) with ESMTP id B535C13C45B for ; Sat, 31 Mar 2007 01:55:42 +0000 (UTC) (envelope-from crossd@cs.rpi.edu) Received: from monica.cs.rpi.edu (root@monica.cs.rpi.edu [128.213.7.2]) by cliffclavin.cs.rpi.edu (8.13.6/8.13.6) with ESMTP id l2V1iP7e034695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2007 20:44:26 -0500 (EST) Received: from monica.cs.rpi.edu (crossd@localhost [127.0.0.1]) by monica.cs.rpi.edu (8.13.3/8.12.6) with ESMTP id l2V1iPgB053181 for ; Fri, 30 Mar 2007 21:44:25 -0400 (EDT) (envelope-from crossd@monica.cs.rpi.edu) Received: (from crossd@localhost) by monica.cs.rpi.edu (8.13.6/8.12.6/Submit) id l2V1iPMS053180; Fri, 30 Mar 2007 21:44:25 -0400 (EDT) (envelope-from crossd) Date: Fri, 30 Mar 2007 21:44:25 -0400 (EDT) From: "David E. Cross" To: freebsd-hackers@freebsd.org Message-ID: <20070330214137.U74265@monica.cs.rpi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 128.213.1.9 Subject: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 01:55:43 -0000 I recently ran into a problem where the 32bit JVM won't run on a 64bit host. I, and at least one other person in -java thinks it has to do with 32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is this still the issue? Could someone point me in the general direction of the specifics of the problem (if they exist, if not, I may try to create a simpler test case then java)? I tried a few searches, but nothing matching what I remembered came up. -- David E. Cross From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 02:23:34 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A62DF16A402 for ; Sat, 31 Mar 2007 02:23:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 70F5413C455 for ; Sat, 31 Mar 2007 02:23:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l2V2NNeG002152; Fri, 30 Mar 2007 22:23:23 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Fri, 30 Mar 2007 22:23:24 -0400 (EDT) Date: Fri, 30 Mar 2007 22:23:23 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "David E. Cross" In-Reply-To: <20070330214137.U74265@monica.cs.rpi.edu> Message-ID: References: <20070330214137.U74265@monica.cs.rpi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 02:23:34 -0000 On Fri, 30 Mar 2007, David E. Cross wrote: > I recently ran into a problem where the 32bit JVM won't run on a 64bit host. > I, and at least one other person in -java thinks it has to do with 32 bit KSE > on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is > this still the issue? Could someone point me in the general direction of the > specifics of the problem (if they exist, if not, I may try to create a > simpler test case then java)? > > I tried a few searches, but nothing matching what I remembered came up. No, you can't run 32-bit libpthread on 64-bit kernel. There are no compatiblity hooks in the kernel to handle 32-bit kse interfaces. It is really too messy to provide it. -- DE From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 02:50:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEC1116A404 for ; Sat, 31 Mar 2007 02:50:14 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3548813C458 for ; Sat, 31 Mar 2007 02:50:14 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l2V2QOox000606 for ; Sat, 31 Mar 2007 04:26:24 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Sat, 31 Mar 2007 04:26:23 +0200 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703310426.23953.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Subject: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 02:50:14 -0000 Hello List, I have these files: --- loader.cpp --- #include #include "tls.h" int main() { tls = 0; printf("%d\n", tls); } --- tls.cpp --- #include "tls.h" int __thread tls; --- tls.h --- extern __thread int tls; When I compile them like this: c++ -fPIC -o tls.so tls.cpp -shared c++ -fPIC -o loader loader.cpp tls.so And run the resulting program, I get: pyotr@nox:~/projects/misc/tls> ./loader /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in non-PLT relocations When I omit -fPIC, it runs fine. But I need fPIC for the shared object on amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it ran fine (with fPIC). Much to my surprise however, a particularly large application I'm working on did compile & run on FreeBSD/amd64 using -fpic (lowercase) and gcc 4.3. Trying -fpic on FreeBSD/i386 resulted in failure. FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp threadprivate()) support in gcc 4.3. The workaround I found on FreeBSD/amd64 was linking the main executable with -fno-PIC, or building everything with -fpic. (both workarounds didn't work on FreeBSD/i386) I would be grateful if someone could shed some light on this. Regards, Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 03:15:35 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB2DD16A409 for ; Sat, 31 Mar 2007 03:15:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3172013C48C for ; Sat, 31 Mar 2007 03:15:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2V3FXwi028186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Mar 2007 20:15:33 -0700 X-Auth-Received: from [192.168.10.7] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2V3FWGo032513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2007 20:15:33 -0700 Message-ID: <460DE02F.5020202@u.washington.edu> Date: Fri, 30 Mar 2007 20:14:39 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200703310426.23953.pieter@degoeje.nl> In-Reply-To: <200703310426.23953.pieter@degoeje.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.30.200638 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 03:15:35 -0000 Pieter de Goeje wrote: > Hello List, > > I have these files: > --- loader.cpp --- > #include > #include "tls.h" > > int main() { > tls = 0; > printf("%d\n", tls); > } > > --- tls.cpp --- > #include "tls.h" > int __thread tls; > > --- tls.h --- > extern __thread int tls; > > When I compile them like this: > c++ -fPIC -o tls.so tls.cpp -shared > c++ -fPIC -o loader loader.cpp tls.so > > And run the resulting program, I get: > pyotr@nox:~/projects/misc/tls> ./loader > /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in non-PLT > relocations > > When I omit -fPIC, it runs fine. But I need fPIC for the shared object on > amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it ran fine (with > fPIC). > > Much to my surprise however, a particularly large application I'm working on > did compile & run on FreeBSD/amd64 using -fpic (lowercase) and gcc 4.3. > Trying -fpic on FreeBSD/i386 resulted in failure. > > FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp > threadprivate()) support in gcc 4.3. > > The workaround I found on FreeBSD/amd64 was linking the main executable > with -fno-PIC, or building everything with -fpic. (both workarounds didn't > work on FreeBSD/i386) > > I would be grateful if someone could shed some light on this. > > Regards, > Pieter de Goeje Pieter, Did you know that -fPIC and -fpic aren't the same? From : |-fpic| Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. |-fPIC| If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. Position-independent code requires special support, and therefore works only on certain machines. Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 05:27:41 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6870516A401 for ; Sat, 31 Mar 2007 05:27:41 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.freebsd.org (Postfix) with ESMTP id F38C313C459 for ; Sat, 31 Mar 2007 05:27:40 +0000 (UTC) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: from triptrop.cse.unsw.edu.au (blaax11-a130.dialup.optusnet.com.au [203.164.190.130]) by mail20.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l2V5RZO2009710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Mar 2007 15:27:37 +1000 Received: from triptrop.cse.unsw.edu.au (localhost [127.0.0.1]) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6) with ESMTP id l2V5PxCq001782 for ; Sat, 31 Mar 2007 15:26:00 +1000 (EST) (envelope-from tbourke@triptrop.cse.unsw.edu.au) Received: (from tbourke@localhost) by triptrop.cse.unsw.edu.au (8.13.8/8.13.6/Submit) id l2V5Pxak001781 for hackers@freebsd.org; Sat, 31 Mar 2007 15:25:59 +1000 (EST) (envelope-from tbourke) Date: Sat, 31 Mar 2007 15:25:58 +1000 From: Timothy Bourke To: hackers@freebsd.org Message-ID: <20070331052558.GD755@triptrop.cse.unsw.EDU.AU> Mail-Followup-To: hackers@freebsd.org References: <20070325015717.GA797@triptrop> <20070329224205.GA819@triptrop.cse.unsw.EDU.AU> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NklN7DEeGtkPCoo3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://www.cse.unsw.edu.au/~tbourke/pubkey.txt Cc: Subject: Re: enable/disable in kbd drivers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 05:27:41 -0000 --NklN7DEeGtkPCoo3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mar 30 at 12:02 -0700, Maksim Yevmenkin wrote: > On 3/29/07, Timothy Bourke wrote: > >It seems that, for the extant drivers: > > * enable only increments kb_active, > > * disable only decrements kb_active. >=20 > well, yes, if all kbdmux did was call KBD_ACTIVATE/_DEACTIVATE > directly, i would not have any problem with it. however, kbdmux calls > enable() method and other drivers (such as the one you wrote) may do > other things in enable/disable() methods. perhaps the right thing to > do to is to have kbdmux check is keyboard is "enabled" and if not - > call enable()? Maybe there is a gap between the function names, enable() and disable(), and their intended operation? If we interpret enable/disable() as a form of reference counting (as seems to be implemented) then consumers of a keyboard driver should call enable() when they expected to receive data, and disable() when finished with the driver (as done by syscons). Drivers wanting to run regardless of such requests could call enable() themselves when initialized (as they do already). Other drivers could run activation code when enable() is called and kb_active changes from 0 to 1, and deactivation code when disable() is called and kb_active changes from 1 to 0. Specifically my driver could acquire the ppbus and start a polling thread when attached (enable() && 0->1). It could release the ppbus and stop the polling thread when not required (disable() and 1->0). Thank you, Tim. --NklN7DEeGtkPCoo3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFGDfDmtKVK1sFb0ecRAkZxAJ0Tx2CEINrTn0gTlBh2hlh8KT6NqgCcCkKN oZunk8VGtrjWruIBagddJl0= =xBVI -----END PGP SIGNATURE----- --NklN7DEeGtkPCoo3-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 07:16:12 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3150F16A402 for ; Sat, 31 Mar 2007 07:16:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from gateway.cybervisiontech.com.ua (gateway.cybervisiontech.com.ua [88.81.251.18]) by mx1.freebsd.org (Postfix) with ESMTP id DBB7713C455 for ; Sat, 31 Mar 2007 07:16:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (hq.cybervisiontech.com [127.0.0.1]) by gateway.cybervisiontech.com.ua (Postfix) with ESMTP id 9DAE6ED46C6; Sat, 31 Mar 2007 10:16:09 +0300 (EEST) X-Virus-Scanned: amavisd-new at cybervisiontech.com Received: from gateway.cybervisiontech.com.ua ([127.0.0.1]) by localhost (hq.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1Xor8-dkqek; Sat, 31 Mar 2007 10:16:08 +0300 (EEST) Received: from [10.2.1.87] (rein.cybervisiontech.com.ua [10.2.1.87]) by gateway.cybervisiontech.com.ua (Postfix) with ESMTP id 7F7B4ED469D; Sat, 31 Mar 2007 10:16:08 +0300 (EEST) Message-ID: <460E0AB8.8040608@icyb.net.ua> Date: Sat, 31 Mar 2007 10:16:08 +0300 From: Andriy Gapon User-Agent: Thunderbird 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Daniel Eischen References: <1175318584.00714931.1175306401@10.7.7.3> <1175318590.00714940.1175308202@10.7.7.3> In-Reply-To: <1175318590.00714940.1175308202@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 07:16:12 -0000 on 31/03/2007 05:23 Daniel Eischen said the following: > On Fri, 30 Mar 2007, David E. Cross wrote: > >> I recently ran into a problem where the 32bit JVM won't run on a 64bit host. >> I, and at least one other person in -java thinks it has to do with 32 bit KSE >> on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is >> this still the issue? Could someone point me in the general direction of the >> specifics of the problem (if they exist, if not, I may try to create a >> simpler test case then java)? >> >> I tried a few searches, but nothing matching what I remembered came up. > > No, you can't run 32-bit libpthread on 64-bit kernel. There > are no compatiblity hooks in the kernel to handle 32-bit kse > interfaces. It is really too messy to provide it. Daniel, maybe you can send a followup to the following ? http://www.freebsd.org/cgi/query-pr.cgi?pr=110655 Given that 32-bit libthr also doesn't work on 64-bit kernel, the only option is to map thread libs to libc_r via libmap32.conf. BTW, next time there is a poll about retiring libc_r please count me against for precisely this reason. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 11:02:30 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D7B816A407 for ; Sat, 31 Mar 2007 11:02:30 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id E802913C4B0 for ; Sat, 31 Mar 2007 11:02:28 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l2VB2MlJ023646 for ; Sat, 31 Mar 2007 15:02:22 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l2VB2LMg023645 for hackers@freebsd.org; Sat, 31 Mar 2007 15:02:22 +0400 (MSD) (envelope-from yar) Date: Sat, 31 Mar 2007 15:02:21 +0400 From: Yar Tikhiy To: hackers@freebsd.org Message-ID: <20070331110221.GI98431@comp.chem.msu.su> References: <20070326135106.GG60831@comp.chem.msu.su> <460B76A0.5030200@aueb.gr> <20070330172133.GD98431@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070330172133.GD98431@comp.chem.msu.su> User-Agent: Mutt/1.5.9i Cc: Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 11:02:30 -0000 On Fri, Mar 30, 2007 at 09:21:33PM +0400, Yar Tikhiy wrote: [...] > If we've started to delete the pattern space, we should print the > text in place of it because `c' is for `change'. BSD and GNU seds > have this bug, but Solaris sed doesn't have it. [...] By the way, I found myself w/o a Solaris account, but I was able to build Solaris sed in FreeBSD quickly from the OpenSolaris sources. All it took was downloading the following files: http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed.h http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed0.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed1.c http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbhead/regexp.h and issuing this command: cc -I. -o sed sed*.c Voila! (Their regexp.h offers definitions of its functions, not just their prototypes, which made my task very easy.) Perhaps other basic tools from Solaris could be built in this way for the purpose of testing, too, in case one needs them but has no Solaris account at hand. Another $0.02 from yours truly. :-) -- Yar From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 14:33:59 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F39A316A403 for ; Sat, 31 Mar 2007 14:33:58 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id 730FB13C4AD for ; Sat, 31 Mar 2007 14:33:58 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so729697wxc for ; Sat, 31 Mar 2007 07:33:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=CNRJC2BEHWdNed8W8DpqgsyMxZTv/ttussZfB8dT/0v1Ax84KkcJ+HDc2MMgtzYXQJ+Jp0WEIfd0HpJvwev+2HqxcUSvrRincMhJPCwPBzbqVkuvYMCbFIt5ZhQlsLuFvpD5rJwxyF8JG0tfOYwHPrBoKYn2edHyLozKOCkImBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=pqxHiwVR9p2ZPQqz2j5wqeV+ugUbZ0d9h3kp4BsBYgE2phh1Svcnj9GJc1JqYe3ZhuxVZgoqyZJLa6s+G90Lna+rJmjKXc2HNnqaO7kh9tWt7ORiP5IQvKeOFRcNb70SuMQ8/vUyvj4l96buyvmPgPmp5hJI8psD6vXR8aYvObE= Received: by 10.70.56.4 with SMTP id e4mr5523727wxa.1175349922569; Sat, 31 Mar 2007 07:05:22 -0700 (PDT) Received: from kan.dnsalias.net ( [24.34.98.164]) by mx.google.com with ESMTP id 14sm4719959wrl.2007.03.31.07.05.21; Sat, 31 Mar 2007 07:05:21 -0700 (PDT) Date: Sat, 31 Mar 2007 10:05:15 -0400 From: Alexander Kabaev To: Pieter de Goeje Message-ID: <20070331100515.15b62e92@kan.dnsalias.net> In-Reply-To: <200703310426.23953.pieter@degoeje.nl> References: <200703310426.23953.pieter@degoeje.nl> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.11; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_i2A_C2kAIm0sZ0KNAm5Xrlm; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org Subject: Re: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 14:33:59 -0000 --Sig_i2A_C2kAIm0sZ0KNAm5Xrlm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 31 Mar 2007 04:26:23 +0200 Pieter de Goeje wrote: > Hello List, >=20 > I have these files: > --- loader.cpp --- > #include > #include "tls.h" >=20 > int main() { > tls =3D 0; > printf("%d\n", tls); > } >=20 > --- tls.cpp --- > #include "tls.h" > int __thread tls; >=20 > --- tls.h --- > extern __thread int tls; >=20 > When I compile them like this: > c++ -fPIC -o tls.so tls.cpp -shared > c++ -fPIC -o loader loader.cpp tls.so >=20 > And run the resulting program, I get: > pyotr@nox:~/projects/misc/tls> ./loader > /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in > non-PLT relocations >=20 > When I omit -fPIC, it runs fine. But I need fPIC for the shared > object on amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it > ran fine (with fPIC). >=20 > Much to my surprise however, a particularly large application I'm > working on did compile & run on FreeBSD/amd64 using -fpic (lowercase) > and gcc 4.3. Trying -fpic on FreeBSD/i386 resulted in failure. >=20 > FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp=20 > threadprivate()) support in gcc 4.3. >=20 > The workaround I found on FreeBSD/amd64 was linking the main > executable with -fno-PIC, or building everything with -fpic. (both > workarounds didn't work on FreeBSD/i386) >=20 > I would be grateful if someone could shed some light on this. >=20 There is no reason whatsoever to compile main binary code with -f[pP]ic. Executables are not shared libraries and stuffing position independent code into them makes no sense. --=20 Alexander Kabaev --Sig_i2A_C2kAIm0sZ0KNAm5Xrlm Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGDmqbQ6z1jMm+XZYRAlR9AKCCthvWBQFibWpZnGwAYO2Srt3gKACfTpBe RjvoMEvItrccTK97B6x6QHM= =WmDR -----END PGP SIGNATURE----- --Sig_i2A_C2kAIm0sZ0KNAm5Xrlm-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 15:53:14 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2273B16A401 for ; Sat, 31 Mar 2007 15:53:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 11B1913C455 for ; Sat, 31 Mar 2007 15:53:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sat, 31 Mar 2007 08:23:52 -0700 Received: from [192.168.2.4] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4F422125B65; Sat, 31 Mar 2007 08:53:13 -0700 (PDT) Message-ID: <460E83E8.6050202@elischer.org> Date: Sat, 31 Mar 2007 08:53:12 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "David E. Cross" References: <20070330214137.U74265@monica.cs.rpi.edu> In-Reply-To: <20070330214137.U74265@monica.cs.rpi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 15:53:14 -0000 David E. Cross wrote: > I recently ran into a problem where the 32bit JVM won't run on a 64bit > host. I, and at least one other person in -java thinks it has to do > with 32 bit KSE on a 64bit kernel (I have a vague memory on this > somewheres WAY back). Is this still the issue? Could someone point me > in the general direction of the specifics of the problem (if they exist, > if not, I may try to create a simpler test case then java)? > > I tried a few searches, but nothing matching what I remembered came up. > The KSE system calls have not been emulated in the 32 bit emulation layer. it tries to save a 64 bit stack frame where it needs to save a 32 bit stack frame. try run libthr for now. fixing the emulation layer is in my "to do" list but I'm busy with RealWork (TM) From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 18:48:20 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DBBF16A403; Sat, 31 Mar 2007 18:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 302C913C468; Sat, 31 Mar 2007 18:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l2VIm9uK067650; Sat, 31 Mar 2007 13:48:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Sat, 31 Mar 2007 14:40:43 -0400 User-Agent: KMail/1.9.4 References: <1175318584.00714931.1175306401@10.7.7.3> <1175318590.00714940.1175308202@10.7.7.3> <460E0AB8.8040608@icyb.net.ua> In-Reply-To: <460E0AB8.8040608@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703311440.44428.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Sat, 31 Mar 2007 13:48:09 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2981/Sat Mar 31 10:50:41 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Daniel Eischen , freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 18:48:20 -0000 On Saturday 31 March 2007 03:16, Andriy Gapon wrote: > on 31/03/2007 05:23 Daniel Eischen said the following: > > On Fri, 30 Mar 2007, David E. Cross wrote: > > > >> I recently ran into a problem where the 32bit JVM won't run on a 64bit host. > >> I, and at least one other person in -java thinks it has to do with 32 bit KSE > >> on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is > >> this still the issue? Could someone point me in the general direction of the > >> specifics of the problem (if they exist, if not, I may try to create a > >> simpler test case then java)? > >> > >> I tried a few searches, but nothing matching what I remembered came up. > > > > No, you can't run 32-bit libpthread on 64-bit kernel. There > > are no compatiblity hooks in the kernel to handle 32-bit kse > > interfaces. It is really too messy to provide it. > > > Daniel, > > maybe you can send a followup to the following ? > http://www.freebsd.org/cgi/query-pr.cgi?pr=110655 > > Given that 32-bit libthr also doesn't work on 64-bit kernel, the only > option is to map thread libs to libc_r via libmap32.conf. > BTW, next time there is a poll about retiring libc_r please count me > against for precisely this reason. I plan on making sure full 32-bit compat exists for both libthr and libpthread and backporting it to 6.x for work. Very few things are too hard to wrap with a 32-bit shim. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 18:53:40 2007 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FD6816A401 for ; Sat, 31 Mar 2007 18:53:40 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 856BE13C483 for ; Sat, 31 Mar 2007 18:53:39 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (dialup85.ach.sch.gr [81.186.70.85]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2VIgBWe016118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 31 Mar 2007 21:42:25 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2VH7s2K003122; Sat, 31 Mar 2007 20:08:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2VH7dEQ003121; Sat, 31 Mar 2007 20:07:39 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Sat, 31 Mar 2007 20:07:39 +0300 From: Giorgos Keramidas To: Yar Tikhiy Message-ID: <20070331170738.GB2687@kobe.laptop> References: <20070326135106.GG60831@comp.chem.msu.su> <460B76A0.5030200@aueb.gr> <20070330172133.GD98431@comp.chem.msu.su> <20070331110221.GI98431@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070331110221.GI98431@comp.chem.msu.su> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.68, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.52, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: hackers@freebsd.org Subject: Re: sed -i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 18:53:40 -0000 On 2007-03-31 15:02, Yar Tikhiy wrote: >On Fri, Mar 30, 2007 at 09:21:33PM +0400, Yar Tikhiy wrote: >[...] >> If we've started to delete the pattern space, we should print the >> text in place of it because `c' is for `change'. BSD and GNU seds >> have this bug, but Solaris sed doesn't have it. >[...] > > By the way, I found myself w/o a Solaris account, but I was able > to build Solaris sed in FreeBSD quickly from the OpenSolaris sources. > All it took was downloading the following files: > > http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed.h > http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed0.c > http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbcmd/sed/sed1.c > http://cvs.opensolaris.org/source/raw/onnv/onnv-gate/usr/src/ucbhead/regexp.h > > and issuing this command: > > cc -I. -o sed sed*.c > > Voila! (Their regexp.h offers definitions of its functions, not > just their prototypes, which made my task very easy.) > > Perhaps other basic tools from Solaris could be built in this way > for the purpose of testing, too, in case one needs them but has no > Solaris account at hand. Nice. With very minor modifications, it may be possible to build more of the OpenSolaris tools on FreeBSD. For instance, the only change I had to make to build the Solaris version of cat(1) on FreeBSD was: %%% --- cat.c.orig Sat Mar 31 20:03:26 2007 +++ cat.c Sat Mar 31 20:02:07 2007 @@ -43,7 +43,9 @@ #include #include +#ifdef __FreeBSD_version #include +#endif #include #include #include %%% The Solaris version of cat(1) calls textdomain() and gettext() explicitly, so I also had to use libintl.so from the Ports to compile it successfully: $ cc -I/usr/local/include cat.c -L/usr/local/lib -lintl But it does work, AFAICT. I haven't tried localized message support yet, but this will take a bit more effort :-) From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 22:02:17 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B309516A401 for ; Sat, 31 Mar 2007 22:02:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7590F13C48C for ; Sat, 31 Mar 2007 22:02:17 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l2VM2CDw000741; Sat, 31 Mar 2007 18:02:12 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Sat, 31 Mar 2007 18:02:13 -0400 (EDT) Date: Sat, 31 Mar 2007 18:02:12 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <200703311440.44428.jhb@freebsd.org> Message-ID: References: <1175318584.00714931.1175306401@10.7.7.3> <1175318590.00714940.1175308202@10.7.7.3> <460E0AB8.8040608@icyb.net.ua> <200703311440.44428.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: 32/64bit KSE issues? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 22:02:17 -0000 On Sat, 31 Mar 2007, John Baldwin wrote: > On Saturday 31 March 2007 03:16, Andriy Gapon wrote: >> on 31/03/2007 05:23 Daniel Eischen said the following: >>> On Fri, 30 Mar 2007, David E. Cross wrote: >>> >>>> I recently ran into a problem where the 32bit JVM won't run on a 64bit host. >>>> I, and at least one other person in -java thinks it has to do with 32 bit KSE >>>> on a 64bit kernel (I have a vague memory on this somewheres WAY back). Is >>>> this still the issue? Could someone point me in the general direction of the >>>> specifics of the problem (if they exist, if not, I may try to create a >>>> simpler test case then java)? >>>> >>>> I tried a few searches, but nothing matching what I remembered came up. >>> >>> No, you can't run 32-bit libpthread on 64-bit kernel. There >>> are no compatiblity hooks in the kernel to handle 32-bit kse >>> interfaces. It is really too messy to provide it. [ ... ] > I plan on making sure full 32-bit compat exists for both libthr and > libpthread and backporting it to 6.x for work. Very few things are > too hard to wrap with a 32-bit shim. Not according to peter@ ;-) But if you can do it, that'd be great. -- DE From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 23:01:13 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C8EA16A402 for ; Sat, 31 Mar 2007 23:01:13 +0000 (UTC) (envelope-from stanislav.ochotnicky@kmit.sk) Received: from alibaba.kmit.sk (alibaba.kmit.sk [194.160.28.1]) by mx1.freebsd.org (Postfix) with ESMTP id D43B613C489 for ; Sat, 31 Mar 2007 23:01:12 +0000 (UTC) (envelope-from stanislav.ochotnicky@kmit.sk) Received: from localhost (localhost.localdomain [127.0.0.1]) by alibaba.kmit.sk (Postfix) with ESMTP id DDE305FBA8 for ; Sun, 1 Apr 2007 00:36:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at kmit.sk Received: from [194.160.28.54] (roller.kmit.sk [194.160.28.54]) by alibaba.kmit.sk (Postfix) with ESMTP id 0B4FC5FB89 for ; Sun, 1 Apr 2007 00:36:57 +0200 (CEST) Message-ID: <460EE276.1020802@kmit.sk> Date: Sun, 01 Apr 2007 00:36:38 +0200 From: Stanislav Ochotnicky MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig74E48E8AA4A6B00D1143CA34" Subject: Deny system call using ptrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 23:01:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig74E48E8AA4A6B00D1143CA34 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi, I'm trying to create sort of user-space access control system based on allowing/denying syscalls. I was able (after a few problems) to start ptracing program, stop at every enter/exit from system call, inspect arguments etc. What I'm however trying to do, is denying access to syscalls. In linux I was able to do this by changing register eax to SYS_getpid or other safe system call using ptrace(PT_SETREGS,..). Problem is, that FreeBSD kernel seems to ignore changed register, and execute original system call. If I do PT_SETREGS and right after that PT_GETREGS, I can see that register was changed, so that should be ok. It is possible I'm missing something, or there is another option. I'd be grateful for any advice or idea. Thanks, S.O. --------------enig74E48E8AA4A6B00D1143CA34 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGDuJ9B9Uc/HGhZ3wRCDg/AKCKTx+GSxXyD4WIq/waShnDyEcQ8ACfSQvN cluHm6M02nO2AItKjE0FKDw= =LMMz -----END PGP SIGNATURE----- --------------enig74E48E8AA4A6B00D1143CA34-- From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 23:12:44 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D98816A401 for ; Sat, 31 Mar 2007 23:12:44 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id E561E13C4BA for ; Sat, 31 Mar 2007 23:12:43 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l2VNCdLr004396; Sun, 1 Apr 2007 01:12:40 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Sun, 1 Apr 2007 01:12:39 +0200 User-Agent: KMail/1.9.6 References: <200703310426.23953.pieter@degoeje.nl> <20070331100515.15b62e92@kan.dnsalias.net> In-Reply-To: <20070331100515.15b62e92@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704010112.39803.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Subject: Re: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 23:12:44 -0000 On zaterdag 31 maart 2007, Alexander Kabaev wrote: > There is no reason whatsoever to compile main binary code with -f[pP]ic. > Executables are not shared libraries and stuffing position independent > code into them makes no sense. You are right ofcourse. However it doesn't explain why it won't work. - Pieter de Goeje From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 23:16:28 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A04716A401 for ; Sat, 31 Mar 2007 23:16:28 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp1.utsp.utwente.nl [130.89.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 006EE13C4BF for ; Sat, 31 Mar 2007 23:16:27 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id l2VNGOLr004864; Sun, 1 Apr 2007 01:16:24 +0200 From: Pieter de Goeje To: freebsd-hackers@freebsd.org Date: Sun, 1 Apr 2007 01:16:24 +0200 User-Agent: KMail/1.9.6 References: <200703310426.23953.pieter@degoeje.nl> <460DE02F.5020202@u.washington.edu> In-Reply-To: <460DE02F.5020202@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704010116.24514.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Garrett Cooper Subject: Re: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 23:16:28 -0000 On zaterdag 31 maart 2007, Garrett Cooper wrote: > Pieter de Goeje wrote: > > Hello List, > > > > I have these files: > > --- loader.cpp --- > > #include > > #include "tls.h" > > > > int main() { > > tls = 0; > > printf("%d\n", tls); > > } > > > > --- tls.cpp --- > > #include "tls.h" > > int __thread tls; > > > > --- tls.h --- > > extern __thread int tls; > > > > When I compile them like this: > > c++ -fPIC -o tls.so tls.cpp -shared > > c++ -fPIC -o loader loader.cpp tls.so > > > > And run the resulting program, I get: > > pyotr@nox:~/projects/misc/tls> ./loader > > /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in non-PLT > > relocations > > > > When I omit -fPIC, it runs fine. But I need fPIC for the shared object on > > amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it ran fine (with > > fPIC). > > > > Much to my surprise however, a particularly large application I'm working > > on did compile & run on FreeBSD/amd64 using -fpic (lowercase) and gcc > > 4.3. Trying -fpic on FreeBSD/i386 resulted in failure. > > > > FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp > > threadprivate()) support in gcc 4.3. > > > > The workaround I found on FreeBSD/amd64 was linking the main executable > > with -fno-PIC, or building everything with -fpic. (both workarounds > > didn't work on FreeBSD/i386) > > > > I would be grateful if someone could shed some light on this. > > > > Regards, > > Pieter de Goeje > > Pieter, > Did you know that -fPIC and -fpic aren't the same? From > I was aware of that, however: > : > |-fpic| > > Generate position-independent code (PIC) suitable for use in a > shared library, if supported for the target machine. Such code > accesses all constant addresses through a global offset table (GOT). > The dynamic loader resolves the GOT entries when the program starts > (the dynamic loader is not part of GCC; it is part of the operating > system). If the GOT size for the linked executable exceeds a > machine-specific maximum size, you get an error message from the > linker indicating that -fpic does not work; in that case, recompile > with -fPIC instead. (These maximums are 8k on the SPARC and 32k on > the m68k and RS/6000. The 386 has no such limit.) > > Position-independent code requires special support, and therefore > works only on certain machines. For the 386, GCC supports PIC for > System V but not for the Sun 386i. Code generated for the IBM > RS/6000 is always position-independent. > > |-fPIC| > > If supported for the target machine, emit position-independent code, > suitable for dynamic linking and avoiding any limit on the size of > the global offset table. This option makes a difference on the m68k, > PowerPC and SPARC. tells me that there should not be a difference between the two on the AMD64 arch. Apparently there is... > > Position-independent code requires special support, and therefore > works only on certain machines. Cheers, Pieter de Goeje