From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 02:10: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 091A4106566B for ; Sun, 18 Jan 2009 02:10:37 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from n23.bullet.mail.mud.yahoo.com (n23.bullet.mail.mud.yahoo.com [68.142.206.162]) by mx1.freebsd.org (Postfix) with SMTP id BC6388FC21 for ; Sun, 18 Jan 2009 02:10:36 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from [68.142.194.243] by n23.bullet.mail.mud.yahoo.com with NNFMP; 18 Jan 2009 01:57:11 -0000 Received: from [68.142.201.242] by t1.bullet.mud.yahoo.com with NNFMP; 18 Jan 2009 01:57:11 -0000 Received: from [127.0.0.1] by omp403.mail.mud.yahoo.com with NNFMP; 18 Jan 2009 01:57:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 107913.65498.bm@omp403.mail.mud.yahoo.com Received: (qmail 13724 invoked by uid 60001); 18 Jan 2009 01:57:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=KpbIIB9WXpfZxPQN0FdI+OXoOF72CaB99sD1MjiOHXXsqX2/pAaGd/XXhO9+3dW93hEdR8BWJvu+ZL+wOGkRF3sdTKHTxZ+5rt7vSkID99BQlp4LxTlMnSoJbq7J2Xd14VpXOYNKdcZJxBk81d+YUR8wzgeoOBTbOBUpcZaHvbU=; X-YMail-OSG: v1qrQjgVM1mcADnp3PW.vepyQlZZpph7T3D1z2E2U0eH7vz2LPzS8Wy_IeqMAsmySaZPBnEHYPbrc91lB0zEJpmrF4OkGTwJpB9lboB7lF7wQ2CwAByw6Ot.IIFOrrm0Xl7gqcxpRhXGvPTlJFKyaZFCkvhF35kpeyuNcislb6H.t0dBn1Wvp0KFUg-- Received: from [130.86.201.132] by web45414.mail.sp1.yahoo.com via HTTP; Sat, 17 Jan 2009 17:57:10 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Sat, 17 Jan 2009 17:57:10 -0800 (PST) From: Kamlesh Patel To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Subject: Remote kernel debugging in FreeBSD using serial communication X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shilp.kamal@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2009 02:10:37 -0000 Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 My problem is my developing and target system does not have DS25 female port. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? Thanks, Kamlesh MS CS CSUS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 02:52: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 BF52F106566B for ; Sun, 18 Jan 2009 02:52:44 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id A23978FC23 for ; Sun, 18 Jan 2009 02:52:44 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 8E7C45B11; Sat, 17 Jan 2009 18:35:53 -0800 (PST) To: shilp.kamal@yahoo.com In-reply-to: Your message of "Sat, 17 Jan 2009 17:57:10 PST." <568396.13362.qm@web45414.mail.sp1.yahoo.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Comments: In-reply-to Kamlesh Patel message dated "Sat, 17 Jan 2009 17:57:10 -0800." Date: Sat, 17 Jan 2009 18:35:53 -0800 From: Bakul Shah Message-Id: <20090118023553.8E7C45B11@mail.bitblocks.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Remote kernel debugging in FreeBSD using serial communication 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, 18 Jan 2009 02:52:45 -0000 On Sat, 17 Jan 2009 17:57:10 PST Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial communication. I > got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 > > My problem is my developing and target system does not have DS25 female port. > > Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F S > erial cable or any other remote debugging idea? Get one or more modular kits like the one below: http://www.cablesnmor.com/modular-kit-db9f-rj45.aspx Now wire it according to the pinouts here: http://yost.com/computers/RJ45-serial/index.html If (in the unlikely event) you have any more RS-232 devices, you can attach a similar db{9,25}{f,m}-rj45 adapter to each -- just make sure that on the RJ-45 side signals come out as specified in the web page above (also reproduced below). Now you can use a "half-twist" 8 conductor cable to connect *any* two such devices. You can even use a 4 or 6 conductor half-twist cable with the same RJ-45 jacks since the layout is such that the more important signals are towards the middle. 1 2 3 4 5 6 7 8 CTS DCD RD SG SG TD DTR RTS From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 03:00:43 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 E8B841065679 for ; Sun, 18 Jan 2009 03:00:43 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ew0-f13.google.com (mail-ew0-f13.google.com [209.85.219.13]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2618FC21 for ; Sun, 18 Jan 2009 03:00:43 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by ewy6 with SMTP id 6so19469ewy.19 for ; Sat, 17 Jan 2009 19:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=KGc6rynqpgiageRCFicyI5gR04lYVOkdbkCdbjwdFco=; b=kJue6+wjmeQtrNVc1woPWIry+S1kZWnc3DOxI/csq4lpqr59xfr3ODaZKbCJo7RqZ1 bYgBhOuZKLnnuDTGi2cHDrLHB7W8SCIn6kSG106EwapZWBluXXSzi/bjIlOYD6Ct1Twh ogsAwtT4JamSUd7lKuiQ2sU6S85HqVR65lGOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=HRx5CFz0uDzbxkdXv7qt72/NjMqYas/aJh7yZYqvOG4HMG4nHr2q+woblcbQUbO5fa X2ZY8LTxWbm9NlbAmW73wJCNQoUB/JwQ0hlMaxfFCKFDJndCfvbKpjzkyk+6qF6ThPpz T6DDguSPECCkbG5bUGHsYH1vyn5ofZCtOwC5c= Received: by 10.210.135.17 with SMTP id i17mr3262561ebd.46.1232246349817; Sat, 17 Jan 2009 18:39:09 -0800 (PST) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id c24sm6463590ika.17.2009.01.17.18.39.08 (version=SSLv3 cipher=RC4-MD5); Sat, 17 Jan 2009 18:39:08 -0800 (PST) Date: Sun, 18 Jan 2009 02:39:05 +0000 From: RW To: freebsd-hackers@freebsd.org Message-ID: <20090118023905.5d42271c@gumby.homeunix.com> In-Reply-To: <568396.13362.qm@web45414.mail.sp1.yahoo.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.7; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Remote kernel debugging in FreeBSD using serial communication 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, 18 Jan 2009 03:00:44 -0000 On Sat, 17 Jan 2009 17:57:10 -0800 (PST) Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial > communication. I got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 > > My problem is my developing and target system does not have DS25 > female port. > > Anyone have any idea about Remote kernel debugging in FreeBSD using > DS9 F/F Serial cable or any other remote debugging idea? > Have you tried following the link about 9-pin null-modem cables on the above page? Is there a particular problem? If you go to PC World, or equivalent, a null modem cable will have 9-pin connectors. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 06:39: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 2A4571065674 for ; Sun, 18 Jan 2009 06:39:54 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8B43F8FC12 for ; Sun, 18 Jan 2009 06:39:53 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 18 Jan 2009 06:39:52 -0000 Received: from p54A3EF46.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.239.70] by mail.gmx.net (mp029) with SMTP; 18 Jan 2009 07:39:52 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/X9OIy92/X1JySY4tksustkSfwW3oYEfmXXOgPWD CryWxfgQIgE2Uq Message-ID: <4972CEB7.40505@gmx.de> Date: Sun, 18 Jan 2009 07:39:51 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: xorquewasp@googlemail.com References: <20090117231404.GB77134@logik.internal.network> In-Reply-To: <20090117231404.GB77134@logik.internal.network> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 06:39:54 -0000 xorquewasp@googlemail.com schrieb: > Hello. > > I have some C code that's compiled with -fexceptions using > the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. > > A function c_function in the C code takes a callback as an argument. > > I'm passing this function the address of a function ext_function defined > in another language (Ada, to be precise, but it seems to happen > with C++ too). The main body of my program is written in this language > so C is effectively the "foreign" code (whatever). > > If ext_function raises an exception, the exception is NOT propagated > through the C code, the process simply exits. > > To clarify: > > 1. Ada_program_main calls c_function, passing ext_function as argument. > 2. c_function calls ext_function. > 3. ext_function raises exception. > 4. process exits > > In this case, the C code lives inside a dynamic library, which is > linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified > this explicity, I'm assuming -fexceptions causes this). > > If I statically link the C code (so libgcc_s.so isn't involved, I think), > the exception is propagated correctly. > > 1. Ada_program_main calls c_function, passing ext_function as argument. > 2. c_function calls ext_function. > 3. ext_function raises exception. > 4. stack unwinds back to Ada_program_main. > 5. Ada_program_main handles exception. > > Why is it that the code can't unwind the call stack correctly? Is this > a bug? The same code seems to work correctly on Debian Lenny with the same > compiler. > > Any help would be appreciated. > xw Are more C functions involved? E.g. is the function pointer passed to qsort(), which lives in libc, which is not compiled with -fexceptions. Look at the stack trace when the exception occurs. In gdb you can use the command "catch throw" (sic) to break when an exception gets thrown. Conversely you can break at the catcher with "catch catch" (if it gets this far). From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 06:45: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 7BAEA1065673 for ; Sun, 18 Jan 2009 06:45:15 +0000 (UTC) (envelope-from grog@lemis.com) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.freebsd.org (Postfix) with ESMTP id 054108FC14 for ; Sun, 18 Jan 2009 06:45:14 +0000 (UTC) (envelope-from grog@lemis.com) Received: from dereel.lemis.com (ozlabs.org [203.10.76.45]) by ozlabs.org (Postfix) with ESMTP id 267BADE09E; Sun, 18 Jan 2009 17:33:56 +1100 (EST) Received: by dereel.lemis.com (Postfix, from userid 1004) id C577EA1DDA; Sun, 18 Jan 2009 15:22:06 +1100 (EST) Date: Sun, 18 Jan 2009 15:22:06 +1100 From: Greg 'groggy' Lehey To: Kamlesh Patel Message-ID: <20090118042206.GH5043@dereel.lemis.com> References: <568396.13362.qm@web45414.mail.sp1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="doKZ0ri6bHmN2Q5y" Content-Disposition: inline In-Reply-To: <568396.13362.qm@web45414.mail.sp1.yahoo.com> User-Agent: Mutt/1.4.2.3i Organization: The FreeBSD Project Phone: +61-3-5346-1370 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Cc: freebsd-hackers@freebsd.org Subject: Re: Remote kernel debugging in FreeBSD using serial communication 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, 18 Jan 2009 06:45:15 -0000 --doKZ0ri6bHmN2Q5y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Saturday, 17 January 2009 at 17:57:10 -0800, Kamlesh Patel wrote: > Hi All, > > I am trying remote kernel debugging in FreeBSD using serial > communication. I got the following link. > > http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 This article is inaccurate in a number of points, notably building the kernel. I'd recommend that you read the document at http://www.lemis.com/grog/Papers/Debug-tutorial/, which also gives you much more information about the debugging process. > My problem is my developing and target system does not have DS25 > female port. It doesn't have to be DB25, and it doesn't have to be female. > Anyone have any idea about Remote kernel debugging in FreeBSD using > DS9 F/F Serial cable or any other remote debugging idea? That should work just as well. There's nothing special about the link. But if you have any alternatives, don't use an async serial cable for kernel debugging. It's glacially slow, and people have had all sorts of problems with it in the course of time. Firewire is much better, and you may even find that the hardware is cheaper. Greg -- See complete headers for address and phone numbers. --doKZ0ri6bHmN2Q5y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklyrm0ACgkQIubykFB6QiPnNACfY6Uk5Ylq5ci27w6plrUe67wY ITIAn3QZ4zfhw/qx/sJtEYvRJPf4m2bP =bxHx -----END PGP SIGNATURE----- --doKZ0ri6bHmN2Q5y-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 07:07: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 57161106564A for ; Sun, 18 Jan 2009 07:07:30 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id 3A04F8FC16 for ; Sun, 18 Jan 2009 07:07:30 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0I77Uo29347; Sat, 17 Jan 2009 23:07:30 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0I77Ts25673; Sat, 17 Jan 2009 23:07:29 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Sat, 17 Jan 2009 23:07:29 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: xorquewasp@googlemail.com In-Reply-To: <20090117231404.GB77134@logik.internal.network> Message-ID: References: <20090117231404.GB77134@logik.internal.network> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 07:07:30 -0000 On Sat, 17 Jan 2009, xorquewasp@googlemail.com wrote: > Hello. > > I have some C code that's compiled with -fexceptions using > the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. > > A function c_function in the C code takes a callback as an argument. > > I'm passing this function the address of a function ext_function defined > in another language (Ada, to be precise, but it seems to happen > with C++ too). The main body of my program is written in this language > so C is effectively the "foreign" code (whatever). > > If ext_function raises an exception, the exception is NOT propagated > through the C code, the process simply exits. I tried a simple example of this in C++ and it works as expected. (I am on 7.0-RELEASE/amd64.) So it isn't completely busted, at least. Can you post an example that exhibits the problem? Ideally, something complete that can be compiled and is as simple as possible. If you can do it with C++ rather than Ada it might be easier, so people don't have to install the Ada compiler. Also please mention the commands you use to compile, and what they output when you compile using -v, and what architecture you are on. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 07:19:28 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 3CA30106566B for ; Sun, 18 Jan 2009 07:19:28 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f13.google.com (mail-ew0-f13.google.com [209.85.219.13]) by mx1.freebsd.org (Postfix) with ESMTP id 996228FC2F for ; Sun, 18 Jan 2009 07:19:27 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy6 with SMTP id 6so71450ewy.19 for ; Sat, 17 Jan 2009 23:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=vMVpg8iLnylecpPfGX0xjac3FJ54/qwK5fomgeuXzvY=; b=oQo8igbfeWeCVpNRAFOBmE2sR/L2CdrHJ+uSwLDI2fAyauWYevOP6Ohb5Pw9auOUjY LXTH/Ej5E2wHIynRi0rbolxqk96my2nwC1RINSaiosNEKX8oNxvO9RoU22J4QymPpfmj 6Y5IxCO8HHNz5FP0mF1SR5orOtMYcqJGHMtAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=j1InTGDtd8UXmw8tR70uV6f4uEA8Khi++ms6PpXAGTEksW/Mr1bZEg6ghOvOlHf8al k6U+AQH8vG+DheOtxH+crfEalwjJ1VI8O2m6DBkR90sx8Yu79+yNDlB6TdRr4mPmgvVN dxd7b6JD86oduFsTpj3xYPUi5pBdKGwJwkBzo= Received: by 10.210.35.17 with SMTP id i17mr5526282ebi.165.1232263166541; Sat, 17 Jan 2009 23:19:26 -0800 (PST) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id p10sm5398865gvf.25.2009.01.17.23.19.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Jan 2009 23:19:26 -0800 (PST) Received: by logik.internal.network (Postfix, from userid 11001) id 33C905C2B; Sun, 18 Jan 2009 07:19:24 +0000 (UTC) Date: Sun, 18 Jan 2009 07:19:24 +0000 From: xorquewasp@googlemail.com To: Christoph Mallon Message-ID: <20090118071924.GA43496@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> <4972CEB7.40505@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4972CEB7.40505@gmx.de> Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 07:19:28 -0000 On 2009-01-18 07:39:51, Christoph Mallon wrote: > > Are more C functions involved? E.g. is the function pointer passed to > qsort(), which lives in libc, which is not compiled with -fexceptions. > Look at the stack trace when the exception occurs. In gdb you can use the > command "catch throw" (sic) to break when an exception gets thrown. > Conversely you can break at the catcher with "catch catch" (if it gets this > far). Unfortunately not. That was the first thing I looked at. Here's the complete test: /* c_function.c */ #include void c_function (void (*func)(int x)) { printf ("-- %s enter\n", __func__); func (23); printf ("-- %s exit\n", __func__); } -- ada_main.adb with interfaces.c; with ada.text_io; procedure ada_main is package c renames interfaces.c; test_error : exception; procedure ext_function (x : in c.int) is begin ada.text_io.put_line ("-- ext_function " & c.int'image (x)); raise test_error; end ext_function; procedure c_function (process : access procedure (x : in c.int)); pragma import (c, c_function, "c_function"); begin ada.text_io.put_line ("-- ada_main entry"); c_function (ext_function'access); exception when test_error => ada.text_io.put_line ("-- ada_main caught test_error"); end ada_main; Compilation: gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc gcc43 -o ada_main.o -c ada_main.adb -g -fstack-check -gnatwaleFG -gnatVa -gnato -gnata gnatbind ada_main.ali gnatlink -o main-dynamic ada_main.ali c_function.so gnatbind ada_main.ali gnatlink -o main-static ada_main.ali c_function.o $ LD_LIBRARY_PATH=. ldd c_function.so c_function.so: libc.so.6 => /lib/libc.so.6 (0x2807d000) libgcc_s.so.1 => /usr/local/lib/gcc-4.2.3/libgcc_s.so.1 (0x28170000) Test: $ ./main-static -- ada_main entry -- c_function enter -- ext_function 23 -- ada_main caught test_error $ LD_LIBRARY_PATH=. ./main-dynamic -- ada_main entry -- c_function enter -- ext_function 23 raised ADA_MAIN.TEST_ERROR : ada_main.adb:15 $ LD_LIBRARY_PATH=. gdb68 ./main-dynamic (gdb) catch exception Catchpoint 1: all Ada exceptions (gdb) b __gnat_os_exit Breakpoint 2 at 0x805851b: file adaint.c, line 2116. (gdb) r Catchpoint 1, ADA_MAIN.TEST_ERROR at 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15 15 raise test_error; (gdb) bt #0 <__gnat_debug_raise_exception> (e=0x8061168) at s-except.adb:48 #1 0x0804b620 in <__gnat_raise_nodefer_with_msg> (e=0x8061168) at a-except.adb:830 #2 0x0804b698 in <__gnat_raise_exception> (e=0x8061168, message=0x8061168) at a-except.adb:870 #3 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15 #4 0x280927ae in c_function (func=0x8049bf8 ) at c_function.c:9 #5 0x08049b5c in ada_main () at ada_main.adb:24 (gdb) c Breakpoint 2, __gnat_os_exit (status=1) at adaint.c:2116 (gdb) bt #0 __gnat_os_exit (status=1) at adaint.c:2116 #1 0x0805a41e in __gnat_unhandled_terminate () at raise.c:78 #2 0x0805a1f1 in <__gnat_last_chance_handler> (except=@0x8071000) at a-elchha.adb:138 #3 0x0804ae14 in ada.exceptions.exception_traces.unhandled_exception_terminate () at a-exextr.adb:175 #4 0x0804aad2 in ada.exceptions.exception_propagation.cleanupunwind_handler (uw_version=1, uw_phases=10, uw_eclass=5138137877735301376, uw_exception=0xa, uw_context=3217024852, uw_argument=0, =134587758) at a-exexpr.adb:369 #5 0x0805c282 in _Unwind_ForcedUnwind_Phase2 (exc=0x806f000, context=0xbfbfe754) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:168 #6 0x0805c4d6 in _Unwind_Resume (exc=0x806f000) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:237 #7 0x08049cfa in ada_main.ext_function (x=23) at ada_main.adb:16 #8 0x280927ae in c_function (func=0x8049bf8 ) at c_function.c:9 #9 0x08049b5c in ada_main () at ada_main.adb:24 From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 07:41:00 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 E981D1065673 for ; Sun, 18 Jan 2009 07:41:00 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f13.google.com (mail-ew0-f13.google.com [209.85.219.13]) by mx1.freebsd.org (Postfix) with ESMTP id 528208FC0C for ; Sun, 18 Jan 2009 07:40:59 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy6 with SMTP id 6so76062ewy.19 for ; Sat, 17 Jan 2009 23:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=4d0qVK9H9baNhyIrhtcGUOMgmDWrVx36YQGNlFajKFI=; b=NUgFFW4oNZcYjubAvhe2yxMqB35B99iw+y1Cu3iqL47ppslUDzmn4kSYpwR3uoTYhQ 86F4XET34tNBfIK0kgb1RwuWamgeDgd1/mtKDxmHr1070u6oe8kCFbTXJhzd7TkYdVdg /HHRFaXkSdKLYg9nt4ca+fzXWB6ZsE3629BD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=UwDMi9Qq3qLgE4Sl5FaqmRtifHSMpxSYtNoyqnp2Ol1SFGBP85AxU15vc2TDpzDvFP PD+3NRUbetIkWOtKaRjnALtpAKVBJLgTHsicPDOSMa9ReylWJU9yHXH2zLHk3L6KoZbm pWr7i6f04RU5RTG/ZNKDLdnghDSG+nA+Eulb0= Received: by 10.210.35.17 with SMTP id i17mr5579917ebi.70.1232264459270; Sat, 17 Jan 2009 23:40:59 -0800 (PST) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id i6sm3353596gve.22.2009.01.17.23.40.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Jan 2009 23:40:58 -0800 (PST) Received: by logik.internal.network (Postfix, from userid 11001) id 475F65C2B; Sun, 18 Jan 2009 07:40:57 +0000 (UTC) Date: Sun, 18 Jan 2009 07:40:57 +0000 From: xorquewasp@googlemail.com To: Nate Eldredge Message-ID: <20090118074057.GB43496@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 07:41:01 -0000 On 2009-01-17 23:07:29, Nate Eldredge wrote: > I tried a simple example of this in C++ and it works as expected. (I am on > 7.0-RELEASE/amd64.) So it isn't completely busted, at least. > > Can you post an example that exhibits the problem? Ideally, something > complete that can be compiled and is as simple as possible. If you can do > it with C++ rather than Ada it might be easier, so people don't have to > install the Ada compiler. Also please mention the commands you use to > compile, and what they output when you compile using -v, and what > architecture you are on. Hello. You're right, the C++ example works here. I'm not sure why it didn't before. Here's a C++ version: /* main.cpp */ #include extern "C" { extern void c_function (void (*func)(int x)); } void ext_function (int x) { printf ("-- ext_function %d\n", x); throw "test_error"; } int main (void) { try { c_function (&ext_function); } catch (...) { printf ("caught test_error\n"); } return 0; } /* c_function.c */ #include void c_function (void (*func)(int x)) { printf ("-- %s enter\n", __func__); func (23); printf ("-- %s exit\n", __func__); } $ uname -smir FreeBSD 6.4-RELEASE-p1 i386 GENERIC $ gcc43 -v Using built-in specs. Target: i386-portbld-freebsd6.4 Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=43 --bindir=/usr/local/bin/gcc43 --libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4 Thread model: posix gcc version 4.3.2 (GCC) $ c++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 $ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter $ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc $ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-errors -Wno-unused-parameter $ c++ -o main-dynamic main.o c_function.so $ c++ -o main-static main.o c_function.o $ ./main-static -- c_function enter -- ext_function 23 caught test_error LD_LIBRARY_PATH=. ./main-dynamic -- c_function enter -- ext_function 23 caught test_error This example is problematic, however - the C++ compiler is 3.4.6 (I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support). From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 09:38: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 574C5106564A for ; Sun, 18 Jan 2009 09:38:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f16.google.com (mail-bw0-f16.google.com [209.85.218.16]) by mx1.freebsd.org (Postfix) with ESMTP id A5E378FC12 for ; Sun, 18 Jan 2009 09:38:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz9 with SMTP id 9so4989bwz.19 for ; Sun, 18 Jan 2009 01:38:12 -0800 (PST) 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=zoLR2c98u3jYO6O3JqRa/yix93TUbvUtCk4vkSAhz/g=; b=G4+nKAGT+gs9oW2vOV340d7q9mIPqHUEy2bqy18vy51pGDlH45bkzI0D4SfKiYYF4K oqreR0kVyNIORecvig9NaeY05JInkUBr3/eCBwGWfIyKE9LAz85FVKJGC2CAV6QNs8eN /IDATjpWeQrgzmdddnW+P8NrWXIzXZSiIEWq8= 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=uzp1iUP0iawgWY54X9THSVx5I2b2RIDvN9t7b/IUNMvrqSoGcDYhSfW34FkgW9k5AP V4is4Lf6ErHQRzUxcSVGpJDL1ADKO1qVw7JQs42p1G+uV/NKkBz8G8NAHXcJce8vzwbI 38VA2w8RQ8GOY3101J/bUpYPtfVZSjy1jzulA= MIME-Version: 1.0 Received: by 10.181.159.17 with SMTP id l17mr1007739bko.14.1232271492243; Sun, 18 Jan 2009 01:38:12 -0800 (PST) In-Reply-To: <20090118074057.GB43496@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> <20090118074057.GB43496@logik.internal.network> Date: Sun, 18 Jan 2009 01:38:12 -0800 Message-ID: <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> From: Garrett Cooper To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nate Eldredge , freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 09:38:14 -0000 On Sat, Jan 17, 2009 at 11:40 PM, wrote: > On 2009-01-17 23:07:29, Nate Eldredge wrote: >> I tried a simple example of this in C++ and it works as expected. (I am= on >> 7.0-RELEASE/amd64.) So it isn't completely busted, at least. >> >> Can you post an example that exhibits the problem? Ideally, something >> complete that can be compiled and is as simple as possible. If you can = do >> it with C++ rather than Ada it might be easier, so people don't have to >> install the Ada compiler. Also please mention the commands you use to >> compile, and what they output when you compile using -v, and what >> architecture you are on. > > Hello. > > You're right, the C++ example works here. I'm not sure why it didn't befo= re. > > Here's a C++ version: > > /* main.cpp */ > > #include > > extern "C" { > extern void > c_function (void (*func)(int x)); > } > > void > ext_function (int x) > { > printf ("-- ext_function %d\n", x); > throw "test_error"; > } > > int > main (void) > { > try { > c_function (&ext_function); > } catch (...) { > printf ("caught test_error\n"); > } > return 0; > } > > /* c_function.c */ > > #include > > void > c_function (void (*func)(int x)) > { > printf ("-- %s enter\n", __func__); > func (23); > printf ("-- %s exit\n", __func__); > } > > $ uname -smir > FreeBSD 6.4-RELEASE-p1 i386 GENERIC > > $ gcc43 -v > Using built-in specs. > Target: i386-portbld-freebsd6.4 > Configured with: ./..//gcc-4.3.2/configure --enable-languages=3Dc,ada --= disable-nls --with-system-zlib --with-libiconv-prefix=3D/usr/local --progra= m-suffix=3D43 --bindir=3D/usr/local/bin/gcc43 --libdir=3D/usr/local/lib/gcc= -4.3.2 --prefix=3D/usr/local --mandir=3D/usr/local/man --infodir=3D/usr/loc= al/info/gcc43 --build=3Di386-portbld-freebsd6.4 > Thread model: posix > gcc version 4.3.2 (GCC) > > $ c++ -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.4.6 [FreeBSD] 20060305 > > $ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror= -Wall -std=3Dc99 -pedantic-errors -Wno-unused-parameter > $ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o = -lc > $ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-e= rrors -Wno-unused-parameter > $ c++ -o main-dynamic main.o c_function.so > $ c++ -o main-static main.o c_function.o > > $ ./main-static > -- c_function enter > -- ext_function 23 > caught test_error > LD_LIBRARY_PATH=3D. ./main-dynamic > -- c_function enter > -- ext_function 23 > caught test_error > > This example is problematic, however - the C++ compiler is 3.4.6 > (I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support). I'd check the release notes between 4.2.x and 4.3.x, and see whether or not they invalidated a certain lexigraphical part of C++ that was a gray area, which could be affecting your compilation. Have you possibly discussed this very issue on the gcc lists yet? Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using? Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 09:43: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 C70E9106564A for ; Sun, 18 Jan 2009 09:43:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f15.google.com (mail-bw0-f15.google.com [209.85.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 093F48FC12 for ; Sun, 18 Jan 2009 09:43:28 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz8 with SMTP id 8so5926514bwz.12 for ; Sun, 18 Jan 2009 01:43:27 -0800 (PST) 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=V0gUVYzwnfb2+mB3iGreuKQR8Zh+opoo7VeA+4syiMU=; b=cO8dO7MnJms+hdwflCr/Y1RRjOFQfJhwwgTF2eOZhYdY37pCw+UVPYlAJszDwIopd7 EoHSD/gNSuWSPERL5D1VQ/yu/636tYcXMQTm7iyMNj8XSY+SZZpN/OCaaEbqXhfmvXns hbY3AGXC7MigFp8DgznnlxvZER7LRhQ3kDroQ= 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=HZur4O9pc+Xn7p8yQMVq5jZdtR47C6FFqWl7kSEx5Vp1Pi4gfdcwt7VkxF+FxMnWus LpklenSh/MJ14kyN/BU7ybVBYBv5yVoduH6Xns3jePn+zIPQv3o3/HATA2Ri7YCHAEQE Ju7ZlskwkDI6Wed2xp9uVM4M8e+i8pGlN2ic8= MIME-Version: 1.0 Received: by 10.181.240.7 with SMTP id s7mr1603682bkr.110.1232271807611; Sun, 18 Jan 2009 01:43:27 -0800 (PST) In-Reply-To: <722201.19666.qm@web45408.mail.sp1.yahoo.com> References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> Date: Sun, 18 Jan 2009 01:43:27 -0800 Message-ID: <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> From: Garrett Cooper To: shilp.kamal@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hackers freeBSD Subject: Re: panic: Going nowhere without my init! 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, 18 Jan 2009 09:43:30 -0000 On Sat, Jan 17, 2009 at 6:00 PM, Kamlesh Patel wrot= e: > Ya, I added three extra lines. > > --- On Thu, 1/15/09, Garrett Cooper wrote: > >> From: Garrett Cooper >> Subject: Re: panic: Going nowhere without my init! >> To: shilp.kamal@yahoo.com >> Cc: "Hackers freeBSD" >> Date: Thursday, January 15, 2009, 11:33 PM >> On Wed, Jan 14, 2009 at 9:30 PM, Kamlesh Patel >> wrote: >> > Hi All, >> > >> > Thanks for answering my previous question >> "FreeBSD kernel Debugging tools for Virtual Memory >> Module", thank you Dag-Erling Sm=F8rgrav. >> > >> > Today i made a comment in Getpid() function of >> sys/kern/kern_prot.c file and i got error of >> > >> > >> ------------------------------------------------------------------------= -------- >> > panic: Going nowhere without my init! >> > Can not dump. No dump device defined. >> > Automatic reboot in 15 seconds - press a key on the >> console to >> abort-------------------------------------------------------------------= ------------- >> > >> > Could anyone help me in solving this error? >> >> "Made a comment" -- what kind of comment? Do you >> in fact mean add >> additional code? >> -Garrett Ok...? Why not just replace the init with a working copy off of a compatibl= e CD? I still don't understand why adding a [C, etc] `comment' would cause these problems. Thanks, -Garrett PS Please don't top-post. PPS Please CC the list. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 09: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 B5190106564A for ; Sun, 18 Jan 2009 09:57:53 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id 4284E8FC14 for ; Sun, 18 Jan 2009 09:57:52 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by nf-out-0910.google.com with SMTP id h3so334926nfh.33 for ; Sun, 18 Jan 2009 01:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=qa4bbFufLgCerUz/O3jA+IjKpY0p5FKIMEOBJbrRows=; b=s44GR84D7ZY1Jau7/jQBw6HeIkXZ2IZ4AmvfS8WEEvUThuwVc9kC0jrb4/PqmMx8Ej GlH+v9kBSGiwXpRDN3qBiijQ5Fit0cnMhvUypxVDEhAFr5YNmwgHQiUUFp0aOM1HWzLe n6lc31M/MhzPiToZi7o36OVriIRASRF84OWOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=O9mby2E40yEGtehNj18Y4Nk7qXWHkw/8UFe5X3dy+0fHEGDPtpLKfJoDaETqfjijaj l7jCLkwX244St+nBx/xahRhc4741HG1S+fLk/yl8LAZuj9nVR3XTTRUl4CoXO82FvX0s lyDrlFptIyNkC1jf3grrbm3Emi5XXVujIy0no= Received: by 10.210.54.17 with SMTP id c17mr1549132eba.35.1232272672201; Sun, 18 Jan 2009 01:57:52 -0800 (PST) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id u14sm5669690gvf.31.2009.01.18.01.57.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Jan 2009 01:57:51 -0800 (PST) Received: by logik.internal.network (Postfix, from userid 11001) id EA2485C2B; Sun, 18 Jan 2009 09:57:49 +0000 (UTC) Date: Sun, 18 Jan 2009 09:57:49 +0000 From: xorquewasp@googlemail.com To: Garrett Cooper Message-ID: <20090118095749.GA63288@logik.internal.network> References: <20090117231404.GB77134@logik.internal.network> <20090118074057.GB43496@logik.internal.network> <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d6fde3d0901180138y61cf4a8bgc01fd5baa684954b@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 18 Jan 2009 09:57:53 -0000 On 2009-01-18 01:38:12, Garrett Cooper wrote: > > I'd check the release notes between 4.2.x and 4.3.x, and see whether > or not they invalidated a certain lexigraphical part of C++ that was a > gray area, which could be affecting your compilation. Have you > possibly discussed this very issue on the gcc lists yet? Hello. Just want to clarify that the C++ example I just gave was because someone specifically asked for it. I don't think the problem is specific to a language (and I'm not even using C++) as gcc exception handling is language independent. Right now, I'm assuming that this is a bug that's turned up in (at least) 4.3.2 on FreeBSD (works on Debian). I haven't gone to the gcc lists yet because it seems like this problem only happens on FreeBSD. They're for later... > > Also, what CFLAGS / CXXFLAGS / CPUTYPE are you using? > Exactly what was shown above plus -O switches - For C: -fexceptions -O2 -g -W -Werror -Wall -std=c99 -pedantic-errors -Wno-unused-parameter For Ada: -O3 -g -fstack-check -gnatwaleFG -gnatVa -gnato -gnata thanks, xw From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 12:38: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 5C9921065672 for ; Sun, 18 Jan 2009 12:38:19 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mx1.freebsd.org (Postfix) with ESMTP id CC8D48FC08 for ; Sun, 18 Jan 2009 12:38:18 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by bwz7 with SMTP id 7so10886bwz.19 for ; Sun, 18 Jan 2009 04:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=92238D9MMgphdq6g+jrSal/Yrb4shvq+ker2XlycaEU=; b=BXJXPxXcncKCS7WPLKtPhTmSxJDMdHpN/32BzdvLxPUpt5gMI9B0VYGc4kYXo1cDXP byIalnSZfu1RAM2fujuYeTlVp63RTHm7Onb9eWFLv1rK5oYybwj6Bq+nXN4NEh07+ow7 dk8lQammAanFmAWmWPjeQjfERKi/nbMADseBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Op8e5ij9WKkBlB/KQuf4Z3buMhUl72xzfTUyk4hi+hHAnckktpGr4WEf3ynu8W7znD GdjM4sr4l7TaHGP4j9lnGfj/rACrK8ZrE6vTVah2hNj2BUwJsoLM8alJUATuzS5mZyk9 QxMkbqbf/Xw32oaORvUWgr91TPNdlzOfx/atE= Received: by 10.103.222.1 with SMTP id z1mr2064917muq.51.1232282200696; Sun, 18 Jan 2009 04:36:40 -0800 (PST) Received: by 10.103.137.8 with HTTP; Sun, 18 Jan 2009 04:36:40 -0800 (PST) Message-ID: Date: Sun, 18 Jan 2009 10:36:40 -0200 From: "Carlos A. M. dos Santos" To: "lazaax -" In-Reply-To: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: admin jop 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, 18 Jan 2009 12:38:20 -0000 On Sat, Jan 17, 2009 at 12:49 PM, lazaax - wrote: > hi hackers, is someone that can tell me how mach money can a company > pay me each mount for admin a bsd server installed in the company, i > will adminthe server remotly, is not a stable jop.... please can tell > me on us dolar This list is dedicated to discuss the development of FreeBSD. Please ask at freebsd-jobs or at -questios. Also, if you look at the -jobs archive you will find a lot of job offerings that can help you: http://lists.freebsd.org/pipermail/freebsd-jobs/ -- cd /usr/ports/sysutils/life make clean From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 12:11: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 E280D10656C3; Mon, 19 Jan 2009 12:11:53 +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 DBF718FC0A; Mon, 19 Jan 2009 12:11:52 +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 OAA10550; Mon, 19 Jan 2009 14:11:49 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49746E05.1070109@icyb.net.ua> Date: Mon, 19 Jan 2009 14:11:49 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: ich watchdog vs intel smm code 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, 19 Jan 2009 12:11:57 -0000 Some time earlier I reported that ichwd driver doesn't produce any effect on my system with Intel DG33TL motherboard when watchdog timer is allowed to expire. I did some investigation and also discussed the issue with a maintainer of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is present on most of Intel motherboards with ICH9 chipset. All evidence seems to point in one direction - Intel SMM code. It seems that ICH9 always gets configured by BIOS to produce an SMI when a watchdog timer expires. Also, ICH watchdog has a logic to cause a reboot if its timer expires twice in a row, this is to avoid a potential hang in SMI handler. ICH9 allows SMI to be globally enabled and disabled. BIOS configures it to be enabled. Sometimes this bit is locked down (by BIOS), so it's not possible to change it, but sometimes it is not locked. So, if we globally disable SMI, then the watchdog in ICH9 does indeed cause a reboot. Evidently this happens after the timer expires twice in row. My conclusion is that SMI handler installed by BIOS somehow acknowledges watchdog SMI (e.g. clears a certain status bit, or performs watchdog timer reload). But it doesn't execute any "corrective" action. My guess is there might some configuration (or some other form of massaging) that needs to be done in order to convince SMM code to perform a reboot upon watchdog SMI. It would be nice if we had some Intel insiders who could provide a glimpse into Intel SMM code logic with respect to the watchdog. Finally some technical details: NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: pmbase+0x0068: 0x1200 (TCO1_CNT) in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, "End of SMI (EOS)" bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: pmbase+0x0030: 0x0000203b (SMI_EN) "No Reboot (NR)" bit of GCS register is zero: 0x3410: 0x00c01444 -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 12:27:25 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 1000310656D8; Mon, 19 Jan 2009 12:27:25 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id C86B38FC1C; Mon, 19 Jan 2009 12:27:24 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (93-152-14-233.daisydsl.managedbroadband.co.uk [93.152.14.233]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n0JCRMRL061121; Mon, 19 Jan 2009 12:27:23 GMT (envelope-from ken@mthelicon.com) Message-ID: From: "Pegasus Mc Cleaft" To: "Andriy Gapon" , , References: <49746E05.1070109@icyb.net.ua> In-Reply-To: <49746E05.1070109@icyb.net.ua> Date: Mon, 19 Jan 2009 12:27:22 -0000 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit 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 X-Antivirus: avast! (VPS 090118-0, 18/01/2009), Outbound message X-Antivirus-Status: Clean Cc: Subject: Re: ich watchdog vs intel smm code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2009 12:27:25 -0000 ----- Original Message ----- From: "Andriy Gapon" To: ; Sent: Monday, January 19, 2009 12:11 PM Subject: ich watchdog vs intel smm code > > Some time earlier I reported that ichwd driver doesn't produce any > effect on my system with Intel DG33TL motherboard when watchdog timer is > allowed to expire. > I did some investigation and also discussed the issue with a maintainer > of Linux iTCO_wdt driver, Wim Van Sebroeck. He told me that the issue is > present on most of Intel motherboards with ICH9 chipset. > > All evidence seems to point in one direction - Intel SMM code. > It seems that ICH9 always gets configured by BIOS to produce an SMI when > a watchdog timer expires. Also, ICH watchdog has a logic to cause a > reboot if its timer expires twice in a row, this is to avoid a potential > hang in SMI handler. > ICH9 allows SMI to be globally enabled and disabled. BIOS configures it > to be enabled. Sometimes this bit is locked down (by BIOS), so it's not > possible to change it, but sometimes it is not locked. > So, if we globally disable SMI, then the watchdog in ICH9 does indeed > cause a reboot. Evidently this happens after the timer expires twice in > row. > > My conclusion is that SMI handler installed by BIOS somehow acknowledges > watchdog SMI (e.g. clears a certain status bit, or performs watchdog > timer reload). But it doesn't execute any "corrective" action. > > My guess is there might some configuration (or some other form of > massaging) that needs to be done in order to convince SMM code to > perform a reboot upon watchdog SMI. > > It would be nice if we had some Intel insiders who could provide a > glimpse into Intel SMM code logic with respect to the watchdog. > > Finally some technical details: > > NMI2SMI_EN and TCO_LOCK bits of TCO1_CNT are set 1: > pmbase+0x0068: 0x1200 (TCO1_CNT) > > in SMI_EN register TCO_EN bit is 1, GBL_SMI_EN is 1, "End of SMI > (EOS)" bit is 1 and (not sure if this matters) LEGACY_USB_EN is 1: > pmbase+0x0030: 0x0000203b (SMI_EN) > > "No Reboot (NR)" bit of GCS register is zero: > 0x3410: 0x00c01444 I have a simmilar problem on my gigabyte motherboard (one of the X48 ones), however, I believe the fault to be in hardware and not in firmware or software.. Mentioned in the datasheet for the ICH9, the speaker pin is used as a configuration pin while reset it asserted. If a logic 1 is present on this pin when reset is deasserted, the ICH9 chip locks out the ability for software to enable the watchdog. With the ichwd driver for BSD, this condition is announced with a message like "Watchdog present, but disabled in BIOS". (Well.. something close to that) ~Peg From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 12:37: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 3948D106564A; Mon, 19 Jan 2009 12:37:17 +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 336F58FC34; Mon, 19 Jan 2009 12:37:15 +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 OAA11784; Mon, 19 Jan 2009 14:37:10 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <497473F5.4030506@icyb.net.ua> Date: Mon, 19 Jan 2009 14:37:09 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Pegasus Mc Cleaft References: <49746E05.1070109@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-acpi@freebsd.org Subject: Re: ich watchdog vs intel smm code 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, 19 Jan 2009 12:37:17 -0000 on 19/01/2009 14:27 Pegasus Mc Cleaft said the following: > > ----- Original Message ----- From: "Andriy Gapon" [snip] >> So, if we globally disable SMI, then the watchdog in ICH9 does indeed >> cause a reboot. Evidently this happens after the timer expires twice >> in row. [snip] > Mentioned in the datasheet for the ICH9, the speaker pin is used as a > configuration pin while reset it asserted. If a logic 1 is present on > this pin when reset is deasserted, the ICH9 chip locks out the ability > for software to enable the watchdog. With the ichwd driver for BSD, this > condition is announced with a message like "Watchdog present, but > disabled in BIOS". (Well.. something close to that) "ICH WDT present but disabled in BIOS or hardware" I believe your issue is quite a different one, it is older and known and explicitly reported by the driver. In this case the watchdog does work and does seem to generate SMI. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 13:06: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 1A7F6106564A for ; Mon, 19 Jan 2009 13:06:42 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id AA5FC8FC08 for ; Mon, 19 Jan 2009 13:06:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9D24A1CC77; Mon, 19 Jan 2009 14:06:40 +0100 (CET) Date: Mon, 19 Jan 2009 14:06:40 +0100 From: Ed Schouten To: Garrett Cooper Message-ID: <20090119130640.GD1247@hoeg.nl> References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ioqcch2Htvy99P9q" Content-Disposition: inline In-Reply-To: <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Hackers , shilp.kamal@yahoo.com Subject: Re: panic: Going nowhere without my init! 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, 19 Jan 2009 13:06:42 -0000 --Ioqcch2Htvy99P9q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Garrett Cooper wrote: > I still don't understand why adding a [C, etc] `comment' would cause > these problems. I guess if you break getpid() to not return 1 in the case of init(8), it will just say "init: already running" and quit. This causes this panic to occur. --=20 Ed Schouten WWW: http://80386.nl/ --Ioqcch2Htvy99P9q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl0euAACgkQ52SDGA2eCwU0MACfVIaX7VeClBXv23ExuDZlzD9d D/oAni8g5IXAzx2ITFaJ3+yH83fGi9s9 =umLp -----END PGP SIGNATURE----- --Ioqcch2Htvy99P9q-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 13:45:25 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 A61751065676 for ; Mon, 19 Jan 2009 13:45:25 +0000 (UTC) (envelope-from iek@a-ka.net) Received: from mail-ew0-f33.google.com (mail-ew0-f33.google.com [209.85.219.33]) by mx1.freebsd.org (Postfix) with ESMTP id 4744F8FC1D for ; Mon, 19 Jan 2009 13:45:25 +0000 (UTC) (envelope-from iek@a-ka.net) Received: by ewy14 with SMTP id 14so351220ewy.19 for ; Mon, 19 Jan 2009 05:45:24 -0800 (PST) Received: by 10.210.92.8 with SMTP id p8mr209088ebb.55.1232371979171; Mon, 19 Jan 2009 05:32:59 -0800 (PST) Received: from admin.gulfstream.local (port-181-adslby-pool47.infonet.by [81.25.47.181]) by mx.google.com with ESMTPS id d25sm8732318nfh.36.2009.01.19.05.32.57 (version=SSLv3 cipher=OTHER); Mon, 19 Jan 2009 05:32:58 -0800 (PST) Date: Mon, 19 Jan 2009 15:32:55 +0200 From: igor krasnoselski X-Mailer: The Bat! (v3.99.24) Professional X-Priority: 3 (Normal) Message-ID: <651996463.20090119153255@a-ka.net> To: hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Jan 2009 13:56:17 +0000 Cc: Subject: Wi-Fi support - which iface works better? 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, 19 Jan 2009 13:45:26 -0000 Hi world, I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: ZyXEL G-302 EE D-link DWA-510 ASUS WL-138g V2 TRENDnet TEW-423PI P.S. Digging the "7.1 Hardware Notes" on the Web gave me no information about that cards. Please note me if they are supported at all. WBR, Igor Krasnoselski From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 18:00:21 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 3579E1065672 for ; Mon, 19 Jan 2009 18:00:21 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2B68FC13 for ; Mon, 19 Jan 2009 18:00:20 +0000 (UTC) (envelope-from wahjava@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so1982131tib.3 for ; Mon, 19 Jan 2009 10:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received :x-spam-checker-version:x-spam-level:x-spam-status:received:from:to :cc:subject:organization:references:x-face:x-uptime:x-url :x-openpgp-id:x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse :x-attribution:date:in-reply-to:message-id:user-agent:face :mime-version:content-type; bh=xd/f4dkEm1OJWhqL7lt56dQHuUVq0QQ4VbUx6kpMtjg=; b=cAw7h4vu++A3SMpSDXn8t8pOlHfo3lU+bEhZ8NlPzpNlc3bgqm1Xoa33HH/wRCIAmC XqdQrv7Z1V9W8d23HgdSIYu+oZAuya41FJ4ZkOGchk1oHgIWVKghsE2rPvTYDTXsmWAX 3zmt0SVK8h/QJ4DzHk2mVNJCk13sYz332Io4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:x-spam-checker-version:x-spam-level:x-spam-status:from:to:cc :subject:organization:references:x-face:x-uptime:x-url:x-openpgp-id :x-openpgp-fingerprint:x-os:x-mailer:x-mail-morse:x-attribution:date :in-reply-to:message-id:user-agent:face:mime-version:content-type; b=rRAt+1ekI4piFa70ATqznp2ZVyPI/E+cKiJfaKPIk7bCmo2j2eQBpyoaacHQceedgy 4IYAF0M5CkQAE4MPlrBVlnIuZTjftATs/XnOQvilb8v2CB3/qx+Az/Byn2O0BIJeCgkG inqc1PHe4BXN3fGD1/x2qzmk/yHBWMiEzo1Bg= Received: by 10.110.57.6 with SMTP id f6mr3528295tia.31.1232386184294; Mon, 19 Jan 2009 09:29:44 -0800 (PST) Received: from chateau.d.lf ([122.163.191.70]) by mx.google.com with ESMTPS id a4sm1632745tib.7.2009.01.19.09.29.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 19 Jan 2009 09:29:43 -0800 (PST) Sender: Ashish SHUKLA Received: by chateau.d.lf (Postfix, from userid 99) id 57731B6544; Mon, 19 Jan 2009 23:00:17 +0530 (IST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chateau.d.lf X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=ham version=3.2.5 Received: from chateau.d.lf (chateau.d.lf [IPv6:::1]) by chateau.d.lf (Postfix) with ESMTP id CD7AAB6518; Mon, 19 Jan 2009 23:00:13 +0530 (IST) From: wahjava.ml@gmail.com (Ashish SHUKLA) To: igor krasnoselski Organization: alt.religion.emacs References: <651996463.20090119153255@a-ka.net> X-Face: )vGQ9yK7Y$Flebu1C>(B\gYBm)[$zfKM+p&TT[[JWl6:]S>cc$%-z7-`46Zf0B*syL.C]oCq[upTG~zuS0.$"_%)|Q@$hA=9{3l{%u^h3jJ^Zl; t7 X-Uptime: 22:57:17 up 6:34, 1 user, load average: 0.37, 0.35, 0.33 X-URL: http://wahjava.wordpress.com/ X-OpenPGP-ID: 762E5E74 X-OpenPGP-Fingerprint: 1E00 4679 77E4 F8EE 2E4B 56F2 1F2F 8410 762E 5E74 X-OS: GNU/Linux on Linux 2.6.28-ARCH kernel on x86_64 architecture X-Mailer: Gnus v5.13 X-Mail-Morse: .-- .- .... .--- .- ...- .- .--.-. --. -- .- .. .-.. .-.-.- -.-. --- -- X-Attribution: =?utf-8?B?4KSG4KS24KWA4KS3?= Date: Mon, 19 Jan 2009 23:00:09 +0530 In-Reply-To: <651996463.20090119153255@a-ka.net> (igor krasnoselski's message of "Mon, 19 Jan 2009 15:32:55 +0200") Message-ID: <877i4rtd9a.fsf@chateau.d.lf> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJ1BMVEWpqal/f39tbW1jY2Md HR2goKCenp6UlJROTk7////9/f35+fnT09ORJdieAAACVklEQVQ4jXXUP2vbQBQA8AvUTkgz5OzY Z0iGWhpS6BSrkECn0mvx0MEJ6AjtYrfoBCVDlD8naJYmNlRfwZq8+mkKlIZaGpJSYmP7Q/XkJDrJ Td8i/H68u3vHPaPufwLdf32AMA4A6GcAgvAamY1pOJiDIFqicTwLswDhfr3uxfFtkAY/GFHPMwzD 8zpnACmIOnE6js7rQb+v4NJrG9od0C+QgpHMy5jBewV+UDSMWiw1Y4fWfyV7+NGFzDsYa3pth9LJ Q4XvXxFHcJRvHOmygn5NAEabnDcQQguarnfoiwSCJ99jmKKcphsZONmWsDK9Ro7cvZOCtQdg8nje egLhc2LNlkLmsezzTFUUy5w18ocox/f0LaLgJy0zO75zk+9pp85GAj36xjqhdI0y3tq2m4dqqcWX zQWBTz8L1irvolXV4J+3q7eCDgVnttjNq6X8H+9KOZsuNk1uCzx8pSp+E9HImfJOTLdcGqo+YKnG EIovizkEn48V7BO+ch2DXcD4ENSpWiU+q8hjjbgTBZCXnZtyj0Ws4Q1Q0B2WXFtYZo65Bbyeeldw RS6qFueM80LlLA29YlVwGRYvFD+kwI/0O+A2PlpOP9GwslUVciHuYGechuBTp922YiDZCrghTknm XSyOM+D3aoRZlo0Jb42zY7DN4p2x4AeZ+QAYutx1sHwTHzMT5cMNduQ9yW3GczN4KZ86kb0c9O8T yXDeFqpl2fryPEAYGXIlezAPXYh2NgVr/gvdoHIuDwuPwOhcWE8f8mmICq41eATkn8x0kuRTIKcB wE9+/QUtiiAnYcaN7wAAAABJRU5ErkJggg== MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Cc: hackers@FreeBSD.org Subject: Re: Wi-Fi support - which iface works better? 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, 19 Jan 2009 18:00:21 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable igor krasnoselski writes: > Hi world, > I'm up to build a little Wi-Fi network at my home. So I need to know, wha= t Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: > ZyXEL G-302 EE > D-link DWA-510 > ASUS WL-138g V2 > TRENDnet TEW-423PI > P.S. Digging the "7.1 Hardware Notes" on the Web gave me no > information about that cards. Please note me if they are supported at > all. It depends on the wifi chipset present in those NICs. I prefer Atheros, as it is well supported (at least in 8-CURRENT) and has complete FOSS drivers :). So I think you should find which NIC has which chipset. HTH =2D-=20 Ashish SHUKLA --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkl0uKUACgkQHy+EEHYuXnQuWwCeNDVXaJtO/v/hJxLcRU/w3bH5 jW8AoNslO9IxmRZVwaF1DOUY0QJpqkUi =ZgsL -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 18:08:25 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 98363106567D for ; Mon, 19 Jan 2009 18:08:25 +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 83A958FC2A for ; Mon, 19 Jan 2009 18:08:25 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (c-69-181-136-207.hsd1.ca.comcast.net [69.181.136.207]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n0JHnmG8050347; Mon, 19 Jan 2009 09:49:49 -0800 (PST) Message-ID: <4974BD3B.3020407@rawbw.com> Date: Mon, 19 Jan 2009 09:49:47 -0800 From: Yuri User-Agent: Thunderbird 2.0.0.19 (X11/20090110) MIME-Version: 1.0 To: igor krasnoselski References: <651996463.20090119153255@a-ka.net> In-Reply-To: <651996463.20090119153255@a-ka.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: Wi-Fi support - which iface works better? 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: Mon, 19 Jan 2009 18:08:26 -0000 igor krasnoselski wrote: > I'm up to build a little Wi-Fi network at my home. So I need to know, what Wi-Fi NIC is working better under FreeBSD 7.1, from the next little list: > ZyXEL G-302 EE > D-link DWA-510 > ASUS WL-138g V2 > TRENDnet TEW-423PI > P.S. Digging the "7.1 Hardware Notes" on the Web gave me no information about that cards. Please note me if they are supported at all. > > WBR, Igor Krasnoselski > This depends on the card chipset. It's sometimes hard to tell by the card model and I don't know which chipsets these cards have. I used two cards with chipsets: Atheros 5212 (ath) and Ralink Technology RT2561S (ral). Both of them don't work in a stable way under 71-PRERELEASE and in a very similar way. Connections get broken, link goes down sporadically. 'up scan' hangs, pings often don't go through after link is established, 'airdump' command stops working after a while on both of them. Based on these experiences i came to a conclusion that WiFi support isn't stable yet in FreeBSD. Yuri From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 19 23:13:56 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 9730E1065670 for ; Mon, 19 Jan 2009 23:13:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 558808FC16 for ; Mon, 19 Jan 2009 23:13:56 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4883A6D449; Mon, 19 Jan 2009 23:13:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 30B1B844B1; Tue, 20 Jan 2009 00:13:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ed Schouten References: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> <722201.19666.qm@web45408.mail.sp1.yahoo.com> <7d6fde3d0901180143g6345c128mcbdf72799472ed03@mail.gmail.com> <20090119130640.GD1247@hoeg.nl> Date: Tue, 20 Jan 2009 00:13:54 +0100 In-Reply-To: <20090119130640.GD1247@hoeg.nl> (Ed Schouten's message of "Mon, 19 Jan 2009 14:06:40 +0100") Message-ID: <86wscqanyl.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , shilp.kamal@yahoo.com, FreeBSD Hackers Subject: Re: panic: Going nowhere without my init! 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, 19 Jan 2009 23:13:57 -0000 Ed Schouten writes: > I guess if you break getpid() to not return 1 in the case of init(8), it > will just say "init: already running" and quit. This causes this panic > to occur. Who knows? We have no idea what the OP actually did, because he didn't bother to tell us. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 00:41: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 74146106566B; Tue, 20 Jan 2009 00:41:42 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green.homeunix.org [66.92.150.152]) by mx1.freebsd.org (Postfix) with ESMTP id 217968FC0A; Tue, 20 Jan 2009 00:41:41 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (obama@localhost [127.0.0.1]) by green.homeunix.org (8.14.3/8.14.1) with ESMTP id n0K0fcbi078603; Mon, 19 Jan 2009 19:41:38 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.14.3/8.14.1/Submit) id n0K0fZo2078598; Mon, 19 Jan 2009 19:41:35 -0500 (EST) (envelope-from green) Date: Mon, 19 Jan 2009 19:41:35 -0500 From: Brian Fundakowski Feldman To: Jason Evans Message-ID: <20090120004135.GB12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49710BD6.7040705@FreeBSD.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hackers@FreeBSD.org, Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 20 Jan 2009 00:41:42 -0000 On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: > Brian Fundakowski Feldman wrote: > > Could you, and anyone else who would care to, check this out? It's a > regression >> fix but it also makes the code a little bit clearer. Thanks! >> >> Index: lib/libc/stdlib/malloc.c > > Why does malloc need to change for this? Unless there's a really good > reason, I don't want the extra branches in the locking functions. Because malloc is the thing causing the regression. It is easy enough to optimize out the one extra fetch and branch in the single-threaded case if I can get some consensus that the fix to it is actually fine. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 01:00: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 6A5C5106564A for ; Tue, 20 Jan 2009 01:00:51 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from n57.bullet.mail.sp1.yahoo.com (n57.bullet.mail.sp1.yahoo.com [98.136.44.49]) by mx1.freebsd.org (Postfix) with SMTP id 47F3C8FC0C for ; Tue, 20 Jan 2009 01:00:51 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from [69.147.65.172] by n57.bullet.mail.sp1.yahoo.com with NNFMP; 20 Jan 2009 00:59:50 -0000 Received: from [69.147.84.102] by t14.bullet.mail.sp1.yahoo.com with NNFMP; 20 Jan 2009 00:59:50 -0000 Received: from [127.0.0.1] by omp206.mail.sp1.yahoo.com with NNFMP; 20 Jan 2009 00:59:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 695100.30850.bm@omp206.mail.sp1.yahoo.com Received: (qmail 95161 invoked by uid 60001); 20 Jan 2009 00:59:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=s8Xn3PyDp8OZE760uOH4MF9IBqy45OXs40dBwnPWc3XWcnOlUXh2yFhMK1Ly97/M7m6x6SQhzd4udJXEJVZxTR8g0vrMWdw266JEEavEvaY1Q/jBshBkDR1lvjad8jMbIupHTceQyZq2udkqXRM0VAmCieaio/x2T3HUxdIfaks=; X-YMail-OSG: 0PhBlaAVM1mqX.rSh.6evnEn0bRVJ3WD_hdkSkl1pWDLwVZtbV9yd6Ks5nMRveiX3xkVVLnTTeNcF6w7MRPlDPoy3zkCFI3F92MZViWhPMsPlkGEEWITlX3FAwMv4l7j9xR_5PJZntxFZs6d1wbaNW9T8nDQfQtIemsxfocDwKYoXdv4i9Vm_J4h4z4wciA03_ynbMYZjs8PCPwEqq4XeGzgsCMS Received: from [130.86.114.167] by web45402.mail.sp1.yahoo.com via HTTP; Mon, 19 Jan 2009 16:59:50 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Mon, 19 Jan 2009 16:59:50 -0800 (PST) From: Kamlesh Patel To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86wscqanyl.fsf@ds4.des.no> MIME-Version: 1.0 Message-ID: <560136.94786.qm@web45402.mail.sp1.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: panic: Going nowhere without my init! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shilp.kamal@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 01:00:51 -0000 Hi All, Sorry for late reply, i was out of work for a week. I made wrong comment in Getpid(): Getpid() { /* ...... /* ... */ .... */ return() } I removed it and now it is working fine. Thanks --- On Mon, 1/19/09, Dag-Erling Sm=F8rgrav wrote: From: Dag-Erling Sm=F8rgrav Subject: Re: panic: Going nowhere without my init! To: "Ed Schouten" Cc: "Garrett Cooper" , shilp.kamal@yahoo.com, "FreeBSD = Hackers" Date: Monday, January 19, 2009, 3:13 PM Ed Schouten writes: > I guess if you break getpid() to not return 1 in the case of init(8), it > will just say "init: already running" and quit. This causes this panic > to occur. Who knows? We have no idea what the OP actually did, because he didn't bother to tell us. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no _______________________________________________ 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" =0A=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 08:56:28 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 EFDDD1065701 for ; Tue, 20 Jan 2009 08:56:28 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id B1DEE8FC1B for ; Tue, 20 Jan 2009 08:56:28 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D992E6D449; Tue, 20 Jan 2009 08:56:27 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id BB99E844C4; Tue, 20 Jan 2009 09:56:27 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: shilp.kamal@yahoo.com References: <560136.94786.qm@web45402.mail.sp1.yahoo.com> Date: Tue, 20 Jan 2009 09:56:27 +0100 In-Reply-To: <560136.94786.qm@web45402.mail.sp1.yahoo.com> (Kamlesh Patel's message of "Mon, 19 Jan 2009 16:59:50 -0800 (PST)") Message-ID: <86k58qs6dg.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: panic: Going nowhere without my init! 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, 20 Jan 2009 08:56:29 -0000 Kamlesh Patel writes: > I made wrong comment in Getpid(): > > Getpid() { > > /* ...... > > /* ... */ > > .... */ > > return() > } That still doesn't tell us anything. To start with, there is no function named Getpid() anywhere in the tree. Secondly, the code you show us won't even compile (improperly nested comments), much less run. Thirdly, you haven't told us what you were trying to achieve with your modification, so we can't even help you get it right. Also, please don't top-post. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 10:43: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 685371065672 for ; Tue, 20 Jan 2009 10:43:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D7A6E8FC21 for ; Tue, 20 Jan 2009 10:43:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 10:43:23 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp045) with SMTP; 20 Jan 2009 11:43:23 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/BTVFSZv3B5RolQBgSEM0aL+4AZtssPsvOFcqFtO 3ybwq0bQYtLKdT Message-ID: <4975AACA.3050906@gmx.de> Date: Tue, 20 Jan 2009 11:43:22 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: FreeBSD Current References: <496D94FD.9030300@gmx.de> In-Reply-To: <496D94FD.9030300@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.44 Cc: uwe@grohnwaldt.eu, FreeBSD Hackers , miwi@freebsd.org Subject: Re: Question about panic in brelse() 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, 20 Jan 2009 10:43:27 -0000 Sadly I got no response about the panic problem so far. I investigated further and I came to the conclusion, that there are at least two problems/bugs in brelse(). Here are my findings. All lines refer to sys/kern/vfs_bio.c at r183754, which is the most recent version of this file. Below is the KASSERT(), which triggers in bundirty() (which is called by brelse()): KASSERT(bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE, ("bundirty: buffer %p still on queue %d", bp, bp->b_qindex)); So this assertion triggers, if neither B_REMFREE is set nor the buffer is in QUEUE_NONE. Now lets have a look at brelse() before the call to bundirty() happens. In line 1325 we find: if (bp->b_flags & B_REMFREE) bremfreel(bp); In bremfreel() B_REMFREE is cleared (line 684). So after this B_REMFREE is guaranteed to be clear and so the first part of the triggered KASSERT() will be false. Now for the second part, i.e. QUEUE_NONE: At line 1331 starts an if-cascade. No matter which case of this cascade is entered, b_qindex is set and it especially in no case it is set to QUEUE_NONE. so after this if-cascade it is guaranteed that b_qindex is *not* QUEUE_NONE. So when we arrive at line 1373ff at the problematic call to bundirty(), which contains the KASSERT(), it is guaranteed that neither B_REMFREE is set nor the buffer is in QUEUE_NONE and therefore the KASSERT() will be triggered. So we have a serious problem here: When the call is done, it *will* fail. This is one part of the problem. I have no solution, I don't know what would be correct here. Further, I looked at r93707 when this call to bundirty() was added. The situation was basically the same back then, i.e. the buffer could not be in QUEUE_NONE (the check for B_REMFREE did not exist back then, so the KASSERT() was more strict). So this change seems to wrong all along or at least dubious. The commit log of r93707 on the other hand claims that it solved a serious problem. If this was tested back then, it must have been done without INVARIANTS. It seems to be, that it was a hot fix - mind the MFC time of 1 day. Now for the second problem. As stated in the original mail, there is a buffer for which a write attempt failed: > b_iocmd = BIO_WRITE > b_ioflags = BIO_ERROR > b_error = EIO > b_flags = B_NOCACHE Because the error ist "just" an EIO, the buffer is re-dirtied and BIO_ERROR is cleared (line 1144ff). So writing the buffer should be tried again. But later in line 1342ff it is determined that the buffer contains junk, because B_NOCACHE is set so B_INVAL is also set. This leads to entering the path in line 1373, which then triggers the KASSERT(). On the other hand, the buffer does not contain junk, because it should be retried to be written! It only should be not kept around after the write was successful (or is considered to be failed permamently). So I think testing B_NOCACHE here alone is to weak and the condition has to be modified. I propose this change: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); This only enters the path to invalidate the buffer in case of B_NOCACHE being set, if B_DELWRI is *not* set. Can somebody reconstruct my analysis and confirm/reject it? Does my proposed solution for the second problem look sensible? Are the two problems related, i.e. can the first problem only occur because the second problem exists? What about the change in r93707 in general? Is it wrong? Does my proposal remove the cause for the change done in r93707 or are there other circumstances by which the situation can be triggered? Hopefully somebody can shed some more light on this. Christoph From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 11:54: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 7043E1065670 for ; Tue, 20 Jan 2009 11:54:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B5D298FC17 for ; Tue, 20 Jan 2009 11:54:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 20 Jan 2009 11:54:14 -0000 Received: from p54A3DE90.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.144] by mail.gmx.net (mp044) with SMTP; 20 Jan 2009 12:54:14 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+utelR/Y6ujdgyu/bVfT2n6VYnVrr0K6MTdwFu20 0qyFq5MfdjBtUp Message-ID: <4975BB65.2020502@gmx.de> Date: Tue, 20 Jan 2009 12:54:13 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: FreeBSD Current References: <496D94FD.9030300@gmx.de> <4975AACA.3050906@gmx.de> In-Reply-To: <4975AACA.3050906@gmx.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: uwe@grohnwaldt.eu, FreeBSD Hackers , miwi@freebsd.org Subject: Re: Question about panic in brelse() 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, 20 Jan 2009 11:54:16 -0000 Christoph Mallon schrieb: > @@ -1340,7 +1340,8 @@ > } > TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); > /* buffers with junk contents */ > - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || > + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || > + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) > (bp->b_ioflags & BIO_ERROR)) { > bp->b_flags |= B_INVAL; > bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); I just realised that somehow a || got lost. The diff should read: @@ -1340,7 +1340,8 @@ } TAILQ_INSERT_HEAD(&bufqueues[bp->b_qindex], bp, b_freelist); /* buffers with junk contents */ - } else if (bp->b_flags & (B_INVAL | B_NOCACHE | B_RELBUF) || + } else if (bp->b_flags & (B_INVAL | B_RELBUF) || + ((bp->b_flags & (B_NOCACHE | B_DELWRI)) == B_NOCACHE) || (bp->b_ioflags & BIO_ERROR)) { bp->b_flags |= B_INVAL; bp->b_xflags &= ~(BX_BKGRDWRITE | BX_ALTDATA); From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 08:21: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 5E5C4106567A for ; Tue, 20 Jan 2009 08:21:26 +0000 (UTC) (envelope-from creddym@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 33FEB8FC13 for ; Tue, 20 Jan 2009 08:21:26 +0000 (UTC) (envelope-from creddym@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3134972rvf.43 for ; Tue, 20 Jan 2009 00:21:25 -0800 (PST) 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=ixvxZhf4NiTBvM5ZZgQjj9UCJv7KID6fQoiJ+L67xT8=; b=XD4AAPvHlDN+dnXc53RlqmcMataCgQtqCjQC9155TjeEaJMrnlSwm5xGv1kJ7xVIfm Mgr+WSzH5dIQgp8GOQ5EkFZPZ4dcRig8+rTx3ZzjPtc040AbfatBEnvODACI8FwF4Cqy FG/Zrqz4UrlyAlC31yQJhi7cFmXLCu2YcJRuM= 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=ET2CpiBgWYfntnd68P1r8rq/NvSwrBdVdtfepO4AqpTFGZLuR0NRqHYcunsylRcLtO BrmuK98IrGHoGaDwixPE7f62vAfrXmyE+XvuK64hr1XjtnIfrfYaMO0S4cbUU8UBClpP 8KMVDIEh9DyMuucI865LpDQcHqtdDvk99FcmA= MIME-Version: 1.0 Received: by 10.141.99.2 with SMTP id b2mr2491817rvm.3.1232438081026; Mon, 19 Jan 2009 23:54:41 -0800 (PST) Date: Tue, 20 Jan 2009 13:24:41 +0530 Message-ID: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> From: chandra reddy To: freebsd-questions@freebsd.org X-Mailman-Approved-At: Tue, 20 Jan 2009 12:19:46 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input 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, 20 Jan 2009 08:21:26 -0000 Hi, I am getting the following error when i run tar on a directory. [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 tar: Cannot open directory config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/detection-time: No such file or directory tar: Cannot open directory config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/failure-action: No such file or directory [chandra@home]$ ldd tar tar: libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) chandra@home]$ uname -a FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I have debugged libc and found that system call "fstafs" is failing and returning -1. Can any one help me what is the real problem here and how to fix it? Thanks Chandra_ -- "debugging a buggy debugger with a cross buggy debugger leads to a buggy life " From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 08:58: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 4B91A10656C4; Tue, 20 Jan 2009 08:58:14 +0000 (UTC) (envelope-from creddym@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 0B34B8FC1F; Tue, 20 Jan 2009 08:58:13 +0000 (UTC) (envelope-from creddym@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so3146151rvf.43 for ; Tue, 20 Jan 2009 00:58:13 -0800 (PST) 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=w9Wc8at8eBtrdEJkoQ1Hoea8+WtIablZcXZ/Ws4p4A0=; b=P7WXFoaZu4+kW64G68682Xm+yj3GX0bKzbEKxH/RvJetqyjda2IMNJWpyJReHfLe/5 KhZH45j4DOcFtBdNECPbJAFWtv9n5cI+fMFPsyJgkTGojcO0mDt1x6MqDuLhbyjaTOdD oF2+w6VdmmD/E6I0p+UxVhQFrHJioAIsgmbPY= 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=E8pR3XnEPuKP72LRl9lPpk52A9ii/lPWY6/d76LjBIHbFZoPo7cFKCPxjD9hqqZg+F qJj80nuaYOGWz5yqXnvDZ9z1UlIuEvtGhT6aCwLwLJk2oxJ+U8UJ7EZp7jGD1OiUBTm6 DZ8j3jaMMNd6XnlyiXeA44hwarQ04SRdz4EP0= MIME-Version: 1.0 Received: by 10.141.210.2 with SMTP id m2mr2457693rvq.26.1232441893528; Tue, 20 Jan 2009 00:58:13 -0800 (PST) In-Reply-To: References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Date: Tue, 20 Jan 2009 14:28:13 +0530 Message-ID: <3f95d3db0901200058w281f9f06rb3c7b1d63b1d401d@mail.gmail.com> From: chandra reddy To: Doug Hardie X-Mailman-Approved-At: Tue, 20 Jan 2009 12:20:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input 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, 20 Jan 2009 08:58:15 -0000 Hi Doug, I have checked the files permission. It is fine. It passes on FreeBSD6 but fails on FreeBSD 7. It passes on a local file system but fails on NFS file system. Thanks -Chandra On Tue, Jan 20, 2009 at 2:02 PM, Doug Hardie wrote: > > On Jan 19, 2009, at 23:54, chandra reddy wrote: > > Hi, >> >> I am getting the following error when i run tar on a directory. >> >> [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 >> >> tar: Cannot open directory >> >> config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/detection-time: >> No such file or directory >> tar: Cannot open directory >> >> config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-liveness-detection/failure-action: >> No such file or directory >> [chandra@home]$ ldd tar >> tar: >> libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) >> chandra@home]$ uname -a >> FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> I have debugged libc and found that system call "fstafs" is failing and >> returning -1. >> >> Can any one help me what is the real problem here and how to fix it? >> > > Check and be sure that those directories have r and x for the user running > tar. It looks like a permission problem. > -- "debugging a buggy debugger with a cross buggy debugger leads to a buggy life " From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 13:17: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 A5EEA106566C; Tue, 20 Jan 2009 13:17:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 50EBE8FC12; Tue, 20 Jan 2009 13:17:39 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id n0KCn3Xx064959; Tue, 20 Jan 2009 04:49:03 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id n0KCn3sl064958; Tue, 20 Jan 2009 04:49:03 -0800 (PST) (envelope-from david) Date: Tue, 20 Jan 2009 04:49:03 -0800 From: David Wolfskill To: chandra reddy Message-ID: <20090120124903.GH17567@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , chandra reddy , freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dQAkT9kf8uI42z2+" Content-Disposition: inline In-Reply-To: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input 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, 20 Jan 2009 13:17:41 -0000 --dQAkT9kf8uI42z2+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 20, 2009 at 01:24:41PM +0530, chandra reddy wrote: > Hi, >=20 > I am getting the following error when i run tar on a directory. >=20 > [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 >=20 > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/bfd-l= iveness-detection/detection-time: > No such file or directory > tar: Cannot open directory > ... > FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > I have debugged libc and found that system call "fstafs" is failing and > returning -1. I believe you will find that the system call is "fstatfs". =20 > Can any one help me what is the real problem here and how to fix it? A subsequent message of your verified that the hierarchy being read was on an NFS-mounted file system. Perchance, was that NFS mount managwed by amd(8)? If so, while I do not have a "fix" for you, I am relieved to see someone else finally report these symptoms. Please see for an archived copy of my initial message in a thread reporting this. There is additional detail (including kernel trace information & how-to-repeat instructions) in subsequent messages in the thread. Also mentioned is a circumvention -- basically, crippling amd(8) so it no longer attempts to unmount() a file system. However, I was unable to re-create the symptoms at home -- only at work. A colleague at work was able to re-create the symptoms, and was intending to experiment a bit more, but he's been busy with other things recently. Please contact me (off-list, if you prefer), and we can discuss additional details. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --dQAkT9kf8uI42z2+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkl1yD4ACgkQmprOCmdXAD1UxgCghs3BhjNOLyskf9J9ZB75CZ8+ AAIAnjq/eBOITNAvB0X6e39ks7HWLTFz =JX2n -----END PGP SIGNATURE----- --dQAkT9kf8uI42z2+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 13:46:32 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 628A41065735 for ; Tue, 20 Jan 2009 13:46:32 +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 1F60A8FC1F for ; Tue, 20 Jan 2009 13:46:31 +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 1LPGw2-0008Ja-OX for freebsd-hackers@freebsd.org; Tue, 20 Jan 2009 15:46:30 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jan 2009 15:46:30 +0200 From: Danny Braniss Message-ID: Subject: ps acting weird? 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, 20 Jan 2009 13:46:33 -0000 I just stumbled on this, ps(1) gives different info if the user is root or a simple mortal: simple-mortal> ps p8130 PID TT STAT TIME COMMAND 8130 ?? Is 0:05.72 [java] root# ps p8130 PID TT STAT TIME COMMAND 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... was this always like this? btw, this is on 7.1-stable danny From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 15:49: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 9361D106567E for ; Tue, 20 Jan 2009 15:49:10 +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 700088FC2A for ; Tue, 20 Jan 2009 15:49:10 +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 0BB9246B03; Tue, 20 Jan 2009 10:49:10 -0500 (EST) Date: Tue, 20 Jan 2009 15:49:09 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: 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: ps acting weird? 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, 20 Jan 2009 15:49:11 -0000 On Tue, 20 Jan 2009, Danny Braniss wrote: > I just stumbled on this, ps(1) gives different info if the user is root or a > simple mortal: > > simple-mortal> ps p8130 > PID TT STAT TIME COMMAND > 8130 ?? Is 0:05.72 [java] > > root# ps p8130 > > PID TT STAT TIME COMMAND > 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... > > was this always like this? > btw, this is on 7.1-stable This happens when command lines are really long -- the kernel caches certain command line data when it's short (i.e., under a couple of hundred characters), but when it's long the only way to get it is to attach to the process's address space using debugging interfaces and read it from there. This requires ps(1) to have debugging rights for the target process, which will not always be true for simple mortal users, but will often be true for root. You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which will take effect when the command line is next changed (typically, when the program is run again, but there are some programs that update their command lines to show status information, in which case it will be when they next update). This shows up particularly for Java command lines, which are often long. I would be careful not to tune it up too high as it will use up kernel memory/address space, but setting it to, say, 4k or 8k on modern systems shouldn't really be a problem, especially since most commands don't have long command lines. The problem this limit addresses is what happens when maxproc processes all set maximally-sized command lines. I.e., if your maxproc is 6,000, then fully filling the command line cache gives you 1.5MB of command line in kernel address space and memory - a lot, but very little compared to making the limit 4000 bytes, in which case it's more around 24MB. Robert N M Watson Computer Laboratory University of Cambridge > > danny > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 16:23:52 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 D70F71065675 for ; Tue, 20 Jan 2009 16:23:52 +0000 (UTC) (envelope-from assaulter0x80@gmail.com) Received: from mail-bw0-f10.google.com (mail-bw0-f10.google.com [209.85.218.10]) by mx1.freebsd.org (Postfix) with ESMTP id 598B88FC13 for ; Tue, 20 Jan 2009 16:23:52 +0000 (UTC) (envelope-from assaulter0x80@gmail.com) Received: by bwz3 with SMTP id 3so501387bwz.19 for ; Tue, 20 Jan 2009 08:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=tHya/PlG1ecTZdUiTh1b9MKDhFZwAcAIsZP3Ggz89IU=; b=EqE4JWk0rxcN+2NE/gmPS0lef4PYkMaP2kz+gFU30bQY7f6Hd6FxJNyOBpwUNjvP66 VJccwkXzcyHJOKjhkMr8Gfk66VAe6NExG5njFznKSd/oiymcx7UUuiaSxuupRb2SCml2 yse45xcKMxZX4PisWsdNW831ewRNngO9oW7os= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=RCs880RykxgrvXZMytMScH2zZIgfVpAWDatSup5wDpklqaGEgo1SifPnGrj3pRVKma zHtt2LLzXw8z3UydE310jMs+YUJmLt9VhEZN2g/oDj7jz9P3oumVhmHYpHO17sh3gpmD S9vj83IgxeQfMKKpCH7aLiCgHg3XgFXiZrdlQ= Received: by 10.181.50.1 with SMTP id c1mr2543119bkk.3.1232468486603; Tue, 20 Jan 2009 08:21:26 -0800 (PST) Received: by 10.181.14.18 with HTTP; Tue, 20 Jan 2009 08:21:26 -0800 (PST) Message-ID: Date: Tue, 20 Jan 2009 17:21:26 +0100 From: "Jacky Oh" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: KLD: program.ko: depends of kernel - no avaiable 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, 20 Jan 2009 16:23:53 -0000 Hi, I'm writing a syscall module and he compiles well but at load time, kldload shows: KLD: program.ko: depends of kernel - no avaiable anyone know something about this? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 17:25: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 34ABB106564A for ; Tue, 20 Jan 2009 17:25:08 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by mx1.freebsd.org (Postfix) with ESMTP id BD9328FC14 for ; Tue, 20 Jan 2009 17:25:07 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy13 with SMTP id 13so1321051ewy.19 for ; Tue, 20 Jan 2009 09:25:06 -0800 (PST) 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=QgRAzm+ykE4FRzYZunWe+KXcT6mOEgTHeGSaozb14lQ=; b=wU5iM/pPw/EZklp8rGXTS0T9WSqhI+7AzniZ1zivj1KqxFPnV0UD5QKgxquB/qQV/2 eFoVlWit5eEM2JIByUzhJPCJiaMfnPV7UwX6wb6DoFvDe83Xc1mw/etoPegyawvLOE14 98p0EtYPLgKOghhXA+CowXZJCb6ELmdNGUqAQ= 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=PXX+kOgv019tcIei1tXKl65lccFVv8E8BkOgHlq6rXU1vfodjd/HnWMhmFS7bSftnq spnNIJLoYaWdtQNotKXeHpNVywmziFwTVshPc3cX9hdnkNnPbU/1t+kCh5rKHR8eLc0v zWUukjpiWZTq5u9UcIsmNRkWEfgLACCUePM7o= MIME-Version: 1.0 Received: by 10.210.10.1 with SMTP id 1mr918789ebj.85.1232472306117; Tue, 20 Jan 2009 09:25:06 -0800 (PST) In-Reply-To: References: Date: Tue, 20 Jan 2009 18:25:06 +0100 Message-ID: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> From: "Paul B. Mahol" To: Jacky Oh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: KLD: program.ko: depends of kernel - no avaiable 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, 20 Jan 2009 17:25:08 -0000 On 1/20/09, Jacky Oh wrote: > Hi, > > I'm writing a syscall module and he compiles well but at load time, kldload > shows: > > KLD: program.ko: depends of kernel - no avaiable program.ko expect kernel that is not currently running. This usually means that kernel which you are currently using and source from which you are building program.ko are not in sync. It is hard to guess because you did not give any useful information. And this is one really belongs to questions@ and not to hackers@ > anyone know something about this? > > Thanks! > _______________________________________________ > 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" > -- Paul From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 20:02: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 4D283106564A for ; Tue, 20 Jan 2009 20:02:40 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id F2BD98FC16 for ; Tue, 20 Jan 2009 20:02:39 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from DSPAM-Daemon (localhost [127.0.0.1]) by mx0.deglitch.com (Postfix) with SMTP id DEFA58FC4F for ; Tue, 20 Jan 2009 23:02:37 +0300 (MSK) Received: from orion.SpringDaemons.com (drsun1.dialup.corbina.ru [85.21.245.235]) by mx0.deglitch.com (Postfix) with ESMTPA id 6FA868FC27; Tue, 20 Jan 2009 23:02:35 +0300 (MSK) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 3D46F398F3; Tue, 20 Jan 2009 23:02:40 +0300 (MSK) Date: Tue, 20 Jan 2009 23:02:40 +0300 From: Stanislav Sedov To: "Paul B. Mahol" Message-Id: <20090120230240.c1047c0d.stas@FreeBSD.org> In-Reply-To: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> References: <3a142e750901200925g5c648c08t6d9364be9027407@mail.gmail.com> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jan 20 23:02:37 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 49762ddd967007949615204 Cc: freebsd-hackers@freebsd.org, Jacky Oh Subject: Re: KLD: program.ko: depends of kernel - no avaiable 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, 20 Jan 2009 20:02:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Jan 2009 18:25:06 +0100 "Paul B. Mahol" mentioned: > On 1/20/09, Jacky Oh wrote: > > Hi, > > > > I'm writing a syscall module and he compiles well but at load time, kldload > > shows: > > > > KLD: program.ko: depends of kernel - no avaiable > > program.ko expect kernel that is not currently running. > This usually means that kernel which you are currently using and > source from which you are building program.ko are not in sync. > It is hard to guess because you did not give any useful information. > And this is one really belongs to questions@ and not to hackers@ > The other possible reason that you used the symbol undefined in kernel (e.g. called unexistent function). - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAkl2LeAACgkQK/VZk+smlYFLwgCfVxU28ltWAe66XcxkSzXtR+wA 4SAAoIJmjx/aLIr4mI2k81bfl3gX++sf =Er2z -----END PGP SIGNATURE----- !DSPAM:49762ddd967007949615204! From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 20:18: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 54B481065696 for ; Tue, 20 Jan 2009 20:18:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id ED7E68FC4D for ; Tue, 20 Jan 2009 20:18:14 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0KKFp0u002864; Tue, 20 Jan 2009 13:15:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 13:16:27 -0700 (MST) Message-Id: <20090120.131627.-1717264382.imp@bsdimp.com> To: assaulter0x80@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: KLD: program.ko: depends of kernel - no avaiable 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, 20 Jan 2009 20:18:16 -0000 In message: "Jacky Oh" writes: : Hi, : : I'm writing a syscall module and he compiles well but at load time, kldload : shows: : : KLD: program.ko: depends of kernel - no avaiable : : anyone know something about this? Yes. rebuild the kernel and modules to have the same __FreeBSD_version warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 20: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 EECA0106566C for ; Tue, 20 Jan 2009 20:22:11 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from core.tav.kiev.ua (tavex.colocall.com [62.149.10.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8AEE58FC12 for ; Tue, 20 Jan 2009 20:22:11 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [209.52.235.211] (helo=[10.80.5.136]) by core.tav.kiev.ua with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.52 (FreeBSD)) id 1LPMXY-000A3d-VZ for freebsd-hackers@freebsd.org; Tue, 20 Jan 2009 21:45:38 +0200 Message-ID: <4976297C.7020405@bluezbox.com> Date: Tue, 20 Jan 2009 11:43:56 -0800 From: Oleksandr Tymoshenko User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Core-Spam-Level: ---- X-Core-Spam-Report: Spam detection software, running on the system "core.tav.kiev.ua", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Yesterday I ran into a "problem" with uart(4) on big-endian MIPS board. uart code treats registers as bytes and reads/writes them using bus_space_read_1/bus_space_write_1. To handle word-aligned registers we have regshft in uart_bas structure. It works for little-endian flags where lowest byte resides at uart_base + (regnum << regshft) address but for big endian targets actual data resides at uart_base + ((regnum + 1) << regshft) - 1. [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Subject: uart and big-endian targets 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, 20 Jan 2009 20:22:12 -0000 Yesterday I ran into a "problem" with uart(4) on big-endian MIPS board. uart code treats registers as bytes and reads/writes them using bus_space_read_1/bus_space_write_1. To handle word-aligned registers we have regshft in uart_bas structure. It works for little-endian flags where lowest byte resides at uart_base + (regnum << regshft) address but for big endian targets actual data resides at uart_base + ((regnum + 1) << regshft) - 1. One way to solve it is to increase uart_base when setting uart_bas, but it's not obvious and requires knowledge of uart(4) internals. I think better solution would be to take into account endianess when defining uart_regofs. Or if other BE devices have data in highest byte new field should be added to uart_bas (defaulted to 0) Any thoughts? -- gonzo From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 20:33: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 C35651065930 for ; Tue, 20 Jan 2009 20:33:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6503C8FC08 for ; Tue, 20 Jan 2009 20:33:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0KKUbrG003196; Tue, 20 Jan 2009 13:30:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 13:31:13 -0700 (MST) Message-Id: <20090120.133113.-1630673491.imp@bsdimp.com> To: gonzo@bluezbox.com From: "M. Warner Losh" In-Reply-To: <4976297C.7020405@bluezbox.com> References: <4976297C.7020405@bluezbox.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: uart and big-endian targets 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, 20 Jan 2009 20:33:49 -0000 In message: <4976297C.7020405@bluezbox.com> Oleksandr Tymoshenko writes: : Yesterday I ran into a "problem" with uart(4) on big-endian MIPS : board. uart code treats registers as bytes and reads/writes them using : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : have regshft in uart_bas structure. It works for little-endian flags : where lowest byte resides at uart_base + (regnum << regshft) address : but for big endian targets actual data resides at : uart_base + ((regnum + 1) << regshft) - 1. That's not the problem. The problem is that we're trying to do byte accesses to word registers. That's why we see a disconnect between the addresses since we're reading the wrong byte. also, we may be getting lucky with this access, but many chips have issues when you access word registers as bytes. : One way to solve it is to increase uart_base when setting uart_bas, : but it's not obvious and requires knowledge of uart(4) internals. : I think better solution would be to take into account endianess : when defining uart_regofs. Or if other BE devices have data in : highest byte new field should be added to uart_bas (defaulted to 0) : : Any thoughts? The base problem here is: uart.h: #define uart_getreg(bas, reg) \ bus_space_read_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value) \ bus_space_write_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) These should be, for the platform you are using: #define uart_getreg(bas, reg) \ bus_space_read_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) #define uart_setreg(bas, reg, value) \ bus_space_write_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) There's no easy way to swap these out, nor is there a way to have variants for different kinds of hardware attached to the same machine (the UART on the SoC will have different access patterns than the UART on the modem on the PC Card that's plugged in, for example). This is a short-coming in the design of UART. One that's relatively easy to fix, mind you, and one that could easily be fixed. There's so many twists like this that it can be hard to anticipate them all. The Octeon port basically copies uart_dev_ns8250.c and provides its own set of accessors. This is right from a accessing the hardware correctly point of view, but a pita from a code reuse point of view. Were it not for the other quirks in Cavium's serial ports, there'd be little reason to go this route... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 20:49: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 0D6D1106571A for ; Tue, 20 Jan 2009 20:49:21 +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 DAF4F8FC1E for ; Tue, 20 Jan 2009 20:49:20 +0000 (UTC) (envelope-from chris@young-alumni.com) Received: by mail.oldschoolpunx.net (Postfix, from userid 58) id 745227D27B; Tue, 20 Jan 2009 14:32:53 -0600 (CST) Received: from [192.168.8.200] (unknown [192.168.8.200]) by mail.oldschoolpunx.net (Postfix) with ESMTPSA id E49E67D223 for ; Tue, 20 Jan 2009 14:29:04 -0600 (CST) Message-Id: From: Chris Ruiz To: freebsd-hackers@freebsd.org In-Reply-To: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@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: Tue, 20 Jan 2009 14:29:04 -0600 References: <3f95d3db0901192354s502644cdh3ecf44a4ecf3fe6f@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: tar fails on FreeBSD 7 and passes on FreeBSD 6 for the same input 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, 20 Jan 2009 20:49:21 -0000 On Jan 20, 2009, at 1:54 AM, chandra reddy wrote: > Hi, > > I am getting the following error when i run tar on a directory. > > [chandra@home]$ tar zcf config-xsl.tar config-xsl/9.6 > > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/ > bfd-liveness-detection/detection-time: > No such file or directory > tar: Cannot open directory > config-xsl/9.6/configuration/protocols/mpls/label-switched-path/oam/ > bfd-liveness-detection/failure-action: > No such file or directory > [chandra@home]$ ldd tar > tar: > libc.so.6 => /usr/local/lib/compat/libc.so.6 (0x28097000) I am a little confused by the above. It shows your tar binary being linked to a library from freebsd 6 NOT 7. Did you update your "world" when you updated your kernel to 7? This is the appropriate output on a recent CURRENT: # ldd /usr/bin/tar /usr/bin/tar: libarchive.so.4 => /usr/lib/libarchive.so.4 (0x800649000) libbz2.so.3 => /usr/lib/libbz2.so.3 (0x800774000) libz.so.4 => /lib/libz.so.4 (0x800884000) libc.so.7 => /lib/libc.so.7 (0x800998000) IIRC, 7 should have very similar output and should be linked to libc.so.7. > chandra@home]$ uname -a > FreeBSD chandra 7.1-RC1 FreeBSD 7.1-RC1 #0: Sun Dec 7 05:57:33 UTC > 2008 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > I have debugged libc and found that system call "fstafs" is failing > and > returning -1. > > Can any one help me what is the real problem here and how to fix it? > > > > Thanks > Chandra_ My best guess is that you have an incompletely upgraded system. Chris Ruiz From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 21:18:28 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 665641065672 for ; Tue, 20 Jan 2009 21:18:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F3C238FC1A for ; Tue, 20 Jan 2009 21:18:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0KLFtVf003796; Tue, 20 Jan 2009 14:15:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 14:16:31 -0700 (MST) Message-Id: <20090120.141631.-1146313365.imp@bsdimp.com> To: gonzo@bluezbox.com From: "M. Warner Losh" In-Reply-To: <20090120.133113.-1630673491.imp@bsdimp.com> References: <4976297C.7020405@bluezbox.com> <20090120.133113.-1630673491.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: uart and big-endian targets 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, 20 Jan 2009 21:18:30 -0000 In message: <20090120.133113.-1630673491.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <4976297C.7020405@bluezbox.com> : Oleksandr Tymoshenko writes: : : Yesterday I ran into a "problem" with uart(4) on big-endian MIPS : : board. uart code treats registers as bytes and reads/writes them using : : bus_space_read_1/bus_space_write_1. To handle word-aligned registers we : : have regshft in uart_bas structure. It works for little-endian flags : : where lowest byte resides at uart_base + (regnum << regshft) address : : but for big endian targets actual data resides at : : uart_base + ((regnum + 1) << regshft) - 1. : : That's not the problem. The problem is that we're trying to do byte : accesses to word registers. That's why we see a disconnect between : the addresses since we're reading the wrong byte. also, we may be : getting lucky with this access, but many chips have issues when you : access word registers as bytes. : : : One way to solve it is to increase uart_base when setting uart_bas, : : but it's not obvious and requires knowledge of uart(4) internals. : : I think better solution would be to take into account endianess : : when defining uart_regofs. Or if other BE devices have data in : : highest byte new field should be added to uart_bas (defaulted to 0) : : : : Any thoughts? : : The base problem here is: : : uart.h: : : #define uart_getreg(bas, reg) \ : bus_space_read_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value) \ : bus_space_write_1((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) : : These should be, for the platform you are using: : : #define uart_getreg(bas, reg) \ : bus_space_read_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg)) : #define uart_setreg(bas, reg, value) \ : bus_space_write_4((bas)->bst, (bas)->bsh, uart_regofs(bas, reg), value) : : There's no easy way to swap these out, nor is there a way to have : variants for different kinds of hardware attached to the same machine : (the UART on the SoC will have different access patterns than the UART : on the modem on the PC Card that's plugged in, for example). This is : a short-coming in the design of UART. One that's relatively easy to : fix, mind you, and one that could easily be fixed. There's so many : twists like this that it can be hard to anticipate them all. : : The Octeon port basically copies uart_dev_ns8250.c and provides its : own set of accessors. This is right from a accessing the hardware : correctly point of view, but a pita from a code reuse point of view. : Were it not for the other quirks in Cavium's serial ports, there'd be : little reason to go this route... actually, the more I've thought about this, and chatted with folks offline, I think the right way to fix this is in bus_space... Warner From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 20 21:51: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 58DAD10656E4 for ; Tue, 20 Jan 2009 21:51:17 +0000 (UTC) (envelope-from mcsiv@mcsiv.hu) Received: from viefep31-int.chello.at (viefep31-int.chello.at [62.179.121.49]) by mx1.freebsd.org (Postfix) with ESMTP id 935298FC13 for ; Tue, 20 Jan 2009 21:51:16 +0000 (UTC) (envelope-from mcsiv@mcsiv.hu) Received: from edge01.upc.biz ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090120213250.HJXJ9551.viefep18-int.chello.at@edge01.upc.biz> for ; Tue, 20 Jan 2009 22:32:50 +0100 Received: from [192.168.1.20] ([89.132.243.99]) by edge01.upc.biz with edge id 5xYo1b03G29PSXt01xYpqr; Tue, 20 Jan 2009 22:32:50 +0100 X-SourceIP: 89.132.243.99 Message-ID: <497642F6.7000405@mcsiv.hu> Date: Tue, 20 Jan 2009 22:32:38 +0100 From: =?ISO-8859-2?Q?Moln=E1r_Zolt=E1n?= User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Subject: hp dl-380 and freebsd 6.4,7.1 problem 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, 20 Jan 2009 21:51:18 -0000 Hi everybody! First of all, sorry for my bad english. I have two hp dl-380 server with 6.4 and 7.1 freebsd, but all of them have a poor performance. To illustrate the problem: Reference machine (AMD 2500 Athlon, pata disk, 6.4 bsd with generic kernel): # time tar xvzf php-5.1.4.tar.gz 0.980u 1.260s 0:14.48 15.4% 61+416k 210+20413io 4pf+0w HP DL-380 (3000 dual xeon, scsi disk, 6.4 bsd with generic kernel): # time tar xvzf php-5.1.4.tar.gz 0.668u 1.234s 1:58.47 1.5% 65+443k 0+19205io 0pf+0w The cream of the joke: (on HP) # time tar xvzf php-5.1.4.tar.gz -O > /dev/null 0.412u 0.096s 0:03.62 13.8% 60+357k 0+0io 0pf+0w Seems good, another probe: # time tar xvzf php-5.1.4.tar.gz -O > ./asdasd 0.494u 0.224s 0:06.21 11.4% 64+384k 0+324io 0pf+0w Hmmm, what the hell is that? Copying a big file (1Gb) from partition to another partition, its fast enough. Copying a big file from ftp seems ok, no performance problem. HP utility says everything ok with the server (memory, processors, disks and others) # diskinfo -t /dev/da0s1 Seek times: Full stroke: 250 iter in 1.135873 sec = 4.543 msec Half stroke: 250 iter in 1.090216 sec = 4.361 msec Quarter stroke: 500 iter in 2.994673 sec = 5.989 msec Short forward: 400 iter in 1.230212 sec = 3.076 msec Short backward: 400 iter in 1.592944 sec = 3.982 msec Seq outer: 2048 iter in 0.356638 sec = 0.174 msec Seq inner: 2048 iter in 0.354043 sec = 0.173 msec Transfer rates: outside: 102400 kbytes in 1.567910 sec = 65310 kbytes/sec middle: 102400 kbytes in 1.831442 sec = 55912 kbytes/sec inside: 102400 kbytes in 3.978799 sec = 25736 kbytes/sec It`s seems ok. The performance problem is come forward again while executiing a php script, its 10x slower then running same script on the reference machine. No errors in dmesg, no errors in log, SMP seems working normal, systat says balanced usage on each processor while a task running. vmstat doesnt appear abnormal working. Where can i find the problem? Thanks for any suggestion. Zoltán Molnár // From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 09:38:33 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 5AD4E1065677 for ; Wed, 21 Jan 2009 09:38:33 +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 122FD8FC1A for ; Wed, 21 Jan 2009 09:38:32 +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 1LPZXb-000N4U-V6; Wed, 21 Jan 2009 11:38:31 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: Comments: In-reply-to Robert Watson message dated "Tue, 20 Jan 2009 15:49:09 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 2009 11:38:31 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: ps acting weird? 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, 21 Jan 2009 09:38:33 -0000 > > On Tue, 20 Jan 2009, Danny Braniss wrote: > > > I just stumbled on this, ps(1) gives different info if the user is root or a > > simple mortal: > > > > simple-mortal> ps p8130 > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.72 [java] > > > > root# ps p8130 > > > > PID TT STAT TIME COMMAND > > 8130 ?? Is 0:05.73 /usr/local/diablo-jdk1.6.0/bin/java ... > > > > was this always like this? > > btw, this is on 7.1-stable > > This happens when command lines are really long -- the kernel caches certain > command line data when it's short (i.e., under a couple of hundred > characters), but when it's long the only way to get it is to attach to the > process's address space using debugging interfaces and read it from there. > This requires ps(1) to have debugging rights for the target process, which > will not always be true for simple mortal users, but will often be true for > root. > > You can set the kern.ps_arg_cache_limit sysctl to increase the limit, which > will take effect when the command line is next changed (typically, when the > program is run again, but there are some programs that update their command > lines to show status information, in which case it will be when they next > update). This shows up particularly for Java command lines, which are often > long. > > I would be careful not to tune it up too high as it will use up kernel > memory/address space, but setting it to, say, 4k or 8k on modern systems > shouldn't really be a problem, especially since most commands don't have long > command lines. The problem this limit addresses is what happens when maxproc > processes all set maximally-sized command lines. I.e., if your maxproc is > 6,000, then fully filling the command line cache gives you 1.5MB of command > line in kernel address space and memory - a lot, but very little compared to > making the limit 4000 bytes, in which case it's more around 24MB. > > Robert N M Watson > Computer Laboratory > University of Cambridge > thanks Robert, it is always educational to read your answers! i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 would have been enough (excluding those pathological cases of 'command *') btw, this tomcat/java command line was 312 (why not use a config file!). which brings on another issue: ps -o command= -p 777 /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] while ps -o comm= -p 777 java thanks, danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 11:06: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 7EEA31065784 for ; Wed, 21 Jan 2009 11:06:44 +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 5A5A28FC13 for ; Wed, 21 Jan 2009 11:06:44 +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 D8C1846B09; Wed, 21 Jan 2009 06:06:43 -0500 (EST) Date: Wed, 21 Jan 2009 11:06:43 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Braniss In-Reply-To: Message-ID: References: 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: ps acting weird? 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, 21 Jan 2009 11:06:45 -0000 On Wed, 21 Jan 2009, Danny Braniss wrote: > thanks Robert, it is always educational to read your answers! > > i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 > would have been enough (excluding those pathological cases of 'command *') > btw, this tomcat/java command line was 312 (why not use a config file!). > > which brings on another issue: > > ps -o command= -p 777 > /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] > while > ps -o comm= -p 777 > java ps distinguishes "comm", which is the binary name as stored in the process structure's p_comm field, and the command line, which is p_args. From the ps(1) man page: KEYWORDS The following is a complete list of the available keywords and their meanings. Several of them have aliases (keywords which are synonyms). ... comm command command command and arguments Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 11:20:56 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 95233106566B for ; Wed, 21 Jan 2009 11:20:56 +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 B667B8FC1E for ; Wed, 21 Jan 2009 11:20:55 +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 NAA00580; Wed, 21 Jan 2009 13:20:52 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49770513.8090203@icyb.net.ua> Date: Wed, 21 Jan 2009 13:20:51 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov Subject: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 11:20:56 -0000 Question 1: I am writing a driver that would use per-open private data (among other features). Do I have to use D_TRACKCLOSE flag in this case? In general I am a little bit confused about when d_close is invoked. Supposing D_TRACKCLOSE is not set and multiple programs concurrently open, use and close a device - when d_close is called - when one program closes its last descriptor tied to the device or when the system-wide last such descriptor is closed? Question 2: I also would like the driver to provide a select capability quite similar to that of network (e.g. TCP) sockets using d_poll. I.e. a userland program should be able to query when it can write data to the device without blocking and when it can read data without blocking, plus when an error occurred in the device/driver, so there is no point in further waiting. At this moment I am thoroughly confused by meaning of various event masks described in poll(2). E.g. what is normal priority, non-zero priority and high priority. Which flags should I care about if all data is the same priority for me? Which flag(s) should I set when I'd like to communicate an error condition (e.g. similar to TCP connection reset)? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 11:21: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 47831106566B; Wed, 21 Jan 2009 11:21:17 +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 F101B8FC1D; Wed, 21 Jan 2009 11:21:16 +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 1LPb91-000OC2-Qt; Wed, 21 Jan 2009 13:21:15 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Robert Watson In-reply-to: References: Comments: In-reply-to Robert Watson message dated "Wed, 21 Jan 2009 11:06:43 +0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 2009 13:21:15 +0200 From: Danny Braniss Message-ID: Cc: freebsd-hackers@freebsd.org Subject: Re: ps acting weird? 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, 21 Jan 2009 11:21:18 -0000 > On Wed, 21 Jan 2009, Danny Braniss wrote: > > > thanks Robert, it is always educational to read your answers! > > > > i have set kern.ps_arg_cache_limit, as you suggested to 4k, but i think 512 > > would have been enough (excluding those pathological cases of 'command *') > > btw, this tomcat/java command line was 312 (why not use a config file!). > > > > which brings on another issue: > > > > ps -o command= -p 777 > > /usr/local/diablo-jdk1.6.0/bin/java -Djava.endorsed.dirs= -classpath [...] > > while > > ps -o comm= -p 777 > > java > > ps distinguishes "comm", which is the binary name as stored in the process > structure's p_comm field, and the command line, which is p_args. From the > ps(1) man page: > > KEYWORDS > The following is a complete list of the available keywords and their > meanings. Several of them have aliases (keywords which are synonyms). > ... > comm command > command command and arguments hehe, i read the manual :-), hence my question, the only difference, from the manual, is that command is comm and arguments, which now you explained that it's not so. danny From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 11:30:43 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 17623106564A for ; Wed, 21 Jan 2009 11:30:43 +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 2203E8FC0A for ; Wed, 21 Jan 2009 11:30:41 +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 NAA00768 for ; Wed, 21 Jan 2009 13:30:40 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4977075F.2010003@icyb.net.ua> Date: Wed, 21 Jan 2009 13:30:39 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <49770513.8090203@icyb.net.ua> In-Reply-To: <49770513.8090203@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 11:30:43 -0000 Question 3: is it ok to use M_WAITOK in pci attach routine? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 12:28: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 15A0D106566C for ; Wed, 21 Jan 2009 12:28:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id A3CFD8FC16 for ; Wed, 21 Jan 2009 12:28:10 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=jXPpYkP_560A:10 a=AhisAw-siT9GQ4rWsuIA:9 a=-0y9--pqKVyeKhapeerevIbaxlEA:4 a=LY0hPdMaydYA:10 Received: from [85.19.218.115] (account mc467741@c2i.net HELO [10.37.1.92]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 793827449; Wed, 21 Jan 2009 13:28:08 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Wed, 21 Jan 2009 13:30:31 +0100 User-Agent: KMail/1.9.7 References: <49770513.8090203@icyb.net.ua> <4977075F.2010003@icyb.net.ua> In-Reply-To: <4977075F.2010003@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211330.32679.hselasky@c2i.net> Cc: Andriy Gapon Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 12:28:11 -0000 On Wednesday 21 January 2009, Andriy Gapon wrote: > Question 3: > is it ok to use M_WAITOK in pci attach routine? Yes. --HPS From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 12:37:33 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 DEE3D106566C for ; Wed, 21 Jan 2009 12:37:33 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f20.google.com (mail-ew0-f20.google.com [209.85.219.20]) by mx1.freebsd.org (Postfix) with ESMTP id 484DC8FC13 for ; Wed, 21 Jan 2009 12:37:32 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy13 with SMTP id 13so1831437ewy.19 for ; Wed, 21 Jan 2009 04:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=fHTCKr04V99PP4yp9X2jdgnoJCjViCRGyhnl1FDnlH0=; b=Cx/DAbbgDUAct/nPoUp05T0iF4NY92lPjOlFLFdb87vQ5MixGMnOcd8w2IcFGC8/0m czT1K9a//Dxua3zNi3Pmlj0sM/OJqgKOKAXZqFhHy5E53PqJClPOUF48DRQ9R73z4+Zd 86K1vYrNClVUClXhbL8RxLjEC2j7/TTHlRR3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=sg+6DlhxspfwOCHsciGVyTRPDZ8o0+isTDdGQYvjzBJ93/5zWzrb7idljFmqkhP+hR u8XJ7XzrIHgNfhfQA34F2Riz7SYYl5X4XeV5LusSwbtI9m1MogSgNMoy1PlIv8RN2Gf4 6/KNLCDJyAARgatGJ3HrZISfJzjhER3UbTJB4= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.210.90.20 with SMTP id n20mr6078374ebb.198.1232539948042; Wed, 21 Jan 2009 04:12:28 -0800 (PST) Date: Wed, 21 Jan 2009 12:12:28 +0000 X-Google-Sender-Auth: 6702fde5684bcbba Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Kernel Module - GCC Requires memmove 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, 21 Jan 2009 12:37:34 -0000 Hi, I'm doing the unusual task of converting some c++ code into a FreeBSD kernel module. Now all has been going great, and thus far I've been able to debug quite a bit of it using printfs. However, I decided to start using a kernel debugger, and to make this easier I passed g++ the =E2=80=93O0 flag, to make it compile without optimisations. Bang, I hit a problem. All of a sudden when using the =E2=80=93O0 my module wouldn't load because it was missing an undefined reference to memmove. I found the specific object file which was using memmove. I did that by doing objdump =E2=80=93t *.o and finding which file had an undefined symbol memmove. Once I found the object file I grepped the associated source and I was sure I was not using memmove. I then got gcc to output both the post-processed source, as well as the asm. The .ii file (post-processed source) did NOT mention memmove at all. So I found it very odd that an undefined symbol existed in the object file. So then I looked in the .s file (asm), and it was clearing making a single call to memmove. So after a few hours of pulling my hair out I found this in the gcc manual: "-nostdlib .... The compiler may generate calls to memcmp, memset, memcpy and memmove. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified." So it appears that gcc may add calls to those four functions even if you don't use them yourself? I assume this has not been a problem for anyone yet due to only crazy people trying to use c++ in the kernel, and the specific set of gcc options I'm using. For the moment I have fixed this problem now by defining my own memmove lik= e so: extern "C" void * memmove(void * dst, const void * src, size_t len) { bcopy(src, dst, len); return dst; } But I was wondering if those four functions should be defined in the kernel? I notice that memcpy and memset are already defined by the kernel somewhere, so perhaps memmove and memcmp should join them? Oh I should mention this was happening with the default gcc under FreeBSD 7= .1. Thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 13:35:25 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 CA72A1065776 for ; Wed, 21 Jan 2009 13:35:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5F78FC1D for ; Wed, 21 Jan 2009 13:35:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPdEp-00068F-Rr; Wed, 21 Jan 2009 15:35:23 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LDZKIu007730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 15:35:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LDZKCS007065; Wed, 21 Jan 2009 15:35:20 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LDZKMn007063; Wed, 21 Jan 2009 15:35:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 15:35:20 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121133520.GK58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQ77YLfPrO/qF/pM" Content-Disposition: inline In-Reply-To: <49770513.8090203@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPdEp-00068F-Rr 269538c3b422f5b2f1b01adb631ffc32 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:35:27 -0000 --LQ77YLfPrO/qF/pM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >=20 > Question 1: > I am writing a driver that would use per-open private data (among other > features). > Do I have to use D_TRACKCLOSE flag in this case? No, the dtr registered with devfs_set_cdevpriv(), is called exactly once when the last close is performed, or the device is destroyed. > In general I am a little bit confused about when d_close is invoked. > Supposing D_TRACKCLOSE is not set and multiple programs concurrently > open, use and close a device - when d_close is called - when one program > closes its last descriptor tied to the device or when the system-wide > last such descriptor is closed? D_TRACKCLOSE (attempt to) tracks _file_ close, not filedescriptor close. This actually becomes quite messed up when revoke(2) or forced unmounts of the devfs mount points are mixed in. >=20 > Question 2: > I also would like the driver to provide a select capability quite > similar to that of network (e.g. TCP) sockets using d_poll. I.e. a > userland program should be able to query when it can write data to the > device without blocking and when it can read data without blocking, plus > when an error occurred in the device/driver, so there is no point in > further waiting. > At this moment I am thoroughly confused by meaning of various event > masks described in poll(2). E.g. what is normal priority, non-zero > priority and high priority. poll(2) comes from the Streams, where the messages in the queues do have priorities. See getmsgp(2) on Solaris for the start. Most likely, you do not need any priorities except POLLXXNORM, and FreeBSD uses POLLRDBAND for OOB TCP data only. > Which flags should I care about if all data is the same priority for me? > Which flag(s) should I set when I'd like to communicate an error > condition (e.g. similar to TCP connection reset)? I believe, it is a POLLHUP. See the sys_pipe.c, pipe_poll() for the rather clean example of the poll handler. --LQ77YLfPrO/qF/pM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3JJcACgkQC3+MBN1Mb4jJVQCg9hs1JBA2BC+uHzZV7S/Tmogk LgwAn1iiKYHgpPxJsiH7xmJd7vtVjXuu =wJyd -----END PGP SIGNATURE----- --LQ77YLfPrO/qF/pM-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 13:40: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 53DF11065B9A for ; Wed, 21 Jan 2009 13:40:31 +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 CF5128FC25 for ; Wed, 21 Jan 2009 13:40:28 +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 PAA06186; Wed, 21 Jan 2009 15:40:25 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <497725C8.4010101@icyb.net.ua> Date: Wed, 21 Jan 2009 15:40:24 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Kostik Belousov References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> In-Reply-To: <20090121133520.GK58517@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:40:34 -0000 on 21/01/2009 15:35 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >> Question 1: >> I am writing a driver that would use per-open private data (among other >> features). >> Do I have to use D_TRACKCLOSE flag in this case? > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > when the last close is performed, or the device is destroyed. Kostik, thanks a lot for the explanation! I am still a little bit confused about the term "last close" - what is it? I.e. I'd like to get an answer to the below question. >> In general I am a little bit confused about when d_close is invoked. >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently >> open, use and close a device - when d_close is called - when one program >> closes its last descriptor tied to the device or when the system-wide >> last such descriptor is closed? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 13: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 0ECCE10658EA for ; Wed, 21 Jan 2009 13: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 D97FC8FC12 for ; Wed, 21 Jan 2009 13: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 664AC46B03; Wed, 21 Jan 2009 08:52:54 -0500 (EST) Date: Wed, 21 Jan 2009 13:52:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "M. Warner Losh" In-Reply-To: <20090120.131627.-1717264382.imp@bsdimp.com> Message-ID: References: <20090120.131627.-1717264382.imp@bsdimp.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, assaulter0x80@gmail.com Subject: Re: KLD: program.ko: depends of kernel - no avaiable 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, 21 Jan 2009 13:52:57 -0000 On Tue, 20 Jan 2009, M. Warner Losh wrote: > In message: > "Jacky Oh" writes: > : Hi, > : > : I'm writing a syscall module and he compiles well but at load time, kldload > : shows: > : > : KLD: program.ko: depends of kernel - no avaiable > : > : anyone know something about this? > > Yes. rebuild the kernel and modules to have the same __FreeBSD_version It would be nice if the kernel linker included version numbers, both expected and found, in these messages. Unfortunately, this code is rather well-abstracted, and the specific version numbers are rather inaccessible at the point where the error message is printed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 13:55: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 D1111106568F for ; Wed, 21 Jan 2009 13:55:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 710278FC30 for ; Wed, 21 Jan 2009 13:55:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPdY1-00096l-Ma; Wed, 21 Jan 2009 15:55:13 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LDtAmw010184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 15:55:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LDtAOX012964; Wed, 21 Jan 2009 15:55:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LDtAGG012963; Wed, 21 Jan 2009 15:55:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 15:55:10 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121135510.GL58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XRwESHC7KXlqFpSs" Content-Disposition: inline In-Reply-To: <497725C8.4010101@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPdY1-00096l-Ma 7b2b9b149c763bf614376891bcc6db09 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 13:55:21 -0000 --XRwESHC7KXlqFpSs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:35 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > >> Question 1: > >> I am writing a driver that would use per-open private data (among other > >> features). > >> Do I have to use D_TRACKCLOSE flag in this case? > > No, the dtr registered with devfs_set_cdevpriv(), is called exactly once > > when the last close is performed, or the device is destroyed. >=20 > Kostik, >=20 > thanks a lot for the explanation! > I am still a little bit confused about the term "last close" - what is > it? I.e. I'd like to get an answer to the below question. >=20 > >> In general I am a little bit confused about when d_close is invoked. > >> Supposing D_TRACKCLOSE is not set and multiple programs concurrently > >> open, use and close a device - when d_close is called - when one progr= am > >> closes its last descriptor tied to the device or when the system-wide > >> last such descriptor is closed? The kernel data structures for the opened device are as follows: filedesc ---> struct file ---> vnode ---> cdev [cdevpriv] \ / =20 --------->----- Each -> arrow represents a "many to one" relation. There may be zero or one cdevpriv datum associated with struct file. cdev maintains the si_usecount, that is an accumulation of the vref counters for all devfs vnodes that are attached to the cdev. devfs_close() vop is called when the struct file is released. When D_TRACKCLOSE is specified, d_close driver method will be called unconditionally. When D_TRACKCLOSE is not specified, d_close is called when si_usecount is exactly 1, to become zero after the last close of the file that opened a vnode referencing cdev. Also, d_close() is called if the vnode is being reclaimed. Possible causes are revoke(2) call or forced devfs mp unmount. This interferes with close counting. cdevpriv dtr is called when either struct file is released, or device is destroyed by the destroy_dev(). --XRwESHC7KXlqFpSs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3KT0ACgkQC3+MBN1Mb4jR6QCeNk+fmzMnXWS1B7dOZdNqXWJ7 cZYAoN5qGFKNOtzlKiqA4S5AQJn2Bod8 =EUOr -----END PGP SIGNATURE----- --XRwESHC7KXlqFpSs-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:05: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 BF50410656E2 for ; Wed, 21 Jan 2009 14:05:27 +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 997608FC2D for ; Wed, 21 Jan 2009 14:05:27 +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 564C546B09; Wed, 21 Jan 2009 09:05:27 -0500 (EST) Date: Wed, 21 Jan 2009 14:05:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <49770513.8090203@icyb.net.ua> Message-ID: References: <49770513.8090203@icyb.net.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , freebsd-hackers@FreeBSD.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:05:30 -0000 On Wed, 21 Jan 2009, Andriy Gapon wrote: > Question 1: I am writing a driver that would use per-open private data > (among other features). Do I have to use D_TRACKCLOSE flag in this case? In > general I am a little bit confused about when d_close is invoked. Supposing > D_TRACKCLOSE is not set and multiple programs concurrently open, use and > close a device - when d_close is called - when one program closes its last > descriptor tied to the device or when the system-wide last such descriptor > is closed? Kostik has already pointed at the cdevpriv API, but just to reiterate his point: most people will find the semantics of D_TRACKCLOSE confusing and consider them incorrect, so I would advise against using them. > I also would like the driver to provide a select capability quite > similar to that of network (e.g. TCP) sockets using d_poll. I.e. a > userland program should be able to query when it can write data to the > device without blocking and when it can read data without blocking, plus > when an error occurred in the device/driver, so there is no point in > further waiting. > At this moment I am thoroughly confused by meaning of various event > masks described in poll(2). E.g. what is normal priority, non-zero > priority and high priority. > Which flags should I care about if all data is the same priority for me? > Which flag(s) should I set when I'd like to communicate an error > condition (e.g. similar to TCP connection reset)? I find that the description of the polling flags is at best confusing in both man pages and specifications. The best bet is to look at the existing TCP semantics, which are basically defined in sopoll_generic(): if (events & (POLLIN | POLLRDNORM)) if (soreadable(so)) revents |= events & (POLLIN | POLLRDNORM); if (events & POLLINIGNEOF) if (so->so_rcv.sb_cc >= so->so_rcv.sb_lowat || !TAILQ_EMPTY(&so->so_comp) || so->so_error) revents |= POLLINIGNEOF; if (events & (POLLOUT | POLLWRNORM)) if (sowriteable(so)) revents |= events & (POLLOUT | POLLWRNORM); if (events & (POLLPRI | POLLRDBAND)) if (so->so_oobmark || (so->so_rcv.sb_state & SBS_RCVATMARK)) revents |= events & (POLLPRI | POLLRDBAND); A few observations: - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all protocols use sopoll_generic in practice). This is surprising given the wording in the poll(2) man page. - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference between soreadable() and the test in POLLIGNEOF is that POLLIN also considers SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but POLLIGNEOF doesn't. I think Kostik's pointer to the pipe_poll() code is a good one, but if you're looking to emulate TCP semantics a bit more exactly, these differences should be taken into account. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:07: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 BE3621065831 for ; Wed, 21 Jan 2009 14:07:59 +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 E78968FC23 for ; Wed, 21 Jan 2009 14:07:58 +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 QAA07055; Wed, 21 Jan 2009 16:07:55 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49772C3A.10005@icyb.net.ua> Date: Wed, 21 Jan 2009 16:07:54 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Kostik Belousov References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> <20090121135510.GL58517@deviant.kiev.zoral.com.ua> In-Reply-To: <20090121135510.GL58517@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:08:01 -0000 on 21/01/2009 15:55 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: >> on 21/01/2009 15:35 Kostik Belousov said the following: >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >>>> Question 1: >>>> I am writing a driver that would use per-open private data (among other >>>> features). >>>> Do I have to use D_TRACKCLOSE flag in this case? >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly once >>> when the last close is performed, or the device is destroyed. >> Kostik, >> >> thanks a lot for the explanation! >> I am still a little bit confused about the term "last close" - what is >> it? I.e. I'd like to get an answer to the below question. >> >>>> In general I am a little bit confused about when d_close is invoked. >>>> Supposing D_TRACKCLOSE is not set and multiple programs concurrently >>>> open, use and close a device - when d_close is called - when one program >>>> closes its last descriptor tied to the device or when the system-wide >>>> last such descriptor is closed? > > The kernel data structures for the opened device are as follows: > > filedesc ---> struct file ---> vnode ---> cdev > [cdevpriv] \ / > --------->----- > > Each -> arrow represents a "many to one" relation. There may be zero > or one cdevpriv datum associated with struct file. > > cdev maintains the si_usecount, that is an accumulation of the vref > counters for all devfs vnodes that are attached to the cdev. > devfs_close() vop is called when the struct file is released. > When D_TRACKCLOSE is specified, d_close driver method will be > called unconditionally. > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > is exactly 1, to become zero after the last close of the file that > opened a vnode referencing cdev. > Also, d_close() is called if the vnode is being reclaimed. Possible > causes are revoke(2) call or forced devfs mp unmount. This interferes > with close counting. > > cdevpriv dtr is called when either struct file is released, or > device is destroyed by the destroy_dev(). Kostik, is the following true: if D_TRACKCLOSE is specified then a number of d_close() calls and a number of cdevpriv dtr calls are equal (provide each file gets cdevpriv data) ? If not, what is the case where one is called but not the other? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:12: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 D05021065760 for ; Wed, 21 Jan 2009 14:12:27 +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 B5E188FC37 for ; Wed, 21 Jan 2009 14:12:26 +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 QAA07212; Wed, 21 Jan 2009 16:12:25 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49772D47.2090602@icyb.net.ua> Date: Wed, 21 Jan 2009 16:12:23 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Robert Watson References: <49770513.8090203@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-hackers@FreeBSD.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:12:30 -0000 on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > >> Question 1: I am writing a driver that would use per-open private data >> (among other features). Do I have to use D_TRACKCLOSE flag in this >> case? In general I am a little bit confused about when d_close is >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs >> concurrently open, use and close a device - when d_close is called - >> when one program closes its last descriptor tied to the device or when >> the system-wide last such descriptor is closed? > > Kostik has already pointed at the cdevpriv API, but just to reiterate > his point: most people will find the semantics of D_TRACKCLOSE confusing > and consider them incorrect, so I would advise against using them. Robert, Kostik, in simplistic layman's terms I need the following - when a particular program "closes my cdev" (explicitly or via exit) I need to catch that and de-allocate certain resources. There can be multiple concurrent programs opening, using and closing my cdev. I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead I should perform the resource management in cdevpriv destructor. Am I guessing correctly this time? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:14: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 E402110657C3 for ; Wed, 21 Jan 2009 14:14:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 82C9D8FC26 for ; Wed, 21 Jan 2009 14:14:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPdqF-000BSZ-1S; Wed, 21 Jan 2009 16:14:03 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LEDuKb011883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 16:13:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LEDuMA023952; Wed, 21 Jan 2009 16:13:56 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LEDuXI023950; Wed, 21 Jan 2009 16:13:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 16:13:55 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121141355.GM58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <20090121133520.GK58517@deviant.kiev.zoral.com.ua> <497725C8.4010101@icyb.net.ua> <20090121135510.GL58517@deviant.kiev.zoral.com.ua> <49772C3A.10005@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m+utxuhC6KVTvgNz" Content-Disposition: inline In-Reply-To: <49772C3A.10005@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPdqF-000BSZ-1S f555fa7860a3dfe1788a8fb7382ee76b X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:14:08 -0000 --m+utxuhC6KVTvgNz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 04:07:54PM +0200, Andriy Gapon wrote: > on 21/01/2009 15:55 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: > >> on 21/01/2009 15:35 Kostik Belousov said the following: > >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: > >>>> Question 1: > >>>> I am writing a driver that would use per-open private data (among ot= her > >>>> features). > >>>> Do I have to use D_TRACKCLOSE flag in this case? > >>> No, the dtr registered with devfs_set_cdevpriv(), is called exactly o= nce > >>> when the last close is performed, or the device is destroyed. > >> Kostik, > >> > >> thanks a lot for the explanation! > >> I am still a little bit confused about the term "last close" - what is > >> it? I.e. I'd like to get an answer to the below question. > >> > >>>> In general I am a little bit confused about when d_close is invoked. > >>>> Supposing D_TRACKCLOSE is not set and multiple programs concurrently > >>>> open, use and close a device - when d_close is called - when one pro= gram > >>>> closes its last descriptor tied to the device or when the system-wide > >>>> last such descriptor is closed? > >=20 > > The kernel data structures for the opened device are as follows: > >=20 > > filedesc ---> struct file ---> vnode ---> cdev > > [cdevpriv] \ / =20 > > --------->----- > >=20 > > Each -> arrow represents a "many to one" relation. There may be zero > > or one cdevpriv datum associated with struct file. > >=20 > > cdev maintains the si_usecount, that is an accumulation of the vref > > counters for all devfs vnodes that are attached to the cdev. > > devfs_close() vop is called when the struct file is released. > > When D_TRACKCLOSE is specified, d_close driver method will be > > called unconditionally. > > When D_TRACKCLOSE is not specified, d_close is called when si_usecount > > is exactly 1, to become zero after the last close of the file that > > opened a vnode referencing cdev. > > Also, d_close() is called if the vnode is being reclaimed. Possible > > causes are revoke(2) call or forced devfs mp unmount. This interferes > > with close counting. > >=20 > > cdevpriv dtr is called when either struct file is released, or > > device is destroyed by the destroy_dev(). >=20 > Kostik, >=20 > is the following true: if D_TRACKCLOSE is specified then a number of > d_close() calls and a number of cdevpriv dtr calls are equal (provide > each file gets cdevpriv data) ? > If not, what is the case where one is called but not the other? No, I already described this. See the note about vnode reclamation. Also, d_close counter would have an interacation with destroy_dev(). To give you short summary, for D_TRACKCLOSE, d_close() may be called less times then dtr. --m+utxuhC6KVTvgNz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3LaMACgkQC3+MBN1Mb4gFGgCgoQSl8YQZJMQww5RIiam7k5aV MY8AniVnLokljoW1W0ksV8wxqC/n6iYT =T06g -----END PGP SIGNATURE----- --m+utxuhC6KVTvgNz-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:15: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 4FE3510657D2; Wed, 21 Jan 2009 14:15:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E60D78FC32; Wed, 21 Jan 2009 14:15:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPdrM-000Bf3-R1; Wed, 21 Jan 2009 16:15:12 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LEFAEw012017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 16:15:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LEFA4x024876; Wed, 21 Jan 2009 16:15:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LEF9MA024875; Wed, 21 Jan 2009 16:15:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 16:15:09 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121141509.GN58517@deviant.kiev.zoral.com.ua> References: <49770513.8090203@icyb.net.ua> <49772D47.2090602@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cfQkLQGU7KOA/8T" Content-Disposition: inline In-Reply-To: <49772D47.2090602@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPdrM-000Bf3-R1 27a6638792289c7e398fe02084c62e8e X-Terabit: YES Cc: freebsd-hackers@FreeBSD.org, Robert Watson Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:15:16 -0000 --+cfQkLQGU7KOA/8T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: > on 21/01/2009 16:05 Robert Watson said the following: > >=20 > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > >=20 > >> Question 1: I am writing a driver that would use per-open private data > >> (among other features). Do I have to use D_TRACKCLOSE flag in this > >> case? In general I am a little bit confused about when d_close is > >> invoked. Supposing D_TRACKCLOSE is not set and multiple programs > >> concurrently open, use and close a device - when d_close is called - > >> when one program closes its last descriptor tied to the device or when > >> the system-wide last such descriptor is closed? > >=20 > > Kostik has already pointed at the cdevpriv API, but just to reiterate > > his point: most people will find the semantics of D_TRACKCLOSE confusing > > and consider them incorrect, so I would advise against using them. >=20 > Robert, Kostik, >=20 > in simplistic layman's terms I need the following - when a particular > program "closes my cdev" (explicitly or via exit) I need to catch that > and de-allocate certain resources. There can be multiple concurrent > programs opening, using and closing my cdev. >=20 > I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead > I should perform the resource management in cdevpriv destructor. > Am I guessing correctly this time? Yes. This is the purpose of the cdevpriv KPI. --+cfQkLQGU7KOA/8T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3Le0ACgkQC3+MBN1Mb4gr1gCgwnF62FbmZOVjZ/zlQazR70FO WwcAoLzScUMCpgDy7/LQfJkDz9KI7txK =5R02 -----END PGP SIGNATURE----- --+cfQkLQGU7KOA/8T-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 14:16: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 9A2731065B18 for ; Wed, 21 Jan 2009 14:16:17 +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 8392B8FC18 for ; Wed, 21 Jan 2009 14:16:16 +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 QAA07340; Wed, 21 Jan 2009 16:16:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49772E2C.7050008@icyb.net.ua> Date: Wed, 21 Jan 2009 16:16:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Kostik Belousov References: <49770513.8090203@icyb.net.ua> <49772D47.2090602@icyb.net.ua> <20090121141509.GN58517@deviant.kiev.zoral.com.ua> In-Reply-To: <20090121141509.GN58517@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Robert Watson Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 14:16:18 -0000 on 21/01/2009 16:15 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: >> on 21/01/2009 16:05 Robert Watson said the following: >>> On Wed, 21 Jan 2009, Andriy Gapon wrote: >>> >>>> Question 1: I am writing a driver that would use per-open private data >>>> (among other features). Do I have to use D_TRACKCLOSE flag in this >>>> case? In general I am a little bit confused about when d_close is >>>> invoked. Supposing D_TRACKCLOSE is not set and multiple programs >>>> concurrently open, use and close a device - when d_close is called - >>>> when one program closes its last descriptor tied to the device or when >>>> the system-wide last such descriptor is closed? >>> Kostik has already pointed at the cdevpriv API, but just to reiterate >>> his point: most people will find the semantics of D_TRACKCLOSE confusing >>> and consider them incorrect, so I would advise against using them. >> Robert, Kostik, >> >> in simplistic layman's terms I need the following - when a particular >> program "closes my cdev" (explicitly or via exit) I need to catch that >> and de-allocate certain resources. There can be multiple concurrent >> programs opening, using and closing my cdev. >> >> I guess what you both say is that I shouldn't use D_TRACKCLOSE, instead >> I should perform the resource management in cdevpriv destructor. >> Am I guessing correctly this time? > > Yes. This is the purpose of the cdevpriv KPI. Thank you! Sorry for being so thick :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 15:03: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 1E0FC1065678 for ; Wed, 21 Jan 2009 15:03:24 +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 3154A8FC12 for ; Wed, 21 Jan 2009 15:03:22 +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 RAA09108 for ; Wed, 21 Jan 2009 17:03:21 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49773938.5010000@icyb.net.ua> Date: Wed, 21 Jan 2009 17:03:20 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: MOD_UNLOAD and driver with cdev 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, 21 Jan 2009 15:03:24 -0000 Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? I see in the current code that one strategy is to simply call destroy_dev(). I guess detach routines are called automatically and destroy_dev can be done there as well.. Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? How to check for that best? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 15:39: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 5325F106566C for ; Wed, 21 Jan 2009 15:39:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id EE4A68FC16 for ; Wed, 21 Jan 2009 15:39:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPfAd-000JRY-Om; Wed, 21 Jan 2009 17:39:11 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LFd9wx019250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 17:39:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LFd908043726; Wed, 21 Jan 2009 17:39:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LFd8hZ043725; Wed, 21 Jan 2009 17:39:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 17:39:08 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121153908.GO58517@deviant.kiev.zoral.com.ua> References: <49773938.5010000@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GPOl6LAGMgeiWDic" Content-Disposition: inline In-Reply-To: <49773938.5010000@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPfAd-000JRY-Om 71e14d707151996085c57c8656e2c194 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: MOD_UNLOAD and driver with cdev 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, 21 Jan 2009 15:39:13 -0000 --GPOl6LAGMgeiWDic Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: >=20 > Do I need to code for MOD_UNLOAD for driver module that also creates a cd= ev? > I see in the current code that one strategy is to simply call > destroy_dev(). I guess detach routines are called automatically and > destroy_dev can be done there as well.. What are the detach routines ? Do you mean newbus device detach ? Yes, the usual strategy is to call destroy_dev from unload handler. >=20 > Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > How to check for that best? This cannot be checked race-free. --GPOl6LAGMgeiWDic Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3QZwACgkQC3+MBN1Mb4il9QCcDgl+fvM6v2My/B5VVwzfduiR wGYAnjqq815Ce1WShNgU9gM3GzUEzUuw =Kw/R -----END PGP SIGNATURE----- --GPOl6LAGMgeiWDic-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 15:50: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 14AD0106566C for ; Wed, 21 Jan 2009 15:50:44 +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 430568FC17 for ; Wed, 21 Jan 2009 15:50:42 +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 RAA10940; Wed, 21 Jan 2009 17:50:39 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4977444E.8050306@icyb.net.ua> Date: Wed, 21 Jan 2009 17:50:38 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Kostik Belousov References: <49773938.5010000@icyb.net.ua> <20090121153908.GO58517@deviant.kiev.zoral.com.ua> In-Reply-To: <20090121153908.GO58517@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: MOD_UNLOAD and driver with cdev 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, 21 Jan 2009 15:50:45 -0000 on 21/01/2009 17:39 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: >> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? >> I see in the current code that one strategy is to simply call >> destroy_dev(). I guess detach routines are called automatically and >> destroy_dev can be done there as well.. > What are the detach routines ? Do you mean newbus device detach ? Yes, device_detach. This seems to work and make_device_driver.sh also suggests it this way. But I am not sure about possible races. > Yes, the usual strategy is to call destroy_dev from unload handler. > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? >> How to check for that best? > > This cannot be checked race-free. So no point in trying? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 15:57:18 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 5253D1065670 for ; Wed, 21 Jan 2009 15:57:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id EC0E58FC1D for ; Wed, 21 Jan 2009 15:57:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LPfS8-000L34-Lj; Wed, 21 Jan 2009 17:57:16 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0LFvDQF020642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 17:57:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0LFvDjp045411; Wed, 21 Jan 2009 17:57:13 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0LFvDv5045410; Wed, 21 Jan 2009 17:57:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Jan 2009 17:57:13 +0200 From: Kostik Belousov To: Andriy Gapon Message-ID: <20090121155713.GP58517@deviant.kiev.zoral.com.ua> References: <49773938.5010000@icyb.net.ua> <20090121153908.GO58517@deviant.kiev.zoral.com.ua> <4977444E.8050306@icyb.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FbmEh7Ek6NM6xKh/" Content-Disposition: inline In-Reply-To: <4977444E.8050306@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LPfS8-000L34-Lj 82b12179c113a912744efbcce1eac9ee X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: MOD_UNLOAD and driver with cdev 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, 21 Jan 2009 15:57:18 -0000 --FbmEh7Ek6NM6xKh/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2009 at 05:50:38PM +0200, Andriy Gapon wrote: > on 21/01/2009 17:39 Kostik Belousov said the following: > > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: > >> Do I need to code for MOD_UNLOAD for driver module that also creates a= cdev? > >> I see in the current code that one strategy is to simply call > >> destroy_dev(). I guess detach routines are called automatically and > >> destroy_dev can be done there as well.. > > What are the detach routines ? Do you mean newbus device detach ? >=20 > Yes, device_detach. This seems to work and make_device_driver.sh also > suggests it this way. But I am not sure about possible races. >=20 > > Yes, the usual strategy is to call destroy_dev from unload handler. > >=20 > >> Is it reasonable to refuse unload if cdev is in use (in MOD_QUIESCE)? > >> How to check for that best? > >=20 > > This cannot be checked race-free. >=20 > So no point in trying? I would say no. You could use count_dev(), but my own experience shown that ability to unload driver is more important then unadvertently knock out filedescriptor from under the running program. --FbmEh7Ek6NM6xKh/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkl3RdkACgkQC3+MBN1Mb4g3UACgnTrYA02QZeOjXrEJmrGnDCdE SEQAn1a85AOQLOH1HLVZ+ivEcpFxuPl2 =2Y5h -----END PGP SIGNATURE----- --FbmEh7Ek6NM6xKh/-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 20:09: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 3B6CA10656C6; Wed, 21 Jan 2009 20:09:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F0A488FC12; Wed, 21 Jan 2009 20:09:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9CE8546B32; Wed, 21 Jan 2009 15:09:40 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LK9NdS035728; Wed, 21 Jan 2009 15:09:34 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 21 Jan 2009 14:02:52 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211402.52967.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 15:09:34 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov , jb@freebsd.org, pluknet Subject: Re: PRINTF_BUFR_SIZE in freebsd6 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, 21 Jan 2009 20:09:41 -0000 On Wednesday 17 December 2008 8:52:38 am pluknet wrote: > 2008/12/17 pluknet : > > 2008/12/16 Kostik Belousov : > >> On Tue, Dec 16, 2008 at 03:23:28PM +0300, pluknet wrote: > >>> Hi. > >>> > >>> Could the PRINTF_BUFR_SIZE option be safely merged into RELENG_6 without > >>> merging a possible underlining infrastructure and breaking something else? > >>> I want to use it in my custom freebsd6 because I see "interspersed strings > >>> written from different CPUs at the same time": > >>> > >>> uuusseseerrvmrem: vlmivmeimtme :e mx:ceed eldi bly 2i89m68m (iihttt t > >>> pde) eaxtx cfcorke1 22e3e > >>> deded ebyd by28 296898 68(h t(tpdh) att ftorkp1 22d3 > >>> ) at fork1 223 > >>> > >>> I'm talking about only merging kern/subr_prf.c 1.126, 1.128, 1.129. > >>> > >>> Thanks. > >> > >> I did a backport of the option some time ago, see > >> http://people.freebsd.org/~kib/misc/releng_6_printf_bufr.3.patch > >> > > > > Thank you! > > > > 6.3 system panics (many page faults, one after another) early at boot > > without the option, and boots with it in the QEMU environment. > > Next step to test it on a real (and SMPable) hardware. > > > > Now tested on a real 2xXeon 3.0 w/ HTT enabled w/ PRINTF_BUFR_SIZE enabled. > > Received the following panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x72 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07fc8c3 > stack pointer = 0x28:0xe4f56a78 > frame pointer = 0x28:0xe4f56b44 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 14 (swi4: clock sio) > [thread pid 14 tid 100002 ] > Stopped at vm_fault+0x1e3: cmpw $0,0x72(%eax) > db> bt > Tracing pid 14 tid 100002 td 0xc63e9c80 > vm_fault(c1066000,c009e000,2,0) at vm_fault+0x1e3 > trap_pfault(e4f56bb0,0,c009effe) at trap_pfault+0x137 > trap(410008,c63e0028,e4f50028,c009effe,c638effe,...) at trap+0x325 > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc08a2cad, esp = 0xe4f56bf0, ebp = 0xe4f56c10 --- > generic_bcopy(c0a63a68,7cf,c0a63a4c,7cf,fffff832) at generic_bcopy+0x41 > vga_txtdraw(c0a63a40,7cf,fffff832,0) at vga_txtdraw+0xbe > scrn_update(c0a63a40,1) at scrn_update+0x22d > scrn_timer(c0a6c1e0) at scrn_timer+0x1e0 > softclock(0) at softclock+0x1f4 > ithread_execute_handlers(c63e8460,c6629800) at ithread_execute_handlers+0xd6 > ithread_loop(c63a7910,e4f56d38,c0a10040,0,c0922ea6,...) at ithread_loop+0x53 > fork_exit(c068d158,c63a7910,e4f56d38) at fork_exit+0x61 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4f56d6c, ebp = 0 --- > db> I've seen this panic (or varations of it) on stock 6.x for a long time. I suspect some sort of bug in syscons itself. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 20:09: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 F267F10656D1 for ; Wed, 21 Jan 2009 20:09:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C4D538FC29 for ; Wed, 21 Jan 2009 20:09:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 745BB46B2E; Wed, 21 Jan 2009 15:09:47 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LK9NdT035728; Wed, 21 Jan 2009 15:09:41 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 21 Jan 2009 14:07:43 -0500 User-Agent: KMail/1.9.7 References: <4947AA3C.4040005@icyb.net.ua> In-Reply-To: <4947AA3C.4040005@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211407.44021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 15:09:41 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andriy Gapon Subject: Re: usb keyboard vs btx: an SMI theory 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, 21 Jan 2009 20:09:48 -0000 On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: > Again, I am very fuzzy about the exact details, but I think that this is > something that could be happening and I think that SMI is of primary > interest here. I also think that this might explain to a certain degree > the difference in behavior between "older" btx and "newer" btx. One thing to keep in mind is that when an SMI# is delivered, the processor enters System Management Mode (SMM). In SMM, the CPU actually uses a different set of memory for its RAM. It also runs in a sort of weird 32-bit real mode. It is not going to call the stock IRQ 1 handler. Instead, it passes data back to "normal" mode by changing the values restored into registers when exiting SMM. Typically doing an I/O port access to the ports backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler emulates the inb/outb request by storing the resulting data for an inb in the %ax register the "normal" mode sees once it resumes execution after the 'inb' instruction. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 20:09: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 CDE40106576A for ; Wed, 21 Jan 2009 20:09:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9548FC22 for ; Wed, 21 Jan 2009 20:09:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 3343D46B32; Wed, 21 Jan 2009 15:09:53 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0LK9NdU035728; Wed, 21 Jan 2009 15:09:47 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 21 Jan 2009 14:08:37 -0500 User-Agent: KMail/1.9.7 References: <20081216230430.GA24352@curry.mchp.siemens.de> <20081223173322.GA4123@curry.mchp.siemens.de> In-Reply-To: <20081223173322.GA4123@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901211408.37883.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 21 Jan 2009 15:09:47 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8885/Wed Jan 21 12:48:08 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Andre Albsmeier Subject: Re: How to "detach" a foreign driver from a device so my driver can attach? 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, 21 Jan 2009 20:09:54 -0000 On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote: > On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote: > > Hello all, > > > > I am writing a driver which attaches to the Host-PCI bridge. When > > compiled into the kernel or loaded by the loader everything works > > and the driver gets attached. This is due to the fact that I return > > BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000 > > returned by pci_hostb_probe() in i386/pci/pci_bus.c. > > > > However, when I want to load my driver via kldload this fails since > > the hostb device has already been attached during kernel load (when > > my driver was not present): > > > > hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00 > > > > What can I do to make my driver load via kldload? > > Is there a way to detach the hostb0 from the Host-PCI bridge? > > Found the answer myself but will post it here in case anyone > got a similar problem one day: I added the device detach method > for the hostb driver to sys/i386/pci/pci_bus.c: > > --- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.000000000 +0200 > +++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.000000000 +0100 > @@ -619,10 +619,13 @@ > return 0; > } > > +static int pci_hostb_detach(device_t dev) { return 0; } > + > static device_method_t pci_hostb_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, pci_hostb_probe), > DEVMETHOD(device_attach, pci_hostb_attach), > + DEVMETHOD(device_detach, pci_hostb_detach), > DEVMETHOD(device_shutdown, bus_generic_shutdown), > DEVMETHOD(device_suspend, bus_generic_suspend), > DEVMETHOD(device_resume, bus_generic_resume), > > Now, when kldload'ing my driver, it can walk through all devices > and detach hostb using device_detach(). In the case of hostb, this is wrong however. You want to attach as a child of hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as well. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 23:00:37 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 330131065670; Wed, 21 Jan 2009 23:00:37 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green.homeunix.org [66.92.150.152]) by mx1.freebsd.org (Postfix) with ESMTP id CACC88FC3D; Wed, 21 Jan 2009 23:00:36 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (obama@localhost [127.0.0.1]) by green.homeunix.org (8.14.3/8.14.1) with ESMTP id n0LN0Y8a012869; Wed, 21 Jan 2009 18:00:34 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.14.3/8.14.1/Submit) id n0LN0X8w012868; Wed, 21 Jan 2009 18:00:33 -0500 (EST) (envelope-from green) Date: Wed, 21 Jan 2009 18:00:33 -0500 From: Brian Fundakowski Feldman To: Jason Evans Message-ID: <20090121230033.GC12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090120004135.GB12007@green.homeunix.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hackers@FreeBSD.org, Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 21 Jan 2009 23:00:37 -0000 On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote: > On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: > > Brian Fundakowski Feldman wrote: > > > Could you, and anyone else who would care to, check this out? It's a > > regression > >> fix but it also makes the code a little bit clearer. Thanks! > >> > >> Index: lib/libc/stdlib/malloc.c > > > > Why does malloc need to change for this? Unless there's a really good > > reason, I don't want the extra branches in the locking functions. > > Because malloc is the thing causing the regression. It is easy enough > to optimize out the one extra fetch and branch in the single-threaded case > if I can get some consensus that the fix to it is actually fine. Pessimization removed: Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 187160) +++ lib/libc/stdlib/malloc.c (working copy) @@ -1217,6 +1217,13 @@ _SPINUNLOCK(&mutex->lock); } +static inline void +malloc_mutex_always_unlock(malloc_mutex_t *mutex) +{ + + _SPINUNLOCK(&mutex->lock); +} + /* * End mutex. */ @@ -1300,6 +1307,13 @@ _pthread_mutex_unlock(lock); } +static inline void +malloc_spin_always_unlock(pthread_mutex_t *lock) +{ + + _pthread_mutex_unlock(lock); +} + /* * End spin lock. */ @@ -5515,9 +5529,8 @@ void _malloc_prefork(void) { + arena_t *larenas[narenas]; bool again; - unsigned i, j; - arena_t *larenas[narenas], *tarenas[narenas]; /* Acquire all mutexes in a safe order. */ @@ -5530,19 +5543,23 @@ */ memset(larenas, 0, sizeof(arena_t *) * narenas); do { + unsigned int i; + again = false; malloc_spin_lock(&arenas_lock); for (i = 0; i < narenas; i++) { if (arenas[i] != larenas[i]) { + arena_t *tarenas[narenas]; + unsigned int j; + memcpy(tarenas, arenas, sizeof(arena_t *) * narenas); malloc_spin_unlock(&arenas_lock); for (j = 0; j < narenas; j++) { if (larenas[j] != tarenas[j]) { larenas[j] = tarenas[j]; - malloc_spin_lock( - &larenas[j]->lock); + malloc_spin_lock(&larenas[j]->lock); } } again = true; @@ -5569,19 +5586,24 @@ /* Release all mutexes, now that fork() has completed. */ #ifdef MALLOC_DSS - malloc_mutex_unlock(&dss_mtx); + malloc_mutex_always_unlock(&dss_mtx); #endif - malloc_mutex_unlock(&huge_mtx); + malloc_mutex_always_unlock(&huge_mtx); - malloc_mutex_unlock(&base_mtx); + malloc_mutex_always_unlock(&base_mtx); memcpy(larenas, arenas, sizeof(arena_t *) * narenas); - malloc_spin_unlock(&arenas_lock); + malloc_spin_always_unlock(&arenas_lock); for (i = 0; i < narenas; i++) { if (larenas[i] != NULL) - malloc_spin_unlock(&larenas[i]->lock); + malloc_spin_always_unlock(&larenas[i]->lock); } + /* + * This ends the special post-__isthreaded exemption behavior for + * malloc stuff. We should really be single threaded right now + * in effect regardless of __isthreaded status. + */ } /* Index: lib/libthr/thread/thr_fork.c =================================================================== --- lib/libthr/thread/thr_fork.c (revision 187160) +++ lib/libthr/thread/thr_fork.c (working copy) @@ -105,7 +105,7 @@ struct pthread_atfork *af; pid_t ret; int errsave; - int unlock_malloc; + int was_threaded; int rtld_locks[MAX_RTLD_LOCKS]; if (!_thr_is_inited()) @@ -122,16 +122,16 @@ } /* - * Try our best to protect memory from being corrupted in - * child process because another thread in malloc code will - * simply be kill by fork(). + * All bets are off as to what should happen soon if the parent + * process was not so kindly as to set up pthread fork hooks to + * relinquish all running threads. */ if (_thr_isthreaded() != 0) { - unlock_malloc = 1; + was_threaded = 1; _malloc_prefork(); _rtld_atfork_pre(rtld_locks); } else { - unlock_malloc = 0; + was_threaded = 0; } /* @@ -159,7 +159,7 @@ _thr_umutex_init(&curthread->lock); _thr_umutex_init(&_thr_atfork_lock); - if (unlock_malloc) + if (was_threaded) _rtld_atfork_post(rtld_locks); _thr_setthreaded(0); @@ -173,7 +173,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) + if (was_threaded) _malloc_postfork(); /* Run down atfork child handlers. */ @@ -188,7 +188,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) { + if (was_threaded) { _rtld_atfork_post(rtld_locks); _malloc_postfork(); } -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 23:26: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 4F50D106564A for ; Wed, 21 Jan 2009 23:26:11 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id A9B5F8FC08 for ; Wed, 21 Jan 2009 23:26:10 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fxm4 with SMTP id 4so973517fxm.19 for ; Wed, 21 Jan 2009 15:26:09 -0800 (PST) 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=nTnxSF+6Ntb4BIbyBn+MHaHZp6gPGuagHsbLvVOzdeE=; b=AExo+/5x3dnOuP2wKEIKqmu5iEwSalZt8//fCRalLVwhFmAEd14jvWzlkUOjIV/vEc RFiuRfvl9BHngJuondd2AI7OkKQ9rOqm2NJFuyC9BuWXIXd9mrbW1DzN17swcxAOqc7+ vrVug1oQ5nNK7c5LDTwt0iGa+xEGDAMJL5egc= 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=v/c0RMZ/IKCD1lkCmgvGKDDT5w+ks9EmPoSA3t6BABrjmYJJQDGkxgfrp9jocDJ55N A51sIPZ+hqnOkE2ZNAJtEoij8t6lS96c2RSmufkgxRswNDgWMzcgjwHs3RquuebYv/mI xKnJqOBfD7hFHGLtto4h39KPUOXactaDNqWuY= MIME-Version: 1.0 Received: by 10.181.137.17 with SMTP id p17mr3060666bkn.193.1232580369399; Wed, 21 Jan 2009 15:26:09 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2009 15:26:09 -0800 Message-ID: <7d6fde3d0901211526x26e03968n658874fe7a7b85cf@mail.gmail.com> From: Garrett Cooper To: Andrew Brampton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove 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, 21 Jan 2009 23:26:11 -0000 On Wed, Jan 21, 2009 at 4:12 AM, Andrew Brampton wrote: > Hi, > I'm doing the unusual task of converting some c++ code into a FreeBSD > kernel module. Now all has been going great, and thus far I've been > able to debug quite a bit of it using printfs. However, I decided to > start using a kernel debugger, and to make this easier I passed g++ > the =96O0 flag, to make it compile without optimisations. > > Bang, I hit a problem. All of a sudden when using the =96O0 my module > wouldn't load because it was missing an undefined reference to > memmove. I found the specific object file which was using memmove. I > did that by doing objdump =96t *.o and finding which file had an > undefined symbol memmove. Once I found the object file I grepped the > associated source and I was sure I was not using memmove. I then got > gcc to output both the post-processed source, as well as the asm. > > The .ii file (post-processed source) did NOT mention memmove at all. > So I found it very odd that an undefined symbol existed in the object > file. So then I looked in the .s file (asm), and it was clearing > making a single call to memmove. > > So after a few hours of pulling my hair out I found this in the gcc manua= l: > "-nostdlib .... The compiler may generate calls to memcmp, memset, > memcpy and memmove. These entries are usually resolved by entries in > libc. These entry points should be supplied through some other > mechanism when this option is specified." > > So it appears that gcc may add calls to those four functions even if > you don't use them yourself? I assume this has not been a problem for > anyone yet due to only crazy people trying to use c++ in the kernel, > and the specific set of gcc options I'm using. > > For the moment I have fixed this problem now by defining my own memmove l= ike so: > > extern "C" void * memmove(void * dst, const void * src, size_t len) { > bcopy(src, dst, len); > return dst; > } > > But I was wondering if those four functions should be defined in the > kernel? I notice that memcpy and memset are already defined by the > kernel somewhere, so perhaps memmove and memcmp should join them? > > Oh I should mention this was happening with the default gcc under FreeBSD= 7.1. > > Thanks > Andrew And you #include'd string.h? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 23:36:01 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 6C39B106566B; Wed, 21 Jan 2009 23:36:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2397D8FC12; Wed, 21 Jan 2009 23:35:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n0LNZuuV020739; Wed, 21 Jan 2009 18:35:57 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Wed, 21 Jan 2009 18:35:57 -0500 (EST) Date: Wed, 21 Jan 2009 18:35:56 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Brian Fundakowski Feldman In-Reply-To: <20090121230033.GC12007@green.homeunix.org> Message-ID: References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jason Evans , Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2009 23:36:01 -0000 On Wed, 21 Jan 2009, Brian Fundakowski Feldman wrote: > On Mon, Jan 19, 2009 at 07:41:35PM -0500, Brian Fundakowski Feldman wrote: >> On Fri, Jan 16, 2009 at 02:36:06PM -0800, Jason Evans wrote: >>> Brian Fundakowski Feldman wrote: >>> > Could you, and anyone else who would care to, check this out? It's a >>> regression >>>> fix but it also makes the code a little bit clearer. Thanks! >>>> >>>> Index: lib/libc/stdlib/malloc.c >>> >>> Why does malloc need to change for this? Unless there's a really good >>> reason, I don't want the extra branches in the locking functions. >> >> Because malloc is the thing causing the regression. It is easy enough >> to optimize out the one extra fetch and branch in the single-threaded case >> if I can get some consensus that the fix to it is actually fine. The changes to thr_fork.c seem gratuituous; they don't affect any functionality, and I don't see the difference between the flag saying "unlock the malloc mutex" or "I was threaded". Clearly, it is set in "if (__isthreaded)", so it is obvious that it indeed was threaded. I can't speak to the malloc changes... -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 21 23:44: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 312C6106564A for ; Wed, 21 Jan 2009 23:44:23 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id E83BF8FC0A for ; Wed, 21 Jan 2009 23:44:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:1416:e549:1db8:acb8] (unknown [IPv6:2001:7b8:3a7:0:1416:e549:1db8:acb8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 149E111F859; Thu, 22 Jan 2009 00:44:22 +0100 (CET) Message-ID: <4977B357.2080500@andric.com> Date: Thu, 22 Jan 2009 00:44:23 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre MIME-Version: 1.0 To: Andrew Brampton References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove 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, 21 Jan 2009 23:44:23 -0000 On 2009-01-21 13:12, Andrew Brampton wrote: > The .ii file (post-processed source) did NOT mention memmove at all. > So I found it very odd that an undefined symbol existed in the object > file. So then I looked in the .s file (asm), and it was clearing > making a single call to memmove. This can (amongst others) occur if you assign structs, e.g.: int test(void) { struct foo { char bar[100]; } a, b; b = a; } Compile this with gcc -O0 -S, and you'll see it generates a call to memcpy(). From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 00:14: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 072391065677 for ; Thu, 22 Jan 2009 00:14:55 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id 629B38FC26 for ; Thu, 22 Jan 2009 00:14:54 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by gxk14 with SMTP id 14so4505283gxk.19 for ; Wed, 21 Jan 2009 16:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=olk6QACZgDkpKYs/okTwRqtmgvjQ8+E44r/xRCzsjFw=; b=iJPIbahHDAzHZMEwwuzJKSZRLdW3+3mMF3RRp9/vCjaUvYp3ZlF8i2PRgRv2z5Zc/h fD43hHrg3YD2WBBZHieSjaoXUGv3C8uQbi63VMRAfbHmA5BVUbuQS5NqVWJH7ua1T1Yh fwagrQ8RQAe4XKl7VEB5boFW3TF0EZO6XwaAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=qKHPqqZe7liImvR+YiTWDT6o/JNs0jKphLEdhgfUmpvQ5spA3fg1sqtZWhevYe+Jmr JeiMQRO4J5ketziCppOFysH9AwDDXRVlOz7nY7g3BWQReOygpuTiyvBjShiVfwXLasue 6fnh481Gl6ryohT2y01WVwgc7gvbfM7Rwuh1I= Received: by 10.150.219.16 with SMTP id r16mr496759ybg.17.1232581971922; Wed, 21 Jan 2009 15:52:51 -0800 (PST) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id i52sm17112892rne.18.2009.01.21.15.52.50 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 15:52:51 -0800 (PST) Date: Wed, 21 Jan 2009 18:52:45 -0500 From: Alexander Kabaev To: Dimitry Andric Message-ID: <20090121185245.00739316@kan.dnsalias.net> In-Reply-To: <4977B357.2080500@andric.com> References: <4977B357.2080500@andric.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/7TM59FX/r37fSNZHRWdH19J"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: Kernel Module - GCC Requires memmove 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, 22 Jan 2009 00:14:55 -0000 --Sig_/7TM59FX/r37fSNZHRWdH19J Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 22 Jan 2009 00:44:23 +0100 Dimitry Andric wrote: > On 2009-01-21 13:12, Andrew Brampton wrote: > > The .ii file (post-processed source) did NOT mention memmove at all. > > So I found it very odd that an undefined symbol existed in the > > object file. So then I looked in the .s file (asm), and it was > > clearing making a single call to memmove. >=20 > This can (amongst others) occur if you assign structs, e.g.: >=20 > int test(void) > { > struct foo { > char bar[100]; > } a, b; >=20 > b =3D a; > } >=20 > Compile this with gcc -O0 -S, and you'll see it generates a call to > memcpy(). > _______________________________________________ > 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" =46rom GCC's info pages: Most of the compiler support routines used by GCC are present in `libgcc', but there are a few exceptions. GCC requires the freestanding environment provide `memcpy', `memmove', `memset' and `memcmp'.=20 We do not provide all necessary functions in kernel and mostly depend on luck for the kernel to link. Your luck apparently ran out :( --=20 Alexander Kabaev --Sig_/7TM59FX/r37fSNZHRWdH19J Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJd7VNQ6z1jMm+XZYRAk0pAKCZEn45WIWw1uGOJ7vxIrN/gNEA4wCgtlXb oMe7pMEfENFjjxujEjSUSQw= =MX+Y -----END PGP SIGNATURE----- --Sig_/7TM59FX/r37fSNZHRWdH19J-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 00:52: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 87A5A1065673 for ; Thu, 22 Jan 2009 00:52:15 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1256B8FC0A for ; Thu, 22 Jan 2009 00:52:14 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by fk-out-0910.google.com with SMTP id f40so502030fka.11 for ; Wed, 21 Jan 2009 16:52:14 -0800 (PST) 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=pqsPVBXJy/Wq6cIEkPLz8spV0NMUZz5T/IKngpF/E6s=; b=tRsLuea2glsyHzd8IUFQ5uBylD+l2bxk3bL5b6VdnE+z8+zrXGX8GRY2GQ51moyQNf EJatD7eOOOEk1/m4a0yzf73JPtlvmVfKlcIGy1LJJ9SlLJSoHujocjMj+aoC1uTjnaEN KGhmh3hJrCgAiyTx1bqkbbhCZuhWWp+nzz4oA= 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=kqJj/okI5EcN+LkxdunM8tgp6FBsUpjN5OmyOIjQ3ynm6xH+/QFw5Gba3JgVsBAMQT 5t1HDgbEDyCwJYgjrMuyaFagk8AOgTN3mH2ZxPIPYC5R+g3D7yS6SNjV/8/q/VFDFI8M FEm6pVPCBKXLgWbmb/aSv+PIYzxGuzekm+rQs= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.223.103.207 with SMTP id l15mr2929344fao.2.1232585533946; Wed, 21 Jan 2009 16:52:13 -0800 (PST) In-Reply-To: <20090121185245.00739316@kan.dnsalias.net> References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> Date: Thu, 22 Jan 2009 00:52:13 +0000 X-Google-Sender-Auth: 86dc5910537cd8c1 Message-ID: From: Andrew Brampton To: Alexander Kabaev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove 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, 22 Jan 2009 00:52:15 -0000 2009/1/21 Alexander Kabaev : > From GCC's info pages: > > Most of the compiler support routines used by GCC are present in > `libgcc', but there are a few exceptions. GCC requires the > freestanding environment provide `memcpy', `memmove', `memset' and > `memcmp'. > > > We do not provide all necessary functions in kernel and mostly depend > on luck for the kernel to link. Your luck apparently ran out :( > Thanks for the info, good thing I'm not a gambling man. Anyway I also read that part of the GCC manual, so my next question is: If code can be generated with those four functions, why are they not exported by the kernel? Surely another kernel module will at some point also be hit by this? thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 01:07: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 C30FB106566C for ; Thu, 22 Jan 2009 01:07:36 +0000 (UTC) (envelope-from kabaev@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 72E768FC0A for ; Thu, 22 Jan 2009 01:07:36 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1671691ywe.13 for ; Wed, 21 Jan 2009 17:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=0J8GJP1WD1+6KCQYneZGEZmZ49Y51uDvJuqDJ6v2KEo=; b=cyB708DuDjHEFqHAJKccBccQDJcg74npQuHAcDnxgGCUMvyBCqJlEDivu3kYH0aX5o 0ou8234vChCiqvCT2eFz1CpiFLRIM+EpwMJ1rAoJWBgG17iUbk2qEfpS1mKRzz6CTx68 4w5g/JiQjQdii7K1GQCY/9RAdnt22wuQbrejU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=snGog6YKcfJl83QanUqFBe+781vFQYkNNApoSO+xUsrIC9PviRLmJOJwtWF9/JuyPq wStP1PCXNyURWMqtm9jzei7CWz8Ko1VDpf5h9zQEZr7KRq6ZiZ5lcc8Z+yYjpvURs52i VUJgBMKdddNogXFLn0xEzkIPIyuu0gYNB3bno= Received: by 10.151.111.1 with SMTP id o1mr6094162ybm.28.1232586455638; Wed, 21 Jan 2009 17:07:35 -0800 (PST) Received: from kan.dnsalias.net (c-98-217-224-113.hsd1.ma.comcast.net [98.217.224.113]) by mx.google.com with ESMTPS id k49sm17276200rnd.13.2009.01.21.17.07.34 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 17:07:35 -0800 (PST) Date: Wed, 21 Jan 2009 20:07:30 -0500 From: Alexander Kabaev To: Andrew Brampton Message-ID: <20090121200730.121e3e28@kan.dnsalias.net> In-Reply-To: References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/x87sEwRtdH4Y5Qwu25Wxzy0"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove 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, 22 Jan 2009 01:07:37 -0000 --Sig_/x87sEwRtdH4Y5Qwu25Wxzy0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 22 Jan 2009 00:52:13 +0000 Andrew Brampton wrote: > 2009/1/21 Alexander Kabaev : > > From GCC's info pages: > > > > Most of the compiler support routines used by GCC are present in > > `libgcc', but there are a few exceptions. GCC requires the > > freestanding environment provide `memcpy', `memmove', `memset' and > > `memcmp'. > > > > > > We do not provide all necessary functions in kernel and mostly > > depend on luck for the kernel to link. Your luck apparently ran > > out :( > > >=20 > Thanks for the info, good thing I'm not a gambling man. Anyway I also > read that part of the GCC manual, so my next question is: If code can > be generated with those four functions, why are they not exported by > the kernel? Surely another kernel module will at some point also be > hit by this? >=20 > thanks > Andrew Very good question and the answer is simple: we do not export these functions because nobody needed them yet :) Historically we have grown these functions on an 'as needed' basis. I am sure the patch to add missing functions would get committed if it were made available. --=20 Alexander Kabaev --Sig_/x87sEwRtdH4Y5Qwu25Wxzy0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJd8bSQ6z1jMm+XZYRAqe8AJ9lbnx3zcxJ58dtMeqr8KF1THYpIACghpaO AaDOBgvg5O79LmHt3PrB7V4= =VVG0 -----END PGP SIGNATURE----- --Sig_/x87sEwRtdH4Y5Qwu25Wxzy0-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 01:14: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 06C2A106566B for ; Thu, 22 Jan 2009 01:14:45 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id D93608FC1A for ; Thu, 22 Jan 2009 01:14:44 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0M1Eio15560; Wed, 21 Jan 2009 17:14:44 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0M1Ei706522; Wed, 21 Jan 2009 17:14:44 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Wed, 21 Jan 2009 17:14:44 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Andrew Brampton In-Reply-To: Message-ID: References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Module - GCC Requires memmove 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, 22 Jan 2009 01:14:45 -0000 On Thu, 22 Jan 2009, Andrew Brampton wrote: > 2009/1/21 Alexander Kabaev : >> From GCC's info pages: >> >> Most of the compiler support routines used by GCC are present in >> `libgcc', but there are a few exceptions. GCC requires the >> freestanding environment provide `memcpy', `memmove', `memset' and >> `memcmp'. >> >> >> We do not provide all necessary functions in kernel and mostly depend >> on luck for the kernel to link. Your luck apparently ran out :( >> > > Thanks for the info, good thing I'm not a gambling man. Anyway I also > read that part of the GCC manual, so my next question is: If code can > be generated with those four functions, why are they not exported by > the kernel? Surely another kernel module will at some point also be > hit by this? Possibly because the kernel is usually compiled with optimization, in which case the compiler presumably generates inline code for these functions. I vaguely recall Linux having a policy that compiling the kernel without optimization was not supported, possibly because of situations like this. -- Nate Eldredge neldredge@math.ucsd.edu From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 05:06: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 74CB71065780; Thu, 22 Jan 2009 05:06:12 +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 119798FC12; Thu, 22 Jan 2009 05:06:11 +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 n0M4ubZE061171; Wed, 21 Jan 2009 23:56:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0M4ubsE061170; Wed, 21 Jan 2009 23:56:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 21 Jan 2009 23:56:37 -0500 From: David Schultz To: Daniel Eischen Message-ID: <20090122045637.GA61058@zim.MIT.EDU> Mail-Followup-To: Daniel Eischen , Brian Fundakowski Feldman , hackers@FreeBSD.ORG, Jason Evans , Julian Elischer References: <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Brian Fundakowski Feldman , hackers@FreeBSD.ORG, Jason Evans , Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 22 Jan 2009 05:06:12 -0000 I think there *is* a real bug here, but there's two distinct ways to fix it. When a threaded process forks, malloc acquires all its locks so that its state is consistent after a fork. However, the post-fork hook that's supposed to release these locks fails to do so in the child because the child process isn't threaded, and malloc_mutex_unlock() is optimized to be a no-op in single-threaded processes. If the child *stays* single-threaded, malloc() works by accident even with all the locks held because malloc_mutex_lock() is also a no-op in single-threaded processes. But if the child goes multi-threaded, then things break. Solution 1 is to actually unlock the locks in the child process, which is what Brian is proposing. Solution 2 is to take the position that all of this pre- and post-fork bloat in the fork() path is gratuitous and should be removed. The rationale here is that if you fork with multiple running threads, there's scads of ways in which the child's heap could be inconsistent; fork hooks would be needed not just in malloc(), but in stdio, third party libraries, etc. Why should malloc() be special? It's the programmer's job to quiesce all the threads before calling fork(), and if the programmer doesn't do this, then POSIX only guarantees that async-signal-safe functions will work. Note that Solution 2 also fixes Brian's problem if he quiesces all of his worker threads before forking (as he should!) With the pre-fork hook removed, all the locks will start out free in the child. So that's what I vote for... From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 05:42:59 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 DFF71106564A; Thu, 22 Jan 2009 05:42:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id AAEB88FC16; Thu, 22 Jan 2009 05:42:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n0M5gu8u021756; Thu, 22 Jan 2009 00:42:56 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Thu, 22 Jan 2009 00:42:57 -0500 (EST) Date: Thu, 22 Jan 2009 00:42:56 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Schultz In-Reply-To: <20090122045637.GA61058@zim.MIT.EDU> Message-ID: References: <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: hackers@freebsd.org, Jason Evans , Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 05:43:00 -0000 On Wed, 21 Jan 2009, David Schultz wrote: > I think there *is* a real bug here, but there's two distinct ways > to fix it. When a threaded process forks, malloc acquires all its > locks so that its state is consistent after a fork. However, the > post-fork hook that's supposed to release these locks fails to do > so in the child because the child process isn't threaded, and > malloc_mutex_unlock() is optimized to be a no-op in > single-threaded processes. If the child *stays* single-threaded, > malloc() works by accident even with all the locks held because > malloc_mutex_lock() is also a no-op in single-threaded processes. > But if the child goes multi-threaded, then things break. > > Solution 1 is to actually unlock the locks in the child process, > which is what Brian is proposing. > > Solution 2 is to take the position that all of this pre- and > post-fork bloat in the fork() path is gratuitous and should be > removed. The rationale here is that if you fork with multiple > running threads, there's scads of ways in which the child's heap > could be inconsistent; fork hooks would be needed not just in > malloc(), but in stdio, third party libraries, etc. Why should > malloc() be special? It's the programmer's job to quiesce all the > threads before calling fork(), and if the programmer doesn't do > this, then POSIX only guarantees that async-signal-safe functions > will work. > > Note that Solution 2 also fixes Brian's problem if he quiesces all > of his worker threads before forking (as he should!) With the > pre-fork hook removed, all the locks will start out free in the > child. So that's what I vote for... The problem is that our own libraries (libthr included) need to malloc() for themselves, even after a fork() in the child. After a fork(), the malloc locks should be reinitialized in the child if it was threaded, so that our implementation actually works for all the async signal calls, fork(), exec(), etc. I forget the exact failure modes for very common cases, but if you remove the re-initialization of the malloc locks, I'm sure you will have problems. Perhaps much of this malloc() stuff goes away when we move to pthread locks that are not pointers to allocated objects, but instead are actual objects/structures. This needs to be done in order for mutexes/CVs/etc to be PTHREAD_PROCESS_SHARED (placed in shared memory and used by multiple processes). In other words, pthread_mutex_t goes from this: typedef struct pthread_mutex *pthread_mutex_t; to something like this: struct __pthread_mutex { uint32_t lock; ... } typedef struct __pthread_mutex pthread_mutex_t; Same thing for CVs, and we probably should convert any other locks used internally by libc/libpthread (spinlocks). So after a fork(), there is no need to reallocate anything, it can just be reinitialized if necessary. -- DE From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 07:15:18 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 055AF106566B; Thu, 22 Jan 2009 07:15:18 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8DBE68FC22; Thu, 22 Jan 2009 07:15:16 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n0M7FGw4005059; Thu, 22 Jan 2009 08:15:16 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n0M7FF0t021981; Thu, 22 Jan 2009 08:15:15 +0100 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n0M7FF0C014172; Date: Thu, 22 Jan 2009 08:15:15 +0100 From: Andre Albsmeier To: John Baldwin Message-ID: <20090122071515.GA97409@curry.mchp.siemens.de> References: <20081216230430.GA24352@curry.mchp.siemens.de> <20081223173322.GA4123@curry.mchp.siemens.de> <200901211408.37883.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901211408.37883.jhb@freebsd.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org, Andre Albsmeier Subject: Re: How to "detach" a foreign driver from a device so my driver can attach? 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, 22 Jan 2009 07:15:18 -0000 On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote: > On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote: > > On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote: > > > Hello all, > > > > > > I am writing a driver which attaches to the Host-PCI bridge. When > > > compiled into the kernel or loaded by the loader everything works > > > and the driver gets attached. This is due to the fact that I return > > > BUS_PROBE_SPECIFIC in my probe routine which gains over the -10000 > > > returned by pci_hostb_probe() in i386/pci/pci_bus.c. > > > > > > However, when I want to load my driver via kldload this fails since > > > the hostb device has already been attached during kernel load (when > > > my driver was not present): > > > > > > hostb0@pci0:0:0: class=0x060000 card=0x11d510cf chip=0x35808086 > rev=0x02 hdr=0x00 > > > > > > What can I do to make my driver load via kldload? > > > Is there a way to detach the hostb0 from the Host-PCI bridge? > > > > Found the answer myself but will post it here in case anyone > > got a similar problem one day: I added the device detach method > > for the hostb driver to sys/i386/pci/pci_bus.c: > > > > --- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.000000000 +0200 > > +++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.000000000 +0100 > > @@ -619,10 +619,13 @@ > > return 0; > > } > > > > +static int pci_hostb_detach(device_t dev) { return 0; } > > + > > static device_method_t pci_hostb_methods[] = { > > /* Device interface */ > > DEVMETHOD(device_probe, pci_hostb_probe), > > DEVMETHOD(device_attach, pci_hostb_attach), > > + DEVMETHOD(device_detach, pci_hostb_detach), > > DEVMETHOD(device_shutdown, bus_generic_shutdown), > > DEVMETHOD(device_suspend, bus_generic_suspend), > > DEVMETHOD(device_resume, bus_generic_resume), > > > > Now, when kldload'ing my driver, it can walk through all devices > > and detach hostb using device_detach(). > > In the case of hostb, this is wrong however. You want to attach as a child of As I learned in the meanwhile, yes. But it was quite interesting to learn how things work when you have never been into FreeBSD driver hacking before ;-). > hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as > well. Would this work in 6.x as well? You wrote in another mail that in 7.0 agp attaches to hostb. This makes me think that in 6.x things are handled differently. If not, I will stick to my detaching while I am on 6.x (don't need agp on my 440BXs) and do it right when I have migrated to 7.x... Thanks, -Andre From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 07:15:24 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 81314106564A; Thu, 22 Jan 2009 07:15:24 +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 37BAD8FC08; Thu, 22 Jan 2009 07:15: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 n0M7H3Hu061853; Thu, 22 Jan 2009 02:17:03 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0M7H3c1061852; Thu, 22 Jan 2009 02:17:03 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 22 Jan 2009 02:17:03 -0500 From: David Schultz To: Daniel Eischen Message-ID: <20090122071703.GA61697@zim.MIT.EDU> Mail-Followup-To: Daniel Eischen , hackers@FreeBSD.ORG, Jason Evans , Julian Elischer References: <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: hackers@FreeBSD.ORG, Jason Evans , Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 22 Jan 2009 07:15:24 -0000 On Thu, Jan 22, 2009, Daniel Eischen wrote: > On Wed, 21 Jan 2009, David Schultz wrote: > > >I think there *is* a real bug here, but there's two distinct ways > >to fix it. When a threaded process forks, malloc acquires all its > >locks so that its state is consistent after a fork. However, the > >post-fork hook that's supposed to release these locks fails to do > >so in the child because the child process isn't threaded, and > >malloc_mutex_unlock() is optimized to be a no-op in > >single-threaded processes. If the child *stays* single-threaded, > >malloc() works by accident even with all the locks held because > >malloc_mutex_lock() is also a no-op in single-threaded processes. > >But if the child goes multi-threaded, then things break. > > > >Solution 1 is to actually unlock the locks in the child process, > >which is what Brian is proposing. > > > >Solution 2 is to take the position that all of this pre- and > >post-fork bloat in the fork() path is gratuitous and should be > >removed. The rationale here is that if you fork with multiple > >running threads, there's scads of ways in which the child's heap > >could be inconsistent; fork hooks would be needed not just in > >malloc(), but in stdio, third party libraries, etc. Why should > >malloc() be special? It's the programmer's job to quiesce all the > >threads before calling fork(), and if the programmer doesn't do > >this, then POSIX only guarantees that async-signal-safe functions > >will work. > > > >Note that Solution 2 also fixes Brian's problem if he quiesces all > >of his worker threads before forking (as he should!) With the > >pre-fork hook removed, all the locks will start out free in the > >child. So that's what I vote for... > > The problem is that our own libraries (libthr included) > need to malloc() for themselves, even after a fork() in > the child. After a fork(), the malloc locks should be > reinitialized in the child if it was threaded, so that > our implementation actually works for all the async > signal calls, fork(), exec(), etc. I forget the exact > failure modes for very common cases, but if you remove > the re-initialization of the malloc locks, I'm sure > you will have problems. If you can't implement functions that are required to be async-signal-safe like fork() and exec() without malloc(), then for now I guess we should go for something along the lines of what Brian is proposing. If the app programmer has taken special pains to ensure that all other threads are stopped when a fork happens, the fork() call shouldn't return in the child with all the malloc locks bogusly held. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 07:42: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 7C04D10656E3; Thu, 22 Jan 2009 07:42:58 +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 3457E8FC14; Thu, 22 Jan 2009 07:42:58 +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 n0M7ibgF062054; Thu, 22 Jan 2009 02:44:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n0M7ibO7062053; Thu, 22 Jan 2009 02:44:37 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 22 Jan 2009 02:44:37 -0500 From: David Schultz To: Daniel Eischen , hackers@FreeBSD.ORG, Jason Evans , Julian Elischer Message-ID: <20090122074437.GA61965@zim.MIT.EDU> Mail-Followup-To: Daniel Eischen , hackers@FreeBSD.ORG, Jason Evans , Julian Elischer References: <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> <49710BD6.7040705@FreeBSD.org> <20090120004135.GB12007@green.homeunix.org> <20090121230033.GC12007@green.homeunix.org> <20090122045637.GA61058@zim.MIT.EDU> <20090122071703.GA61697@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090122071703.GA61697@zim.MIT.EDU> Cc: Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 22 Jan 2009 07:42:58 -0000 On Thu, Jan 22, 2009, David Schultz wrote: > If you can't implement functions that are required to be > async-signal-safe like fork() and exec() without malloc(), then > for now I guess we should go for something along the lines of what > Brian is proposing. If the app programmer has taken special pains > to ensure that all other threads are stopped when a fork happens, > the fork() call shouldn't return in the child with all the malloc > locks bogusly held. Note that even with Brian's patch, the memory associated with the all the parent's threads' stacks is leaked, and libthr can't be expected to be in a particularly happy state after all of its threads disappear. It just happens to (sort of) work for now. In any case, it's clearly a bug that libthr's fork handler calls _malloc_postfork() in the child even when _malloc_postfork() doesn't work properly in the (now single-threaded) child. Which way to fix it is up to you guys... From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 08:45:49 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 D398B106567C for ; Thu, 22 Jan 2009 08:45:49 +0000 (UTC) (envelope-from xistence@0x58.com) Received: from mailexchange.osnn.net (mailexchange.osnn.net [70.86.102.30]) by mx1.freebsd.org (Postfix) with SMTP id 8C28F8FC32 for ; Thu, 22 Jan 2009 08:45:49 +0000 (UTC) (envelope-from xistence@0x58.com) Received: (qmail 78943 invoked by uid 0); 22 Jan 2009 08:45:48 -0000 Received: from unknown (HELO ?10.10.10.248?) (xistence@0x58.com@68.3.6.222) by mailexchange.osnn.net with SMTP; 22 Jan 2009 08:45:48 -0000 Message-Id: From: Bert JW Regeer To: FreeBSD Hackers Content-Type: multipart/signed; boundary=Apple-Mail-1-903676918; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 22 Jan 2009 01:45:47 -0700 X-Mailer: Apple Mail (2.930.3) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: freebsd-update's install_verify routine excessive stating 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, 22 Jan 2009 08:45:56 -0000 --Apple-Mail-1-903676918 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hackers, Recently I decided it would be time to upgrade an older laptop that was still running 6.2-RELEASE to a more recent release 7.1-RELEASE (re- install not possible, laptop has no cd-rom drive, and does not boot from a USB one). Everything went well, including the kernel update. It was not until after I rebooted and ran: ./freebsd-update.sh -f freebsd-update.conf install That I started noticing something rather weird. It had been running for a good 30 minutes before I started wondering what was going on. top gave me nothing of value, other than that all of the time was spent running sh, and that it was spending all of its time in system, not user where I would have expected it. Thinking went wrong I stopped the process and started it again. After a ktrace and kdump I found the culprit in install_verify in the freebsd-update utility, it would read one line, and then run stat on one of the many files that was listed in /usr/upgrade/files/. install_verify () { # Generate a list of hashes cat $@ | cut -f 2,7 -d '|' | grep -E '^f' | cut -f 2 -d '|' | sort -u > filelist # Make sure all the hashes exist while read HASH; do if ! [ -f files/${HASH}.gz ]; then echo -n "Update files missing -- " echo "this should never happen." echo "Re-run '$0 fetch'." return 1 fi done < filelist # Clean up rm filelist } running find /usr/upgrade/files/ | wc -l showed over 64000 files. So what was happening here is that freebsd-update.sh is doing due diligence in checking that all the files exist, however it uses the built in test utility to do so. While in normal situations this may not be that big of a deal since the changeset is likely to be small, running stat on 64000 individual files in a loop is rather slow. In my case I have just removed the offending code and hoped all went well, however this is off course not an acceptable solution. I have not yet come up with an acceptable way to fix the offending code, hence my post to hackers. I am also not sure as to how I would file a pr bug report for this situation, any guidance would be greatly appreciated. This email has become much longer than I had originally intended. I just wanted to get this out to see what you all had to say about this. Cheers, Bert JW Regeer --Apple-Mail-1-903676918-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 10:20: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 AA8DE106564A for ; Thu, 22 Jan 2009 10:20:26 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3F18FC14 for ; Thu, 22 Jan 2009 10:20:26 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:1910:dd32:a724:3707] (unknown [IPv6:2001:7b8:3a7:0:1910:dd32:a724:3707]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8C68C11F859; Thu, 22 Jan 2009 11:20:25 +0100 (CET) Message-ID: <4978486B.3070504@andric.com> Date: Thu, 22 Jan 2009 11:20:27 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090116 Shredder/3.0b2pre MIME-Version: 1.0 To: Nate Eldredge References: <4977B357.2080500@andric.com> <20090121185245.00739316@kan.dnsalias.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Andrew Brampton Subject: Re: Kernel Module - GCC Requires memmove 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, 22 Jan 2009 10:20:26 -0000 On 2009-01-22 02:14, Nate Eldredge wrote: > I vaguely recall Linux having a policy that compiling the kernel without > optimization was not supported, possibly because of situations like this. No, Linux has its own implementations of mem{cmp,cpy,move,set}, both in fallback C versions, and optimized versions for several arches. Compiling Linux without optimization will fail at the linking stage, due to extern inline functions in header files, without implementation in separate .c files. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 12:17: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 ECB7F1065672; Thu, 22 Jan 2009 12:17:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id BBD418FC08; Thu, 22 Jan 2009 12:17:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0MCHfuI086654; Thu, 22 Jan 2009 13:17:41 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0MCHfY3086653; Thu, 22 Jan 2009 13:17:41 +0100 (CET) (envelope-from olli) Date: Thu, 22 Jan 2009 13:17:41 +0100 (CET) Message-Id: <200901221217.n0MCHfY3086653@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 22 Jan 2009 13:17:42 +0100 (CET) Cc: Subject: Re: freebsd-update's install_verify routine excessive stating 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, 22 Jan 2009 12:17:46 -0000 Hi, I've Cc'ed Colin Percival, the author of freebsd-update. Bert JW Regeer wrote: > Recently I decided it would be time to upgrade an older laptop that > was still running 6.2-RELEASE to a more recent release 7.1-RELEASE > [...] > Everything went well, including the kernel update. It was not until > after I rebooted and ran: > > ./freebsd-update.sh -f freebsd-update.conf install > > That I started noticing something rather weird. It had been running > for a good 30 minutes before I started wondering what was going on. > top gave me nothing of value, other than that all of the time was > spent running sh, and that it was spending all of its time in system, > not user where I would have expected it. Thinking went wrong I stopped > the process and started it again. > > After a ktrace and kdump I found the culprit in install_verify in the > freebsd-update utility, it would read one line, and then run stat on > one of the many files that was listed in /usr/upgrade/files/. > > install_verify () { > # Generate a list of hashes > cat $@ | That should be "$@" with double quotes. $@ doesn't make sense without the quotes. Apart from that, it's a typical case of "useless use of cat". > cut -f 2,7 -d '|' | > grep -E '^f' | > cut -f 2 -d '|' | > sort -u > filelist It's unclear why there are two "cut" commands. The 7th field isn't used at all. Also, the -E option to grep is superfluous here. Finally, using awk might be more efficient than cut + grep. So I would suggest to replace the whole pipe with this: awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | sort -u > filelist > # Make sure all the hashes exist > while read HASH; do > if ! [ -f files/${HASH}.gz ]; then > echo -n "Update files missing -- " > echo "this should never happen." > echo "Re-run '$0 fetch'." > return 1 > fi > done < filelist > > # Clean up > rm filelist > } > > running find /usr/upgrade/files/ | wc -l showed over 64000 files. So > what was happening here is that freebsd-update.sh is doing due > diligence in checking that all the files exist, however it uses the > built in test utility to do so. While in normal situations this may > not be that big of a deal since the changeset is likely to be small, > running stat on 64000 individual files in a loop is rather slow. > > In my case I have just removed the offending code and hoped all went > well, however this is off course not an acceptable solution. I have > not yet come up with an acceptable way to fix the offending code, > hence my post to hackers. I am also not sure as to how I would file a > pr bug report for this situation, any guidance would be greatly > appreciated. You are right, that loop doesn't scale very well. I'm not surprised it is horribly slow with 64000 files on an old laptop that probably has a disk that isn't too fast. It would be much better to generate two lists: - The list of hashes, as already done ("filelist") - A list of gzipped files present, stripped to the hash: (cd files; echo *.gz) | tr ' ' '\n' | sed 's/\.gz$//' > filespresent Note we use "echo" instead of "ls", in order to avoid the kern.argmax limit. 64000 files would certainly exceed that limit. Also note that the output is already sorted because the shell sorts wildcard expansions. Now that we have those two files, we can use comm(1) to find out whether there are any hashes in filelist that are not in filespresent: if [ -n "$(comm -23 filelist filespresent)" ]; then echo -n "Update files missing -- " ... fi That solution scales much better because no shell loop is required at all. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Life is short (You need Python)" -- Bruce Eckel, ANSI C++ Comitee member, author of "Thinking in C++" and "Thinking in Java" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 12:33:49 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 4CE28106567F for ; Thu, 22 Jan 2009 12:33:49 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8CC8D8FC22 for ; Thu, 22 Jan 2009 12:33:48 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 22 Jan 2009 12:33:47 -0000 Received: from p54A3E2E9.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.226.233] by mail.gmx.net (mp056) with SMTP; 22 Jan 2009 13:33:47 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/GR8MRxgfGI0VyjL2y5ZmgX5RSdoweq7UN1vZzQh /JQ3LovZP6lb4p Message-ID: <497867A9.7000801@gmx.de> Date: Thu, 22 Jan 2009 13:33:45 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Oliver Fromme References: <200901221217.n0MCHfY3086653@lurza.secnetix.de> In-Reply-To: <200901221217.n0MCHfY3086653@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.66 Cc: freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 22 Jan 2009 12:33:49 -0000 Oliver Fromme schrieb: > > cut -f 2,7 -d '|' | > > grep -E '^f' | > > cut -f 2 -d '|' | > > sort -u > filelist > > It's unclear why there are two "cut" commands. The 7th > field isn't used at all. Also, the -E option to grep After the first cut the seventh field becomes the second: echo 'a|b|c|d|e|f|g' | cut -f 2,7 -d '|' So the second cut selects the original seventh field and fills it into the file "filelist". > > So I would suggest to replace the whole pipe with this: > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > sort -u > filelist It should print $7, see above. Christoph From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 12:44:49 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 5829B106564A; Thu, 22 Jan 2009 12:44:49 +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 3AA268FC17; Thu, 22 Jan 2009 12:44:47 +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 OAA25169; Thu, 22 Jan 2009 14:44:45 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <49786A3C.9070502@icyb.net.ua> Date: Thu, 22 Jan 2009 14:44:44 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Robert Watson References: <49770513.8090203@icyb.net.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-hackers@FreeBSD.org Subject: Re: device driver: cdesw questions? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 12:44:49 -0000 on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: >> I also would like the driver to provide a select capability quite >> similar to that of network (e.g. TCP) sockets using d_poll. I.e. a >> userland program should be able to query when it can write data to the >> device without blocking and when it can read data without blocking, plus >> when an error occurred in the device/driver, so there is no point in >> further waiting. >> At this moment I am thoroughly confused by meaning of various event >> masks described in poll(2). E.g. what is normal priority, non-zero >> priority and high priority. >> Which flags should I care about if all data is the same priority for me? >> Which flag(s) should I set when I'd like to communicate an error >> condition (e.g. similar to TCP connection reset)? > > I find that the description of the polling flags is at best confusing in > both man pages and specifications. The best bet is to look at the > existing TCP semantics, which are basically defined in sopoll_generic(): [snip] > A few observations: > > - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all > protocols use sopoll_generic in practice). This is surprising given the > wording in the poll(2) man page. > > - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference > between > soreadable() and the test in POLLIGNEOF is that POLLIN also considers > SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but > POLLIGNEOF doesn't. > > I think Kostik's pointer to the pipe_poll() code is a good one, but if > you're looking to emulate TCP semantics a bit more exactly, these > differences should be taken into account. Robert, Kostik, thank you for the great pointers. >From previous network programming I recall that if an error occurs on a TCP socket then select(2) marks the socket as available for reading (and probably for writing too), then a subsequent operation gets actual error code. I think that maybe this was the only way to do it in select-only days. I am a little bit confused about exceptfds parameter of select, the manual page says "The only exceptional condition detectable is out-of-band data received on a socket" and I am not sure what that would be for TCP and how that could be used in practice. Anyway, I'd probably stick to the same strategy - mark the device as available for reading and writing if an error occurs and then return error code in actual read/write. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 13:29: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 75C511065675; Thu, 22 Jan 2009 13:29:16 +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 5E0E68FC14; Thu, 22 Jan 2009 13:29:15 +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 PAA26865; Thu, 22 Jan 2009 15:29:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <497874A8.3070205@icyb.net.ua> Date: Thu, 22 Jan 2009 15:29:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: John Baldwin References: <4947AA3C.4040005@icyb.net.ua> <200901211407.44021.jhb@freebsd.org> In-Reply-To: <200901211407.44021.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: usb keyboard vs btx: an SMI theory 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, 22 Jan 2009 13:29:16 -0000 on 21/01/2009 21:07 John Baldwin said the following: > On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: >> Again, I am very fuzzy about the exact details, but I think that this is >> something that could be happening and I think that SMI is of primary >> interest here. I also think that this might explain to a certain degree >> the difference in behavior between "older" btx and "newer" btx. > > One thing to keep in mind is that when an SMI# is delivered, the processor > enters System Management Mode (SMM). In SMM, the CPU actually uses a > different set of memory for its RAM. It also runs in a sort of weird 32-bit > real mode. It is not going to call the stock IRQ 1 handler. Instead, it > passes data back to "normal" mode by changing the values restored into > registers when exiting SMM. Typically doing an I/O port access to the ports > backing the keyboard (0x60 and 0x64) cause an SMI# and the SMM handler > emulates the inb/outb request by storing the resulting data for an inb in > the %ax register the "normal" mode sees once it resumes execution after > the 'inb' instruction. > I've been thinking about that and also decided that my SMI theory is rubbish. On the other hand, I still suspect that there could be some race in protected<->real transition, but from looking at the code I can not imagine how it could happen. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 14:19: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 1CBDD10656BA; Thu, 22 Jan 2009 14:19:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 90B328FC44; Thu, 22 Jan 2009 14:19:56 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0MEJrr9092480; Thu, 22 Jan 2009 15:19:53 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0MEJrsK092478; Thu, 22 Jan 2009 15:19:53 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200901221419.n0MEJrsK092478@lurza.secnetix.de> To: christoph.mallon@gmx.de (Christoph Mallon) Date: Thu, 22 Jan 2009 15:19:53 +0100 (CET) In-Reply-To: <497867A9.7000801@gmx.de> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 22 Jan 2009 15:19:54 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 22 Jan 2009 14:19:57 -0000 Christoph Mallon wrote: > Oliver Fromme schrieb: > > > cut -f 2,7 -d '|' | > > > grep -E '^f' | > > > cut -f 2 -d '|' | > > > sort -u > filelist > > > > It's unclear why there are two "cut" commands. The 7th > > field isn't used at all. Also, the -E option to grep > > After the first cut the seventh field becomes the second: Ah yes, you're right, of course. My caffeine level was insufficient, I guess. :-) > > So I would suggest to replace the whole pipe with this: > > > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > > sort -u > filelist > > It should print $7, see above. Right. Thanks for pointing it out. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Whatever happened to the days when hacking started at the cerebral cortex, and not at the keyboard?" -- Sid on userfriendly.org by Illiad, 2007-06-20 From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 15:42:00 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 73CD0106571E for ; Thu, 22 Jan 2009 15:42:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 30DD18FC1B for ; Thu, 22 Jan 2009 15:42:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id CCE6F46B03; Thu, 22 Jan 2009 10:41:59 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0MFfgo1043174; Thu, 22 Jan 2009 10:41:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andre Albsmeier Date: Thu, 22 Jan 2009 10:18:05 -0500 User-Agent: KMail/1.9.7 References: <20081216230430.GA24352@curry.mchp.siemens.de> <200901211408.37883.jhb@freebsd.org> <20090122071515.GA97409@curry.mchp.siemens.de> In-Reply-To: <20090122071515.GA97409@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901221018.05726.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 22 Jan 2009 10:41:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8892/Thu Jan 22 09:34:53 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org Subject: Re: How to "detach" a foreign driver from a device so my driver can attach? 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, 22 Jan 2009 15:42:01 -0000 On Thursday 22 January 2009 2:15:15 am Andre Albsmeier wrote: > On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote: > > hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as > > well. > > Would this work in 6.x as well? You wrote in another mail that > in 7.0 agp attaches to hostb. This makes me think that in 6.x > things are handled differently. Yes, 6.x does not work this way. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 16:35: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 75D381065674 for ; Thu, 22 Jan 2009 16:35:47 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3A27B8FC1D for ; Thu, 22 Jan 2009 16:35:47 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4577A6D449; Thu, 22 Jan 2009 16:35:46 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 2BAD0844BA; Thu, 22 Jan 2009 17:35:46 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Bert JW Regeer References: Date: Thu, 22 Jan 2009 17:35:46 +0100 In-Reply-To: (Bert JW Regeer's message of "Thu, 22 Jan 2009 01:45:47 -0700") Message-ID: <86vds7nvrx.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers Subject: Re: freebsd-update's install_verify routine excessive stating 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, 22 Jan 2009 16:35:47 -0000 Bert JW Regeer writes: > [problems with freebsd-update] You should probably send a copy of this to cperciva@... DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 01:57: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 8A41F106566C for ; Fri, 23 Jan 2009 01:57:30 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 593928FC13 for ; Fri, 23 Jan 2009 01:57:30 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-72-81-43-86.phlapa.east.verizon.net [72.81.43.86]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 7B67B5D4AB; Fri, 23 Jan 2009 10:39:13 +0900 (JST) Date: Thu, 22 Jan 2009 20:38:19 -0500 From: Yoshihiro Ota To: Oliver Fromme Message-Id: <20090122203819.585fb35f.ota@j.email.ne.jp> In-Reply-To: <200901221217.n0MCHfY3086653@lurza.secnetix.de> References: <200901221217.n0MCHfY3086653@lurza.secnetix.de> 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, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 01:57:30 -0000 Hi. It's interesting. On Thu, 22 Jan 2009 13:17:41 +0100 (CET) Oliver Fromme wrote: > Hi, > > > So I would suggest to replace the whole pipe with this: > > awk -F "|" '$2 ~ /^f/ {print $2}' "$@" | > sort -u > filelist > > It would be much better to generate two lists: > - The list of hashes, as already done ("filelist") > - A list of gzipped files present, stripped to the hash: > > (cd files; echo *.gz) | > tr ' ' '\n' | > sed 's/\.gz$//' > filespresent > > Note we use "echo" instead of "ls", in order to avoid the > kern.argmax limit. 64000 files would certainly exceed that > limit. Also note that the output is already sorted because > the shell sorts wildcard expansions. > > Now that we have those two files, we can use comm(1) to > find out whether there are any hashes in filelist that are > not in filespresent: > > if [ -n "$(comm -23 filelist filespresent)" ]; then > echo -n "Update files missing -- " > ... > fi > > That solution scales much better because no shell loop is > required at all. This will probably be the fastest. awk -F "|" ' $2 ~ /^f/{required[$7]=$7; count++} END{FS="[/.]"; while("find files -name *.gz" | getline>0) if($2 in required) if(--count<=0) exit(0); exit(count)}' "$@" It verifies entries using hashtable instead of sort. Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. I am not well aware how good awk's associate array is, though. Regards, Hiro From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 11:09: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 85F0A1065673; Fri, 23 Jan 2009 11:09:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 048668FC22; Fri, 23 Jan 2009 11:09:07 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0NB94Jn069165; Fri, 23 Jan 2009 12:09:05 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0NB933k069163; Fri, 23 Jan 2009 12:09:03 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200901231109.n0NB933k069163@lurza.secnetix.de> To: ota@j.email.ne.jp (Yoshihiro Ota) Date: Fri, 23 Jan 2009 12:09:03 +0100 (CET) In-Reply-To: <20090122203819.585fb35f.ota@j.email.ne.jp> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 23 Jan 2009 12:09:05 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 11:09:09 -0000 Yoshihiro Ota wrote: > Oliver Fromme wrote: > > It would be much better to generate two lists: > > - The list of hashes, as already done ("filelist") > > - A list of gzipped files present, stripped to the hash: > > > > (cd files; echo *.gz) | > > tr ' ' '\n' | > > sed 's/\.gz$//' > filespresent > > > > Note we use "echo" instead of "ls", in order to avoid the > > kern.argmax limit. 64000 files would certainly exceed that > > limit. Also note that the output is already sorted because > > the shell sorts wildcard expansions. > > > > Now that we have those two files, we can use comm(1) to > > find out whether there are any hashes in filelist that are > > not in filespresent: > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > echo -n "Update files missing -- " > > ... > > fi > > > > That solution scales much better because no shell loop is > > required at all. > > This will probably be the fastest. Are you sure? I'm not. Only a benchmark can answer that. See below. > awk -F "|" ' > $2 ~ /^f/{required[$7]=$7; count++} > END{FS="[/.]"; > while("find files -name *.gz" | getline>0) > if($2 in required) > if(--count<=0) > exit(0); > exit(count)}' "$@" I think this awk solution is more difficult to read and understand, which means that it is also more prone to introduce errors. In fact, there are several problems already: First, you didn't quote the *.gz wildcard, so it will fail if there happens to be a file "*.gz" in the current directory. Second, the script makes assumptions about the format of the hash strings, e.g. that they don't contain dots. (Currently they only contain hex digits, AFAICT, but what if the format changes in the future.) Third, exit(count) is a bad idea, because exit codes are truncated to 8 bits. If 256 files happen to be missing, the script will seem to exit successfully. All these flaws could be fixed, of course, but it will introduce more complexity. The shell code using sort(1) and comm(1) doesn't have those flaws and appears more robust. > It verifies entries using hashtable instead of sort. > Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. > I am not well aware how good awk's associate array is, though. It is pretty simple. It's a hash list that starts with 50 buckets. The number of buckets is doubled (and all entries re-hashed!) when the average number of elements per bucket exceeds 2. The hash function is very simple, it's just "hash = hash * 31 + c" for every character c in the string, the result is modulo the current number of buckets. Note that freebsd-update uses SHA256 hashes which are fairly long (64 characters). BTW, you can easily make benchmarks. The following command will create 64000 files of the format "%64x.gz". Be sure to have enough free inodes on your file system ("df -i"). jot -rw "%08x" 64000 0 2000000000 | sed 's/.*/&&&&&&&&.gz/' | xargs touch This took 2 minutes on my notebook (3 years old). I also noticed that the first 47000 inodes were created very quickly (about 5 seconds), but then the speed dropped down suddenly to about 150 inodes per second for the rest of the two minutes. CPU was 100% system according to top. Removing the files is equally slow. So there seems to be a limit of about 47000 inodes per directory -- any more than that and it gets horribly inefficient. Therefore it would probably be a good idea to change freebsd-update to create subdirectories and distribute the files among them. For example, make 16 subdirectories [0-9a-f] and put the files into them according to the first digit of the hash. This will probably boost performance noticeably. Sorting those 64000 files is really *not* an issue. The difference between "ls" and "ls -f" is only 0.2 seconds on my notebook. When using "ls -f | sort", sort(1) uses only 0.12 seconds of CPU time. This is negligible. Next I made a simple test with awk within that directory: awk 'BEGIN{while("find . -name \\*.gz" | getline>0)required[$1]=$1}' That script (which does only half of the required work) takes 4 seconds, reproducible. So I didn't bother to write and test the full awk solution. Bottom line: The awk solution is less robust, less readable, and much slower. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 15:55: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 2CCC3106566B for ; Fri, 23 Jan 2009 15:55:34 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by mx1.freebsd.org (Postfix) with ESMTP id C9B838FC19 for ; Fri, 23 Jan 2009 15:55:33 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: by gxk14 with SMTP id 14so5358342gxk.19 for ; Fri, 23 Jan 2009 07:55:33 -0800 (PST) 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=jQ6IvJR2s2mqLhCFx5fxpuLkhdd+/Dg57ujR4YFJbPg=; b=XEg9WPDssKVzTz6/yTFLRR6i63myATkbtUbDzdMAqFiwql6OZKllPspO8maC29KsWH tRSc1kLlszWxuki2eMfj6eMLstxXidJJ/sVMFk4oQz9nPRTfCj1gsDaFbBLz/27dobxK ZmiHab/5Mxs3CoJfaE1QGob3/UolT4rjBiKY4= 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=GKJs2d3czMCMUBUFF3e61sBmgx7M87cPkxRviOgTSZbB4A7gmTSfVp54T3/RDHmv56 0Jpe4HRaEsC74F4E9aAWWNkWSUSQFV/zY6VUZauhb+lxTsbDxgM+mIX9hjkZFYn0vkfW Lra5n0XjCCotxrncImOHcwW5zuILy8YG0mlB8= MIME-Version: 1.0 Received: by 10.142.162.9 with SMTP id k9mr1546350wfe.159.1232726132884; Fri, 23 Jan 2009 07:55:32 -0800 (PST) Date: Fri, 23 Jan 2009 21:25:32 +0530 Message-ID: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> From: Mehul Chadha To: freebsd-hackers@freebsd.org, freebsd-ia32@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: doubts regarding System Initialization working (SYSINIT) 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, 23 Jan 2009 15:55:34 -0000 Hello all, I have been browsing through the FreeBSD kernel's source code trying to understand its working . In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects are sorted using bubble sort and then they are executed in order. My doubt is that we have declared the pointer to the struct sysinit as const pointer to a const in the macro definition of SYSINIT ie when the macro SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is expanded completely we get the following static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, (sysinit_cfunc_t)(sysinit_ nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; Here we see that the pointer is of type const and to a const but when we sort and swap using *sipp=*xipp; We are trying to change the address of const pointer to a new address in which case it should segfault but it works fine. Why does it not segfault it seems I have not understood the concept behind using const *const... I will be very thankful if you can help me with it. Regards, Mehul From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 19:34: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 260D21065676 for ; Fri, 23 Jan 2009 19:34:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id C2D698FC1E for ; Fri, 23 Jan 2009 19:34:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 29069 invoked by uid 399); 23 Jan 2009 19:34:41 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Jan 2009 19:34:41 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <497A1BEE.7070709@FreeBSD.org> Date: Fri, 23 Jan 2009 11:35:10 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Oliver Fromme References: <200901231109.n0NB933k069163@lurza.secnetix.de> In-Reply-To: <200901231109.n0NB933k069163@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yoshihiro Ota , freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 19:34:42 -0000 Oliver Fromme wrote: > Yoshihiro Ota wrote: > > Oliver Fromme wrote: > > > It would be much better to generate two lists: > > > - The list of hashes, as already done ("filelist") > > > - A list of gzipped files present, stripped to the hash: > > > > > > (cd files; echo *.gz) | > > > tr ' ' '\n' | > > > sed 's/\.gz$//' > filespresent > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > kern.argmax limit. 64000 files would certainly exceed that > > > limit. Also note that the output is already sorted because > > > the shell sorts wildcard expansions. > > > > > > Now that we have those two files, we can use comm(1) to > > > find out whether there are any hashes in filelist that are > > > not in filespresent: > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > echo -n "Update files missing -- " > > > ... > > > fi > > > > > > That solution scales much better because no shell loop is > > > required at all. > > > > This will probably be the fastest. > > Are you sure? I'm not. I'd put money on this being faster for a lot of reasons. test is a builtin in our /bin/sh, so there is no exec involved for 'test -f', but going out to disk for 64k files on an individual basis should definitely be slower than getting the file list in one shot. There's no doubt that the current routine is not efficient. The cat should be eliminated, the following is equivalent: cut -f 2,7 -d '|' $@ | (quoting the $@ won't make a difference here). I haven't seen the files we're talking about, but I can't help thinking that cut | grep | cut could be streamlined. > Only a benchmark can answer that. Agreed, when making changes like this you should always benchmark them. I did a lot of that when working on portmaster 2.0 which is why I have some familiarity with this issue. > > awk -F "|" ' > > $2 ~ /^f/{required[$7]=$7; count++} > > END{FS="[/.]"; > > while("find files -name *.gz" | getline>0) > > if($2 in required) > > if(--count<=0) > > exit(0); > > exit(count)}' "$@" > > I think this awk solution is more difficult to read and > understand, which means that it is also more prone to > introduce errors. I agree, but I have only passing familiarity with awk, so to someone who knows awk this might look like "hello world." :) Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 20:06: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 74554106564A; Fri, 23 Jan 2009 20:06:29 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id E53E18FC14; Fri, 23 Jan 2009 20:06:28 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0NK6MfS092586; Fri, 23 Jan 2009 21:06:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0NK6M1B092584; Fri, 23 Jan 2009 21:06:22 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200901232006.n0NK6M1B092584@lurza.secnetix.de> To: dougb@FreeBSD.org (Doug Barton) Date: Fri, 23 Jan 2009 21:06:22 +0100 (CET) In-Reply-To: <497A1BEE.7070709@FreeBSD.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 23 Jan 2009 21:06:25 +0100 (CET) Cc: Yoshihiro Ota , freebsd-hackers@FreeBSD.org, xistence@0x58.com, cperciva@FreeBSD.org Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 20:06:29 -0000 Doug Barton wrote: > Oliver Fromme wrote: > > Yoshihiro Ota wrote: > > > Oliver Fromme wrote: > > > > It would be much better to generate two lists: > > > > - The list of hashes, as already done ("filelist") > > > > - A list of gzipped files present, stripped to the hash: > > > > > > > > (cd files; echo *.gz) | > > > > tr ' ' '\n' | > > > > sed 's/\.gz$//' > filespresent > > > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > > kern.argmax limit. 64000 files would certainly exceed that > > > > limit. Also note that the output is already sorted because > > > > the shell sorts wildcard expansions. > > > > > > > > Now that we have those two files, we can use comm(1) to > > > > find out whether there are any hashes in filelist that are > > > > not in filespresent: > > > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > > echo -n "Update files missing -- " > > > > ... > > > > fi > > > > > > > > That solution scales much better because no shell loop is > > > > required at all. > > > > > > This will probably be the fastest. > > > > Are you sure? I'm not. > > I'd put money on this being faster for a lot of reasons. I assume, with "this" you mean my solution to the slow shell loop problem (not quoted above), not Yoshihiro Ota's awk proposal? > test is a > builtin in our /bin/sh, so there is no exec involved for 'test -f', > but going out to disk for 64k files on an individual basis should > definitely be slower than getting the file list in one shot. Correct. > There's no doubt that the current routine is not efficient. The cat > should be eliminated, the following is equivalent: > > cut -f 2,7 -d '|' $@ | > > (quoting the $@ won't make a difference here). Right, technically it doesn't make a difference because the file names are fixed and don't contain spaces. *But* then it is better to use $*. Every time I see $@ without double quotes I wonder if the author forgot to add them. It always smells like a bug. Using $@ without quotes is pointless because then it behaves exactly the same as $*. > I haven't seen the files we're talking about, but I can't help > thinking that cut | grep | cut could be streamlined. Yes, it can. I already explained pretty much all of that (useless cat etc.) in my first post in this thread. Did you read it? My suggestion (after a small correction by Christoph Mallon) was to replace the cat|cut|grep|cut sequence with this single awk command: awk -F "|" '$2 ~ /^f/ {print $7}' "$@" For those not fluent with awk, it means this: - Treat "|" as field separator. - Search for lines where the second field matches ^f (i.e. it starts with an "f"). - Print the 7th field of those matching lines. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd In my experience the term "transparent proxy" is an oxymoron (like jumbo shrimp). "Transparent" proxies seem to vary from the distortions of a funhouse mirror to barely translucent. I really, really dislike them when trying to figure out the corrective lenses needed with each of them. -- R. Kevin Oberman, Network Engineer From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 20:36: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 A34A7106564A for ; Fri, 23 Jan 2009 20:36:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 3979F8FC13 for ; Fri, 23 Jan 2009 20:36:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19844 invoked by uid 399); 23 Jan 2009 20:36:54 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Jan 2009 20:36:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <497A2A83.9010606@FreeBSD.org> Date: Fri, 23 Jan 2009 12:37:23 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Oliver Fromme References: <200901232006.n0NK6M1B092584@lurza.secnetix.de> In-Reply-To: <200901232006.n0NK6M1B092584@lurza.secnetix.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yoshihiro Ota , freebsd-hackers@FreeBSD.org, xistence@0x58.com, cperciva@FreeBSD.org Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 20:36:56 -0000 Oliver Fromme wrote: > I assume, with "this" you mean my solution to the slow > shell loop problem (not quoted above), not Yoshihiro Ota's > awk proposal? I meant the solution using comm, sorry. (I forgot to mention that I would probably use cmp here, but that's a personal preference.) > Yes, it can. I already explained pretty much all of that > (useless cat etc.) in my first post in this thread. Did > you read it? Yes, I was attempting to agree with you. :) > My suggestion (after a small correction by > Christoph Mallon) was to replace the cat|cut|grep|cut > sequence with this single awk command: > > awk -F "|" '$2 ~ /^f/ {print $7}' "$@" > > For those not fluent with awk, it means this: > - Treat "|" as field separator. > - Search for lines where the second field matches ^f > (i.e. it starts with an "f"). > - Print the 7th field of those matching lines. Like I said, I haven't seen the files, but this looks good at first blush. That said, the generation of the hash list file is just a drop in the bucket. The real inefficiency in this function is the test -f for 64k files, one at a time. Doug -- This .signature sanitized for your protection From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 22: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 123551065677; Fri, 23 Jan 2009 22:22:15 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8636F8FC17; Fri, 23 Jan 2009 22:22:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n0NMMAkT097665; Fri, 23 Jan 2009 23:22:11 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n0NMMAcS097663; Fri, 23 Jan 2009 23:22:10 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <200901232222.n0NMMAcS097663@lurza.secnetix.de> To: dougb@freebsd.org (Doug Barton) Date: Fri, 23 Jan 2009 23:22:10 +0100 (CET) In-Reply-To: <497A2A83.9010606@FreeBSD.org> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 23 Jan 2009 23:22:11 +0100 (CET) Cc: Yoshihiro Ota , freebsd-hackers@freebsd.org, xistence@0x58.com, cperciva@freebsd.org Subject: Re: freebsd-update's install_verify routine excessive stating 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, 23 Jan 2009 22:22:15 -0000 Doug Barton wrote: > Oliver Fromme wrote: > > I assume, with "this" you mean my solution to the slow > > shell loop problem (not quoted above), not Yoshihiro Ota's > > awk proposal? > > I meant the solution using comm, sorry. (I forgot to mention that I > would probably use cmp here, but that's a personal preference.) I see. No problem. However, I think cmp wouldn't work here, because cmp only detects whether there is a difference between two files. In this case we need to know if one file is a subset of the other: For every hash there must be a .gz file, but it doesn't hurt if there are more files. So the list of hashes can be a subset of the list of .gz files, they don't have to be equal. While I were at it, I skimmed through the cmp source and found a bug (or inefficiency): When the -s option is specified (i.e. silent, exit code only), it would be sufficient to terminate when the first difference is encountered. But it always compares the whole files. I'll try to make a patch to improve this. > > Yes, it can. I already explained pretty much all of that > > (useless cat etc.) in my first post in this thread. Did > > you read it? > > Yes, I was attempting to agree with you. :) OK, sorry. I misunderstood. :) > > My suggestion (after a small correction by > > Christoph Mallon) was to replace the cat|cut|grep|cut > > sequence with this single awk command: > > > > awk -F "|" '$2 ~ /^f/ {print $7}' "$@" > > > > For those not fluent with awk, it means this: > > - Treat "|" as field separator. > > - Search for lines where the second field matches ^f > > (i.e. it starts with an "f"). > > - Print the 7th field of those matching lines. > > Like I said, I haven't seen the files, but this looks good at first > blush. That said, the generation of the hash list file is just a drop > in the bucket. The real inefficiency in this function is the test -f > for 64k files, one at a time. Yes, definitely. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 22:57:56 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 C7606106564A; Fri, 23 Jan 2009 22:57:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 994088FC17; Fri, 23 Jan 2009 22:57:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 146CA46B09; Fri, 23 Jan 2009 17:57:56 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n0NMvoNw054798; Fri, 23 Jan 2009 17:57:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Fri, 23 Jan 2009 17:55:15 -0500 User-Agent: KMail/1.9.7 References: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> In-Reply-To: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901231755.15548.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 23 Jan 2009 17:57:50 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/8897/Fri Jan 23 07:59:36 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Mehul Chadha , freebsd-ia32@freebsd.org Subject: Re: doubts regarding System Initialization working (SYSINIT) 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, 23 Jan 2009 22:57:57 -0000 On Friday 23 January 2009 10:55:32 am Mehul Chadha wrote: > Hello all, > I have been browsing through the FreeBSD kernel's > source code trying to understand its working . > > In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects > are sorted using bubble sort and then they are executed in order. > > My doubt is that we have declared the pointer to the struct sysinit as > const pointer to a const in the macro definition of SYSINIT ie when > the macro > > SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is > expanded completely we get the following > > static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, > (sysinit_cfunc_t)(sysinit_ > nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const > __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" > "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; > > Here we see that the pointer is of type const and to a const but when we sort > and swap using > *sipp=*xipp; > > We are trying to change the address of const pointer to a new address > in which case it should segfault but it works fine. > > Why does it not segfault it seems I have not understood the concept > behind using const *const... I will be very thankful if you can help > me with it. I'm guessing the startup code doesn't map the SYSINIT pages read only because it is not smart enough to honor that request perhaps. That is, I wouldn't be surprised if all of .rodata in the kernel was mapped as R/W instead of R/O. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 23 23:21:49 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 8846C1065782 for ; Fri, 23 Jan 2009 23:21:49 +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 5A3F28FC0C for ; Fri, 23 Jan 2009 23:21:49 +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 n0NNLmhg094684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 15:21:48 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <497A510C.3030106@freebsd.org> Date: Fri, 23 Jan 2009 15:21:48 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: John Baldwin References: <251d650c0901230755n769de861u1fe2e76dd28bbde8@mail.gmail.com> <200901231755.15548.jhb@freebsd.org> In-Reply-To: <200901231755.15548.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-hackers@freebsd.org, Mehul Chadha Subject: Re: doubts regarding System Initialization working (SYSINIT) 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, 23 Jan 2009 23:21:49 -0000 John Baldwin wrote: > On Friday 23 January 2009 10:55:32 am Mehul Chadha wrote: > >> Hello all, >> I have been browsing through the FreeBSD kernel's >> source code trying to understand its working . >> >> In the mi_startup() in /sys/kern/init_main.c all the SYSINIT objects >> are sorted using bubble sort and then they are executed in order. >> >> My doubt is that we have declared the pointer to the struct sysinit as >> const pointer to a const in the macro definition of SYSINIT ie when >> the macro >> >> SYSINIT(kmem, SI_SUB_KMEM, SI_ORDER_FIRST, kmeminit, NULL) is >> expanded completely we get the following >> >> static struct sysinit kmem_sys_init = { SI_SUB_KMEM, SI_ORDER_FIRST, >> (sysinit_cfunc_t)(sysinit_ >> nfunc_t)kmeminit, ((void *)(((void *)0))) }; static void const * const >> __set_sysinit_set_sym_kmem_sys_init __attribute__((__section__("set_" >> "sysinit_set"))) __attribute__((__used__)) = &kmem_sys_init; >> >> Here we see that the pointer is of type const and to a const but when we >> > sort > >> and swap using >> *sipp=*xipp; >> >> We are trying to change the address of const pointer to a new address >> in which case it should segfault but it works fine. >> >> Why does it not segfault it seems I have not understood the concept >> behind using const *const... I will be very thankful if you can help >> me with it. >> > > I'm guessing the startup code doesn't map the SYSINIT pages read only because > it is not smart enough to honor that request perhaps. That is, I wouldn't be > surprised if all of .rodata in the kernel was mapped as R/W instead of R/O. > > I think I have an ancient patch from someone to fix the code to not do this; let me dig for it. Sam From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 03:09:38 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 CFBDF106564A; Sat, 24 Jan 2009 03:09:38 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 43F5E8FC27; Sat, 24 Jan 2009 03:09:38 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-221-3.phil.east.verizon.net [70.20.221.3]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 551165ED7C; Sat, 24 Jan 2009 12:09:34 +0900 (JST) Date: Fri, 23 Jan 2009 22:08:40 -0500 From: Yoshihiro Ota To: Oliver Fromme Message-Id: <20090123220840.2e1b25bc.ota@j.email.ne.jp> In-Reply-To: <200901231109.n0NB933k069163@lurza.secnetix.de> References: <20090122203819.585fb35f.ota@j.email.ne.jp> <200901231109.n0NB933k069163@lurza.secnetix.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@FreeBSD.ORG, xistence@0x58.com, cperciva@FreeBSD.ORG Subject: Re: freebsd-update's install_verify routine excessive stating 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, 24 Jan 2009 03:09:39 -0000 Oliver, You are making a good point but connecting two different subjects. The algorithm with awk is still the fastest in theory. It uses a hash table which runs at O(c) for each comparison ASSUMING you have a good hash function that yields such result. The total number of comparison is O(n) or O(C1 * n) where C1 is some constant number based on the hash function performance. On the other hand, comparison sorts are in O(n * log(n)) comparison. The 2nd comparison of two files are at O(n). So, total comparison is still O(n * log(n)) or O(C2 * n * log(n)) where C2 is some constant based on the algorithm and implementation. That is in theory. In reality or practice, it may not be true because you could have poor C1 such that the comparison solution becomes better or because n is small enough so that it doesn't matter which solution to take. In fact, awk implementation was poor and resulted large C1 as well as slower than sort(1). Experiment is yet important so that you can determine the best algorithm in your TEST environment. This is where you are making a point. If you have control over these conditions, you can not to choose the theoretically best algorithm. I agree and had indeed expected your outcome as awk is actually known to inefficiency in its implementations. In that regard, in the practical point of view, the original implementation by cperciva@ was good enough such that searching for faster algorithms was not necessary for all people except Bert. At the end, it is up to the implementer to pick up the solution. Regards, Hiro On Fri, 23 Jan 2009 12:09:03 +0100 (CET) Oliver Fromme wrote: > > Yoshihiro Ota wrote: > > Oliver Fromme wrote: > > > It would be much better to generate two lists: > > > - The list of hashes, as already done ("filelist") > > > - A list of gzipped files present, stripped to the hash: > > > > > > (cd files; echo *.gz) | > > > tr ' ' '\n' | > > > sed 's/\.gz$//' > filespresent > > > > > > Note we use "echo" instead of "ls", in order to avoid the > > > kern.argmax limit. 64000 files would certainly exceed that > > > limit. Also note that the output is already sorted because > > > the shell sorts wildcard expansions. > > > > > > Now that we have those two files, we can use comm(1) to > > > find out whether there are any hashes in filelist that are > > > not in filespresent: > > > > > > if [ -n "$(comm -23 filelist filespresent)" ]; then > > > echo -n "Update files missing -- " > > > ... > > > fi > > > > > > That solution scales much better because no shell loop is > > > required at all. > > > > This will probably be the fastest. > > Are you sure? I'm not. > Only a benchmark can answer that. See below. > > > awk -F "|" ' > > $2 ~ /^f/{required[$7]=$7; count++} > > END{FS="[/.]"; > > while("find files -name *.gz" | getline>0) > > if($2 in required) > > if(--count<=0) > > exit(0); > > exit(count)}' "$@" > > I think this awk solution is more difficult to read and > understand, which means that it is also more prone to > introduce errors. In fact, there are several problems > already: > > First, you didn't quote the *.gz wildcard, so it will > fail if there happens to be a file "*.gz" in the current > directory. > > Second, the script makes assumptions about the format of > the hash strings, e.g. that they don't contain dots. > (Currently they only contain hex digits, AFAICT, but what > if the format changes in the future.) > > Third, exit(count) is a bad idea, because exit codes are > truncated to 8 bits. If 256 files happen to be missing, > the script will seem to exit successfully. > > All these flaws could be fixed, of course, but it will > introduce more complexity. The shell code using sort(1) > and comm(1) doesn't have those flaws and appears more > robust. > > > It verifies entries using hashtable instead of sort. > > Therefore, it is O(n+m) instead of O(n*log(n))+O(m*log(m)) in theory. > > I am not well aware how good awk's associate array is, though. > > It is pretty simple. It's a hash list that starts with > 50 buckets. The number of buckets is doubled (and all > entries re-hashed!) when the average number of elements > per bucket exceeds 2. The hash function is very simple, > it's just "hash = hash * 31 + c" for every character c > in the string, the result is modulo the current number > of buckets. Note that freebsd-update uses SHA256 hashes > which are fairly long (64 characters). > > BTW, you can easily make benchmarks. The following command > will create 64000 files of the format "%64x.gz". Be sure > to have enough free inodes on your file system ("df -i"). > > jot -rw "%08x" 64000 0 2000000000 | sed 's/.*/&&&&&&&&.gz/' | xargs touch > > This took 2 minutes on my notebook (3 years old). I also > noticed that the first 47000 inodes were created very > quickly (about 5 seconds), but then the speed dropped down > suddenly to about 150 inodes per second for the rest of > the two minutes. CPU was 100% system according to top. > Removing the files is equally slow. > > So there seems to be a limit of about 47000 inodes per > directory -- any more than that and it gets horribly > inefficient. Therefore it would probably be a good idea > to change freebsd-update to create subdirectories and > distribute the files among them. For example, make 16 > subdirectories [0-9a-f] and put the files into them > according to the first digit of the hash. This will > probably boost performance noticeably. > > Sorting those 64000 files is really *not* an issue. The > difference between "ls" and "ls -f" is only 0.2 seconds on > my notebook. When using "ls -f | sort", sort(1) uses only > 0.12 seconds of CPU time. This is negligible. > > Next I made a simple test with awk within that directory: > > awk 'BEGIN{while("find . -name \\*.gz" | getline>0)required[$1]=$1}' > > That script (which does only half of the required work) > takes 4 seconds, reproducible. So I didn't bother to > write and test the full awk solution. > > Bottom line: The awk solution is less robust, less readable, > and much slower. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- > chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "The most important decision in [programming] language design > concerns what is to be left out." -- Niklaus Wirth From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 24 22:33: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 2177E1065672 for ; Sat, 24 Jan 2009 22:33:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id 8A5BB8FC14 for ; Sat, 24 Jan 2009 22:33:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19944 invoked by uid 399); 24 Jan 2009 22:33:13 -0000 Received: from localhost (HELO ?192.168.0.19?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2009 22:33:13 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <497B9743.6080109@FreeBSD.org> Date: Sat, 24 Jan 2009 14:33:39 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Oliver Fromme References: <200901232222.n0NMMAcS097663@lurza.secnetix.de> In-Reply-To: <200901232222.n0NMMAcS097663@lurza.secnetix.de> 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: freebsd-update's install_verify routine excessive stating 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, 24 Jan 2009 22:33:15 -0000 Oliver Fromme wrote: > Doug Barton wrote: > > Oliver Fromme wrote: > > > I assume, with "this" you mean my solution to the slow > > > shell loop problem (not quoted above), not Yoshihiro Ota's > > > awk proposal? > > > > I meant the solution using comm, sorry. (I forgot to mention that I > > would probably use cmp here, but that's a personal preference.) > > I see. No problem. > > However, I think cmp wouldn't work here, because cmp only > detects whether there is a difference between two files. > > In this case we need to know if one file is a subset of > the other: For every hash there must be a .gz file, but > it doesn't hurt if there are more files. So the list of > hashes can be a subset of the list of .gz files, they > don't have to be equal. Hrrmmm, that doesn't sound like a good thing to me. I would think that the hash list is pretty useless if it doesn't cover all the files. > While I were at it, I skimmed through the cmp source and > found a bug (or inefficiency): When the -s option is > specified (i.e. silent, exit code only), it would be > sufficient to terminate when the first difference is > encountered. But it always compares the whole files. > I'll try to make a patch to improve this. That would definitely be appreciated, I use cmp -s in several places in portmaster where that speed-up would make a non-trivial difference. If there is anything I can do to help please let me know. Doug -- This .signature sanitized for your protection