From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 22 16:12:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B288D106578F for ; Sun, 22 Mar 2009 16:12:10 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by mx1.freebsd.org (Postfix) with ESMTP id 915288FC13 for ; Sun, 22 Mar 2009 16:12:10 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms181.mailsrvcs.net ([172.18.12.133]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KGW007PLY7SUXHE@vms173011.mailsrvcs.net> for freebsd-hackers@freebsd.org; Sun, 22 Mar 2009 10:11:52 -0500 (CDT) Received: from 96.234.43.209 ([96.234.43.209]) by vms181.mailsrvcs.net (Verizon Webmail) with HTTP; Sun, 22 Mar 2009 10:11:52 -0500 (CDT) Date: Sun, 22 Mar 2009 10:11:52 -0500 (CDT) From: Sergey Babkin To: gabriele.modena@gmail.com Message-id: <81564424.534529.1237734712737.JavaMail.root@vms181.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [96.234.43.209] X-Mailman-Approved-At: Sun, 22 Mar 2009 16:22:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Semantic File System 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, 22 Mar 2009 16:12:11 -0000 Sorry if this sounds like s tupid suggestion, but have you thought abou= t doing an user-space prototype first? It's usually much easier to deve= lop and modify. Then after the features get worked out, move it into the= kernel. -SB Mar 21, 2009 07:51:18 AM, [1]gabriele.mod= ena@gmail.com wrote: Hello, I am an AI master student at the university of = Amsterdam. On of my current research interests lays in the area of i= nformation retrieval and I would like to do a project within my Unive= rsity research group starting next june. I am actually studying back= ground literature about semantic filesystem and information retrieval ov= er local files. Being also quite interested in kernel development, I= would like to propose a proof of concept that implements such technique= s. My goal, though, would not be just a reimplementation of existing = code, but possibly some more extensive work that combines techniques alr= eady used in other domains of II. Could this be an interesting Summe= r of Code proposal for the FreeBSD Foundation? I plan to write down = some notes/ideas (and details) I have on a wiki starting from next week.= Regards. _______________________________________________ = [2]freebsd-hackers@freebsd.org mailing list [3]http://lists.freebsd.org/mailman/listinfo/fr= eebsd-hackers To unsubscribe, send any mail to "[4]freebsd-hackers-unsubscribe@freebsd.org" References 1. 3D"mailto:gabr= 2. 3D"mailto:freebsd-hackers@freebsd.org" 3. 3D"http://lists.freebsd.org/mailman/listinfo/freebsd-hackers" 4. 3D"mailto:fr= From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 22 16:52:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FAE51065672 for ; Sun, 22 Mar 2009 16:52:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DFD6B8FC13 for ; Sun, 22 Mar 2009 16:52:54 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 857C646B32; Sun, 22 Mar 2009 12:52:54 -0400 (EDT) Date: Sun, 22 Mar 2009 16:52:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gabriele Modena In-Reply-To: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> Message-ID: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Semantic File System 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, 22 Mar 2009 16:52:55 -0000 On Sat, 21 Mar 2009, Gabriele Modena wrote: > I am an AI master student at the university of Amsterdam. > > On of my current research interests lays in the area of information > retrieval and I would like to do a project within my University research > group starting next june. > > I am actually studying background literature about semantic filesystem and > information retrieval over local files. > > Being also quite interested in kernel development, I would like to propose a > proof of concept that implements such techniques. My goal, though, would not > be just a reimplementation of existing code, but possibly some more > extensive work that combines techniques already used in other domains of II. > > Could this be an interesting Summer of Code proposal for the FreeBSD > Foundation? > > I plan to write down some notes/ideas (and details) I have on a wiki > starting from next week. Hi Gabriele-- We are certainly not uninterested in projects along these lines, but I think the trick will be creating a convincing proposal that argues that (a) you can do the work in a summer, (b) there's a compelling usage case for including the results in FreeBSD, and (c) find a mentor who can supervise you in this project. What sort of semantic file system do you have in mind? How would you feel about a middle-ground project along the lines of Mac OS X Spotlight or similar efficient userspace indexing of a file system based on feedback from the file system about what has changed, or something BeOS-like, in which indexing takes place for extended attributes rather than for contents? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 22 21:38:35 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0338E106564A for ; Sun, 22 Mar 2009 21:38:35 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id D54788FC15 for ; Sun, 22 Mar 2009 21:38:34 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 21825 invoked from network); 22 Mar 2009 21:38:34 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Mar 2009 21:38:34 -0000 Message-ID: <49C6AFD6.2070400@telenix.org> Date: Sun, 22 Mar 2009 17:38:30 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: FreeBSD-Hackers X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: dbus causing my cvsup to fail 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, 22 Mar 2009 21:38:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This one completely mystifies me. I have a little script I use to cvsup, cvs update, and rebuild my system, and it's been hitting failures about once a month over the last 6 months. The failures are all fairly alike: cvsup fails to apply a delta to one of the text files in /home/ncvs/usr/ports (not the subdirs, things like UPDATING only). Generally I don't notice this until hours later, when I notice that my cvs update of that file failed, and I've been fixing it by deleting the affected file in my /home/ncvs, and re-running my script. Just now, I happened to run it while I was watching, and I caught this coming from my messages, it's obviously from the same processes (my machine is named "april"): Mar 22 17:03:32 april dbus-daemon: Would reject message, 1 matched rules; type="method_call", sender=":1.59" (uid=1001 pid=42493 comm=") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=1202 comm=")) I lost the actual error message, but I recall that the 1.59 was part of the string defining the delta. The rest of it I'm blaming on dbus due to the very coincidental timing, exactly the same as the error. I wish I'd kept the original error, but it's gone now, it didn't go into messages. So, somehow, dbus is causing this, but I'm not on particularly good terms with dbus & hal, so I can't tell where to go to start fixing this. Anyone get anything from this error message? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknGr9YACgkQz62J6PPcoOkabQCdEE6Icqcs13cZpc8W8OkPgJ7B RaAAoIIepuLb6eXAurn/iGicQNNXqCVl =rHj3 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 03:00:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55DC3106566B for ; Mon, 23 Mar 2009 03:00:54 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id E8CBE8FC14 for ; Mon, 23 Mar 2009 03:00:53 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 1173 invoked from network); 23 Mar 2009 02:34:11 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 23 Mar 2009 02:34:11 -0000 Message-ID: <49C6F4F4.5030609@acm.poly.edu> Date: Sun, 22 Mar 2009 22:33:24 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 03:00:54 -0000 Ahoy. I got bitten by this today--a system I administer for someone had users in more than 16 groups, so I had to bump the value, recompile the kernel, and reboot. It seems desirable to (at the very least) make this a read-only tunable that can be set using /boot/loader.conf, so as to avoid source modification and kernel recompilation. I had a look around, and noticed that NGROUPS_MAX is used to construct static arrays in a couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that malloc(9)/MALLOC(9) can be used to allocate memory for the array instead, and panic() (or something) can be called if the allocation fails, no? Is that about the gist of it? If I'm not overlooking something major, I'd like to take a stab at it. -Boris From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 01:35:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DBBF106564A for ; Mon, 23 Mar 2009 01:35:10 +0000 (UTC) (envelope-from ruchi20386@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 58A408FC0A for ; Mon, 23 Mar 2009 01:35:10 +0000 (UTC) (envelope-from ruchi20386@gmail.com) Received: by gxk24 with SMTP id 24so6850885gxk.19 for ; Sun, 22 Mar 2009 18:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:received:message-id:subject :from:to:content-type; bh=s8SLcoM7rN76CHkokHMuandzaDyH0kBpH+sDZHoqjjo=; b=t4X6NZUXlOCJdTBvSuBQd7iq1gx5voLK3a7UGgsCj7Kjg3BzznBfC3BY07WaB7BxFP omIIXywBoUEDcRdEY6hwCTKmZxY2fGeBNTZjELS7eJD+ymHUlKMEZPs3mCvFNnpaqpO0 3Sk9fKjjzuaG8kiIAl5YwEvKXVub5R4L5dYu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=BSqNqoRMliBdUlHEHe8W7BjucVQgzrIDAokL/C+OdF7VlzBVk5F3OB5Y/MSigN93Yu Fc0Fb1qCOUPtTw8eex2HFfpnWrzMBRNnDf3CXnMENB+zPjdYJ+Sy2Txr5F1bpYptrC39 blBIeQ7bNrImAngyLVnD/+xKw8BiKXmgxzvck= MIME-Version: 1.0 Date: Sun, 22 Mar 2009 21:08:01 -0400 Received: by 10.151.45.2 with SMTP id x2mr11782163ybj.109.1237770496456; Sun, 22 Mar 2009 18:08:16 -0700 (PDT) Message-ID: From: Ruchi Varshney To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 23 Mar 2009 03:20:30 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: AVR-GCC compiler options 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, 23 Mar 2009 01:35:11 -0000 Hi,I am looking for a way to intermix source code with the asm code generated when I compile a .c file "avr-gcc -S" option. Right now, I know that when I use "avr-objdump -S" on the .s file obtained from avr-gcc, I can see that the output is intermixes with the actual source code from the .c file. Is there a way I can get the source code to appear in the .s file when I use "avr-gcc"? Thanks Ruchi From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 03:53:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC875106566B for ; Mon, 23 Mar 2009 03:53:01 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id B48A88FC1A for ; Mon, 23 Mar 2009 03:53:01 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-75-22.phlapa.east.verizon.net [141.151.75.22]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 9FBBE6D4DB; Mon, 23 Mar 2009 12:52:59 +0900 (JST) Date: Sun, 22 Mar 2009 23:52:53 -0400 From: Yoshihiro Ota To: Robert Watson Message-Id: <20090322235253.432874dd.ota@j.email.ne.jp> In-Reply-To: References: <20090320045319.04484fc5.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good? 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, 23 Mar 2009 03:53:02 -0000 On Fri, 20 Mar 2009 13:24:09 +0000 (GMT) Robert Watson wrote: > > On Fri, 20 Mar 2009, Yoshihiro Ota wrote: > > > 1. With TCP connections, only sender side can detect some communication > > issues passively if happened. By using two connections, you lost that > > ability by your self. I agree on this one. > > Could you expand a bit on this point? While the connection creation process > (usually) asymmetric, once the connection is built it's essentially the same > state machine on both sides of the connection, and socket semantics with > respect to the state machine are effectively identical. Application on both > sides should be able to detect disconnect, monitor connection state using > TCP_INFO, etc. What I meant was that there were cases when a receiver could not tell weather no data was coming or communication was interrupted. Once connection is established, a route is available between a server and a client. Let's say this route is broken for some reasons, i.e. someone unplugged a cable or a firewall started dropping or rejecting between these server and client, a sender may not notice as soon as it happens but at least, a sender knows a massages was not delivered right. On the other hand, receiver side does not have any idea that a message delivery failure has happened at all or for a while unless using heartbeat messages in upper layer. KEEP_ALIVE option seems to be implementation dependent such that you cannot assure TCP connection availability for every minute. Thanks, Hiro From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 04:57:27 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16761106564A for ; Mon, 23 Mar 2009 04:57:27 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id BE8B68FC19 for ; Mon, 23 Mar 2009 04:57:26 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2N4dbow061938; Mon, 23 Mar 2009 00:39:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2N4dbYa061937; Mon, 23 Mar 2009 00:39:37 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 23 Mar 2009 00:39:37 -0400 From: David Schultz To: Boris Kochergin Message-ID: <20090323043937.GA61818@zim.MIT.EDU> Mail-Followup-To: Boris Kochergin , freebsd-hackers@FreeBSD.ORG References: <49C6F4F4.5030609@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C6F4F4.5030609@acm.poly.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 04:57:27 -0000 On Sun, Mar 22, 2009, Boris Kochergin wrote: > Ahoy. I got bitten by this today--a system I administer for someone had > users in more than 16 groups, so I had to bump the value, recompile the > kernel, and reboot. It seems desirable to (at the very least) make this > a read-only tunable that can be set using /boot/loader.conf, so as to > avoid source modification and kernel recompilation. I had a look around, > and noticed that NGROUPS_MAX is used to construct static arrays in a > couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that > malloc(9)/MALLOC(9) can be used to allocate memory for the array > instead, and panic() (or something) can be called if the allocation > fails, no? Is that about the gist of it? If I'm not overlooking > something major, I'd like to take a stab at it. There's already a kern.ngroups sysctl, but there are many places where `ngroups' needs to be used in preference to NGROUPS in the kernel. In userland, sysconf(_SC_NGROUPS_MAX) needs to be used in preference to NGROUPS_MAX. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 06:06:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1411065673 for ; Mon, 23 Mar 2009 06:06:27 +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 B32088FC0A for ; Mon, 23 Mar 2009 06:06:26 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n2N66M9g025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2009 16:36:23 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-hackers@freebsd.org Date: Mon, 23 Mar 2009 16:36:07 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart58953020.MTTDRR8SoT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200903231636.17259.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Ruchi Varshney Subject: Re: AVR-GCC compiler options 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, 23 Mar 2009 06:06:27 -0000 --nextPart58953020.MTTDRR8SoT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 23 March 2009 11:38:01 Ruchi Varshney wrote: > Hi,I am looking for a way to intermix source code with the asm code > generated when I compile a .c file "avr-gcc -S" option. > Right now, I know that when I use "avr-objdump -S" on the .s file obtained > from avr-gcc, I can see that the output is intermixes with the actual > source code from the .c file. Is there a way I can get the source code to > appear in the .s file when I use "avr-gcc"? You'd be better off asking this question on the avr-gcc list. You can pass -Wa,-adhlmsn=3Dfoo.lst to gcc and it will make a .lst which wi= ll do=20 what I think you want.. =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 --nextPart58953020.MTTDRR8SoT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD4DBQBJxybR5ZPcIHs/zowRAoe5AJY+nXIGlkRBUl2vly9dtUC8VHIEAJ45V/In 16nZameRSLPNDfj7pOs4hA== =r27H -----END PGP SIGNATURE----- --nextPart58953020.MTTDRR8SoT-- From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 07:56:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D00C1065676; Mon, 23 Mar 2009 07:56:08 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id D90B78FC1E; Mon, 23 Mar 2009 07:56:07 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n2N7Oq2U053841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2009 00:24:52 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n2N7OqrW053840; Mon, 23 Mar 2009 00:24:52 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA09831; Sun, 22 Mar 09 23:20:59 PST Date: Mon, 23 Mar 2009 00:19:57 -0700 From: perryh@pluto.rain.com To: ota@j.email.ne.jp Message-Id: <49c7381d.eJH7/fiaDJB9Gr6c%perryh@pluto.rain.com> References: <20090320045319.04484fc5.ota@j.email.ne.jp> <20090322235253.432874dd.ota@j.email.ne.jp> In-Reply-To: <20090322235253.432874dd.ota@j.email.ne.jp> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, rwatson@freebsd.org Subject: Re: 2 uni-directional TCP connection good? 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, 23 Mar 2009 07:56:09 -0000 > What I meant was that there were cases when a receiver could not > tell weather no data was coming or communication was interrupted. > Once connection is established, a route is available between a > server and a client. Let's say this route is broken for some > reasons, i.e. someone unplugged a cable or a firewall started > dropping or rejecting between these server and client, a sender > may not notice as soon as it happens but at least, a sender knows > a massages was not delivered right. On the other hand, receiver > side does not have any idea that a message delivery failure has > happened at all or for a while unless using heartbeat messages > in upper layer. KEEP_ALIVE option seems to be implementation > dependent such that you cannot assure TCP connection availability > for every minute. The whole point of TCP (vs IP alone, or UDP) is to establish reliable end-to-end communication over unreliable underlying links. If a packet is corrupted or lost, it gets resent. If a route goes down, and an alternate is available, TCP will -- eventually -- find it and recover. If the last (or only) route goes down, TCP will in principle wait indefinitely for a route to become available, whether by reestablishment of the original or provision of an alternative. So you are correct that a receiver can't tell the difference between a loss of connectivity and the sender having crashed, however the situation is entirely symmetric: the sender can't tell the difference either. It all gets sorted out when communication is reestablished; at that point traffic will resume (if the link had been down) or the uncrashed end will get a connection reset (if its peer had crashed). The practice of sending keep-alive packets simply converts a temporary (thus potentially recoverable) communication loss into what amounts to an unrecoverable crash of whichever end gets impatient first. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 08:20:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7103C106564A for ; Mon, 23 Mar 2009 08:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4BF6C8FC0A for ; Mon, 23 Mar 2009 08:20:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E35FB46B51; Mon, 23 Mar 2009 04:20:20 -0400 (EDT) Date: Mon, 23 Mar 2009 08:20:20 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yoshihiro Ota In-Reply-To: <20090322235253.432874dd.ota@j.email.ne.jp> Message-ID: References: <20090320045319.04484fc5.ota@j.email.ne.jp> <20090322235253.432874dd.ota@j.email.ne.jp> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good 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, 23 Mar 2009 08:20:21 -0000 On Sun, 22 Mar 2009, Yoshihiro Ota wrote: >> On Fri, 20 Mar 2009, Yoshihiro Ota wrote: >> >>> 1. With TCP connections, only sender side can detect some communication >>> issues passively if happened. By using two connections, you lost that >>> ability by your self. I agree on this one. >> >> Could you expand a bit on this point? While the connection creation >> process (usually) asymmetric, once the connection is built it's essentially >> the same state machine on both sides of the connection, and socket >> semantics with respect to the state machine are effectively identical. >> Application on both sides should be able to detect disconnect, monitor >> connection state using TCP_INFO, etc. > > What I meant was that there were cases when a receiver could not tell > weather no data was coming or communication was interrupted. Once > connection is established, a route is available between a server and a > client. Let's say this route is broken for some reasons, i.e. someone > unplugged a cable or a firewall started dropping or rejecting between these > server and client, a sender may not notice as soon as it happens but at > least, a sender knows a massages was not delivered right. On the other > hand, receiver side does not have any idea that a message delivery failure > has happened at all or for a while unless using heartbeat messages in upper > layer. KEEP_ALIVE option seems to be implementation dependent such that you > cannot assure TCP connection availability for every minute. This is generally considered a robustness property rather than a fragility issue, but yes: if you need a liveliness property for idle connections with TCP, it's something you have to implement at the application layer, and many protocols indeed do this. I don't see that this is an argument for using two TCP connections as opposed to one, however. If you're interested in alternative protocols, however, SCTP allows a number of these protocol behaviors to be modified, and includes support for a heartbeat. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 12:57:53 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 471861065673 for ; Mon, 23 Mar 2009 12:57:53 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 92D1B8FC0C for ; Mon, 23 Mar 2009 12:57:52 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 26485 invoked from network); 23 Mar 2009 12:51:11 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 23 Mar 2009 12:51:11 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id D11861031D; Mon, 23 Mar 2009 12:51:10 +0000 (UTC) Date: Mon, 23 Mar 2009 12:51:10 +0000 From: ttw+bsd@cobbled.net To: Boris Kochergin , freebsd-hackers@FreeBSD.ORG Message-ID: <20090323125110.GB8686@holyman.cobbled.net> Mail-Followup-To: Boris Kochergin , freebsd-hackers@FreeBSD.ORG References: <49C6F4F4.5030609@acm.poly.edu> <20090323043937.GA61818@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090323043937.GA61818@zim.MIT.EDU> Cc: Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 12:57:53 -0000 On 23.03-00:39, David Schultz wrote: [ ... ] > There's already a kern.ngroups sysctl, but there are many places > where `ngroups' needs to be used in preference to NGROUPS in the > kernel. In userland, sysconf(_SC_NGROUPS_MAX) needs to be used in > preference to NGROUPS_MAX. you will also note that, as you look at this more, NGROUPS_MAX controls very little regarding the relevant buffers and, generally, without reviewing it again to be specific i'd suggest that you may expose a number of buffer overruns but will most certainally not get the 'correct' behaviour from the change. i.e. removing NGROUPS_MAX may remove an error message from setgroups but will not increase the buffer allocations or alter relevant code to check NGROUPS_MAX correctly. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 13:11:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C461065674 for ; Mon, 23 Mar 2009 13:11:44 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 3E7B48FC13 for ; Mon, 23 Mar 2009 13:11:43 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 24690 invoked from network); 23 Mar 2009 12:45:03 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 23 Mar 2009 12:45:03 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id C15B11031D; Mon, 23 Mar 2009 12:45:02 +0000 (UTC) Date: Mon, 23 Mar 2009 12:45:02 +0000 From: ttw+bsd@cobbled.net To: Boris Kochergin Message-ID: <20090323124502.GA8686@holyman.cobbled.net> Mail-Followup-To: Boris Kochergin , freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C6F4F4.5030609@acm.poly.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 13:11:45 -0000 On 22.03-22:33, Boris Kochergin wrote: > Ahoy. I got bitten by this today--a system I administer for someone had > users in more than 16 groups, so I had to bump the value, recompile the > kernel, and reboot. It seems desirable to (at the very least) make this > a read-only tunable that can be set using /boot/loader.conf, so as to > avoid source modification and kernel recompilation. I had a look around, > and noticed that NGROUPS_MAX is used to construct static arrays in a > couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that > malloc(9)/MALLOC(9) can be used to allocate memory for the array > instead, and panic() (or something) can be called if the allocation > fails, no? Is that about the gist of it? If I'm not overlooking > something major, I'd like to take a stab at it. i've sumbitted a patch for this to hackers@' list but actually bumping the groups limit is more work. i'm pretty far on with it but am unsure wwhen it'll be completed. if anyone wishes a copy of the patches or current working patch then i'd be happy to post it. note that bumping NGROUPS_MAX will do little in itself. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 14:21:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38250106566C for ; Mon, 23 Mar 2009 14:21:05 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0024E8FC0A for ; Mon, 23 Mar 2009 14:21:04 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 4719 invoked from network); 23 Mar 2009 14:21:04 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 23 Mar 2009 14:21:04 -0000 Message-ID: <49C79A9B.9070309@acm.poly.edu> Date: Mon, 23 Mar 2009 10:20:11 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: ttw+bsd@cobbled.net, freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> <20090323124502.GA8686@holyman.cobbled.net> In-Reply-To: <20090323124502.GA8686@holyman.cobbled.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 14:21:06 -0000 ttw+bsd@cobbled.net wrote: > On 22.03-22:33, Boris Kochergin wrote: > >> Ahoy. I got bitten by this today--a system I administer for someone had >> users in more than 16 groups, so I had to bump the value, recompile the >> kernel, and reboot. It seems desirable to (at the very least) make this >> a read-only tunable that can be set using /boot/loader.conf, so as to >> avoid source modification and kernel recompilation. I had a look around, >> and noticed that NGROUPS_MAX is used to construct static arrays in a >> couple of locations ("ibcs2_gid_t iset[NGROUPS_MAX];"). It seems that >> malloc(9)/MALLOC(9) can be used to allocate memory for the array >> instead, and panic() (or something) can be called if the allocation >> fails, no? Is that about the gist of it? If I'm not overlooking >> something major, I'd like to take a stab at it. >> > > i've sumbitted a patch for this to hackers@' list but actually > bumping the groups limit is more work. i'm pretty far on with it > but am unsure wwhen it'll be completed. if anyone wishes a copy of > the patches or current working patch then i'd be happy to post it. > > note that bumping NGROUPS_MAX will do little in itself. > _______________________________________________ > 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" > Well, bumping it does get rid of messages like: Mar 22 20:44:26 hydrogen sshd[96152]: getgrouplist: groups list too small Mar 22 20:44:26 hydrogen sshd[96152]: fatal: initgroups: [user]: Invalid argument ...and allows users who are in more than 16 groups to log in. I think there's something to be said for that. Anyway, thanks for the update. I'd love to see a resolution to this other than having to recompile the kernel. Let me know if I can help things along somehow. -Boris From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 15:34:13 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70CE2106566C for ; Mon, 23 Mar 2009 15:34:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B41848FC18 for ; Mon, 23 Mar 2009 15:34:12 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA17650 for ; Mon, 23 Mar 2009 17:34:10 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49C7ABF1.3060808@icyb.net.ua> Date: Mon, 23 Mar 2009 17:34:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: fdc io ports 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, 23 Mar 2009 15:34:13 -0000 There is the following verbose and helpful comment in fdc_isa.c: > On standard ISA, we don't just use an 8 port range > (e.g. 0x3f0-0x3f7) since that covers an IDE control register at > 0x3f6. So, on older hardware, we use 0x3f0-0x3f5 and 0x3f7. > However, some BIOSs omit the control port, while others start at > 0x3f2. Of the latter, sometimes we have two resources, other times > we have one. We have to deal with the following cases: > > 1: 0x3f0-0x3f5 # very rare > 2: 0x3f0 # hints -> 0x3f0-0x3f5,0x3f7 > 3: 0x3f0-0x3f5,0x3f7 # Most common > 4: 0x3f2-0x3f5,0x3f7 # Second most common > 5: 0x3f2-0x3f5 # implies 0x3f7 too. > 6: 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 # becoming common > 7: 0x3f2-0x3f3,0x3f4-0x3f5 # rare > 8: 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 > 9: 0x3f0-0x3f3,0x3f4-0x3f5,0x3f7 Looking in fdc.c it seems that it never uses ports at offsets 0, 1 and 3: > #define FDOUT 2 /* Digital Output Register (W) */ ... > #define FDSTS 4 /* NEC 765 Main Status Register (R) */ > #define FDDSR 4 /* Data Rate Select Register (W) */ > #define FDDATA 5 /* NEC 765 Data Register (R/W) */ > #define FDCTL 7 /* Control Register (W) */ On my system ACPIreserves 0x3f2-0x3f5,0x3f7 ("second most common" above). In i386/amd64 world, it seems that the only reason to specify hint.fdc.0.port="0x3F0" in GENERIC.hints is to say "we actually do not use 0x3f0 and 0x3f1 ports, but we guess that they might affect fdc, so we'll reserve them just in case". Do we really need to do this over-safety? The only reason for me asking is that I am hacking on a driver for a Super I/O chip that actually uses 0x3f0 and 0x3f1 ports and there is a resource conflict with fdc when ACPI is disabled. It's not an issue, but I thought that we could free up those ports. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 15:54:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 097F8106566C for ; Mon, 23 Mar 2009 15:54:36 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 5420F8FC0C for ; Mon, 23 Mar 2009 15:54:35 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 77645 invoked from network); 23 Mar 2009 15:54:33 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 23 Mar 2009 15:54:33 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id 5F2201031D; Mon, 23 Mar 2009 15:54:33 +0000 (UTC) Date: Mon, 23 Mar 2009 15:54:33 +0000 From: n0g0013 To: Boris Kochergin Message-ID: <20090323155433.GA24517@holyman.cobbled.net> Mail-Followup-To: Boris Kochergin , freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> <20090323124502.GA8686@holyman.cobbled.net> <49C79A9B.9070309@acm.poly.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49C79A9B.9070309@acm.poly.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 15:54:36 -0000 On 23.03-10:20, Boris Kochergin wrote: [ ... ] > Well, bumping it does get rid of messages like: > > Mar 22 20:44:26 hydrogen sshd[96152]: getgrouplist: groups list too small > Mar 22 20:44:26 hydrogen sshd[96152]: fatal: initgroups: [user]: Invalid > argument yes, that's great but you may be surprised to learn that it doesn't actually solve your problem. i think (and without looking specifically at the impact my even be confident enough to say definately) if you get a groups list it will only be cropped and the error message is being erroneously avoided, not corrected. i'd also suggest that you may be opening up your system to some overflows although, generally, the code sections use the same limits and so you might get away with it. [ ... ] > I'd love to see a resolution to this other than having to recompile the > kernel. Let me know if I can help things along somehow. if you can grab my patch, confirm it builds for you and that it doesn't crash your system , that would be a big help. unfortunately i was going to test it on my xen box only to discover that it doesn't work with amd64 yet. i'm currently coding blind and am not a good programmer so this is bad[tm]. if you can do this and are happy to run a few further tests after that then i'll be sure to put some heat under the rest of the process and get the group limits removed correctly. -- t t w From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 16:24:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47FF5106566C for ; Mon, 23 Mar 2009 16:24:42 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6328FC1A for ; Mon, 23 Mar 2009 16:24:41 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 5316 invoked from network); 23 Mar 2009 16:24:41 -0000 Received: from unknown (HELO ?10.0.0.135?) (spawk@128.238.64.31) by acm.poly.edu with AES256-SHA encrypted SMTP; 23 Mar 2009 16:24:41 -0000 Message-ID: <49C7B793.1090308@acm.poly.edu> Date: Mon, 23 Mar 2009 12:23:47 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: n0g0013 , freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> <20090323124502.GA8686@holyman.cobbled.net> <49C79A9B.9070309@acm.poly.edu> <20090323155433.GA24517@holyman.cobbled.net> In-Reply-To: <20090323155433.GA24517@holyman.cobbled.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 23 Mar 2009 16:24:44 -0000 n0g0013 wrote: > On 23.03-10:20, Boris Kochergin wrote: > [ ... ] > >> Well, bumping it does get rid of messages like: >> >> Mar 22 20:44:26 hydrogen sshd[96152]: getgrouplist: groups list too small >> Mar 22 20:44:26 hydrogen sshd[96152]: fatal: initgroups: [user]: Invalid >> argument >> > > yes, that's great but you may be surprised to learn that it doesn't > actually solve your problem. i think (and without looking > specifically at the impact my even be confident enough to say > definately) if you get a groups list it will only be cropped and the > error message is being erroneously avoided, not corrected. i'd also > suggest that you may be opening up your system to some overflows > although, generally, the code sections use the same limits and so > you might get away with it. > > [ ... ] > >> I'd love to see a resolution to this other than having to recompile the >> kernel. Let me know if I can help things along somehow. >> > > if you can grab my patch, confirm it builds for you and that it doesn't > crash your system , that would be a big help. unfortunately i was > going to test it on my xen box only to discover that it doesn't work > with amd64 yet. i'm currently coding blind and am not a good > programmer so this is bad[tm]. > > if you can do this and are happy to run a few further tests after that > then i'll be sure to put some heat under the rest of the process and > get the group limits removed correctly. > > On my 7.0 system, and a kernel recompiled with NGROUPS_MAX set to 64, a getgrouplist() call for a user who is in more than 16 groups (24, to be exact) will populate the array specified by the "gid_t *groups" argument with the 24 groups the user is in, in addition to the group specified in the "gid_t basegid" argument. The value of the variable specified in the "int *ngroups" will also be 25, and the getgrouplist() call will return 0. So, as far as being a hack for a specific problem, it seems to work properly. Sure, I'll test the patch. Can you point me at it? -Boris From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 16:54:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB03106564A for ; Mon, 23 Mar 2009 16:54:48 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 69E6F8FC1C for ; Mon, 23 Mar 2009 16:54:48 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1306572yxm.13 for ; Mon, 23 Mar 2009 09:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=RtjOOeatpVw04rO4WV/Otd0XOMinQtC0O57VFFNwHLI=; b=WjYFBCQ8HuE3ltcGRTbg4lRQmHzKdY7EgEEAhom5rYcvykloZECft1WbdS22Txy9tt Pksm4T5k1lI+oUlEM2MBC640sRYuUQy+TQhScI0NfyvEtta98UQYRtn6Iw64NAAZqifh cMUjmuOFJT0Arqvb9bzjJ194LwcvnryppF7+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=KHeDhQJZBOUsGP97pKqXocpWPH1DyR82nZvUmPEx2DOrCtsisltcV93Y7gRrnKm4Ez OzxY6ehfvGQHztMAak5Y6bnVMQe8voWpk50Fx426S1kV7EAoyLpg0qGagTntra0DhoiB 3c8osR2brSqN8o2F9YNLbEelDXTkquA90De8Y= MIME-Version: 1.0 Received: by 10.100.153.4 with SMTP id a4mr4356826ane.41.1237825814120; Mon, 23 Mar 2009 09:30:14 -0700 (PDT) Date: Mon, 23 Mar 2009 12:30:14 -0400 Message-ID: <3c0b01820903230930q1b54f9a5p38f4d6d230a350c7@mail.gmail.com> From: Alexander Sack To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Long double support in FreeBSD? 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, 23 Mar 2009 16:54:49 -0000 Hello: I'm working with building the Boost libraries and Boost.Math has long double support stubbed out for FreeBSD (personally I don't need it but..). I believe looking at some historical threads about this over the weekend and a lot of it was due to compiler GNUish bugs handling long double math (I believe Bruce Evans had some patches at one point but mentioned it was still crappy). Can someone speak if the current compiler/BSD flavors support long double math on a 64-bit capable CPU (LM=1)? Thanks! -aps From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 18:01:19 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 568E2106564A for ; Mon, 23 Mar 2009 18:01:19 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 171D78FC16 for ; Mon, 23 Mar 2009 18:01:18 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2NI3RC0009032; Mon, 23 Mar 2009 14:03:27 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2NI3RRn009031; Mon, 23 Mar 2009 14:03:27 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 23 Mar 2009 14:03:27 -0400 From: David Schultz To: Alexander Sack Message-ID: <20090323180327.GA8943@zim.MIT.EDU> Mail-Followup-To: Alexander Sack , FreeBSD Hackers References: <3c0b01820903230930q1b54f9a5p38f4d6d230a350c7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c0b01820903230930q1b54f9a5p38f4d6d230a350c7@mail.gmail.com> Cc: FreeBSD Hackers Subject: Re: Long double support in FreeBSD? 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, 23 Mar 2009 18:01:19 -0000 On Mon, Mar 23, 2009, Alexander Sack wrote: > I'm working with building the Boost libraries and Boost.Math has long > double support stubbed out for FreeBSD (personally I don't need it > but..). I believe looking at some historical threads about this over > the weekend and a lot of it was due to compiler GNUish bugs handling > long double math (I believe Bruce Evans had some patches at one point > but mentioned it was still crappy). > > Can someone speak if the current compiler/BSD flavors support long > double math on a 64-bit capable CPU (LM=1)? Long doubles are supported, except that long double versions of the following libm functions are missing: acoshl asinhl atanhl cbrtl coshl erfcl erfl expl expm1l lgammal log10l log1pl log2l logl powl sinhl tanhl tgammal The only other caveat is that on i386 we set the FPU to 53-bit precision so that gcc produces saner results in double precision. (See the archives for the gruesome details.) Of course, if you're running FreeBSD/amd64 on a 64-bit machine, this doesn't apply. From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 18:22:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D14106567A for ; Mon, 23 Mar 2009 18:22:11 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 628C38FC2D for ; Mon, 23 Mar 2009 18:22:11 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1335488ywh.13 for ; Mon, 23 Mar 2009 11:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=j6soVvfHz4nXI63I1cTnaXJTGcXKa3o3+ws/wkdJ2so=; b=oVeieS5CYoWIP/44cwb43rtqtXCPzUP3nsQS5BkL10fGA1ErJM014GGLxcowD1lsMF 1DkYcJpZSFmnKtRkCoLSQ6+AObuCg1kHIZxdQb0cvoUaoGYXu1bpQvZaUOlWj0S30ac8 i/JWz0E+/eUnTa0mr9HQpYsvynE2wqt+tZB6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RQOGfJgZ85kDMhrMDnGSkY07rwvFzKyHj3EwGqhadbsR2bLvBeEylRtijlcvwEapIC pnth/FdGJNxq/A25astDIK7RhMA6MEz/9J87MsFaRpYTOGWAYLRZvqHdmmsbY8uwEVMy mIJHBEL1IdRthEvCTNK1/oxELV8gj0sPb+USo= MIME-Version: 1.0 Received: by 10.100.105.9 with SMTP id d9mr6734499anc.142.1237832530871; Mon, 23 Mar 2009 11:22:10 -0700 (PDT) In-Reply-To: <20090323180327.GA8943@zim.MIT.EDU> References: <3c0b01820903230930q1b54f9a5p38f4d6d230a350c7@mail.gmail.com> <20090323180327.GA8943@zim.MIT.EDU> Date: Mon, 23 Mar 2009 14:22:10 -0400 Message-ID: <3c0b01820903231122mb763be4geb07cafecc80db1b@mail.gmail.com> From: Alexander Sack To: Alexander Sack , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Long double support in FreeBSD? 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, 23 Mar 2009 18:22:12 -0000 On Mon, Mar 23, 2009 at 2:03 PM, David Schultz wrote: > On Mon, Mar 23, 2009, Alexander Sack wrote: >> I'm working with building the Boost libraries and Boost.Math has long >> double support stubbed out for FreeBSD (personally I don't need it >> but..). =A0I believe looking at some historical threads about this over >> the weekend and a lot of it was due to compiler GNUish bugs handling >> long double math (I believe Bruce Evans had some patches at one point >> but mentioned it was still crappy). >> >> Can someone speak if the current compiler/BSD flavors support long >> double math on a 64-bit capable CPU (LM=3D1)? > > Long doubles are supported, except that long double versions of > the following libm functions are missing: > > =A0 =A0acoshl asinhl atanhl cbrtl coshl erfcl erfl expl expm1l > =A0 =A0lgammal log10l log1pl log2l logl powl sinhl tanhl tgammal > > The only other caveat is that on i386 we set the FPU to 53-bit > precision so that gcc produces saner results in double precision. > (See the archives for the gruesome details.) Of course, if you're > running FreeBSD/amd64 on a 64-bit machine, this doesn't apply. > Thank you so much David, that is what I needed to know (I just thought asking would be easier in this case than trying to parse through the many threads over the past about this topic). -aps From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 18:34:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DFB106566C; Mon, 23 Mar 2009 18:34:26 +0000 (UTC) (envelope-from chris@young-alumni.com) Received: from mail.oldschoolpunx.net (cpe-72-177-10-243.austin.res.rr.com [72.177.10.243]) by mx1.freebsd.org (Postfix) with ESMTP id AAE668FC12; Mon, 23 Mar 2009 18:34:26 +0000 (UTC) (envelope-from chris@young-alumni.com) Received: by mail.oldschoolpunx.net (Postfix, from userid 58) id D96FA96E54; Mon, 23 Mar 2009 13:18:05 -0500 (CDT) Received: from [192.168.8.100] (unknown [192.168.8.100]) by mail.oldschoolpunx.net (Postfix) with ESMTPSA id 340AB96DBB; Mon, 23 Mar 2009 13:14:12 -0500 (CDT) Message-Id: <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> From: Chris Ruiz To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Mar 2009 13:14:10 -0500 References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Subject: Re: ETA for ZFS v. 13 Merge From HEAD ? 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, 23 Mar 2009 18:34:27 -0000 On Mar 16, 2009, at 1:09 PM, Zaphod Beeblebrox wrote: > On Sun, Mar 15, 2009 at 6:39 PM, Pegasus Mc Cleaft > wrote: > >> Hi Adrian, >> >> I am not sure, but I didnt think ZFS 13 was ever going to be >> merged into >> 7-stable. I thought the kernel memory requirements were to great >> (just going >> back in my memory on that one). Also, I think there are still a few >> bugs >> left with the zil being enabled (and/or prefetch) causing lockups >> on machine >> with a lot of IO. I know I have hit that bug a few times on my >> machine when >> using various torrent clients when they want to preallocate large >> amounts of >> diskspace. >> >> I personally cant wait until a later version of ZFS is imported that >> supports encryption. I can finally say good-bye to our GEOM ELI USB >> drives >> for backups!! Never the less, I am quite thankfull to thoes >> involved in >> porting V13 to FreeBSD. Its a wonderfull improvement and my FS of >> choice >> when installing on new machines (especially zfs boot) > > > I think that you're touching on two entirely separate points here... > What it > takes to upgrade ZFS in -STABLE and what it takes to bring ZFS > modules in to > FreeBSD. > > I sincerely hope that ZFSv13 is planned for -STABLE. Last we left > this > issue, testing and a few kernel improvements were in the way. None > of the > kernel improvements were going to change the API, so the project was > doable > in -STABLE. That said, time marches on, 8.0-RELEASE draws ever > nearer. > When we were still several years out on 8.0 and ZFS was causing me > more > problems, I was much more keen to push for the port. I would still > welcome > it with open arms, but I'm not convinced that anyone is going to > push it > forward. > > The issue of encryption (along with many other issues) is tied to the > ability of FreeBSD to compile and use ZFS modules. Just like netgraph > modules extend the function of netgraph.ko and geom modules extend > the base > geom function, ZFS is designed (in Solaris, at least) to take > modules. ZFS > encryption is a module. I'm not clear on compression --- it would > make > sense that it is a module, but it seemingly got copied into FreeBSD > as a > core feature (and it may also be so in solaris). > > Anyways... is there any plans to allow for ZFS modules in FreeBSD? AFAIK ZFS v13 requires changes to the kernel that would break the ABI, which is not allowed to change in a STABLE branch. With 8.0 coming within the next 6 months, I doubt that 7 will see a new version of ZFS. There are no problems running ZFS v13 with zil and prefetch enabled and I have not had any predictable out of kernel memory panics. For me, ZFS on CURRENT really is *that* much better. Also, OpenSolaris has yet to integrate ZFS on disk encryption into their source. The code is currently under review: http://opensolaris.org/os/project/zfs-crypto/ . OpenSolaris uses ZFS v14 now and on disk encryption will probably be synced to a newer version of ZFS, meaning that this would require another code sync with OpenSolaris. Chris From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 23 21:09:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D5A710656BF; Mon, 23 Mar 2009 21:09:19 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 055E18FC17; Mon, 23 Mar 2009 21:09:18 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1384247yxm.13 for ; Mon, 23 Mar 2009 14:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RqvEaNtr0G+lRWmt5xB//Pjto3zMCblYprLM0t7AqvQ=; b=n7tvbVpWoVTPXcx3VXwYEXFzdmT/gCoynqMxLAhH/jm7DfKXEzgds3O8UN3Iwq9MTj 0q+tXq/K7xX+E/G2agZlyhLEyfZYUREKStJ9nRCpTdslAaK+HZJNw8ChcvN0MrLjX+MO AOcJOUMcAt8EVNUSmsYi0Mt6lid2ZWk8xw3m0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dBMqF17hCvUpaBMPHChybEsKjRanSiu2xxAhs/ZdMVlicPUXD+4GAaEjuAW0EvRF/b zx29MAGiNjLtc0U0+NnKF9Jx6pzKk64bMYfERP7wf8cb6Kx+kcfy6HyesXQ15XST4uVO e2cAC2GDBQih8SsSk3z1drmr1w4HF0BuY9ksk= MIME-Version: 1.0 Received: by 10.151.45.2 with SMTP id x2mr11920744ybj.176.1237842558273; Mon, 23 Mar 2009 14:09:18 -0700 (PDT) In-Reply-To: <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> References: <78cb3d3f0903151209r46837d70m914a23e30a19060e@mail.gmail.com> <4AE4493D5E9141E8812E4BC83FB5A2A5@PegaPegII> <5f67a8c40903161109le12b8afuc25b8c1ec1b6f70c@mail.gmail.com> <9DCF097D-421A-4F5F-8A48-D0286551C62C@young-alumni.com> Date: Mon, 23 Mar 2009 17:09:18 -0400 Message-ID: <5f67a8c40903231409q17fd0370wd2907525b8b6aff0@mail.gmail.com> From: Zaphod Beeblebrox To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: ETA for ZFS v. 13 Merge From HEAD ? 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, 23 Mar 2009 21:09:20 -0000 On Mon, Mar 23, 2009 at 2:14 PM, Chris Ruiz wrote: > > AFAIK ZFS v13 requires changes to the kernel that would break the ABI, > which is not allowed to change in a STABLE branch. With 8.0 coming within > the next 6 months, I doubt that 7 will see a new version of ZFS. Can we have someone who actually knows comment on this requirement? The last time this was discussed, I didn't hear this conclusion --- that ZFS 13 required ABI breaking kernel changes. > Also, OpenSolaris has yet to integrate ZFS on disk encryption into their > source. The code is currently under review: > http://opensolaris.org/os/project/zfs-crypto/ . OpenSolaris uses ZFS v14 > now and on disk encryption will probably be synced to a newer version of > ZFS, meaning that this would require another code sync with OpenSolaris. It should be said that importing updates from OpenSolaris needs to be easier. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 00:24:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C913A1065677 for ; Tue, 24 Mar 2009 00:24:41 +0000 (UTC) (envelope-from ab@addr.com) Received: from proxy1.addr.com (proxy1.addr.com [38.113.244.28]) by mx1.freebsd.org (Postfix) with ESMTP id B282B8FC17 for ; Tue, 24 Mar 2009 00:24:41 +0000 (UTC) (envelope-from ab@addr.com) Received: from ABPC (c-24-6-143-28.hsd1.ca.comcast.net [24.6.143.28]) by proxy1.addr.com (8.12.11/8.12.8/Submit) with SMTP id n2NNie2B049567 for ; Mon, 23 Mar 2009 16:44:40 -0700 (PDT) Message-ID: <7D939245FB7E4AFCA6AD00BFE5E933E0@ABPC> From: "Anthony Bourov" To: Date: Mon, 23 Mar 2009 16:39:49 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: nsdispatch performance issue for large group files 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, 24 Mar 2009 00:24:42 -0000 Regarding performance of: lib/libc/net/nsdispatch.c When used from: lib/libc/net/getgrent.c (called by initgroups()) I don't normally post here but I wanted to make a suggestion on a = performance issue that I spotted. I run a large number of high-volume = web hosting servers and noticed on some of the servers a severe decrease = in Apache's performance when the /etc/group file is large (over 100,000 = entries in a group file as it is combined across servers). I did a trace and found the following operation: stat("/etc/nsswitch.conf", {st_mode=3D052, st_size=3D4503681233059861, = ...}) =3D 0 repeating as many times as there is groups in the group file. I narrowed = the problem down to where apache calls "initgroups()" before forking = each process (nothing wrong here). And init groups goes through every = entry in the group file using getgrent(), which in turn calls nsdispatch = and which for every single call does "stat" on "/etc/nsswitch.conf" to = see if it changed.=20 This issue impacts different servers differently, on most of the SCSI = servers this delays apache startup my maybe a minute, however, on a Dell = SATA raid the "stat" command was significantly slower and caused = everything to come to a halt for several minuted every time apache = starts. In my opinion this is a very significant performance issue when working = with large servers. Most programs, including apache, will call = "initgroups()" for every time they fork, and it the group file is large = this means as many "stat" requests on the file system as there are = entries in the group file for every single fork() that the server does. For myself I just made it never test "stat" on "/etc/nsswitch.conf" = after the first time since I know that file is never modified. However, = a better solution would for nsdispatch realise in that case that it is = being ran in batch mode and should not keep testing if the file has = changed. This would effect both "getgrent" and "getpwent".=20 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 00:25:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC35B1065672 for ; Tue, 24 Mar 2009 00:25:10 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id C28508FC22 for ; Tue, 24 Mar 2009 00:25:10 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 6048 invoked from network); 23 Mar 2009 16:58:28 -0700 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 23 Mar 2009 16:58:28 -0700 From: Sean Bruno To: freebsd-hackers@freebsd.org Content-Type: text/plain Date: Mon, 23 Mar 2009 16:58:28 -0700 Message-Id: <1237852708.5106.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Subject: BSDCan Firewire Plugfest 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, 24 Mar 2009 00:25:11 -0000 Dan has accepted my proposal to have a plugfest at BSDCan on Friday night: http://www.bsdcan.org/2009/schedule/events/144.en.html I'm hoping that folks can bring their various devices and laptops to the occasion. Even if you don't have a Firewire device, swing by with your laptop and see if there's any new information to be gained from your machines. Sean From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 06:50:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B2C5106566C for ; Tue, 24 Mar 2009 06:50:08 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id F15BA8FC19 for ; Tue, 24 Mar 2009 06:50:07 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2221816rvb.43 for ; Mon, 23 Mar 2009 23:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=b0KircyRnXHv+f9a1gzBIzV70WmBQVDE6wXmm+IWwxc=; b=c5c2qN9q7Kml4iDjWGw0bw/qy+ho5BS5C2xVCq9J1qaWK+llvcOJ8SG4aEfBG0i2HJ da+WGCtsO/CSn/N4L3WXo3Rdp1ppO+Xen48o/A64DKPRRVAzH4hGBWBXaGSoJo2btVag A1ulWds5Xp9xEVGKtQ+eKVbiDfOyM6oSEu1Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XOmsF36o14f21XNZjbvouOiAp08BSTXY8TrOsxo49sJiWaq83QW29ZDerVUMzzPNP4 FGrd3Zu/LfmChjKsgQMkehyo/nY3xdcEIMOR+JSclTOFFY0/PrvAq/PsfL7vFp5r79Xo JD1PIJTww7Zq9fuCKFMozWcfP5emOtTaFr1xM= MIME-Version: 1.0 Received: by 10.142.82.6 with SMTP id f6mr3239992wfb.182.1237876108513; Mon, 23 Mar 2009 23:28:28 -0700 (PDT) In-Reply-To: <49710E4F.6020404@delphij.net> References: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> <49710E4F.6020404@delphij.net> Date: Tue, 24 Mar 2009 14:28:28 +0800 Message-ID: <2e566b9e0903232328y45801f76lc6d64acb4fef3dc@mail.gmail.com> From: "Shaowei Wang (wsw)" To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: A patch of HPTIOP driver for 7.1-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 06:50:08 -0000 Hi, delphij The problem about FreeBSD-7.x-amd64's hptiop driver is solved by patching our RAID-manage software (userland utils). The hptrr driver is a soft RAID so a 32-bit compatibility ioctl structure i= s necessary. The hptiop is a hardware RAID controller, the firmware is 32-bit= . I'm not so familiar with FreeBSD's development community. I'm sorry Posting the infomation here. On Sat, Jan 17, 2009 at 6:46 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Shaowei, > > It seems that I can not apply your patch directly, I have tried to do it > manually, as attached, please let me know if it's Ok. I can commit for > you against -HEAD if it looks fine and take care for MFC. > > Note that, however, I am more or less concerned about the driver if > 32-bit utility is running on amd64 platform. There seems to have three > pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and > found that it has defined a 32-bit compatibility ioctl structure. > According to my understanding to hptiop(4), this could be a problem. > > PS. For faster handling it is probably a good idea to submit patch > through our PR system: http://www.freebsd.org/send-pr.html > > Shaowei Wang (wsw) wrote: > > Hi, guys > > > > hptiop driver in the 7.1 release has a little bug. > > Because this issue the Raid-manage GUI program which we provided can NO= T > > work anymore. > > > > So we give the patch: > > > > Index: hptiop.h > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- hptiop.h (revision 186851) > > +++ hptiop.h (working copy) > > @@ -260,7 +260,7 @@ > > unsigned long lpOutBuffer; /* output data buffer */ > > u_int32_t nOutBufferSize; /* size of output data > buffer > > */ > > unsigned long lpBytesReturned; /* count of HPT_U8s return= ed > */ > > -}; > > +}__attribute__((packed)); > > > > #define HPT_IOCTL_FLAG_OPEN 1 > > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > -wsw > > > > > /************************************************************************= / > > > > =E5=A4=A7=E5=AE=B6=E5=A5=BD=EF=BC=9A > > > > hptiop=E7=9A=84=E9=A9=B1=E5=8A=A8=E5=9C=A87.1=E5=8F=91=E8=A1=8C=E7=89= =88=E4=B8=AD=E6=9C=89=E4=B8=AA=E5=B0=8F=E9=94=99=E8=AF=AF=E3=80=82 > > =E8=BF=99=E4=B8=AA=E5=B0=8F=E9=94=99=E8=AF=AF=E5=AF=BC=E8=87=B4=E4=BA= =86=E6=88=91=E4=BB=AC=E6=8F=90=E4=BE=9B=E7=9A=84=E9=98=B5=E5=88=97=E7=AE=A1= =E7=90=86=E7=A8=8B=E5=BA=8F=E6=97=A0=E6=B3=95=E8=BF=90=E8=A1=8C=E3=80=82 > > > > =E6=88=91=E4=BB=AC=E7=BB=99=E5=87=BA=E4=BA=86=E8=A1=A5=E4=B8=81=EF=BC= =9A > > > > Index: hptiop.h > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- hptiop.h (revision 186851) > > +++ hptiop.h (working copy) > > @@ -260,7 +260,7 @@ > > unsigned long lpOutBuffer; /* output data buffer */ > > u_int32_t nOutBufferSize; /* size of output data > buffer > > */ > > unsigned long lpBytesReturned; /* count of HPT_U8s return= ed > */ > > -}; > > +}__attribute__((packed)); > > > > #define HPT_IOCTL_FLAG_OPEN 1 > > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > -wsw > > > > > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > 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" > > > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.10 (FreeBSD) > > iEYEARECAAYFAklxDk4ACgkQi+vbBBjt66CvUQCfaAnk0XQTh3Wrn2O4Dy0pEUFW > oqsAoIvlTSNGRDg71SNyGfZ5VjDh9Z93 > =3D1xSB > -----END PGP SIGNATURE----- > > Index: sys/dev/hptiop/hptiop.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/hptiop/hptiop.h =EF=BC=88=E7=89=88=E6=9C=AC 187338=EF=BC= =89 > +++ sys/dev/hptiop/hptiop.h =EF=BC=88=E5=B7=A5=E4=BD=9C=E5=89=AF=E6= =9C=AC=EF=BC=89 > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output data > buffer */ > unsigned long lpBytesReturned; /* count of HPT_U8s return= ed > */ > -}; > +} __attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 10:13:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575791065670 for ; Tue, 24 Mar 2009 10:13:39 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1F58FC18 for ; Tue, 24 Mar 2009 10:13:38 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1178128qwb.7 for ; Tue, 24 Mar 2009 03:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=pbxRqqr12+sJsPArBHtsI7aiW0tRlPDXykD4WqStyEI=; b=vH1HAc0PMIQtG6l/RNgavdONVwYUZMEelCGyjEVJcr3tdUnvAowW/gjLMollz/HWB1 Rk174c2nMyNbNDBD5olX0EmgDN3WoiCt3nm12T7eBif1+uJWoVpCb5qLykSibJYa8BUu h07rXyL+uwALTm4Bs4wBJ1Cnd1o96drxox+dE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=xaRtnoYtkuIoGzZkjyuIZSsOhEk6+xRG17siulQ3a/bd4+8EC8TS0op6FcELw+3cvN ZM+Zf0MioYNI+WctgBTOiRgANrWB53TS7wJDffUd9DK+dMo0H2AmMq7KMMZ/RQwLClNC wBnr/4n6PsE3sjLt0PNT95uhgq/6qtBbxa5uc= Received: by 10.224.67.212 with SMTP id s20mr10310998qai.294.1237888399237; Tue, 24 Mar 2009 02:53:19 -0700 (PDT) Received: from localhost.localdomain ([213.152.137.43]) by mx.google.com with ESMTPS id 26sm5840594qwa.2.2009.03.24.02.53.16 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 02:53:18 -0700 (PDT) Message-ID: <49C8AD9B.7000500@gmail.com> Date: Tue, 24 Mar 2009 12:53:31 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [problem] aac0 does not respond 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, 24 Mar 2009 10:13:40 -0000 Hello, All Describe my problem: have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 2 HHD of 6 have errors in smart data (damaged) i am try read file /var/db/mysql/ibdata1 from this volume system does not respond ( lost access to ssh ) after read 6GB data from this file and print debug messages on ttyv0 As to prevent the emergence of this problem? As monitor the status of RAID-controller? please, any solutions /Vladimir Ermakov ==========================messages on ttyv0================================== Mar 22 20:20:12 df24 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 50 SECONDS Mar 22 20:20:12 df24 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 50 SECONDS Mar 22 20:20:12 df24 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 50 SECONDS Mar 22 20:20:32 df24 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:32 df24 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:32 df24 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 70 SECONDS Mar 22 20:20:52 df24 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 90 SECONDS Mar 22 20:20:52 df24 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 90 SECONDS Mar 22 20:20:52 df24 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 90 SECONDS Mar 22 20:21:12 df24 kernel: aac0: COMMAND 0xffffffff80859dd0 TIMEOUT AFTER 111 SECONDS Mar 22 20:21:12 df24 kernel: aac0: COMMAND 0xffffffff808599e0 TIMEOUT AFTER 111 SECONDS Mar 22 20:21:12 df24 kernel: aac0: COMMAND 0xffffffff808569c0 TIMEOUT AFTER 111 SECONDS =============================================================== # ls -halt /var/db/mysql/ibdata1 -rw-rw---- 1 88 88 256G Mar 22 23:23 /var/db/mysql/ibdata1 # tar -cf - /var/db/mysql/ibdata1 | pv -br > /dev/null 3.73GB [ 146MB/s] # smartctl -a -d scsi /dev/pass4 smartctl version 5.38 [amd64-portbld-freebsd7.1] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ Device: FUJITSU MAX3147RC Version: 0104 Serial number: xxxxxxxxxxxxxxxxx Device type: <31> Transport protocol: SAS Local Time is: Tue Mar 24 10:07:08 2009 CET Device supports SMART and is Enabled Temperature Warning Enabled SMART Health Status: OK Current Drive Temperature: 21 C Drive Trip Temperature: 65 C Manufactured in week 18 of year 2006 Recommended maximum start stop count: 10000 times Current start stop count: 46 times Error counter log: Errors Corrected by Total Correction Gigabytes Total ECC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 75782 1488 0 0 31950.874 1488 write: 0 567 0 0 0 12148.416 0 verify: 0 17642 960 0 0 10148.962 960 # uname -a FreeBSD sys3 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #1: Mon Nov 3 18:39:49 UTC 2008 root@sys3:/usr/obj/usr/src/sys/SYS3 amd64 # pciconf -lvc *** aac0@pci0:10:0:0: class=0x010400 card=0x02b69005 chip=0x02859005 rev=0x09 hdr=0x00 vendor = 'Adaptec Inc' device = 'AAC-RAID RAID Controller' class = mass storage subclass = RAID cap 01[98] = powerspec 2 supports D0 D1 D3 current D0 cap 05[a0] = MSI supports 2 messages, 64 bit cap 10[d0] = PCI-Express 1 endpoint cap 03[90] = VPD *** # dmesg | grep aac0 aac0: mem 0xb8a00000-0xb8bfffff irq 16 at device 0.0 on pci10 aac0: Enabling 64-bit address support aac0: Enable Raw I/O aac0: Enable 64-bit array aac0: New comm. interface enabled aac0: [ITHREAD] aac0: Adaptec 5805, aac driver 2.0.0-1 aacp0: on aac0 aacp1: on aac0 aacp2: on aac0 aacd0: on aac0 From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 10:50:51 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40780106574A for ; Tue, 24 Mar 2009 10:50:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id BC3438FC1D for ; Tue, 24 Mar 2009 10:50:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz8 with SMTP id 8so2027922bwz.43 for ; Tue, 24 Mar 2009 03:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=kMOp22vdK7a8/M6zybOTHr9L5fw1pgaWDRUnuMgaZro=; b=JIdAdFeQ/q8yU9JxLcj/itIwh78ywLbi7IXJrFJjPc8OfrGqI95GsCD6bKj+BMBfZG SZTivQYOMIUVHm0bEYo1fjX4PMGSScSntoGxFyAap9K6ZAlg844qFz+81Hkbejr/mNPf AhHNW1jsLFhdbF8T73HIGteNGME5JKy8sRM04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vzmk2cWNllNSKWPX3UlfqPwIBg5vwCQiHxBzwZtMrcNIGHBOPxbANPR/9jniWORS57 xHqavYLHgSBd/Y7Bp+Db2RA8ZZBlf2I9E98TXP5B9IR0vd4VaRsgsflecZ+pVMcGmlsx wftNHZ6jnRP8Cqr3+Cd7KonEFByidyNSC/3t4= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.108.211 with SMTP id g19mr6931155fap.39.1237890276646; Tue, 24 Mar 2009 03:24:36 -0700 (PDT) In-Reply-To: <49C8AD9B.7000500@gmail.com> References: <49C8AD9B.7000500@gmail.com> Date: Tue, 24 Mar 2009 11:24:36 +0100 X-Google-Sender-Auth: 1634396cbda040bb Message-ID: <3bbf2fe10903240324t6616cc9dx6ae28028ac971be6@mail.gmail.com> From: Attilio Rao To: Vladimir Ermakov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [problem] aac0 does not respond 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, 24 Mar 2009 10:50:51 -0000 2009/3/24 Vladimir Ermakov : > Hello, All > > Describe my problem: > have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 > 2 HHD of 6 =C2=A0have errors in smart data (damaged) > i am try read file /var/db/mysql/ibdata1 from this volume > system does not respond ( lost access to ssh ) after read 6GB data from t= his > file > and print debug messages on ttyv0 > > As to prevent the emergence of this problem? > As monitor the status of RAID-controller? > > please, any solutions Is this -STABLE or -CURRENT? And if it is -CURRENT, what revision? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 11:09:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8571C1065687 for ; Tue, 24 Mar 2009 11:09:29 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id AA1598FC22 for ; Tue, 24 Mar 2009 11:09:28 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 3033 invoked from network); 24 Mar 2009 11:09:27 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 24 Mar 2009 11:09:27 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id AF9531031D; Tue, 24 Mar 2009 11:09:26 +0000 (UTC) Date: Tue, 24 Mar 2009 11:09:26 +0000 From: n0g0013 To: Boris Kochergin Message-ID: <20090324110926.GA14099@holyman.cobbled.net> Mail-Followup-To: Boris Kochergin , freebsd-hackers@freebsd.org References: <49C6F4F4.5030609@acm.poly.edu> <20090323124502.GA8686@holyman.cobbled.net> <49C79A9B.9070309@acm.poly.edu> <20090323155433.GA24517@holyman.cobbled.net> <49C7B793.1090308@acm.poly.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <49C7B793.1090308@acm.poly.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Doing away with NGROUPS_MAX in src/sys/sys/syslimits.h? 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, 24 Mar 2009 11:09:30 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 23.03-12:23, Boris Kochergin wrote: [ ... ] > >yes, that's great but you may be surprised to learn that it doesn't > >actually solve your problem. i think (and without looking > >specifically at the impact my even be confident enough to say > >definately) if you get a groups list it will only be cropped and the > >error message is being erroneously avoided, not corrected. i'd also > >suggest that you may be opening up your system to some overflows > >although, generally, the code sections use the same limits and so > >you might get away with it. [ ... ] > On my 7.0 system, and a kernel recompiled with NGROUPS_MAX set to 64, a > getgrouplist() call for a user who is in more than 16 groups (24, to be > exact) will populate the array specified by the "gid_t *groups" argument > with the 24 groups the user is in, in addition to the group specified in > the "gid_t basegid" argument. The value of the variable specified in the > "int *ngroups" will also be 25, and the getgrouplist() call will return > 0. So, as far as being a hack for a specific problem, it seems to work > properly. yeah, looked at it now. NGROUPS is defined from NGROUPS_MAX (bad memory). the other significant values would be KI_NGROUPS which is not defined from NGROUPS_MAX; neither are the IPC or RPC relevant values, although, as i said they use their own max values for validation (i.e. they don't suddenly using NGROUPS_MAX instead of CMGROUPS) so probably won't overflow trivially but i wouldn't say they are necissarily safe. suffice to say if it works for you great but be aware that you may have security and other issues associated with the change. [ ... ] > Sure, I'll test the patch. Can you point me at it? sure, attached. but note it's functionally zero progress, it only looks to remove the dependancy on NGROUPS_MAX as static definition and make SC_NGROUPS_MAX a writable and referenced value. however, it won't currently give you the extra groups you want because it defines other values from _NGROUP_COMPAT (which is 16) until i can complete the changes to a stable state. it would still be nice to know that i haven't messed it up completely and that, at the very least the system still boots and runs with it. p.s: i've gotta finish some bloody web stuff and then i'll throw some more time at it this afternoon. -- t t w --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="remove-ngroups_max,v1r2.patch" Index: contrib/openpam/lib/openpam_borrow_cred.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_borrow_cred.c,v retrieving revision 1.1.1.9 diff -b -u -r1.1.1.9 openpam_borrow_cred.c --- contrib/openpam/lib/openpam_borrow_cred.c 21 Dec 2007 11:49:29 -0000 1.1.1.9 +++ contrib/openpam/lib/openpam_borrow_cred.c 4 Feb 2009 16:38:46 -0000 @@ -60,6 +60,7 @@ struct pam_saved_cred *scred; const void *scredp; int r; + int ngroups ; ENTERI(pwd->pw_uid); r = pam_get_data(pamh, PAM_SAVED_CRED, &scredp); @@ -73,26 +74,55 @@ (int)geteuid()); RETURNC(PAM_PERM_DENIED); } - scred = calloc(1, sizeof *scred); - if (scred == NULL) - RETURNC(PAM_BUF_ERR); - scred->euid = geteuid(); - scred->egid = getegid(); - r = getgroups(NGROUPS_MAX, scred->groups); - if (r < 0) { - FREE(scred); - RETURNC(PAM_SYSTEM_ERR); - } - scred->ngroups = r; +/* get the maximum number of system groups */ +#if _POSIX_VERSION > 199212 + ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + ngroups = NGROUPS_MAX ; +#else + ngroups = _NGROUPS_COMPAT ; +#endif +/* initally allocate enough memory for max_groups */ + scred = malloc( sizeof(struct pam_saved_cred) + + ngroups*sizeof(gid_t) ) ; + if( scred == NULL ) + RETURNC( PAM_BUF_ERR ) ; +/* set the save values */ + scred->euid = geteuid() ; + scred->egid = getegid() ; +/* save groups into our (probably) oversized memory allocation */ + r = getgroups( ngroups, scred->groups ) ; + if( r < 0 ) { + FREE( scred ) ; /* call PAM's free macro */ + RETURNC( PAM_SYSTEM_ERR ) ; + } ; + scred->ngroups = r ; + ngroups = r < ngroups ? r : ngroups ; /* choose the smallest */ + /* ... number of groups to allocate */ + ngroups = ngroups < _NGROUPS_COMPAT ? ngroups : _NGROUPS_COMPAT ; + /* but keep it within expected minimum value */ + /* XXX: we don't really want this but until we get + * educated on the implications this is probably safe + * and certainaly compatible */ +/* realloc, releasing unneeded memory */ + scred = realloc( (void*)scred, + sizeof(struct pam_saved_cred)+ngroups*sizeof(gid_t) ) ; + /* nb: we ignore failure and try to store the larger + * ... structure as initially requested. catching the + * ... error in 'pam_set_data' if neccessary. */ +/* save the credentials to PAM user data area */ r = pam_set_data(pamh, PAM_SAVED_CRED, scred, &openpam_free_data); if (r != PAM_SUCCESS) { FREE(scred); RETURNC(r); } +/* set the new credentials */ if (geteuid() == pwd->pw_uid) RETURNC(PAM_SUCCESS); if (initgroups(pwd->pw_name, pwd->pw_gid) < 0 || - setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0) { + setegid(pwd->pw_gid) < 0 || seteuid(pwd->pw_uid) < 0) + { + /* if any of the set calls failed, then restore and fail */ openpam_restore_cred(pamh); RETURNC(PAM_SYSTEM_ERR); } Index: contrib/openpam/lib/openpam_impl.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/contrib/openpam/lib/openpam_impl.h,v retrieving revision 1.1.1.17 diff -b -u -r1.1.1.17 openpam_impl.h --- contrib/openpam/lib/openpam_impl.h 21 Dec 2007 11:49:29 -0000 1.1.1.17 +++ contrib/openpam/lib/openpam_impl.h 5 Feb 2009 15:41:19 -0000 @@ -110,13 +110,17 @@ int env_size; }; -#ifdef NGROUPS_MAX +#if _POSIX_VERSION > 199212 #define PAM_SAVED_CRED "pam_saved_cred" struct pam_saved_cred { uid_t euid; gid_t egid; - gid_t groups[NGROUPS_MAX]; int ngroups; + gid_t groups[]; + /* keep this last so that we can simply + .. over-allocate the amount of space + .. nb: don't use sizeof' unless you adjust + .. for the number of groups */ }; #endif Index: include/rpc/auth_unix.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/include/rpc/auth_unix.h,v retrieving revision 1.11 diff -b -u -r1.11 auth_unix.h --- include/rpc/auth_unix.h 23 Mar 2002 17:24:55 -0000 1.11 +++ include/rpc/auth_unix.h 14 Jan 2009 11:15:21 -0000 @@ -52,7 +52,7 @@ #define MAX_MACHINE_NAME 255 /* gids compose part of a credential; there may not be more than 16 of them */ -#define NGRPS 16 +#define AUTH_UNIX_NGROUPS 16 /* * Unix style credentials. Index: lib/libc/rpc/auth_unix.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/auth_unix.c,v retrieving revision 1.18 diff -b -u -r1.18 auth_unix.c --- lib/libc/rpc/auth_unix.c 14 Jun 2007 20:07:35 -0000 1.18 +++ lib/libc/rpc/auth_unix.c 4 Feb 2009 15:31:57 -0000 @@ -182,27 +182,48 @@ * Returns an auth handle with parameters determined by doing lots of * syscalls. */ -AUTH * +AUTH* authunix_create_default() { - int len; char machname[MAXHOSTNAMELEN + 1]; + AUTH* auth_unix ; uid_t uid; gid_t gid; - gid_t gids[NGROUPS_MAX]; - - if (gethostname(machname, sizeof machname) == -1) - abort(); - machname[sizeof(machname) - 1] = 0; + gid_t *gids ; + uint ngroups ; + uint max_ngroups ; + +/* get hostname or fail */ + if( gethostname(machname,sizeof(machname)) == -1 ) + abort() ; + machname[sizeof(machname)-1] = 0 ; /* add a null terminator */ +/* set uid/gid from current effective values */ uid = geteuid(); gid = getegid(); - if ((len = getgroups(NGROUPS_MAX, gids)) < 0) - abort(); - if (len > NGRPS) - len = NGRPS; - /* XXX: interface problem; those should all have been unsigned */ - return (authunix_create(machname, (int)uid, (int)gid, len, - (int *)gids)); +/* set the group set */ +#if _POSIX_VERSION > 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = 16 ; +#endif + gids = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( gids == NULL ) + abort () ; + if( (ngroups=getgroups(max_ngroups,gids)) < 0 ) { + free( gids ) ; + abort() ; + } +/* clip the groups to a transmissable size */ + if( ngroups > AUTH_UNIX_NGROUPS ) + ngroups = AUTH_UNIX_NGROUPS ; +/* XXX: interface problem; those should all have been unsigned */ + auth_unix = authunix_create( machname, + (int)uid, (int)gid, (int)ngroups, + (int*)gids ) ; + free( (void*)gids ) ; + return( auth_unix ) ; } /* Index: lib/libc/rpc/authunix_prot.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/authunix_prot.c,v retrieving revision 1.10 diff -b -u -r1.10 authunix_prot.c --- lib/libc/rpc/authunix_prot.c 20 Nov 2007 01:51:20 -0000 1.10 +++ lib/libc/rpc/authunix_prot.c 4 Feb 2009 16:03:29 -0000 @@ -67,13 +67,14 @@ paup_gids = &p->aup_gids; - if (xdr_u_long(xdrs, &(p->aup_time)) - && xdr_string(xdrs, &(p->aup_machname), MAX_MACHINE_NAME) - && xdr_int(xdrs, &(p->aup_uid)) - && xdr_int(xdrs, &(p->aup_gid)) - && xdr_array(xdrs, (char **) paup_gids, - &(p->aup_len), NGRPS, sizeof(int), (xdrproc_t)xdr_int) ) { - return (TRUE); + if( xdr_u_long(xdrs,&(p->aup_time)) && + xdr_string(xdrs,&(p->aup_machname),MAX_MACHINE_NAME) && + xdr_int(xdrs,&(p->aup_uid)) && + xdr_int(xdrs,&(p->aup_gid)) && + xdr_array(xdrs,(char**)paup_gids,&(p->aup_len), + AUTH_UNIX_NGROUPS,sizeof(int),(xdrproc_t)xdr_int) ) + { + return( TRUE ) ; } - return (FALSE); + return( FALSE ) ; } Index: lib/libc/rpc/netname.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/netname.c,v retrieving revision 1.8 diff -b -u -r1.8 netname.c --- lib/libc/rpc/netname.c 16 Oct 2004 06:11:35 -0000 1.8 +++ lib/libc/rpc/netname.c 14 Jan 2009 01:29:47 -0000 @@ -61,6 +61,7 @@ #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 256 #endif + #ifndef NGROUPS #define NGROUPS 16 #endif Index: lib/libc/rpc/netnamer.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/netnamer.c,v retrieving revision 1.12 diff -b -u -r1.12 netnamer.c --- lib/libc/rpc/netnamer.c 10 Mar 2005 00:58:21 -0000 1.12 +++ lib/libc/rpc/netnamer.c 3 Feb 2009 17:55:48 -0000 @@ -69,7 +69,6 @@ #ifndef NGROUPS #define NGROUPS 16 #endif - /* * Convert network-name into unix credential */ @@ -104,7 +103,7 @@ return (0); } *gidp = (gid_t) atol(p); - for (gidlen = 0; gidlen < NGROUPS; gidlen++) { + for (gidlen = 0; gidlen < _NGROUPS_RPC_MAX; gidlen++) { p = strsep(&res, "\n,"); if (p == NULL) break; @@ -157,7 +156,7 @@ static int _getgroups(uname, groups) char *uname; - gid_t groups[NGROUPS]; + gid_t groups[_NGROUPS_RPC_MAX]; { gid_t ngroups = 0; struct group *grp; @@ -169,10 +168,11 @@ while ((grp = getgrent())) { for (i = 0; grp->gr_mem[i]; i++) if (!strcmp(grp->gr_mem[i], uname)) { - if (ngroups == NGROUPS) { + if( ngroups == _NGROUPS_RPC_MAX ) { #ifdef DEBUG - fprintf(stderr, - "initgroups: %s is in too many groups\n", uname); + fprintf( stderr, + "initgroups: %s is in too many groups\n", + uname ) ; #endif goto toomany; } Index: lib/libc/rpc/svc_auth_des.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/svc_auth_des.c,v retrieving revision 1.9 diff -b -u -r1.9 svc_auth_des.c --- lib/libc/rpc/svc_auth_des.c 22 Mar 2002 23:18:37 -0000 1.9 +++ lib/libc/rpc/svc_auth_des.c 3 Feb 2009 17:51:01 -0000 @@ -452,7 +452,7 @@ short uid; /* cached uid */ short gid; /* cached gid */ short grouplen; /* length of cached groups */ - short groups[NGROUPS]; /* cached groups */ + short groups[_NGROUPS_RPC_MAX]; /* cached groups */ }; /* Index: lib/libc/rpc/svc_auth_unix.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/libc/rpc/svc_auth_unix.c,v retrieving revision 1.11 diff -b -u -r1.11 svc_auth_unix.c --- lib/libc/rpc/svc_auth_unix.c 16 Oct 2004 06:11:35 -0000 1.11 +++ lib/libc/rpc/svc_auth_unix.c 4 Feb 2009 16:04:10 -0000 @@ -68,7 +68,7 @@ struct area { struct authunix_parms area_aup; char area_machname[MAX_MACHINE_NAME+1]; - int area_gids[NGRPS]; + int area_gids[AUTH_UNIX_NGROUPS] ; } *area; u_int auth_len; size_t str_len, gid_len; @@ -98,7 +98,7 @@ aup->aup_uid = (int)IXDR_GET_INT32(buf); aup->aup_gid = (int)IXDR_GET_INT32(buf); gid_len = (size_t)IXDR_GET_U_INT32(buf); - if (gid_len > NGRPS) { + if( gid_len > AUTH_UNIX_NGROUPS ) { stat = AUTH_BADCRED; goto done; } Index: lib/librpcsec_gss/svc_rpcsec_gss.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/lib/librpcsec_gss/svc_rpcsec_gss.c,v retrieving revision 1.4 diff -b -u -r1.4 svc_rpcsec_gss.c --- lib/librpcsec_gss/svc_rpcsec_gss.c 3 Nov 2008 10:38:00 -0000 1.4 +++ lib/librpcsec_gss/svc_rpcsec_gss.c 5 Feb 2009 16:09:37 -0000 @@ -127,7 +127,7 @@ rpc_gss_ucred_t cl_ucred; /* unix-style credentials */ bool_t cl_done_callback; /* TRUE after call */ void *cl_cookie; /* user cookie from callback */ - gid_t cl_gid_storage[NGRPS]; + gid_t cl_gid_storage[AUTH_UNIX_NGROUPS]; gss_OID cl_mech; /* mechanism */ gss_qop_t cl_qop; /* quality of protection */ u_int cl_seq; /* current sequence number */ @@ -578,7 +578,7 @@ getpwuid_r(uid, &pwd, buf, sizeof(buf), &pw); if (pw) { - int len = NGRPS; + int len = AUTH_UNIX_NGROUPS; uc->uid = pw->pw_uid; uc->gid = pw->pw_gid; uc->gidlist = client->cl_gid_storage; Index: sys/compat/svr4/svr4_misc.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/compat/svr4/svr4_misc.c,v retrieving revision 1.101 diff -b -u -r1.101 svr4_misc.c --- sys/compat/svr4/svr4_misc.c 21 Apr 2008 21:24:08 -0000 1.101 +++ sys/compat/svr4/svr4_misc.c 14 Jan 2009 11:58:47 -0000 @@ -710,7 +710,12 @@ *retval = 0; break; case SVR4_CONFIG_NGROUPS: - *retval = NGROUPS_MAX; + *retval = _NGROUPS_COMPAT; + /* XXX: this should pull the value + * from sysctl but i cannot find + * the definitions for the similar + * varaibles here (i.e. 'maxproc') + */ break; case SVR4_CONFIG_CHILD_MAX: *retval = maxproc; Index: sys/fs/portalfs/portal.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/fs/portalfs/portal.h,v retrieving revision 1.10 diff -b -u -r1.10 portal.h --- sys/fs/portalfs/portal.h 6 Jan 2005 18:10:40 -0000 1.10 +++ sys/fs/portalfs/portal.h 16 Jan 2009 23:44:50 -0000 @@ -43,7 +43,7 @@ int pcr_flag; /* File open mode */ uid_t pcr_uid; /* From ucred */ short pcr_ngroups; /* From ucred */ - gid_t pcr_groups[NGROUPS]; /* From ucred */ + gid_t pcr_groups[_NGROUPS_COMPAT]; /* From ucred */ }; #ifdef _KERNEL Index: sys/i386/ibcs2/ibcs2_misc.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/i386/ibcs2/ibcs2_misc.c,v retrieving revision 1.70 diff -b -u -r1.70 ibcs2_misc.c --- sys/i386/ibcs2/ibcs2_misc.c 13 Jan 2008 14:44:07 -0000 1.70 +++ sys/i386/ibcs2/ibcs2_misc.c 14 Jan 2009 12:24:56 -0000 @@ -659,14 +659,14 @@ struct thread *td; struct ibcs2_getgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t iset[_NGROUPS_COMPAT]; + gid_t gp[_NGROUPS_COMPAT]; u_int i, ngrp; int error; if (uap->gidsetsize < 0) return (EINVAL); - ngrp = MIN(uap->gidsetsize, NGROUPS_MAX); + ngrp = MIN(uap->gidsetsize, _NGROUPS_COMPAT); error = kern_getgroups(td, &ngrp, gp); if (error) return (error); @@ -685,11 +685,11 @@ struct thread *td; struct ibcs2_setgroups_args *uap; { - ibcs2_gid_t iset[NGROUPS_MAX]; - gid_t gp[NGROUPS_MAX]; + ibcs2_gid_t iset[_NGROUPS_COMPAT]; + gid_t gp[_NGROUPS_COMPAT]; int error, i; - if (uap->gidsetsize < 0 || uap->gidsetsize > NGROUPS_MAX) + if (uap->gidsetsize < 0 || uap->gidsetsize > _NGROUPS_COMPAT) return (EINVAL); if (uap->gidsetsize && uap->gidset) { error = copyin(uap->gidset, iset, sizeof(ibcs2_gid_t) * @@ -789,8 +789,13 @@ return 0; case IBCS2_SC_NGROUPS_MAX: - mib[1] = KERN_NGROUPS; - break; + /* XXX: IBCS2 compat with group limits not known to + * me, so i'll just return a compatibile/safe limit + * for now */ + PROC_LOCK(p) ; + td->td_retval[0] = _NGROUPS_COMPAT ; + PROC_UNLOCK(p) ; + return( 0 ) ; case IBCS2_SC_OPEN_MAX: PROC_LOCK(p); Index: sys/kern/kern_mib.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/kern/kern_mib.c,v retrieving revision 1.93 diff -b -u -r1.93 kern_mib.c --- sys/kern/kern_mib.c 28 Jan 2009 19:58:05 -0000 1.93 +++ sys/kern/kern_mib.c 4 Feb 2009 13:15:06 -0000 @@ -124,8 +124,8 @@ SYSCTL_INT(_kern, KERN_POSIX1, posix1version, CTLFLAG_RD, 0, _POSIX_VERSION, "Version of POSIX attempting to comply to"); -SYSCTL_INT(_kern, KERN_NGROUPS, ngroups, CTLFLAG_RD, - 0, NGROUPS_MAX, "Maximum number of groups a user can belong to"); +SYSCTL_INT(_kern, KERN_NGROUPS, ngroups, CTLFLAG_RW, + 0, _NGROUPS_COMPAT, "Maximum number of groups allocated to a user"); SYSCTL_INT(_kern, KERN_JOB_CONTROL, job_control, CTLFLAG_RD, 0, 1, "Whether job control is available"); Index: sys/sys/param.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/sys/param.h,v retrieving revision 1.382 diff -b -u -r1.382 param.h --- sys/sys/param.h 28 Jan 2009 17:57:16 -0000 1.382 +++ sys/sys/param.h 4 Feb 2009 14:11:55 -0000 @@ -57,7 +57,7 @@ * is created, otherwise 1. */ #undef __FreeBSD_version -#define __FreeBSD_version 800062 /* Master, propagated to newvers */ +#define __FreeBSD_version 800060 /* Master, propagated to newvers */ #ifndef LOCORE #include @@ -77,7 +77,8 @@ #define MAXLOGNAME 17 /* max login name length (incl. NUL) */ #define MAXUPRC CHILD_MAX /* max simultaneous processes */ #define NCARGS ARG_MAX /* max bytes for an exec function */ -#define NGROUPS NGROUPS_MAX /* max number groups */ +#define NGROUPS _NGROUPS_COMPAT + /* depreciated check sysctl/sysconf for NGROUPS_MAX value instead */ #define NOFILE OPEN_MAX /* max open files per process */ #define NOGROUP 65535 /* marker for empty group set member */ #define MAXHOSTNAMELEN 256 /* max hostname size */ Index: sys/sys/syslimits.h =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/sys/sys/syslimits.h,v retrieving revision 1.23 diff -b -u -r1.23 syslimits.h --- sys/sys/syslimits.h 29 May 2007 15:14:46 -0000 1.23 +++ sys/sys/syslimits.h 3 Feb 2009 18:02:22 -0000 @@ -54,7 +54,6 @@ #define MAX_CANON 255 /* max bytes in term canon input line */ #define MAX_INPUT 255 /* max bytes in terminal input */ #define NAME_MAX 255 /* max bytes in a file name */ -#define NGROUPS_MAX 16 /* max supplemental group id's */ #ifndef OPEN_MAX #define OPEN_MAX 64 /* max open files per process */ #endif @@ -66,9 +65,35 @@ * We leave the following values undefined to force applications to either * assume conservative values or call sysconf() to get the current value. * - * HOST_NAME_MAX + * HOST_NAME_MAX NGROUPS_MAX * * (We should do this for most of the values currently defined here, * but many programs are not prepared to deal with this yet.) */ +/* + * here are some reference values in respect of the obsoleted + * NGROUPS_MAX value. + * nb: some apps appear to check NGROUPS_MAX as meaning that + * ... system has user groups (i.e. to #ifdef chunks of code). + * ... this is easy to change but maybe historically defined? + */ +#define _NGROUPS_RPC_MAX 16 /* reference only */ + /* nb: this is the old system max, so named + * ... because it's limit appears to + * ... have been derived from a limitation + * ... in RPC (and thereby NFS), where it's + * ... the max number of groups we can exchange */ +#define _NGROUPS_COMPAT _NGROUPS_RPC_MAX /* reference only */ + /* nb: although this is defined as equal to the rpc + * ... limit, i have defined it distintly so that + * ... we may distinguish (whilst updating) usage + * ... that is correctly explicit (i.e. should be 16) + * ... and usage that is only 16 because of an expected + * ... convention. hopefully we may remove these and + * ... define additional _NGROUPS_*_MAX for those defined + * ... uses. */ +#define _NGROUPS_SYS_MAX 65536 /* reference only */ + /* nb: the idea's to have this extensible + * ... indefinately, this is what linux have and + * ... should more than cover immediate needs */ #endif Index: usr.bin/catman/catman.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.bin/catman/catman.c,v retrieving revision 1.14 diff -b -u -r1.14 catman.c --- usr.bin/catman/catman.c 5 Dec 2005 14:22:12 -0000 1.14 +++ usr.bin/catman/catman.c 8 Feb 2009 22:51:44 -0000 @@ -93,8 +93,9 @@ enum Ziptype {NONE, BZIP, GZIP}; static uid_t uid; -static gid_t gids[NGROUPS_MAX]; +static gid_t *gids; static int ngids; +static int max_ngroups ; static int starting_dir; static char tmp_file[MAXPATHLEN]; struct stat test_st; @@ -789,7 +790,15 @@ /* NOTREACHED */ } } - ngids = getgroups(NGROUPS_MAX, gids); +/* allocate memory for group ids */ +#if _POSIX_VERSION > 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + ngids = getgroups( max_ngroups, gids ) ; if ((starting_dir = open(".", 0)) < 0) { err(1, "."); } Index: usr.bin/newgrp/newgrp.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.bin/newgrp/newgrp.c,v retrieving revision 1.2 diff -b -u -r1.2 newgrp.c --- usr.bin/newgrp/newgrp.c 30 Oct 2003 15:14:34 -0000 1.2 +++ usr.bin/newgrp/newgrp.c 9 Feb 2009 22:05:53 -0000 @@ -146,9 +146,10 @@ static void addgroup(const char *grpname) { - gid_t grps[NGROUPS_MAX]; + gid_t *grps; long lgid; - int dbmember, i, ngrps; + int dbmember, i, ngrps, max_ngroups ; + /* XXX: should 'max_ngroups' be a static const variable? */ gid_t egid; struct group *grp; char *ep, *pass; @@ -185,9 +186,21 @@ } } - if ((ngrps = getgroups(NGROUPS_MAX, (gid_t *)grps)) < 0) { +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + grps = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( grps == NULL ) { + warn( "group set memory allocation" ) ; + return ; + } + if( (ngrps=getgroups(max_ngroups,(gid_t*)grps)) < 0 ) { warn("getgroups"); - return; + goto error_free ; } /* Remove requested gid from supp. list if it exists. */ @@ -201,7 +214,7 @@ if (setgroups(ngrps, (const gid_t *)grps) < 0) { PRIV_END; warn("setgroups"); - return; + goto error_free ; } PRIV_END; } @@ -210,14 +223,14 @@ if (setgid(grp->gr_gid)) { PRIV_END; warn("setgid"); - return; + goto error_free ; } PRIV_END; grps[0] = grp->gr_gid; /* Add old effective gid to supp. list if it does not exist. */ if (egid != grp->gr_gid && !inarray(egid, grps, ngrps)) { - if (ngrps == NGROUPS_MAX) + if( ngrps == max_ngroups ) warnx("too many groups"); else { grps[ngrps++] = egid; @@ -225,12 +238,15 @@ if (setgroups(ngrps, (const gid_t *)grps)) { PRIV_END; warn("setgroups"); - return; + goto error_free ; } PRIV_END; } } +error_free: + free( grps ) ; + return ; } static int Index: usr.sbin/chown/chown.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/chown/chown.c,v retrieving revision 1.29 diff -b -u -r1.29 chown.c --- usr.sbin/chown/chown.c 7 Aug 2004 04:19:37 -0000 1.29 +++ usr.sbin/chown/chown.c 8 Feb 2009 16:22:31 -0000 @@ -269,7 +269,8 @@ { static uid_t euid = -1; static int ngroups = -1; - gid_t groups[NGROUPS_MAX]; + static int max_groups ; + gid_t *groups; /* Check for chown without being root. */ if (errno != EPERM || (uid != (uid_t)-1 && @@ -279,16 +280,31 @@ } /* Check group membership; kernel just returns EPERM. */ +#if _POSIX_VERSION >= 199212 + max_groups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_groups = NGROUPS_MAX ; +#else + max_groups = _NGROUPS_COMPAT ; +#endif + groups = (gid_t*)calloc( max_groups, sizeof(gid_t) ) ; + if( groups == NULL ) { + warnx( "failed to allocate memory for group set" ) ; + goto exit_cleanup ; + } if (gid != (gid_t)-1 && ngroups == -1 && euid == (uid_t)-1 && (euid = geteuid()) != 0) { - ngroups = getgroups(NGROUPS_MAX, groups); + ngroups = getgroups( max_groups, groups ) ; while (--ngroups >= 0 && gid != groups[ngroups]); if (ngroups < 0) { warnx("you are not a member of group %s", gname); - return; + goto exit_cleanup ; } } warn("%s", file); +exit_cleanup: + free( groups ) ; + return ; } void Index: usr.sbin/chroot/chroot.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/chroot/chroot.c,v retrieving revision 1.11 diff -b -u -r1.11 chroot.c --- usr.sbin/chroot/chroot.c 7 Aug 2004 04:19:37 -0000 1.11 +++ usr.sbin/chroot/chroot.c 5 Feb 2009 23:29:48 -0000 @@ -59,6 +59,7 @@ char *user; /* user to switch to before running program */ char *group; /* group to switch to ... */ char *grouplist; /* group list to switch to ... */ +int max_ngroups; /* max number of groups allowable */ int main(argc, argv) @@ -69,12 +70,25 @@ struct passwd *pw; char *endp, *p; const char *shell; - gid_t gid, gidlist[NGROUPS_MAX]; + gid_t gid, *gidlist ; uid_t uid; - int ch, gids; + int ch, gids ; +/* set some defaults */ gid = 0; uid = 0; + user = NULL ; + group = NULL ; + grouplist = NULL ; +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + +/* process command line options */ while ((ch = getopt(argc, argv, "G:g:u:")) != -1) { switch(ch) { case 'u': @@ -103,9 +117,12 @@ if (argc < 1) usage(); +/* if a group argument was passed then process it */ if (group != NULL) { + /* if the first char's a digit then assume it's a gid ... */ if (isdigit((unsigned char)*group)) { gid = (gid_t)strtoul(group, &endp, 0); + /* ... and back out that assumption if it proves wrong */ if (*endp != '\0') goto getgroup; } else { @@ -117,8 +134,15 @@ } } - for (gids = 0; - (p = strsep(&grouplist, ",")) != NULL && gids < NGROUPS_MAX; ) { +/* process command line group list */ + if( grouplist != NULL ) { + gidlist = (gid_t*)calloc( max_ngroups, sizeof(gid_t) ) ; + if( gidlist == NULL ) + errx( 1, "inadquate memory for group list" ) ; + for( gids = 0 ; + gids < max_ngroups && + (p=strsep(&grouplist,",")) != NULL ; ) + { if (*p == '\0') continue; @@ -135,9 +159,11 @@ } gids++; } - if (p != NULL && gids == NGROUPS_MAX) + if( p != NULL && gids == max_ngroups ) errx(1, "too many supplementary groups provided"); + } +/* set user from command line option, if supplied */ if (user != NULL) { if (isdigit((unsigned char)*user)) { uid = (uid_t)strtoul(user, &endp, 0); @@ -152,9 +178,11 @@ } } +/* change root */ if (chdir(argv[0]) == -1 || chroot(".") == -1) err(1, "%s", argv[0]); +/* set credentials */ if (gids && setgroups(gids, gidlist) == -1) err(1, "setgroups"); if (group && setgid(gid) == -1) @@ -162,11 +190,14 @@ if (user && setuid(uid) == -1) err(1, "setuid"); +/* exec the remaining arguments as the chroot'd command ... */ if (argv[1]) { execvp(argv[1], &argv[1]); err(1, "%s", argv[1]); + /* NOTREACHED */ } +/* ... or execute the default system shell */ if (!(shell = getenv("SHELL"))) shell = _PATH_BSHELL; execlp(shell, shell, "-i", (char *)NULL); Index: usr.sbin/gssd/gssd.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/gssd/gssd.c,v retrieving revision 1.1 diff -b -u -r1.1 gssd.c --- usr.sbin/gssd/gssd.c 3 Nov 2008 10:38:00 -0000 1.1 +++ usr.sbin/gssd/gssd.c 5 Feb 2009 16:16:37 -0000 @@ -464,8 +464,8 @@ result->uid = uid; getpwuid_r(uid, &pwd, buf, sizeof(buf), &pw); if (pw) { - int len = NGRPS; - int groups[NGRPS]; + int len = AUTH_UNIX_NGROUPS ; + int groups[AUTH_UNIX_NGROUPS] ; result->gid = pw->pw_gid; getgrouplist(pw->pw_name, pw->pw_gid, groups, &len); Index: usr.sbin/mount_portalfs/cred.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/mount_portalfs/cred.c,v retrieving revision 1.1 diff -b -u -r1.1 cred.c --- usr.sbin/mount_portalfs/cred.c 11 Mar 2005 08:39:58 -0000 1.1 +++ usr.sbin/mount_portalfs/cred.c 16 Jan 2009 23:49:36 -0000 @@ -46,7 +46,7 @@ set_user_credentials(struct portal_cred *user, struct portal_cred *save) { save->pcr_uid = geteuid(); - if ((save->pcr_ngroups = getgroups(NGROUPS_MAX, save->pcr_groups)) < 0) + if( (save->pcr_ngroups=getgroups(_NGROUPS_COMPAT,save->pcr_groups)) < 0 ) return (-1); if (setgroups(user->pcr_ngroups, user->pcr_groups) < 0) return (-1); Index: usr.sbin/pppd/options.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/pppd/options.c,v retrieving revision 1.26 diff -b -u -r1.26 options.c --- usr.sbin/pppd/options.c 7 Nov 2007 10:53:38 -0000 1.26 +++ usr.sbin/pppd/options.c 10 Feb 2009 09:11:47 -0000 @@ -72,10 +72,6 @@ char *strdup(char *); #endif -#ifndef GIDSET_TYPE -#define GIDSET_TYPE gid_t -#endif - /* * Option variables and default values. */ @@ -779,23 +775,64 @@ int fd; { uid_t uid; - int ngroups, i; + int ngroups, max_ngroups, i; struct stat sbuf; - GIDSET_TYPE groups[NGROUPS_MAX]; + gid_t *groups; +/* get the uid */ uid = getuid(); +/* ... and return true if root */ +/* XXX: needs credential check */ if (uid == 0) return 1; + +/* if we're not root, get some info about the file */ if (fstat(fd, &sbuf) != 0) return 0; + +/* test for owner match with current process */ if (sbuf.st_uid == uid) return sbuf.st_mode & S_IRUSR; +/* ... and a group match */ if (sbuf.st_gid == getgid()) return sbuf.st_mode & S_IRGRP; - ngroups = getgroups(NGROUPS_MAX, groups); - for (i = 0; i < ngroups; ++i) - if (sbuf.st_gid == groups[i]) - return sbuf.st_mode & S_IRGRP; + +/* if we've still no luck then check the group list for permission match */ +#if _POSIX_VERSION >= 199212 + max_ngroups = sysconf( _SC_NGROUPS_MAX ) ; +#elif defined(NGROUPS_MAX) + max_ngroups = NGROUPS_MAX ; +#else + max_ngroups = _NGROUPS_COMPAT ; +#endif + groups = (gid_t*) calloc( max_ngroups, sizeof(gid_t) ) ; + if( groups == NULL ) { + /* if we cannot check groups correctly then assume 'fd' is unreadable + * XXX: this may be false as the converse is more likely. + * i.e. it would be failed readable on available groups + * and granted on full list, however, we just can't be + * psychic and i'm not about to code some idiotic loop that tries + * to get 'some' memory for partial testing. probably a better + * recourse would be to simply die here but that seems severe + * for a 'readable' test. + * NB: we don't need a 'full' allocation of memory to test the + * group list, only to store it. one idea would be to do this in + * 'blocks' + */ + option_error( 1, "unable to allocate memory for group list" ) ; + return( 0 ) ; + } +/* get groups */ + ngroups = getgroups( max_ngroups, groups ) ; +/* ... and test the group permission if matching */ + for( i = 0 ; i < ngroups ; ++i ) { + if (sbuf.st_gid == groups[i]) { + free( (void*)groups) ; + return( sbuf.st_mode & S_IRGRP ) ; + } + } +/* otherwise return other permissions match */ + free( (void*)groups ) ; return sbuf.st_mode & S_IROTH; } Index: usr.sbin/rpc.lockd/kern.c =================================================================== RCS file: /home/__orole/dev/cabinet/zeeNi/ai/freebsd/src/usr.sbin/rpc.lockd/kern.c,v retrieving revision 1.21 diff -b -u -r1.21 kern.c --- usr.sbin/rpc.lockd/kern.c 17 Aug 2006 05:55:20 -0000 1.21 +++ usr.sbin/rpc.lockd/kern.c 5 Feb 2009 16:22:17 -0000 @@ -239,15 +239,15 @@ int ngroups; ngroups = xucred->cr_ngroups - 1; - if (ngroups > NGRPS) - ngroups = NGRPS; - if (cl->cl_auth != NULL) - cl->cl_auth->ah_ops->ah_destroy(cl->cl_auth); - cl->cl_auth = authunix_create(hostname, + if( ngroups > AUTH_UNIX_NGROUPS ) + ngroups = AUTH_UNIX_NGROUPS ; + if( cl->cl_auth != NULL ) + cl->cl_auth->ah_ops->ah_destroy( cl->cl_auth ) ; + cl->cl_auth = authunix_create( hostname, xucred->cr_uid, xucred->cr_groups[0], ngroups, - &xucred->cr_groups[1]); + &xucred->cr_groups[1] ) ; } --zYM0uCDKw75PZbzx-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 12:46:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE031065670 for ; Tue, 24 Mar 2009 12:46:44 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9F46E8FC2B for ; Tue, 24 Mar 2009 12:46:44 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so1838998waf.27 for ; Tue, 24 Mar 2009 05:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VETnndAGaR8wkw4dhxnWQ1SYzGBWSe/tAdHPh6HqmWk=; b=HwWl+IywYzBQooKB3dFetV1AsZdUfgMbza5ImB9CWkl3Dg8Se198Lz97oLtKQYoM4y X/5WtFGPsnzpIeyhnKd2hf9LCDlxzoCK7bMzRblKurz56bE8mCmJcI+Z9tec7quunqq0 4tPuUP7FIwHuIEbRR8vvDecyT6+ozae9ceJVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=hwGd0FcTNjAt5y4Qv9OE19Dv2VfFBzEUNq4GVg4Mc2JLKhFP/ndU2+anbhJQka3lQB 4MIHOgG/8Z05ygM/5OIod8/dFUh21kXc75UzjXvN5XXPURNzBQJzaLv1H+UYFqDLmF70 gkFo4u3zPhKQKtpWpsHuydpqKVThaxKgKNRCc= Received: by 10.114.178.13 with SMTP id a13mr5585604waf.88.1237898803720; Tue, 24 Mar 2009 05:46:43 -0700 (PDT) Received: from localhost.localdomain ([213.152.137.43]) by mx.google.com with ESMTPS id y25sm2766832pod.10.2009.03.24.05.46.40 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 05:46:42 -0700 (PDT) Message-ID: <49C8D63E.4050107@gmail.com> Date: Tue, 24 Mar 2009 15:46:54 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <49C8AD9B.7000500@gmail.com> In-Reply-To: <49C8AD9B.7000500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [problem] aac0 does not respond 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, 24 Mar 2009 12:46:47 -0000 Vladimir Ermakov wrote: > Hello, All > > Describe my problem: > have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 > 2 HHD of 6 have errors in smart data (damaged) > i am try read file /var/db/mysql/ibdata1 from this volume > system does not respond ( lost access to ssh ) after read 6GB data > from this file > and print debug messages on ttyv0 > > As to prevent the emergence of this problem? > As monitor the status of RAID-controller? > similar problem http://lists.freebsd.org/pipermail/freebsd-scsi/2008-June/003524.html /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 12:48:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31BE1065713 for ; Tue, 24 Mar 2009 12:48:36 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by mx1.freebsd.org (Postfix) with ESMTP id 586588FC14 for ; Tue, 24 Mar 2009 12:48:36 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2358462rvb.43 for ; Tue, 24 Mar 2009 05:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BGkL++c5nJceXl6o+nEYG8wt1fLikQ3s5Hrb+4oAIEg=; b=jxfc/QiBCbsaJIiw6Fe+PjCAWzN8I+gLSyQ7SgUHn7Ky8x65VbI+Vu20JZfTvzJYke GQPgMLSDXM4IP8XM0+Pa5Josb3v3hckQ8tVbxEn5ikIJfVg5vXv0KOLUZ7gQbk/Q8KU8 M2jnwWdzSLTiMhKSP6eUwJg+kgi3F9tjkuy3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=n95RXXpQlW4BkslDyKwARQI0a1Ejl5PYBpZYbJjwf+g8qPR8EeNj4Z/hBvJw3sdNfz qPifFUMTK+O3mXQre/t2oH9/KbyqAtoINdre2pdFbVkYgqLLsXRqaojN+vb2x5He3IAq GfqWcQPzLmssKhG073g4wegtAtz3O3loerCJ0= Received: by 10.114.174.2 with SMTP id w2mr5572068wae.195.1237898915111; Tue, 24 Mar 2009 05:48:35 -0700 (PDT) Received: from localhost.localdomain ([213.152.137.43]) by mx.google.com with ESMTPS id y25sm2771992pod.10.2009.03.24.05.48.31 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 05:48:33 -0700 (PDT) Message-ID: <49C8D6AD.7050501@gmail.com> Date: Tue, 24 Mar 2009 15:48:45 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <49C8AD9B.7000500@gmail.com> <3bbf2fe10903240324t6616cc9dx6ae28028ac971be6@mail.gmail.com> <49C8B5E3.2000104@gmail.com> In-Reply-To: <49C8B5E3.2000104@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [problem] aac0 does not respond 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, 24 Mar 2009 12:48:37 -0000 Attilio Rao wrote: > 2009/3/24 Vladimir Ermakov : > >> Hello, All >> >> Describe my problem: >> have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 >> 2 HHD of 6 have errors in smart data (damaged) >> i am try read file /var/db/mysql/ibdata1 from this volume >> system does not respond ( lost access to ssh ) after read 6GB data >> from this >> file >> and print debug messages on ttyv0 >> >> As to prevent the emergence of this problem? >> As monitor the status of RAID-controller? >> >> please, any solutions >> > > Is this -STABLE or -CURRENT? > And if it is -CURRENT, what revision? > > Thanks, > Attilio > > > it -STABLE thx /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 13:22:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3069C1065841 for ; Tue, 24 Mar 2009 13:22:41 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id AEB278FC21 for ; Tue, 24 Mar 2009 13:22:40 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm11 with SMTP id 11so2132514fxm.43 for ; Tue, 24 Mar 2009 06:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rYEVgdTu/2I6hAxbyi1V2g82/OHYCPq4Awp1rF4bJRg=; b=nhHdhTbYuCAN8NMp7KqdSSPLxKJqrjRo7qCEJevvTBgLkyvKX+MuVToWXs4elRgc5d DZtt9GQUjdqgbwhJgqiobeM8lNo1uTPTCwWdOJRDFUxgueGxeyf2rRdyx8wjpDMBcEwk ZlCQ/lR2aVcTgNyzkimxJmxB21V2ANTpqjTz4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qxLmhOQW2YasQJ+Cq1leC9i8fOU/8wAyIgtjinfVlbgIAUZLkchEUNOY/6m8iUswAa YU8MKk4AM99qJ6BZFBVZQGviFbso2i3XNWqU1FJWrxV82q/jQmZHyymVY1NTdtH1Fb0p OFTG7mS3KtT+2xtiAeBEkWFMqtb59ROq7OKY8= MIME-Version: 1.0 Received: by 10.103.24.11 with SMTP id b11mr3629774muj.58.1237900959725; Tue, 24 Mar 2009 06:22:39 -0700 (PDT) In-Reply-To: <49C8AD9B.7000500@gmail.com> References: <49C8AD9B.7000500@gmail.com> Date: Tue, 24 Mar 2009 16:22:39 +0300 Message-ID: From: pluknet To: Vladimir Ermakov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: [problem] aac0 does not respond 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, 24 Mar 2009 13:22:42 -0000 2009/3/24 Vladimir Ermakov : > Hello, All > > Describe my problem: > have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 > 2 HHD of 6 =A0have errors in smart data (damaged) > i am try read file /var/db/mysql/ibdata1 from this volume > system does not respond ( lost access to ssh ) after read 6GB data from t= his > file > and print debug messages on ttyv0 > > As to prevent the emergence of this problem? > As monitor the status of RAID-controller? > You can check status of aac controller with arcconf utility and post results there.. --=20 wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 24 14:25:16 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCF9106567A for ; Tue, 24 Mar 2009 14:25:16 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE388FC0C for ; Tue, 24 Mar 2009 14:25:16 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2398557rvb.43 for ; Tue, 24 Mar 2009 07:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=idjLDnpwgobjwhGiXOppjHMeIh/rv1wpNFVI5o3mGWY=; b=d54IVqnECPqmTEuy1cgTMJU/l1phy2le3jXuxe28ujWwBpsACEUKp9I13pD8tXOFI1 sOc4nUoaEe29gdA48O7uUQPmxqtDAUJGAz1ZOsurJ7WnR0AXD+VwxjAQJUIW9GbBiJ2C fkHUbBEVKjpS4Es2d3hZquibRjqLRnftHANks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XzQXeBJEXCOWHFVgOz/Powyzj9Jvco0leBL7z+bZAQnF1XRyi7dB2c9VqkYiymtX5M Qfa+3zEjy+xcZ4yz8WhNJI+04Usl30Kx83TD8fdsIn1YkD6mnxTwmEY0Dw0ymjew5VQQ Mwu7lvOG7x6cQAnV0bxDouSN8QcXVWxvVwnRg= Received: by 10.115.47.1 with SMTP id z1mr5640810waj.133.1237904715933; Tue, 24 Mar 2009 07:25:15 -0700 (PDT) Received: from localhost.localdomain ([213.152.137.43]) by mx.google.com with ESMTPS id n20sm20153380pof.17.2009.03.24.07.25.13 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Mar 2009 07:25:15 -0700 (PDT) Message-ID: <49C8ED57.9080807@gmail.com> Date: Tue, 24 Mar 2009 17:25:27 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: pluknet References: <49C8AD9B.7000500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: [problem] aac0 does not respond 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, 24 Mar 2009 14:25:17 -0000 pluknet wrote: > 2009/3/24 Vladimir Ermakov : > >> Hello, All >> >> Describe my problem: >> have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 >> > > You can check status of aac controller with arcconf utility > > and post results there.. > > OK i am try enter command: # arcconf task start 1 device 0 4 verify after viewed logs (note, from kernel config: options AAC_DEBUG=2) # less /var/log/messages Mar 24 14:43:24 sys3 kernel: aac0: JobProgress (97) - running (9500000, 10000000) Mar 24 14:43:24 sys3 kernel: aac0: (ScsiVerify) handle 4 Mar 24 14:44:10 sys3 kernel: aac0: JobProgress (98) - running (9600000, 10000000) Mar 24 14:44:10 sys3 kernel: aac0: (ScsiVerify) handle 4 Mar 24 14:44:55 sys3 kernel: aac0: JobProgress (99) - running (9700000, 10000000) Mar 24 14:44:55 sys3 kernel: Mar 24 14:44:55 sys3 kernel: aac0: (ScsiVerify) handle 4 Mar 24 14:45:41 sys3 kernel: aac0: JobProgress (100) - running (9800000, 10000000) Mar 24 14:45:41 sys3 kernel: aac0: (ScsiVerify) handle 4 Mar 24 14:46:28 sys3 kernel: aac0: JobProgress (101) - running (9900000, 10000000) Mar 24 14:46:28 sys3 kernel: aac0: (ScsiVerify) handle 4 Mar 24 14:47:15 sys3 kernel: aac0: EventNotify(0) Mar 24 14:47:15 sys3 kernel: aac0: (23) Mar 24 14:47:15 sys3 kernel: aac0: JobProgress (102) - success (9900000, 10000000) Mar 24 14:47:15 sys3 kernel: aac0: (ScsiVerify) handle 4 # arcconf getlogs 1 EVENT *** Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85525106568A for ; Tue, 24 Mar 2009 16:17:37 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D2C488FC0C for ; Tue, 24 Mar 2009 16:17:36 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id AD3B028484 for ; Wed, 25 Mar 2009 00:17:35 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 2D85FEB0CBA; Wed, 25 Mar 2009 00:17:35 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id ia-bQ8QU4o-L; Wed, 25 Mar 2009 00:17:30 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 183A7EDBD4C; Wed, 25 Mar 2009 00:17:27 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=RktJc/9XMVczhh+7UbdSc85D7s5178pcpQi40bnIXblIODgFQcUZIIhCNreC9hBbZ TpYhS/gsfsJrE+hkxjkAg== Message-ID: <49C90791.7040807@delphij.net> Date: Tue, 24 Mar 2009 09:17:21 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090217) MIME-Version: 1.0 To: "Shaowei Wang (wsw)" References: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> <49710E4F.6020404@delphij.net> <2e566b9e0903232328y45801f76lc6d64acb4fef3dc@mail.gmail.com> In-Reply-To: <2e566b9e0903232328y45801f76lc6d64acb4fef3dc@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org, d@delphij.net Subject: Re: A patch of HPTIOP driver for 7.1-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 16:17:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Shaowei Wang (wsw) wrote: > Hi, delphij > > The problem about FreeBSD-7.x-amd64's hptiop driver is solved by > patching our RAID-manage software (userland utils). > > The hptrr driver is a soft RAID so a 32-bit compatibility ioctl > structure is necessary. The hptiop is a hardware RAID controller, the > firmware is 32-bit. So do we need to patch the driver at our side? My reading is that we will not need it anymore? Please feel free to let me know if you want the patch be committed. Since we are going to have 7.2-RELEASE by early May, it's important to merge stuff back early so they get more through tests, etc. > I'm not so familiar with FreeBSD's development community. I'm sorry > Posting the infomation here. Never mind, the PR system is just a more convenient way of tracking issues (i.e. you can check back if a problem has been resolved at a later time, etc.). > On Sat, Jan 17, 2009 at 6:46 AM, Xin LI > wrote: > > Hi, Shaowei, > > It seems that I can not apply your patch directly, I have tried to do it > manually, as attached, please let me know if it's Ok. I can commit for > you against -HEAD if it looks fine and take care for MFC. > > Note that, however, I am more or less concerned about the driver if > 32-bit utility is running on amd64 platform. There seems to have three > pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and > found that it has defined a 32-bit compatibility ioctl structure. > According to my understanding to hptiop(4), this could be a problem. > > PS. For faster handling it is probably a good idea to submit patch > through our PR system: http://www.freebsd.org/send-pr.html > > Shaowei Wang (wsw) wrote: >> Hi, guys > >> hptiop driver in the 7.1 release has a little bug. >> Because this issue the Raid-manage GUI program which we provided > can NOT >> work anymore. > >> So we give the patch: > >> Index: hptiop.h >> =================================================================== >> --- hptiop.h (revision 186851) >> +++ hptiop.h (working copy) >> @@ -260,7 +260,7 @@ >> unsigned long lpOutBuffer; /* output data buffer */ >> u_int32_t nOutBufferSize; /* size of output > data buffer >> */ >> unsigned long lpBytesReturned; /* count of HPT_U8s > returned */ >> -}; >> +}__attribute__((packed)); > >> #define HPT_IOCTL_FLAG_OPEN 1 >> #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > >> ==================================================================== > >> -wsw > > > /************************************************************************/ > >> '¶} > >> hptiop„q¨(7.1ÑLH- *ï >> Ù*ïüô†ìЛ„5¡ àÕÐL > >> ìÙú†e > >> Index: hptiop.h >> =================================================================== >> --- hptiop.h (revision 186851) >> +++ hptiop.h (working copy) >> @@ -260,7 +260,7 @@ >> unsigned long lpOutBuffer; /* output data buffer */ >> u_int32_t nOutBufferSize; /* size of output > data buffer >> */ >> unsigned long lpBytesReturned; /* count of HPT_U8s > returned */ >> -}; >> +}__attribute__((packed)); > >> #define HPT_IOCTL_FLAG_OPEN 1 >> #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > >> ==================================================================== > >> -wsw > > > > ------------------------------------------------------------------------ > >> _______________________________________________ >> 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 > " > > Index: sys/dev/hptiop/hptiop.h =================================================================== - --- sys/dev/hptiop/hptiop.h （版本 187338） +++ sys/dev/hptiop/hptiop.h （工作副本） @@ -260,7 +260,7 @@ unsigned long lpOutBuffer; /* output data buffer */ u_int32_t nOutBufferSize; /* size of output data buffer */ unsigned long lpBytesReturned; /* count of HPT_U8s returned */ - -}; +} __attribute__((packed)); #define HPT_IOCTL_FLAG_OPEN 1 #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknJB5EACgkQi+vbBBjt66CPRwCeLna7weWqMVK8G/MPFcpIR5Xb z3QAn39CaWIMqTUBmj/EnAc9i09byweF =ylVm -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 00:45:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB7B5106566B for ; Wed, 25 Mar 2009 00:45:24 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 682668FC13 for ; Wed, 25 Mar 2009 00:45:24 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by yw-out-2324.google.com with SMTP id 5so1777214ywh.13 for ; Tue, 24 Mar 2009 17:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=etJGrE7KTAcRj+k/L3jN20DOTlv1H7Pwrib4vYfYQ+U=; b=sWTJTI2IMr4lS1sSZ9KmZGDJSe90Gerg2Vxiu19lhUdkRakqKRczyAt5Pz5k1QNRQI 0KYCwbQx6dhR8MG/eJ7O1ZeQes2W89V0eXuKZaCB6tlRU2VqlPc3bjDj4qDLMhB/l0V7 dnCYhqhBzKMlhpVUfdDfUFwSh4dKL7lpZ5MKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kl8ivXeMs4IYglRW1STGGZ5UeVRCu/kWgOjJuj765ivaven+HxgOQhCqmokSdu4S0U QSEIQnpYCimBFfSNWwPc41hPkTEWE3lF5ZQSLYaRVHb3lhfDQ92TP/oq7LVGNQEilBC7 P5P8t2iL/bOTwFCs6E2pNnD+AstJCc+BxL+Wk= MIME-Version: 1.0 Received: by 10.142.191.5 with SMTP id o5mr3647897wff.53.1237941923311; Tue, 24 Mar 2009 17:45:23 -0700 (PDT) In-Reply-To: <49C90791.7040807@delphij.net> References: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> <49710E4F.6020404@delphij.net> <2e566b9e0903232328y45801f76lc6d64acb4fef3dc@mail.gmail.com> <49C90791.7040807@delphij.net> Date: Wed, 25 Mar 2009 08:45:23 +0800 Message-ID: <2e566b9e0903241745p6dc9ba4bq38a555b3896c23fb@mail.gmail.com> From: "Shaowei Wang (wsw)" To: d@delphij.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: A patch of HPTIOP driver for 7.1-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:45:25 -0000 On Wed, Mar 25, 2009 at 12:17 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Shaowei Wang (wsw) wrote: > > Hi, delphij > > > > The problem about FreeBSD-7.x-amd64's hptiop driver is solved by > > patching our RAID-manage software (userland utils). > > > > The hptrr driver is a soft RAID so a 32-bit compatibility ioctl > > structure is necessary. The hptiop is a hardware RAID controller, the > > firmware is 32-bit. > > So do we need to patch the driver at our side? My reading is that we > will not need it anymore? Please feel free to let me know if you want > the patch be committed. Since we are going to have 7.2-RELEASE by early > May, it's important to merge stuff back early so they get more through > tests, etc. > Yes, this patch should be committed when we going to have the next FreeBSD release. Thanks! > > I'm not so familiar with FreeBSD's development community. I'm sorry > > Posting the infomation here. > > Never mind, the PR system is just a more convenient way of tracking > issues (i.e. you can check back if a problem has been resolved at a > later time, etc.). I'll try to use the PR system next time and thank you again. > > > On Sat, Jan 17, 2009 at 6:46 AM, Xin LI > > wrote: > > > > Hi, Shaowei, > > > > It seems that I can not apply your patch directly, I have tried to do i= t > > manually, as attached, please let me know if it's Ok. I can commit for > > you against -HEAD if it looks fine and take care for MFC. > > > > Note that, however, I am more or less concerned about the driver if > > 32-bit utility is running on amd64 platform. There seems to have three > > pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) an= d > > found that it has defined a 32-bit compatibility ioctl structure. > > According to my understanding to hptiop(4), this could be a problem. > > > > PS. For faster handling it is probably a good idea to submit patch > > through our PR system: http://www.freebsd.org/send-pr.html > > > > Shaowei Wang (wsw) wrote: > >> Hi, guys > > > >> hptiop driver in the 7.1 release has a little bug. > >> Because this issue the Raid-manage GUI program which we provided > > can NOT > >> work anymore. > > > >> So we give the patch: > > > >> Index: hptiop.h > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- hptiop.h (revision 186851) > >> +++ hptiop.h (working copy) > >> @@ -260,7 +260,7 @@ > >> unsigned long lpOutBuffer; /* output data buffer */ > >> u_int32_t nOutBufferSize; /* size of output > > data buffer > >> */ > >> unsigned long lpBytesReturned; /* count of HPT_U8s > > returned */ > >> -}; > >> +}__attribute__((packed)); > > > >> #define HPT_IOCTL_FLAG_OPEN 1 > >> #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >> -wsw > > > > > > > /************************************************************************= / > > > >> '=C2=B6} > > > >> hptiop=E2=80=9Eq=C2=A8(7.1=C3=91LH- * =C3=AF > >> =C3=99* =C3=AF=C3=BC=C3=B4=E2=80=A0 =C3=AC=C3=90=E2=80=BA=E2=80=9E5 = =C2=A1 =C3=A0=C3=95=C3=90L > > > >> =C3=AC=C3=99=C3=BA=E2=80=A0e > > > >> Index: hptiop.h > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- hptiop.h (revision 186851) > >> +++ hptiop.h (working copy) > >> @@ -260,7 +260,7 @@ > >> unsigned long lpOutBuffer; /* output data buffer */ > >> u_int32_t nOutBufferSize; /* size of output > > data buffer > >> */ > >> unsigned long lpBytesReturned; /* count of HPT_U8s > > returned */ > >> -}; > >> +}__attribute__((packed)); > > > >> #define HPT_IOCTL_FLAG_OPEN 1 > >> #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >> -wsw > > > > > > > > -----------------------------------------------------------------------= - > > > >> _______________________________________________ > >> 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 > > " > > > > > > Index: sys/dev/hptiop/hptiop.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > - --- sys/dev/hptiop/hptiop.h =EF=BC=88=E7=89=88=E6=9C=AC 187338=EF= =BC=89 > +++ sys/dev/hptiop/hptiop.h =EF=BC=88=E5=B7=A5=E4=BD=9C=E5=89=AF=E6= =9C=AC=EF=BC=89 > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output > data buffer */ > unsigned long lpBytesReturned; /* count of HPT_U8s > returned */ > - -}; > +} __attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > > > > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAknJB5EACgkQi+vbBBjt66CPRwCeLna7weWqMVK8G/MPFcpIR5Xb > z3QAn39CaWIMqTUBmj/EnAc9i09byweF > =3DylVm > -----END PGP SIGNATURE----- > From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 04:12:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87837106566B for ; Wed, 25 Mar 2009 04:12:12 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 593A88FC12 for ; Wed, 25 Mar 2009 04:12:12 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-75-22.phlapa.east.verizon.net [141.151.75.22]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 9558B68172; Wed, 25 Mar 2009 13:12:10 +0900 (JST) Date: Wed, 25 Mar 2009 00:12:05 -0400 From: Yoshihiro Ota To: Michael David Crawford Message-Id: <20090325001205.aea0f0d1.ota@j.email.ne.jp> In-Reply-To: <49C35A58.2030607@prgmr.com> References: <20090320045319.04484fc5.ota@j.email.ne.jp> <49C35A58.2030607@prgmr.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good? 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, 25 Mar 2009 04:12:12 -0000 On Fri, 20 Mar 2009 01:56:56 -0700 Michael David Crawford wrote: > Yoshihiro Ota wrote: > > > I saw a program that opens 2 TCP connections. > > One connection is only used for server to client messaging only > > and the other connection is used only for client to server messaging. > > > > 2. He also said that it would also waste network bandwidth. > > You have a two-way communication no matter what you do. But if you > don't actually use inbound direction, all it gets used for is the > receipt of ACK packets. > > That is, the inbound connection is used to make the data transfer reliable. > > If you don't have any payload data on the inbound connection, then the > outbound connection won't have any ACK packets. > > If you're sending payload data, the ACK info can "hitchhike" along with > the payload packets, thus saving bandwidth. But if you're not sending > any payload data at all, there will be packets transmitted which contain > the ACKs and nothing else. > > The extra network overhead will be modest if you're sending a lot of > data all at once, say transferring a large file. But if very little > data is sent per packet, say individual characters in a telnet > connection, the overhead would be very high. So far until this, this was what I had though and learned about TCP connections. > If you have a single connection with payload data in both directions, > then the ACKs will almost always ride along with some payload data. The > only time a packet will contain nothing but an ACK will be when some > data was transmitted, but none is to be received at the time. > > Mike However, I had forgotten this case. This can explain he even said that using 2 TCP connection would cut the bandwidth into half. This sounds like the case he was referring to. Thanks, Hiro From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 04:59:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 682DB106566B; Wed, 25 Mar 2009 04:59:19 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 266CE8FC16; Wed, 25 Mar 2009 04:59:19 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-75-22.phlapa.east.verizon.net [141.151.75.22]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 8707D5C652; Wed, 25 Mar 2009 13:59:17 +0900 (JST) Date: Wed, 25 Mar 2009 00:59:11 -0400 From: Yoshihiro Ota To: Robert Watson Message-Id: <20090325005911.87aa63ab.ota@j.email.ne.jp> In-Reply-To: References: <20090320045319.04484fc5.ota@j.email.ne.jp> <20090322235253.432874dd.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: 2 uni-directional TCP connection good 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, 25 Mar 2009 04:59:19 -0000 On Mon, 23 Mar 2009 08:20:20 +0000 (GMT) Robert Watson wrote: > > On Sun, 22 Mar 2009, Yoshihiro Ota wrote: > > >> On Fri, 20 Mar 2009, Yoshihiro Ota wrote: > >> > >>> 1. With TCP connections, only sender side can detect some communication > >>> issues passively if happened. By using two connections, you lost that > >>> ability by your self. I agree on this one. > >> > >> Could you expand a bit on this point? While the connection creation > >> process (usually) asymmetric, once the connection is built it's essentially > >> the same state machine on both sides of the connection, and socket > >> semantics with respect to the state machine are effectively identical. > >> Application on both sides should be able to detect disconnect, monitor > >> connection state using TCP_INFO, etc. > > > > What I meant was that there were cases when a receiver could not tell > > weather no data was coming or communication was interrupted. Once > > connection is established, a route is available between a server and a > > client. Let's say this route is broken for some reasons, i.e. someone > > unplugged a cable or a firewall started dropping or rejecting between these > > server and client, a sender may not notice as soon as it happens but at > > least, a sender knows a massages was not delivered right. On the other > > hand, receiver side does not have any idea that a message delivery failure > > has happened at all or for a while unless using heartbeat messages in upper > > layer. KEEP_ALIVE option seems to be implementation dependent such that you > > cannot assure TCP connection availability for every minute. > > This is generally considered a robustness property rather than a fragility > issue, but yes: if you need a liveliness property for idle connections with > TCP, it's something you have to implement at the application layer, and many > protocols indeed do this. I don't see that this is an argument for using two > TCP connections as opposed to one, however. If you're interested in > alternative protocols, however, SCTP allows a number of these protocol > behaviors to be modified, and includes support for a heartbeat. Actually, the programs I had problems with were ggated/ggatec. As I look back my records, I found a problem with ggate when I had a slow ggated server (Celeron 400MHz) and a fast ggatec client (AMD Turion(tm) 64 X2 1.9GHz). While the client was writing a large file to the server, there were often major delays in its communication. While this was happening, I observed with "systat -vm" and saw interrupts on the NIC was 1 per a couple seconds. Indeed, I tested SCTP with ggate but as far as I remember, STCP seemed to have problems such that ggate couldn't establish a connection back in 7.0-RELEASE. I tested the same code in 7.1-RELEASE just before and it appeared to be working. It was just an experiment back in a year ago and couldn't find a reason easily. So, I gave up. Recently, ggate became necessity. I enhanced some of debug capabilities and found that when this happens, sequence numbers in ggate are out of sync. For example, while this is happening, ggatec reports it has finished send() with seq# 186, but at the same exact time, ggated reports it has only recv()ed up to seq# 184. They get synced eventually, but it takes long time and happens frequently. Meanwhile, terminal does not response in timely manner. This hiccup doesn't happen if client is doing read-access to ggated. FTP or nfs doesn't have similar hiccup and communicate at its max speed, 100-Base T. Both ggatec and ggated creates 2 TCP connections and 2 threads for blocking reads and writes. When I mentioned this problem to the friend mentioned above, he suggested to change 2 uni-directional TCP connections to 1 bi-directional one. In fact, this fixed the problem. At the same time, he also expressed that 2 uni-directional TCP connection was so bad no one should not use like it must be prohibited at all. So, I wondered and wanted to know how other people would say about it. If using 2 uni-directional TCP communication is not that bad idea or something prohibited, then we may have some issues in TCP layer. If anyone is interested in looking into, I can elaborate other observations as well. Thanks, Hiro From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 08:58:12 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06DB61065695 for ; Wed, 25 Mar 2009 08:58:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C14D98FC2A for ; Wed, 25 Mar 2009 08:58:11 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F408B730A1; Wed, 25 Mar 2009 09:47:22 +0100 (CET) Date: Wed, 25 Mar 2009 09:47:22 +0100 From: Luigi Rizzo To: hackers@freebsd.org Message-ID: <20090325084722.GC98685@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: does Copyright on source files expire ? 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, 25 Mar 2009 08:58:12 -0000 Someone just asked me permission to move to a 3-clause BSD copyright some piece of software that I haven't touched in 10+ years. I said yes, but then I was wondering what happens if the person listed is not responding or not reachable anymore: does copyright on source code expire, and if so, when ? (I suppose it is related to either the date listed on the copyright, or to the date of some remarkable event for the author). cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 09:29:23 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D22DF106568D for ; Wed, 25 Mar 2009 09:29:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 942448FC25 for ; Wed, 25 Mar 2009 09:29:23 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2P9Vq21037484; Wed, 25 Mar 2009 05:31:52 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2P9VqEK037483; Wed, 25 Mar 2009 05:31:52 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 25 Mar 2009 05:31:52 -0400 From: David Schultz To: Luigi Rizzo Message-ID: <20090325093152.GB85469@zim.MIT.EDU> Mail-Followup-To: Luigi Rizzo , hackers@FreeBSD.ORG References: <20090325084722.GC98685@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325084722.GC98685@onelab2.iet.unipi.it> Cc: hackers@FreeBSD.ORG Subject: Re: does Copyright on source files expire ? 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, 25 Mar 2009 09:29:24 -0000 On Wed, Mar 25, 2009, Luigi Rizzo wrote: > Someone just asked me permission to move to a 3-clause BSD > copyright some piece of software that I haven't touched in 10+ years. > > I said yes, but then I was wondering what happens if the > person listed is not responding or not reachable anymore: > does copyright on source code expire, and if so, when ? > (I suppose it is related to either the date listed on the copyright, > or to the date of some remarkable event for the author). In the US, the rule that applies most of the time is that Copyright expires 70 years after the author dies, although there are many special cases where the term differs. A person's Copyright doesn't go away just because they die, disappear, or fail to respond. If you can't contact them, their heirs, or whomever they transferred the Copyright to, you're stuck. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 09:29:58 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFC1D1065670 for ; Wed, 25 Mar 2009 09:29:58 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 983A18FC0A for ; Wed, 25 Mar 2009 09:29:58 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:54776 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1LmPC9-0008Ag-7j for hackers@freebsd.org; Wed, 25 Mar 2009 10:14:45 +0100 Received: (qmail 27343 invoked from network); 25 Mar 2009 10:14:42 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 25 Mar 2009 10:14:42 +0100 Received: (qmail 13485 invoked by uid 1001); 25 Mar 2009 10:14:42 +0100 Date: Wed, 25 Mar 2009 10:14:42 +0100 From: Erik Trulsson To: Luigi Rizzo Message-ID: <20090325091442.GA13455@owl.midgard.homeip.net> References: <20090325084722.GC98685@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325084722.GC98685@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1LmPC9-0008Ag-7j. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1LmPC9-0008Ag-7j 69329ebfb348537ee761c40a8e278cfd Cc: hackers@freebsd.org Subject: Re: does Copyright on source files expire ? 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, 25 Mar 2009 09:29:59 -0000 On Wed, Mar 25, 2009 at 09:47:22AM +0100, Luigi Rizzo wrote: > Someone just asked me permission to move to a 3-clause BSD > copyright some piece of software that I haven't touched in 10+ years. > > I said yes, but then I was wondering what happens if the > person listed is not responding or not reachable anymore: > does copyright on source code expire, and if so, when ? Yes, it will expire eventually, after a long time. The exact length of copyright can vary a bit between different countries, but in most places nowadays I think it is 'life of author plus 70 years' > (I suppose it is related to either the date listed on the copyright, > or to the date of some remarkable event for the author). > -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 09:36:04 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A41151065670 for ; Wed, 25 Mar 2009 09:36:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFDD8FC18 for ; Wed, 25 Mar 2009 09:36:04 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1038E73098; Wed, 25 Mar 2009 10:41:00 +0100 (CET) Date: Wed, 25 Mar 2009 10:41:00 +0100 From: Luigi Rizzo To: hackers@FreeBSD.ORG Message-ID: <20090325094100.GA915@onelab2.iet.unipi.it> References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325093152.GB85469@zim.MIT.EDU> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: does Copyright on source files expire ? 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, 25 Mar 2009 09:36:05 -0000 On Wed, Mar 25, 2009 at 05:31:52AM -0400, David Schultz wrote: > On Wed, Mar 25, 2009, Luigi Rizzo wrote: > > Someone just asked me permission to move to a 3-clause BSD > > copyright some piece of software that I haven't touched in 10+ years. > > > > I said yes, but then I was wondering what happens if the > > person listed is not responding or not reachable anymore: > > does copyright on source code expire, and if so, when ? > > (I suppose it is related to either the date listed on the copyright, > > or to the date of some remarkable event for the author). > > In the US, the rule that applies most of the time is that > Copyright expires 70 years after the author dies, although there > are many special cases where the term differs. > > A person's Copyright doesn't go away just because they die, > disappear, or fail to respond. If you can't contact them, their > heirs, or whomever they transferred the Copyright to, you're stuck. so it's worse than a patent :) cheers luigi From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 10:01:14 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E6DD1065672 for ; Wed, 25 Mar 2009 10:01:14 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6FE8FC13 for ; Wed, 25 Mar 2009 10:01:13 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2PA3gGj037648; Wed, 25 Mar 2009 06:03:42 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2PA3gl4037647; Wed, 25 Mar 2009 06:03:42 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 25 Mar 2009 06:03:42 -0400 From: David Schultz To: Luigi Rizzo Message-ID: <20090325100342.GA37547@zim.MIT.EDU> Mail-Followup-To: Luigi Rizzo , hackers@FreeBSD.ORG References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> <20090325094100.GA915@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325094100.GA915@onelab2.iet.unipi.it> Cc: hackers@FreeBSD.ORG Subject: Re: does Copyright on source files expire ? 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, 25 Mar 2009 10:01:14 -0000 On Wed, Mar 25, 2009, Luigi Rizzo wrote: > On Wed, Mar 25, 2009 at 05:31:52AM -0400, David Schultz wrote: > > On Wed, Mar 25, 2009, Luigi Rizzo wrote: > > > Someone just asked me permission to move to a 3-clause BSD > > > copyright some piece of software that I haven't touched in 10+ years. > > > > > > I said yes, but then I was wondering what happens if the > > > person listed is not responding or not reachable anymore: > > > does copyright on source code expire, and if so, when ? > > > (I suppose it is related to either the date listed on the copyright, > > > or to the date of some remarkable event for the author). > > > > In the US, the rule that applies most of the time is that > > Copyright expires 70 years after the author dies, although there > > are many special cases where the term differs. > > > > A person's Copyright doesn't go away just because they die, > > disappear, or fail to respond. If you can't contact them, their > > heirs, or whomever they transferred the Copyright to, you're stuck. > > so it's worse than a patent :) In that sense, yes. But at least with Copyright you have the option of rewriting the code from scratch. In the U.S., there have been various attempts to improve the laws regarding orphaned works, but most of the good ideas run afoul of international Copyright treaties. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 11:36:51 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D08AB10656C3 for ; Wed, 25 Mar 2009 11:36:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 8F24A8FC14 for ; Wed, 25 Mar 2009 11:36:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LmR6F-0006ED-E3 for hackers@FreeBSD.ORG; Wed, 25 Mar 2009 13:16:47 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Mar 2009 13:16:47 +0200 From: Danny Braniss Message-ID: Cc: Subject: Intel Integrated Raid (iir) relevance 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, 25 Mar 2009 11:36:52 -0000 It's no longer working (for me) under 7.2, and so far I am not getting any feedback, so since it seems that this particular hardware has reached EOL, I was wondering if, a) it's true, b) drop it, and replace it. c) should time be spent in getting it to work again. danny From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 09:34:19 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E734910656C9 for ; Wed, 25 Mar 2009 09:34:19 +0000 (UTC) (envelope-from johans@stack.nl) Received: from mx0.stack.nl (mj0.stack.nl [IPv6:2001:610:1108:5010::187]) by mx1.freebsd.org (Postfix) with ESMTP id 9F96F8FC1B for ; Wed, 25 Mar 2009 09:34:19 +0000 (UTC) (envelope-from johans@stack.nl) Received: by mx0.stack.nl (Postfix, from userid 65534) id AC8E52B3703; Wed, 25 Mar 2009 10:34:18 +0100 (CET) X-Spam-DCC: : X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on toad.stack.nl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Relay-Country: Received: from mud.stack.nl (mud.stack.nl [IPv6:2001:610:1108:5011:230:48ff:fe12:2794]) by mx0.stack.nl (Postfix) with ESMTP id D81282B364D; Wed, 25 Mar 2009 10:34:16 +0100 (CET) Received: by mud.stack.nl (Postfix, from userid 801) id CF61C11458; Wed, 25 Mar 2009 10:34:16 +0100 (CET) Date: Wed, 25 Mar 2009 10:34:16 +0100 From: Johan van Selst To: Luigi Rizzo Message-ID: <20090325093416.GA66389@mud.stack.nl> References: <20090325084722.GC98685@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20090325084722.GC98685@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.19 (2009-01-14) X-Mailman-Approved-At: Wed, 25 Mar 2009 11:50:57 +0000 Cc: hackers@freebsd.org Subject: Re: does Copyright on source files expire ? 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, 25 Mar 2009 09:34:22 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Luigi Rizzo wrote: > I said yes, but then I was wondering what happens if the > person listed is not responding or not reachable anymore: > does copyright on source code expire, and if so, when ? Yes, copyright expires. When it expires exactly depends on local legislation. Generally this is a number of years after the death of the longest living author. I believe in the US copyright generally expires 70 years after the death - or if the copyright is owned by a company, then it expires 120 years after creation (or 95 years after publication). There is a lot of documentation about copyright details available on the internet - but keep in mind that laws change frequently. So it's probably safe to assume that all code used in FreeBSD is still covered by copyright and all licenses granted by the authors still apply (untill one day the copyright expires). P.S. As with all legal stuff, there are always exceptions to the rule: specific cases and local legislation may differ a lot. Ciao, Johan --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iEYEAREIAAYFAknJ+pgACgkQaOElK32lxTuuUQCgjyWGg66zeYOv6FEBZOBXu9C5 bDYAn0xIkGZsRTukTbQLqehF5e0/i0+L =J6Ad -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 13:31:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 181C8106566B; Wed, 25 Mar 2009 13:31:03 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id D20CF8FC1E; Wed, 25 Mar 2009 13:31:02 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so48480rvb.43 for ; Wed, 25 Mar 2009 06:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=UU4vvlVub97Bn84E46/7IQs+Y0C7tULYLQHSGMjoPok=; b=gc+6A2PeZx1lr5NM2XkLtvqPQKGCO6TCBZiMLyB9ZOT8l8xUwh0LJ6GxmTa4R/6dUw Qw4gkqO0xLLCOQwIUque00NN4MegWAfPic/EA2Enac4NPuato3KGJn9RSuEmFQEjrq5D W3LQ1x3PeRR91zgyOzaAtV3uINeCUHfryi2hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mUQOZr35ViyQKRLQsk+nXBMrP/m/+QgCGuCJ+5MO6miZXy+eARmxhqCHQswTWUCei6 b1IPrxrgJexQGvBtMwqXIQY/EsdXkjgdyygmSsYw7womEGr2SCy/fmre1aUfa9nTYpgS cBsIladyTbK0CgPKlOwLb8KZR2fRW+UeN1Mzw= Received: by 10.114.208.20 with SMTP id f20mr6499100wag.46.1237987862486; Wed, 25 Mar 2009 06:31:02 -0700 (PDT) Received: from localhost.localdomain ([213.152.137.43]) by mx.google.com with ESMTPS id y25sm7584833pod.10.2009.03.25.06.30.58 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 06:31:00 -0700 (PDT) Message-ID: <49CA321E.5070305@gmail.com> Date: Wed, 25 Mar 2009 16:31:10 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Ed Maste References: <49C8AD9B.7000500@gmail.com> <3bbf2fe10903240324t6616cc9dx6ae28028ac971be6@mail.gmail.com> <49C8B5E3.2000104@gmail.com> <49C8D6AD.7050501@gmail.com> <20090324141136.GA46558@jem.dhs.org> In-Reply-To: <20090324141136.GA46558@jem.dhs.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Attilio Rao , freebsd-hackers@freebsd.org Subject: Re: [problem] aac0 does not respond 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, 25 Mar 2009 13:31:03 -0000 Ed Maste wrote: > 2009/3/24 Vladimir Ermakov : > >> Hello, All >> >> Describe my problem: >> have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 >> 2 HHD of 6 have errors in smart data (damaged) >> i am try read file /var/db/mysql/ibdata1 from this volume >> system does not respond ( lost access to ssh ) after read 6GB data >> > >from this > >> file >> and print debug messages on ttyv0 >> > > If the messages you see are the same as in the message to which you > provided a link ("COMMAND xxx TIMED OUT AFTER xxx SECONDS") it typically > means that the RAID controller has crashed. My initial suggestion is to > check the firmware version installed on your card, and update to the > latest from Adaptec's website if you're not running that one already. > > Attilio also has some driver updates (ported from Adaptec's latest > vendor driver) that you can try. The plan is to commit them sometime > soon, but he can forward those on for testing before that happens. > > -Ed > > Hello I updated the firmware [Build 16116] to [Build 16501]. Update does not fix problem. Where to get a some driver updates? /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 19:27:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBDDB106564A for ; Wed, 25 Mar 2009 19:27:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id AE62D8FC08 for ; Wed, 25 Mar 2009 19:27:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-21-14.dsl.snfc21.pacbell.net [71.139.21.14]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n2PIprm0041638 for ; Wed, 25 Mar 2009 11:51:53 -0700 (PDT) Message-ID: <49CA7D47.7070406@rawbw.com> Date: Wed, 25 Mar 2009 11:51:51 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Atheros wireless card keeps losing signal when signal is too weak X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 19:27:40 -0000 I have Linux box sitting next to FreeBSD box that has a very cheap Airlink 101 card but it has no problems connecting to my WiFi network. Every time when Linux box says that quality of connection drops below 10/100 FreeBSD box shows "status: no carrier". Linux connections still function ok. I even bought a large WiFi antenna for FreeBSD box but still have this problem. Is there some 'sensitivity' parameter that driver may be setting too low on the card? 'iwconfig' on Linux shows some 'sensitivity' parameter=200. 7.1-STABLE ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on pci0 Yuri From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 21:13:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58D1F1065692 for ; Wed, 25 Mar 2009 21:13:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id E21218FC1A for ; Wed, 25 Mar 2009 21:13:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so253297ewy.43 for ; Wed, 25 Mar 2009 14:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EwECD6pWi5dkuX7rSDZaCaWEKMVEUZpYV+zEtgacPvc=; b=kQVQx3K8uf6J0X3cx8LOulSuIVFX1nHmhTwuoDiao6sD6SAh0L9f1GogUXfY4sDX/G wNy++Gr7WjdQ77VfpsqU5/WdUihi8le9hNRY8g+PzRmDAm4fEyti3CeG1wce9Y/dAaN/ AqxDLV435H5Y61C3PJhlAFgEXMzeP48UZTQ84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SsS9oxJTyPv3l+rT3/0U1RepYKXGgkQf2WgEATzDZoizYvJhhDPM7PdKyKEDMr4ffW r0I0/pqXOfClsBzEm76c2QM/zYB6wcI38bX0s7cCCz480DZ7jNPZA0S7YIuVzYMgKJT4 vVIu0RWX6OxrZytpkV7n76oecjewJ2U9EVeJ8= MIME-Version: 1.0 Received: by 10.210.16.11 with SMTP id 11mr29420ebp.9.1238014246008; Wed, 25 Mar 2009 13:50:46 -0700 (PDT) In-Reply-To: <49CA7D47.7070406@rawbw.com> References: <49CA7D47.7070406@rawbw.com> Date: Wed, 25 Mar 2009 21:50:46 +0100 Message-ID: <3a142e750903251350l66801af4j26722a5b905a9a34@mail.gmail.com> From: "Paul B. Mahol" To: yuri@rawbw.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Atheros wireless card keeps losing signal when signal is too weak 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, 25 Mar 2009 21:13:48 -0000 On 3/25/09, Yuri wrote: > I have Linux box sitting next to FreeBSD box that has a very cheap > Airlink 101 card but it has no problems connecting to my WiFi network. > > Every time when Linux box says that quality of connection drops below > 10/100 FreeBSD box shows "status: no carrier". > Linux connections still function ok. > > I even bought a large WiFi antenna for FreeBSD box but still have this > problem. > > Is there some 'sensitivity' parameter that driver may be setting too low > on the card? I'm only aware of roam:rssi & roam:rate -- Paul From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 25 21:30:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9DC1065736 for ; Wed, 25 Mar 2009 21:30:36 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id EC9688FC20 for ; Wed, 25 Mar 2009 21:30:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n2PLUYtZ047292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Mar 2009 14:30:35 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49CAA27A.6060602@freebsd.org> Date: Wed, 25 Mar 2009 14:30:34 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: "Paul B. Mahol" References: <49CA7D47.7070406@rawbw.com> <3a142e750903251350l66801af4j26722a5b905a9a34@mail.gmail.com> In-Reply-To: <3a142e750903251350l66801af4j26722a5b905a9a34@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: yuri@rawbw.com, freebsd-hackers@freebsd.org Subject: Re: Atheros wireless card keeps losing signal when signal is too weak 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, 25 Mar 2009 21:30:38 -0000 Paul B. Mahol wrote: > On 3/25/09, Yuri wrote: > >> I have Linux box sitting next to FreeBSD box that has a very cheap >> Airlink 101 card but it has no problems connecting to my WiFi network. >> >> Every time when Linux box says that quality of connection drops below >> 10/100 FreeBSD box shows "status: no carrier". >> Linux connections still function ok. >> >> I even bought a large WiFi antenna for FreeBSD box but still have this >> problem. >> >> Is there some 'sensitivity' parameter that driver may be setting too low >> on the card? >> > > I'm only aware of roam:rssi & roam:rate > > Those parameters control the roaming algorithm. The OP didn't identify their card, freebsd version, or provide any info about their setup or why ifconfig reports "no carrier". It just sounds like there's a loss in the signal and freebsd gets a beacon miss and tries to reconnect while linux does not. Once the rssi drops to "10" (presumably 5dBm) minor variations in the environment can become significant (e.g. orientation of a laptop, obstructions, antenna quality) and it's impossible to comment on what's happening w/o detailed information such as provided by athstats. FWIW cardbus cards that follow the reference design closely typically work pretty well and don't benefit from an external antenna. Vendors of cheap designs often scrimp when it comes to the antenna. When wireless is inside a case (e.g. a PCI card) then it's worth remoting the antenna but you need to be careful about routing the pigtail(s) and I can't count the number of times I've tracked problems down to faulty cables and/or connections. Sam From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 01:39:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AA191065672 for ; Thu, 26 Mar 2009 01:39:23 +0000 (UTC) (envelope-from psteele@maxiscale.com) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by mx1.freebsd.org (Postfix) with SMTP id 98BE98FC14 for ; Thu, 26 Mar 2009 01:39:22 +0000 (UTC) (envelope-from psteele@maxiscale.com) Received: from source ([209.85.198.233]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKScrcyh7LM+uNkWAHEnLr1n7z1Cmnbn8w@postini.com; Wed, 25 Mar 2009 18:39:22 PDT Received: by rv-out-0506.google.com with SMTP id g9so337825rvb.5 for ; Wed, 25 Mar 2009 18:39:21 -0700 (PDT) Received: by 10.141.29.21 with SMTP id g21mr128238rvj.198.1238031561275; Wed, 25 Mar 2009 18:39:21 -0700 (PDT) Received: from localhost ([76.231.178.131]) by mx.google.com with ESMTPS id k2sm406609rvb.4.2009.03.25.18.39.20 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Mar 2009 18:39:20 -0700 (PDT) Date: Wed, 25 Mar 2009 18:38:25 -0700 (PDT) From: Peter Steele To: freebsd-hackers@freebsd.org Message-ID: <3084677.261238031500941.JavaMail.HALO$@halo> In-Reply-To: <21432774.241238031049378.JavaMail.HALO$@halo> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: WARNING: Expected rawoffset 0, found 63? 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, 26 Mar 2009 01:39:23 -0000 I posted this on the questions list but didn't get a lot of traction. I've created GEOM mirrored file systems on two slices of my system's drives and everything seems to be working, but I get the warning s WARNING: Expected rawoffset 0, found 63 WARNING: Expected rawoffset 0, found 50332464 when the mirrors are being created. These correspond to the offsets for these slices in the partition table: # fdisk -p ad4 # /dev/ad4 g c484521 h16 s63 p 1 0xa5 63 50332401 a 1 p 2 0xa5 50332464 16778160 p 3 0xa5 67110624 421285536 Partition three is not mirror, just partitions 1 and 2. I use the following command to create the slice 1 mirror: gmirror label -v -n -b round-robin s1 and a similar one for slice 2. Additional drives are added to this mirror after the data has been copied to the mirrored file systems. The disks are setup with the required labels, including making sure the c partition is reduced in size by one sector. E.g.: # bsdlabel ad4s1 # /dev/ad4s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 10485760 16 4.2BSD 2048 16384 28528 c: 50332400 0 unused 0 0 # "raw" part, don't edit d: 8388608 10485776 4.2BSD 2048 16384 28528 e: 31457280 18874384 4.2BSD 2048 16384 28528 bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities # bsdlabel ad4s2 # /dev/ad4s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 16778143 16 swap c: 16778159 0 unused 0 0 # "raw" part, don't edit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities So as far as I can tell I have everything configured the way it should be and everything appears to be working fine, but these warnings worry me. Should I be worried? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 04:33:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C191065672 for ; Thu, 26 Mar 2009 04:33:08 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 00CE38FC13 for ; Thu, 26 Mar 2009 04:33:07 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-21-14.dsl.snfc21.pacbell.net [71.139.21.14]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n2Q4X6F4071431 for ; Wed, 25 Mar 2009 21:33:06 -0700 (PDT) Message-ID: <49CB057E.8080900@rawbw.com> Date: Wed, 25 Mar 2009 21:33:02 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <49CA7D47.7070406@rawbw.com> <3a142e750903251350l66801af4j26722a5b905a9a34@mail.gmail.com> <49CAA27A.6060602@freebsd.org> In-Reply-To: <49CAA27A.6060602@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Atheros wireless card keeps losing signal when signal is too weak X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 04:33:08 -0000 Sam Leffler wrote: > Those parameters control the roaming algorithm. The OP didn't > identify their card, freebsd version, or provide any info about their > setup or why ifconfig reports "no carrier". It just sounds like > there's a loss in the signal and freebsd gets a beacon miss and tries > to reconnect while linux does not. Once the rssi drops to "10" > (presumably 5dBm) minor variations in the environment can become > significant (e.g. orientation of a laptop, obstructions, antenna > quality) and it's impossible to comment on what's happening w/o > detailed information such as provided by athstats. > > FWIW cardbus cards that follow the reference design closely typically > work pretty well and don't benefit from an external antenna. Vendors > of cheap designs often scrimp when it comes to the antenna. When > wireless is inside a case (e.g. a PCI card) then it's worth remoting > the antenna but you need to be careful about routing the pigtail(s) > and I can't count the number of times I've tracked problems down to > faulty cables and/or connections. > I did identify my FreeBSD version and card in my original post, but here they are again: 7.1-STABLE ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on pci0 One way or another little cheap laptop card with ndis driver delivers more steady connection then atheros pci card connected to freebsd. Maybe like you mentioned Linux has higher tolerance to missing beacons. Does it make sense to have a parameter "lost beakon tolerance"? Yuri From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 09:59:11 2009 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1D2106564A for ; Thu, 26 Mar 2009 09:59:11 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1445E8FC08 for ; Thu, 26 Mar 2009 09:59:11 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id ACD2019017 for ; Thu, 26 Mar 2009 09:59:09 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA for ; Thu, 26 Mar 2009 09:59:09 +0000 (GMT) Date: Thu, 26 Mar 2009 09:58:49 +0000 From: Bruce Cran To: hackers@freebsd.org Message-ID: <20090326095849.1ec57dda@gluon.draftnet> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Overflow in vm.vmtotal expected when allocating huge amounts of memory? 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, 26 Mar 2009 09:59:12 -0000 Are overflows in the vm counters expected when dealing with huge amounts of memory on 64-bit platforms? I wrote an application which malloc'd 10TB memory and then sat doing nothing; vm.vmtotal showed -2132654356K. Shouldn't unsigned integers be used for any vm stats to avoid overflows? -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 10:12:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2359106566C for ; Thu, 26 Mar 2009 10:12:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD358FC0C for ; Thu, 26 Mar 2009 10:12:41 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so449357ewy.43 for ; Thu, 26 Mar 2009 03:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OJs2WpcoUznq1yWX9hkxsGpgihV38JWR0EsGDQ3jdTE=; b=et5as0h4Xo86TJSt8m+1CaHL35NwNM9veYr3Nrf5fg/Tple5Nbn0/rZCKbg7ipMti1 tCTetzEVL4K3R0TuTgnjQpy1f7BMYAq241jAWqjiBPqoQx/UQ4NdWZFfvHuN49Nsess6 F+iAQoEPI7AF6uEcXcGZJ5cAQiUJ1JwnWr/b4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NtIhN5F2ba19qx5M8BSwkg3NJD0rGeY+0QH5f5MtWCDmMphIN/K9rJ/srRARH9IFhS vT24sTn1dsF6WZvVSF/OAk4cx51gMGuoDMxPjGXq7hRsrNIhttxLJWhSSg5GOSxWihdp EaL1wH/k83j149wG0aqmGet4a96MpE2assT1s= MIME-Version: 1.0 Received: by 10.210.120.7 with SMTP id s7mr515984ebc.78.1238062361093; Thu, 26 Mar 2009 03:12:41 -0700 (PDT) In-Reply-To: <49CB057E.8080900@rawbw.com> References: <49CA7D47.7070406@rawbw.com> <3a142e750903251350l66801af4j26722a5b905a9a34@mail.gmail.com> <49CAA27A.6060602@freebsd.org> <49CB057E.8080900@rawbw.com> Date: Thu, 26 Mar 2009 11:12:41 +0100 Message-ID: <3a142e750903260312k20e34aafn49b6445c9c955adf@mail.gmail.com> From: "Paul B. Mahol" To: yuri@rawbw.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Atheros wireless card keeps losing signal when signal is too weak 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, 26 Mar 2009 10:12:43 -0000 On 3/26/09, Yuri wrote: > Sam Leffler wrote: >> Those parameters control the roaming algorithm. The OP didn't >> identify their card, freebsd version, or provide any info about their >> setup or why ifconfig reports "no carrier". It just sounds like >> there's a loss in the signal and freebsd gets a beacon miss and tries >> to reconnect while linux does not. Once the rssi drops to "10" >> (presumably 5dBm) minor variations in the environment can become >> significant (e.g. orientation of a laptop, obstructions, antenna >> quality) and it's impossible to comment on what's happening w/o >> detailed information such as provided by athstats. >> >> FWIW cardbus cards that follow the reference design closely typically >> work pretty well and don't benefit from an external antenna. Vendors >> of cheap designs often scrimp when it comes to the antenna. When >> wireless is inside a case (e.g. a PCI card) then it's worth remoting >> the antenna but you need to be careful about routing the pigtail(s) >> and I can't count the number of times I've tracked problems down to >> faulty cables and/or connections. >> > > I did identify my FreeBSD version and card in my original post, but here > they are again: > 7.1-STABLE > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath0: mem 0xcffe0000-0xcffeffff irq 16 at device 5.0 on pci0 > > One way or another little cheap laptop card with ndis driver delivers > more steady connection then atheros pci card connected to freebsd. > Maybe like you mentioned Linux has higher tolerance to missing beacons. > Does it make sense to have a parameter "lost beakon tolerance"? Perhaps this is what are you looking for: bmissthreshold count Set the number of consecutive missed beacons at which the station will attempt to roam (i.e., search for a new access point). The count parameter must be in the range 1 to 255; though the upper bound may be reduced according to device capabilities. The default threshold is 7 consecutive missed beacons; but this may be overridden by the device driver. Another name for the bmissthreshold parameter is bmiss. -- Paul From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 10:17:42 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5119D1065672 for ; Thu, 26 Mar 2009 10:17:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 481058FC15 for ; Thu, 26 Mar 2009 10:17:37 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2Q9w6lh007477 for ; Thu, 26 Mar 2009 20:58:06 +1100 Received: from server.vk2pj.dyndns.org (c122-106-216-167.belrs3.nsw.optusnet.com.au [122.106.216.167]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n2Q9w2rK003549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Mar 2009 20:58:04 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n2Q9w28c057883; Thu, 26 Mar 2009 20:58:02 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n2Q9w2PT057882; Thu, 26 Mar 2009 20:58:02 +1100 (EST) (envelope-from peter) Date: Thu, 26 Mar 2009 20:58:02 +1100 From: Peter Jeremy To: Luigi Rizzo , hackers@FreeBSD.ORG Message-ID: <20090326095802.GH56137@server.vk2pj.dyndns.org> References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OpLPJvDmhXTZE4Lg" Content-Disposition: inline In-Reply-To: <20090325093152.GB85469@zim.MIT.EDU> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: does Copyright on source files expire ? 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, 26 Mar 2009 10:17:42 -0000 --OpLPJvDmhXTZE4Lg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Mar-25 05:31:52 -0400, David Schultz wrote: >In the US, the rule that applies most of the time is that >Copyright expires 70 years after the author dies, although there >are many special cases where the term differs. And the '70' gets regularly extended following pressure from the big content owners. As a rule of thumb, you can expect (eg) 'Mickey Mouse' to never be released from Copyright. --=20 Peter Jeremy --OpLPJvDmhXTZE4Lg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAknLUaoACgkQ/opHv/APuIeGNQCfZWXFdfZPozF0P1bZMcm0TRsw rnwAni624ziDRkGS96EcHEzpWhxYLEUn =YhIk -----END PGP SIGNATURE----- --OpLPJvDmhXTZE4Lg-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 11:48:32 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE125106566B for ; Thu, 26 Mar 2009 11:48:32 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: from mail1.slb.deg.dub.stisp.net (mail1.slb.deg.dub.stisp.net [84.203.253.98]) by mx1.freebsd.org (Postfix) with SMTP id 2712B8FC13 for ; Thu, 26 Mar 2009 11:48:31 +0000 (UTC) (envelope-from fergus@cobbled.net) Received: (qmail 15401 invoked from network); 26 Mar 2009 11:48:29 -0000 Received: from unknown (HELO holyman.cobbled.net) (84.203.180.117) by mail1.slb.deg.dub.stisp.net with SMTP; 26 Mar 2009 11:48:29 -0000 Received: by holyman.cobbled.net (Postfix, from userid 16385) id D5FDE10322; Thu, 26 Mar 2009 11:48:28 +0000 (UTC) Date: Thu, 26 Mar 2009 11:48:28 +0000 From: ttw+bsd@cobbled.net To: Luigi Rizzo , hackers@FreeBSD.ORG Message-ID: <20090326114828.GA2840@holyman.cobbled.net> Mail-Followup-To: Luigi Rizzo , hackers@FreeBSD.ORG References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090325093152.GB85469@zim.MIT.EDU> Cc: Subject: Re: does Copyright on source files expire ? 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, 26 Mar 2009 11:48:33 -0000 On 25.03-05:31, David Schultz wrote: [ ... ] > A person's Copyright doesn't go away just because they die, > disappear, or fail to respond. If you can't contact them, their > heirs, or whomever they transferred the Copyright to, you're stuck. yeah but it's a little like finding something. if there not about and not reachable there isn't much they can do to stop you using it. if they popup and make demands later then you get to choose between re-writes and haggling (twenty shekels is standard). point is you "can" use it, the actual copyright owner needs to sue you; not like saying "jehovah" which may result in action by the agents of the state. n.b: using the above opinion may get you crucified. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 13:22:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E8C106566B for ; Thu, 26 Mar 2009 13:22:15 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id D593C8FC23 for ; Thu, 26 Mar 2009 13:22:14 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so439858yxm.13 for ; Thu, 26 Mar 2009 06:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=uxIb+JYrq2e0g7mm3XXmU1yWp93gPzilid/JOzYCeXE=; b=PVlXV6MSHtrHX5wdthshkhypdgcZdbu4g0LVr7ikfstHMOO4Nkb0COiLA2k/qhlDpD 7A38HzhmjcyWvsvl5XjwulCwVOVdh7vOi1dJbpjCkbHcTkR8H8OF7kyXhQGOoRVQAffh nE6fVfFbcS4wv0FrQLkxBYIGE06+EIxHbLzBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=PRPwqPdvmQxPXPd4KPpFf/O4+RuV38MlJ1wmT0zz0elQgJJ4fJl34UOqN0gTQrDm89 RkqsEWyxy2NRTFJUOIaHZB/V4g3esTmD31+Xe8lYswHUmJytdVG0gObTnKXdm/IetcqV aIUaApzA2uGeKzxmQ/t3/jU8EbmdZLpGGubqE= MIME-Version: 1.0 Received: by 10.143.41.5 with SMTP id t5mr365560wfj.134.1238071914406; Thu, 26 Mar 2009 05:51:54 -0700 (PDT) Date: Thu, 26 Mar 2009 18:21:54 +0530 Message-ID: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> From: Prashant Vaibhav To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, jeff@freebsd.org Subject: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 26 Mar 2009 13:22:15 -0000 Hi everyone, I'm a potential Google Summer of Code applicant, proposing to work on improving the timecounter performance in the FreeBSD kernel (suggestion from Timecounter Performance Improvements). My qualifications are mentioned at the end of this email, for those interested. After some initial discussion in #freebsd-soc, I'm posting this to the mailing lists (and CC'ing it to specific people) for further discussion before I finalize and submit my application. The primary idea is to improve the performance and resolution of gettimeofday() and friends by creating a efficient userspace implementation of these functions, along with some supporting modifications to the kernel. According to my understanding, currently the gettimeofday() function calls into the kernel to retrieve the timing information to pass on to user apps. I propose to improve it as follows: Export the relevant timing information to a shared page in memory, which will be mapped into every user app's address space. The gettimeofday() function's implementation will then be changed to read the timestamp counter (TSC) from the processor, and use the reading in conjunction with the timing info exported by the kernel to calculate and return the time info in proper format. The TSC can be read very efficiently from userspace (currently this is the fastest and highest resolution timer available, beating HPET, PIT, RTC etc.). This will allow applications to have a very fast and more importantly, a higher resolution timer available to them. This will also pave way for optionally making the FreeBSD kernel tickless, which would help with efficiency and power consumption (the processor will be able to sleep for longer durations without having to service timer interrupts several hundred times a second). Other operating systems (like OS X) already do this to varying extent. There are several issues with this approach however, and I plan to tackle each of them so that there is no loss of functionality or accuracy, and certainly no loss of performance. The project will be completed in stages, tackling each of these issues =E2=80=94 - Implement the exporting of shared system-wide pages to be mapped into each process. (There has been some work done in this area: Avoiding syscall overhead). This page will contain timing info. - Have the kernel read and export the information related to TSC during boot-up. This is heavily processor dependent and each processor (those f= rom Intel/AMD) has its own peculiarities. The kernel should provide at least= the TSC frequency by which the TSC read from userspace can be scaled to get nanosecond time. Wall time offset at boot-time should also be exported s= o TSC can be converted to wall time. - The TSC frequency might change on certain processors with non-constant TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only way= to combat this is that the kernel be notified every time the processor frequency changes. Every cpu frequency driver will need to be updated to notify the kernel before and after a cpu freq change. The tsc frequency = will then need to be adjusted in the exported info. This does not apply to mo= dern processors (Intel Core or higher and recent AMD processors, both of whic= h have a constant tsc rate). - On multiprocessor systems, threads might bounce between different processors. There are two problems here: The TSC of each core could have= an offset relative to each other, and the TSC of each core could have a drifting frequency. The first issue is found on most multicore CPUs, and will be solved by measuring the offset at boot-time and exporting this i= nfo so that the tsc read by the user app can be corrected based on the core = it's running on. The second issue only applies to AMD Athlon X2 during C1 sta= te. This is solved by following AMD's recommendation: disable c1 clock rampi= ng during bootup and suspend/resume by updating relevant info in the northbridge configuration. - In case we have some time left before completion of GSoC, one more thing can be added. Scaling the processor frequency up and down takes a finite amount of time (tens to hundreds of microseconds). During this ti= me, the tsc frequency is undefined. Since we will be notified both before an= d after such a change (by the cpufreq drivers), an alternate source (like = HPET or RTC) can be used to measure this duration and correct the tsc offset after the switch. Given all this is handled carefully, we will be able to use the TSC read-ou= t as either: (1) an offset from the last-updated timestamp (updated HZ times every second, on each timer interrupt). Or (2) use the TSC exclusively for timing and disable the timer interrupt. Currently the first approach will be used. This will avoid having to call into the kernel to get the timing info, as well as provide finer resolution timing. The second approach is an extension to allow for a tickless kernel (not part of my proposal, but do-able in the future). To summarize: The kernel exports a shared page mapped into each process and set as read-only. This page is updated on each clock tick to contain the time. Thi= s page also contains the tsc frequency and other information, which is potentially updated every time this info changes. The userspace implementation of gettimeofday() reads the timestamp counter from the processor, and the scale, offset etc. from the shared page to convert it to nanoseconds. This offset is then added to the last updated nano time (also present in the shared page) and returned to the application. The various peculiarities of each processor's tsc implementation will be accounted for. We will also need to make comprehensive benchmarks and tests to assert the validity and performance benefits. I am not well versed with rigorous benchmarking so this part of the project would need additional thought. My qualifications / personal details: I'm a 22 year old Indian male. I'm an undergrad in Electrical Engineering & Computer Science at Jacobs University Bremen, Germany. I have years of experience in C/C++ and varying job experiences ranging from web developmen= t to human-computer interaction devices. I've taken courses in computer architecture and operating systems. More details will be listed on my application, for now I'll mention the experience most relevant to the task at hand =E2=80=94 Since August 2008, I've started and completed a port of the Darwin XNU kernel (used by OS X), for generic x86 PCs. (Webpage: http://code.google.com/p/xnu-dev) Among other things, I added lots of rtc/tsc improvements to Apple's implementation that deals with exactly the same problems I have described above. All issues were solved, and the kerne= l is being used in production of thousands of computers worldwide (including the computer I'm typing this on!). Most of the code was written by me, with support from a few other people, so I have a fair idea of the challenge and their solutions. The tsc multicore synchronization was written independentl= y by two other people, so this is the part with which I'm least familiar. The code is already implemented for XNU and it works well: so most of the work would be porting it to BSD. Since I'm the author of most of it, and have good contact with the other 3-4 people who contributed other parts, there should be no licensing issues. I've also written a SpeedStep driver for OS = X (http://code.google.com/p/xnu-speedstep), which sends clock recalibration signals to the kernel (also made relevant modifications in the kernel for this to work). What I still need to learn/plan My experience with FreeBSD is somewhat limited. I have a dragonflyBSD based home server (because freebsd didn't have drivers for its cheap ethernet card). My kernel programming experience is also limited to the XNU kernel (since about July last year) and I've helped fix a minor bug (typo in ethernet driver PCI ID) in dfbsd kernel. But I'm a fast learner, and given the very well commented and clear code in the freebsd kernel, I should be u= p to speed pretty soon. Right now I've installed freebsd in a virtual machine and am playing around with it. Will shortly try building the kernel and maybe make small modifications, figure out exactly which parts of the kerne= l will need modifications. I've also been reading the freebsd handbook, the "arch" book and the dev handbook. Another big problem for me would be making the modifications to export the shared page and map it into each process =E2=80=94 my experience is mostly = in handling the tsc/rtc code, but not in memory management, so this is something I need to learn. Lastly, I'm not very well-versed in making rigorous benchmarks. I've done simple benchmarking during the xnu kernel development, but these were limited to measuring clock ticks. A more comprehensive test plan would include mysql benchmarks and similar. Thanks everyone for reading through this humongous email! :-) Discussion commenceth =E2=80=94 Best, Prashant Vaibhav PS: I am out of town with limited connectivity so responses could be somewhat slow. My aim however is to finalize and submit the application by the end of the month. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 17:16:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2590D1065906 for ; Thu, 26 Mar 2009 17:16:19 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 86AC28FC2D for ; Thu, 26 Mar 2009 17:16:18 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by ewy19 with SMTP id 19so646364ewy.43 for ; Thu, 26 Mar 2009 10:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=JTC3Y/hJXdN7AVroXHqo5/yFOw/xdQEf1SqMIcvegpQ=; b=cQ67PJxvqo7x8VwYdux4rbehvPKdFG+j1DjnJr01DUU2wHvd/YBtFXBYu9AiDhyUqS 04ozfvDw7+u18JZTjtUdOLRtKHa1Z1aNJMTwewg7VoT57UQJWqo4c0fRifOJ4OC8rPpi 4FlI8XXO2Mhv9OwHihoBvNgvO30hptvlWKTpo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=icbmxZYoTafCf3pv1B0LAacj8215FCIbl4PV7O1gJQJJGokPZl9Pf/oOV5E1L+FY7g CcUgX2cuUvdnoeZzwAPT8SCOG2C6M/xOl/A00pUjEBru9F4r97l98J8pHSQiM1liJgX1 6atZGD9kLCYSx03lK0IMnuVRtJ45s0KHTA7N0= MIME-Version: 1.0 Received: by 10.210.11.17 with SMTP id 17mr865212ebk.25.1238087777302; Thu, 26 Mar 2009 10:16:17 -0700 (PDT) Date: Thu, 26 Mar 2009 18:16:17 +0100 Message-ID: <671bb5fc0903261016s74de6a56va2ae7f7127eef286@mail.gmail.com> From: Alexej Sokolov To: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Intel Pro 82546GB COPPER. Frames reception by disabled interrupts 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, 26 Mar 2009 17:16:25 -0000 Hello, interrupts disable: E1000_WRITE_REG(&adapter->hw, E1000_IMC, 0xffffffff); this clears interrupt mask register. Question: Will network adapter accept incoming frames and transfer them to hast memory by disabled interrupts ? Thenx, Alexej From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 21:42:49 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAF491065673 for ; Thu, 26 Mar 2009 21:42:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C5AE48FC1E for ; Thu, 26 Mar 2009 21:42:49 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 619C546B3C; Thu, 26 Mar 2009 17:42:49 -0400 (EDT) Date: Thu, 26 Mar 2009 21:42:49 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: ttw+bsd@cobbled.net In-Reply-To: <20090326114828.GA2840@holyman.cobbled.net> Message-ID: References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> <20090326114828.GA2840@holyman.cobbled.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@FreeBSD.ORG, Luigi Rizzo Subject: Re: does Copyright on source files expire ? 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, 26 Mar 2009 21:42:50 -0000 On Thu, 26 Mar 2009, ttw+bsd@cobbled.net wrote: > On 25.03-05:31, David Schultz wrote: > [ ... ] >> A person's Copyright doesn't go away just because they die, disappear, or >> fail to respond. If you can't contact them, their heirs, or whomever they >> transferred the Copyright to, you're stuck. > > yeah but it's a little like finding something. if there not about and not > reachable there isn't much they can do to stop you using it. if they popup > and make demands later then you get to choose between re-writes and haggling > (twenty shekels is standard). In some countries, such as the US, copyright violation can be a criminal, not just civil, matter. Also, in countries where copyright can be assigned, the holder listed in a file may not accurately represent who the current holder is, so while the original author may be unreachable, etc, the current holder may be alive and kicking. Robert N M Watson Computer Laboratory University of Cambridge > > point is you "can" use it, the actual copyright owner needs to sue > you; not like saying "jehovah" which may result in action by the agents > of the state. > > n.b: using the above opinion may get you crucified. > _______________________________________________ > 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 26 22:24:52 2009 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B861065672 for ; Thu, 26 Mar 2009 22:24:52 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: from mired.org (two.mired.org [74.143.213.43]) by mx1.freebsd.org (Postfix) with ESMTP id F01638FC13 for ; Thu, 26 Mar 2009 22:24:51 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers2.e313df@mired.org) Received: (qmail 23953 invoked by uid 1001); 26 Mar 2009 17:56:43 -0400 Received: from bhuda.mired.org (localhost.localdomain [127.0.0.1]) by bhuda (tmda-ofmipd) with ESMTP; Thu, 26 Mar 2009 17:56:43 -0400 Date: Thu, 26 Mar 2009 17:56:42 -0400 To: Peter Jeremy Message-ID: <20090326175642.4fafdde3@bhuda.mired.org> In-Reply-To: <20090326095802.GH56137@server.vk2pj.dyndns.org> References: <20090325084722.GC98685@onelab2.iet.unipi.it> <20090325093152.GB85469@zim.MIT.EDU> <20090326095802.GH56137@server.vk2pj.dyndns.org> Organization: Meyer Consulting X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd7.1) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEXguIzRkGnhyaz069mXhW0WHRnbrnR9WCQ6LB0CchNMAAACSUlEQVQ4jV2TQW7jMAxFGaPQOgQEdZaGMsgBrAvUA03dCxj1Uu4U2gfwQD7AGNax51NK07RcxXz6/CSl0Ij450vkPG1jzpIZM1UwDCl/xB14TWnNX8A00Qj5a0mnVFVbVUz4MeErea2HikSRqZzY894zwg9p2+/AtO8LzxFED+tNAUFeU29iFOLRxlZAcdo9A8wi8ZBMV4BKPde82Oxrvs6BTkulQIClte0DLFzzsKk9j1MBex8iUaP00Bd78S/muyFScrTXz6zLkEUxJp+SabQfNOs4f4Jpx5qSZ/304PWwlEWP1cOn/mJQR7EOD+uKhjcBLziuL7xoY5Xm+VFAUSw/LwwwsHEHxihpwV4EJH0xXRkbw1PkRw+X4pEuSJwBggqk+HEYKkiL5/74/nQkogigzQsAFrakxZyfw3wMIEEZPv4AWMfxwqE5GNxGaERjmH+PG8AE0L4/w9g0lsp1raLYAN5azQa+AOoO9NwcpFkTrG2VKNMNEL5UKUUAw34tha0z7onUG0oBoNtczE04GwFE3wCHc0ChezAJ6A1WMV81AtY7wDAJSlXwV+4cwBvsOsrQMRawfQEBz0deEZ7WNpV2szckIKo5VpDHDSDvF1GItwqqAlG01Hh50BGtVhuUkjkasg/14bYFGCgWg1fSWHvmOoJck2xdp9ZvZBHzDVTzX23TkrOn7qe5U2COEw5D4Vx3qEQpFY2Z/3QFnJxzp7YCmSMG19nOUoe869zZfOQb5ywQuWu0yCn5+8gxZz+BE7vG3j4/wbf4D/sXN9Wug1s7AAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Mike Meyer Cc: hackers@FreeBSD.ORG, Luigi Rizzo Subject: Re: does Copyright on source files expire ? 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, 26 Mar 2009 22:24:52 -0000 On Thu, 26 Mar 2009 20:58:02 +1100 Peter Jeremy wrote: > On 2009-Mar-25 05:31:52 -0400, David Schultz wrote: > >In the US, the rule that applies most of the time is that > >Copyright expires 70 years after the author dies, although there > >are many special cases where the term differs. > > And the '70' gets regularly extended following pressure from the big > content owners. As a rule of thumb, you can expect (eg) 'Mickey > Mouse' to never be released from Copyright. You forgot "and anything with a copyright newer than that one, which includes anything in the US written after March 1, 1989." after the words "Mickey Mouse". And yes, chasing down the owners is a PITA. IIRC, Paul Allen did a DVD retrospective of John Wayne's movies, and it cost more to chase down and obtain rights from all the people involved than it did to produce the DVD. But that's the way the big content owners want it. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 26 22:54:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1531065743; Thu, 26 Mar 2009 22:54:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id ACC258FC21; Thu, 26 Mar 2009 22:54:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id B699D78D28; Thu, 26 Mar 2009 22:36:41 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2QLUxv9001171; Thu, 26 Mar 2009 21:30:59 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 Mar 2009 18:21:54 +0530." <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> Date: Thu, 26 Mar 2009 21:30:59 +0000 Message-ID: <1170.1238103059@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 26 Mar 2009 22:54:32 -0000 In message <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com>, Prasha nt Vaibhav writes: >The gettimeofday() function's implementation will then be >changed to read the timestamp counter (TSC) from the processor, and use the >reading in conjunction with the timing info exported by the kernel to >calculate and return the time info in proper format. I take it as read, that you know that there are other relvant functions than gettimeofday() and that these must provide a monotonic timescale when queried interleaved ? Be aware that the TSC may not be, and may not stay synchronized across multiple cores. Further more, the TSC is not constant frequency and in particular not "known frequency" at all times. There are a lot of nasty cases to check, and a nasty interpolation required, which, in my tests some years back, totally negated any speedup from using the TSC in the first place. At the very minimum, you will have to add a quirk table where known good {CPU+MOBO+BIOS} combinations can be entered, as we find them. >This will also pave way for optionally making the >FreeBSD kernel tickless, Rubbish. Timecounters are not even closely associated with the tick or ticklessness of the kernel. [1] > - The TSC frequency might change on certain processors with non-constant > TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only way to > combat this is that the kernel be notified every time the processor > frequency changes. Every cpu frequency driver will need to be updated to > notify the kernel before and after a cpu freq change. That is not good enough, the bios may autonomously change the cpu speed and the skew from not knowing exactly _when_ and _how_ the cpu clock changed, is a significant number of microseconds, plenty of time to make strange things happen. You will want to study carefully Dave Mills work to tame the alpha chips wandering SAW clocks. Poul-Henning [1] In my mind, reworking the callout system in the kernel would be a much better more neded and much more worthwhile project. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 08:42:34 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF61106564A for ; Fri, 27 Mar 2009 08:42:34 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 701668FC14 for ; Fri, 27 Mar 2009 08:42:34 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 09:30:29 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2R8USQ9002556 for freebsd-hackers@freebsd.org; Fri, 27 Mar 2009 09:30:28 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 27 Mar 2009 09:30:23 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Message-ID: <20090327083023.GA2140@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 27 Mar 2009 08:30:29.0844 (UTC) FILETIME=[49934940:01C9AEB6] Subject: doing 'make installworld / installkernel' a second time? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 08:42:35 -0000 Hello, I've created a bootable USB key with -CURRENT like this: # mkdir -p /usr/src/CURRENT/obj # cd /usr/src/CURRENT # setenv CVSROOT :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs # cvs login # cvs checkout src # cd /usr/src/CURRENT/src # setenv MAKEOBJDIRPREFIX /usr/src/CURRENT/obj # make buildworld # make buildkernel KERNCONF=GENERIC (USB key inserted as /dev/da0) # fdisk -I da0 # fdisk -B da0 # bsdlabel -w da0s1 auto # bsdlabel -B da0s1 # newfs /dev/da0s1a # mount /dev/da0s1a /mnt # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt # echo /dev/da0s1a / ufs rw 1 1 > /mnt/etc/fstab # cat < /mnt/etc/rc.conf wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" hostname=tinyCurrent sshd_enable="YES" EOF-EOF-EOF # cp /etc/wpa_supplicant.conf /mnt/etc # umount /mnt the resulting USB key boots fine; what I'm unsure about is: can I copy /usr/src/CURRENT onto the key with # cp -rp /usr/src/CURRENT /mnt and when it is booted (in my EeePC) can I do there the installation to the SSD again with # newfs -m 0 -o space /dev/ad2s1a # mount /dev/ad2s1a /mnt # setenv MAKEOBJDIRPREFIX /CURRENT/obj # cd /CURRENT/src # make installworld DESTDIR=/mnt # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t # make distrib-dirs DESTDIR=/mnt # make distribution DESTDIR=/mnt or is /CURRENT/src and /CURRENT/obj not enough for the 2nd installation, for example because the 1st 'make installworld' has removed stuff below /usr/src/CURRENT/obj? Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 10:17:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DF4A106566B for ; Fri, 27 Mar 2009 10:17:05 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n17.bullet.mail.mud.yahoo.com (n17.bullet.mail.mud.yahoo.com [68.142.206.144]) by mx1.freebsd.org (Postfix) with SMTP id 5AFF68FC19 for ; Fri, 27 Mar 2009 10:17:05 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [68.142.194.244] by n17.bullet.mail.mud.yahoo.com with NNFMP; 27 Mar 2009 10:03:16 -0000 Received: from [68.142.201.242] by t2.bullet.mud.yahoo.com with NNFMP; 27 Mar 2009 10:03:16 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 27 Mar 2009 10:03:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 687847.51162.bm@omp403.mail.mud.yahoo.com Received: (qmail 12195 invoked by uid 60001); 27 Mar 2009 10:03:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238148196; bh=YTl6zFjDgms4QxSGdLHwKbWgZt0DnFaoOCzTixwTDng=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=NBzmHYNzT5xc1UsrLGX6u3yP8FXeABt6gXIdxaVlYDUbUqevvlyGWnjwmwTRdLJXAmRr1b336WzVyv/+W4b8v8zT0z9aEcMSHCj7qAGPpwOkQsP8ON21uyrJjIMyuIbrDnmmsckbeaJHZVu+6RpnZfK1WqwEQgPoSZrlqp769c4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=YCym9Pq6Xh9/m/feNQ5pmyfnVfj50VKbiBQl2oriQ46blQ372XiYuTEvxXxGcmNGGMscLEa5Be1LcDUGe6VFuheyBnNIditlhdvvnorWZ2QmXdj7KvJkAkwX+MRwpctHTEcnQJFBCH7RPFqOo96wZ6it+QOe3CkIlsUxK8kqvAg=; Message-ID: <17314.10813.qm@web45811.mail.sp1.yahoo.com> X-YMail-OSG: cc1piUQVM1m9ce.PwXQX_odWIjd2c6jNq1DvmmG3.5KZun6hjaF2wy6EsMlqcTxyFsSwKCPKHAQMiReJzAYqsoFG6Ob9GFRvAZxONcu_xLtSxzO2buylf03J72qFAluqzQfj7I6qkDRlOGWhz9Ry7IVS8wx02nLpR5L8FD.1.i7obhe49dykC67etkC6ZxSDefSABK9L3kxzBLUQAQ-- Received: from [58.71.34.137] by web45811.mail.sp1.yahoo.com via HTTP; Fri, 27 Mar 2009 03:03:14 PDT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 03:03:14 -0700 (PDT) From: Won De Erick To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 10:17:05 -0000 Hi All, I'm not quite familiar with FreeBSD, but I want to do the following in 6.2/7.1. /* Raise IOPL to 3 to open all I/O ports */ /* something like 'i386_iopl(3)' */ ... /* Open SMRAM access */ outl(unsigned int port, unsigned long int data); Also, I appreciate comments on the following wrapper: static inline outl(unsigned int port, unsigned long int data) { asm("outl %0, %1" : : "a" (data), "dN" (port)); } My goal is to switch the processor to SMM by triggering SMI from userland. Thanks in advance, Won From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 10:24:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B3F6106566B for ; Fri, 27 Mar 2009 10:24:01 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 328728FC15 for ; Fri, 27 Mar 2009 10:24:01 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id n2RALixB062663; Fri, 27 Mar 2009 19:21:45 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <200903271021.n2RALixB062663@sana.init-main.com> To: Won De Erick In-reply-to: Your message of "Fri, 27 Mar 2009 03:03:14 MST." <17314.10813.qm@web45811.mail.sp1.yahoo.com> Date: Fri, 27 Mar 2009 19:21:44 +0900 From: Takanori Watanabe Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 10:24:01 -0000 In message <17314.10813.qm@web45811.mail.sp1.yahoo.com>, Won De Erick wrote: > >Hi All, > >I'm not quite familiar with FreeBSD, but I want to do the following in 6.2/7.1 >. > > /* Raise IOPL to 3 to open all I/O ports */ > /* something like 'i386_iopl(3)' */ > ... see i386_get_ioperm(2) or io(4). > /* Open SMRAM access */ > outl(unsigned int port, unsigned long int data); > > >Also, I appreciate comments on the following wrapper: > >static inline outl(unsigned int port, unsigned long int data) >{ > asm("outl %0, %1" : : "a" (data), "dN" (port)); >} > > >My goal is to switch the processor to SMM by triggering SMI from userland. Probably this will work. So what do you want ask about that? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 10:36:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D18F2106564A for ; Fri, 27 Mar 2009 10:36:19 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA588FC08 for ; Fri, 27 Mar 2009 10:36:19 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ln9Q8-0000Uk-8L for freebsd-hackers@freebsd.org; Fri, 27 Mar 2009 10:36:16 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Mar 2009 10:36:16 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Mar 2009 10:36:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 27 Mar 2009 11:35:12 +0100 Lines: 60 Message-ID: References: <17314.10813.qm@web45811.mail.sp1.yahoo.com> <200903271021.n2RALixB062663@sana.init-main.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09C3938DD63C238AC27CD1AA" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090318) In-Reply-To: <200903271021.n2RALixB062663@sana.init-main.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 10:36:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09C3938DD63C238AC27CD1AA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Takanori Watanabe wrote: > In message <17314.10813.qm@web45811.mail.sp1.yahoo.com>, Won De Erick w= rote: >> Hi All, >> >> I'm not quite familiar with FreeBSD, but I want to do the following in= 6.2/7.1 >> .=20 >> >> /* Raise IOPL to 3 to open all I/O ports */ >> /* something like 'i386_iopl(3)' */ >> ... >=20 > see i386_get_ioperm(2) or io(4). >=20 >> /* Open SMRAM access */ >> outl(unsigned int port, unsigned long int data); >> >> >> Also, I appreciate comments on the following wrapper: >> >> static inline outl(unsigned int port, unsigned long int data) >> { >> asm("outl %0, %1" : : "a" (data), "dN" (port)); >> } >> >> >> My goal is to switch the processor to SMM by triggering SMI from userl= and. >=20 >=20 > Probably this will work. > So what do you want ask about that? One thing that comes to my mind is this: http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf :) --------------enig09C3938DD63C238AC27CD1AA 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) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJzKvxldnAQVacBcgRAny3AKD7EwvOu82hOxxBFPVwLjbiITxFOgCdGAx1 fa8akgT3PK5VJ+VJ0VCYDfE= =io1w -----END PGP SIGNATURE----- --------------enig09C3938DD63C238AC27CD1AA-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 12:23:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CDAA1065675 for ; Fri, 27 Mar 2009 12:23:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1A02B8FC17 for ; Fri, 27 Mar 2009 12:23:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA23147; Fri, 27 Mar 2009 14:23:47 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CCC552.5070001@icyb.net.ua> Date: Fri, 27 Mar 2009 14:23:46 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Ivan Voras References: <17314.10813.qm@web45811.mail.sp1.yahoo.com> <200903271021.n2RALixB062663@sana.init-main.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 12:23:50 -0000 on 27/03/2009 12:35 Ivan Voras said the following: > Takanori Watanabe wrote: >> In message <17314.10813.qm@web45811.mail.sp1.yahoo.com>, Won De Erick wrote: >>> Hi All, >>> >>> I'm not quite familiar with FreeBSD, but I want to do the following in 6.2/7.1 >>> . >>> >>> /* Raise IOPL to 3 to open all I/O ports */ >>> /* something like 'i386_iopl(3)' */ >>> ... >> see i386_get_ioperm(2) or io(4). >> >>> /* Open SMRAM access */ >>> outl(unsigned int port, unsigned long int data); >>> >>> >>> Also, I appreciate comments on the following wrapper: >>> >>> static inline outl(unsigned int port, unsigned long int data) >>> { >>> asm("outl %0, %1" : : "a" (data), "dN" (port)); >>> } >>> Take a look at machine/cpufunc.h >>> My goal is to switch the processor to SMM by triggering SMI from userland. >> >> Probably this will work. >> So what do you want ask about that? > > One thing that comes to my mind is this: > http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf > > :) Yeah, and IDA Pro rocks too :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 12:55:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1FCA106566C; Fri, 27 Mar 2009 12:55:59 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 869D38FC12; Fri, 27 Mar 2009 12:55:59 +0000 (UTC) (envelope-from prashant.vaibhav@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so1156025wfg.7 for ; Fri, 27 Mar 2009 05:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NKU9ufi6oZGNDyWWMse+RnGFzJny4MHIj+vXHvP1PTU=; b=omQIkFPLazsAc93UbMtEoLj1KJf9WaTb1WmA3iFb09ObC7LzuI1cEGtACE07t+c7Ln yUjAu5Fr8u97Yd1e0Ljij4joTmLt1J3uFohqRDtJ1y7jiVR2tks2rcPpHcEqT/0AuxdK 4VD8wFcViAk4puZPw30qHHwj9//SqzwPOQ5rI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LV1VXktGNSkPEpAKRohrfhVbb0GHi/idtQKrR4qQnr6CGN/jjQCSajp8ajGVVqXljK StX38EGh1ArKhXrgKC7dNREEfwbN6+8S2ZSjFr5Xk9ynkRR8wX7epCk101JE3/s8sTpG ZebIVpHKiivY90aX96bgODghgXQJSA4PVzPMA= MIME-Version: 1.0 Received: by 10.143.156.12 with SMTP id i12mr880391wfo.320.1238158558726; Fri, 27 Mar 2009 05:55:58 -0700 (PDT) In-Reply-To: <1170.1238103059@critter.freebsd.dk> References: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> <1170.1238103059@critter.freebsd.dk> Date: Fri, 27 Mar 2009 18:25:58 +0530 Message-ID: <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> From: Prashant Vaibhav To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 12:56:00 -0000 Poul-Henning, Thanks for the feedback! >[...] these must provide a monotonic timescale when queried interleaved > ? Be aware that the TSC may not be, and may not stay synchronized across > multiple cores. The TSC is documented to be monotonically increasing across all x86 processors that implement it (that I'm aware of). I know that the TSC may not stay synchronized across multiple cores *in theory*. Practically, acros= s most processors the only real issue has been an offset in the tsc of cores relative to each other (which can be measured and accounted for), or one core losing some ticks wrt the other during specific sleep states (this can be disabled and is recommended by AMD and Red Hat Linux). >Further more, the TSC is not constant frequency and in particular not > "known frequency" at all times. The TSC is guaranteed to be constant frequency on relatively modern processors from Intel and AMD =E2=80=94 whether the processor we are runnin= g on supports constant TSC rate can be queried via a CPUID instruction. The frequency can be measured at boot time by using another timing source such as the PIT, or read directly off the CPU for some models. >There are a lot of nasty cases to check, I have implemented many such 'nasty checks' over the past several months during my work with the xnu kernel =E2=80=94 I might have missed some, howe= ver. They are all done once during system boot (and during resume from sleep on some AMD dual cores). They're not very involved in my opinion. >and a nasty interpolation required, Could you please elaborate or hint me on some terms I can google about the interpolations that are required? Are you referring to the interpolation needed during measuring the tsc frequency to account for the (weird) duration of PIT? This happens during bootup only. >which, in my tests some years back, totally negated any speedup from using > the TSC in the first place. This could be an issue: I have not made extensive benchmarks. The benefit o= f using TSC could still be: the availability of a higher resolution timer which can be accessed from userspace. >At the very minimum, you will have to add a quirk table where known good > {CPU+MOBO+BIOS} combinations can be entered, as we find them. Perhaps. Or alternatively, a quirk table for known *bad* combinations. In m= y experience, most current x86 processors are OK (tested on Intel Pentium 4 and above, and AMD Athlons and above, with a variety of motherboard/BIOSes)= . >Rubbish. Timecounters are not even closely associated with the tick or > ticklessness of the kernel. My understanding could be flawed here, but the reasoning was: for a tickles kernel, we need some sort of monotonically increasing, known-rate counter a= s a replacement for periodic timer interrupts. Using the TSC (or HPET) would allow us to do so. Unless the alternative is to read the RTC at each call o= f gettimeofday() et al, which itself is not foolproof (eg. the user updates the hardware clock on a running system). I'm not aware of other high-resolution counters on the x86 platform which can serve this purpose. The PIT could be read, but it has too little range (16 bits iirc?) to be useful unless proper wraparound is done. The TSC is 64bits wide and guaranteed not to wrap around for 10 years or more (cf. Intel manuals). >the bios may autonomously change the cpu speed True. This could be an issue. For XNU and the SpeedStep driver we made, we combat this by disabling such BIOS-initiated frequency changes (refer: VoodooPower www.superhai.com/darwin.html ) >not knowing exactly _when_ and _how_ the cpu clock changed, is a > significant number of microseconds, plenty of time to make strange things > happen. Yes, for BIOS-initiated cpu frequency changes. For cpufreq driver-initiated changes, as I mentioned, the kernel can be notified before and after each change, the duration can be timed using an external timer and accounted for= . >You will want to study carefully Dave Mills work to tame the alpha chips > wandering SAW clocks. Will do. I just started reading your paper on timecounters in FreeBSD which has been quite informative! Best, Prashant Vaibhav On Fri, Mar 27, 2009 at 3:00 AM, Poul-Henning Kamp wrot= e: > In message <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com>, > Prasha > nt Vaibhav writes: > > >The gettimeofday() function's implementation will then be > >changed to read the timestamp counter (TSC) from the processor, and use > the > >reading in conjunction with the timing info exported by the kernel to > >calculate and return the time info in proper format. > > I take it as read, that you know that there are other relvant > functions than gettimeofday() and that these must provide a > monotonic timescale when queried interleaved ? > > Be aware that the TSC may not be, and may not stay synchronized > across multiple cores. > > Further more, the TSC is not constant frequency and in particular > not "known frequency" at all times. > > There are a lot of nasty cases to check, and a nasty interpolation > required, which, in my tests some years back, totally negated any > speedup from using the TSC in the first place. > > At the very minimum, you will have to add a quirk table where > known good {CPU+MOBO+BIOS} combinations can be entered, as we > find them. > > >This will also pave way for optionally making the > >FreeBSD kernel tickless, > > Rubbish. Timecounters are not even closely associated with the > tick or ticklessness of the kernel. [1] > > > - The TSC frequency might change on certain processors with > non-constant > > TSC rate (because of SpeedStep, dynamic freq scaling etc.). The only > way to > > combat this is that the kernel be notified every time the processor > > frequency changes. Every cpu frequency driver will need to be updated > to > > notify the kernel before and after a cpu freq change. > > That is not good enough, the bios may autonomously change the cpu speed > and the skew from not knowing exactly _when_ and _how_ the cpu clock > changed, is a significant number of microseconds, plenty of time > to make strange things happen. > > You will want to study carefully Dave Mills work to tame the alpha > chips wandering SAW clocks. > > Poul-Henning > > [1] In my mind, reworking the callout system in the kernel would > be a much better more neded and much more worthwhile project. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 13:46:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD641065679; Fri, 27 Mar 2009 13:46:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 10A738FC21; Fri, 27 Mar 2009 13:46:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C4A478CCB; Fri, 27 Mar 2009 13:46:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RDk7Lo004956; Fri, 27 Mar 2009 13:46:07 GMT (envelope-from phk@critter.freebsd.dk) To: Prashant Vaibhav From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 18:25:58 +0530." <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com> Date: Fri, 27 Mar 2009 13:46:07 +0000 Message-ID: <4955.1238161567@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 13:46:10 -0000 In message <17560ccf0903270555oe7d1652p7414a221aa2d6167@mail.gmail.com>, Prashant Vaibhav writes: >>[...] these must provide a monotonic timescale when queried interleaved >> ? Be aware that the TSC may not be, and may not stay synchronized across >> multiple cores. > >The TSC is documented to be monotonically increasing [...] Notice the absence of the word "regular" ? That it is "monotonically increasing" just means that it does not count backwards (except on the buggy cpu-revs where it does). It does not mean that it counts upwards at a stable or constant rate. >>Further more, the TSC is not constant frequency and in particular not >> "known frequency" at all times. > >The TSC is guaranteed to be constant frequency on relatively modern >processors from Intel and AMD [...] Which is why you will neeed a {CPU+MOBO+BIOS} table of known good combinations: the majority of systems out there does not guarantee and some of those that do lie. Or have bugs. Or both. >>There are a lot of nasty cases to check, > >They're not very involved in my opinion. Then you likely have not done enough :-) >>and a nasty interpolation required, > >Could you please elaborate or hint me on some terms I can google about the >interpolations that are required? Are you referring to the interpolation >needed during measuring the tsc frequency to account for the (weird) >duration of PIT? This happens during bootup only. I'm talking about the systems where SMM bios operations cause the different CPU's TSC to develop skew over time. >>which, in my tests some years back, totally negated any speedup from using >> the TSC in the first place. > >This could be an issue: I have not made extensive benchmarks. The benefit of >using TSC could still be: the availability of a higher resolution timer >which can be accessed from userspace. We have the same resolution today, if you dare to enable TSC in the kernel. In fact, we have even better resolution, because the "struct bintime" format is much more precise than both timespec and timeval. So far I doubt anybody but me have tried to measure that this makes a difference :-) >>At the very minimum, you will have to add a quirk table where known good >> {CPU+MOBO+BIOS} combinations can be entered, as we find them. > >Perhaps. >Or alternatively, a quirk table for known *bad* combinations. No, FreeBSD is shipped "working by default", not "possibly working" by default and particularly not in an area, where the signs of trouble are so subtle that most people don't recognize them at all and just blame it on "random buggy crap". >>Rubbish. Timecounters are not even closely associated with the tick or > >My understanding could be flawed here, but the reasoning was: for a tickles >kernel, we need some sort of monotonically increasing, known-rate counter as >a replacement for periodic timer interrupts. We already have that in FreeBSD for CPU time accounting. The crucial fact about a tickless kernel, is that it does not take an interrupt N times a second just to see if there is anything to do in the callout queue, but instead uses the hardware timer to aim an interrupt at the next time it needs to wake up. >>the bios may autonomously change the cpu speed > >True. This could be an issue. Your optimism is cute but misguided. On most laptops the bios WILL change the CPU speed without notice in reaction to temperature and battery power. Let me repeat: >> [1] In my mind, reworking the callout system in the kernel would >> be a much better more neded and much more worthwhile project. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 14:00:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C4771065675 for ; Fri, 27 Mar 2009 14:00:14 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by mx1.freebsd.org (Postfix) with SMTP id 195D88FC18 for ; Fri, 27 Mar 2009 14:00:14 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [216.252.122.219] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 27 Mar 2009 13:47:14 -0000 Received: from [69.147.65.155] by t4.bullet.sp1.yahoo.com with NNFMP; 27 Mar 2009 13:47:14 -0000 Received: from [127.0.0.1] by omp403.mail.sp1.yahoo.com with NNFMP; 27 Mar 2009 13:47:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 640805.54419.bm@omp403.mail.sp1.yahoo.com Received: (qmail 82828 invoked by uid 60001); 27 Mar 2009 13:47:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238161634; bh=uFXKEGscEawekV+JTgHtA1mfOwGbScZWXZKjeCMNihc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IJr12P3J+/IqDKKm7F2EEAL60FQo+M7ue4jaKyAdSfU7lwLWPCwkYb4vB1EkbMj2y5NQNyCUodf9GnsO/X2b6V+xQzOlrfPnngZ5ZJGeMHeO3s1ZeoZyeUyPasv70JkRZMzZxFVMbsoYL5PLE1NtxRynXHXhmzKzG2W8GLZ8dL4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KiilzO/E5JJsOMiPpuFFlkA7Nz5Vl95VO0osbmtjhZeaVCwqcpfYKq6HXFQCIMQRQ/ziBfjBPle7IQvYupftF4nTBkQNcidVNQ4TVmKNxO00b+se8yhFM1Jhjch0O0mM2aBUouaVoGLqtxccHPz4urN/kVeXKJpHK8Tn5H2WCgQ=; Message-ID: <492862.81876.qm@web45808.mail.sp1.yahoo.com> X-YMail-OSG: taXu_OYVM1nwuCIOPMMtkfoUabqJ4z.pX5W3rYy4wRFxBGg4ZzqM0cGOZnvDdrxHwVSx6tYlGLVG78bKlyoe1ThzHyHbYroJIiKv2BHiOfe.Pi.tsMubt9W1vnhXJWR0izo2Pieh5XxkusyETctrqEOntBd2ORxgAWBJbAU9SQBG1WGPfXwEBz65czA.Oh71WrvPOCzCzCkqHrXC7Jrq2vtndwdsB45u Received: from [58.71.34.137] by web45808.mail.sp1.yahoo.com via HTTP; Fri, 27 Mar 2009 06:47:14 PDT X-Mailer: YahooMailClassic/5.2.14 YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 06:47:14 -0700 (PDT) From: Won De Erick To: Ivan Voras , Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 14:00:14 -0000 --- On Fri, 3/27/09, Andriy Gapon wrote:=0A> on 27/03/200= 9 12:35 Ivan Voras said=0A> the following:=0A> > Takanori Watanabe wrote:= =0A> >> In message <17314.10813.qm@web45811.mail.sp1.yahoo.com>,=0A> Won De= Erick wrote:=0A> >>> Hi All,=0A> >>>=0A> >>> I'm not quite familiar with F= reeBSD, but I=0A> >>> want to do the following in 6.2/7.1=0A> >>> . =0A> >>= >=0A> >>>=A0 /* Raise IOPL to 3 to open all I/O ports=0A> >>> */=0A> >>>= =A0 /* something like 'i386_iopl(3)' */=0A> >>>=A0 ...=0A> >> see=A0 i386_g= et_ioperm(2) or io(4).=0A> >>=0A> >>>=A0 /* Open SMRAM access */=0A> >>>=A0= outl(unsigned int port, unsigned long=0A> >>> int data);=0A> >>>=0A> >>>= =0A> >>> Also, I appreciate comments on the following=0A> >>> wrapper:=0A> = >>>=0A> >>> static inline outl(unsigned int port, unsigned=0A> >>> long int= data)=0A> >>> {=0A> >>>=A0 asm("outl %0, %1" : : "a" (data), "dN"=0A> >>> = (port));=0A> >>> }=0A> >>>=0A> =0A> Take a look at machine/cpufunc.h=0A=0A= Oh I see. :)=0A=0A> =0A> >>> My goal is to switch the processor to SMM by= =0A> >>> triggering SMI from userland.=0A> >>=0A> >> Probably this will wor= k.=0A> >> So what do you want ask about that?=0A=0AIf it is possible, I sho= uld want to write data to certain registers or portion of a memory where th= e BIOS firmware or the BMC firmware could possibly detect it as 'reconfigur= ation', and make significant log on SEL as "System Reconfigured". If someon= e has a better idea, it is very much welcome. =0A=0A> > =0A> > One thing th= at comes to my mind is this:=0A> > http://invisiblethingslab.com/resources/= misc09/smm_cache_fun.pdf=0A=0AI will add that to the ff:=0A=0Ahttp://www.ss= i.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf=0A=0AI'v= e made the Exploit code found at the appendix runnable on FreeBSD 7.1 repla= cing some of the unsupported functions, but I'm still finding ways how to v= erify whether I've written successfully a data to the intended address or n= ot. I've replaced '/dev/xf86 with '/dev/mem'. Then opened 'dev/io' instead = of using 'i386_get_ioperm()'. Am I on the right track?=0A=0A> > =0A> > :)= =0A> =0A> Yeah, and IDA Pro rocks too :-)=0A> =0A> =0A> -- =0A> Andriy Gapo= n=0A=0A=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 14:41:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3119A106567B for ; Fri, 27 Mar 2009 14:41:39 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7004A8FC25 for ; Fri, 27 Mar 2009 14:41:38 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA26659; Fri, 27 Mar 2009 16:41:35 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49CCE59E.6020606@icyb.net.ua> Date: Fri, 27 Mar 2009 16:41:34 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Won De Erick References: <492862.81876.qm@web45808.mail.sp1.yahoo.com> In-Reply-To: <492862.81876.qm@web45808.mail.sp1.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 14:41:39 -0000 on 27/03/2009 15:47 Won De Erick said the following: > --- On Fri, 3/27/09, Andriy Gapon wrote: >> on 27/03/2009 12:35 Ivan Voras said the following: >>> One thing that comes to my mind is this: >>> http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf > > I will add that to the ff: > > http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf > > > I've made the Exploit code found at the appendix runnable on FreeBSD 7.1 > replacing some of the unsupported functions, but I'm still finding ways how to > verify whether I've written successfully a data to the intended address or not. > I've replaced '/dev/xf86 with '/dev/mem'. Then opened 'dev/io' instead of using > 'i386_get_ioperm()'. Am I on the right track? I believe yes. I made identical changes to Joanna/Rafal's code that gets a glimpse of what SMI handler does via CPU cache. Interesting read :) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 15:06:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E71D61065674 for ; Fri, 27 Mar 2009 15:06:23 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from n61.bullet.mail.sp1.yahoo.com (n61.bullet.mail.sp1.yahoo.com [98.136.44.37]) by mx1.freebsd.org (Postfix) with SMTP id A9C0F8FC13 for ; Fri, 27 Mar 2009 15:06:23 +0000 (UTC) (envelope-from won.derick@yahoo.com) Received: from [216.252.122.218] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 27 Mar 2009 15:06:23 -0000 Received: from [69.147.84.116] by t3.bullet.sp1.yahoo.com with NNFMP; 27 Mar 2009 15:06:23 -0000 Received: from [127.0.0.1] by omp208.mail.sp1.yahoo.com with NNFMP; 27 Mar 2009 15:06:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 437671.86943.bm@omp208.mail.sp1.yahoo.com Received: (qmail 79004 invoked by uid 60001); 27 Mar 2009 15:06:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1238166383; bh=3VsQOYqxv9a3vmSfzZbqu4nLCP7Po7hbbVMgx+1L7ec=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=3kO/zl9bjDKdujmr4ewTzR1Yg3rj+NVbFyZnyS3SvXgJCp6FUxBSUTFtLhYxM4a7nloU0S/QoINW6Z7CqwqPLzcvDtW6T5ItDUZG2hsBoipw3wJVdN+Hu9i2Zd/r8hO/9gx7x8fy9XiZhsjW/Rxm1n0Kq+OK16f6YlJRjnH/Dak= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=JxQFL9gBh3zOBHHnZmtb3F1XOvQvlhtyFM5/W+IOnHSpyoXI52fPGQBWpeXIrx7F2sSHp5JsGDLtEtpsobWM7DXbbcNGqFCYmLChv9uibEReob6rfQQlr0KkIRDphvAjh7CButg29b+GKwMpXJXx2x4eRPd0UBllrjknd+4rCVo=; Message-ID: <313076.76815.qm@web45801.mail.sp1.yahoo.com> X-YMail-OSG: 9_syW4UVM1krDgO3XCjtNVnPyAMjXWHDKkHtqUMCQRv58wFazvGQy6EqodJHaVkWdDj0NB1XOF1R0q9JNofEjiq09k5RGdqs95LgNXxHTngbZ0W1wpNBGAtDS64.OUoB0TrV4ORztyRXhkNt8ExpqvCBpku9wHCPI0HmbRnpLuRJmVpFBgiAs_BjcnTf4PvzU3fW6kd1PLWFSoBAmvUXAsNudnkQsCIcUwEQ18wX7Xep.UIarF1py7iGou8QJki_Ri_Te4RkOQA0re376nhNYOc- Received: from [58.71.34.137] by web45801.mail.sp1.yahoo.com via HTTP; Fri, 27 Mar 2009 08:06:23 PDT X-Mailer: YahooMailClassic/5.1.20 YahooMailWebService/0.7.289.1 Date: Fri, 27 Mar 2009 08:06:23 -0700 (PDT) From: Won De Erick To: Andriy Gapon MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: Switching to SMM with FreeBSD 6.2 onwards 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, 27 Mar 2009 15:06:24 -0000 --- On Fri, 3/27/09, Andriy Gapon wrote: > on 27/03/2009 15:47 Won De Erick said > the following: > > --- On Fri, 3/27/09, Andriy Gapon > wrote: > >> on 27/03/2009 12:35 Ivan Voras said the > following: > >>> One thing that comes to my mind is this: > >>> http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf > > > > I will add that to the ff: > > > > http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006-duflot-paper.pdf > > > > > > I've made the Exploit code found at the appendix > runnable on FreeBSD 7.1 > > replacing some of the unsupported functions, but I'm > still finding ways how to > > verify whether I've written successfully a data to the > intended address or not. > > I've replaced '/dev/xf86 with '/dev/mem'. Then opened > 'dev/io' instead of using > > 'i386_get_ioperm()'. Am I on the right track? > > I believe yes. I made identical changes to Joanna/Rafal's > code that gets a glimpse > of what SMI handler does via CPU cache. Interesting read > :) Have you tried modifying some chipset configurations? Can I know what part? I am using IBM x3650 with dual core Xeon processor. > > -- > Andriy Gapon > Hi all, is there any tool that I can use to view the memory map I/O? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 15:10:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 690681065672 for ; Fri, 27 Mar 2009 15:10:57 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from mail.pica.nl (mail.pica.nl [192.87.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id E98738FC12 for ; Fri, 27 Mar 2009 15:10:56 +0000 (UTC) (envelope-from Matthias.Apitz@oclc.org) Received: from rebelion.Sisis.de ([10.0.1.29]) by mail.pica.nl with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Mar 2009 16:10:54 +0100 Received: (from guru@localhost) by rebelion.Sisis.de (8.14.2/8.13.8/Submit) id n2RFAqAp013497 for freebsd-hackers@freebsd.org; Fri, 27 Mar 2009 16:10:52 +0100 (CET) (envelope-from matthias.apitz@oclc.org) X-Authentication-Warning: rebelion.Sisis.de: guru set sender to matthias.apitz@oclc.org using -f Date: Fri, 27 Mar 2009 16:10:52 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Message-ID: <20090327151052.GA13243@rebelion.Sisis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.0-STABLE (i386) X-OriginalArrivalTime: 27 Mar 2009 15:10:54.0784 (UTC) FILETIME=[398E3400:01C9AEEE] Subject: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthias Apitz List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 15:10:58 -0000 Hello, When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD only as $ ls -l /dev/ad* /dev/ad2 /dev/ad2s1 /dev/ad2s1a /dev/ad3 /dev/ad3a I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: $ mount /dev/ad2s1a on / (ufs, local, noatime) /dev/ad3s1a on /usr/home (ufs, local, noatime) ... and all runs fine; more details below... What could be the reason for this? Thx matthias $ uname -a FreeBSD tinyCurrent 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC i386 $ ls -l /dev/ad* crw-r----- 1 root operator 0, 79 Mar 27 15:45 /dev/ad2 crw-r----- 1 root operator 0, 80 Mar 27 15:45 /dev/ad2s1 crw-r----- 1 root operator 0, 81 Mar 27 15:45 /dev/ad2s1a crw-r----- 1 root operator 0, 83 Mar 27 15:45 /dev/ad3 crw-r----- 1 root operator 0, 84 Mar 27 15:45 /dev/ad3a $ mount /dev/da0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad2s1a on /mnt (ufs, local, read-only) $ dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Sun Mar 22 11:47:41 CET 2009 root@rebelion.Sisis.de:/usr/src/myHEAD/obj/usr/src/myHEAD/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff AMD Features=0x100000 real memory = 1064828928 (1015 MB) avail memory = 1024409600 (976 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f700000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xec00-0xec07 mem 0xf7f00000-0xf7f7ffff,0xd0000000-0xdfffffff,0xf7ec0000-0xf7efffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: mem 0xf7f80000-0xf7ffffff at device 2.1 on pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci3: on pcib1 pcib2: irq 18 at device 28.2 on pci0 pci1: on pcib2 uhci0: port 0xe400-0xe41f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f30 usbus0: on uhci0 uhci1: port 0xe480-0xe49f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: on uhci1 uhci2: port 0xe800-0xe81f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: on uhci2 uhci3: port 0xe880-0xe89f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus3: on uhci3 ehci0: mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci4: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. Timecounter "TSC" frequency 900100078 Hz quality 800 Timecounters tick every 1.000 msec usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 usbus0: 12Mbps Full Speed USB v1.0 ad2: FAILURE - SET_MULTI status=51 error=4 ad2: 3847MB at ata1-master UDMA66 ugen2.1: at usbus2 uhub0: on usbus2 ugen3.1: at usbus3 uhub1: on usbus3 ugen4.1: at usbus4 uhub2: on usbus4 ugen0.1: at usbus0 uhub3: on usbus0 ugen1.1: at usbus1 uhub4: on usbus1 ad3: FAILURE - SET_MULTI status=51 error=4 ad3: 15391MB at ata1-slave UDMA66 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 usbus3 usbus1 usbus0 uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 usbus1 usbus0 uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 usbus1 uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub2: 8 ports with 8 removable, self powered ugen4.2: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 7712MB (15794176 512 byte sectors: 255H 63S/T 983C) Root mount waiting for: usbus4 ugen4.3: at usbus4 umass1: on usbus4 umass1: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus4 umass1:1:1:-1: Attached to scbus1 (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI Status: Check Condition (probe0:umass-sim1:1:0:0): NOT READY asc:3a,0 (probe0:umass-sim1:1:0:0): Medium not present (probe0:umass-sim1:1:0:0): Unretryable error da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/da0s1a -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 14:24:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D3E81065689; Fri, 27 Mar 2009 14:24:29 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4F0D68FC29; Fri, 27 Mar 2009 14:24:27 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n2RE6xsA084417; Fri, 27 Mar 2009 21:06:59 +0700 (KRAT) (envelope-from eugen@kuzbass.ru) Message-ID: <49CCDD7D.FA83BF14@kuzbass.ru> Date: Fri, 27 Mar 2009 21:06:53 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Prashant Vaibhav References: <17560ccf0903260551v1f5cba9eu87727c0bae7baa3@mail.gmail.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Mar 2009 15:22:04 +0000 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, jeff@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 14:24:29 -0000 Prashant Vaibhav wrote: > The primary idea is to improve the performance and resolution of > gettimeofday() and friends by creating a efficient userspace implementation > of these functions, along with some supporting modifications to the kernel. Are you aware of CLOCK_*_FAST family of timecounters present in FreeBSD 7.x? If not, you may want to take a look: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/time.h#rev1.71 Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 15:27:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 185B81065672 for ; Fri, 27 Mar 2009 15:27:13 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id EAB978FC17 for ; Fri, 27 Mar 2009 15:27:12 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms070.mailsrvcs.net ([172.18.12.133]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KH600L0K88ULXSN@vms173019.mailsrvcs.net>; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms070.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Mar 2009 10:26:54 -0500 (CDT) Date: Fri, 27 Mar 2009 10:26:54 -0500 (CDT) From: Sergey Babkin To: phk@phk.freebsd.dk Message-id: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Fri, 27 Mar 2009 15:38:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 15:27:13 -0000 (Sorry for the top quoting). Probably the best implementation of gettimeofd= ay() is to have a page in the kernel mapped read-only to all the user pr= ocesses. Put the kernel's idea of time into this page. Then getting the = time becomes a simple read (OK, two reads, to make sure that no update = has happened in between). The TSC can then be used to add the precis= ion between the ticks of the kernel timer: i.e. remember the value of TS= C when the last tick happen, and the highest rate at which TSC may be ti= cking at this CPU, and export in the same page. This would guarantee thatthe time is not moving back. However there are more issues with TS= C. TSC is guaranteed to have the same value on all the processors that s= hare the same system bus. But if the machine is built of multiple buses = with bridges between them, all bets are off. Each bus may be stopped, resta= rted and clocked separately. There is no way to tell, on which CPU is th= e process currently runnning, and it may be rescheduled do a different C= PU right before or after the RDTSC instruction. -SB Ma= r 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: In message <[2]17560ccf0903260551v1f5cba9eu8= 7727c0bae7baa3@mail.gmail.com>, Prasha nt Vaibhav writes: = >The gettimeofday() function's implementation will then be >change= d to read the timestamp counter (TSC) from the processor, and use the &g= t;reading in conjunction with the timing info exported by the kernel to = >calculate and return the time info in proper format. I take it a= s read, that you know that there are other relvant functions than gettim= eofday() and that these must provide a monotonic timescale when queried = interleaved ? Be aware that the TSC may not be, and may not stay syn= chronized across multiple cores. Further more, the TSC is not con= stant frequency and in particular not "known frequency" at all times. There are a lot of nasty cases to check, and a nasty interpolation = required, which, in my tests some years back, totally negated any speedu= p from using the TSC in the first place. At the very minimum, you wi= ll have to add a quirk table where known good {CPU+MOBO+BIOS} combinatio= ns can be entered, as we find them. >This will also pave way f= or optionally making the >FreeBSD kernel tickless, Rubbish. T= imecounters are not even closely associated with the tick or ticklessnes= s of the kernel. [1] > - The TSC frequency might change on cert= ain processors with non-constant > TSC rate (because of SpeedStep, = dynamic freq scaling etc.). The only way to > combat this is that t= he kernel be notified every time the processor > frequency changes.= Every cpu frequency driver will need to be updated to > notify the= kernel before and after a cpu freq change. That is not good enough= , the bios may autonomously change the cpu speed and the skew from not k= nowing exactly _when_ and _how_ the cpu clock changed, is a significant = number of microseconds, plenty of time to make strange things happen. You will want to study carefully Dave Mills work to tame the alpha = chips wandering SAW clocks. Poul-Henning [1] In my mind, rewo= rking the callout system in the kernel would be a much better more neded= and much more worthwhile project. -- Poul-Henning Kamp | = UNIX since Zilog Zeus 3.20 [3]phk@FreeBSD.ORG | TCP= /IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe N= ever attribute to malice what can adequately be explained by incompetence.<= br>_______________________________________________ [4]freebsd-hackers@freebsd.org mailing list [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo unsubscribe, send any mail to "[6]fre= ebsd-hackers-unsubscribe@freebsd.org" References 1. 3D"mailto:phk@phk.freebsd.dk" 2. file://localhost/tmp/3D= 3. 3D"mailto:phk@FreeBSD.ORG" 4. 3D"mailto:fre= 5. 3D"http://lists.=/ 6. 3D"mailto:freebsd-hackers-unsub= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 16:36:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4B0106566C for ; Fri, 27 Mar 2009 16:36:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 343EB8FC16 for ; Fri, 27 Mar 2009 16:36:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LnEMC-000Cx8-Gs; Fri, 27 Mar 2009 18:52:32 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <49CCDA41.4060101@samsco.org> References: <49CCDA41.4060101@samsco.org> Comments: In-reply-to Scott Long message dated "Fri, 27 Mar 2009 07:53:05 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Mar 2009 18:52:32 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: amr driver broken since March 12 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, 27 Mar 2009 16:36:47 -0000 > Danny Braniss wrote: > > at least for me :-) > > [and sorry for the cross posting] > > > > old (March 12 , i know need the svn rev number but...) > > None of the commit activity on March 12 is jumping out at me as being > suspicious. However, you are now the second person who has told me > about AMR problems in 7.1 recently. If you have a precise svn change > number, it would help greatly. > > Scott my bad. the last working amr/iir is from March 12. I first detected the problem sometime later, but not later than March 23. So it has to be changes in that time frame. both drivers are showing similar symptoms: waiting for not busy the iir goes on for ever, and it's the cam that eventually panics, run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (actually not 100% true, depending if WITNESS is on or off, it sometimes just hangs). the amr seems to time out: amr0: adapter is busy thanks for looking into the problem, danny From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 16:40:08 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176FA10656CE for ; Fri, 27 Mar 2009 16:40:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id BE2A78FC08 for ; Fri, 27 Mar 2009 16:40:07 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2RG5pGM060442; Fri, 27 Mar 2009 10:05:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CCF95F.1050307@samsco.org> Date: Fri, 27 Mar 2009 10:05:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Danny Braniss References: <49CCDA41.4060101@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org X-Mailman-Approved-At: Fri, 27 Mar 2009 16:43:38 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: amr driver broken since March 12 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, 27 Mar 2009 16:40:08 -0000 Danny Braniss wrote: >> Danny Braniss wrote: >>> at least for me :-) >>> [and sorry for the cross posting] >>> >>> old (March 12 , i know need the svn rev number but...) >> None of the commit activity on March 12 is jumping out at me as being >> suspicious. However, you are now the second person who has told me >> about AMR problems in 7.1 recently. If you have a precise svn change >> number, it would help greatly. >> >> Scott > my bad. the last working amr/iir is from March 12. > I first detected the problem sometime later, but not later than March 23. > So it has to be changes in that time frame. > > both drivers are showing similar symptoms: > waiting for not busy > the iir goes on for ever, and it's the cam that eventually panics, > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > (actually not 100% true, depending if WITNESS is on or off, it sometimes > just hangs). > the amr seems to time out: > amr0: adapter is busy > > thanks for looking into the problem, > > danny > > Ok, here are a series of revisions to step through, in forward order. Make sure that you are starting with at least revision 189568. Then, update to exactly the revision numbers below, recompile the kernel, and test: 190087 190091 From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 16:40:11 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C78210656C3; Fri, 27 Mar 2009 16:40:11 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id C6BAD8FC1B; Fri, 27 Mar 2009 16:40:10 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id n2RGTGkT095250; Fri, 27 Mar 2009 11:29:16 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id n2RGTF9q095249; Fri, 27 Mar 2009 11:29:15 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Fri, 27 Mar 2009 11:29:15 -0500 From: Scott Lambert To: Danny Braniss Message-ID: <20090327162915.GQ80292@sysmon.tcworks.net> Mail-Followup-To: Danny Braniss , freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org References: <49CCDA41.4060101@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Mailman-Approved-At: Fri, 27 Mar 2009 16:43:50 +0000 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: amr driver broken since March 12 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, 27 Mar 2009 16:40:12 -0000 On Fri, Mar 27, 2009 at 06:52:32PM +0300, Danny Braniss wrote: > > Danny Braniss wrote: > > > at least for me :-) > > > [and sorry for the cross posting] > > > > > > old (March 12 , i know need the svn rev number but...) > > > > None of the commit activity on March 12 is jumping out at me as being > > suspicious. However, you are now the second person who has told me > > about AMR problems in 7.1 recently. If you have a precise svn change > > number, it would help greatly. > > > > Scott (Long) > > my bad. the last working amr/iir is from March 12. > I first detected the problem sometime later, but not later than March 23. > So it has to be changes in that time frame. I think Scott Long was actually asking if you could try to cvsup (or csup) to a date between those two and see if the problem shows there. If you go for, (23 - 12/2) + 12, something like March 17, it would help to narrow what changes could be causing the problem. If you see the problem with a March 17 kernel, you can split the time between March 12 and 17 and try again. Then just keep cutting the search space in half until you can pretty much say "This is the commit that broke things for me." It's not always possible for someone to take the time to do the binary search for the actual commit which broke things for them. But when they can, it really helps the developers. Just cutting it down from 11 days to 5 or 6 days can probably be a big help. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 16:52:42 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E85106566B for ; Fri, 27 Mar 2009 16:52:42 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD058FC21 for ; Fri, 27 Mar 2009 16:52:40 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1063218ewy.43 for ; Fri, 27 Mar 2009 09:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IwTlJuQVkU5k/Sm8UdKZVLV4PU8dNdfgO2Qf/WMGL2M=; b=ugLXd9v9+WkZNFF55SqtWYtavoFSwOUV9eRds8WkQzlCwvvBOs9LynbAsLgD4/rvnP st+LQj5pLDIA+vbO6FvPaJXoqun+5mutfvRR/hcjDI3Z0SDRMPi15KAGMp01p0RvjhtJ TK6f9A7bP3ojtkHtLmT5Iz1jHhqrRlLJOs5d8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KzqzAd3WEUnS8nFMK2FBoWb4Bb4/vqWYZJovD8O0biVMrNFRRpctRDV7xzLSx59zB5 8mWwU8b4kabVjHirFmy83FRmFMvK1UE0Sg8VjkzJjY0DhA7tqTe58hHHXZdrBf5XVSDW XSvRZr9eYxHU0mJ4GDSuVIbcz3O+nJCiMUwZc= MIME-Version: 1.0 Received: by 10.210.87.19 with SMTP id k19mr1747933ebb.62.1238172760180; Fri, 27 Mar 2009 09:52:40 -0700 (PDT) In-Reply-To: <20090327151052.GA13243@rebelion.Sisis.de> References: <20090327151052.GA13243@rebelion.Sisis.de> Date: Fri, 27 Mar 2009 17:52:40 +0100 Message-ID: <3a142e750903270952h3ba5e28fp72b39283b2a46d97@mail.gmail.com> From: "Paul B. Mahol" To: Matthias Apitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: CURRENT sees only /dev/ad2s1a, but not /dev/ad3s1a 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, 27 Mar 2009 16:52:42 -0000 On 3/27/09, Matthias Apitz wrote: > > Hello, > > When I boot my EeePC from USB key (/dev/da0s1a) -CURRENT it sees the two SSD > only > as > > $ ls -l /dev/ad* > /dev/ad2 > /dev/ad2s1 > /dev/ad2s1a > /dev/ad3 > /dev/ad3a > > I can mount /dev/ad2s1a but ofc not /dev/ad3s1a; > > when I'm booting the RELENG_7 from /dev/ad2s1a itself it looks like this: > > $ mount > /dev/ad2s1a on / (ufs, local, noatime) > /dev/ad3s1a on /usr/home (ufs, local, noatime) CURRENT have replaced geom_bsd with geom_part_bsd and that can cause various problems, search current archives for more info. -- Paul From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 16:51:39 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 575BE106566B; Fri, 27 Mar 2009 16:51:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 147C58FC12; Fri, 27 Mar 2009 16:51:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2RGpHNQ060615; Fri, 27 Mar 2009 10:51:17 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CD0405.1060704@samsco.org> Date: Fri, 27 Mar 2009 10:51:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Sergey Babkin References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> In-Reply-To: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org X-Mailman-Approved-At: Fri, 27 Mar 2009 17:02:15 +0000 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 16:51:40 -0000 I've been talking about this for years. All I need is help with the VM magic to create the page on fork. I also want two pages, one global for gettimeofday (and any other global data we can think of) and one per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: > (Sorry for the top quoting). Probably the best implementation of > gettimeofd=y() is to have > a page in the kernel mapped read-only to all the user pr=cesses. Put > the kernel's idea of time > into this page. Then getting the =ime becomes a simple read (OK, two > reads, to make sure that > no update =as happened in between). > The TSC can then be used to add the precis=on between the ticks of > the kernel timer: > i.e. remember the value of TS= when the last tick happen, and the > highest rate at which > TSC may be ti=king at this CPU, and export in the same page. This > would guarantee thatthe time is not moving back. > However there are more issues with TS=. TSC is guaranteed to have > the same value > on all the processors that s=are the same system bus. But if the > machine is built of multiple > buses =ith bridges between them, all bets are off. Each bus may be > stopped, resta=ted > and clocked separately. There is no way to tell, on which CPU is th= > process currently > runnning, and it may be rescheduled do a different C=U right before > or after the RDTSC > instruction. > -SB > Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: > > In message <[2]17560ccf0903260551v1f5cba9eu8 7727c0bae7baa3@mail.gmail.com>, Prasha > nt Vaibhav writes: > =The gettimeofday() function's implementation will then be > >change= to read the timestamp counter (TSC) from the processor, > and use the > &g=;reading in conjunction with the timing info exported by the > kernel to > =calculate and return the time info in proper format. > I take it a= read, that you know that there are other relvant > functions than gettim=ofday() and that these must provide a > monotonic timescale when queried =nterleaved ? > Be aware that the TSC may not be, and may not stay syn=hronized > across multiple cores. > Further more, the TSC is not con=tant frequency and in particular > not "known frequency" at all times. > There are a lot of nasty cases to check, and a nasty interpolation > =equired, which, in my tests some years back, totally negated any > speedu= from using the TSC in the first place. > At the very minimum, you wi=l have to add a quirk table where > known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we > find them. > >This will also pave way f=r optionally making the > >FreeBSD kernel tickless, > Rubbish. T=mecounters are not even closely associated with the > tick or ticklessnes= of the kernel. [1] > > - The TSC frequency might change on cert=in processors with > non-constant > > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The > only way to > > combat this is that t=e kernel be notified every time the > processor > > frequency changes.=very cpu frequency driver will need to be > updated to > > notify the=ernel before and after a cpu freq change. > That is not good enough= the bios may autonomously change the cpu > speed > and the skew from not k=owing exactly _when_ and _how_ the cpu > clock > changed, is a significant =umber of microseconds, plenty of time > to make strange things happen. > You will want to study carefully Dave Mills work to tame the alpha > =hips wandering SAW clocks. > Poul-Henning > [1] In my mind, rewo=king the callout system in the kernel would > be a much better more neded=nd much more worthwhile project. > -- > Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 > [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > N=ver attribute to malice what can adequately be explained by > incompetence.<=r>_______________________________________________ > [4]freebsd-hackers@freebsd.org mailing list > [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo > unsubscribe, send any mail to "[6]fre ebsd-hackers-unsubscribe@freebsd.org" > > > References > > 1. 3D"mailto:phk@phk.freebsd.dk" > 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" > 4. 3D"mailto:fre 5. 3D"http://lists.=/ > 6. 3D"mailto:freebsd-hackers-unsub_______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 17:31:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A719106566B; Fri, 27 Mar 2009 17:31:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2418FC14; Fri, 27 Mar 2009 17:31:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2C7B578CD0; Fri, 27 Mar 2009 17:31:28 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RHVRVO005740; Fri, 27 Mar 2009 17:31:27 GMT (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 10:51:17 CST." <49CD0405.1060704@samsco.org> Date: Fri, 27 Mar 2009 17:31:27 +0000 Message-ID: <5739.1238175087@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, Sergey Babkin , prashant.vaibhav@gmail.com, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 17:31:30 -0000 In message <49CD0405.1060704@samsco.org>, Scott Long writes: >I've been talking about this for years. All I need is help with the VM >magic to create the page on fork. I also want two pages, one global >for gettimeofday (and any other global data we can think of) and one >per-process for static data like getpid/getgid. Agreed, that is a good place to start. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 18:19:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9E301065680 for ; Fri, 27 Mar 2009 18:19:17 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA598FC16 for ; Fri, 27 Mar 2009 18:19:17 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by an-out-0708.google.com with SMTP id d11so747044and.13 for ; Fri, 27 Mar 2009 11:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=072cPdOVo+jrqhu6xN2dVesAoBG6ikaFPu8DMD8VXcE=; b=NFDVoB1nHsH6GaSbmGgWlHoEmrgN46+9ZSQJna81iBGVKo6hXj5O2XF6PaC8Grtusj fLxgcUX3gwoa6QBP3jFzcJJ6zgq+jhd8ITqFSU8p7kEus6+xFpGaAaund4VVgIQMkRkI x7UgLAlV5Pb80skiv8Lmi6TM4KPMqz8S9v/cA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ngb6e3gvarjINEVcT+8t4pUnOR9TbWzF3VNcJEP8puWapfyYy0BBW55cRRF8gf1LlR 6UExbOIB1rKt9QAVQYyWs53V2gm9S0ZFc7dgIIqWiUflSfreyDBWGO4iuQoWSMIsTQl3 BUiDYybeFeLu26dZaRVME6up7W26x1UgzDCQg= MIME-Version: 1.0 Received: by 10.100.206.14 with SMTP id d14mr2020519ang.67.1238177956676; Fri, 27 Mar 2009 11:19:16 -0700 (PDT) In-Reply-To: <5739.1238175087@critter.freebsd.dk> References: <49CD0405.1060704@samsco.org> <5739.1238175087@critter.freebsd.dk> Date: Fri, 27 Mar 2009 14:19:16 -0400 Message-ID: <3c0b01820903271119l4161c7b8yf74613b184add487@mail.gmail.com> From: Alexander Sack To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: attilio@freebsd.org, Scott Long , Sergey Babkin , prashant.vaibhav@gmail.com, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 18:19:18 -0000 On Fri, Mar 27, 2009 at 1:31 PM, Poul-Henning Kamp wro= te: > In message <49CD0405.1060704@samsco.org>, Scott Long writes: > >>I've been talking about this for years. =A0All I need is help with the VM >>magic to create the page on fork. =A0I also want two pages, one global >>for gettimeofday (and any other global data we can think of) and one >>per-process for static data like getpid/getgid. > > Agreed, that is a good place to start. I'm assuming folks are still in love with the TSC because it still the cheapest as oppose ACPI-fast or HPET to even contemplate this? Also I thought at least PHK's comment (Sergey mentioned it) was true regardless of bus, that the TSC is not consistent across multiple packages (and for that matter I suppose cores) due to I *think* its ISA lineage so how does this work again? Won't the rate in which you tick up be sporadic over the course of the process scheduled on different cores? (i.e. depending on what core RDTSC happened to land on) -aps From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 18:23:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4591065692; Fri, 27 Mar 2009 18:23:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7B31A8FC21; Fri, 27 Mar 2009 18:23:57 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 33D5546B09; Fri, 27 Mar 2009 14:23:57 -0400 (EDT) Date: Fri, 27 Mar 2009 18:23:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <49CD0405.1060704@samsco.org> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 18:24:00 -0000 On Fri, 27 Mar 2009, Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global for > gettimeofday (and any other global data we can think of) and one per-process > for static data like getpid/getgid. FWIW, there are some variations in schemes across OS's -- one extreme is the Linux approach, which actually exports a mini shared library in ELF format on the shared page, providing implementations of various services (such as entering system calls), time stuff, etc. Less extreme are the shared pages offered on Mac OS X, etc. Robert N M Watson Computer Laboratory University of Cambridge > > Scott > > > Sergey Babkin wrote: >> (Sorry for the top quoting). Probably the best implementation of >> gettimeofd=y() is to have >> a page in the kernel mapped read-only to all the user pr=cesses. Put >> the kernel's idea of time >> into this page. Then getting the =ime becomes a simple read (OK, two >> reads, to make sure that >> no update =as happened in between). >> The TSC can then be used to add the precis=on between the ticks of >> the kernel timer: >> i.e. remember the value of TS= when the last tick happen, and the >> highest rate at which >> TSC may be ti=king at this CPU, and export in the same page. This >> would guarantee thatthe time is not moving back. >> However there are more issues with TS=. TSC is guaranteed to have >> the same value >> on all the processors that s=are the same system bus. But if the >> machine is built of multiple >> buses =ith bridges between them, all bets are off. Each bus may be >> stopped, resta=ted >> and clocked separately. There is no way to tell, on which CPU is th= >> process currently >> runnning, and it may be rescheduled do a different C=U right before >> or after the RDTSC >> instruction. >> -SB >> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >> In message <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3@mail.gmail.com>, Prasha >> nt Vaibhav writes: >> =The gettimeofday() function's implementation will then be >> >change= to read the timestamp counter (TSC) from the processor, >> and use the >> &g=;reading in conjunction with the timing info exported by the >> kernel to >> =calculate and return the time info in proper format. >> I take it a= read, that you know that there are other relvant >> functions than gettim=ofday() and that these must provide a >> monotonic timescale when queried =nterleaved ? >> Be aware that the TSC may not be, and may not stay syn=hronized >> across multiple cores. >> Further more, the TSC is not con=tant frequency and in particular >> not "known frequency" at all times. >> There are a lot of nasty cases to check, and a nasty interpolation >> =equired, which, in my tests some years back, totally negated any >> speedu= from using the TSC in the first place. >> At the very minimum, you wi=l have to add a quirk table where >> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >> find them. >> >This will also pave way f=r optionally making the >> >FreeBSD kernel tickless, >> Rubbish. T=mecounters are not even closely associated with the >> tick or ticklessnes= of the kernel. [1] >> > - The TSC frequency might change on cert=in processors with >> non-constant >> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >> only way to >> > combat this is that t=e kernel be notified every time the >> processor >> > frequency changes.=very cpu frequency driver will need to be >> updated to >> > notify the=ernel before and after a cpu freq change. >> That is not good enough= the bios may autonomously change the cpu >> speed >> and the skew from not k=owing exactly _when_ and _how_ the cpu >> clock >> changed, is a significant =umber of microseconds, plenty of time >> to make strange things happen. >> You will want to study carefully Dave Mills work to tame the alpha >> =hips wandering SAW clocks. >> Poul-Henning >> [1] In my mind, rewo=king the callout system in the kernel would >> be a much better more neded=nd much more worthwhile project. >> -- >> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> N=ver attribute to malice what can adequately be explained by >> incompetence.<=r>_______________________________________________ >> [4]freebsd-hackers@freebsd.org mailing list >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >> unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe@freebsd.org" >> >> References >> >> 1. 3D"mailto:phk@phk.freebsd.dk" >> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >> 6. >> 3D"mailto:freebsd-hackers-unsub_______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 18:25:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C548F1065722; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 88E648FC08; Fri, 27 Mar 2009 18:25:14 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4220746B55; Fri, 27 Mar 2009 14:25:14 -0400 (EDT) Date: Fri, 27 Mar 2009 18:25:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <49CD0405.1060704@samsco.org> Message-ID: References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 18:25:15 -0000 On Fri, 27 Mar 2009, Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global for > gettimeofday (and any other global data we can think of) and one per-process > for static data like getpid/getgid. One note though -- the time to do the global page is at execve()-time. Robert N M Watson Computer Laboratory University of Cambridge > > Scott > > > Sergey Babkin wrote: >> (Sorry for the top quoting). Probably the best implementation of >> gettimeofd=y() is to have >> a page in the kernel mapped read-only to all the user pr=cesses. Put >> the kernel's idea of time >> into this page. Then getting the =ime becomes a simple read (OK, two >> reads, to make sure that >> no update =as happened in between). >> The TSC can then be used to add the precis=on between the ticks of >> the kernel timer: >> i.e. remember the value of TS= when the last tick happen, and the >> highest rate at which >> TSC may be ti=king at this CPU, and export in the same page. This >> would guarantee thatthe time is not moving back. >> However there are more issues with TS=. TSC is guaranteed to have >> the same value >> on all the processors that s=are the same system bus. But if the >> machine is built of multiple >> buses =ith bridges between them, all bets are off. Each bus may be >> stopped, resta=ted >> and clocked separately. There is no way to tell, on which CPU is th= >> process currently >> runnning, and it may be rescheduled do a different C=U right before >> or after the RDTSC >> instruction. >> -SB >> Ma= 26, 2009 06:55:04 PM, [1]phk@phk.freebsd.dk wrote: >> In message <[2]17560ccf0903260551v1f5cba9eu8 >> 7727c0bae7baa3@mail.gmail.com>, Prasha >> nt Vaibhav writes: >> =The gettimeofday() function's implementation will then be >> >change= to read the timestamp counter (TSC) from the processor, >> and use the >> &g=;reading in conjunction with the timing info exported by the >> kernel to >> =calculate and return the time info in proper format. >> I take it a= read, that you know that there are other relvant >> functions than gettim=ofday() and that these must provide a >> monotonic timescale when queried =nterleaved ? >> Be aware that the TSC may not be, and may not stay syn=hronized >> across multiple cores. >> Further more, the TSC is not con=tant frequency and in particular >> not "known frequency" at all times. >> There are a lot of nasty cases to check, and a nasty interpolation >> =equired, which, in my tests some years back, totally negated any >> speedu= from using the TSC in the first place. >> At the very minimum, you wi=l have to add a quirk table where >> known good {CPU+MOBO+BIOS} combinatio=s can be entered, as we >> find them. >> >This will also pave way f=r optionally making the >> >FreeBSD kernel tickless, >> Rubbish. T=mecounters are not even closely associated with the >> tick or ticklessnes= of the kernel. [1] >> > - The TSC frequency might change on cert=in processors with >> non-constant >> > TSC rate (because of SpeedStep, =ynamic freq scaling etc.). The >> only way to >> > combat this is that t=e kernel be notified every time the >> processor >> > frequency changes.=very cpu frequency driver will need to be >> updated to >> > notify the=ernel before and after a cpu freq change. >> That is not good enough= the bios may autonomously change the cpu >> speed >> and the skew from not k=owing exactly _when_ and _how_ the cpu >> clock >> changed, is a significant =umber of microseconds, plenty of time >> to make strange things happen. >> You will want to study carefully Dave Mills work to tame the alpha >> =hips wandering SAW clocks. >> Poul-Henning >> [1] In my mind, rewo=king the callout system in the kernel would >> be a much better more neded=nd much more worthwhile project. >> -- >> Poul-Henning Kamp | =NIX since Zilog Zeus 3.20 >> [3]phk@FreeBSD.ORG | TCP=IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> N=ver attribute to malice what can adequately be explained by >> incompetence.<=r>_______________________________________________ >> [4]freebsd-hackers@freebsd.org mailing list >> [5]http://lists.freebsd.org/mailman/listinfo/freebsd-hackersTo >> unsubscribe, send any mail to "[6]fre >> ebsd-hackers-unsubscribe@freebsd.org" >> >> References >> >> 1. 3D"mailto:phk@phk.freebsd.dk" >> 2. file://localhost/tmp/3D 3. 3D"mailto:phk@FreeBSD.ORG" >> 4. 3D"mailto:fre 5. 3D"http://lists.=/ >> 6. >> 3D"mailto:freebsd-hackers-unsub_______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 18:30:26 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEC5210656C1; Fri, 27 Mar 2009 18:30:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5468FC0C; Fri, 27 Mar 2009 18:30:26 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n2RIUL7v061016; Fri, 27 Mar 2009 12:30:21 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <49CD1B3D.3030103@samsco.org> Date: Fri, 27 Mar 2009 12:30:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Robert Watson References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org X-Mailman-Approved-At: Fri, 27 Mar 2009 19:34:31 +0000 Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 18:30:28 -0000 Robert Watson wrote: > > On Fri, 27 Mar 2009, Scott Long wrote: > >> I've been talking about this for years. All I need is help with the >> VM magic to create the page on fork. I also want two pages, one >> global for gettimeofday (and any other global data we can think of) >> and one per-process for static data like getpid/getgid. > > FWIW, there are some variations in schemes across OS's -- one extreme is > the Linux approach, which actually exports a mini shared library in ELF > format on the shared page, providing implementations of various services > (such as entering system calls), time stuff, etc. Less extreme are the > shared pages offered on Mac OS X, etc. > Yes, but I'd like to start somewhere, and considering that it's been impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB time to get the basic VM magic done, I'm keeping my expectations as modest as possible. Scott From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 20:02:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42E6E10656C6 for ; Fri, 27 Mar 2009 20:02:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 255FF8FC25 for ; Fri, 27 Mar 2009 20:02:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 0B09EAE06B; Fri, 27 Mar 2009 13:02:49 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 05BB42D603F; Fri, 27 Mar 2009 13:02:26 -0700 (PDT) Message-ID: <49CD30E9.7030501@elischer.org> Date: Fri, 27 Mar 2009 13:02:49 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Scott Long References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> In-Reply-To: <49CD0405.1060704@samsco.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 20:02:31 -0000 Scott Long wrote: > I've been talking about this for years. All I need is help with the VM > magic to create the page on fork. I also want two pages, one global > for gettimeofday (and any other global data we can think of) and one > per-process for static data like getpid/getgid. interestingly it is even feasible to have a per-thread page.. it requires that the scheduler change a page table entry tough. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 20:08:15 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFB7106566C for ; Fri, 27 Mar 2009 20:08:15 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1A4258FC22 for ; Fri, 27 Mar 2009 20:08:14 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 604FE961D8; Fri, 27 Mar 2009 13:08:50 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E4C092D6037; Fri, 27 Mar 2009 13:08:11 -0700 (PDT) Message-ID: <49CD3242.8050802@elischer.org> Date: Fri, 27 Mar 2009 13:08:34 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Scott Long References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> In-Reply-To: <49CD1B3D.3030103@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, Robert Watson , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 20:08:15 -0000 Scott Long wrote: > Robert Watson wrote: >> >> On Fri, 27 Mar 2009, Scott Long wrote: >> >>> I've been talking about this for years. All I need is help with the >>> VM magic to create the page on fork. I also want two pages, one >>> global for gettimeofday (and any other global data we can think of) >>> and one per-process for static data like getpid/getgid. >> >> FWIW, there are some variations in schemes across OS's -- one extreme >> is the Linux approach, which actually exports a mini shared library in >> ELF format on the shared page, providing implementations of various >> services (such as entering system calls), time stuff, etc. Less >> extreme are the shared pages offered on Mac OS X, etc. >> > > Yes, but I'd like to start somewhere, and considering that it's been > impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB > time to get the basic VM magic done, I'm keeping my expectations as > modest as possible. try alc.. :-) > > Scott > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 20:16:04 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CCE0106566C; Fri, 27 Mar 2009 20:16:04 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 222088FC2D; Fri, 27 Mar 2009 20:16:04 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KH6000LGIUQFY00@asmtp020.mac.com>; Fri, 27 Mar 2009 12:16:03 -0700 (PDT) Message-id: <2C3C7185-CB37-4067-B2A9-A03B5B288606@mac.com> From: Chuck Swiger To: Scott Long In-reply-to: <49CD1B3D.3030103@samsco.org> Date: Fri, 27 Mar 2009 12:16:02 -0700 References: <11609492.9579.1238167614335.JavaMail.root@vms070.mailsrvcs.net> <49CD0405.1060704@samsco.org> <49CD1B3D.3030103@samsco.org> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Fri, 27 Mar 2009 20:21:51 +0000 Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, Robert Watson , prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 20:16:05 -0000 Hi, Scott & all-- On Mar 27, 2009, at 11:30 AM, Scott Long wrote: > Robert Watson wrote: >> On Fri, 27 Mar 2009, Scott Long wrote: >>> I've been talking about this for years. All I need is help with >>> the VM magic to create the page on fork. I also want two pages, >>> one global for gettimeofday (and any other global data we can >>> think of) and one per-process for static data like getpid/getgid. >> FWIW, there are some variations in schemes across OS's -- one >> extreme is the Linux approach, which actually exports a mini shared >> library in ELF format on the shared page, providing implementations >> of various services (such as entering system calls), time stuff, >> etc. Less extreme are the shared pages offered on Mac OS X, etc. > > Yes, but I'd like to start somewhere, and considering that it's been > impossible in _5_ years to get the 30 minutes of Peter or JeffR or JHB > time to get the basic VM magic done, I'm keeping my expectations as > modest as possible. I'm not entirely sure how close the Mach/xnu and FreeBSD implementations of pmap_* stuff are, but the xnu code for commpage stuff is here: http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/pmap.c [pmap_commpage32_init(), pmap_commpage64_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/ [all :-)] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/i386/commpage/commpage_gettimeofday.s [but this one in particular] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/osfmk/vm/vm_shared_region.c [cf "COMM PAGE" comments, vm_commpage_init()] http://www.opensource.apple.com/darwinsource/Current/xnu-1228.9.59/bsd/kern/kern_fork.c [fork_create_child(), procdup(), uses of pmap_map_sharedpage()] [ ADC login might be needed, otherwise I think rwatson has been importing xnu periodically for TrustedBSD or other work, and might be able to provide similar pointers... ] Regards, -- -Chuck From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 20:23:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91CB11065673 for ; Fri, 27 Mar 2009 20:23:27 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4CDDA8FC25 for ; Fri, 27 Mar 2009 20:23:26 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so874597yxm.13 for ; Fri, 27 Mar 2009 13:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=W0mv/bhZzP7qVrfj5Whw95jdcrE6/FkJr3qKvE/GrmY=; b=doN0Z2xG5ujCErrYlS+SjLfmx8ruD3apvGU+iNiMSmCKawbbwFUGtJ/pWPMnLHFEAB 7PbhWN++/e/ZmD2NiW5IqCsbruyayi4VmghoZQpVt6MyHscUhly1NVskEkzDA11Da6mM cr1vAYH7xjI848SeJBUg5EP0Zl3HegioxqaLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=BMKIglFOyDcTWrWqrRQiz4aBfHhBhpDOlT0wlgc7bAyqsto5gSFwpG3lTSuYZtcQe+ adfAoVKLo9bU51wKkKgdScOGvjaB0IxbaU9/QsraYlqUbPtUAvD9LGMjbLtWo/BGB8ft Ds4xubz5roxooZGs3IOfHGdpGZcC7yryvxVV4= MIME-Version: 1.0 Received: by 10.100.133.2 with SMTP id g2mr2093758and.134.1238185406570; Fri, 27 Mar 2009 13:23:26 -0700 (PDT) Date: Fri, 27 Mar 2009 16:23:26 -0400 Message-ID: <3c0b01820903271323t1376671enf7be1febd30113be@mail.gmail.com> From: Alexander Sack To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Building a DDB friendly kernel/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, 27 Mar 2009 20:23:28 -0000 Hi Folks: I'm debugging an issue with a third-party driver that causes an NMI during driver initialization. It only occurs for one version of the driver thus far. I want to isolate what triggers the NMI and generally get a feel for the initialization of the hardware. I'm running a 6.x-amd64 kernel. Can someone explain to me why when I compile the kernel with default debugging options (makeoptions -g, options DDB/KDB etc. etc.) the kernel comes and boots BUT if I remove -O2 and -frename-registers (in an effort to make text even close to readible), the kernel boots and then double-faults on mounting root? I guess more importantly, what's the RIGHT way to build a DDB/KDB friendly kernel? I thought -O2 and/or -frename-registers could cause DDB to act up but perhaps I'm wrong. Thanks! -aps From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 21:14:17 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E7D106564A; Fri, 27 Mar 2009 21:14:17 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by mx1.freebsd.org (Postfix) with ESMTP id 964C28FC1C; Fri, 27 Mar 2009 21:14:17 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms074.mailsrvcs.net ([172.18.12.133]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KH600L1ROBILXXO@vms173019.mailsrvcs.net>; Fri, 27 Mar 2009 16:14:06 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms074.mailsrvcs.net (Verizon Webmail) with HTTP; Fri, 27 Mar 2009 16:14:06 -0500 (CDT) Date: Fri, 27 Mar 2009 16:14:06 -0500 (CDT) From: Sergey Babkin To: scottl@samsco.org Message-id: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Fri, 27 Mar 2009 21:52:30 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: babkin@verizon.net, freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 21:14:18 -0000 Would not a normal mmap be duplicated on fork? I'd do it as a small pseudo-= driver that allows to mmap this page. Then libc would open this pseudo-d= evice and mmap it, either in the on-load handler or on the first call of= gettimeofday(). I think, that should be it, no special magic nece= ssary. The per-process is more difficult and would require the magic= :-) Or maybe no magic a s such: just mmap the file from the /proc files= ystem. Then on fork in the child unmap this page, open the new file, and= map it. vfork will still be tricky :-) It also means wasting an extra p= age per process. -SB Mar 27, 2009 12:51:56 PM, [1]scottl@samsc= o.org wrote: I've been talking about this for years. All I need is help with = the VM magic to create the page on fork. I also want two pages, one gl= obal for gettimeofday (and any other global data we can think of) and on= e per-process for static data like getpid/getgid. Scott Sergey Babkin wrote: > (Sorry for the top quoting). Probably the= best implementation of > gettimeofd=3Dy() is to have > a= page in the kernel mapped read-only to all the user pr=3Dcesses. Put &g= t; the kernel's idea of time > into this page. Then getting the= =3Dime becomes a simple read (OK, two > reads, to make sure that<= br>> no update =3Das happened in between). References 1. file://localhost/tmp/3D"mai= From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 22:59:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675331065677; Fri, 27 Mar 2009 22:59:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 271F88FC08; Fri, 27 Mar 2009 22:59:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CDF7A46B53; Fri, 27 Mar 2009 18:59:39 -0400 (EDT) Date: Fri, 27 Mar 2009 22:59:39 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Sergey Babkin In-Reply-To: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> Message-ID: References: <33531707.21385.1238188446396.JavaMail.root@vms074.mailsrvcs.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scottl@samsco.org, freebsd-hackers@freebsd.org, attilio@freebsd.org, phk@phk.freebsd.dk, freebsd-current@freebsd.org, prashant.vaibhav@gmail.com Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 22:59:40 -0000 On Fri, 27 Mar 2009, Sergey Babkin wrote: > Would not a normal mmap be duplicated on fork? I'd do it as a small > pseudo-= driver > that allows to mmap this page. Then libc would open this pseudo-d= > evice and mmap it, > either in the on-load handler or on the first call of= > gettimeofday(). I think, that should > be it, no special magic nece= ssary. > The per-process is more difficult and would require the magic= :-) Or > maybe > no magic a s such: just mmap the file from the /proc files= ystem. > Then on fork > in the child unmap this page, open the new file, and= map it. vfork > will still be tricky :-) > It also means wasting an extra p= age per process. Part of the point of mapping in the page at execve()-time, or fork()-time for per-process pages (which I'm not entirely convinced we need yet) is to avoid the cost of an extra device open, mmap, etc, for every execve(), which can be quite expensive. I stuck a prototype page mapped from a special device exporting time information here a year or two ago: http://www.watson.org/~robert/freebsd/20080203-evilmem.diff http://www.watson.org/~robert/freebsd/evilmem_test.c This doesn't do TSC-based adjustment, just drops a timestamp in from the callout wheel, but was intended to allow Kris to do a bit of comparative benchmarking and decide if it might be a viable approach to invest further work in. Obviously, the above code should never, ever, get near a production kernel, since it was a 2-hour hack for experimental purposes. I think the right way forward is to prototype: map the page in at execve()-time in the kernel and pass the address to rtld via elf auxiliary arguments, and have rtld link it (via some or another means), exposing symbols or code or whatever, to libc. If someone wants to make it a dynamic shared object in ELF-speak, then I'm all for that as it would minimize the work rtld had to do. I guess interesting questions are whether (a) it would be desirable to have per-page, per-cpu, or per-thread mappings. If there are non-synchronized TSCs, then there might be some interesting advantages to a per-CPU page. Robert N M Watson Computer Laboratory University of Cambridge > -SB > Mar 27, 2009 12:51:56 PM, [1]scottl@samsc= o.org wrote: > > I've been talking about this for years. All I need is help with = > the VM > magic to create the page on fork. I also want two pages, one gl= > obal > for gettimeofday (and any other global data we can think of) and > on= e > per-process for static data like getpid/getgid. > Scott > Sergey Babkin wrote: > > (Sorry for the top quoting). Probably the= best implementation of > > gettimeofd=3Dy() is to have > > a= page in the kernel mapped read-only to all the user > pr=3Dcesses. Put > &g= t; the kernel's idea of time > > into this page. Then getting the= =3Dime becomes a simple read > (OK, two > > reads, to make sure that<= br>> no update =3Das happened in > between). > > > References > > 1. file://localhost/tmp/3D"mai= > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 23:02:05 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 123891065686; Fri, 27 Mar 2009 23:02:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id C3F448FC24; Fri, 27 Mar 2009 23:02:04 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 94FAD78CCD; Fri, 27 Mar 2009 23:02:03 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RN22tw007320; Fri, 27 Mar 2009 23:02:02 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 22:59:39 GMT." Date: Fri, 27 Mar 2009 23:02:02 +0000 Message-ID: <7319.1238194922@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: scottl@samsco.org, Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 23:02:06 -0000 In message , Robert Wats on writes: >I guess interesting questions are whether (a) it would be desirable to have >per-page, per-cpu, or per-thread mappings. If there are non-synchronized >TSCs, then there might be some interesting advantages to a per-CPU page. Rule #3: The only thing worse than generalizing from one example is generalizing from no examples at all. We can add those mappings when we know why we would want them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 23:05:35 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678081065679; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 414CB8FC1C; Fri, 27 Mar 2009 23:05:35 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EFE0646B53; Fri, 27 Mar 2009 19:05:34 -0400 (EDT) Date: Fri, 27 Mar 2009 23:05:34 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <7319.1238194922@critter.freebsd.dk> Message-ID: References: <7319.1238194922@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scottl@samsco.org, Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 23:05:37 -0000 On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: > In message , Robert Wats > on writes: > >> I guess interesting questions are whether (a) it would be desirable to have >> per-page, per-cpu, or per-thread mappings. If there are non-synchronized >> TSCs, then there might be some interesting advantages to a per-CPU page. > > Rule #3: > The only thing worse than generalizing from one example is > generalizing from no examples at all. > > We can add those mappings when we know why we would want them. If we believe TSCs won't be synchronized, and don't want to synchronize them ourselves, then we'll need different mapping state to get from a TSC stamp to a time on different CPUs. In which case user application threads will need to know their CPU in order to use the right conversion data (ideally without a system call, since that's part of what we're avoiding here), or use a per-CPU mapping and not know (in which case they'll need to detect and handle the very rare "preempted and migrated between read TSC and read conversion data" race). I'm not pushing a per-CPU page, but there would be some interesting advantages to supporting that. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 23:10:39 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFB611065674; Fri, 27 Mar 2009 23:10:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1508FC12; Fri, 27 Mar 2009 23:10:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 99EFA78CC9; Fri, 27 Mar 2009 23:10:38 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n2RNAcxj007363; Fri, 27 Mar 2009 23:10:38 GMT (envelope-from phk@critter.freebsd.dk) To: Robert Watson From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 27 Mar 2009 23:05:34 GMT." Date: Fri, 27 Mar 2009 23:10:38 +0000 Message-ID: <7362.1238195438@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: scottl@samsco.org, Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 27 Mar 2009 23:10:40 -0000 In message , Robert Wats on writes: >In which case user application threads will need to >know their CPU [...] Didn't jemalloc solve that problem once already ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 00:08:42 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF61E106564A; Sat, 28 Mar 2009 00:08:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A9CD78FC17; Sat, 28 Mar 2009 00:08:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 360CC46B45; Fri, 27 Mar 2009 20:08:42 -0400 (EDT) Date: Sat, 28 Mar 2009 00:08:42 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <7362.1238195438@critter.freebsd.dk> Message-ID: References: <7362.1238195438@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: scottl@samsco.org, Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 28 Mar 2009 00:08:43 -0000 On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: > In message , Robert > Wats on writes: > >> In which case user application threads will need to know their CPU [...] > > Didn't jemalloc solve that problem once already ? I think jemalloc implements thread-affinity for arenas rather than CPU-affinity in the strict sense, but I may misread. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 00:45:27 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8850106566B; Sat, 28 Mar 2009 00:45:27 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id A583B8FC15; Sat, 28 Mar 2009 00:45:27 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTPA id 1299850819; Fri, 27 Mar 2009 17:31:16 -0700 (PDT) Message-ID: <49CD6E90.6050303@FreeBSD.org> Date: Fri, 27 Mar 2009 17:25:52 -0700 From: Jason Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Robert Watson References: <7362.1238195438@critter.freebsd.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sergey Babkin , freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, Poul-Henning Kamp , freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 28 Mar 2009 00:45:28 -0000 Robert Watson wrote: > On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >> In message , >> Robert Wats on writes: >> >>> In which case user application threads will need to know their CPU [...] >> >> Didn't jemalloc solve that problem once already ? > > I think jemalloc implements thread-affinity for arenas rather than > CPU-affinity in the strict sense, but I may misread. CPU affinity is of limited use to malloc unless it can safely pin threads to CPUs. Unfortunately, malloc cannot muck with CPU affinity, since that's up to the application. Therefore, as you say, jemalloc implements (dynamically balanced) arena affinity. It might work okay in practice to use the current CPU ID to decide which arena to use, if the scheduler does not often migrate running processes. I haven't explored that possibility though, since the infrastructure for cheaply querying the CPU ID doesn't currently (to my knowledge) exist. Jason From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 11:38:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8845A10656C7; Sat, 28 Mar 2009 11:38:45 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id B13568FC0C; Sat, 28 Mar 2009 11:38:44 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by bwz8 with SMTP id 8so1253563bwz.43 for ; Sat, 28 Mar 2009 04:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=RiRf1+J3La1qKaOdeuNvzH9XeNTxakW4GwX7ycbaeto=; b=IJt7w/LL9tOjFE+Rus5TAERbpsEd6LjGeWenUIPQUo6Zh+OMvW1UgOonqn4NbpmdtX yJ5ScnD+0hnWFzjf5UikxntspGOzZNNWFGu+Bm53TUay6zmOnr6NUwTZmMZ13ebLqzab 6mR/NjVWTsI2OoKZSn4A79Iyz0q6i//JnhHyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jpU2Lr3nFAaMpKkN4yauwBE5EH+8vT57AoW9eU9OKSYvTu5y/Es73zMjxOqbN7Ekdm Q0ul7QzSZo9VVeAjHWyLBrRo2J7yTxrsd2A/ly0qNyEqsRRRxZl11egEh3q2La2u8Cja kWgO9S2ipA43eDsyzYmHZEcPc207kFYGKocRU= MIME-Version: 1.0 Received: by 10.204.62.13 with SMTP id v13mr1088495bkh.50.1238240323512; Sat, 28 Mar 2009 04:38:43 -0700 (PDT) Date: Sat, 28 Mar 2009 14:38:43 +0300 Message-ID: From: Vladimir Ermakov To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, emaste@freebsd.org Subject: Re: [problem] aac0 does not respond 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, 28 Mar 2009 11:38:46 -0000 2009/3/24 Vladimir Ermakov : >Hello, All > >Describe my problem: >have volume RAID-10 (SAS-HDD x 6) on Adaptec RAID 5805 >2 HHD of 6 have errors in smart data (damaged) >i am try read file /var/db/mysql/ibdata1 from this volume >system does not respond ( lost access to ssh ) after read 6GB data >from this >file >and print debug messages on ttyv0 hi tried load FreeBSD 6.3-RELEASE i386, mount ufs partition from this volume and read the file --------------------------------- # cat ibdata1 > /dev/null # echo $? 0 # --------------------------------- on FreeBSD 6.3-RELEASE i386 this problem does not /Vladimir Ermakov From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 13:10:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 860291065670 for ; Sat, 28 Mar 2009 13:10:15 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFF08FC13 for ; Sat, 28 Mar 2009 13:10:15 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1001060yxm.13 for ; Sat, 28 Mar 2009 06:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jYB9S2FD7z+SPTvn/CysGdwwuu1tKiQH7zW96QFXBxY=; b=ZMvk25Mmf1RFRIvFx1r9/rFe3ygSwZQIBSM6oVEFmU+wDTxfwXYSdKRDxPnpHIjaV0 acUCJt4iNUy+NMmZ0sd57XUGsv1TNhPUdSuK7tgAQosFItIO+4nPGCTFjDdfsX5ZrH+0 JCUACmZEFdW6CGzs1/HP0IcMngKsj+/0Ucf/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KRqRpDPk+JvcyZm5vRBKlQ8yjmyEUfMoqMg/+LiD26VB1H2hK7vlMM1duzqs+756LP VO/f8pcuBSMGeo8BA+lCABBzACtpGrwmOLa+yFTLiZ24ucl0MKJtZqZ8MpC+jES6kQYt sFJjWy6/fUUem8aYYOr+VuZVxdPWAQHHiKSck= MIME-Version: 1.0 Received: by 10.150.212.14 with SMTP id k14mr6216738ybg.10.1238244403540; Sat, 28 Mar 2009 05:46:43 -0700 (PDT) In-Reply-To: <49CD6E90.6050303@FreeBSD.org> References: <7362.1238195438@critter.freebsd.dk> <49CD6E90.6050303@FreeBSD.org> Date: Sat, 28 Mar 2009 07:46:43 -0500 Message-ID: <2fd864e0903280546r5eb7ae8avc96fd2d21cac1a7e@mail.gmail.com> From: Astrodog To: Jason Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 28 Mar 2009 13:20:00 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) 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, 28 Mar 2009 13:10:15 -0000 On Fri, Mar 27, 2009 at 7:25 PM, Jason Evans wrote: > Robert Watson wrote: >> >> On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >>> >>> In message , >>> Robert Wats on writes: >>> >>>> In which case user application threads will need to know their CPU [..= .] >>> >>> Didn't jemalloc solve that problem once already ? >> >> I think jemalloc implements thread-affinity for arenas rather than >> CPU-affinity in the strict sense, but I may misread. > > CPU affinity is of limited use to malloc unless it can safely pin threads= to > CPUs. =A0Unfortunately, malloc cannot muck with CPU affinity, since that'= s up > to the application. =A0Therefore, as you say, jemalloc implements (dynami= cally > balanced) arena affinity. > > It might work okay in practice to use the current CPU ID to decide which > arena to use, if the scheduler does not often migrate running processes. = =A0I > haven't explored that possibility though, since the infrastructure for > cheaply querying the CPU ID doesn't currently (to my knowledge) exist. > > Jason Hopefully, this is a more reasonable CC list, yet will still get to everyon= e... First, re: scottl's creating pages on fork, I might be able to do that. I'll give it a shot when I get back to my machine at home, and let you know if it either works, or just blows up in my face, and causes the usual brain melt I get when I poke at VM stuff. As far as thread CPU affinity goes, as I understand things, this is implemented in sched_ule, and one could certainly make a version of malloc that takes advantage of this... however, locking a thread to a CPU has some pretty significant side effects. Even if you only lock running/runnable threads to a CPU, you could end up with some horribly unbalanced scheduling, depending entirely on the load of the machine when the threads are started, and pinned, that the scheduler cannot balance, even on a system with moderate load, which would probably hurt performance more than most things one could do trying to get an accurate, fast timer. If nothing else, it'd be a nightmare on machines with intermittent high load, and it'd produce fairly inconsistent performance. For cheaply getting the current CPUID, if there's actual demand for this information in userland applications, it should be fairly easy to add to the scheduler, assuming it doesn't already exist. If JeffR, etc doesn't have time, let me know and I'll crank out a patch. --- Harrison Grundy From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 28 19:04:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AB28106566C; Sat, 28 Mar 2009 19:04:21 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id E3ABB8FC15; Sat, 28 Mar 2009 19:04:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LndpK-0000X0-WA; Sat, 28 Mar 2009 22:04:19 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <49CCF95F.1050307@samsco.org> References: <49CCDA41.4060101@samsco.org> <49CCF95F.1050307@samsco.org> Comments: In-reply-to Scott Long message dated "Fri, 27 Mar 2009 10:05:51 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Mar 2009 22:04:18 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: amr driver broken since March 12 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, 28 Mar 2009 19:04:22 -0000 > Danny Braniss wrote: > >> Danny Braniss wrote: > >>> at least for me :-) > >>> [and sorry for the cross posting] > >>> > >>> old (March 12 , i know need the svn rev number but...) > >> None of the commit activity on March 12 is jumping out at me as being > >> suspicious. However, you are now the second person who has told me > >> about AMR problems in 7.1 recently. If you have a precise svn change > >> number, it would help greatly. > >> > >> Scott > > my bad. the last working amr/iir is from March 12. > > I first detected the problem sometime later, but not later than March 23. > > So it has to be changes in that time frame. > > > > both drivers are showing similar symptoms: > > waiting for not busy > > the iir goes on for ever, and it's the cam that eventually panics, > > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > > (actually not 100% true, depending if WITNESS is on or off, it sometimes > > just hangs). > > the amr seems to time out: > > amr0: adapter is busy > > > > thanks for looking into the problem, > > > > danny > > > > > > Ok, here are a series of revisions to step through, in forward order. > Make sure that you are starting with at least revision 189568. Then, > update to exactly the revision numbers below, recompile the kernel, and > test: > > 190087 > 190091 > it seems March 12 was a bit off :-) it took some time, but I managed to close the gap: 189100 ok 189150 fails I will continue tomorrow, but this should be helpful. cheers, danny