From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 01:13:37 2012 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 1D117106564A; Sun, 15 Apr 2012 01:13:37 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id D455F8FC08; Sun, 15 Apr 2012 01:13:36 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q3F11L4K005374; Sat, 14 Apr 2012 20:01:21 -0500 (CDT) Date: Sat, 14 Apr 2012 20:01:20 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Andriy Gapon In-Reply-To: <4F89B567.6090008@FreeBSD.org> Message-ID: References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sat, 14 Apr 2012 20:01:21 -0500 (CDT) X-Mailman-Approved-At: Sun, 15 Apr 2012 01:34:52 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 15 Apr 2012 01:13:37 -0000 It would be nice if the updated FreeBSD bootloader could have the ability to boot both Solaris and FreeBSD root filesystems in the same pool so that one could switch between several zfs-based operating systems without needing to use a different partition for each one. Is this within the bounds of possibility or a totally irrational thought? Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 02:30:45 2012 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 DFECC106566C; Sun, 15 Apr 2012 02:30:45 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 844C38FC12; Sun, 15 Apr 2012 02:30:45 +0000 (UTC) Received: by obqv19 with SMTP id v19so4687044obq.13 for ; Sat, 14 Apr 2012 19:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Iy+G+ukDFLj2TWtAHDVFNQCw3/WAA7ILCbHzudkXajM=; b=uC9+iNah8xhUuBO+Kex6SLx7YOGnKiTntAF+kHYnuC5WXc8XdB1uu2Y7BORGebukXY VyE5rdeV8nVDsDKrDGSUyOwjIEPvNWzojhsoG9PU3SYpAFuxQV1jh1I9EyXYMaqwd6TG ldmgFs4TAD53ROBsaTP+zgv6+vX0EuNpIammdT6NkLdOLnM8D8iV616Mhe1QCbKCzoh4 YTSPk3+N2g2Qy/ORDI/2UVnJu4wbztvWVodOAk2AKSp+F3hfgIYm7t1EZ9vPG6rLCx+Z HlJc1mb0PYs+/EJZ8/l7uAnPfSm2GgCaXcZH5RzyTUUiLo40Mmho09SLlYUsaC/WxU0Q a11A== Received: by 10.60.28.137 with SMTP id b9mr9422981oeh.57.1334457044996; Sat, 14 Apr 2012 19:30:44 -0700 (PDT) Received: from [192.168.2.5] (dpc691939029.direcpc.com. [69.19.39.29]) by mx.google.com with ESMTPS id w4sm12227222oeg.12.2012.04.14.19.30.33 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Apr 2012 19:30:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sat, 14 Apr 2012 19:30:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> To: Bob Friesenhahn X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Sun, 15 Apr 2012 02:59:21 +0000 Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 15 Apr 2012 02:30:46 -0000 On Apr 14, 2012, at 6:01 PM, Bob Friesenhahn wrote: > It would be nice if the updated FreeBSD bootloader could have the = ability to boot both Solaris and FreeBSD root filesystems in the same = pool so that one could switch between several zfs-based operating = systems without needing to use a different partition for each one. Is = this within the bounds of possibility or a totally irrational thought? This sort of depends on whether or not the device is hardcoded = in the zpool, right? Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 08:54:56 2012 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 52DC3106564A; Sun, 15 Apr 2012 08:54:56 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4A38FC0A; Sun, 15 Apr 2012 08:54:56 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3F8si74026461; Sun, 15 Apr 2012 01:54:47 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F8A8CD2.5020103@rawbw.com> Date: Sun, 15 Apr 2012 01:54:42 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <4F775DF5.1020704@rawbw.com> <4F7CA124.8080401@freebsd.org> <201204051006.11598.jhb@freebsd.org> In-Reply-To: <201204051006.11598.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Is there any modern alternative to pstack? 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, 15 Apr 2012 08:54:56 -0000 On 04/05/2012 07:06, John Baldwin wrote: > In this case we probably should become the upstream maintainer. My patch > actually bumps the version to 1.3 as it is sort of intended to do that. bsd-pstack on SourceForge is dead. Sole project owner isn't responsive, and as per SF policy they don't allow anyone to take over such project. They suggest to fork. So will you object if I create a new project on SF, say bsd-pstack-new, will import the current source and apply your patch and make a release? I will also update pstack port so that it will become current. Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 09:30:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D31431065670; Sun, 15 Apr 2012 09:30:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2128FC19; Sun, 15 Apr 2012 09:30:49 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3F9UTqC055311; Sun, 15 Apr 2012 12:30:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3F9UTpe002607; Sun, 15 Apr 2012 12:30:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3F9UTEf002606; Sun, 15 Apr 2012 12:30:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 15 Apr 2012 12:30:29 +0300 From: Konstantin Belousov To: Yuri Message-ID: <20120415093029.GR2358@deviant.kiev.zoral.com.ua> References: <4F775DF5.1020704@rawbw.com> <4F7CA124.8080401@freebsd.org> <201204051006.11598.jhb@freebsd.org> <4F8A8CD2.5020103@rawbw.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="38uh/aik6W4+24mM" Content-Disposition: inline In-Reply-To: <4F8A8CD2.5020103@rawbw.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: freebsd-hackers@freebsd.org Subject: Re: Is there any modern alternative to pstack? 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, 15 Apr 2012 09:30:50 -0000 --38uh/aik6W4+24mM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2012 at 01:54:42AM -0700, Yuri wrote: > On 04/05/2012 07:06, John Baldwin wrote: > >In this case we probably should become the upstream maintainer. My patch > >actually bumps the version to 1.3 as it is sort of intended to do that. >=20 > bsd-pstack on SourceForge is dead. Sole project owner isn't responsive,= =20 > and as per SF policy they don't allow anyone to take over such project.= =20 > They suggest to fork. > So will you object if I create a new project on SF, say bsd-pstack-new,= =20 > will import the current source and apply your patch and make a release? > I will also update pstack port so that it will become current. It seems that the license is two-clause BSD. My opinion is that such tool should be imported into the base. --38uh/aik6W4+24mM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+KlTUACgkQC3+MBN1Mb4gzsQCeJZ4/mFW9Ahcsez0xXslnNYtD GhsAn2sa6oQ5/BENMEvmQFOiW9nwUoZK =f/zU -----END PGP SIGNATURE----- --38uh/aik6W4+24mM-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 19:00:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8C7D106566B for ; Sun, 15 Apr 2012 19:00:11 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 6B71F8FC14 for ; Sun, 15 Apr 2012 19:00:11 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3FJ09LB018216; Sun, 15 Apr 2012 12:00:10 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F8B1AB8.4030402@rawbw.com> Date: Sun, 15 Apr 2012 12:00:08 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: Konstantin Belousov References: <4F775DF5.1020704@rawbw.com> <4F7CA124.8080401@freebsd.org> <201204051006.11598.jhb@freebsd.org> <4F8A8CD2.5020103@rawbw.com> <20120415093029.GR2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120415093029.GR2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Is there any modern alternative to pstack? 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, 15 Apr 2012 19:00:11 -0000 On 04/15/2012 02:30, Konstantin Belousov wrote: > It seems that the license is two-clause BSD. > My opinion is that such tool should be imported into the base. I agree, this is the best option. This is a very low level tool, somewhat similar to or extending procstat(1). Yuri From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 21:31:10 2012 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 897F1106566B for ; Sun, 15 Apr 2012 21:31:10 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 364248FC12 for ; Sun, 15 Apr 2012 21:31:10 +0000 (UTC) Received: by iahk25 with SMTP id k25so8591626iah.13 for ; Sun, 15 Apr 2012 14:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=anjQAUCJ7LTf74ya7arVTpWb07ljbGfM66HMaFIFuJI=; b=bOdif8g3n+xC4tGojrOj/nIzUTF1a8nEfsPbp/0wp5igCIeDY7qK+DFfdKXeveAqPl MKxWW7rKbk9G4IjeLuNU78o8hUGK1dhZvW9SsAt38ZvljcrxZn4UMPOkAiY2GyWvTl/R 67aOLyJYc5ZqRtFzLVRStqaLECkRgboQLE5yw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=anjQAUCJ7LTf74ya7arVTpWb07ljbGfM66HMaFIFuJI=; b=Yy7ZHran3i0lNBYPBlghKticf2SevqXnxw/r1z/WePzbZML0I1MPdxv9G8ff15MRpo vLsVh6UD1CoO9aPbHkzHeKBxkgsLdWzIp8k50gThd39Uuzyn3UqtwPKCuMtQCVJKIWgD rlBjv0KqTWTzBdY4HksZeltBYdrpUs3/YbQpgiwb+RoBIZrSZHj+M13xUfNrK93YcmAZ uE3gUsVSD0C26D9NnRWZccJRGFBUqIvGDkxZfFgyfxVN4xDGSLdNU0Igqt6s2M8hrCdL S82xvaFMEEPav1PB9puqebACbTXJMq3/GwYJlEDGwZXWEMPj5h8VIMos94iZQ1+FdXT/ zgbw== Received: by 10.50.216.136 with SMTP id oq8mr3790356igc.63.1334525469596; Sun, 15 Apr 2012 14:31:09 -0700 (PDT) Received: from DataIX.net (adsl-99-181-156-81.dsl.klmzmi.sbcglobal.net. [99.181.156.81]) by mx.google.com with ESMTPS id i7sm7794098igq.11.2012.04.15.14.31.08 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Apr 2012 14:31:09 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3FLV790054826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Apr 2012 17:31:07 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3FLV5g0054825; Sun, 15 Apr 2012 17:31:05 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sun, 15 Apr 2012 17:31:05 -0400 From: Jason Hellenthal To: Yuri Message-ID: <20120415213105.GA54254@DataIX.net> References: <4F775DF5.1020704@rawbw.com> <4F7CA124.8080401@freebsd.org> <201204051006.11598.jhb@freebsd.org> <4F8A8CD2.5020103@rawbw.com> <20120415093029.GR2358@deviant.kiev.zoral.com.ua> <4F8B1AB8.4030402@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <4F8B1AB8.4030402@rawbw.com> X-Gm-Message-State: ALoCoQknvVnCpsUiifxLbRBBQqze00t/cxJHv5OzxqZQBsMw/Ag9josADR2swVSrNAH8BChgdZbc Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: Is there any modern alternative to pstack? ++sysutils/timelimit 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, 15 Apr 2012 21:31:10 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2012 at 12:00:08PM -0700, Yuri wrote: > On 04/15/2012 02:30, Konstantin Belousov wrote: > > It seems that the license is two-clause BSD. > > My opinion is that such tool should be imported into the base. >=20 > I agree, this is the best option. This is a very low level tool,=20 > somewhat similar to or extending procstat(1). >=20 Every once in a while when this comes up it makes me think of this. sysutils/timelimit BSD licensed and the maintainer is more than willing to maintain it. And gets rid of the problem with colliding with timelimit from netpipes-4.2 which happens to be a pain to use. --=20 ;s =3D; --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPiz4YAAoJEBSh2Dr1DU7WxxEH/jQlkPJwU9R9/SesKgogvKBu ooA+RdNfipobzQmTc3a4g7sgSvbNyzn8BTUeTC86LrMlDtFvfYaM/bW3b/Tu9FFq thdpRbcGzy/8wcFrH5LxoWmCj1mzx4AZVBBwPRDTrM/GaOct3pJqpgvFCO+W4RA/ Cki2508SaO895NwPI4N3huzySlmqK+bkmfS8GKY3NPzsfB+Vz5ciGQFhFVg448La 15ek6kaTynAVd7g91Knftnc8WR2mRxI4CDJZ2NInsujll6TDOEfwcKWSwE/gw8Gy iA4OYyvZU96VGWVnzyS7RMVksxSdA/0FeFQmApD6kwQBdoU6zfybSg/LlETpoAY= =SUsT -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 21:28:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 669A31065672 for ; Sun, 15 Apr 2012 21:28:05 +0000 (UTC) (envelope-from maheshbabu90@yahoo.co.in) Received: from nm29-vm4.bullet.mail.sg3.yahoo.com (nm29-vm4.bullet.mail.sg3.yahoo.com [106.10.151.163]) by mx1.freebsd.org (Postfix) with SMTP id A5B778FC23 for ; Sun, 15 Apr 2012 21:28:04 +0000 (UTC) Received: from [106.10.166.112] by nm29.bullet.mail.sg3.yahoo.com with NNFMP; 15 Apr 2012 21:27:57 -0000 Received: from [106.10.150.25] by tm1.bullet.mail.sg3.yahoo.com with NNFMP; 15 Apr 2012 21:27:57 -0000 Received: from [127.0.0.1] by omp1026.mail.sg3.yahoo.com with NNFMP; 15 Apr 2012 21:27:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 894480.44358.bm@omp1026.mail.sg3.yahoo.com Received: (qmail 28014 invoked by uid 60001); 15 Apr 2012 21:27:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1334525277; bh=9B9W27qD42u8apV/2/rmfc77ZHYuIqfBo8ALTsvFNP0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=u9zHrcRFEARItxZ6A40Q/svi0N2FWxyUCUFYw+Mr9jJ9lYm+T+cdQ4YQDy8yr0zctP04kcoGnMowtbLl7ztEWDSGcSlyXeFqIQw2NsSDkL4pw/Eoful7wcalNWltbl4vvpjRiz2+njKzD5cQvCp/Dw0LrxDXwZaUF6TMA4UxwRs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wY3201GDxjuduoD2UwUJPv1TjtqUmrMb06iWY+FgTJgdbS1Ocs+cFvPuB1FnybyBz9mhqt1AUK6dGVwO9GCA1cH+Lblbc2HyIlwEII9UU/UBl0zs34av2J8gtVo1vFssWNd/LivJLdrj3ihDG6XkFaPeWmP/MqLN3MVUiccSrzI=; X-YMail-OSG: mB1TLTQVM1lffcazpLSYZhF42cyqi9USCOvdm2WUa3duSQm DfY6w2rTiHk_d8GlaarGi7rkILvmk7pVJKFmIrzcL5biaIXRr986MLgjwMaw Zoc8qXW.Gn9tHJzvoVrlr6YuHKTBiFdDPKT7uJ_Y99.auhautIPk7XdF2PA2 AHNYeexxjG61z9lNO4FFHQYWoh3vG8Pbhc1A.OF1jxT6KYBfzml1ztb0N7hZ ikn64hHo8Pf3SLixJrA7qxUjtgLEuEpPE0RHnKmYV3qayiVTm7z6g09fEouR LfcnwZXzFTcRTVdAADWkTVKOoP2hGY.Bq6HEgcbNXhQSerkDSGIu8e_K9uoa 0t2qgrROkGpnArzyzywyJ3i1iBUrKapHlJEWkVIO1.ZsWkQy7C2mF2MPLaTD eRzkxz6Y- Received: from [14.139.155.21] by web193204.mail.sg3.yahoo.com via HTTP; Mon, 16 Apr 2012 05:27:57 SGT X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1334525277.20956.YahooMailNeo@web193204.mail.sg3.yahoo.com> Date: Mon, 16 Apr 2012 05:27:57 +0800 (SGT) From: Mahesh Babu To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 15 Apr 2012 21:42:51 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Regarding cores in FreeBSD 9 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mahesh Babu List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 21:28:05 -0000 1. How to find in which core the given process is running?=0A2. How to forc= e a process to run in a particular core? for example: I need to run process= ID 1200 in core 2.=A0 =0A From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 15 21:48:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DBD31065672 for ; Sun, 15 Apr 2012 21:48:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA028FC14 for ; Sun, 15 Apr 2012 21:48:37 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0M2J00D04J8VKJ00@smtpauth1.wiscmail.wisc.edu> for freebsd-hackers@freebsd.org; Sun, 15 Apr 2012 16:48:31 -0500 (CDT) Received: from wanderer.tachypleus.net ([unknown] [76.210.67.9]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0M2J00AKVJ8UWM00@smtpauth1.wiscmail.wisc.edu>; Sun, 15 Apr 2012 16:48:31 -0500 (CDT) Date: Sun, 15 Apr 2012 16:48:30 -0500 From: Nathan Whitehorn In-reply-to: <1334525277.20956.YahooMailNeo@web193204.mail.sg3.yahoo.com> To: Mahesh Babu Message-id: <4F8B422E.4050504@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.67.9 X-Spam-PmxInfo: Server=avs-16, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.15.213916, SenderIP=76.210.67.9 References: <1334525277.20956.YahooMailNeo@web193204.mail.sg3.yahoo.com> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120327 Thunderbird/10.0.3 Cc: "freebsd-hackers@freebsd.org" Subject: Re: Regarding cores in FreeBSD 9 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, 15 Apr 2012 21:48:37 -0000 On 04/15/12 16:27, Mahesh Babu wrote: > 1. How to find in which core the given process is running? You can see it in top. > 2. How to force a process to run in a particular core? for example: I need to run process ID 1200 in core 2. Use cpuset. You can either run it in the first place on core 2 with cpuset -l 2 or switch an existing process cpuset -l 2 -p 1200. -Nathan From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 06:48:48 2012 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 DB05C106566B for ; Mon, 16 Apr 2012 06:48:48 +0000 (UTC) (envelope-from willingbug@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3DAE8FC08 for ; Mon, 16 Apr 2012 06:48:48 +0000 (UTC) Received: by obqv19 with SMTP id v19so5975046obq.13 for ; Sun, 15 Apr 2012 23:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IFtOeXXrBZi9fYyeOH93xeDwPbLllmo1+jkSFoCSwAI=; b=x7+7teuJWIFdata5QUQVrasbgmqT9jFvyhrFFzKs0WEUoGhoMLJ6HLcecnCJ5kgtax KYp01+Gjm4DF4LZoxSfxcolPoTN6l9NdG+eJYR2qdiQ4yuk+YTlWi2VLmpW30C0pxYAf s4g/eSaxQ5WyO02t0zIdQcy9TrCo9bvKrk1D2AHz2ZrEeh74YNAxV5hADgBiIla7Q6zJ 1ylWfwf0661UkIjmTF808EsUX5Gsdx3Dbh2vguz7Y5iU6RGxc2247TBcCozj/WDJV0O1 bO792rML3WLDNWcDuVFehm4QcVoCwSG0ahY6iwkHpGDWc3SARbVPPKCch3xXs64ttc7R zIgQ== MIME-Version: 1.0 Received: by 10.182.110.102 with SMTP id hz6mr14140745obb.58.1334558928279; Sun, 15 Apr 2012 23:48:48 -0700 (PDT) Received: by 10.182.78.71 with HTTP; Sun, 15 Apr 2012 23:48:48 -0700 (PDT) Date: Mon, 16 Apr 2012 14:48:48 +0800 Message-ID: From: cz li To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: The user-mode stack space is how many bytes? 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, 16 Apr 2012 06:48:48 -0000 The user-mode stack space is how many bytes, the kernel stack is how many bytes. I've written a driver.I want to add it to the kernel source. How should I do? Thank you. lichaozhong 2012-4-16 From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 09:01:32 2012 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 AE7B1106566B for ; Mon, 16 Apr 2012 09:01:32 +0000 (UTC) (envelope-from fuzhli1007@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3FD8FC0A for ; Mon, 16 Apr 2012 09:01:32 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so6398254pbc.13 for ; Mon, 16 Apr 2012 02:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4jdBjjCSqfsEKTV9x2vlRuaup8ilBLrTV0dQh99/xVI=; b=zQvUHooqh7X1Ac0ybi4R/hchAxB0jMOlxai0fMeEBolq2c33nT4BpY9ILRxTCDiaP+ UoniLQO31Ukvc6EhJAUTeStnBiSf/ukoZ93f+ixt9jNWbZl9KC3araA3N23eQ1/j4YwM B4JUoux14y1EpuPtTF+t3CG2lpLQ2LbWNAFmZUPhbcfr+U9Ao8vTSkFQSqp6tOl/IQn8 swmnNiMfrU384ae6p8/mpUPKaZkglupPQ6TNhHHwCiu+36bnXKXiWoKVoEuTw3CrNPoZ VrXGOnmxLpivNuWSLY/xUMbcCNxaccvN/kokyxBbOximKP+gpCV30eFUc6oUa/K6XItQ N+1Q== Received: by 10.68.201.6 with SMTP id jw6mr26825829pbc.92.1334566892320; Mon, 16 Apr 2012 02:01:32 -0700 (PDT) Received: from [10.8.1.109] ([124.207.251.123]) by mx.google.com with ESMTPS id l4sm17153093pbl.27.2012.04.16.02.01.26 (version=SSLv3 cipher=OTHER); Mon, 16 Apr 2012 02:01:29 -0700 (PDT) Message-ID: <4F8BDFDD.6070604@gmail.com> Date: Mon, 16 Apr 2012 17:01:17 +0800 From: fuzhli User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: cz li References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: The user-mode stack space is how many bytes? 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, 16 Apr 2012 09:01:32 -0000 On 2012/4/16 14:48, cz li wrote: > The user-mode stack space is how many bytes, the kernel stack is how > many bytes. I've written a driver.I want to add it to the kernel > source. How should I do? > Thank you. > > lichaozhong > 2012-4-16 > _______________________________________________ > 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" > You can use limits(1) to show the user-mode stack space size. As I know, the kernel stack size is 2 pages. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 12:34:46 2012 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 C848A106564A; Mon, 16 Apr 2012 12:34:46 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 7DC418FC0C; Mon, 16 Apr 2012 12:34:46 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 748846528BD; Mon, 16 Apr 2012 14:28:55 +0200 (CEST) Received: from [192.168.96.31] (eb0011.eb.z [192.168.96.31]) by mail.embedded-brains.de (Postfix) with ESMTP id C73086528BE; Mon, 16 Apr 2012 14:28:50 +0200 (CEST) Message-ID: <4F8C1082.3020801@embedded-brains.de> Date: Mon, 16 Apr 2012 14:28:50 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: XDR Library and Short Enums 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, 16 Apr 2012 12:34:46 -0000 Hi, the XDR library implementation of xdr_enum() is currently: /* * XDR enumerations */ bool_t xdr_enum(XDR *xdrs, enum_t *ep) { enum sizecheck { SIZEVAL }; /* used to find the size of an enum */ /* * enums are treated as ints */ /* LINTED */ if (sizeof (enum sizecheck) == sizeof (long)) { return (xdr_long(xdrs, (long *)(void *)ep)); } else /* LINTED */ if (sizeof (enum sizecheck) == sizeof (int)) { return (xdr_int(xdrs, (int *)(void *)ep)); } else /* LINTED */ if (sizeof (enum sizecheck) == sizeof (short)) { return (xdr_short(xdrs, (short *)(void *)ep)); } else { return (FALSE); } } The enum_t is defined as: typedef int32_t enum_t; This is problematic with short enums (variable sized enums). I case of short enums sizeof (enum sizecheck) would be 1. The ARM EABI lets you a choice between two alternatives described in the document issued by ARM. See also section 7.1.3 "Enumerated Types" http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf How would you implement and use the XDR library with short enums? The xdr_enum() can be easily changed to: /* * XDR enumerations */ bool_t xdr_enum(XDR *xdrs, enum_t *ep) { /* * enums are treated as ints */ /* LINTED */ if (sizeof (enum_t) == sizeof (long)) { return (xdr_long(xdrs, (long *)(void *)ep)); } else /* LINTED */ if (sizeof (enum_t) == sizeof (int)) { return (xdr_int(xdrs, (int *)(void *)ep)); } else /* LINTED */ if (sizeof (enum_t) == sizeof (short)) { return (xdr_short(xdrs, (short *)(void *)ep)); } else { return (FALSE); } } The problem is in the XDR library usage. An example is this (rpc_msg.h): enum msg_type { CALL=0, REPLY=1 }; How would you fix this? What about enum msg_type { CALL=0, REPLY=1, _MSG_TYPE_INVALID = 0xffffffff }; ? -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 13:21:09 2012 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 0329E106566B; Mon, 16 Apr 2012 13:21:09 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 799418FC15; Mon, 16 Apr 2012 13:21:08 +0000 (UTC) Received: by dadz14 with SMTP id z14so23548434dad.17 for ; Mon, 16 Apr 2012 06:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zIjq9JyfIliD1sZ2nd2gPCdhigEM1QsE+OnjjeO/YOI=; b=rPNLrBTBE/HF0ZSXGrs5Y5b3Ky0h2A957pFoUNfhw8/hezkUQyc9/5XahidNuEcXlE G0jAqCmOeaTTMAh1+NlbVcHaCS0oD0JcnTKfKMm2vcj0fYLjMOVKmWqCAQylJ9I+4r04 pf7ekQtSSK7pJ1krLizTzvXsN4FE9XEDlavnbNA+l8KXTsT6jegd411MkPcMJAR9Vo/2 Izjls2IFzSZpBzaRQTBRo+4wllDNnL9V5/Brd0U8MISYXcU5NMSfN5lBWIu6k6i+WkSA DRhKN+YK3jp7nrJQXQFYRR7okG6qyN1SN7+fQir9lhxb3412xfJLW3U9GXFV+pw2L23s eoSQ== MIME-Version: 1.0 Received: by 10.68.233.234 with SMTP id tz10mr28202390pbc.68.1334582467977; Mon, 16 Apr 2012 06:21:07 -0700 (PDT) Received: by 10.68.234.106 with HTTP; Mon, 16 Apr 2012 06:21:07 -0700 (PDT) In-Reply-To: References: <1334419376.1082.162.camel@revolution.hippie.lan> Date: Mon, 16 Apr 2012 08:21:07 -0500 Message-ID: From: Mark Tinguely To: Damjan Marion Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ian Lepore , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:21:09 -0000 On Sat, Apr 14, 2012 at 1:37 PM, Damjan Marion wrote: > > On Apr 14, 2012, at 6:02 PM, Ian Lepore wrote: > >> It's been my growing impression for about a year that the arm support in >> FreeBSD has atrophied to the point where it can barely be said that it's >> supported at all. =A0Now I see this morning that marius@ has committed a >> set of style cleanups to the at91 code (r234281), so maybe it's not >> quite as dead as I feared. > > Hi Ian, > > Are you aware of projects/armv6[1] in svn? > > Due to big changes in architecture introduced with ARMv6 we have > separate tree where all ongoing development is happening. > Hopefully we will be able to merge back changes to HEAD soon. > > We have (partially) working support for recent Marvel SoC and some TI boa= rds > (PandaBoard/OMAP4, Beaglebone/AM335x). There is also OMAP3 code waiting > to be integrated. > > Also Andrew is working on moving to ARM EABI[2] which will > allow us to use llvm/clang and all new ARM goodies which are > not supported in our aged gcc. > > Any help is welcome... > > Damjan > > [1] http://svnweb.freebsd.org/base/projects/armv6/ > [2] http://svnweb.freebsd.org/base/projects/arm_eabi There is a lot of ARM work going on in the shadows. I know of other things, but will let them say what they are doing. I am doing an experimental implementation using the ARMv7 hardware features on the pandaboard getting ready for ARMv8. As of this weekend, the ARMv7 experimental pmap/support is booting multi-user. There is a lot of improvements, fixing, tweeking, and polishing. (I am taking out domains shared level1 pagetables, remove the pv_entry. I will eventually start doing the 64 bit extended address support, etc). I eventually want to change the boot (fold chunks of initarm() into pmap/machdep because they are constant for every platform. --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 14:18:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5093A106564A; Mon, 16 Apr 2012 14:18:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9FC8FC17; Mon, 16 Apr 2012 14:18:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 89A52B93B; Mon, 16 Apr 2012 10:18:02 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 16 Apr 2012 09:56:21 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> In-Reply-To: <4F89B567.6090008@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204160956.21148.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 16 Apr 2012 10:18:02 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 16 Apr 2012 14:18:03 -0000 On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: > on 14/04/2012 18:37 Andriy Gapon said the following: > > > > I would like to ask for a review and/or testing of the following three patches: > > http://people.freebsd.org/~avg/zfsboot.patches.diff > > > > These patches add support for booting from an arbitrary filesystem of any > > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > > affectfrom where zfsloader would be loaded. zfsboot passes information about > > the boot pool and filesystem to zfsloader, which uses those for loaddev and > > default value of currdev. A different pool+filesystem could be selected in > > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > > and is not derived from fstab, then it gets set to the selected boot filesystem. > > A note for prospective testers: the patched loader expect to be started by the > patched zfs boot as it passes an additional parameter for a filesystem guid. > I should probably add some way to distinguish between the older and newer zfs > boot blocks. Maybe an extra bit in bootflags? What do you think? An extra bit (similar to existing flags for detecting PXE and CD booting) sounds fine to me. (Note, I'm only replying to the question, have not looked at patches yet). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 14:18:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48CF6106566C for ; Mon, 16 Apr 2012 14:18:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2A88FC19 for ; Mon, 16 Apr 2012 14:18:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6C918B945; Mon, 16 Apr 2012 10:18:03 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Mon, 16 Apr 2012 09:59:29 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F775DF5.1020704@rawbw.com> <4F8A8CD2.5020103@rawbw.com> <20120415093029.GR2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120415093029.GR2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204160959.29089.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 16 Apr 2012 10:18:03 -0400 (EDT) Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: Is there any modern alternative to pstack? 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, 16 Apr 2012 14:18:04 -0000 On Sunday, April 15, 2012 5:30:29 am Konstantin Belousov wrote: > On Sun, Apr 15, 2012 at 01:54:42AM -0700, Yuri wrote: > > On 04/05/2012 07:06, John Baldwin wrote: > > >In this case we probably should become the upstream maintainer. My patch > > >actually bumps the version to 1.3 as it is sort of intended to do that. > > > > bsd-pstack on SourceForge is dead. Sole project owner isn't responsive, > > and as per SF policy they don't allow anyone to take over such project. > > They suggest to fork. > > So will you object if I create a new project on SF, say bsd-pstack-new, > > will import the current source and apply your patch and make a release? > > I will also update pstack port so that it will become current. > It seems that the license is two-clause BSD. > My opinion is that such tool should be imported into the base. I'm fine with putting it into the base. If so, we should import 1.2 first I think and then apply the 1.3 patch. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 16:05:40 2012 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 C562A106564A for ; Mon, 16 Apr 2012 16:05:40 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 93EAB8FC0C for ; Mon, 16 Apr 2012 16:05:40 +0000 (UTC) Received: (qmail 5280 invoked by uid 0); 16 Apr 2012 16:05:33 -0000 Received: from 67.206.183.41 by rms-us017 with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 16 Apr 2012 12:05:29 -0400 From: "Dieter BSD" Message-ID: <20120416160531.155070@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: HCb+b/dd3zOlNR3dAHAhvZx+IGRvb0CY Subject: Re: Is there any modern alternative to pstack? 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, 16 Apr 2012 16:05:40 -0000 Konstantin Belousov wrote: > My opinion is that such tool should be imported into the base. Why? Don't optional tools belong in ports? From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 18:41:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81F6F1065673 for ; Mon, 16 Apr 2012 18:41:31 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm19.bullet.mail.sp2.yahoo.com (nm19.bullet.mail.sp2.yahoo.com [98.139.91.89]) by mx1.freebsd.org (Postfix) with SMTP id 52FBC8FC12 for ; Mon, 16 Apr 2012 18:41:31 +0000 (UTC) Received: from [98.139.91.63] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 16 Apr 2012 18:41:25 -0000 Received: from [98.139.44.82] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 16 Apr 2012 18:41:25 -0000 Received: from [127.0.0.1] by omp1019.access.mail.sp2.yahoo.com with NNFMP; 16 Apr 2012 18:41:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 319528.1707.bm@omp1019.access.mail.sp2.yahoo.com Received: (qmail 72234 invoked by uid 60001); 16 Apr 2012 18:41:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334601684; bh=GXmL2gMXEykrxapPPJivO8hjViWNzGf0q/Wm32tf+zs=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m256cddN8yQ2cWqDLfiYIY81mGdtI4FARQ0taTXMYsssWNk0O+9LHwnqYJwedwom7Cvod+53rLJFEy1oFRFjAF3jJfUv/thHaKcWGc2nt2jSHkjHWZNm1SJiwIfRkEOeh04pDL79Ilrx2VyOzp9H0SA1vT9iUZyE2FSgS4R+7Ns= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0Ftq1xcT0XmCtdFz1nBfnwN48nwF4Yr4yaRq6oSzwPDShqJ2k5oR+m6he0tS8ib0D8W1uJ99lvE6AjiVhd5FYk6TQpvx86O17zsM/xEWBBE5uosN08aBZw4jm4ucExh+5x+ONQ98KzCrcnmdokBcwImQdl3IozB2J9CsErjzjm8=; X-YMail-OSG: a48na58VM1k4XAFYvtuhiG.6PGtBaCzxkZHbO2IjSZ7akyd h9iU43SC5QeIgQ7bQP5JjUxofblc0giEbiAEekqgXFD2j5BVPlVJZJMTHk5l 4sVS1svE2k79f92WOU79TsQLeBWSfOdx0gsmWzFYYYrLqMAf8Eyyt3VCMjPK IKM8FyrTjhsW6mDUXxVUPamK3JLVbPtvYbsu1CuR7ij5VVlVH0Uzu.eENs6V 9znX3zwI9PrKvc8YHdHHkdAfObaABmApyBbFCBP5pJHDlvmFh9Ha_FnipgwE OqXtsAn.ykaZSsnN8ZvZTUmZkuixwHmKvXhpZI8IO7QxEbpTPbLl8lSq0wrc BDL21WbRkB4tfry83ogk9_3iC0_nZ3xGKtmW_d6fppaC4zVI0MVDnfgfQY7N Wx.ezCzUHrvBu2fk7VllcgbCCewCwPrqe8r82xYvnMf.iIvMFTasKhNiaRv_ UpvrI Received: from [75.62.238.5] by web180001.mail.gq1.yahoo.com via HTTP; Mon, 16 Apr 2012 11:41:24 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334601684.58522.YahooMailClassic@web180001.mail.gq1.yahoo.com> Date: Mon, 16 Apr 2012 11:41:24 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov In-Reply-To: <20120413214536.GL2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN 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, 16 Apr 2012 18:41:31 -0000 Many thanks. I verified the patch you provided and it works fine.=0A=0ASush= anth=0A=0A=0A> Oh, I see. The problem is the VM_MAP_WIRE_NOHOLES flag.=0A> = Since we=0A> map only the initial stack fragment even for the=0A> MCL_WIREF= UTURE maps,=0A> there is a hole in the stack region.=0A> =0A> In fact, for = MCL_WIREFUTURE, we probably should map the=0A> whole=0A> stack at once, pre= faulting all pages.=0A> =0A> Below are two patches. The change for vm_mmap.= c would fix=0A> your immediate=0A> problem by allowing holes in wired regio= n.=0A> =0A> The change for vm_map.c prefaults the whole stack instead of=0A= > the=0A> initial fragment. The single-threaded programs still get a=0A> fa= ult=0A> on stack growth.=0A> =0A> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_= map.c=0A> index 6198629..2fd18d1 100644=0A> --- a/sys/vm/vm_map.c=0A> +++ b= /sys/vm/vm_map.c=0A> @@ -3259,7 +3259,10 @@ vm_map_stack(vm_map_t map,=0A> = vm_offset_t addrbos, vm_size_t max_ssize,=0A> =A0=A0=A0 =A0 =A0 addrbos + = max_ssize <=0A> addrbos)=0A> =A0=A0=A0 =A0=A0=A0 return=0A> (KERN_NO_SPACE= );=0A> =0A> -=A0=A0=A0 init_ssize =3D (max_ssize < sgrowsiz) ?=0A> max_ssi= ze : sgrowsiz;=0A> +=A0=A0=A0 if (map->flags & MAP_WIREFUTURE)=0A> +=A0=A0= =A0 =A0=A0=A0 init_ssize =3D=0A> max_ssize;=0A> +=A0=A0=A0 else=0A> +=A0=A0= =A0 =A0=A0=A0 init_ssize =3D=0A> (max_ssize < sgrowsiz) ? max_ssize : sgrow= siz;=0A> =0A> =A0=A0=A0 PROC_LOCK(curthread->td_proc);=0A> =A0=A0=A0 vme= mlim =3D lim_cur(curthread->td_proc,=0A> RLIMIT_VMEM);=0A> diff --git a/sys= /vm/vm_mmap.c b/sys/vm/vm_mmap.c=0A> index 2588c85..3fccd9e 100644=0A> --- = a/sys/vm/vm_mmap.c=0A> +++ b/sys/vm/vm_mmap.c=0A> @@ -1561,9 +1561,11 @@ vm= _mmap(vm_map_t map, vm_offset_t=0A> *addr, vm_size_t size, vm_prot_t prot,= =0A> =A0=A0=A0 =A0=A0=A0=A0=A0* If the=0A> process has requested that all = future mappings=0A> =A0=A0=A0 =A0=A0=A0=A0=A0* be=0A> wired, then heed thi= s.=0A> =A0=A0=A0 =A0=A0=A0=A0=A0*/=0A> -=A0=A0=A0 =A0=A0=A0 if (map->flags= =0A> & MAP_WIREFUTURE)=0A> +=A0=A0=A0 =A0=A0=A0 if (map->flags=0A> & MAP_WI= REFUTURE) {=0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> vm_map_wire(map, *addr, = *addr + size,=0A> -=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> =A0 =A0 VM_MAP_WIRE_US= ER | VM_MAP_WIRE_NOHOLES);=0A> +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> =A0 =A0 V= M_MAP_WIRE_USER | ((flags & MAP_STACK) ?=0A> +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0= =0A> =A0 =A0 VM_MAP_WIRE_HOLESOK : VM_MAP_WIRE_NOHOLES));=0A> +=A0=A0=A0 = =A0=A0=A0 }=0A> =A0=A0=A0 } else {=0A> =A0=A0=A0 =A0=A0=A0 /*=0A> =A0=A0= =A0 =A0=A0=A0=A0=A0* If this=0A> mapping was accounted for in the vnode's= =0A> From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 19:12:08 2012 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 2D8B1106566B for ; Mon, 16 Apr 2012 19:12:08 +0000 (UTC) (envelope-from etempest@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id CC9C68FC18 for ; Mon, 16 Apr 2012 19:12:07 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT4xvB1ww9PQUo6a+VVqMiGWd/p+knQWL@postini.com; Mon, 16 Apr 2012 12:12:07 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 16 Apr 2012 12:08:34 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 16 Apr 2012 12:08:34 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 16 Apr 2012 15:08:29 -0400 From: Ewart Tempest To: "freebsd-hackers@freebsd.org" Date: Mon, 16 Apr 2012 15:08:25 -0400 Thread-Topic: Corrupted pmap pm_vlist - pmap_remove_pte() Thread-Index: Ac0cBEza14fHNTwiSTiknI7KKPUryw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 16 Apr 2012 20:33:43 +0000 Cc: Tony Lanza , Ewart Tempest Subject: Corrupted pmap pm_vlist - pmap_remove_pte() 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, 16 Apr 2012 19:12:08 -0000 In FreeBSD 6.*, we have been seeing crashes in pmap_remove_pages() that onl= y seem to occur in scaling scenarios: 2564 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY 2565 pte =3D vtopte(pv->pv_va); 2566 #else 2567 pte =3D pmap_pte(pmap, pv->pv_va); 2568 #endif 2569 tpte =3D *pte; <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D page fault here The suspicion is that the pmap's pm_pvlist list is getting corrupted. To th= is end, I have a question on the following logic in pmap_remove_pte() (see = in-line comment): 1533 static int 1534 pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va, pd_en= try_t ptepde) 1535 { 1536 pt_entry_t oldpte; 1537 vm_page_t m; 1538=20 1539 PMAP_LOCK_ASSERT(pmap, MA_OWNED); 1540 oldpte =3D pte_load_clear(ptq); 1541 if (oldpte & PG_W) 1542 pmap->pm_stats.wired_count -=3D 1; 1543 /* 1544 * Machines that don't support invlpg, also don't support 1545 * PG_G. 1546 */ 1547 if (oldpte & PG_G) 1548 pmap_invalidate_page(kernel_pmap, va); 1549 pmap->pm_stats.resident_count -=3D 1; 1550 if (oldpte & PG_MANAGED) { 1551 m =3D PHYS_TO_VM_PAGE(oldpte & PG_FRAME); 1552 if (oldpte & PG_M) { 1553 #if defined(PMAP_DIAGNOSTIC) 1554 if (pmap_nw_modified((pt_entry_t) oldpte)) { 1555 printf( 1556 "pmap_remove: modified page not writable: va: 0x%lx, pte: 0x%lx\n"= , 1557 va, oldpte); 1558 } 1559 #endif 1560 if (pmap_track_modified(va)) 1561 vm_page_dirty(m); 1562 } 1563 if (oldpte & PG_A) 1564 vm_page_flag_set(m, PG_REFERENCED); 1565 pmap_remove_entry(pmap, m, va); 1566 } 1567 return (pmap_unuse_pt(pmap, va, ptepde)); <=3D=3D=3D=3D=3D=3D=3D *= ** under what circumstances is it valid to free the page but not remove it = from the pmap's pm_vlist? Even the code comment for pmap_unuse_pt() commenc= es "After removing a page table entry ... ". *** 1568 } If the tail end of the above function is changed as follows: 1565 pmap_remove_entry(pmap, m, va); 1565.5 return (pmap_unuse_pt(pmap, va, ptepde)); 1566 } 1567 return (0); Then we don't see any crashes ... but is it the right thing to do? Ewart From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 16 21:39:13 2012 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 5DF99106564A for ; Mon, 16 Apr 2012 21:39:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA5D8FC14 for ; Mon, 16 Apr 2012 21:39:13 +0000 (UTC) Received: by dadz14 with SMTP id z14so25052696dad.17 for ; Mon, 16 Apr 2012 14:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Oe1Rzw5IV4CqmIbACSJOMKXTOY2z5fT0e+kAqRzGP/A=; b=G/SP3oQIcP4AVNwj0GLd/zXEjI4AMF1cjeW5pdTsoGajGpaR6gMaIhwZteqkAmj/4R RrFKjgNlH1GrHhUD+zSl5iV+fiZIjoJ829fJ+wVnBb8J7EfrDkSSW7633+Bq+O86CQ8g LH1prnlghCZjFYKfeUIPKOOJlFG+8YfS/5zbaZBXo6YpzYrL5CyA0ezNvWxPrvE4ekZe NR3YmhB2WlC7avvLXKrqxDJGXiGGmUUMFQNxfTJLo/B29/l621dmJ7qLetMK314etHjN wwlY1uDqE23fw12sAS0Tw6mo8Cg4UvJHadxNAPF3cAsKfzaC5+SSi3MCRUicTJXuZb4a yapA== MIME-Version: 1.0 Received: by 10.68.212.130 with SMTP id nk2mr28090928pbc.166.1334612352937; Mon, 16 Apr 2012 14:39:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Mon, 16 Apr 2012 14:39:12 -0700 (PDT) In-Reply-To: <20120411192153.5672b62c@ernst.jennejohn.org> References: <20120403193124.46ad9de9@ernst.jennejohn.org> <20120411192153.5672b62c@ernst.jennejohn.org> Date: Mon, 16 Apr 2012 14:39:12 -0700 X-Google-Sender-Auth: 0c_7IbjDbwKnak4f9NHzYoUPgdA Message-ID: From: Adrian Chadd To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , Jerry Toung Subject: Re: CAM disk I/O starvation 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, 16 Apr 2012 21:39:13 -0000 On 11 April 2012 10:21, Gary Jennejohn wrote: > Just for the archive my bad disk performance seems to have been fixed in > HEAD by svn commit r234074. =A0Seems that all interrupts were being handl= ed > by a single CPU/core (I have 6), which resulted in abysmal interrupt > handling when mutltiple disks were busy. > > Since this commit my disk preformance is back to normal and long lags > are a thing of the past. Hi, This is kind of worrying. You only have a few disks, a single core SHOULD be able to handle all the interrupts for those disks whilst leaving plenty of cycles to spare to drive the rest of your system. And you have 5 other cores. Would you be willing to help out diagnose exactly why that particular behaviour is causing you so much trouble? It almost sounds like something in the IO path is blocking for far too long, not allowing the rest of the system to move forward. That's very worrying for an interrupt handler. :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 09:48:30 2012 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 C4F881065670; Tue, 17 Apr 2012 09:48:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 570FF8FC0C; Tue, 17 Apr 2012 09:48:29 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3H9mLY8018351; Tue, 17 Apr 2012 12:48:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3H9mLuP005591; Tue, 17 Apr 2012 12:48:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3H9mKwf005590; Tue, 17 Apr 2012 12:48:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 17 Apr 2012 12:48:20 +0300 From: Konstantin Belousov To: Ewart Tempest Message-ID: <20120417094820.GK2358@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nO+apMLAy/edto0B" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: alc@freebsd.org, "freebsd-hackers@freebsd.org" , Tony Lanza Subject: Re: Corrupted pmap pm_vlist - pmap_remove_pte() 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, 17 Apr 2012 09:48:30 -0000 --nO+apMLAy/edto0B Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2012 at 03:08:25PM -0400, Ewart Tempest wrote: > In FreeBSD 6.*, we have been seeing crashes in pmap_remove_pages() that o= nly seem to occur in scaling scenarios: >=20 > 2564 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY > 2565 pte =3D vtopte(pv->pv_va); > 2566 #else > 2567 pte =3D pmap_pte(pmap, pv->pv_va); > 2568 #endif > 2569 tpte =3D *pte; <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D page fault here >=20 > The suspicion is that the pmap's pm_pvlist list is getting corrupted. To = this end, I have a question on the following logic in pmap_remove_pte() (se= e in-line comment): >=20 > 1533 static int > 1534 pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va, pd_= entry_t ptepde) > 1535 { > 1536 pt_entry_t oldpte; > 1537 vm_page_t m; > 1538=20 > 1539 PMAP_LOCK_ASSERT(pmap, MA_OWNED); > 1540 oldpte =3D pte_load_clear(ptq); > 1541 if (oldpte & PG_W) > 1542 pmap->pm_stats.wired_count -=3D 1; > 1543 /* > 1544 * Machines that don't support invlpg, also don't support > 1545 * PG_G. > 1546 */ > 1547 if (oldpte & PG_G) > 1548 pmap_invalidate_page(kernel_pmap, va); > 1549 pmap->pm_stats.resident_count -=3D 1; > 1550 if (oldpte & PG_MANAGED) { > 1551 m =3D PHYS_TO_VM_PAGE(oldpte & PG_FRAME); > 1552 if (oldpte & PG_M) { > 1553 #if defined(PMAP_DIAGNOSTIC) > 1554 if (pmap_nw_modified((pt_entry_t) oldpte)) { > 1555 printf( > 1556 "pmap_remove: modified page not writable: va: 0x%lx, pte: 0x%lx\= n", > 1557 va, oldpte); > 1558 } > 1559 #endif > 1560 if (pmap_track_modified(va)) > 1561 vm_page_dirty(m); > 1562 } > 1563 if (oldpte & PG_A) > 1564 vm_page_flag_set(m, PG_REFERENCED); > 1565 pmap_remove_entry(pmap, m, va); > 1566 } > 1567 return (pmap_unuse_pt(pmap, va, ptepde)); <=3D=3D=3D=3D=3D=3D=3D= *** under what circumstances is it valid to free the page but not remove i= t from the pmap's pm_vlist? Even the code comment for pmap_unuse_pt() comme= nces "After removing a page table entry ... ". *** It is valid to not remove pv_entry when no pv_entry exists for the mapping. The pv_entry is created if the page is managed, see pmap_enter() code. The block above the return is executed when the page is managed, or at least pmap thinks so. The HEAD code will panic in pmap_pvh_free() if pmap_phv_remove() cannot find the pv entry for given page and given pmap/va. > 1568 } >=20 > If the tail end of the above function is changed as follows: >=20 > 1565 pmap_remove_entry(pmap, m, va); > 1565.5 return (pmap_unuse_pt(pmap, va, ptepde)); > 1566 } > 1567 return (0); >=20 > Then we don't see any crashes ... but is it the right thing to do? Should be not. Try to test this with some unmanaged mapping, like /dev/mem pages mapped into the exiting process address space. I am too new to know about any nuances of the RELENG_6 code. --nO+apMLAy/edto0B Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+NPGQACgkQC3+MBN1Mb4jKjwCfZdJAjdcJ2d7SFP/NdhiTAZc/ kf4AnAmlE3ir/1n6zUackWmq8k5OTp81 =Gcsz -----END PGP SIGNATURE----- --nO+apMLAy/edto0B-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 10:36:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAC70106566C for ; Tue, 17 Apr 2012 10:36:01 +0000 (UTC) (envelope-from ali_mousa_zy@yahoo.com) Received: from nm8-vm0.bullet.mail.ne1.yahoo.com (nm8-vm0.bullet.mail.ne1.yahoo.com [98.138.91.23]) by mx1.freebsd.org (Postfix) with SMTP id 8F1908FC08 for ; Tue, 17 Apr 2012 10:36:01 +0000 (UTC) Received: from [98.138.90.48] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 10:35:54 -0000 Received: from [98.138.89.168] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 10:35:54 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 10:35:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 949824.96841.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 36037 invoked by uid 60001); 17 Apr 2012 10:35:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334658954; bh=JKFR9+pMLWTHZCDwf25CZyygj6Wjudl207jMTJIGUyM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1W9oE85MXVyOslfpRnjgWq+CxWPiiJglfQWxQwi/ec116IYdffpiB8MhnRoqISZbqOcpfRTuTYAgcEA6yPJOWrc4pm73vCAOyHnGW2P4Z9rnx/giOPjkT6YIGwerJmwHofstyEqbsp26IH8+n12IMr46gjuesoFDLVTnqOkhrrM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=zc8U19l15HhvIHzqAAQuaMmK/28iy3qzOpO+eDoyRIKid9wtr78Rb26xYfwutnmOoKBxM4H6/8c7ebKHtX2Pkc3n+afXyMniUrMwNU6DvfScgs95HzDHnyn56wP7YU7YTQ49aHuqXA4n4CEFJglbpNQthpiU2XBEa1CC//zBO1M=; X-YMail-OSG: tS507ZEVM1kSVHrtx0nVaIGJ2RDNliio4E8MAJc85s1CZuE kvyuej2M8DVCOj9uS.ozUfXKXJJUZ9U_4_fpmxCRhdVFYWhx4fv71S2268Jn zfUfo8avFHBAm5fs2GqbWMUA08G7etI7V.WiTAiotxxjLNQse0lgCZzkrNRE 3RLaaejfclA7hMLnDBW3W3eIE6AYDLalvHRPfn5dZionUAfaLMHErdSP.kpJ u5Z_TXm7Wp.vk00DnAKOmcuxAUXM2t3OP_e2rOso0fl04BkEclOZPPoS0nEx jBUZif5dqGAvg4sQBzl8MsCzilkrXnBc_IzFSioxnkbC1s102SOYifLQMomD 1.4x.irQnZ6Qb.0M.pLXB5xI_oK372Q7kT8h1AM4rChMZYTfrF9RsO0Q_plN .ApZNvxAnzR6EzvOIvfEgJkTnGY8nKrhxgqVaWW4tadStgZqiJDX4KuqYFuS vAYYCdxU- Received: from [92.253.83.80] by web125404.mail.ne1.yahoo.com via HTTP; Tue, 17 Apr 2012 03:35:54 PDT X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1334658954.23682.YahooMailNeo@web125404.mail.ne1.yahoo.com> Date: Tue, 17 Apr 2012 03:35:54 -0700 (PDT) From: ali mousa To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 17 Apr 2012 11:31:22 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Performance mesurment tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ali mousa List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:36:02 -0000 Hi all=0A=0AI'm working on a new tool that may increase Operating System = =0Aperformance. I'm looking for a tool that can measure OS performance =0Ae= specially FreeBSD, so I can compare after and before applying the =0Apatch.= =0A=0AI will be thankful for any help. =0A=A0=0AAli=0AAlrahahleh =0Atech y= ahoo, software apps dev eng,=0A=0Awork email :amousa@yahoo-inc.com=0Aperson= al email: ali_mousa_zy@yahoo.com=0Adirect +(962) 65506933=A0=A0=A0 mobile += (962) 777465533=0A=0Aal husseini building 141 mecca street, amman, 1114, jo= =0Aphone (408) 349 3300=A0=A0=A0 fax (408) 349 3301=A0=A0 From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 12:28:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 666A71065679 for ; Tue, 17 Apr 2012 12:28:38 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by mx1.freebsd.org (Postfix) with ESMTP id 27CD48FC1A for ; Tue, 17 Apr 2012 12:28:38 +0000 (UTC) Received: from [192.168.1.6] (unknown [217.157.7.221]) by csmtp2.one.com (Postfix) with ESMTPA id E6D9B307981E; Tue, 17 Apr 2012 12:20:31 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Erik Cederstrand In-Reply-To: <1334658954.23682.YahooMailNeo@web125404.mail.ne1.yahoo.com> Date: Tue, 17 Apr 2012 14:20:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38AB916D-ABB7-40BB-9689-DCB7F5ADA5A5@cederstrand.dk> References: <1334658954.23682.YahooMailNeo@web125404.mail.ne1.yahoo.com> To: ali mousa X-Mailer: Apple Mail (2.1257) Cc: "freebsd-hackers@freebsd.org" Subject: Re: Performance mesurment tools 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, 17 Apr 2012 12:28:38 -0000 Hi Ali, Den 17/04/2012 kl. 12.35 skrev ali mousa: > Hi all >=20 > I'm working on a new tool that may increase Operating System=20 > performance. I'm looking for a tool that can measure OS performance=20 > especially FreeBSD, so I can compare after and before applying the=20 > patch.=20 Take a look at the benchmark tools in /usr/ports/benchmarks/ and find = one that measures the area you are trying to improve. You might want to consult http://wiki.freebsd.org/BenchmarkAdvice before = you run any measurements. Thanks, Erik= From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 13:00:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1AF61065670 for ; Tue, 17 Apr 2012 13:00:30 +0000 (UTC) (envelope-from ali_mousa_zy@yahoo.com) Received: from nm37-vm3.bullet.mail.ne1.yahoo.com (nm37-vm3.bullet.mail.ne1.yahoo.com [98.138.229.131]) by mx1.freebsd.org (Postfix) with SMTP id 624358FC14 for ; Tue, 17 Apr 2012 13:00:30 +0000 (UTC) Received: from [98.138.90.56] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 12:58:40 -0000 Received: from [98.138.88.238] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 12:58:40 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 17 Apr 2012 12:58:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 66101.13631.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 88057 invoked by uid 60001); 17 Apr 2012 12:58:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334667519; bh=JhmcOBZdFQEUgkKpDKv/ckNL7jpTPAH0cdGj2JWDj20=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PPHO8hSvDra7vslpK7w10A0D5K+7V7G3EaNRnZXboa7NoIFlBUxnwuppoN0wq3fWLB3ExBo89InuDMimZ3EA0UHpVzmTYkTQzXjt0tjl98/NWaRS+7ek1WnTilxdzbSd5pfSjpZ5hIniZMtWmgPcbQxTSUZQmY377Wy/bAT9P3U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=r6qZhOrmVSw8fmstCQELW+qVn+UkCkrLeaeWCz/O1kOo34UYJdLpL/NhDTundKAhSb/mzX9on42NpgZqpJOea5gFGHkr6QZaZrcxjLxk7A7BCVyfv3J5BF8jmQszuRfVvecOUjAlnj0ZaSUQ0zsMRchkVhvQylCcjBndwhWwuU4=; X-YMail-OSG: m7sLcW0VM1nzDRF4t3XBp..kbF4VkG45ADVR34fHiVXCCYE 5fUfBu0NbGnO7ryrBIVxJkuHzwCYnlG5n96OkNCzKjgj_Fj78tGut6azB5Vr L8on7EB1Z1g_Gk4gQgV7PsBbhb3o97Y3kKZNL6YmgZGjod2wJNGAm6DnqW.f uofakhPgCB5Iw3w4vJrVjWR9OBqEAq8XZngSZgBRLiLA5yj9ry7KNnMd5Xm3 8pguUMCtKE.VDh76eSsOhAwm2OAHjEKHKKPtpV80XHkmeDVjcGwf.hUyMlSy sg06Sdf2CLvvNh_n7uugvnG_i8S3kebJjqzXwhFpleO8avL4PFOcaEJYE3m8 GW.IlWNKkvRYbkaeQ0vJdVgGpI6g0kbeN5.iHtHxceIsQj.ErVgbtGhe3qu5 XlOjnGgbtorY3ey1BXSn_QgRycalaDa.e4HB4hSYz.3B29.jGha0YC.kD3Zu mAUza.5zZyMEXcyFFkplWHkjUk9z3JA-- Received: from [92.253.83.80] by web125406.mail.ne1.yahoo.com via HTTP; Tue, 17 Apr 2012 05:58:39 PDT X-Mailer: YahooMailWebService/0.8.117.340979 References: <1334658954.23682.YahooMailNeo@web125404.mail.ne1.yahoo.com> <38AB916D-ABB7-40BB-9689-DCB7F5ADA5A5@cederstrand.dk> Message-ID: <1334667519.85783.YahooMailNeo@web125406.mail.ne1.yahoo.com> Date: Tue, 17 Apr 2012 05:58:39 -0700 (PDT) From: ali mousa To: Erik Cederstrand In-Reply-To: <38AB916D-ABB7-40BB-9689-DCB7F5ADA5A5@cederstrand.dk> MIME-Version: 1.0 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: Performance mesurment tools X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ali mousa List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:00:30 -0000 =0A=0A=A0=0A=A0=0A=0A________________________________=0A From: Erik Cederst= rand =0ATo: ali mousa =0ACc: = "freebsd-hackers@freebsd.org" =0ASent: Tuesda= y, April 17, 2012 3:20 PM=0ASubject: Re: Performance mesurment tools=0A =0A= Hi Erik=0A=0A>> Hi all=0A>> =0A>> I'm working on a new tool that may increa= se Operating System =0A>> performance. I'm looking for a tool that can meas= ure OS performance =0A>> especially FreeBSD, so I can compare after and bef= ore applying the =0A>> patch. =0A=0A>Take a look at the benchmark tools in = /usr/ports/benchmarks/ and find one that measures the area you are trying t= o improve.=0A=0AI'm looking to compare response time and utilization , I fo= und a set of useful dtrace script and I'm going to try them out , any other= resources will be welcomed .=0A=0A>You might want to consult http://wiki.f= reebsd.org/BenchmarkAdvice before you run any measurements.=0A=0AThanks you= for this link, it really helped =0A=0A>Thanks,=0A>Erik____________________= ___________________________=0A>freebsd-hackers@freebsd.org mailing list=0A>= http://lists.freebsd.org/mailman/listinfo/freebsd-hackers=0A>To unsubscribe= , send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 13:35:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B93481065670; Tue, 17 Apr 2012 13:35:59 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E2F28FC0A; Tue, 17 Apr 2012 13:35:59 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so8092126pbc.13 for ; Tue, 17 Apr 2012 06:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fPN7DKKevVG3By0b+jofvX6GRhnMLur5ND+1d8Ed3nk=; b=FkIajizOpoHLfkwadJdkWuvBZVlaUTfrKZ7rPdF8XZDfveEdeAUhj6rYZQNqdww03q KvOHMORj/4chIORW1eVRLctCIQuFbJv6KNJDgV7gi3ldP6pQp+OR4FrCdjVeLDrijK6W r7yp8V4eKOo6Xr0x1vd0776VhXA6jwH/qm1nZTQnow4F65uEl86n64H36LK9qed0xGlr lw8xRi+15jCzRFL2wvnaKKffPj1AADCLl4e/aiDjmbCZqn6m6H7MRcB47qzXcs3jih0j eEJbLKB5QHGlqjH7aOMC61xaJ5nNWAo89EY4xa8FUfFkPneBdcCkLWYC5lVuuOICqgPU Cmpg== MIME-Version: 1.0 Received: by 10.68.223.33 with SMTP id qr1mr36493189pbc.47.1334669759277; Tue, 17 Apr 2012 06:35:59 -0700 (PDT) Received: by 10.68.234.106 with HTTP; Tue, 17 Apr 2012 06:35:59 -0700 (PDT) In-Reply-To: References: <1334419376.1082.162.camel@revolution.hippie.lan> Date: Tue, 17 Apr 2012 08:35:59 -0500 Message-ID: From: Mark Tinguely To: Damjan Marion Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [GSoC] [ARM] arm cleanup - my own proposal X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 13:35:59 -0000 On Mon, Apr 16, 2012 at 8:21 AM, Mark Tinguely wrote: ... > There is a lot of ARM work going on in the shadows. I know of other > things, but will let them say what they are doing. ... Correction to my posting. I am not removing pv_entrys but removing the flag of attributes ( pvh_attrs which hold PVF_xxx values). The ARMv7 and ARMv8 have some OS bits in the page table entries. > --Mark Tinguely. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 14:58:08 2012 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 C129E106564A; Tue, 17 Apr 2012 14:58:08 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id 87AC88FC08; Tue, 17 Apr 2012 14:58:08 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 6532329115C; Tue, 17 Apr 2012 09:50:27 -0500 (CDT) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 4DDB429117C; Tue, 17 Apr 2012 09:50:27 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id gl-KP7lo3p6c; Tue, 17 Apr 2012 09:50:27 -0500 (CDT) Received: from [172.20.122.218] (unknown [198.181.231.228]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh6.mail.rice.edu (Postfix) with ESMTPSA id C917529115C; Tue, 17 Apr 2012 09:50:22 -0500 (CDT) Message-ID: <4F8D8317.3060001@rice.edu> Date: Tue, 17 Apr 2012 09:49:59 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <20120417094820.GK2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120417094820.GK2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, "freebsd-hackers@freebsd.org" , Tony Lanza , Ewart Tempest Subject: Re: Corrupted pmap pm_vlist - pmap_remove_pte() 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, 17 Apr 2012 14:58:08 -0000 On 4/17/2012 4:48 AM, Konstantin Belousov wrote: > On Mon, Apr 16, 2012 at 03:08:25PM -0400, Ewart Tempest wrote: >> In FreeBSD 6.*, we have been seeing crashes in pmap_remove_pages() that only seem to occur in scaling scenarios: >> >> 2564 #ifdef PMAP_REMOVE_PAGES_CURPROC_ONLY >> 2565 pte = vtopte(pv->pv_va); >> 2566 #else >> 2567 pte = pmap_pte(pmap, pv->pv_va); >> 2568 #endif >> 2569 tpte = *pte;<===================== page fault here >> >> The suspicion is that the pmap's pm_pvlist list is getting corrupted. To this end, I have a question on the following logic in pmap_remove_pte() (see in-line comment): >> >> 1533 static int >> 1534 pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va, pd_entry_t ptepde) >> 1535 { >> 1536 pt_entry_t oldpte; >> 1537 vm_page_t m; >> 1538 >> 1539 PMAP_LOCK_ASSERT(pmap, MA_OWNED); >> 1540 oldpte = pte_load_clear(ptq); >> 1541 if (oldpte& PG_W) >> 1542 pmap->pm_stats.wired_count -= 1; >> 1543 /* >> 1544 * Machines that don't support invlpg, also don't support >> 1545 * PG_G. >> 1546 */ >> 1547 if (oldpte& PG_G) >> 1548 pmap_invalidate_page(kernel_pmap, va); >> 1549 pmap->pm_stats.resident_count -= 1; >> 1550 if (oldpte& PG_MANAGED) { >> 1551 m = PHYS_TO_VM_PAGE(oldpte& PG_FRAME); >> 1552 if (oldpte& PG_M) { >> 1553 #if defined(PMAP_DIAGNOSTIC) >> 1554 if (pmap_nw_modified((pt_entry_t) oldpte)) { >> 1555 printf( >> 1556 "pmap_remove: modified page not writable: va: 0x%lx, pte: 0x%lx\n", >> 1557 va, oldpte); >> 1558 } >> 1559 #endif >> 1560 if (pmap_track_modified(va)) >> 1561 vm_page_dirty(m); >> 1562 } >> 1563 if (oldpte& PG_A) >> 1564 vm_page_flag_set(m, PG_REFERENCED); >> 1565 pmap_remove_entry(pmap, m, va); >> 1566 } >> 1567 return (pmap_unuse_pt(pmap, va, ptepde));<======= *** under what circumstances is it valid to free the page but not remove it from the pmap's pm_vlist? Even the code comment for pmap_unuse_pt() commences "After removing a page table entry ... ". *** > It is valid to not remove pv_entry when no pv_entry exists for the mapping. > The pv_entry is created if the page is managed, see pmap_enter() code. > The block above the return is executed when the page is managed, or at > least pmap thinks so. > > The HEAD code will panic in pmap_pvh_free() if pmap_phv_remove() cannot > find the pv entry for given page and given pmap/va. > >> 1568 } >> >> If the tail end of the above function is changed as follows: >> >> 1565 pmap_remove_entry(pmap, m, va); >> 1565.5 return (pmap_unuse_pt(pmap, va, ptepde)); >> 1566 } >> 1567 return (0); >> >> Then we don't see any crashes ... but is it the right thing to do? > Should be not. Try to test this with some unmanaged mapping, like > /dev/mem pages mapped into the exiting process address space. > > I am too new to know about any nuances of the RELENG_6 code. The RELENG_6 code is doing essentially the same things as newer versions. Crashes in this specific place are usually caused by DRAM errors. Alan From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 17:19:18 2012 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 991B61065676 for ; Tue, 17 Apr 2012 17:19:18 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2853B8FC0C for ; Tue, 17 Apr 2012 17:19:17 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so6433087wgb.31 for ; Tue, 17 Apr 2012 10:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HkvWBGGsZ70p9+zaDU7Y5kUTZSZsd89nz0ihqLnPJDQ=; b=BNkSrjRybqnM94y8e6euplVMJBvJTwRkc48lpIAxoVKBjpZymNbbxWU9UkG1SOE7HZ 3jqgkd/kZf4G4tM59PxSqMSoWlFBH+g1lCAKgulSfTowOcd4m7t1iQ7YhUEgMfAfXQkI eh1mQaQy0CAzA+mG71RfgFu7Hdp9HSwIdqPcjxnQozcaAU325YOsDzqcpBFzhssk0UIJ nFAnmDqCvdj3G3/A60kFsepxTgI05u/oUb3yZwB7Dzn0QYGtru1k/MbKDeJYr8GiWJG1 sC1EKTOMdqY+uDM+C6BizEDyNHxesr6OFPqd7qqJZY8NYHwgVlXeKce/w49idIUg8Ou2 CNDg== MIME-Version: 1.0 Received: by 10.216.132.226 with SMTP id o76mr9748579wei.93.1334683156009; Tue, 17 Apr 2012 10:19:16 -0700 (PDT) Received: by 10.180.85.71 with HTTP; Tue, 17 Apr 2012 10:19:15 -0700 (PDT) Date: Tue, 17 Apr 2012 13:19:15 -0400 Message-ID: From: Ryan Stone To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PATCH] Implement DTrace "cpu" variable 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, 17 Apr 2012 17:19:18 -0000 Below I have a patch that implements the "cpu" variable in D, as documented here: https://wikis.oracle.com/display/DTrace/Variables#Variables-DTraceBuiltinVariables. I've implemented it as a new builtin variable that returns curcpu. This is different from how it works in OpenSolaris/Illumos -- in those, it's implemented by groping around in curthread. In FreeBSD there are some places deep in the scheduler where curthread->td_oncpu will be set to -1(in preparation for the thread being descheduled) so I prefer to go with an implementation that works in all cases, even if we diverge from upstream a little bit. If there are no objections I intend to commit this[rstone@rstone-laptop head]svn diff Index: cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c =================================================================== --- cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c (revision 234251) +++ cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c (working copy) @@ -497,6 +497,12 @@ { "zonename", DT_IDENT_SCALAR, 0, DIF_VAR_ZONENAME, DT_ATTR_STABCMN, DT_VERS_1_0, &dt_idops_type, "string" }, #endif + +#if !defined(sun) +{ "cpu", DT_IDENT_SCALAR, 0, DIF_VAR_CPU, + DT_ATTR_STABCMN, DT_VERS_1_6_3, &dt_idops_type, "int" }, +#endif + { NULL, 0, 0, 0, { 0, 0, 0 }, 0, NULL, NULL } }; Index: sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c (revision 234251) +++ sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c (working copy) @@ -3143,6 +3143,11 @@ return (curthread->td_errno); #endif } +#if !defined(sun) + case DIF_VAR_CPU: { + return curcpu; + } +#endif default: DTRACE_CPUFLAG_SET(CPU_DTRACE_ILLOP); return (0); Index: sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h (revision 234251) +++ sys/cddl/contrib/opensolaris/uts/common/sys/dtrace.h (working copy) @@ -251,6 +251,10 @@ #define DIF_VAR_ERRNO 0x0120 /* thread errno */ #define DIF_VAR_EXECARGS 0x0121 /* process arguments */ +#if !defined(sun) +#define DIF_VAR_CPU 0x0200 +#endif + #define DIF_SUBR_RAND 0 #define DIF_SUBR_MUTEX_OWNED 1 #define DIF_SUBR_MUTEX_OWNER 2 to head in the next few days. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 19:16:09 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56F55106566B; Tue, 17 Apr 2012 19:16:09 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 913588FC1E; Tue, 17 Apr 2012 19:16:08 +0000 (UTC) Received: by eaaf13 with SMTP id f13so1844878eaa.13 for ; Tue, 17 Apr 2012 12:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=Q1VuFzBSyYa1uZE5lARsbtqKW0ZghxjkX2QlEe5NLgI=; b=TZ7qB9V9F0+f0muI7n1jqwxRIzVhfFD3TA0YDbc6YpQR5tTYhhPtX3L5QFAqsHya93 7vqzeakmjjQPsa1z+6Xt81EQew/T+d5VyC2qQQUKa/LBCcQ887WHEl08W7bPDtH1O9y1 /SAgdefg44o3hnwp3O7BOeYfFuPc0hIDPuM+dPswdIzlUCuno0nNtEYaZu4TemmH3de2 Y8ecn+OVy7kjDSpemlsUCldjNZx4vvX7vp2sfCLf8XkwxXFtf23snoszTQJAKG3yzgcB c7p25xIRfZfgfBBQXAxJjPGe9cpZ5rJ94uD7x1oAUCv0kJdsJo1t0b1sa6c2dtyndrEk Gygw== Received: by 10.213.110.7 with SMTP id l7mr1275406ebp.7.1334690161570; Tue, 17 Apr 2012 12:16:01 -0700 (PDT) Received: from ernst.jennejohn.org (p578E3B06.dip.t-dialin.net. [87.142.59.6]) by mx.google.com with ESMTPS id d54sm106543825eei.9.2012.04.17.12.15.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Apr 2012 12:16:00 -0700 (PDT) Date: Tue, 17 Apr 2012 21:15:58 +0200 From: Gary Jennejohn To: Adrian Chadd Message-ID: <20120417211558.4793b705@ernst.jennejohn.org> In-Reply-To: References: <20120403193124.46ad9de9@ernst.jennejohn.org> <20120411192153.5672b62c@ernst.jennejohn.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-hackers , Jerry Toung Subject: Re: CAM disk I/O starvation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:16:09 -0000 On Mon, 16 Apr 2012 14:39:12 -0700 Adrian Chadd wrote: > On 11 April 2012 10:21, Gary Jennejohn wrote: > > > Just for the archive my bad disk performance seems to have been fixed in > > HEAD by svn commit r234074.  Seems that all interrupts were being handled > > by a single CPU/core (I have 6), which resulted in abysmal interrupt > > handling when mutltiple disks were busy. > > > > Since this commit my disk preformance is back to normal and long lags > > are a thing of the past. > > Hi, > > This is kind of worrying. You only have a few disks, a single core > SHOULD be able to handle all the interrupts for those disks whilst > leaving plenty of cycles to spare to drive the rest of your system. > And you have 5 other cores. > > Would you be willing to help out diagnose exactly why that particular > behaviour is causing you so much trouble? It almost sounds like > something in the IO path is blocking for far too long, not allowing > the rest of the system to move forward. That's very worrying for an > interrupt handler. :) > Yes, I agree completely. My first thought was that disk I/O scheduling had somehow been pessimized. But then I thought - wait a minute, I have disk caches enabled and command queuing is enabled for all of them, so that shouldn't really have any noticeable impact. So I was at a loss to explain why disk performance had suddenly gotten so bad. I'd be willing to spend some time on diagnosing it, but I have to come up with a scenario which would reliably reproduce the problem. AFAICR it generally happened when I was running csup/svn because my CVS repositoy is on one disk and /usr/{ports,src} are on a different one. I still have the old problem kernel around, but it's probably not instrumented for any meaningful diagnoses. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 19:30:15 2012 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 AB1DD106564A for ; Tue, 17 Apr 2012 19:30:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 791C08FC15 for ; Tue, 17 Apr 2012 19:30:15 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so8495688pbc.13 for ; Tue, 17 Apr 2012 12:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lvBWUk6qbY9MNmHPHHE4qmG28hM1xlkuJBWOF6XLBgU=; b=TJHNGbgn9JVH/4Hnmi/Tt4fnzpr9NwvBQN4a3OurzTjmis67FHF3DYtANZKoEmk6F2 opqvHsaAiFDcQ2OsR/dK7cXR59atY0Ha4YUynUcxaKC6wpru94vn6b3EWfz0DlK0xdc3 qgXPujbFpTGXDLUXD0DED8oKMKqYp20BdNUXnyRZdG84PxlYFQuVWtrBlmm55iBzWNUq ylF4gQ4NlQl6Kod4d49GXtomBS/xyFQs9HUstn8gPsK9OtroALoxwQrPswCTODgOey2Z ajS7cMp/25otQaE19AnC6iJK3FghDCw94Uw4rZw9/CoavITiVkIC0WhM56JvrIybr/mt OXlA== MIME-Version: 1.0 Received: by 10.68.225.132 with SMTP id rk4mr37431473pbc.157.1334691015211; Tue, 17 Apr 2012 12:30:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Tue, 17 Apr 2012 12:30:15 -0700 (PDT) In-Reply-To: <20120417211558.4793b705@ernst.jennejohn.org> References: <20120403193124.46ad9de9@ernst.jennejohn.org> <20120411192153.5672b62c@ernst.jennejohn.org> <20120417211558.4793b705@ernst.jennejohn.org> Date: Tue, 17 Apr 2012 12:30:15 -0700 X-Google-Sender-Auth: alSrn_PnJ8z4amImwK3AFFLX1OY Message-ID: From: Adrian Chadd To: gljennjohn@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers , Jerry Toung Subject: Re: CAM disk I/O starvation 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, 17 Apr 2012 19:30:15 -0000 On 17 April 2012 12:15, Gary Jennejohn wrote: > Yes, I agree completely. =A0My first thought was that disk I/O > scheduling had somehow been pessimized. =A0But then I thought - > wait a minute, I have disk caches enabled and command queuing is > enabled for all of them, so that shouldn't really have any > noticeable impact. =A0So I was at a loss to explain why disk performance > had suddenly gotten so bad. That's assuming there are no bugs anywhere. :) > I'd be willing to spend some time on diagnosing it, but I have to come > up with a scenario which would reliably reproduce the problem. =A0AFAICR > it generally happened when I was running csup/svn because my CVS > repositoy is on one disk and /usr/{ports,src} are on a different one. > > I still have the old problem kernel around, but it's probably not > instrumented for any meaningful diagnoses. Well do you know which version of which tree you used to build that? If it's head, you could "just" keep an earlier source tree around to build a kernel from. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 19:50:33 2012 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 B40891065672 for ; Tue, 17 Apr 2012 19:50:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 806D58FC08 for ; Tue, 17 Apr 2012 19:50:33 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q3HJoX1p026388; Tue, 17 Apr 2012 12:50:33 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q3HJoXh5026387; Tue, 17 Apr 2012 12:50:33 -0700 (PDT) (envelope-from david) Date: Tue, 17 Apr 2012 12:50:33 -0700 From: David Wolfskill To: Gary Jennejohn Message-ID: <20120417195033.GP1437@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Gary Jennejohn , freebsd-hackers References: <20120403193124.46ad9de9@ernst.jennejohn.org> <20120411192153.5672b62c@ernst.jennejohn.org> <20120417211558.4793b705@ernst.jennejohn.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YyxzkC/DtE3JUx8+" Content-Disposition: inline In-Reply-To: <20120417211558.4793b705@ernst.jennejohn.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers Subject: Re: CAM disk I/O starvation 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, 17 Apr 2012 19:50:33 -0000 --YyxzkC/DtE3JUx8+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2012 at 09:15:58PM +0200, Gary Jennejohn wrote: > ... > I still have the old problem kernel around, but it's probably not > instrumented for any meaningful diagnoses. > ... Several months ago, I was running a set of meaurements (to determine how performance for a certain task varied when I changed the hardware configuration of the machine in question). While it turned out that disk I/O was (surprisingly) not very significant, I did find that extending the mechanism I had been using to graph (aggregate) CPU utilization to graph the utilization of each core was enlightening. I don't know whether I can release the code or not -- I'll ask -- but the basic idea is to look at the CPU state counters (they are an ordered quintuple, for user, nice, system, interrupt, and idle) -- use the sysctl OIDs idle kern.cp_time for the aggregate of all CPUs; use idle kern.cp_times for an array of them, one quintuple per core. I graphed them using stacked barcharts; I used math/R to handle the graphing. Since CPU (or any other) utilization only makes sense over an interval, you also need to choose one; I used 10-second intervals by default. In any case, even under 7.1, I noticed that one of the cores got the vast bulk of the interrupt processing. (I also saw some of the cores go quite a bit more idle than others, which was fairly curious.) Anyway: the point of the above rambling is that it isn't necessary to actually "instrument" the kernel itself: the work I did was deliberately designed to be able to run on an unmodified FreeBSD system with no ports, packages, or other 3rd-party software installed except for lang/perl. I also tried comparing running under /usr/bin/time vs. running under my Perl script (which invokes /usr/bin/time to get the getrusage() info) several times, and found no statistically significant difference in resource usage -- even when I reduced the sampling interval down to 1/second. (A sufficiently motivated & talented individual could probably replace the Perl script with a shell script. As it is, the Perl script fork/execs a shell script to do the interval-sampling.) 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. --YyxzkC/DtE3JUx8+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+NyYgACgkQmprOCmdXAD3WCgCfaou9SVuzpqAczEeeqM6WmHnV 4E4AnjQLLW7rBhLsKE/g90SQdZagi6sQ =n2qL -----END PGP SIGNATURE----- --YyxzkC/DtE3JUx8+-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 20:22:30 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 575B8106566B; Tue, 17 Apr 2012 20:22:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3FA208FC1B; Tue, 17 Apr 2012 20:22:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA01638; Tue, 17 Apr 2012 23:22:21 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKEur-000IdG-1A; Tue, 17 Apr 2012 23:22:21 +0300 Message-ID: <4F8DD0FB.7000907@FreeBSD.org> Date: Tue, 17 Apr 2012 23:22:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> In-Reply-To: <201204160956.21148.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 17 Apr 2012 20:22:30 -0000 on 16/04/2012 16:56 John Baldwin said the following: > On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: >> on 14/04/2012 18:37 Andriy Gapon said the following: >>> >>> I would like to ask for a review and/or testing of the following three patches: >>> http://people.freebsd.org/~avg/zfsboot.patches.diff >>> >>> These patches add support for booting from an arbitrary filesystem of any >>> detected ZFS pool. A filesystem could be selected in zfsboot and thus will >>> affectfrom where zfsloader would be loaded. zfsboot passes information about >>> the boot pool and filesystem to zfsloader, which uses those for loaddev and >>> default value of currdev. A different pool+filesystem could be selected in >>> zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set >>> and is not derived from fstab, then it gets set to the selected boot filesystem. >> >> A note for prospective testers: the patched loader expect to be started by the >> patched zfs boot as it passes an additional parameter for a filesystem guid. >> I should probably add some way to distinguish between the older and newer zfs >> boot blocks. Maybe an extra bit in bootflags? What do you think? > > An extra bit (similar to existing flags for detecting PXE and CD booting) > sounds fine to me. (Note, I'm only replying to the question, have not looked > at patches yet). I hope that you will :-) We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments area is 32 bytes (as opposed to 24 previously). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 21:03:42 2012 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 BF9D2106564A; Tue, 17 Apr 2012 21:03:42 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5CABA8FC12; Tue, 17 Apr 2012 21:03:42 +0000 (UTC) Received: by vbmv11 with SMTP id v11so6251792vbm.13 for ; Tue, 17 Apr 2012 14:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Qiby/B2a3/ZpPS9FAvcyDRx+DvSa3GMx4qMbTDUQjXs=; b=gfpvl6LZVt0jl/VrpnrXnQqJDTiPLGdTdyPmF5c0dmvAIoTYIi1zcy5ffoLMiOVpSD FPdb6nZI1DpJ/S/LfGfZEpQd1T5Kk+AuvBxgM27BSQuAKtJCOpfanswtT12sspxveVaU YOdzUO70Gv/U71hJXwDCiOIa8qiYOpkDyFYj9GKW1yo40o5L5n3Il+gG7gYpmFQil/Zw 3fY2esKuEmfLJ5YUhfwzLR/OfNinAgiRfzF+1M7K6MTI3e+T6uAaweYYo5pf2HPNtOX/ RhVPBYspJycvYWvoQaPN3eNwCmX/46uQxnfmMTm8v+Hpc+LgzxRwu9/dajN8235mesiZ yCLw== MIME-Version: 1.0 Received: by 10.220.155.197 with SMTP id t5mr9744359vcw.6.1334696621848; Tue, 17 Apr 2012 14:03:41 -0700 (PDT) Received: by 10.52.185.167 with HTTP; Tue, 17 Apr 2012 14:03:41 -0700 (PDT) Date: Tue, 17 Apr 2012 17:03:41 -0400 Message-ID: From: Matthew Story To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: gabor@freebsd.org Subject: Status of BSD Diff replacement? 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, 17 Apr 2012 21:03:42 -0000 Just wondering what the current status is on a BSD diff replacement. The IdeasPage suggests that a goodly amount of work was done on this for GSoC 2010 (http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but the GPLinBase page says it's unowned and suggests replacement with OpenBSD diff (http://wiki.freebsd.org/GPLinBase). Wondering how much is outstanding on this, and where to start reading to catch up on what's been done? -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 21:28:55 2012 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 764AD1065672; Tue, 17 Apr 2012 21:28:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA078FC1B; Tue, 17 Apr 2012 21:28:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B323AB958; Tue, 17 Apr 2012 17:28:54 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Tue, 17 Apr 2012 16:43:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> <4F8DD0FB.7000907@FreeBSD.org> In-Reply-To: <4F8DD0FB.7000907@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204171643.39447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Apr 2012 17:28:54 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 17 Apr 2012 21:28:55 -0000 On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > on 16/04/2012 16:56 John Baldwin said the following: > > On Saturday, April 14, 2012 1:35:35 pm Andriy Gapon wrote: > >> on 14/04/2012 18:37 Andriy Gapon said the following: > >>> > >>> I would like to ask for a review and/or testing of the following three patches: > >>> http://people.freebsd.org/~avg/zfsboot.patches.diff > >>> > >>> These patches add support for booting from an arbitrary filesystem of any > >>> detected ZFS pool. A filesystem could be selected in zfsboot and thus will > >>> affectfrom where zfsloader would be loaded. zfsboot passes information about > >>> the boot pool and filesystem to zfsloader, which uses those for loaddev and > >>> default value of currdev. A different pool+filesystem could be selected in > >>> zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > >>> and is not derived from fstab, then it gets set to the selected boot filesystem. > >> > >> A note for prospective testers: the patched loader expect to be started by the > >> patched zfs boot as it passes an additional parameter for a filesystem guid. > >> I should probably add some way to distinguish between the older and newer zfs > >> boot blocks. Maybe an extra bit in bootflags? What do you think? > > > > An extra bit (similar to existing flags for detecting PXE and CD booting) > > sounds fine to me. (Note, I'm only replying to the question, have not looked > > at patches yet). > > I hope that you will :-) > > We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > area is 32 bytes (as opposed to 24 previously). Does KARGS_FLAGS_GUID work? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 23:49:19 2012 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 8293D106564A for ; Tue, 17 Apr 2012 23:49:19 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 3417C8FC0A for ; Tue, 17 Apr 2012 23:49:19 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 4748E14E735E; Wed, 18 Apr 2012 01:49:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OxJ4xHSawSb8; Wed, 18 Apr 2012 01:49:10 +0200 (CEST) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id E517514E7304; Wed, 18 Apr 2012 01:49:08 +0200 (CEST) Message-ID: <4F8E0163.9030009@FreeBSD.org> Date: Wed, 18 Apr 2012 01:48:51 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120328 Thunderbird/13.0a2 MIME-Version: 1.0 To: Matthew Story References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfiedler@asu.edu, freebsd-hackers@freebsd.org Subject: Re: Status of BSD Diff replacement? 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, 17 Apr 2012 23:49:19 -0000 On 2012.04.17. 23:03, Matthew Story wrote: > Just wondering what the current status is on a BSD diff replacement. > The IdeasPage suggests that a goodly amount of work was done on this > for GSoC 2010 > (http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but > the GPLinBase page says it's unowned and suggests replacement with > OpenBSD diff (http://wiki.freebsd.org/GPLinBase). Unless OpenBSD folks have changed or developed something, our incomplete BSD diff is OpenBSD diff + improvements. > > Wondering how much is outstanding on this, and where to start reading > to catch up on what's been done? I worked a bit on that in 2008 along with grep and sort but these got more priorities so lots of features are still missing. Then Ben Fiedler also worked on it in 2010 but I don't exactly know what he accomplished and whether he took my code or chose another way. So for someone who wants to work on it, first it should be checked what's done, maybe merge my version and Ben's version, check whether OpenBSD added something new or fixed somethings and then implement missing features and do lots of testing to ensure compatibility with GNU diff. And performance tests and improvements if necessary. I work on grep/regex related things and recently Oleg Moskalenko took over my incomplete BSD sort code but noone is working on BSD diff so any contribution is very welcome. Gabor From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 02:01:08 2012 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 E7761106566C for ; Wed, 18 Apr 2012 02:01:08 +0000 (UTC) (envelope-from bfiedler@asu.edu) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id B54628FC0C for ; Wed, 18 Apr 2012 02:01:08 +0000 (UTC) Received: by dadz14 with SMTP id z14so30097631dad.17 for ; Tue, 17 Apr 2012 19:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NA3kYp7+tlhvmZgJHoGsOFHaZfa9RE21ktV9qk+kmmk=; b=BKYZqIH96EX7x1eKLpnQNSkUa8RfYRgL2jqcHhiZDxdpa3Ti7rpj4RVptb6kbz8H7Z +FBKP8wWgLu1b47vcYBe/o+x+XE5O60/WqJujl44scQfOk2YdDhOLM91sAeI0Y6zXVxA /TPhcR/iVRN22zKcNQkK3L7bHzhW8X0jNibx28M368VOtLo6nGxDOYVzBtzzZUlXj89t QpblRtWXYfPwtiJikkG9JlMMQcdQE5xLj2ATtwBDR6Hv1jitRb+Ul4F6gkhBqwggDpnZ TZFSQZNcABQVAvsFNqpg/VJviH/tdez10ByE73TiHka+y9BxfnQYz+yTpNP9t2DU7nG3 dkxA== MIME-Version: 1.0 Received: by 10.68.189.167 with SMTP id gj7mr1995910pbc.99.1334714468343; Tue, 17 Apr 2012 19:01:08 -0700 (PDT) Received: by 10.68.71.163 with HTTP; Tue, 17 Apr 2012 19:01:08 -0700 (PDT) In-Reply-To: <4F8E0163.9030009@FreeBSD.org> References: <4F8E0163.9030009@FreeBSD.org> Date: Tue, 17 Apr 2012 19:01:08 -0700 Message-ID: From: Ben Fiedler To: Gabor Kovesdan X-Gm-Message-State: ALoCoQneDElIKXKQcrBmh0BecWq1KXXjA/4bEv/fdhEwcLuF0ipTGzTZa/yHNFN6pLkjBSSNCrVQ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Matthew Story , freebsd-hackers@freebsd.org Subject: Re: Status of BSD Diff replacement? 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, 18 Apr 2012 02:01:09 -0000 Gabor, I made a branch off of your perforce diff code in my work on the diff tool: >From my understanding you started those modifications from OpenBSD's diff in 2008, so Matthew's assertion that "our incomplete BSD diff is OpenBSD diff + improvements" is 100% correct. I also ported and started work on sdiff and diff3 from OpenBSD, but made minimal headway on each. The red items on the table here lists the needed argument support to match GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff Though there's only a few left, they are not trivial by any means. -Ben On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan wrote: > On 2012.04.17. 23:03, Matthew Story wrote: > >> Just wondering what the current status is on a BSD diff replacement. The >> IdeasPage suggests that a goodly amount of work was done on this for GSoC >> 2010 (http://wiki.freebsd.org/**IdeasPage#BSD-licensed_Text-** >> Processing_Tools), >> but the GPLinBase page says it's unowned and suggests replacement with >> OpenBSD diff (http://wiki.freebsd.org/**GPLinBase >> ). >> > Unless OpenBSD folks have changed or developed something, our incomplete > BSD diff is OpenBSD diff + improvements. > >> >> Wondering how much is outstanding on this, and where to start reading to >> catch up on what's been done? >> > > I worked a bit on that in 2008 along with grep and sort but these got more > priorities so lots of features are still missing. Then Ben Fiedler also > worked on it in 2010 but I don't exactly know what he accomplished and > whether he took my code or chose another way. So for someone who wants to > work on it, first it should be checked what's done, maybe merge my version > and Ben's version, check whether OpenBSD added something new or fixed > somethings and then implement missing features and do lots of testing to > ensure compatibility with GNU diff. And performance tests and improvements > if necessary. > > I work on grep/regex related things and recently Oleg Moskalenko took over > my incomplete BSD sort code but noone is working on BSD diff so any > contribution is very welcome. > > Gabor > From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 03:30:55 2012 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 D92841065673; Wed, 18 Apr 2012 03:30:55 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A25C8FC0C; Wed, 18 Apr 2012 03:30:55 +0000 (UTC) Received: by qcsg15 with SMTP id g15so5100308qcs.13 for ; Tue, 17 Apr 2012 20:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4azJZLfWoa0wnWxX6i3/fl6HqYbnItJE9NBc5gC2ktE=; b=x9gKqD4QLf5F3Yw2OvgUi15x3vhE+Vv9YbGiLF+GCX1bTRoD7HgUri24VeSp8jwD30 zeb0zGx4lxA6pPWrI43vILdI2EdL3CgFwuTGFm3ONrOhvi3F7FQ1O4fX7VPgXX2EUSO/ MRvOfbthpnWeW/AwhrOvpbslpmkrjOIFXMDXmwzez04R6q9Ij9zNUvGkVVhThXqPxJNq tndTmziN4bOFpdOSebRZ211rQ8f00KhB91bkbBFo+0ROjqr52n9nGq+PWxjJxtWKWlDS 8h51Z1vphm6gY/oMSFBjbfww8HqdxWQo6KPOc9FsnKqSuUbgZZ6F2b4QKuvz1HTFsrrz moFA== MIME-Version: 1.0 Received: by 10.229.106.193 with SMTP id y1mr241095qco.73.1334719849136; Tue, 17 Apr 2012 20:30:49 -0700 (PDT) Received: by 10.229.96.205 with HTTP; Tue, 17 Apr 2012 20:30:48 -0700 (PDT) In-Reply-To: References: <4F8E0163.9030009@FreeBSD.org> Date: Tue, 17 Apr 2012 23:30:48 -0400 Message-ID: From: Matthew Story To: Ben Fiedler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Gabor Kovesdan Subject: Re: Status of BSD Diff replacement? 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, 18 Apr 2012 03:30:55 -0000 On Tue, Apr 17, 2012 at 10:01 PM, Ben Fiedler wrote: > Gabor, > > I made a branch off of your perforce diff code in my work on the diff > tool: From my understanding you started those modifications from OpenBSD's > diff in 2008, so Matthew's assertion that "our incomplete BSD diff is > OpenBSD diff + improvements" is 100% correct. I also ported and started > work on sdiff and diff3 from OpenBSD, but made minimal headway on each. > > The red items on the table here lists the needed argument support to match > GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff Awesome, thanks for that link. > > > Though there's only a few left, they are not trivial by any means. > > -Ben > > > > On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan wrote: > >> On 2012.04.17. 23:03, Matthew Story wrote: >> >>> Just wondering what the current status is on a BSD diff replacement. >>> The IdeasPage suggests that a goodly amount of work was done on this for >>> GSoC 2010 (http://wiki.freebsd.org/**IdeasPage#BSD-licensed_Text-** >>> Processing_Tools), >>> but the GPLinBase page says it's unowned and suggests replacement with >>> OpenBSD diff (http://wiki.freebsd.org/**GPLinBase >>> ). >>> >> Unless OpenBSD folks have changed or developed something, our incomplete >> BSD diff is OpenBSD diff + improvements. >> >>> >>> Wondering how much is outstanding on this, and where to start reading to >>> catch up on what's been done? >>> >> >> I worked a bit on that in 2008 along with grep and sort but these got >> more priorities so lots of features are still missing. Then Ben Fiedler >> also worked on it in 2010 but I don't exactly know what he accomplished and >> whether he took my code or chose another way. So for someone who wants to >> work on it, first it should be checked what's done, maybe merge my version >> and Ben's version, > > just to verify, these are the correct 2 branches to look at: http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2008/&c=iZC@//depot/projects/soc2008/gabor_textproc/?ac=83 http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2010/&c=QTP@//depot/projects/soc2010/bsdtextproc/?ac=83 it looks like gabor_diff in soc2010 is based off the soc2008 work. Is there anyway either of you could provide me with an archive of the working tree for these 2 perforce repos? or make it available in a branch on svn.freebsd.org? I'd like to look into this more, but after reading through the P4Web docs, trying to gain anonymous read-only access through p4 itself, and then reading: http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.html it seems there's no real way to accommodate this sort of thing at current. > check whether OpenBSD added something new or fixed somethings and then >> implement missing features and do lots of testing to ensure compatibility >> with GNU diff. And performance tests and improvements if necessary. >> > Since 2008/2010 the OpenBSD change logs referencing diff(1) sdiff(1) and diff(3) are: 4.9 Use scandir(3) instead of getdirentries(2) in diff(1). Call to getdirentries(2) should be avoided outside of libc 4.8 Many diff(1) improvements. Make diff(1) return 2 on error. 4.6 Fix file descriptor leaks in sdiff(1) when diffing regular files. I think the many diff(1) improvements is when ray started maintaining diff (not millert), so perhaps I can ping him as well if I make any headway on this. > >> I work on grep/regex related things and recently Oleg Moskalenko took >> over my incomplete BSD sort code but noone is working on BSD diff so any >> contribution is very welcome. > > >> >> Gabor >> > > -- regards, matt From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 06:02:25 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3DC02106566C; Wed, 18 Apr 2012 06:02:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2038C8FC08; Wed, 18 Apr 2012 06:02:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA07262; Wed, 18 Apr 2012 09:02:22 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKNyA-000Lme-Iz; Wed, 18 Apr 2012 09:02:22 +0300 Message-ID: <4F8E58EE.8080909@FreeBSD.org> Date: Wed, 18 Apr 2012 09:02:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <201204160956.21148.jhb@freebsd.org> <4F8DD0FB.7000907@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> In-Reply-To: <201204171643.39447.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 06:02:25 -0000 on 17/04/2012 23:43 John Baldwin said the following: > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments >> area is 32 bytes (as opposed to 24 previously). > > Does KARGS_FLAGS_GUID work? > I think that's too terse, we already passed a pool guid via the existing argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 08:57:51 2012 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 DDE73106566C; Wed, 18 Apr 2012 08:57:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 042928FC14; Wed, 18 Apr 2012 08:57:50 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA08986; Wed, 18 Apr 2012 11:57:49 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKQhx-000Lz9-82; Wed, 18 Apr 2012 11:57:49 +0300 Message-ID: <4F8E820B.6080400@FreeBSD.org> Date: Wed, 18 Apr 2012 11:57:47 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-fs@FreeBSD.org References: <4F8999D2.1080902@FreeBSD.org> In-Reply-To: <4F8999D2.1080902@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit Cc: Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 08:57:52 -0000 on 14/04/2012 18:37 Andriy Gapon said the following: > > I would like to ask for a review and/or testing of the following three patches: > http://people.freebsd.org/~avg/zfsboot.patches.diff I've put a new version of the patch here: http://people.freebsd.org/~avg/zfsboot.patches.2.diff Most prominent changes: - new zfsloader should be compatible with previous zfsboot - libi386 unconditionally includes zfs support via use of weak symbols for some functions Unfortunately, unconditional compatibility between i386_devdesc and zfs_devdesc means that i386_devdesc becomes much larger (> 512 bytes). But I think that it shouldn't cause any real problems. > These patches add support for booting from an arbitrary filesystem of any > detected ZFS pool. A filesystem could be selected in zfsboot and thus will > affectfrom where zfsloader would be loaded. zfsboot passes information about > the boot pool and filesystem to zfsloader, which uses those for loaddev and > default value of currdev. A different pool+filesystem could be selected in > zfsloader for booting kernel. Also if vfs.root.mountfrom is not explicitly set > and is not derived from fstab, then it gets set to the selected boot filesystem. > > This should could be used as a foundation for the support of Solaris-like boot > environment selection. I believe that other people have already developed > scripts utilizing ZFS capabilities to provide other aspects of management of > boot environments. > > I am particularly interested in reviews of my attempt to make ZFS boot support > arch-independent. The arches, of course, would have to add some code to make > use of that support. Currently I only enabled it for x86. > > Thank you very much! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 09:09:10 2012 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 B1D641065670 for ; Wed, 18 Apr 2012 09:09:10 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 627A68FC15 for ; Wed, 18 Apr 2012 09:09:10 +0000 (UTC) Received: by vcmm1 with SMTP id m1so6567188vcm.13 for ; Wed, 18 Apr 2012 02:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=298CC/jXWF6FJkD6ueo7KUXcEkKvn0VZpyhdT/phuEQ=; b=IvqfBaJSgl+dNagYBdjzsyebPgCB2tFMJV5miRC9iCjRWJgO8U0RK7tYjy3V9pUJyd Brwgx5ng0JZEPSxX9wr+gQUnvdCK7hfpsl4rUSkrQyu2sjkzybbP7y18V+ur52J31/Bj udAo6+vbts+b7e06HKZadvfmj2G9GXhck8VYTTlc12VvZadSfiQGX5OyWY3QUwDUjFPE J+VrKdlj90ozPQnquWnl1Q4oKpbrFPJeY5L2XISmueV2FTxrE/Y/cHIlQXNy5ohKSTc3 3kLUPFrlVmZuIPuAZeHEvmuIFXFQOrbpelXXXUVyZOurygPuF1wimc2C1zTpvyBk4AjA c5jQ== MIME-Version: 1.0 Received: by 10.52.95.198 with SMTP id dm6mr601883vdb.91.1334740149461; Wed, 18 Apr 2012 02:09:09 -0700 (PDT) Received: by 10.52.181.129 with HTTP; Wed, 18 Apr 2012 02:09:09 -0700 (PDT) In-Reply-To: References: <4F8E0163.9030009@FreeBSD.org> Date: Wed, 18 Apr 2012 10:09:09 +0100 Message-ID: From: Tom Evans To: Matthew Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: Status of BSD Diff replacement? 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, 18 Apr 2012 09:09:10 -0000 On Wed, Apr 18, 2012 at 4:30 AM, Matthew Story wro= te: > Is there anyway either of you could provide me with an archive of the > working tree for these 2 perforce repos? =C2=A0or make it available in a = branch > on svn.freebsd.org? =C2=A0I'd like to look into this more, but after read= ing > through the P4Web docs, trying to gain anonymous read-only access through > p4 itself, and then reading: > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.h= tml > > it seems there's no real way to accommodate this sort of thing at current= . > Hi Matt About 5 years ago I wrote a ruby script for extracting a branch from p4web. It worked then, but I've not looked at it since=E2=80=A6 some people found it useful for getting the latest WIP version of Ben's wpi(4) driver from perforce, so there is a copy preserved on Ben's website: http://www.clearchain.com/downloads/FreeBSD/P4fetch.rb Cheers Tom From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 09:19:09 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE8561065708; Wed, 18 Apr 2012 09:19:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E58008FC16; Wed, 18 Apr 2012 09:19:08 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA09311; Wed, 18 Apr 2012 12:19:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKR2U-000M11-N6; Wed, 18 Apr 2012 12:19:02 +0300 Message-ID: <4F8E8705.4080804@FreeBSD.org> Date: Wed, 18 Apr 2012 12:19:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Bob Friesenhahn References: <4F8999D2.1080902@FreeBSD.org> <4F89B567.6090008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 09:19:09 -0000 on 15/04/2012 04:01 Bob Friesenhahn said the following: > It would be nice if the updated FreeBSD bootloader could have the ability to > boot both Solaris and FreeBSD root filesystems in the same pool so that one > could switch between several zfs-based operating systems without needing to use > a different partition for each one. Is this within the bounds of possibility or > a totally irrational thought? I can not assess feasibility of such a project. Just want to note that ultimately it's the code that gets booted, not filesystems. I have an impression that Solaris boot archive is quite different from how FreeBSD kernel gets booted. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 10:36:31 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2B7721065811 for ; Wed, 18 Apr 2012 10:36:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 14D838FC1B for ; Wed, 18 Apr 2012 10:36:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA10235 for ; Wed, 18 Apr 2012 13:36:28 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKSFQ-000M6M-8Z for freebsd-hackers@FreeBSD.org; Wed, 18 Apr 2012 13:36:28 +0300 Message-ID: <4F8E992A.2090705@FreeBSD.org> Date: Wed, 18 Apr 2012 13:36:26 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: weak symbols vs archive libraries 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, 18 Apr 2012 10:36:31 -0000 I just would like to share something that I stumbled upon. Maybe this is something well known, then forgive me for the noise. When ld combines multiple object files it overrides weak symbol definitions with a strong definition (if any). There are many examples/demonstrations on the Internet on how this works, e.g.: http://winfred-lu.blogspot.com/2009/11/understand-weak-symbols-by-examples.html But when the object files are spread across multiple archives, the there could be some surprises. My understanding is that there are two big rules that linker follows with respect to archive libraries: - linker extracts an object file from a library only if according to a symbol table of the library the object file contains some interesting symbols - if linker extracts an object file then it processes all symbols in it And now the following observation: if linker has already seen a weak definition for a symbol, then it will not actively seek any other definitions for it. But it will take into account the definitions that it stumbles upon. For example, if an object file in an archive library contains only (strong) definitions for some symbols that already have weak definitions, the linker will not extract that object file and will not look into it. And thus the weak definition will not be overridden. OTOH, if that object file contains a definition for at least one still undefined symbol, then the file will be interesting to linker, it will extract the file, process _all_ symbols in it and thus will override the weak definitions with the strong ones. This is something that was unexpected to me. Some references: http://webpages.charter.net/ppluzhnikov/linker.html http://glandium.org/blog/?p=2388 -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 10:50:03 2012 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 A04B31065677; Wed, 18 Apr 2012 10:50:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1888E8FC16; Wed, 18 Apr 2012 10:50:02 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3IAntkT095361; Wed, 18 Apr 2012 13:49:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3IAntBL098721; Wed, 18 Apr 2012 13:49:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3IAntkS098720; Wed, 18 Apr 2012 13:49:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Apr 2012 13:49:55 +0300 From: Konstantin Belousov To: Andriy Gapon Message-ID: <20120418104955.GV2358@deviant.kiev.zoral.com.ua> References: <4F8E992A.2090705@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bvzltMstmN4o5fnw" Content-Disposition: inline In-Reply-To: <4F8E992A.2090705@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: freebsd-hackers@freebsd.org Subject: Re: weak symbols vs archive libraries 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, 18 Apr 2012 10:50:03 -0000 --bvzltMstmN4o5fnw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 01:36:26PM +0300, Andriy Gapon wrote: >=20 > I just would like to share something that I stumbled upon. > Maybe this is something well known, then forgive me for the noise. >=20 > When ld combines multiple object files it overrides weak symbol definitio= ns with > a strong definition (if any). There are many examples/demonstrations on = the > Internet on how this works, e.g.: > http://winfred-lu.blogspot.com/2009/11/understand-weak-symbols-by-example= s.html >=20 > But when the object files are spread across multiple archives, the there = could > be some surprises. > My understanding is that there are two big rules that linker follows with > respect to archive libraries: > - linker extracts an object file from a library only if according to a sy= mbol > table of the library the object file contains some interesting symbols > - if linker extracts an object file then it processes all symbols in it >=20 > And now the following observation: if linker has already seen a weak defi= nition > for a symbol, then it will not actively seek any other definitions for it= . But > it will take into account the definitions that it stumbles upon. > For example, if an object file in an archive library contains only (stron= g) > definitions for some symbols that already have weak definitions, the link= er will > not extract that object file and will not look into it. And thus the weak > definition will not be overridden. OTOH, if that object file contains a > definition for at least one still undefined symbol, then the file will be > interesting to linker, it will extract the file, process _all_ symbols in= it and > thus will override the weak definitions with the strong ones. >=20 > This is something that was unexpected to me. >=20 > Some references: > http://webpages.charter.net/ppluzhnikov/linker.html > http://glandium.org/blog/?p=3D2388 This is from the ELF standard version 1.2 PDF, page 1-5: When the link editor searches archive libraries, it extracts archive members that contain definitions of undefined global symbols. The member's definition may be either a global or a weak symbol. The link editor does not extract archive members to resolve undefined weak symbols. Unresolved weak symbols have a zero value. --bvzltMstmN4o5fnw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+OnFMACgkQC3+MBN1Mb4gR9gCfWKSt7zwtmutep4JKV15Tv0F0 xEMAoIaOLawLAjA1k4N5Dsbc4fVRwQPg =CCfN -----END PGP SIGNATURE----- --bvzltMstmN4o5fnw-- From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 11:16:29 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D10C9106566C for ; Wed, 18 Apr 2012 11:16:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 27A7B8FC0C for ; Wed, 18 Apr 2012 11:16:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA10737; Wed, 18 Apr 2012 14:16:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SKSs6-000M9k-Ez; Wed, 18 Apr 2012 14:16:26 +0300 Message-ID: <4F8EA289.1050000@FreeBSD.org> Date: Wed, 18 Apr 2012 14:16:25 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120317 Thunderbird/10.0.3 MIME-Version: 1.0 To: Konstantin Belousov References: <4F8E992A.2090705@FreeBSD.org> <20120418104955.GV2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120418104955.GV2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: weak symbols vs archive libraries 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, 18 Apr 2012 11:16:29 -0000 on 18/04/2012 13:49 Konstantin Belousov said the following: > This is from the ELF standard version 1.2 PDF, page 1-5: > > When the link editor searches archive libraries, it extracts archive > members that contain definitions of undefined global symbols. The member's > definition may be either a global or a weak symbol. The link editor does > not extract archive members to resolve undefined weak symbols. Unresolved > weak symbols have a zero value. I'll just add to this, in case it's not already very obvious, that the link editor does not extract archive members to find strong definitions for defined weak symbols too. Thank you for the quote! -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 13:54:55 2012 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 58476106567C; Wed, 18 Apr 2012 13:54:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2628FC15; Wed, 18 Apr 2012 13:54:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 8E27FB95E; Wed, 18 Apr 2012 09:54:54 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 18 Apr 2012 09:41:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> In-Reply-To: <4F8E58EE.8080909@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204180941.24699.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Apr 2012 09:54:54 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 13:54:55 -0000 On Wednesday, April 18, 2012 2:02:22 am Andriy Gapon wrote: > on 17/04/2012 23:43 John Baldwin said the following: > > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > >> area is 32 bytes (as opposed to 24 previously). > > > > Does KARGS_FLAGS_GUID work? > > > > I think that's too terse, we already passed a pool guid via the existing > argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or > KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). Ah. I do think the flag should indicate that the bootinfo structure is larger, I was assuming you were adding a new GUID field that didn't exist before. I can't think of something better than KARGS_FLAGS_32. What might be nice actually, is to add a new field to indicate the size of the argument area and to set a flag to indicate that the size field is present (KARGS_FLAGS_SIZE)? Hmm, looks like we should name this structure and move it and the relevant KARGS_FLAGS_* fields into a header while we are at it? -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 14:22:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D8481065673 for ; Wed, 18 Apr 2012 14:22:33 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7298FC19 for ; Wed, 18 Apr 2012 14:22:33 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta07.emeryville.ca.mail.comcast.net with comcast id zSD31i0021eYJf8A7SNT7d; Wed, 18 Apr 2012 14:22:27 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id zSNR1i0124NgCEG01SNS31; Wed, 18 Apr 2012 14:22:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEMOxp066955; Wed, 18 Apr 2012 08:22:24 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201204180941.24699.jhb@freebsd.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:22:23 -0600 Message-ID: <1334758943.1082.242.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 14:22:33 -0000 On Wed, 2012-04-18 at 09:41 -0400, John Baldwin wrote: > On Wednesday, April 18, 2012 2:02:22 am Andriy Gapon wrote: > > on 17/04/2012 23:43 John Baldwin said the following: > > > On Tuesday, April 17, 2012 4:22:19 pm Andriy Gapon wrote: > > >> We already have a flag for ZFS (KARGS_FLAGS_ZFS, 0x4). So the new flag could be > > >> named something ZFS-specific (as silly as KARGS_FLAGS_ZFS2) or something more > > >> general such as KARGS_FLAGS_32_BYTES meaning that the total size of arguments > > >> area is 32 bytes (as opposed to 24 previously). > > > > > > Does KARGS_FLAGS_GUID work? > > > > > > > I think that's too terse, we already passed a pool guid via the existing > > argument space. So it should be something like KARGS_FLAGS_ZFS_FS_GUID or > > KARGS_FLAGS_ZFS_DS_GUID (DS - dataset). > > Ah. I do think the flag should indicate that the bootinfo structure is larger, > I was assuming you were adding a new GUID field that didn't exist before. > I can't think of something better than KARGS_FLAGS_32. What might be nice > actually, is to add a new field to indicate the size of the argument area and > to set a flag to indicate that the size field is present (KARGS_FLAGS_SIZE)? YES! A size field (preferably as the first field in the struct) along with a flag to indicate that it's a new-style boot info struct that starts with a size field, will allow future changes without a lot of drama. It can allow code that has to deal with the struct without interpretting it (such as trampoline code that has to copy it to a new stack or memory area as part of loading the kernel) to be immune to future changes. This probably isn't a big deal in the x86 world, but it can be important for embedded systems where a proprietary bootloader has to pass info to a proprietary board_init() type routine in the kernel using non-proprietary loader/trampoline code that's part of the base. We have a bit of a mess in this regard in the ARM world right now, and it would be a lot lessy messy if something like this had been in place. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 14:37:04 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FECF1065670; Wed, 18 Apr 2012 14:37:04 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 650138FC18; Wed, 18 Apr 2012 14:37:03 +0000 (UTC) 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 RAA12963; Wed, 18 Apr 2012 17:36:56 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F8ED187.9030108@FreeBSD.org> Date: Wed, 18 Apr 2012 17:36:55 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Ian Lepore References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> In-Reply-To: <1334758943.1082.242.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 14:37:04 -0000 on 18/04/2012 17:22 Ian Lepore said the following: > YES! A size field (preferably as the first field in the struct) along > with a flag to indicate that it's a new-style boot info struct that > starts with a size field, will allow future changes without a lot of > drama. It can allow code that has to deal with the struct without > interpretting it (such as trampoline code that has to copy it to a new > stack or memory area as part of loading the kernel) to be immune to > future changes. Yeah, placing the new field at front would immediately break compatibility and even access to the flags field :-) -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 14:40:16 2012 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 4F4C6106564A for ; Wed, 18 Apr 2012 14:40:16 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2D78E8FC1C for ; Wed, 18 Apr 2012 14:40:16 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta14.emeryville.ca.mail.comcast.net with comcast id zSfZ1i0021GXsucAESgAlj; Wed, 18 Apr 2012 14:40:10 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id zSg91i01f4NgCEG8USgA5r; Wed, 18 Apr 2012 14:40:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEe7WJ066972; Wed, 18 Apr 2012 08:40:07 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Andriy Gapon In-Reply-To: <4F8ED187.9030108@FreeBSD.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:40:07 -0600 Message-ID: <1334760007.1082.243.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 14:40:16 -0000 On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > on 18/04/2012 17:22 Ian Lepore said the following: > > YES! A size field (preferably as the first field in the struct) along > > with a flag to indicate that it's a new-style boot info struct that > > starts with a size field, will allow future changes without a lot of > > drama. It can allow code that has to deal with the struct without > > interpretting it (such as trampoline code that has to copy it to a new > > stack or memory area as part of loading the kernel) to be immune to > > future changes. > > Yeah, placing the new field at front would immediately break compatibility and > even access to the flags field :-) > Code would only assume the new field was at the front of the struct if the new flag is set, otherwise it would use the historical struct layout. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 14:41:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E4AD1065676 for ; Wed, 18 Apr 2012 14:41:38 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5548FC12 for ; Wed, 18 Apr 2012 14:41:38 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta06.emeryville.ca.mail.comcast.net with comcast id zSNf1i0050lTkoCA6ShYJ8; Wed, 18 Apr 2012 14:41:32 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta04.emeryville.ca.mail.comcast.net with comcast id zShX1i00q4NgCEG8QShY42; Wed, 18 Apr 2012 14:41:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEfTIg066978 for ; Wed, 18 Apr 2012 08:41:29 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-hackers@freebsd.org In-Reply-To: <4F8ED187.9030108@FreeBSD.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:41:29 -0600 Message-ID: <1334760089.1082.245.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 14:41:38 -0000 On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > on 18/04/2012 17:22 Ian Lepore said the following: > > YES! A size field (preferably as the first field in the struct) along > > with a flag to indicate that it's a new-style boot info struct that > > starts with a size field, will allow future changes without a lot of > > drama. It can allow code that has to deal with the struct without > > interpretting it (such as trampoline code that has to copy it to a new > > stack or memory area as part of loading the kernel) to be immune to > > future changes. > > Yeah, placing the new field at front would immediately break compatibility and > even access to the flags field :-) > Oh wait, is the flags field embedded in the struct? My bad, I didn't look. In the ARM code I'm used to working with, the flags are passed from the bootloader to the kernel entry point in a register; I don't know why assumed that would be true on other platforms. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 15:00:25 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 216E71065748; Wed, 18 Apr 2012 15:00:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 087F38FC16; Wed, 18 Apr 2012 15:00:23 +0000 (UTC) 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 SAA13173; Wed, 18 Apr 2012 18:00:19 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F8ED702.4020803@FreeBSD.org> Date: Wed, 18 Apr 2012 18:00:18 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Ian Lepore References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> <1334760007.1082.243.camel@revolution.hippie.lan> In-Reply-To: <1334760007.1082.243.camel@revolution.hippie.lan> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 15:00:25 -0000 on 18/04/2012 17:40 Ian Lepore said the following: > On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: >> on 18/04/2012 17:22 Ian Lepore said the following: >>> YES! A size field (preferably as the first field in the struct) along >>> with a flag to indicate that it's a new-style boot info struct that >>> starts with a size field, will allow future changes without a lot of >>> drama. It can allow code that has to deal with the struct without >>> interpretting it (such as trampoline code that has to copy it to a new >>> stack or memory area as part of loading the kernel) to be immune to >>> future changes. >> >> Yeah, placing the new field at front would immediately break compatibility and >> even access to the flags field :-) >> > > Code would only assume the new field was at the front of the struct if > the new flag is set, otherwise it would use the historical struct > layout. Right, but where the flag would reside? And how the older code that is not aware of the new flag would cope with the new layout? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 16:39:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56D231065673; Wed, 18 Apr 2012 16:39:00 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE2E28FC24; Wed, 18 Apr 2012 16:38:59 +0000 (UTC) Received: by eaaf13 with SMTP id f13so2128119eaa.13 for ; Wed, 18 Apr 2012 09:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; bh=pD2EF2A0TEThU6P3Tf4gU+/YRQpRnunKnzsu0HFu1rg=; b=RRWInFNklEy8mzQB4b35dDahwlDhQUTwU+L4OUCJiTeXr1MEN+cydMAez8H8w58HH6 mp+JvvL7hjiOIkrXZW9xTRUUYAkyHd7MHpaosAiWhEVdZD1iUjPKYOIB2wmF7LPGbwem TveIMBehT71Qix7kJAAdmcOd2kyfij+rtrxQ3dlZ02YUj1t61+nCYAjEe5vdmC6fG9s2 peup3F2/RTyLVS4vzvpkFC2k0hn692Gia6nsLUKqVrN7LvRibvM16U3i71Wp4t/u4QwZ KuZAoaCCfh7e8UEqQiMgQTLs1ugU0McuvAsVxCFcnpTvqP8y496y6qNZvNecsoy82zyU kHfQ== Received: by 10.213.15.143 with SMTP id k15mr275821eba.251.1334767138611; Wed, 18 Apr 2012 09:38:58 -0700 (PDT) Received: from ernst.jennejohn.org (p54895A89.dip.t-dialin.net. [84.137.90.137]) by mx.google.com with ESMTPS id r44sm120092863eef.2.2012.04.18.09.38.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Apr 2012 09:38:57 -0700 (PDT) Date: Wed, 18 Apr 2012 18:38:55 +0200 From: Gary Jennejohn To: Adrian Chadd Message-ID: <20120418183855.4b429ebc@ernst.jennejohn.org> In-Reply-To: References: <20120403193124.46ad9de9@ernst.jennejohn.org> <20120411192153.5672b62c@ernst.jennejohn.org> <20120417211558.4793b705@ernst.jennejohn.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers , Jerry Toung Subject: Re: CAM disk I/O starvation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:39:00 -0000 On Tue, 17 Apr 2012 12:30:15 -0700 Adrian Chadd wrote: > On 17 April 2012 12:15, Gary Jennejohn wrote: > > I still have the old problem kernel around, but it's probably not > > instrumented for any meaningful diagnoses. > > Well do you know which version of which tree you used to build that? > If it's head, you could "just" keep an earlier source tree around to > build a kernel from. > My /usr/src is from SVN, so I just need to boot it and do uname to get the revision. As a former src committer I like to be on the bleeding edge and I always run HEAD. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 17:48:10 2012 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 AE54A106566C; Wed, 18 Apr 2012 17:48:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 81F8B8FC18; Wed, 18 Apr 2012 17:48:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D0B8BB958; Wed, 18 Apr 2012 13:48:09 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 18 Apr 2012 13:47:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <1334760007.1082.243.camel@revolution.hippie.lan> <4F8ED702.4020803@FreeBSD.org> In-Reply-To: <4F8ED702.4020803@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204181347.59109.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 18 Apr 2012 13:48:10 -0400 (EDT) Cc: freebsd-fs@freebsd.org, Ian Lepore , freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 18 Apr 2012 17:48:10 -0000 On Wednesday, April 18, 2012 11:00:18 am Andriy Gapon wrote: > on 18/04/2012 17:40 Ian Lepore said the following: > > On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > >> on 18/04/2012 17:22 Ian Lepore said the following: > >>> YES! A size field (preferably as the first field in the struct) along > >>> with a flag to indicate that it's a new-style boot info struct that > >>> starts with a size field, will allow future changes without a lot of > >>> drama. It can allow code that has to deal with the struct without > >>> interpretting it (such as trampoline code that has to copy it to a new > >>> stack or memory area as part of loading the kernel) to be immune to > >>> future changes. > >> > >> Yeah, placing the new field at front would immediately break compatibility and > >> even access to the flags field :-) > >> > > > > Code would only assume the new field was at the front of the struct if > > the new flag is set, otherwise it would use the historical struct > > layout. > > Right, but where the flag would reside? > And how the older code that is not aware of the new flag would cope with the new > layout? I think the size should be appended to the end of the current structure. However, it will buy us more flexibility in the future. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 22:09:42 2012 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 0BFD91065670; Wed, 18 Apr 2012 22:09:42 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6FE778FC14; Wed, 18 Apr 2012 22:09:41 +0000 (UTC) Received: by wern13 with SMTP id n13so6618111wer.13 for ; Wed, 18 Apr 2012 15:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=c9m62CQs56KDtUFmkBXJVPg4sPalzlc27HVR0Q4g2jk=; b=lubQ/mf/WmQgHywacGblX2GZzqwRHDyeYU58J8sBUT1hYNZevNy7Z2d0EsrSMc7vzV HDEhgvkkQREemrriWLzQriLTr0jEX72XfupCaAjqDAbw+CoL6gYNy+NUh+Aw/Dk1CZvh Fcwbgd6mYNTjkYYJ5aQEm7R1s+CwYN1Qpp2b+yb4st39kJnvAxjidrtDcKw46jRgPGig QPJRMXGX2dztNNUMonEjjwuJS43Yrz1lyB5c7Nf7ZoB1BezlpIXmVnShvSJJZIqVIUp2 35CjJyyc0Wa5hxpYOvOWyvGuhQuK8yIk0aAFnJ3pvqpF2vazL04ykNKL6eVSZuXyvNIq +07Q== MIME-Version: 1.0 Received: by 10.180.95.197 with SMTP id dm5mr20377508wib.20.1334786980662; Wed, 18 Apr 2012 15:09:40 -0700 (PDT) Received: by 10.180.85.71 with HTTP; Wed, 18 Apr 2012 15:09:40 -0700 (PDT) Date: Wed, 18 Apr 2012 18:09:40 -0400 Message-ID: From: Ryan Stone To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: George Neville-Neil Subject: [PATCH] Implementation of DTrace sched provider (with bonus schedgraph script) 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, 18 Apr 2012 22:09:42 -0000 I've implemented the sched provider for FreeBSD. This provider provides probes that fire when various scheduling decisions are made. This implementation is intended to be compatible with the implementation in Solaris and its derivatives, with the following caveats: Several probes reference features that are not implemented in FreeBSD. This probes are provided but will never fire. These probes are: cpucaps-sleep, cpucaps-wakeup, schedctl-nopreempt, schedctl-preempt and schedctl-yield. I've added some extra probes that do not exist in Solaris and its derivatives, to make it possible to implement a schedgraph DTrace script. These probes are lend-pri and load-change. Scripts intended to be portable to other implementations should not reference these probes. FreeBSD currently does not properly translate internal types to the portable implementation-independent types defined in the documentation. This means that your scripts will see a struct thread * where they should get a lwpsinfo_t *, for example. The patch implementing the sched provider can be found here: http://people.freebsd.org/~rstone/patches/sched_sdt.diff This patch is against r234420. It should apply cleanly to stable/9 as well as head, but it will not compile if applied against stable/8 because of a change in the arguments accepted by the SDT_PROBE_DEFINE* macros. My D script that collections schedgraph data can be found here: http://people.freebsd.org/~rstone/dtrace/schedgraph.d I recommend collecting data with the ring bufpolicy. This causes DTrace to collect data in per-cpu ring buffers which should guarantee that there is no dropped data points. The data is written to stdout when dtrace(1) exits. In my example I exit after running for 5 seconds, but you could just as easily modify the script to run until a certain probe fires and then exit, for example. The output of schedgraph.d isn't quite ready for processing by schedgraph. Here is a very short sh script that post-processes the data to make it parseable by schedgraph: http://people.freebsd.org/~rstone/dtrace/make_ktr Finally, schedgraph.d uses the cpu variable, which is currently not available in FreeBSD. Here is my patch (which I will commit to HEAD soon) that implements that variable. You will have to rebuild dtrace.ko and libdtrace.so. http://people.freebsd.org/~rstone/patches/dtrace_cpu.diff From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 23:37:51 2012 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 6B9541065670 for ; Wed, 18 Apr 2012 23:37:51 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm9.bullet.mail.sp2.yahoo.com (nm9.bullet.mail.sp2.yahoo.com [98.139.91.79]) by mx1.freebsd.org (Postfix) with SMTP id 3F7AE8FC1A for ; Wed, 18 Apr 2012 23:37:51 +0000 (UTC) Received: from [98.139.91.65] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2012 23:37:45 -0000 Received: from [98.139.44.80] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 18 Apr 2012 23:37:45 -0000 Received: from [127.0.0.1] by omp1017.access.mail.sp2.yahoo.com with NNFMP; 18 Apr 2012 23:37:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 885835.30569.bm@omp1017.access.mail.sp2.yahoo.com Received: (qmail 58568 invoked by uid 60001); 18 Apr 2012 23:37:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1334792265; bh=hLjWq9yOGZxIvrawoxPfMkxrIsBbgXx1ld3nOt7nvo0=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iL86dXPaqvSzlgTSXPpooaYOs48bSVOngy2mKzUmBKeAVeYarrYK21EImxKCpM5rkGOAquIRnBTLBcxjT3RibyvKALA8Z8apLVvC8ljoyu3VHy+S+6c45J9UrHDmDuNH6yiUZL5TxSzDhRgGkVvLqmGqbI5AeoSwbWNyiKxhhrg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZbABV/+bVhVLAanbciUTZD5mGl6ltUq6WaPu6/HC42dH2aYZb5qmMOXJvms5kLLG0x7h1w8lHO4DpJh3YLAmu8IFuOa6O25xPZ7iSJPlZAtH8O+DDemymYWz1yUPdz25NvTAoxlDH4cJ9gDQKtd8/7EeTmbKBRHGCb85DyUvw6o=; X-YMail-OSG: r5i8wUwVM1lbbeQf5olhwE0itJUworXdsynemTRv2qEt704 2MN9LiaGR9gqpJs28CHY89eKqEMjFSYcvDgTVThD1l6wOQpujjLangZvXxQH sKyc3QNFOBcydCmcicr4_hPb7b47smbuysKDdicE9oAndZjHNFcpHnPbfcwm H7TkmwDQU.lKkVSRxOpYEJhsocYNAEsavWVF3VM5Tiypq8KLedpNdRCQeO6y frK5iMLsUTbWTzjEpsgK9xSXJXwFKHpZzsxh.vyXfuFYYLcQFwyEopOQZYHQ WXy5TlSgG._RZ3BTzpY4qGxQFar2WArfGpOBPM_5ebHD.AwMs1aTPCHGEx8E B1SXkHz10Kf0fD28mAKxuQSmOwlQ6VWiNz5cKj8NeSOwjWOeg8oXAa2pESCk h8ztnnQrBkU7D75E2.PELmOdvkxIsrM4b0JaMroVhPbJirUDShh_LbfSvnRM p.dnP Received: from [75.62.238.5] by web180012.mail.gq1.yahoo.com via HTTP; Wed, 18 Apr 2012 16:37:45 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.117.340979 Message-ID: <1334792265.20401.YahooMailClassic@web180012.mail.gq1.yahoo.com> Date: Wed, 18 Apr 2012 16:37:45 -0700 (PDT) From: Sushanth Rai To: Konstantin Belousov In-Reply-To: <1334601684.58522.YahooMailClassic@web180001.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN 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, 18 Apr 2012 23:37:51 -0000 Wiring entire address space seems to have interesting side effect. The libc= memory allocator calls madvise() to free the dirty unused pages, which doe= s nothing when the pages are wired. The allocator unmaps only when entire c= hunk is free (default size of 1MB). That leaves lots for free pages which c= annot reclaimed even when the system is under memory pressure.=0A=0ASushant= h=0A=0A--- On Mon, 4/16/12, Sushanth Rai wrote:=0A= =0A> From: Sushanth Rai =0A> Subject: Re: mlockall(= ) on freebsd 7.2 + amd64 returns EAGAIN=0A> To: "Konstantin Belousov" =0A> Cc: alc@freebsd.org, freebsd-hackers@freebsd.org=0A> D= ate: Monday, April 16, 2012, 11:41 AM=0A> Many thanks. I verified the patch= you=0A> provided and it works fine.=0A> =0A> Sushanth=0A> =0A> =0A> > Oh, = I see. The problem is the VM_MAP_WIRE_NOHOLES=0A> flag.=0A> > Since we=0A> = > map only the initial stack fragment even for the=0A> > MCL_WIREFUTURE map= s,=0A> > there is a hole in the stack region.=0A> > =0A> > In fact, for MCL= _WIREFUTURE, we probably should map=0A> the=0A> > whole=0A> > stack at once= , prefaulting all pages.=0A> > =0A> > Below are two patches. The change for= vm_mmap.c would=0A> fix=0A> > your immediate=0A> > problem by allowing hol= es in wired region.=0A> > =0A> > The change for vm_map.c prefaults the whol= e stack=0A> instead of=0A> > the=0A> > initial fragment. The single-threade= d programs still=0A> get a=0A> > fault=0A> > on stack growth.=0A> > =0A> > = diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c=0A> > index 6198629..2fd18d1= 100644=0A> > --- a/sys/vm/vm_map.c=0A> > +++ b/sys/vm/vm_map.c=0A> > @@ -3= 259,7 +3259,10 @@ vm_map_stack(vm_map_t map,=0A> > vm_offset_t addrbos, vm_= size_t max_ssize,=0A> >=A0 =A0=A0=A0 =A0 =A0 addrbos + max_ssize <=0A> > ad= drbos)=0A> >=A0 =A0=A0=A0 =A0=A0=A0 return=0A> > (KERN_NO_SPACE);=0A> >=A0 = =0A> > -=A0=A0=A0 init_ssize =3D (max_ssize < sgrowsiz) ?=0A> > max_ssize := sgrowsiz;=0A> > +=A0=A0=A0 if (map->flags & MAP_WIREFUTURE)=0A> > +=A0=A0= =A0 =A0=A0=A0 init_ssize =3D=0A> > max_ssize;=0A> > +=A0=A0=A0 else=0A> > += =A0=A0=A0 =A0=A0=A0 init_ssize =3D=0A> > (max_ssize < sgrowsiz) ? max_ssize= : sgrowsiz;=0A> >=A0 =0A> >=A0 =A0=A0=A0 PROC_LOCK(curthread->td_proc);=0A= > >=A0 =A0=A0=A0 vmemlim =3D lim_cur(curthread->td_proc,=0A> > RLIMIT_VMEM)= ;=0A> > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c=0A> > index 2588c8= 5..3fccd9e 100644=0A> > --- a/sys/vm/vm_mmap.c=0A> > +++ b/sys/vm/vm_mmap.c= =0A> > @@ -1561,9 +1561,11 @@ vm_mmap(vm_map_t map,=0A> vm_offset_t=0A> > *= addr, vm_size_t size, vm_prot_t prot,=0A> >=A0 =A0=A0=A0 =A0=A0=A0=A0=A0* I= f the=0A> > process has requested that all future mappings=0A> >=A0 =A0=A0= =A0 =A0=A0=A0=A0=A0* be=0A> > wired, then heed this.=0A> >=A0 =A0=A0=A0 =A0= =A0=A0=A0=A0*/=0A> > -=A0=A0=A0 =A0=A0=A0 if (map->flags=0A> > & MAP_WIREFU= TURE)=0A> > +=A0=A0=A0 =A0=A0=A0 if (map->flags=0A> > & MAP_WIREFUTURE) {= =0A> >=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> > vm_map_wire(map, *addr, *addr= + size,=0A> > -=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> > =A0 =A0 VM_MAP_WIRE_USE= R | VM_MAP_WIRE_NOHOLES);=0A> > +=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> > =A0 = =A0 VM_MAP_WIRE_USER | ((flags & MAP_STACK) ?=0A> > +=A0=A0=A0 =A0=A0=A0 = =A0=A0=A0=0A> > =A0 =A0 VM_MAP_WIRE_HOLESOK : VM_MAP_WIRE_NOHOLES));=0A> > = +=A0=A0=A0 =A0=A0=A0 }=0A> >=A0 =A0=A0=A0 } else {=0A> >=A0 =A0=A0=A0 =A0= =A0=A0 /*=0A> >=A0 =A0=A0=A0 =A0=A0=A0=A0=A0* If this=0A> > mapping was acc= ounted for in the vnode's=0A> >=0A> From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 07:30:03 2012 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 D88AF106566B; Thu, 19 Apr 2012 07:30:03 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id B33F38FC14; Thu, 19 Apr 2012 07:30:03 +0000 (UTC) Received: from delta.delphij.net (unknown [IPv6:2001:470:83bf:0:221:5cff:fe6a:37bb]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 13514F5EE; Thu, 19 Apr 2012 00:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1334820603; bh=SthX9g9LAIITLYliDYHeM8d8LapIQuZAJRfTFx549oU=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Ci0GbxGiknvgQLMS7Fm7iuUeLTV2a5cJ/XM8VhyJ43AwiKCj4LlS7M18BeDkvRhK2 cacJsiOKsB8HB/0w0LJb51t2OtigTztikyYPhWYoUzP4tHXn7hv4LrteHH6VMRHXcu sw2en6ycamNUMs2Knyzf9+yZYOWhcbz5JdpkxtlY= Message-ID: <4F8FBEEC.6060509@delphij.net> Date: Thu, 19 Apr 2012 00:29:48 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Barkley Vowk References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, d@delphij.net, freebsd-hardware@freebsd.org Subject: Re: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 07:30:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/12/12 10:14, Barkley Vowk wrote: > I've got a Highpoint 2760A card that I'd like a FreeBSD driver > for, I've got a machine and disks available if someone wants to > tackle that. Please try loading 'hpt27xx.ko' on boot. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPj77sAAoJEG80Jeu8UPuzoW4H/2KsdmWsV/HEERSkyPY/XX/B jJtEAZFFI6X4aYYqANyPXWWBA6mRy586GkZZNlClCw2v4cBxXAnWBWL49tcuJ0UP wURQt9/HU6P+EqbRSVZ98KhvufjvecjLavr9x6wCJ+L8pvc7trnD25l/Z0hTA96Y hIpwTcK/m0IXYopmC0WioPfyZWJx2Uu+DgrUUV6mXOZc9oDDf53v10rbGpQoNUZg GvKfL2Ql0rHZ13EJkjZdURcUj94Nas7pBgumGwedrsKs0NGnjRNmMlYSRzonqe0Z uBaWzqEiB01qNThfCpt0tnAS55wYU+QWmvF9hVSApSwmeCsrneluhyUjf9QJ8M8= =gUd0 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 12:45:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A932C106564A; Thu, 19 Apr 2012 12:45:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2419D8FC08; Thu, 19 Apr 2012 12:45:50 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3JCjjgn008511; Thu, 19 Apr 2012 15:45:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3JCjjAB031703; Thu, 19 Apr 2012 15:45:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3JCjiiu031702; Thu, 19 Apr 2012 15:45:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 19 Apr 2012 15:45:44 +0300 From: Konstantin Belousov To: Sushanth Rai Message-ID: <20120419124544.GJ2358@deviant.kiev.zoral.com.ua> References: <1334601684.58522.YahooMailClassic@web180001.mail.gq1.yahoo.com> <1334792265.20401.YahooMailClassic@web180012.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZlrxixA2Sx//Vzpg" Content-Disposition: inline In-Reply-To: <1334792265.20401.YahooMailClassic@web180012.mail.gq1.yahoo.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: alc@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN 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, 19 Apr 2012 12:45:51 -0000 --ZlrxixA2Sx//Vzpg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 18, 2012 at 04:37:45PM -0700, Sushanth Rai wrote: > Wiring entire address space seems to have interesting side effect. The > libc memory allocator calls madvise() to free the dirty unused pages, > which does nothing when the pages are wired. The allocator unmaps only > when entire chunk is free (default size of 1MB). That leaves lots for > free pages which cannot reclaimed even when the system is under memory > pressure. > Yes, and I would argue that this is the proper interpretation of the wire request. --ZlrxixA2Sx//Vzpg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+QCPgACgkQC3+MBN1Mb4iJdwCferb9scNqKy/DdASUAjY1lkA6 X6MAnA1JL5mHcJKMqedLj+rR3exP/b/C =ayHp -----END PGP SIGNATURE----- --ZlrxixA2Sx//Vzpg-- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 14:59:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBE4A1065670; Thu, 19 Apr 2012 14:59:38 +0000 (UTC) (envelope-from maninya@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5A9688FC0A; Thu, 19 Apr 2012 14:59:38 +0000 (UTC) Received: by yhgm50 with SMTP id m50so5366673yhg.13 for ; Thu, 19 Apr 2012 07:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SCkt3hqiHNIzAHq6gHGn3de3QNf6XMfhJUMhM1C8uAA=; b=eTu0IX/PWcYdj6NJOV5lp0aReAseAuQgAie/XdSW/HlRHOprtZ5eavQ6GCIS81Nb18 uieGljJnb9YhyI4UJPMHq19fQkmEVnwyADTuP2AGJgssa5taaKd+6RJ0WpzwhWBxCU7X LHWsbEN0INdoVleGxN73Gt1/U/0ID6Y4lMtldn8WCXJ/Cw2LnpLxWTH/QECdQGu1GLkT bVt+leVruSZTy97sX9q2I1Ho9dqvlZSavwp0B89zbiQieWXD6SgvL1zkpO26qYSdfTCW gjQnW0dofHPvjeyGtvQUUXgiJVBNXVI+dPidsuYq9kKi8n14yTPWG95Op+VFZTUWFtHr d3xQ== MIME-Version: 1.0 Received: by 10.50.237.101 with SMTP id vb5mr10320700igc.15.1334847565716; Thu, 19 Apr 2012 07:59:25 -0700 (PDT) Received: by 10.42.166.4 with HTTP; Thu, 19 Apr 2012 07:59:25 -0700 (PDT) In-Reply-To: <201204021642.29578.jhb@freebsd.org> References: <201203290944.11446.jhb@freebsd.org> <201204021642.29578.jhb@freebsd.org> Date: Thu, 19 Apr 2012 20:29:25 +0530 Message-ID: From: Maninya M To: John Baldwin , freebsd-hackers@freebsd.org, Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: __NR_mmap2 in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:59:39 -0000 Hello :) After a long time trying different combinations of setting register values, I was finally able to allocate memory to the process. It doesn't seem to work for processes that use malloc(), so that's why I was getting a problem. Thank you very much John Baldwin and Julian Elischer, and to all the other FreeBSD hackers on this amazing forum. Your patient replies to all my questions helped a lot! :) On 3 April 2012 02:12, John Baldwin wrote: > On Saturday, March 31, 2012 5:40:50 pm Maninya M wrote: > > Thanks. > > > > I've tried this. Still getting some allocation problems. > > > > if (temp_regs.r_eax != addr) > > warn("Wanted space at address 0x%.8x, mmap2 system call returned > > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); > > > > What can I do? Please help. > > Hmm, can you capture a ktrace of the target process during this so you can > see > if the kernel sees the mmap request properly? > > > > > void map_memory(unsigned long addr, unsigned long size, int flags) > > { > > int status; > > struct reg regs,temp_regs; > > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ > > printf("%x\n",addr); > > //addr=addr&0xffff0000; > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)®s,0) < 0) > > die_perror("ptrace(PTRACE_GETREGS,%d,(caddr_t)®s,0)",exec_pid); > > > > /* mmap2 system call seems to take arguments as follows: > > * eax = __NR_mmap2 > > * ebx = (unsigned long) page aligned address > > * ecx = (unsigned long) page aligned file size > > * edx = protection > > * esi = flags > > * Other arguments (fd and pgoff) are not required for anonymous > mapping > > */ > > temp_regs = regs; > > > > //printf("temp=%u, > \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); > > // temp_regs.r_eax = __NR_mmap2; > > temp_regs.r_eax=71; > > /*temp_regs.r_ebx = addr; > > temp_regs.r_ecx = size; > > temp_regs.r_edx = flags; > > temp_regs.r_esi = MAP_PRIVATE | MAP_ANONYMOUS;*/ > > //push size > > > > //temp_regs.r_eip = temp_regs.r_esp - 4; > > > > //printf("temp=%u, > \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-4),addr) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed > > ADDER",exec_pid,temp_regs.r_esp,addr); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-8),size) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed > > size",exec_pid,temp_regs.r_esp); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-12),flags) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed > > protections",exec_pid,temp_regs.r_esp); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void > > *)(temp_regs.r_esp-16),MAP_PRIVATE|MAP_ANON|MAP_FIXED) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed > > flags",exec_pid,temp_regs.r_esp); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-20),-1) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed > > ADDER",exec_pid,temp_regs.r_esp,addr); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-24),0) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed > > offset1",exec_pid,temp_regs.r_esp,addr); > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-28),0) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed > > offset1",exec_pid,temp_regs.r_esp,addr); > > > > > > /* > > if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x000080cd) < 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > allocating > > memory",exec_pid,temp_regs.r_eip); > > */ > > if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x000080cd) < > 0) > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > allocating > > memory",exec_pid,temp_regs.r_eip); > > > > //temp_regs.r_eip = temp_regs.r_esp - 32; > > temp_regs.r_esp = temp_regs.r_esp - 28; > > > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > die_perror("ptrace(PT_SETREGS,%d,...) failed while allocating > > memory",exec_pid); > > } > > if (ptrace(PT_STEP,exec_pid,NULL,0) < 0) > > die_perror("ptrace(PT_STEP,...) failed while executing mmap2"); > > > > wait(&status); > > if (WIFEXITED(status)) > > die("Restarted process abrubtly (exited with value %d). Aborting > > Restart.",WEXITSTATUS(status)); > > else if (WIFSIGNALED(status)) > > die("Restarted process abrubtly exited because of uncaught signal > (%d). > > Aborting Restart.",WTERMSIG(status)); > > > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > die_perror("ptrace(PT_GETREGS,...) failed after executing mmap2 > system > > call"); > > } > > //fprintf(stdout,"hello iam here \n"); > > if (temp_regs.r_eax != addr) > > warn("Wanted space at address 0x%.8x, mmap2 system call returned > > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); > > else if (cr_options.verbose) > > > > fprintf(stdout,"Successfully allocated [0x%.8lx - > > 0x%.8lx]\n",addr,addr+size); > > > > /* Restore original registers */ > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > die_perror("ptrace(PT_SETREGS,...) when restoring registering after > > allocating memory (mmap2)"); > > > > } > > } > > > > > > > > > > On 29 March 2012 19:14, John Baldwin wrote: > > > > > On Thursday, March 29, 2012 9:15:43 am Maninya M wrote: > > > > Thanks a lot for replying! > > > > Ok I've tried this to push arguments onto stack. > > > > Is it right? > > > > I get an error at this line: > > > > > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > > dasfallocating memory",exec_pid,temp_regs.r_eip); > > > > > > > > > > > > Please tell me what to do. > > > > > > > > > > > > > > > > > > > > > > > > void map_memory(unsigned long addr, unsigned long size, int flags) > > > > { > > > > int status; > > > > struct reg regs,temp_regs; > > > > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ > > > > > > > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)®s,0) < 0) > > > > > die_perror("ptrace(PTRACE_GETREGS,%d,(caddr_t)®s,0)",exec_pid); > > > > > > > > /* mmap2 system call seems to take arguments as follows: > > > > * eax = __NR_mmap2 > > > > * ebx = (unsigned long) page aligned address > > > > * ecx = (unsigned long) page aligned file size > > > > * edx = protection > > > > * esi = flags > > > > * Other arguments (fd and pgoff) are not required for anonymous > > > mapping > > > > */ > > > > temp_regs = regs; > > > > > > > > //printf("temp=%u, > > > > \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); > > > > // temp_regs.r_eax = __NR_mmap2; > > > > temp_regs.r_eax=71; > > > > /*temp_regs.r_ebx = addr; > > > > temp_regs.r_ecx = size; > > > > temp_regs.r_edx = flags; > > > > temp_regs.r_esi = MAP_PRIVATE | MAP_ANONYMOUS;*/ > > > > //push size > > > > > > > > //temp_regs.r_eip = temp_regs.r_esp - 4; > > > > > > You still want this, it is putting the instruction on the stack. > However, > > > your stack layout is wrong I think. You actually want it to be > something > > > like > > > this: > > > > > > r_esp - 4: > > > r_esp - 8: > > > r_esp - 12: > > > r_esp - 16: (MAP_FIXED?) > > > r_esp - 20: > > > r_esp - 24: > > > r_esp - 28: > > > r_esp - 32: > > > > > > Then you want to set: > > > > > > r_eip = r_esp - 32; > > > r_esp -= 28; > > > > > > I think you want MAP_FIXED since it complains if the returned address > > > doesn't > > > match 'addr' at the end of your routine. However, it might be best if > you > > > just compiled a program that called mmap() and then looked at the > > > disassembly > > > and to make sure the stack layout is correct. > > > > > > > //printf("temp=%u, > > > > \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); > > > > if (ptrace(PT_WRITE_D,exec_pid,(void > *)(temp_regs.r_esp-4),MAP_PRIVATE | > > > > MAP_ANONYMOUS) < 0) > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > allocating > > > > memory",exec_pid,temp_regs.r_eip); > > > > > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-8),flags) < > 0) > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > allocating > > > > memory",exec_pid,temp_regs.r_eip); > > > > > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-12),size) < > 0) > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > allocating > > > > memory",exec_pid,temp_regs.r_eip); > > > > > > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-16), addr) < > 0); > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > > dasfallocating memory",exec_pid,temp_regs.r_eip); > > > > /* > > > > if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x000080cd) > < > 0) > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > allocating > > > > memory",exec_pid,temp_regs.r_eip); > > > > */ > > > > if (ptrace(PT_WRITE_I,exec_pid,(void > *)(temp_regs.r_eip),0x000080cd) < > > > 0) > > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while > > > allocating > > > > memory",exec_pid,temp_regs.r_eip); > > > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > > > die_perror("ptrace(PT_SETREGS,%d,...) failed while allocating > > > > memory",exec_pid); > > > > } > > > > if (ptrace(PT_STEP,exec_pid,NULL,0) < 0) > > > > die_perror("ptrace(PT_STEP,...) failed while executing mmap2"); > > > > > > > > wait(&status); > > > > if (WIFEXITED(status)) > > > > die("Restarted process abrubtly (exited with value %d). Aborting > > > > Restart.",WEXITSTATUS(status)); > > > > else if (WIFSIGNALED(status)) > > > > die("Restarted process abrubtly exited because of uncaught signal > > > (%d). > > > > Aborting Restart.",WTERMSIG(status)); > > > > > > > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > > > die_perror("ptrace(PT_GETREGS,...) failed after executing mmap2 > > > system > > > > call"); > > > > } > > > > //fprintf(stdout,"hello iam here \n"); > > > > if (temp_regs.r_eax != addr) > > > > warn("Wanted space at address 0x%.8x, mmap2 system call returned > > > > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); > > > > else if (cr_options.verbose) > > > > > > > > fprintf(stdout,"Successfully allocated [0x%.8lx - > > > > 0x%.8lx]\n",addr,addr+size); > > > > > > > > /* Restore original registers */ > > > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { > > > > die_perror("ptrace(PT_SETREGS,...) when restoring registering > after > > > > allocating memory (mmap2)"); > > > > > > > > } > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 27 March 2012 17:23, John Baldwin wrote: > > > > > > > > > On Monday, March 26, 2012 1:56:08 pm Maninya M wrote: > > > > > > I am trying to convert a function written for Linux to FreeBSD. > > > > > > What is the equivalent of the __NR_mmap2 system call in FreeBSD? > > > > > > > > > > > > I keep getting the error because of this exception: > > > > > > warn("Wanted space at address 0x%.8x, mmap2 system call returned > > > 0x%.8x. > > > > > > This could be a problem.",addr,temp_regs.eax); > > > > > > > > > > I think you could just use plain mmap() for this? > > > > > > > > > > However, it seems that this is injecting a call into an existing > > > binary, > > > > > not calling mmap() directly. A few things will need to change. > First, > > > > > FreeBSD system calls on i386 put their arguments on the stack, not > in > > > > > registers, so you will need to do a bit more work to push the > arguments > > > > > onto > > > > > the stack rather than just setting registers. > > > > > > > > > > > I changed > > > > > > temp_regs.eax = __NR_mmap2; > > > > > > to > > > > > > temp_regs.eax = 192; > > > > > > > > > > > > but it didn't work. I suppose I couldn't understand this > function. > > > Please > > > > > > help. > > > > > > > > > > > > This is the function: > > > > > > > > > > > > void map_memory(unsigned long addr, unsigned long size, int > flags) > > > > > > { > > > > > > int status; > > > > > > struct user_regs_struct regs,temp_regs; > > > > > > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ > > > > > > > > > > > > if (ptrace(PTRACE_GETREGS,exec_pid,NULL,®s) < 0) > > > > > > die_perror("ptrace(PTRACE_GETREGS,%d,NULL,®s)",exec_pid); > > > > > > > > > > > > /* mmap2 system call seems to take arguments as follows: > > > > > > * eax = __NR_mmap2 > > > > > > * ebx = (unsigned long) page aligned address > > > > > > * ecx = (unsigned long) page aligned file size > > > > > > * edx = protection > > > > > > * esi = flags > > > > > > * Other arguments (fd and pgoff) are not required for > anonymous > > > > > mapping > > > > > > */ > > > > > > temp_regs = regs; > > > > > > temp_regs.eax = __NR_mmap2; > > > > > > temp_regs.ebx = addr; > > > > > > temp_regs.ecx = size; > > > > > > temp_regs.edx = flags; > > > > > > temp_regs.esi = MAP_PRIVATE | MAP_ANONYMOUS; > > > > > > temp_regs.eip = temp_regs.esp - 4; > > > > > > > > > > > > if (ptrace(PTRACE_POKETEXT,exec_pid,(void > > > > > > *)(temp_regs.eip),(void*)int_instr) < 0) > > > > > > die_perror("ptrace(PTRACE_POKETEXT,%d,0x%.8x,INT 0x80) failed > > > while > > > > > > allocating memory",exec_pid,temp_regs.eip); > > > > > > if (ptrace(PTRACE_SETREGS,exec_pid,NULL,&temp_regs) < 0) { > > > > > > die_perror("ptrace(PTRACE_SETREGS,%d,...) failed while > allocating > > > > > > memory",exec_pid); > > > > > > } > > > > > > if (ptrace(PTRACE_SINGLESTEP,exec_pid,NULL,NULL) < 0) > > > > > > die_perror("ptrace(PTRACE_SINGLESTEP,...) failed while > executing > > > > > > mmap2"); > > > > > > > > > > > > wait(&status); > > > > > > if (WIFEXITED(status)) > > > > > > die("Restarted process abrubtly (exited with value %d). > Aborting > > > > > > Restart.",WEXITSTATUS(status)); > > > > > > else if (WIFSIGNALED(status)) > > > > > > die("Restarted process abrubtly exited because of uncaught > signal > > > > > (%d). > > > > > > Aborting Restart.",WTERMSIG(status)); > > > > > > > > > > > > if (ptrace(PTRACE_GETREGS,exec_pid,NULL,&temp_regs) < 0) { > > > > > > die_perror("ptrace(PTRACE_GETREGS,...) failed after executing > > > mmap2 > > > > > > system call"); > > > > > > } > > > > > > > > > > > > if (temp_regs.eax != addr) > > > > > > warn("Wanted space at address 0x%.8x, mmap2 system call > returned > > > > > > 0x%.8x. This could be a problem.",addr,temp_regs.eax); > > > > > > else if (cr_options.verbose) > > > > > > fprintf(stdout,"Successfully allocated [0x%.8lx - > > > > > > 0x%.8lx]\n",addr,addr+size); > > > > > > > > > > > > /* Restore original registers */ > > > > > > if (ptrace(PTRACE_SETREGS,exec_pid,NULL,®s) < 0) { > > > > > > die_perror("ptrace(PTRACE_SETREGS,...) when restoring > registering > > > > > after > > > > > > allocating memory (mmap2)"); > > > > > > } > > > > > > } > > > > > > > > > > > > -- > > > > > > Maninya > > > > > > _______________________________________________ > > > > > > 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" > > > > > > > > > > > > > > > > -- > > > > > John Baldwin > > > > > > > > > > > > > > > > > > > > > -- > > > > Maninya > > > > > > > > > > -- > > > John Baldwin > > > > > > > > > > > -- > > Maninya > > > > -- > John Baldwin > -- Maninya From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 16:38:43 2012 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 AE4801065675; Thu, 19 Apr 2012 16:38:43 +0000 (UTC) (envelope-from maninya@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 50F768FC19; Thu, 19 Apr 2012 16:38:43 +0000 (UTC) Received: by iahk25 with SMTP id k25so15836755iah.13 for ; Thu, 19 Apr 2012 09:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=s1BSFoODfFM2shQ8bpcyGKE4IWB/5541ytcbvsoPY28=; b=J7MOU37A/rT8SJ+we3zSK1pre5HAC7keeyueqRNuxggBtQrNOZ/4zNEXYipIZiW4xP hWvzs1nc5q0JL0Yxq3TYH5nRYRMd7jxFTejN+KTMDLeh99nL0pqtLgADte4B8pj88Uw4 YshOY+B/OkBw5+PyboBy6lojEB2R3oA82IzOX1WsqsoGNg1tG6b6ox+aASd19DYm3cdU JN8UBVZsmybiI4KPlS153GX6YHrON/JYiuZqJpUNh3L0jrXXEfBuNDA0tx2kHh5m8IHh CltkxzxCdwYMlf5ayfQ1LBVCoRfKwQb1nSqU6pSte6o/fzy4DREKTPgB9Sw2QnIg0Ul4 Svkw== MIME-Version: 1.0 Received: by 10.50.186.231 with SMTP id fn7mr3079468igc.15.1334853522573; Thu, 19 Apr 2012 09:38:42 -0700 (PDT) Received: by 10.42.166.4 with HTTP; Thu, 19 Apr 2012 09:38:42 -0700 (PDT) In-Reply-To: References: <201203290944.11446.jhb@freebsd.org> <201204021642.29578.jhb@freebsd.org> Date: Thu, 19 Apr 2012 22:08:42 +0530 Message-ID: From: Maninya M To: John Baldwin , freebsd-hackers@freebsd.org, Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: __NR_mmap2 in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:38:43 -0000 Oh and here is the code that worked. Thanks! :) void map_memory(unsigned long addr, unsigned long size, int flags) { int status; char cmd[200]; struct reg regs,temp_regs; unsigned int int_instr = 0x000080cd; /* INT 0x80 */ unsigned int push_eax= 0x00000050; unsigned int orig_instr; sprintf(cmd,"procstat -v %d "/*| grep 0x | awk ' { print $2,$3,$4 } ' | cut -d '%%' -f1 > temp.txt*/,exec_pid); system(cmd); if (ptrace(PT_GETREGS,exec_pid,(caddr_t)®s,0) < 0) die_perror("ptrace(PTRACE_GETREGS,%d,(caddr_t)®s,0)",exec_pid); /*mmap2 system call seems to take arguments as follows: * eax = __NR_mmap2 * ebx = (unsigned long) page aligned address * ecx = (unsigned long) page aligned file size * edx = protection * esi = flags * Other arguments (fd and pgoff) are not required for anonymous mapping */ int i; orig_instr = ptrace(PT_READ_D, exec_pid, (caddr_t)regs.r_eip,0); temp_regs = regs; unsigned int arr[8]={0,0,-1,MAP_ANON|MAP_PRIVATE|MAP_FIXED,flags,size,addr,45}; for(i=0;i<8;i++) { temp_regs.r_eip=regs.r_eip; temp_regs.r_eax=arr[i]; if(ptrace(PT_WRITE_D, exec_pid,(caddr_t)temp_regs.r_eip,push_eax)<0) die_perror("ptrace(PT_WRITE,%d,0x%.8x) while pushing",exec_pid,arr[i]); if(ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0)<0) die_perror("ptrace(PT_SETREGS,%d,0x%.8x)%d while pushing",exec_pid,arr[i],i); if(ptrace(PT_STEP, exec_pid, (caddr_t)1, 0)<0) printf("\nafter continue\n"); wait(NULL); if(ptrace(PT_GETREGS, exec_pid,(caddr_t)&temp_regs,0)<0); } temp_regs.r_eip=regs.r_eip; temp_regs.r_eax=SYS_mmap; if (ptrace(PT_WRITE_D,exec_pid,(caddr_t)(temp_regs.r_eip),int_instr) < 0) die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while allocating memory",exec_pid,temp_regs.r_eip); if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { die_perror("ptrace(PT_SETREGS,%d,...) failed while allocating memory",exec_pid); } if (ptrace(PT_STEP,exec_pid,(caddr_t)1,0) < 0) die_perror("ptrace(PT_STEP,...) failed while executing mmap"); //temp_regs.r_esp = temp_regs.r_esp - 28; wait(&status); if (WIFEXITED(status)) die("Restarted process abrubtly (exited with value %d). Aborting Restart.",WEXITSTATUS(status)); else if (WIFSIGNALED(status)) die("Restarted process abrubtly exited because of uncaught signal (%d). Aborting Restart.",WTERMSIG(status)); if (ptrace(PT_GETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { die_perror("ptrace(PT_GETREGS,...) failed after executing mmap2 system call"); } //fprintf(stdout,"hello iam here in map_memory() \n"); if (temp_regs.r_eax != addr) warn("Wanted space at address 0x%.8x, mmap2 system call returned 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); else if (cr_options.verbose) fprintf(stdout,"Successfully allocated [0x%.8lx - 0x%.8lx]\n",addr,addr+size); if(ptrace(PT_WRITE_D, exec_pid, (caddr_t)regs.r_eip,orig_instr)<0) die_perror("ptrace(PT_WRITE_D,...) failed after executing mmap2 system call"); //Restore original registers if (ptrace(PT_SETREGS,exec_pid,(caddr_t)®s,0) < 0) { die_perror("ptrace(PT_SETREGS,...) when restoring registering after allocating memory (mmap2)"); } } On 19 April 2012 20:29, Maninya M wrote: > Hello :) > > After a long time trying different combinations of setting register > values, I was finally able to allocate memory to the process. > It doesn't seem to work for processes that use malloc(), so that's why I > was getting a problem. > Thank you very much John Baldwin and Julian Elischer, and to all the other > FreeBSD hackers on this amazing forum. Your patient replies to all my > questions helped a lot! :) > > > > > > On 3 April 2012 02:12, John Baldwin wrote: > >> On Saturday, March 31, 2012 5:40:50 pm Maninya M wrote: >> > Thanks. >> > >> > I've tried this. Still getting some allocation problems. >> > >> > if (temp_regs.r_eax != addr) >> > warn("Wanted space at address 0x%.8x, mmap2 system call returned >> > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); >> > >> > What can I do? Please help. >> >> Hmm, can you capture a ktrace of the target process during this so you >> can see >> if the kernel sees the mmap request properly? >> >> > >> > void map_memory(unsigned long addr, unsigned long size, int flags) >> > { >> > int status; >> > struct reg regs,temp_regs; >> > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ >> > printf("%x\n",addr); >> > //addr=addr&0xffff0000; >> > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)®s,0) < 0) >> > die_perror("ptrace(PTRACE_GETREGS,%d,(caddr_t)®s,0)",exec_pid); >> > >> > /* mmap2 system call seems to take arguments as follows: >> > * eax = __NR_mmap2 >> > * ebx = (unsigned long) page aligned address >> > * ecx = (unsigned long) page aligned file size >> > * edx = protection >> > * esi = flags >> > * Other arguments (fd and pgoff) are not required for anonymous >> mapping >> > */ >> > temp_regs = regs; >> > >> > //printf("temp=%u, >> \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); >> > // temp_regs.r_eax = __NR_mmap2; >> > temp_regs.r_eax=71; >> > /*temp_regs.r_ebx = addr; >> > temp_regs.r_ecx = size; >> > temp_regs.r_edx = flags; >> > temp_regs.r_esi = MAP_PRIVATE | MAP_ANONYMOUS;*/ >> > //push size >> > >> > //temp_regs.r_eip = temp_regs.r_esp - 4; >> > >> > //printf("temp=%u, >> \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-4),addr) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed >> > ADDER",exec_pid,temp_regs.r_esp,addr); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-8),size) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed >> > size",exec_pid,temp_regs.r_esp); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-12),flags) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed >> > protections",exec_pid,temp_regs.r_esp); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void >> > *)(temp_regs.r_esp-16),MAP_PRIVATE|MAP_ANON|MAP_FIXED) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed >> > flags",exec_pid,temp_regs.r_esp); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-20),-1) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed >> > ADDER",exec_pid,temp_regs.r_esp,addr); >> > >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-24),0) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed >> > offset1",exec_pid,temp_regs.r_esp,addr); >> > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-28),0) < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed >> > offset1",exec_pid,temp_regs.r_esp,addr); >> > >> > >> > /* >> > if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x000080cd) < >> 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> allocating >> > memory",exec_pid,temp_regs.r_eip); >> > */ >> > if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x000080cd) >> < 0) >> > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> allocating >> > memory",exec_pid,temp_regs.r_eip); >> > >> > //temp_regs.r_eip = temp_regs.r_esp - 32; >> > temp_regs.r_esp = temp_regs.r_esp - 28; >> > >> > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > die_perror("ptrace(PT_SETREGS,%d,...) failed while allocating >> > memory",exec_pid); >> > } >> > if (ptrace(PT_STEP,exec_pid,NULL,0) < 0) >> > die_perror("ptrace(PT_STEP,...) failed while executing mmap2"); >> > >> > wait(&status); >> > if (WIFEXITED(status)) >> > die("Restarted process abrubtly (exited with value %d). Aborting >> > Restart.",WEXITSTATUS(status)); >> > else if (WIFSIGNALED(status)) >> > die("Restarted process abrubtly exited because of uncaught signal >> (%d). >> > Aborting Restart.",WTERMSIG(status)); >> > >> > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > die_perror("ptrace(PT_GETREGS,...) failed after executing mmap2 >> system >> > call"); >> > } >> > //fprintf(stdout,"hello iam here \n"); >> > if (temp_regs.r_eax != addr) >> > warn("Wanted space at address 0x%.8x, mmap2 system call returned >> > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); >> > else if (cr_options.verbose) >> > >> > fprintf(stdout,"Successfully allocated [0x%.8lx - >> > 0x%.8lx]\n",addr,addr+size); >> > >> > /* Restore original registers */ >> > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > die_perror("ptrace(PT_SETREGS,...) when restoring registering after >> > allocating memory (mmap2)"); >> > >> > } >> > } >> > >> > >> > >> > >> > On 29 March 2012 19:14, John Baldwin wrote: >> > >> > > On Thursday, March 29, 2012 9:15:43 am Maninya M wrote: >> > > > Thanks a lot for replying! >> > > > Ok I've tried this to push arguments onto stack. >> > > > Is it right? >> > > > I get an error at this line: >> > > > >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > > dasfallocating memory",exec_pid,temp_regs.r_eip); >> > > > >> > > > >> > > > Please tell me what to do. >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > void map_memory(unsigned long addr, unsigned long size, int flags) >> > > > { >> > > > int status; >> > > > struct reg regs,temp_regs; >> > > > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ >> > > > >> > > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)®s,0) < 0) >> > > > >> die_perror("ptrace(PTRACE_GETREGS,%d,(caddr_t)®s,0)",exec_pid); >> > > > >> > > > /* mmap2 system call seems to take arguments as follows: >> > > > * eax = __NR_mmap2 >> > > > * ebx = (unsigned long) page aligned address >> > > > * ecx = (unsigned long) page aligned file size >> > > > * edx = protection >> > > > * esi = flags >> > > > * Other arguments (fd and pgoff) are not required for anonymous >> > > mapping >> > > > */ >> > > > temp_regs = regs; >> > > > >> > > > //printf("temp=%u, >> > > >> \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); >> > > > // temp_regs.r_eax = __NR_mmap2; >> > > > temp_regs.r_eax=71; >> > > > /*temp_regs.r_ebx = addr; >> > > > temp_regs.r_ecx = size; >> > > > temp_regs.r_edx = flags; >> > > > temp_regs.r_esi = MAP_PRIVATE | MAP_ANONYMOUS;*/ >> > > > //push size >> > > > >> > > > //temp_regs.r_eip = temp_regs.r_esp - 4; >> > > >> > > You still want this, it is putting the instruction on the stack. >> However, >> > > your stack layout is wrong I think. You actually want it to be >> something >> > > like >> > > this: >> > > >> > > r_esp - 4: >> > > r_esp - 8: >> > > r_esp - 12: >> > > r_esp - 16: (MAP_FIXED?) >> > > r_esp - 20: >> > > r_esp - 24: >> > > r_esp - 28: >> > > r_esp - 32: >> > > >> > > Then you want to set: >> > > >> > > r_eip = r_esp - 32; >> > > r_esp -= 28; >> > > >> > > I think you want MAP_FIXED since it complains if the returned address >> > > doesn't >> > > match 'addr' at the end of your routine. However, it might be best >> if you >> > > just compiled a program that called mmap() and then looked at the >> > > disassembly >> > > and to make sure the stack layout is correct. >> > > >> > > > //printf("temp=%u, >> > > >> \teip=%u\tregs=%u\teip=%u\n",&temp_regs,temp_regs.r_eip,®s,regs.r_eip); >> > > > if (ptrace(PT_WRITE_D,exec_pid,(void >> *)(temp_regs.r_esp-4),MAP_PRIVATE | >> > > > MAP_ANONYMOUS) < 0) >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > allocating >> > > > memory",exec_pid,temp_regs.r_eip); >> > > > >> > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-8),flags) < >> 0) >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > allocating >> > > > memory",exec_pid,temp_regs.r_eip); >> > > > >> > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-12),size) < >> 0) >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > allocating >> > > > memory",exec_pid,temp_regs.r_eip); >> > > > >> > > > if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-16), addr) >> < 0); >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > > dasfallocating memory",exec_pid,temp_regs.r_eip); >> > > > /* >> > > > if (ptrace(PT_WRITE_I,exec_pid,(void >> *)(temp_regs.r_eip),0x000080cd) < >> 0) >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > allocating >> > > > memory",exec_pid,temp_regs.r_eip); >> > > > */ >> > > > if (ptrace(PT_WRITE_I,exec_pid,(void >> *)(temp_regs.r_eip),0x000080cd) < >> > > 0) >> > > > die_perror("ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while >> > > allocating >> > > > memory",exec_pid,temp_regs.r_eip); >> > > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > > > die_perror("ptrace(PT_SETREGS,%d,...) failed while allocating >> > > > memory",exec_pid); >> > > > } >> > > > if (ptrace(PT_STEP,exec_pid,NULL,0) < 0) >> > > > die_perror("ptrace(PT_STEP,...) failed while executing mmap2"); >> > > > >> > > > wait(&status); >> > > > if (WIFEXITED(status)) >> > > > die("Restarted process abrubtly (exited with value %d). Aborting >> > > > Restart.",WEXITSTATUS(status)); >> > > > else if (WIFSIGNALED(status)) >> > > > die("Restarted process abrubtly exited because of uncaught >> signal >> > > (%d). >> > > > Aborting Restart.",WTERMSIG(status)); >> > > > >> > > > if (ptrace(PT_GETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > > > die_perror("ptrace(PT_GETREGS,...) failed after executing mmap2 >> > > system >> > > > call"); >> > > > } >> > > > //fprintf(stdout,"hello iam here \n"); >> > > > if (temp_regs.r_eax != addr) >> > > > warn("Wanted space at address 0x%.8x, mmap2 system call returned >> > > > 0x%.8x. This could be a problem.",addr,temp_regs.r_eax); >> > > > else if (cr_options.verbose) >> > > > >> > > > fprintf(stdout,"Successfully allocated [0x%.8lx - >> > > > 0x%.8lx]\n",addr,addr+size); >> > > > >> > > > /* Restore original registers */ >> > > > if (ptrace(PT_SETREGS,exec_pid,(caddr_t)&temp_regs,0) < 0) { >> > > > die_perror("ptrace(PT_SETREGS,...) when restoring registering >> after >> > > > allocating memory (mmap2)"); >> > > > >> > > > } >> > > > } >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > On 27 March 2012 17:23, John Baldwin wrote: >> > > > >> > > > > On Monday, March 26, 2012 1:56:08 pm Maninya M wrote: >> > > > > > I am trying to convert a function written for Linux to FreeBSD. >> > > > > > What is the equivalent of the __NR_mmap2 system call in FreeBSD? >> > > > > > >> > > > > > I keep getting the error because of this exception: >> > > > > > warn("Wanted space at address 0x%.8x, mmap2 system call returned >> > > 0x%.8x. >> > > > > > This could be a problem.",addr,temp_regs.eax); >> > > > > >> > > > > I think you could just use plain mmap() for this? >> > > > > >> > > > > However, it seems that this is injecting a call into an existing >> > > binary, >> > > > > not calling mmap() directly. A few things will need to change. >> First, >> > > > > FreeBSD system calls on i386 put their arguments on the stack, >> not in >> > > > > registers, so you will need to do a bit more work to push the >> arguments >> > > > > onto >> > > > > the stack rather than just setting registers. >> > > > > >> > > > > > I changed >> > > > > > temp_regs.eax = __NR_mmap2; >> > > > > > to >> > > > > > temp_regs.eax = 192; >> > > > > > >> > > > > > but it didn't work. I suppose I couldn't understand this >> function. >> > > Please >> > > > > > help. >> > > > > > >> > > > > > This is the function: >> > > > > > >> > > > > > void map_memory(unsigned long addr, unsigned long size, int >> flags) >> > > > > > { >> > > > > > int status; >> > > > > > struct user_regs_struct regs,temp_regs; >> > > > > > unsigned long int_instr = 0x000080cd; /* INT 0x80 */ >> > > > > > >> > > > > > if (ptrace(PTRACE_GETREGS,exec_pid,NULL,®s) < 0) >> > > > > > die_perror("ptrace(PTRACE_GETREGS,%d,NULL,®s)",exec_pid); >> > > > > > >> > > > > > /* mmap2 system call seems to take arguments as follows: >> > > > > > * eax = __NR_mmap2 >> > > > > > * ebx = (unsigned long) page aligned address >> > > > > > * ecx = (unsigned long) page aligned file size >> > > > > > * edx = protection >> > > > > > * esi = flags >> > > > > > * Other arguments (fd and pgoff) are not required for >> anonymous >> > > > > mapping >> > > > > > */ >> > > > > > temp_regs = regs; >> > > > > > temp_regs.eax = __NR_mmap2; >> > > > > > temp_regs.ebx = addr; >> > > > > > temp_regs.ecx = size; >> > > > > > temp_regs.edx = flags; >> > > > > > temp_regs.esi = MAP_PRIVATE | MAP_ANONYMOUS; >> > > > > > temp_regs.eip = temp_regs.esp - 4; >> > > > > > >> > > > > > if (ptrace(PTRACE_POKETEXT,exec_pid,(void >> > > > > > *)(temp_regs.eip),(void*)int_instr) < 0) >> > > > > > die_perror("ptrace(PTRACE_POKETEXT,%d,0x%.8x,INT 0x80) >> failed >> > > while >> > > > > > allocating memory",exec_pid,temp_regs.eip); >> > > > > > if (ptrace(PTRACE_SETREGS,exec_pid,NULL,&temp_regs) < 0) { >> > > > > > die_perror("ptrace(PTRACE_SETREGS,%d,...) failed while >> allocating >> > > > > > memory",exec_pid); >> > > > > > } >> > > > > > if (ptrace(PTRACE_SINGLESTEP,exec_pid,NULL,NULL) < 0) >> > > > > > die_perror("ptrace(PTRACE_SINGLESTEP,...) failed while >> executing >> > > > > > mmap2"); >> > > > > > >> > > > > > wait(&status); >> > > > > > if (WIFEXITED(status)) >> > > > > > die("Restarted process abrubtly (exited with value %d). >> Aborting >> > > > > > Restart.",WEXITSTATUS(status)); >> > > > > > else if (WIFSIGNALED(status)) >> > > > > > die("Restarted process abrubtly exited because of uncaught >> signal >> > > > > (%d). >> > > > > > Aborting Restart.",WTERMSIG(status)); >> > > > > > >> > > > > > if (ptrace(PTRACE_GETREGS,exec_pid,NULL,&temp_regs) < 0) { >> > > > > > die_perror("ptrace(PTRACE_GETREGS,...) failed after >> executing >> > > mmap2 >> > > > > > system call"); >> > > > > > } >> > > > > > >> > > > > > if (temp_regs.eax != addr) >> > > > > > warn("Wanted space at address 0x%.8x, mmap2 system call >> returned >> > > > > > 0x%.8x. This could be a problem.",addr,temp_regs.eax); >> > > > > > else if (cr_options.verbose) >> > > > > > fprintf(stdout,"Successfully allocated [0x%.8lx - >> > > > > > 0x%.8lx]\n",addr,addr+size); >> > > > > > >> > > > > > /* Restore original registers */ >> > > > > > if (ptrace(PTRACE_SETREGS,exec_pid,NULL,®s) < 0) { >> > > > > > die_perror("ptrace(PTRACE_SETREGS,...) when restoring >> registering >> > > > > after >> > > > > > allocating memory (mmap2)"); >> > > > > > } >> > > > > > } >> > > > > > >> > > > > > -- >> > > > > > Maninya >> > > > > > _______________________________________________ >> > > > > > 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" >> > > > > > >> > > > > >> > > > > -- >> > > > > John Baldwin >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Maninya >> > > > >> > > >> > > -- >> > > John Baldwin >> > > >> > >> > >> > >> > -- >> > Maninya >> > >> >> -- >> John Baldwin >> > > > > -- > Maninya > -- Maninya From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 19:46:07 2012 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 CD208106566C for ; Thu, 19 Apr 2012 19:46:07 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 500788FC0A for ; Thu, 19 Apr 2012 19:46:07 +0000 (UTC) Received: by lagv3 with SMTP id v3so8611976lag.13 for ; Thu, 19 Apr 2012 12:46:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=oYtWuQiHZEqqBMqsYyBVHHNEWgiPoEJbvYOxY3sT+Jk=; b=aN50gB+CPUVl9wjw9RIWUZwzkaajwFxXnJfzttZsbGjQvB6gU6A5ydpgccbgiMsII6 jqWNfklQtEmYeqsUZ50mMXquRjrRkAXHXImv9fFGW3uhK1YGMV1xRMEmBOMRoQRajjf6 0NeqB9o2joDiji/4njXXnIZBLBZiC3z3wL2xMrexvhKRfGrHQ5Y3DvyzSig3TMeSFJAj TNUc72ouaPHNLt6nVPTyBqW3AuVcmblIvfq/kFXIBaoGukKydqMWmh0kE9DH5cylR8A2 3ZSUfT3dxLaFQsiszGfZpZOaaebovrH8FUjVK74eUfwSnBJs2cpDTom/TEvrDMqBsaql g46Q== MIME-Version: 1.0 Received: by 10.112.49.5 with SMTP id q5mr1666806lbn.7.1334864766245; Thu, 19 Apr 2012 12:46:06 -0700 (PDT) Received: by 10.112.54.41 with HTTP; Thu, 19 Apr 2012 12:46:06 -0700 (PDT) X-Originating-IP: [216.223.13.111] Date: Thu, 19 Apr 2012 15:46:06 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+Xz499hbzL4Qu7Vt6evB2rc3yisYNzueJlWMCzLm1nMep/aUIkMo7e+n4n+q0tkfqkydI Subject: mount_nfs does not like exports longer then 88 chars 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, 19 Apr 2012 19:46:07 -0000 Hello Hackers I was wondering if anyone has come across this issue. This exists in FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at this time. When a nfs export path and host name total to more then 88 characters mount_nfs bombs out with the following error when it attempts to mount it. mount_nfs: nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms-stage-BK/imagefield_default_images: File name too long I traced this down to a check in mount_nfs.c . This is about line 560 in the 7-STABLE version and 734 in the 9-STABLE version /* * If there has been a trailing slash at mounttime it seems * that some mountd implementations fail to remove the mount * entries from their mountlist while unmounting. */ for (speclen = strlen(spec); speclen > 1 && spec[speclen - 1] == '/'; speclen--) spec[speclen - 1] = '\0'; if (strlen(hostp) + strlen(spec) + 1 > MNAMELEN) { warnx("%s:%s: %s", hostp, spec, strerror(ENAMETOOLONG)); return (0); } Does any one know why the check for hostp + spec +1 to be less then MNAMELEN is there for ? I removed the check on my 9-STABLE box and it mounts the long mounts fine I submitted a pr for this its kern/167105 http://www.freebsd.org/cgi/query-pr.cgi?pr=167105 as there is no mention of this in the man page and I cant find any reason for the check at all. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 19:52:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 270BB1065674 for ; Thu, 19 Apr 2012 19:52:12 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mx1.freebsd.org (Postfix) with ESMTP id 72D988FC0A for ; Thu, 19 Apr 2012 19:52:11 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT5Bs4wTufdVOayw4HCsnBXJsrGGw4WQ3@postini.com; Thu, 19 Apr 2012 12:52:11 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Apr 2012 12:52:03 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Apr 2012 12:52:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 19 Apr 2012 15:52:02 -0400 From: Andrew Duane To: Mark Saad , "freebsd-hackers@freebsd.org" Date: Thu, 19 Apr 2012 15:51:57 -0400 Thread-Topic: mount_nfs does not like exports longer then 88 chars Thread-Index: Ac0eZT6OQKdvMUkiRxe9Wz4XxTToyQAAHEUw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {2233B084-7E3F-43D9-AF7E-7FBA31571E66} x-cr-hashedpuzzle: BqVt DG4v DLGx D0pP IoSU LDNt LlGi LxUz OTnG Sj/8 VTQm WYqH WpHt WwV8 X151 X2LB; 2; ZgByAGUAZQBiAHMAZAAtAGgAYQBjAGsAZQByAHMAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcAOwBuAG8AbgBlAHMAdQBjAGgAQABsAG8AbgBnAGMAbwB1AG4AdAAuAG8AcgBnAA==; Sosha1_v1; 7; {2233B084-7E3F-43D9-AF7E-7FBA31571E66}; YQBkAHUAYQBuAGUAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQA; Thu, 19 Apr 2012 19:51:57 GMT; UgBFADoAIABtAG8AdQBuAHQAXwBuAGYAcwAgAGQAbwBlAHMAIABuAG8AdAAgAGwAaQBrAGUAIABlAHgAcABvAHIAdABzACAAbABvAG4AZwBlAHIAIAB0AGgAZQBuACAAOAA4ACAAYwBoAGEAcgBzAA== acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: RE: mount_nfs does not like exports longer then 88 chars 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, 19 Apr 2012 19:52:12 -0000 TU5BTUVMRU4gaXMgdXNlZCB0byBib3VuZCB0aGUgTW91bnQgTkFNZSBMRU5ndGgsIGFuZCBpcyB1 c2VkIGluIG1hbnkgbWFueSBwbGFjZXMuIEl0IG1heSBzZWVtIHRvIHdvcmsgZmluZSwgYnV0IHRo ZXJlIGFyZSBsb3RzIG9mIHV0aWxpdGllcyBhbmQgc3VjaCB0aGF0IHdpbGwgYWxtb3N0IGNlcnRh aW5seSBmYWlsIG1hbmFnaW5nIGl0LiBTZWFyY2ggdGhlIHNvdXJjZSBjb2RlIGZvciBNTkFNRUxF Ti4uLi4uDQoNCsKgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4NCkFuZHJldyBE dWFuZQ0KSnVuaXBlciBOZXR3b3Jrcw0KKzEgOTc4LTU4OS0wNTUxIChvKQ0KKzEgNjAzLTc3MC03 MDg4IChtKQ0KYWR1YW5lQGp1bmlwZXIubmV0DQoNCsKgDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1mcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcgW21h aWx0bzpvd25lci1mcmVlYnNkLQ0KPiBoYWNrZXJzQGZyZWVic2Qub3JnXSBPbiBCZWhhbGYgT2Yg TWFyayBTYWFkDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxOSwgMjAxMiAzOjQ2IFBNDQo+IFRv OiBmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5vcmcNCj4gU3ViamVjdDogbW91bnRfbmZzIGRvZXMg bm90IGxpa2UgZXhwb3J0cyBsb25nZXIgdGhlbiA4OCBjaGFycw0KPiANCj4gSGVsbG8gSGFja2Vy cw0KPiAgIEkgd2FzIHdvbmRlcmluZyBpZiBhbnlvbmUgaGFzIGNvbWUgYWNyb3NzIHRoaXMgaXNz dWUuIFRoaXMgZXhpc3RzIGluDQo+IEZyZWVCU0QgNiwgNywgYW5kIDkgLCBhbmQgcHJvYmFibHkg aW4gOCBidXQgSSBhbSBub3QgdXNpbmcgaXQgYXQgdGhpcyB0aW1lLg0KPiBXaGVuIGEgbmZzIGV4 cG9ydCBwYXRoIGFuZCBob3N0IG5hbWUgdG90YWwgdG8gbW9yZSB0aGVuIDg4IGNoYXJhY3RlcnMN Cj4gbW91bnRfbmZzIGJvbWJzIG91dCB3aXRoIHRoZSBmb2xsb3dpbmcgZXJyb3Igd2hlbiBpdCBh dHRlbXB0cyB0byBtb3VudCBpdC4NCj4gDQo+IG1vdW50X25mczogbnlpc2lsb24yLTEzLmdycDI6 L2lmcy9jbGllbnRzL3d3dy9jc2FyODg0NTIwNDU2L2ZpbGVzX2Ntcy0gc3RhZ2UtQksvaW1hZ2Vm aWVsZF9kZWZhdWx0X2ltYWdlczoNCj4gRmlsZSBuYW1lIHRvbyBsb25nDQo+IA0KPiBJIHRyYWNl ZCB0aGlzIGRvd24gdG8gYSBjaGVjayBpbiBtb3VudF9uZnMuYyAuIFRoaXMgaXMgYWJvdXQgbGlu ZSA1NjANCj4gaW4gdGhlIDctU1RBQkxFIHZlcnNpb24gIGFuZCAgNzM0IGluIHRoZSA5LVNUQUJM RSB2ZXJzaW9uDQo+IA0KPiANCj4gICAgICAgICAvKg0KPiAgICAgICAgICAqIElmIHRoZXJlIGhh cyBiZWVuIGEgdHJhaWxpbmcgc2xhc2ggYXQgbW91bnR0aW1lIGl0IHNlZW1zDQo+ICAgICAgICAg ICogdGhhdCBzb21lIG1vdW50ZCBpbXBsZW1lbnRhdGlvbnMgZmFpbCB0byByZW1vdmUgdGhlIG1v dW50DQo+ICAgICAgICAgICogZW50cmllcyBmcm9tIHRoZWlyIG1vdW50bGlzdCB3aGlsZSB1bm1v dW50aW5nLg0KPiAgICAgICAgICAqLw0KPiAgICAgICAgIGZvciAoc3BlY2xlbiA9IHN0cmxlbihz cGVjKTsNCj4gICAgICAgICAgICAgICAgIHNwZWNsZW4gPiAxICYmIHNwZWNbc3BlY2xlbiAtIDFd ID09ICcvJzsNCj4gICAgICAgICAgICAgICAgIHNwZWNsZW4tLSkNCj4gICAgICAgICAgICAgICAg IHNwZWNbc3BlY2xlbiAtIDFdID0gJ1wwJzsNCj4gICAgICAgICBpZiAoc3RybGVuKGhvc3RwKSAr IHN0cmxlbihzcGVjKSArIDEgPiBNTkFNRUxFTikgew0KPiAgICAgICAgICAgICAgICAgd2Fybngo IiVzOiVzOiAlcyIsIGhvc3RwLCBzcGVjLCBzdHJlcnJvcihFTkFNRVRPT0xPTkcpKTsNCj4gICAg ICAgICAgICAgICAgIHJldHVybiAoMCk7DQo+ICAgICAgICAgfQ0KPiANCj4gRG9lcyBhbnkgb25l IGtub3cgd2h5IHRoZSBjaGVjayBmb3IgaG9zdHAgKyBzcGVjICsxIHRvIGJlIGxlc3MgdGhlbg0K PiBNTkFNRUxFTiBpcyB0aGVyZSBmb3IgPw0KPiANCj4gIEkgcmVtb3ZlZCB0aGUgY2hlY2sgb24g bXkgOS1TVEFCTEUgYm94IGFuZCBpdCBtb3VudHMgdGhlIGxvbmcgbW91bnRzIGZpbmUNCj4gDQo+ IEkgc3VibWl0dGVkIGEgcHIgZm9yIHRoaXMgaXRzIGtlcm4vMTY3MTA1DQo+IGh0dHA6Ly93d3cu ZnJlZWJzZC5vcmcvY2dpL3F1ZXJ5LXByLmNnaT9wcj0xNjcxMDUgYXMgdGhlcmUgaXMgbm8NCj4g bWVudGlvbiBvZiB0aGlzIGluIHRoZSBtYW4gcGFnZSBhbmQgSSBjYW50IGZpbmQgYW55IHJlYXNv biBmb3IgdGhlIGNoZWNrIGF0IGFsbC4NCj4gDQo+IA0KPiAtLQ0KPiBtYXJrIHNhYWQgfCBub25l c3VjaEBsb25nY291bnQub3JnDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGZyZWVic2QtaGFja2Vyc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QN Cj4gaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1oYWNr ZXJzDQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWhhY2tlcnMt DQo+IHVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 19 20:58:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7D52106566B for ; Thu, 19 Apr 2012 20:58:47 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 320DA8FC0A for ; Thu, 19 Apr 2012 20:58:46 +0000 (UTC) Received: by lbbgm6 with SMTP id gm6so3103255lbb.13 for ; Thu, 19 Apr 2012 13:58:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding :x-gm-message-state; bh=Y6NV1Lubl5wbsuQ6I7EzCW66hEGigAyh0mn+We0CDO8=; b=nCPZxwUEf11prIh0zKONoDcqiwiCZzUWHrWgMd8BHvghhN0W0BSjeLG21ZQJa+TdYw z6v8abnx8Zr4YiRklmefR4hU8HAfY8ZhlH/zNf99kPmL4b1hfJaFty1s6Bk9+JE9YcPT gGxJyPCEfxjQy1s9D9Gew3VZBaAl4J5l9wWV/Nnq8i50azRXzplOsGNrj+yJEj2Ys9UR FFjUNJvSVt1xLxKqTiqWcNq54evT4KyffTYpGWMr3yDUyrR5lXivRuZHS1cXrTz6P6mr iZgERFCU57hp6q2/cw1ngu2eNoktuUiwgzcOMja1c2KZS1KExLEuX9gl1qzgYSSwSXE2 v+iQ== MIME-Version: 1.0 Received: by 10.112.49.5 with SMTP id q5mr1765171lbn.7.1334869124876; Thu, 19 Apr 2012 13:58:44 -0700 (PDT) Received: by 10.112.54.41 with HTTP; Thu, 19 Apr 2012 13:58:44 -0700 (PDT) X-Originating-IP: [216.223.13.111] In-Reply-To: References: Date: Thu, 19 Apr 2012 16:58:44 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQly6yuNo9Lt6jSgdxebKYCkOzxMsnPRrvSx46O3LUvjzmdYYT+oCwMAbLaRhAcv6oEJQ9bH Subject: Re: mount_nfs does not like exports longer then 88 chars 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, 19 Apr 2012 20:58:47 -0000 On Thu, Apr 19, 2012 at 3:51 PM, Andrew Duane wrote: > MNAMELEN is used to bound the Mount NAMe LENgth, and is used in many many= places. It may seem to work fine, but there are lots of utilities and such= that will almost certainly fail managing it. Search the source code for MN= AMELEN..... I see that this is used in a number of Mount and fs bits. Do you know why mount_nfs would care how long the exported path and hostname are ? > > =C2=A0................................... > Andrew Duane > Juniper Networks > +1 978-589-0551=C2=A0(o) > +1 603-770-7088=C2=A0(m) > aduane@juniper.net > > > > >> -----Original Message----- >> From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- >> hackers@freebsd.org] On Behalf Of Mark Saad >> Sent: Thursday, April 19, 2012 3:46 PM >> To: freebsd-hackers@freebsd.org >> Subject: mount_nfs does not like exports longer then 88 chars >> >> Hello Hackers >> =C2=A0 I was wondering if anyone has come across this issue. This exists= in >> FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at this ti= me. >> When a nfs export path and host name total to more then 88 characters >> mount_nfs bombs out with the following error when it attempts to mount i= t. >> >> mount_nfs: nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms- s= tage-BK/imagefield_default_images: >> File name too long >> >> I traced this down to a check in mount_nfs.c . This is about line 560 >> in the 7-STABLE version =C2=A0and =C2=A0734 in the 9-STABLE version >> >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If there has been a trailing slash a= t mounttime it seems >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* that some mountd implementations fai= l to remove the mount >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* entries from their mountlist while u= nmounting. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (speclen =3D strlen(spec); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 speclen > 1 && s= pec[speclen - 1] =3D=3D '/'; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 speclen--) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spec[speclen - 1= ] =3D '\0'; >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (strlen(hostp) + strlen(spec) + 1 > MNAME= LEN) { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 warnx("%s:%s: %s= ", hostp, spec, strerror(ENAMETOOLONG)); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (0); >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 } >> >> Does any one know why the check for hostp + spec +1 to be less then >> MNAMELEN is there for ? >> >> =C2=A0I removed the check on my 9-STABLE box and it mounts the long moun= ts fine >> >> I submitted a pr for this its kern/167105 >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167105 as there is no >> mention of this in the man page and I cant find any reason for the check= at all. >> >> >> -- >> mark saad | nonesuch@longcount.org >> _______________________________________________ >> 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" --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 00:58:50 2012 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 0DB0D106566C for ; Fri, 20 Apr 2012 00:58:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id BA4FE8FC16 for ; Fri, 20 Apr 2012 00:58:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAJKzkE+DaFvO/2dsb2JhbABAA4VnrHCCCQEBAQQBAQEgKyAGBQwNAg4DBAEBAQICDRYDAikBCRUJCAYIBwQBCBQEh24Lp2GTAIEviUKCTIISgRgEk0WCLIERiEaGZYMDgUA X-IronPort-AV: E=Sophos;i="4.75,450,1330923600"; d="scan'208";a="165827263" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Apr 2012 20:58:49 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 18620B4039; Thu, 19 Apr 2012 20:58:49 -0400 (EDT) Date: Thu, 19 Apr 2012 20:58:49 -0400 (EDT) From: Rick Macklem To: Mark Saad Message-ID: <182169197.3115940.1334883529079.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: mount_nfs does not like exports longer then 88 chars 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, 20 Apr 2012 00:58:50 -0000 Mark Saad wrote: > On Thu, Apr 19, 2012 at 3:51 PM, Andrew Duane > wrote: > > MNAMELEN is used to bound the Mount NAMe LENgth, and is used in many > > many places. It may seem to work fine, but there are lots of > > utilities and such that will almost certainly fail managing it. > > Search the source code for MNAMELEN..... >=20 > I see that this is used in a number of Mount and fs bits. Do you know > why mount_nfs would care how long the exported path and hostname are ? >=20 Well, it's copied to f_mntfromname in "struct statfs". If one longer than MNAMELEN is allowed, it gets truncated when copied. I have no idea which userland apps. will get upset with a truncated value in f_mntfromname. (To change the size of f_mntfromname would require a new revision of the statfs syscall, I think?) Does this answer what you were asking? rick > > > > =C2=A0................................... > > Andrew Duane > > Juniper Networks > > +1 978-589-0551 (o) > > +1 603-770-7088 (m) > > aduane@juniper.net > > > > > > > > > >> -----Original Message----- > >> From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > >> hackers@freebsd.org] On Behalf Of Mark Saad > >> Sent: Thursday, April 19, 2012 3:46 PM > >> To: freebsd-hackers@freebsd.org > >> Subject: mount_nfs does not like exports longer then 88 chars > >> > >> Hello Hackers > >> =C2=A0 I was wondering if anyone has come across this issue. This exis= ts > >> =C2=A0 in > >> FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at > >> this time. > >> When a nfs export path and host name total to more then 88 > >> characters > >> mount_nfs bombs out with the following error when it attempts to > >> mount it. > >> > >> mount_nfs: > >> nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms- > >> stage-BK/imagefield_default_images: > >> File name too long > >> > >> I traced this down to a check in mount_nfs.c . This is about line > >> 560 > >> in the 7-STABLE version and 734 in the 9-STABLE version > >> > >> > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* If there has been a trailing slash= at mounttime it seems > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* that some mountd implementations f= ail to remove the > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mount > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* entries from their mountlist while= unmounting. > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/ > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for (speclen =3D strlen(spec); > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 speclen > 1 &&= spec[speclen - 1] =3D=3D '/'; > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 speclen--) > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 spec[speclen -= 1] =3D '\0'; > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (strlen(hostp) + strlen(spec) + 1 > MNA= MELEN) { > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 warnx("%s:%s: = %s", hostp, spec, > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 strerror(ENAME= TOOLONG)); > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return (0); > >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > >> > >> Does any one know why the check for hostp + spec +1 to be less then > >> MNAMELEN is there for ? > >> > >> =C2=A0I removed the check on my 9-STABLE box and it mounts the long > >> =C2=A0mounts fine > >> > >> I submitted a pr for this its kern/167105 > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167105 as there is no > >> mention of this in the man page and I cant find any reason for the > >> check at all. > >> > >> > >> -- > >> mark saad | nonesuch@longcount.org > >> _______________________________________________ > >> 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" >=20 >=20 >=20 > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 03:27:28 2012 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 2779B106566B for ; Fri, 20 Apr 2012 03:27:28 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C99568FC14 for ; Fri, 20 Apr 2012 03:27:27 +0000 (UTC) Received: by vcmm1 with SMTP id m1so8480901vcm.13 for ; Thu, 19 Apr 2012 20:27:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=VS4KND60rDd/SP7O8wJy8KftudHbZtwPCwV/jHw1G9c=; b=NWCYJAHhLCeqcZyrn9+g5FLd0EepOn9YHmERb/ZQScVV563Qbl71CXhVZmmiF66UM/ ppexQsO+y4jVaOENKF7vqFjF8EvnlWxe76UZLII6IkdRSOKUfV4BUt+NROa+dlBQt+xt Vt6fwH8jx5eU02XDIqRnJfd9lXPGtSGCYVUXtjd95v7+rEgvhSwpURdxaEq5yKtvS5dP L7nrJMdQD8oJyB3WuAuBhu5EfSLcAwzoYeMlp1MnIxQmbkGFxmQifFVTYXQdQbaPEOhi Q2h2WaKdtY22J4lTlfWCrZpWdhK2Q2GAgJpOWfwu+3LlZ0kpb8MpPn1n7Xm8/zZh2UxW 7kMA== Received: by 10.220.153.8 with SMTP id i8mr2925834vcw.73.1334892446788; Thu, 19 Apr 2012 20:27:26 -0700 (PDT) Received: from [192.168.11.202] (ool-182c8651.dyn.optonline.net. [24.44.134.81]) by mx.google.com with ESMTPS id d7sm5314978vdu.15.2012.04.19.20.27.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 20:27:25 -0700 (PDT) References: <182169197.3115940.1334883529079.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <182169197.3115940.1334883529079.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B179) From: Mark Saad Date: Thu, 19 Apr 2012 23:27:22 -0400 To: Rick Macklem X-Gm-Message-State: ALoCoQk6KA7lwbguExIPILFyq6fEPhGfiPpd0/j+bXD8lw+wxjUEKzEGRWbbRgNSKSH8iPwBISJ8 Cc: "freebsd-hackers@freebsd.org" Subject: Re: mount_nfs does not like exports longer then 88 chars 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, 20 Apr 2012 03:27:28 -0000 On Apr 19, 2012, at 8:58 PM, Rick Macklem wrote: > Mark Saad wrote: >> On Thu, Apr 19, 2012 at 3:51 PM, Andrew Duane >> wrote: >>> MNAMELEN is used to bound the Mount NAMe LENgth, and is used in many >>> many places. It may seem to work fine, but there are lots of >>> utilities and such that will almost certainly fail managing it. >>> Search the source code for MNAMELEN..... >>=20 >> I see that this is used in a number of Mount and fs bits. Do you know >> why mount_nfs would care how long the exported path and hostname are ? >>=20 > Well, it's copied to f_mntfromname in "struct statfs". If one longer > than MNAMELEN is allowed, it gets truncated when copied. I have no idea > which userland apps. will get upset with a truncated value in > f_mntfromname. (To change the size of f_mntfromname would require a new > revision of the statfs syscall, I think?) >=20 > Does this answer what you were asking? rick >=20 Yes and no, it smells like a bug ,in so far as its not mentioned anywhere ou= t there . A one line addition to mount_nfs man page stipulating that there i= s a known limit on the length of the host name and source export would be he= lpful. =20 On the other hand 88 bytes seams like an odd size to me . The check for the= size happens twice in the 7-stable code ,for mount_nfs, and only once in th= e 9-stable code . Not sure why either, and i did bot research it yet. In th= e mean time I am going to take a peak at the other bsd's and see if there is= a solution .=20 >>>=20 >>> ................................... >>> Andrew Duane >>> Juniper Networks >>> +1 978-589-0551 (o) >>> +1 603-770-7088 (m) >>> aduane@juniper.net >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- >>>> hackers@freebsd.org] On Behalf Of Mark Saad >>>> Sent: Thursday, April 19, 2012 3:46 PM >>>> To: freebsd-hackers@freebsd.org >>>> Subject: mount_nfs does not like exports longer then 88 chars >>>>=20 >>>> Hello Hackers >>>> I was wondering if anyone has come across this issue. This exists >>>> in >>>> FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at >>>> this time. >>>> When a nfs export path and host name total to more then 88 >>>> characters >>>> mount_nfs bombs out with the following error when it attempts to >>>> mount it. >>>>=20 >>>> mount_nfs: >>>> nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms- >>>> stage-BK/imagefield_default_images: >>>> File name too long >>>>=20 >>>> I traced this down to a check in mount_nfs.c . This is about line >>>> 560 >>>> in the 7-STABLE version and 734 in the 9-STABLE version >>>>=20 >>>>=20 >>>> /* >>>> * If there has been a trailing slash at mounttime it seems >>>> * that some mountd implementations fail to remove the >>>> mount >>>> * entries from their mountlist while unmounting. >>>> */ >>>> for (speclen =3D strlen(spec); >>>> speclen > 1 && spec[speclen - 1] =3D=3D '/'; >>>> speclen--) >>>> spec[speclen - 1] =3D '\0'; >>>> if (strlen(hostp) + strlen(spec) + 1 > MNAMELEN) { >>>> warnx("%s:%s: %s", hostp, spec, >>>> strerror(ENAMETOOLONG)); >>>> return (0); >>>> } >>>>=20 >>>> Does any one know why the check for hostp + spec +1 to be less then >>>> MNAMELEN is there for ? >>>>=20 >>>> I removed the check on my 9-STABLE box and it mounts the long >>>> mounts fine >>>>=20 >>>> I submitted a pr for this its kern/167105 >>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167105 as there is no >>>> mention of this in the man page and I cant find any reason for the >>>> check at all. >>>>=20 >>>>=20 >>>> -- >>>> mark saad | nonesuch@longcount.org >>>> _______________________________________________ >>>> 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" >>=20 >>=20 >>=20 >> -- >> mark saad | nonesuch@longcount.org >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 13:36:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0299106564A for ; Fri, 20 Apr 2012 13:36:16 +0000 (UTC) (envelope-from fk@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by mx1.freebsd.org (Postfix) with ESMTP id A9BB98FC0C for ; Fri, 20 Apr 2012 13:36:16 +0000 (UTC) Received: from [109.85.197.253] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SLDz9-0003rG-B4; Fri, 20 Apr 2012 15:34:51 +0200 Date: Fri, 20 Apr 2012 15:34:43 +0200 From: Fabian Keil To: Ryan Stone Message-ID: <20120420153443.207738a3.fk@fabiankeil.de> In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/.QPo/nT0fhTI.Lf3A.=fTQp"; protocol="application/pgp-signature" X-Df-Sender: MTgwOTA5 X-Mailman-Approved-At: Fri, 20 Apr 2012 13:51:51 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Implementation of DTrace sched provider (with bonus schedgraph script) 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, 20 Apr 2012 13:36:17 -0000 --Sig_/.QPo/nT0fhTI.Lf3A.=fTQp Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ryan Stone wrote: > I've implemented the sched provider for FreeBSD. This provider > provides probes that fire when various scheduling decisions are made. Thanks a lot. Works for me (so far) with HEAD on amd64. Fabian --Sig_/.QPo/nT0fhTI.Lf3A.=fTQp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+RZfoACgkQSMVSH78upWOomwCfcKGynYrSh78dqANSgUEM/lJ4 XTMAn0RzU8H/YbH1mHP1E8hfj9C4U4G/ =SqxB -----END PGP SIGNATURE----- --Sig_/.QPo/nT0fhTI.Lf3A.=fTQp-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 15:04:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9545106566B for ; Fri, 20 Apr 2012 15:04:21 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA318FC1A for ; Fri, 20 Apr 2012 15:04:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q3KF42Uq096409 for ; Fri, 20 Apr 2012 17:04:06 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q3KF3wxr096406 for ; Fri, 20 Apr 2012 17:04:02 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 20 Apr 2012 17:03:58 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 20 Apr 2012 17:04:06 +0200 (CEST) Subject: what's wrong with cd9660 fs 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, 20 Apr 2012 15:04:21 -0000 i created for test ISO image with 6GB file in it using mkisofs -rJ --iso-level 3 -o /path_to/file.iso . worked fine. tar tvf file.iso shows things fine. even windoze under virtualbox with file.iso mounted as CD/DVD - works fine, and see 6GB file. did mdconfig -a -t vnode -f file.iso and mount_cd9660 /dev/md0 /mnt and i see TWO 4 gigabyte files with the same name! am i doing something wrong or it is a bug/lack of support? with blu-ray disks it would be rather common to have >4GB files recorded. of course i could write UFS disks, but i want them readable on non-unix OS. From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 18:16:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7561C1065674; Fri, 20 Apr 2012 18:16:46 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F90F8FC22; Fri, 20 Apr 2012 18:16:46 +0000 (UTC) Received: by vbmv11 with SMTP id v11so9256185vbm.13 for ; Fri, 20 Apr 2012 11:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nMepNO5cmPZXV5xvNYsEW0OnvvtNK9hGqtPqBmYXmc4=; b=RklNCrq6R11JoMtu320kqp73904Fu2wgdHh0jSoSmcGyA3yAMLZUApsDhfR2zMP5OI 4Sl65lJLQPpreQvJue8jLpQQDw3h295PM/rFLCAb/Xoko19ppcBz5LZBqKs6LQ8ZE8pY WVrhSN1B1pHDpCZGsNdLvvhVCWTeF5i8F0WkOjpPz2b8I6wcQwSSLUSGgZ3eMVS7+hKk Vh3bWkCnuqJdDLQLuXdXrhmDfVL5ereFgW9vTl7hXzoBONIs+dMMtNC0b45yR0op5Nsb 5oSqyqOpNHgmDiqUt7POD1tli1ANzS9aNXpXuSdslfCHsK+luct1gnsmGtY1WS7Tmph9 pSaA== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr814327vcw.20.1334945805489; Fri, 20 Apr 2012 11:16:45 -0700 (PDT) Received: by 10.220.18.16 with HTTP; Fri, 20 Apr 2012 11:16:45 -0700 (PDT) Date: Fri, 20 Apr 2012 14:16:45 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Disabling an arbitrary device 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, 20 Apr 2012 18:16:46 -0000 Hi, I will be bringing up an old thread there, but it would seem the situation did not evolve in the past 9 years. I have a machine running 7.1 whose UHCI controller is generating some interrupt storm: # vmstat -i interrupt total rate irq4: sio0 1328 2 irq19: uhci1+ 63514509 96380 [...] generating useless load on one CPU: # top -SH last pid: 5223; load averages: 0.00, 0.00, 0.00 up 0+00:17:21 13:10:35 117 processes: 14 running, 79 sleeping, 24 waiting CPU: 0.2% user, 0.0% nice, 0.2% system, 6.6% interrupt, 93.0% idle Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Free [...] 57 root -64 - 0K 8K CPU0 0 11:59 86.57% irq19: uhci1+ I thought I could use an hint to forbid uhci(4) attachment, ala: hint.uhci.0.disabled="1" hint.uhci.1.disabled="1" in /boot/loader.conf. However, it would seem that what should be usable with any arbitrary devices, ie. be an integral part of device(9), has to be hardcoded in every driver, sad. - Arnaud ps: the original thread I found is from September 2004: http://lists.freebsd.org/pipermail/freebsd-questions/2004-September/058717.html From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 18:18:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A02FC106566B; Fri, 20 Apr 2012 18:18:30 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3823D8FC08; Fri, 20 Apr 2012 18:18:30 +0000 (UTC) Received: by vbmv11 with SMTP id v11so9257777vbm.13 for ; Fri, 20 Apr 2012 11:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=2fde7twC4oCNCwK5Gkp0baChbIj1MCbtGaniPUd3JCg=; b=SPVAZUrxPmh3cgUSkvD9BUNdvhJ8Z0GvF2erdajzEaD+jMWWKA9hSU+JlTuRTpk0mk xM2MJX+ZOPG1Etpr3CB9uG/Q6osv8MPqYqKH3AjecZ9VHBnlRs8CWjqsL/v0IOIcZDP3 XhqXdQ/4b008QBmBtUXgGnqLxMMayH9yNp7Tma+O5NrJW9o9kH2rLzwiLVg70oJfkAw1 PgloXFlAg34qpwvvYc++e6U45qsgFuJIC/kDMpXIW0RjcTEPIeaO3iM4GyjsOUIwUHIm rk6J4A910Amly3n2+do249Ssmwg0Hq/c3WTgOKMr4HKgi53o/1Rrc+gAz2xNWhIr81fe UWFA== MIME-Version: 1.0 Received: by 10.52.172.172 with SMTP id bd12mr4819915vdc.69.1334945909700; Fri, 20 Apr 2012 11:18:29 -0700 (PDT) Received: by 10.220.18.16 with HTTP; Fri, 20 Apr 2012 11:18:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Apr 2012 14:18:29 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Disabling an arbitrary device 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, 20 Apr 2012 18:18:30 -0000 Hi, On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe wrote: > Hi, > > I will be bringing up an old thread there, but it would seem the > situation did not evolve in the past 9 years. I have a machine running > 7.1 whose UHCI controller is generating some interrupt storm: > > # vmstat -i > interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate > irq4: sio0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01328 =A0 = =A0 =A0 =A0 =A02 > irq19: uhci1+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 63514509 =A0 =A0 =A0963= 80 > [...] > > generating useless load on one CPU: > > # top -SH > last pid: =A05223; =A0load averages: =A00.00, =A00.00, =A00.00 =A0 =A0up = 0+00:17:21 =A013:10:35 > 117 processes: 14 running, 79 sleeping, 24 waiting > CPU: =A00.2% user, =A00.0% nice, =A00.2% system, =A06.6% interrupt, 93.0%= idle > Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Free > [...] > =A0 57 root =A0 =A0 =A0 =A0 =A0-64 =A0 =A0- =A0 =A0 0K =A0 =A0 8K CPU0 = =A0 0 =A011:59 86.57% irq19: uhci1+ > > I thought I could use an hint to forbid uhci(4) attachment, ala: > > hint.uhci.0.disabled=3D"1" > hint.uhci.1.disabled=3D"1" > > in /boot/loader.conf. However, it would seem that what should be > usable with any arbitrary devices, ie. be an integral part of > device(9), has to be hardcoded in every driver, sad. > as for the usual "if you're not happy, please provide a patch": https://github.com/lacombar/freebsd/commit/30786d09b0cb441890cdc749ee524323= 8e81d2d8 regards, - Arnaud > =A0- Arnaud > > ps: the original thread I found is from September 2004: > http://lists.freebsd.org/pipermail/freebsd-questions/2004-September/05871= 7.html From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 20 18:25:58 2012 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 693551065673 for ; Fri, 20 Apr 2012 18:25:58 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id CF3968FC14 for ; Fri, 20 Apr 2012 18:25:57 +0000 (UTC) Received: (qmail invoked by alias); 20 Apr 2012 18:25:51 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp004) with SMTP; 20 Apr 2012 20:25:51 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX1/u5pojGv/uerAtOAayRIQVKbZw5YeuBGgQIYeHXd AuHF5y+EdjaYLK Date: Fri, 20 Apr 2012 20:26:36 +0200 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org References: In-Reply-To: Message-Id: <99329673623314@192.168.2.69> X-Y-GMX-Trusted: 0 Cc: wojtek@wojtek.tensor.gdynia.pl Subject: Re: what's wrong with cd9660 fs 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, 20 Apr 2012 18:25:58 -0000 Hi, > mkisofs -rJ --iso-level 3 -o /path_to/file.iso . > and i see TWO 4 gigabyte files with the same name! This happens too on my "8.0-STABLE Mar 23 14:55:20 CET 2010". FreeBSD is probably not alone with this. An example image can be found at https://dev.haiku-os.org/attachment/ticket/8473/file_of_4gb.iso.bz2 compressed 25 KiB bzip2, uncompressed 4.1 GiB ISO 9660 image with "file_of_4gb" having 2 extents. The content of the image root directory should be: $ ls f* -rw-r--r-- 1 1000 1000 4297064448 Apr 16 13:00 file_of_4gb But on FreeBSD i get this: $ bunzip2 file_of_4gb.iso.bz2 # su Password: # mdconfig -a -t vnode -f file_of_4gb.iso md1 # mount_cd9660 /dev/md1 /mnt # ls -l /mnt/f* -rw-r--r-- 1 1000 1000 4294965248 Apr 16 13:00 file_of_4gb -rw-r--r-- 1 1000 1000 4294965248 Apr 16 13:00 file_of_4gb Omitting Rock Ridge interpretation changes the result: # umount /mnt # mount_cd9660 -r /dev/md1 /mnt # ls -l /mnt/f* -r-xr-xr-x 1 root wheel 2099200 Apr 16 13:00 file_of_4gb This is a skewed reflection of the image entrails: The file content is stored in two file sections (see also ECMA-119 6.5.1). The directory records of both sections bear the same File Identifier (struct iso_directory_record.name), but different Location of Extent (struct iso_directory_record.extent) and Data Length (struct iso_directory_record.size). One extent begins at block 55 (= .extent) and has 4294965248 bytes (= .size). The other begins at block 2097206 and has 2099200 bytes. Afaics in my local copy of /usr/src/sys/fs/cd9660/cd9660_node.h there is a 1:1 relation between struct iso_node and ECMA-119 extents: long iso_extent; /* extent of file */ unsigned long i_size; In /usr/src/sys/fs/cd9660/cd9660_vfsops.c i believe to see a 1:1 relation between struct vnode and struct iso_node: vp->v_data = ip; ip->i_vnode = vp; But there would be needed a 1:N relation between inode and ECMA-119 extents in order to represent large files. I am currently trying to understand how fs/udf handles multiple extents. /usr/src/sys/fs/udf/udf_vnops.c bears in function udf_bmap_internal() a comment: * If the offset is beyond the current extent, look for the * next extent. Have a nice day :) Thomas From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 00:22:45 2012 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 F15711065670; Sat, 21 Apr 2012 00:22:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id D16568FC12; Sat, 21 Apr 2012 00:22:45 +0000 (UTC) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 2358EF397; Fri, 20 Apr 2012 17:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1334967759; bh=BhDwmrf23lopWQaBqa+7qhQQI487kMZA+SED/rmZ14s=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=WPRYZR/fHJlws5sITcAV/pjO01VoT9qsVUhpqoJxZjt5Ej1bidw8LQdsGylMYTWwv LaAFFpUcmkHWiXwIgb1JrQvdyspzQqBJ+3ji84Bo25MvJNZGtXBrdSUiYpnpb/TSFc tiAKJ3BkNOb5a0jQtYt2adG+jPgdwIUTOMQTfKJk= Message-ID: <4F91FDCE.7020600@delphij.net> Date: Fri, 20 Apr 2012 17:22:38 -0700 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: Barkley Vowk References: <4F8FBEEC.6060509@delphij.net> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, d@delphij.net, freebsd-hardware@freebsd.org Subject: Re: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 00:22:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 04/20/12 17:16, Barkley Vowk wrote: > It doesn't seem to work. I've got 22 2.0TB SATA disks, and a 120GB > Intel SSD attached, I get these messages, and the drives all show > in dmesg and /dev. > > But if I try writing to any of them, the process just hangs. What does Ctrl+T says when it hangs? Also, it would be helpful if you can obtain a 'procstat -kk -a' output (please run as root). > Anyone reported success with the 2760A? > > > hpt27xx: RocketRAID 27xx controller driver v1.0 (Apr 19 2012 > 11:02:42) hpt27xx: Attached device index 00 (Path 00 | Target 00 | > E0/Sff) 500c5020e95b8d hpt27xx: Attached device index 01 (Path 01 > | Target 00 | E0/Sff) 500c5020e96089 hpt27xx: Attached device > index 02 (Path 02 | Target 00 | E0/Sff) 500c5010439cd5 hpt27xx: > Attached device index 03 (Path 03 | Target 00 | E0/Sff) > 500c5020c75ac1 hpt27xx: Attached device index 00 (Path 00 | Target > 00 | E0/Sff) 500c5020e9918d hpt27xx: Attached device index 01 > (Path 01 | Target 00 | E0/Sff) 500c5020e987f9 hpt27xx: Attached > device index 02 (Path 02 | Target 00 | E0/Sff) 500c5020d1add > hpt27xx: Attached device index 03 (Path 03 | Target 00 | E0/Sff) > 500c5020e2205d hpt27xx: Attached device index 40 (Path 04 | Target > 00 | E0/Sff) 500c5020e387f1 hpt27xx: Attached device index 41 > (Path 05 | Target 00 | E0/Sff) 500c5020e4eadd hpt27xx: Attached > device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020e47ff1 > hpt27xx: Attached device index 43 (Path 07 | Target 00 | E0/Sff) > 500c5020e4ec91 hpt27xx: Attached device index 40 (Path 04 | Target > 00 | E0/Sff) 500c5020e9607d hpt27xx: Attached device index 41 > (Path 05 | Target 00 | E0/Sff) 500c5020e4801 hpt27xx: Attached > device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020e4e7f1 > hpt27xx: Attached device index 43 (Path 07 | Target 00 | E0/Sff) > 500c5020d0ec39 hpt27xx: Attached device index 00 (Path 00 | Target > 00 | E0/Sff) 500c5020e95b91 hpt27xx: Attached device index 01 > (Path 01 | Target 00 | E0/Sff) 00000000 hpt27xx: Attached device > index 02 (Path 02 | Target 00 | E0/Sff) 500c5020e96359 hpt27xx: > Attached device index 03 (Path 03 | Target 00 | E0/Sff) > 500c5020e4e629 hpt27xx: Attached device index 40 (Path 04 | Target > 00 | E0/Sff) 500c5020d2d69d hpt27xx: Attached device index 41 > (Path 05 | Target 00 | E0/Sff) 500c5020e95b11 hpt27xx: Attached > device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020ea1219 > hpt27xx2: [GIANT-LOCKED] hpt27xx2: [ITHREAD] hpt27xx1: > [GIANT-LOCKED] hpt27xx1: [ITHREAD] hpt27xx0: [GIANT-LOCKED] > hpt27xx0: [ITHREAD] > > > da0 at hpt27xx0 bus 0 scbus8 target 0 lun 0 da0: 4.00> Fixed Direct Access SCSI-0 device da0: 1907729MB (3907029168 > 512 byte sectors: 255H 63S/T 243201C) da1 at hpt27xx0 bus 0 scbus8 > target 1 lun 0 da1: Fixed Direct Access SCSI-0 > device da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T > 243201C) da2 at hpt27xx0 bus 0 scbus8 target 2 lun 0 da2: 0_2 4.00> Fixed Direct Access SCSI-0 device da2: 1907729MB > (3907029168 512 byte sectors: 255H 63S/T 243201C) da3 at hpt27xx0 > bus 0 scbus8 target 3 lun 0 da3: Fixed Direct > Access SCSI-0 device da3: 1907729MB (3907029168 512 byte sectors: > 255H 63S/T 243201C) da4 at hpt27xx0 bus 0 scbus8 target 4 lun 0 > da4: Fixed Direct Access SCSI-0 device da4: > 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da5 at > hpt27xx0 bus 0 scbus8 target 5 lun 0 da5: Fixed > Direct Access SCSI-0 device da5: 1907729MB (3907029168 512 byte > sectors: 255H 63S/T 243201C) da6 at hpt27xx0 bus 0 scbus8 target 6 > lun 0 da6: Fixed Direct Access SCSI-0 device > da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da7 at hpt27xx0 bus 0 scbus8 target 7 lun 0 da7: 4.00> Fixed Direct Access SCSI-0 device da7: 1907729MB (3907029168 > 512 byte sectors: 255H 63S/T 243201C) da8 at hpt27xx0 bus 0 scbus8 > target 8 lun 0 da8: Fixed Direct Access SCSI-0 > device da8: 1907729MB (3907029168 512 byte sectors: 255H 63S/T > 243201C) da9 at hpt27xx0 bus 0 scbus8 target 9 lun 0 da9: 0_9 4.00> Fixed Direct Access SCSI-0 device da9: 1907729MB > (3907029168 512 byte sectors: 255H 63S/T 243201C) da10 at hpt27xx0 > bus 0 scbus8 target 10 lun 0 da10: Fixed > Direct Access SCSI-0 device da10: 1907729MB (3907029168 512 byte > sectors: 255H 63S/T 243201C) da11 at hpt27xx0 bus 0 scbus8 target > 11 lun 0 da11: Fixed Direct Access SCSI-0 > device da11: 1907729MB (3907029168 512 byte sectors: 255H 63S/T > 243201C) da12 at hpt27xx0 bus 0 scbus8 target 12 lun 0 da12: DISK 0_12 4.00> Fixed Direct Access SCSI-0 device da12: 1907729MB > (3907029168 512 byte sectors: 255H 63S/T 243201C) da13 at hpt27xx0 > bus 0 scbus8 target 13 lun 0 da13: Fixed > Direct Access SCSI-0 device da13: 1907729MB (3907029168 512 byte > sectors: 255H 63S/T 243201C) da14 at hpt27xx0 bus 0 scbus8 target > 14 lun 0 da14: Fixed Direct Access SCSI-0 > device da14: 1907729MB (3907029168 512 byte sectors: 255H 63S/T > 243201C) da15 at hpt27xx0 bus 0 scbus8 target 15 lun 0 da15: DISK 0_15 4.00> Fixed Direct Access SCSI-0 device da15: 1907729MB > (3907029168 512 byte sectors: 255H 63S/T 243201C) da16 at hpt27xx0 > bus 0 scbus8 target 16 lun 0 da16: Fixed > Direct Access SCSI-0 device da16: 114473MB (234441648 512 byte > sectors: 255H 63S/T 14593C) da17 at hpt27xx0 bus 0 scbus8 target 17 > lun 0 da17: Fixed Direct Access SCSI-0 device > da17: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > da18 at hpt27xx0 bus 0 scbus8 target 18 lun 0 da18: 4.00> Fixed Direct Access SCSI-0 device da18: 1907729MB (3907029168 > 512 byte sectors: 255H 63S/T 243201C) da19 at hpt27xx0 bus 0 scbus8 > target 19 lun 0 da19: Fixed Direct Access > SCSI-0 device da19: 1907729MB (3907029168 512 byte sectors: 255H > 63S/T 243201C) da20 at hpt27xx0 bus 0 scbus8 target 20 lun 0 da20: > Fixed Direct Access SCSI-0 device da20: > 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da21 at > hpt27xx0 bus 0 scbus8 target 21 lun 0 da21: > Fixed Direct Access SCSI-0 device da21: 1907729MB (3907029168 512 > byte sectors: 255H 63S/T 243201C) da22 at hpt27xx0 bus 0 scbus8 > target 22 lun 0 da22: Fixed Direct Access > SCSI-0 device da22: 1907729MB (3907029168 512 byte sectors: 255H > 63S/T 243201C) > > > On Thu, Apr 19, 2012 at 12:29 AM, Xin Li > wrote: On 04/12/12 10:14, Barkley Vowk wrote: >>>> I've got a Highpoint 2760A card that I'd like a FreeBSD >>>> driver for, I've got a machine and disks available if someone >>>> wants to tackle that. > > Please try loading 'hpt27xx.ko' on boot. > > Cheers, >> _______________________________________________ >> freebsd-hardware@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To >> unsubscribe, send any mail to >> "freebsd-hardware-unsubscribe@freebsd.org" >> - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJPkf3OAAoJEG80Jeu8UPuzAzcH/1GqBOF9QAx8DtSD8wpO3bAo ryS5hUgdr6wCuFvPZqIIel3eS8+U1nL/sVDuOdI2Z52S/PTXg56nDLaR6+HKns3v Bv/rrftLlMouQDawfB53Qa0dHLjZiU0oiQ+k5Ocol7Y57+PTLYpUxRfhti6mFMSg bdsQGpmY+jmshhTWki8PF5W8tDu8ucaSrGwUG4yOuXZZ7oZvMsT4K4Sz+LkGFg6s XAOTVNhYRuRoY9o7rTazMH3PATu9K7oxLRnR0WQcKMAcjpI+Df4QNgguVOMhPYMj j+MId0x8iZQe8JdkAx1UjNUWOjDJvQgqJfhYvC6FQ4iHdTuaea+vKTpw0dK8U1A= =mPEE -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 00:50:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3241065726; Sat, 21 Apr 2012 00:50:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D54538FC1E; Sat, 21 Apr 2012 00:50:07 +0000 (UTC) Received: by vcmm1 with SMTP id m1so9451669vcm.13 for ; Fri, 20 Apr 2012 17:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HwoTQmt2xZGx2bbCgYslpUzJLV4IruOEUhMLvttBSqQ=; b=LLzHZ6YQzMQmVWxz3FfcCxdHXadVTQr2+ny7Pat1h8+n8dYl4jMMa+NFQ8X8RnvtYj rjfJmtGCuIOCgw3IKB7JyzpgBDNSR4IA0rl0+2S40PGTTyQcdFjD1cRwfmCrh+T2kBeX HFriUQWwI9dg/HfVaoRo36OxIDEm7vpsLWkqni+PG9E/KA0kjzOdUX2+ckhLtRGu2yC9 QZAy7Bu5kE+5gfs5S++Xf9rT22AzvFZBHAKj8HSmZVsmr1JbKyERGs5clwWjZ6h8zIxR flpeCt0frJmi7tC4+fNMJZX9ewpS+xk8N54k+42wT9DS7DP+381o2Tf3GjZAJMmBgF4M AYng== MIME-Version: 1.0 Received: by 10.220.152.205 with SMTP id h13mr7274524vcw.12.1334969407189; Fri, 20 Apr 2012 17:50:07 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.220.38.72 with HTTP; Fri, 20 Apr 2012 17:50:07 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Apr 2012 01:50:07 +0100 X-Google-Sender-Auth: dO88HP27lLp6obnohaDnF_n9ehs Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Disabling an arbitrary device 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, 21 Apr 2012 00:50:13 -0000 Il 20 aprile 2012 19:18, Arnaud Lacombe ha scritto: > Hi, > > On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe wrot= e: >> Hi, >> >> I will be bringing up an old thread there, but it would seem the >> situation did not evolve in the past 9 years. I have a machine running >> 7.1 whose UHCI controller is generating some interrupt storm: >> >> # vmstat -i >> interrupt =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0total =C2=A0 =C2=A0 =C2=A0 rate >> irq4: sio0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01328 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02 >> irq19: uhci1+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 63514509 =C2=A0 =C2=A0 =C2=A096380 >> [...] >> >> generating useless load on one CPU: >> >> # top -SH >> last pid: =C2=A05223; =C2=A0load averages: =C2=A00.00, =C2=A00.00, =C2= =A00.00 =C2=A0 =C2=A0up 0+00:17:21 =C2=A013:10:35 >> 117 processes: 14 running, 79 sleeping, 24 waiting >> CPU: =C2=A00.2% user, =C2=A00.0% nice, =C2=A00.2% system, =C2=A06.6% int= errupt, 93.0% idle >> Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Free >> [...] >> =C2=A0 57 root =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-64 =C2=A0 =C2=A0- =C2= =A0 =C2=A0 0K =C2=A0 =C2=A0 8K CPU0 =C2=A0 0 =C2=A011:59 86.57% irq19: uhci= 1+ >> >> I thought I could use an hint to forbid uhci(4) attachment, ala: >> >> hint.uhci.0.disabled=3D"1" >> hint.uhci.1.disabled=3D"1" >> >> in /boot/loader.conf. However, it would seem that what should be >> usable with any arbitrary devices, ie. be an integral part of >> device(9), has to be hardcoded in every driver, sad. >> > as for the usual "if you're not happy, please provide a patch": > > https://github.com/lacombar/freebsd/commit/30786d09b0cb441890cdc749ee5243= 238e81d2d8 I think a generalized kludge should really belong to device_probe_child() rather than device_add_child_ordered(). When you have a tested patch against -CURRENT, can you please send to freebsd-newbus@? BTW, IIRC 7.x doesn't have the new USB stack, which means that you can have caught easilly a driver bug there, did you consider switching at least to 8.x kernel? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 00:16:43 2012 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 A1AB2106566B for ; Sat, 21 Apr 2012 00:16:43 +0000 (UTC) (envelope-from bvowk@ualberta.ca) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 60D698FC0A for ; Sat, 21 Apr 2012 00:16:43 +0000 (UTC) Received: by obqv19 with SMTP id v19so14840412obq.13 for ; Fri, 20 Apr 2012 17:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Oz71FcTBkLD/oiDt19Ai+YLrvaMjENV8/POUYu/9KrQ=; b=NabICK0vyCfVw7YuI6b5kN3eCRmryV0wWlWdEjsJOe9CCFT8mJmpTD2X/uqVECQwwJ tbgz5lI7Qdg68ROL35gPt1vQeuXCnDamM/qTTBPlJT7iPdHTgWjp9sqWfS0L5bwxK/BC BgMF3DwZQXtkqPj3m73sxBGKmBNK+n1jJ/xCokODqxrjblUf17MtfA4bsKA+M//goxUl /FrNy1FMMektfwI8yIjftdzhYKMIuJ7s6WLmknBL0TSQnIpOlldnrP3OAvgEzTt/4UYY RcDx/Ng1O+YMnEBwhl6wIPr+jhR4q5ajBJGhasVDrkBW5MbX4jqB6anenNK8FPgXf7ZF XZxQ== MIME-Version: 1.0 Received: by 10.60.18.137 with SMTP id w9mr11452854oed.7.1334967402932; Fri, 20 Apr 2012 17:16:42 -0700 (PDT) Received: by 10.60.124.199 with HTTP; Fri, 20 Apr 2012 17:16:42 -0700 (PDT) In-Reply-To: <4F8FBEEC.6060509@delphij.net> References: <4F8FBEEC.6060509@delphij.net> Date: Fri, 20 Apr 2012 17:16:42 -0700 Message-ID: From: Barkley Vowk To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnuoqtteWP/dFMtpmPkGx9WvNZtLuxT8YyJO9RY4ejCdUPhBrk9gILj2dn4Jc0mUogiPP+X X-Mailman-Approved-At: Sat, 21 Apr 2012 01:06:03 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Highpoint 2760A / Marvell 88SE9485 SAS HBA Drivers? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 00:16:43 -0000 It doesn't seem to work. I've got 22 2.0TB SATA disks, and a 120GB Intel SSD attached, I get these messages, and the drives all show in dmesg and /dev. But if I try writing to any of them, the process just hangs. Anyone reported success with the 2760A? hpt27xx: RocketRAID 27xx controller driver v1.0 (Apr 19 2012 11:02:42) hpt27xx: Attached device index 00 (Path 00 | Target 00 | E0/Sff) 500c5020e= 95b8d hpt27xx: Attached device index 01 (Path 01 | Target 00 | E0/Sff) 500c5020e= 96089 hpt27xx: Attached device index 02 (Path 02 | Target 00 | E0/Sff) 500c50104= 39cd5 hpt27xx: Attached device index 03 (Path 03 | Target 00 | E0/Sff) 500c5020c= 75ac1 hpt27xx: Attached device index 00 (Path 00 | Target 00 | E0/Sff) 500c5020e= 9918d hpt27xx: Attached device index 01 (Path 01 | Target 00 | E0/Sff) 500c5020e= 987f9 hpt27xx: Attached device index 02 (Path 02 | Target 00 | E0/Sff) 500c5020d= 1add hpt27xx: Attached device index 03 (Path 03 | Target 00 | E0/Sff) 500c5020e= 2205d hpt27xx: Attached device index 40 (Path 04 | Target 00 | E0/Sff) 500c5020e= 387f1 hpt27xx: Attached device index 41 (Path 05 | Target 00 | E0/Sff) 500c5020e= 4eadd hpt27xx: Attached device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020e= 47ff1 hpt27xx: Attached device index 43 (Path 07 | Target 00 | E0/Sff) 500c5020e= 4ec91 hpt27xx: Attached device index 40 (Path 04 | Target 00 | E0/Sff) 500c5020e= 9607d hpt27xx: Attached device index 41 (Path 05 | Target 00 | E0/Sff) 500c5020e= 4801 hpt27xx: Attached device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020e= 4e7f1 hpt27xx: Attached device index 43 (Path 07 | Target 00 | E0/Sff) 500c5020d= 0ec39 hpt27xx: Attached device index 00 (Path 00 | Target 00 | E0/Sff) 500c5020e= 95b91 hpt27xx: Attached device index 01 (Path 01 | Target 00 | E0/Sff) 00000000 hpt27xx: Attached device index 02 (Path 02 | Target 00 | E0/Sff) 500c5020e= 96359 hpt27xx: Attached device index 03 (Path 03 | Target 00 | E0/Sff) 500c5020e= 4e629 hpt27xx: Attached device index 40 (Path 04 | Target 00 | E0/Sff) 500c5020d= 2d69d hpt27xx: Attached device index 41 (Path 05 | Target 00 | E0/Sff) 500c5020e= 95b11 hpt27xx: Attached device index 42 (Path 06 | Target 00 | E0/Sff) 500c5020e= a1219 hpt27xx2: [GIANT-LOCKED] hpt27xx2: [ITHREAD] hpt27xx1: [GIANT-LOCKED] hpt27xx1: [ITHREAD] hpt27xx0: [GIANT-LOCKED] hpt27xx0: [ITHREAD] da0 at hpt27xx0 bus 0 scbus8 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da1 at hpt27xx0 bus 0 scbus8 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da2 at hpt27xx0 bus 0 scbus8 target 2 lun 0 da2: Fixed Direct Access SCSI-0 device da2: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da3 at hpt27xx0 bus 0 scbus8 target 3 lun 0 da3: Fixed Direct Access SCSI-0 device da3: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da4 at hpt27xx0 bus 0 scbus8 target 4 lun 0 da4: Fixed Direct Access SCSI-0 device da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da5 at hpt27xx0 bus 0 scbus8 target 5 lun 0 da5: Fixed Direct Access SCSI-0 device da5: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da6 at hpt27xx0 bus 0 scbus8 target 6 lun 0 da6: Fixed Direct Access SCSI-0 device da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da7 at hpt27xx0 bus 0 scbus8 target 7 lun 0 da7: Fixed Direct Access SCSI-0 device da7: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da8 at hpt27xx0 bus 0 scbus8 target 8 lun 0 da8: Fixed Direct Access SCSI-0 device da8: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da9 at hpt27xx0 bus 0 scbus8 target 9 lun 0 da9: Fixed Direct Access SCSI-0 device da9: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da10 at hpt27xx0 bus 0 scbus8 target 10 lun 0 da10: Fixed Direct Access SCSI-0 device da10: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da11 at hpt27xx0 bus 0 scbus8 target 11 lun 0 da11: Fixed Direct Access SCSI-0 device da11: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da12 at hpt27xx0 bus 0 scbus8 target 12 lun 0 da12: Fixed Direct Access SCSI-0 device da12: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da13 at hpt27xx0 bus 0 scbus8 target 13 lun 0 da13: Fixed Direct Access SCSI-0 device da13: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da14 at hpt27xx0 bus 0 scbus8 target 14 lun 0 da14: Fixed Direct Access SCSI-0 device da14: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da15 at hpt27xx0 bus 0 scbus8 target 15 lun 0 da15: Fixed Direct Access SCSI-0 device da15: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da16 at hpt27xx0 bus 0 scbus8 target 16 lun 0 da16: Fixed Direct Access SCSI-0 device da16: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C) da17 at hpt27xx0 bus 0 scbus8 target 17 lun 0 da17: Fixed Direct Access SCSI-0 device da17: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da18 at hpt27xx0 bus 0 scbus8 target 18 lun 0 da18: Fixed Direct Access SCSI-0 device da18: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da19 at hpt27xx0 bus 0 scbus8 target 19 lun 0 da19: Fixed Direct Access SCSI-0 device da19: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da20 at hpt27xx0 bus 0 scbus8 target 20 lun 0 da20: Fixed Direct Access SCSI-0 device da20: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da21 at hpt27xx0 bus 0 scbus8 target 21 lun 0 da21: Fixed Direct Access SCSI-0 device da21: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da22 at hpt27xx0 bus 0 scbus8 target 22 lun 0 da22: Fixed Direct Access SCSI-0 device da22: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) On Thu, Apr 19, 2012 at 12:29 AM, Xin Li wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 04/12/12 10:14, Barkley Vowk wrote: >> I've got a Highpoint 2760A card that I'd like a FreeBSD driver >> for, I've got a machine and disks available if someone wants to >> tackle that. > > Please try loading 'hpt27xx.ko' on boot. > > Cheers, > - -- > Xin LI =A0 =A0https://www.delphij.net/ > FreeBSD - The Power to Serve! =A0 =A0 =A0 =A0 =A0 Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (FreeBSD) > > iQEcBAEBCAAGBQJPj77sAAoJEG80Jeu8UPuzoW4H/2KsdmWsV/HEERSkyPY/XX/B > jJtEAZFFI6X4aYYqANyPXWWBA6mRy586GkZZNlClCw2v4cBxXAnWBWL49tcuJ0UP > wURQt9/HU6P+EqbRSVZ98KhvufjvecjLavr9x6wCJ+L8pvc7trnD25l/Z0hTA96Y > hIpwTcK/m0IXYopmC0WioPfyZWJx2Uu+DgrUUV6mXOZc9oDDf53v10rbGpQoNUZg > GvKfL2Ql0rHZ13EJkjZdURcUj94Nas7pBgumGwedrsKs0NGnjRNmMlYSRzonqe0Z > uBaWzqEiB01qNThfCpt0tnAS55wYU+QWmvF9hVSApSwmeCsrneluhyUjf9QJ8M8=3D > =3DgUd0 > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.or= g" > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 08:17:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 053FB106564A; Sat, 21 Apr 2012 08:17:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0568FC15; Sat, 21 Apr 2012 08:17:01 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1068020wib.13 for ; Sat, 21 Apr 2012 01:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GJAKO5QezeXPY3DiraaMNXiBKNuwYMPFs7ZqExE1qj0=; b=k0zr5zO74x2NtvVBSfMyx4OnJO3+iymUV4oVGprUt1r56fAFw7xwx+tVGGWCFYHkGM xYkVKIsvf9942M0D7JDdyEOd24ym8j88ksSG30lE0TNd1HgmBwbyJWsVwc90zmT2kZgz KNIEXm4yUJsfDnEWpvEs2QBGd1GGh0cZ0qc0QZYbpuDJDE0YqNta5vhLIp79tgYeoC6s 2PEgFYcyXlju/8rRPr6eRemN9kZsyfcy3K8o4YGK1Pfd5o4J/ZHyhoppssWWtbIFw9Xj MWLkHxj4x3WzbJzv3f/ELp7YAyjFtqzIlB8ZrUhj/dloNjbb/BAT/t2btBfXwYnux+Pm o91A== MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr4335836wib.21.1334996220182; Sat, 21 Apr 2012 01:17:00 -0700 (PDT) Received: by 10.216.49.81 with HTTP; Sat, 21 Apr 2012 01:17:00 -0700 (PDT) In-Reply-To: References: Date: Sat, 21 Apr 2012 04:17:00 -0400 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Disabling an arbitrary device 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, 21 Apr 2012 08:17:02 -0000 Hi, On Fri, Apr 20, 2012 at 8:50 PM, Attilio Rao wrote: > Il 20 aprile 2012 19:18, Arnaud Lacombe ha scritto: >> Hi, >> >> On Fri, Apr 20, 2012 at 2:16 PM, Arnaud Lacombe wro= te: >>> Hi, >>> >>> I will be bringing up an old thread there, but it would seem the >>> situation did not evolve in the past 9 years. I have a machine running >>> 7.1 whose UHCI controller is generating some interrupt storm: >>> >>> # vmstat -i >>> interrupt =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0total =A0 = =A0 =A0 rate >>> irq4: sio0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01328 =A0 = =A0 =A0 =A0 =A02 >>> irq19: uhci1+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 63514509 =A0 =A0 =A09= 6380 >>> [...] >>> >>> generating useless load on one CPU: >>> >>> # top -SH >>> last pid: =A05223; =A0load averages: =A00.00, =A00.00, =A00.00 =A0 =A0u= p 0+00:17:21 =A013:10:35 >>> 117 processes: 14 running, 79 sleeping, 24 waiting >>> CPU: =A00.2% user, =A00.0% nice, =A00.2% system, =A06.6% interrupt, 93.= 0% idle >>> Mem: 33M Active, 9348K Inact, 67M Wired, 400K Cache, 29M Buf, 2892M Fre= e >>> [...] >>> =A0 57 root =A0 =A0 =A0 =A0 =A0-64 =A0 =A0- =A0 =A0 0K =A0 =A0 8K CPU0 = =A0 0 =A011:59 86.57% irq19: uhci1+ >>> >>> I thought I could use an hint to forbid uhci(4) attachment, ala: >>> >>> hint.uhci.0.disabled=3D"1" >>> hint.uhci.1.disabled=3D"1" >>> >>> in /boot/loader.conf. However, it would seem that what should be >>> usable with any arbitrary devices, ie. be an integral part of >>> device(9), has to be hardcoded in every driver, sad. >>> >> as for the usual "if you're not happy, please provide a patch": >> >> https://github.com/lacombar/freebsd/commit/30786d09b0cb441890cdc749ee524= 3238e81d2d8 > > I think a generalized kludge should really belong to > device_probe_child() rather than device_add_child_ordered(). > suit me. > When you have a tested patch against -CURRENT, can you please send to > freebsd-newbus@? > will give it a try, eventually. > BTW, IIRC 7.x doesn't have the new USB stack, which means that you can > have caught easilly a driver bug there, did you consider switching at > least to 8.x kernel? > That is unfortunately not a decision for me to make, though a switch to 9.x will be more likely. That said, it seems that it is not a USB specific issue, but an IRQ19's issue. I did not had a chance to investigate that further, but with uhci(4) disabled, atapci(4) is now IRQ-storming. This is a known issue relatively widely encountered, with various workarounds possible. - Arnaud From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 13:30:14 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F97E106566B for ; Sat, 21 Apr 2012 13:30:14 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4913F8FC0A for ; Sat, 21 Apr 2012 13:30:14 +0000 (UTC) Received: by iahk25 with SMTP id k25so18972208iah.13 for ; Sat, 21 Apr 2012 06:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ok82MAQQgPMhEz0fJ+5Dg3qijovVsJLOAxGS8BeWRNY=; b=ugd+rvpy65/nZ/HvJrEP7fhf6FvpEasnBv4fj+fMbGtRbgHWuPUWUvHz9GINtHKcMr Ctd0RdbvRVkIeG6EVUHlIzPXi7lm+wi3CouZ6i4boA7egTdRfjHondCiPtlZJoRTVrdb APO0nHjoQsMimmSIjCy7lKVe1DQdUMVXWIq94Rd9NBJvq9bvxPGkBDXTdmXuS8ldjFoQ sP/aBNk8IwwGBCZO5s7UAkS6Q1xIinNa5KoDek6yeTJQWFeAUHuq9DPyLjmASu54Rgx1 rgz41lGuAEAZ6TWEoNNITwiEAtSUiFKOzqB+/HhzTnxI72isY35SpYllUo/1MWLVeCuI NBWQ== MIME-Version: 1.0 Received: by 10.50.187.169 with SMTP id ft9mr1800971igc.59.1335015013738; Sat, 21 Apr 2012 06:30:13 -0700 (PDT) Sender: infofarmer@gmail.com Received: by 10.50.109.197 with HTTP; Sat, 21 Apr 2012 06:30:13 -0700 (PDT) Date: Sat, 21 Apr 2012 17:30:13 +0400 X-Google-Sender-Auth: 9HmPQSf4UaLFAjXx73cAxI3EUr8 Message-ID: From: Andrew Pantyukhin To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: cron(8): openlog: ProgramName -> "cron" 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, 21 Apr 2012 13:30:14 -0000 Hello! cron(8) is one of the rare services that puts something complicated in ident (aka progname aka programname) field of the syslog messages it sends: /usr/sbin/cron[PID]. Would anyone be against changing it to just "cron" to ease filtering with stock and third-party syslog daemons, expecting no ":", "[", and "/" in the field? Best, Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 14:55:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE1F6106564A for ; Sat, 21 Apr 2012 14:55:54 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) by mx1.freebsd.org (Postfix) with ESMTP id 23B1D8FC14 for ; Sat, 21 Apr 2012 14:55:54 +0000 (UTC) Received: from [109.85.120.214] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SLbgm-00023T-Af for freebsd-hackers@freebsd.org; Sat, 21 Apr 2012 16:53:28 +0200 Date: Sat, 21 Apr 2012 16:52:06 +0200 From: Fabian Keil To: freebsd-hackers@freebsd.org Message-ID: <20120421165206.0da0cf88@fabiankeil.de> In-Reply-To: <20120420153443.207738a3.fk@fabiankeil.de> References: <20120420153443.207738a3.fk@fabiankeil.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/q/oReAtiOu7WW18Sldvm2JU"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Subject: Re: [PATCH] Implementation of DTrace sched provider (with bonus schedgraph script) 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, 21 Apr 2012 14:55:54 -0000 --Sig_/q/oReAtiOu7WW18Sldvm2JU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Ryan Stone wrote: >=20 > > I've implemented the sched provider for FreeBSD. This provider > > provides probes that fire when various scheduling decisions are made. >=20 > Thanks a lot. Works for me (so far) with HEAD on amd64. The following seems strange to me: runq add Xorg/Xorg tid 100463 on: cpu0 at: 3664816837528 attributes: durati= on: 126.85ms, prio: 104, linkedto: emacs/emacs tid 100463 running Xorg/Xorg tid 100463 on: cpu0 at: 3665070552032 attributes: duratio= n: 49.00us, prio: 120 It seems to imply that the thread had to wait 126.85ms so it could run for 49.00us. While it waited for cpu time, both cpu cores spent a lot more than 49.00us being idle: -------- running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665065545759 attributes: d= uration: 494.09us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665066533938 attributes: dura= tion: 5.33us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665066544595 attributes: d= uration: 120.16us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665066797747 attributes: d= uration: 55.47us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665066908687 attributes: dura= tion: 9.20us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665066933464 attributes: dura= tion: 79.03us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665067091530 attributes: d= uration: 29.19us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665067560848 attributes: d= uration: 106.72us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665067774292 attributes: dura= tion: 5.49us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665067785275 attributes: d= uration: 376.84us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665068538958 attributes: dura= tion: 5.35us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665068585628 attributes: d= uration: 63.05us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665068711726 attributes: dura= tion: 7.69us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665068727114 attributes: d= uration: 278.78us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069297929 attributes: d= uration: 56.36us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069410643 attributes: dura= tion: 8.05us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069435720 attributes: dura= tion: 6.04us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069447800 attributes: d= uration: 45.15us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069538099 attributes: dura= tion: 11.23us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665069560564 attributes: d= uration: 487.04us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665070534639 attributes: dura= tion: 5.37us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665070549009 attributes: dura= tion: 52.97us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665070654952 attributes: d= uration: 439.71us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665071545318 attributes: d= uration: 56.78us, prio: 255 running idle/idle: cpu0 tid 100003 on: cpu0 at: 3665071672443 attributes: d= uration: 55.40us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665071783233 attributes: dura= tion: 9.17us, prio: 255 idle idle/idle: cpu0 tid 100003 on: cpu0 at: 3665071808741 attributes: dura= tion: 83.01us, prio: 255 ----- running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665065783769 attributes: d= uration: 244.57us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665066283934 attributes: d= uration: 244.74us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665066790594 attributes: d= uration: 53.57us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665066914236 attributes: d= uration: 3.49us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665066921213 attributes: dura= tion: 22.79us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665067019387 attributes: dura= tion: 27.54us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665067077581 attributes: dura= tion: 820.16us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665068717906 attributes: d= uration: 27.57us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665068773053 attributes: dura= tion: 5.73us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665068784511 attributes: d= uration: 244.42us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069290295 attributes: d= uration: 54.13us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069420973 attributes: dura= tion: 10.37us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069441715 attributes: d= uration: 40.54us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069522796 attributes: dura= tion: 11.24us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069545272 attributes: d= uration: 51.42us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665069658978 attributes: d= uration: 244.65us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665070159073 attributes: d= uration: 188.70us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665070554778 attributes: d= uration: 46.80us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665070659047 attributes: d= uration: 244.40us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071147838 attributes: dura= tion: 5.52us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071158871 attributes: d= uration: 244.48us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071647827 attributes: dura= tion: 8.30us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071664429 attributes: d= uration: 54.08us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071795945 attributes: dura= tion: 23.26us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071853402 attributes: dura= tion: 22.81us, prio: 255 running idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071899015 attributes: d= uration: 3.15us, prio: 255 idle idle/idle: cpu1 tid 100004 on: cpu1 at: 3665071905311 attributes: dura= tion: 845.12us, prio: 255 Spending cpu time on idle when there's actual work to be done makes no sense to me. I'm not too familiar with sched_ule and schedgraph.py, though, so I'm wondering if I'm interpreting this correctly? Fabian --Sig_/q/oReAtiOu7WW18Sldvm2JU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+SyZkACgkQBYqIVf93VJ3rCwCgzWIpCJzrclwqaI8+yXYVQeFO HyMAn3FL5R+sSL6IP7tLecfKBpuZgJXn =aHMF -----END PGP SIGNATURE----- --Sig_/q/oReAtiOu7WW18Sldvm2JU-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 15:41:38 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 937B3106566C for ; Sat, 21 Apr 2012 15:41:38 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 426FB8FC17 for ; Sat, 21 Apr 2012 15:41:38 +0000 (UTC) Received: by iahk25 with SMTP id k25so19111274iah.13 for ; Sat, 21 Apr 2012 08:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=BMAMHfPcfYFzMHWk+b+sUPtAnzm+rx8Pw2/Go/bKPdU=; b=H/ZDIB5WhA1UFJ32BhxdnuxBD/jgKO++x5CKkevb6rP0Kk8FtB05F/fFWzu+Pu+s2X RwokMT7Iqjty3PK91/y1e87IMvR4MC4soJWeS5f8H8aaMk+WgcXDxtsQWICi95RjdTKS fS4AshOX24AjxZKYqIADCSzEaFieZXX7B79oE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=BMAMHfPcfYFzMHWk+b+sUPtAnzm+rx8Pw2/Go/bKPdU=; b=mryFBUWMvlJCGADT5fDx0s5oQmP9ZMIdJ2ZCxFc8vs8T4Z3MKFhQ3XN3vgw73oXDcx dsVQfjsJUZfD5wH/OrpoZpFrOMKLWvvAM3Mew+Uf+qv5D5oxav7vWIKkCTnBqzsoCUxG eSnlYuZINspUQqD8VGrN6m0P8Yt2Ob0/ymX4nfmLN+TsAQc2/ZPdcR8+0iqfv+ZCwnyo yCdrQ9JeY7wGer//BmBQ+tT3GpDJ3FsifEYXETVLB8h6EHQ+dBRF2IWVnZ1jLsWgstlp ypjRTTOE1KfHGAKOVEqGA4BEVREjt48G6iUlPQd1T1aiLz++8FsJaG55EPOt1rRKBh2a ZbLA== Received: by 10.50.187.137 with SMTP id fs9mr2060254igc.50.1335022891884; Sat, 21 Apr 2012 08:41:31 -0700 (PDT) Received: from DataIX.net (adsl-99-119-128-6.dsl.klmzmi.sbcglobal.net. [99.119.128.6]) by mx.google.com with ESMTPS id hq3sm8631107igc.0.2012.04.21.08.41.31 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 Apr 2012 08:41:31 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3LFfT74087259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Apr 2012 11:41:29 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3LFfSP9087250; Sat, 21 Apr 2012 11:41:28 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 21 Apr 2012 11:41:28 -0400 From: Jason Hellenthal To: Andrew Pantyukhin Message-ID: <20120421154128.GA82839@DataIX.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQlCLISuiQXo6VivEBFiflH0V3vMqFQFjqVw0d91TQ0R/VUG3mCh3nyo06Yq1IIBi3rBd5Z/ Cc: hackers@freebsd.org Subject: Re: cron(8): openlog: ProgramName -> "cron" 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, 21 Apr 2012 15:41:38 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please proceed. On Sat, Apr 21, 2012 at 05:30:13PM +0400, Andrew Pantyukhin wrote: > Hello! >=20 > cron(8) is one of the rare services that puts something complicated in > ident (aka progname aka programname) field of the syslog messages it > sends: /usr/sbin/cron[PID]. Would anyone be against changing it to > just "cron" to ease filtering with stock and third-party syslog > daemons, expecting no ":", "[", and "/" in the field? >=20 >=20 > Best, > Andrew > _______________________________________________ > 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" --=20 - (2^(N-1)) --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPktUnAAoJEBSh2Dr1DU7WKUMH/Rz8Wac/G7A2k8hJ5INSPmhi +0RyuKus83EyFwEZ4tV6CgSH2/khLBneHh0iK9uKLtWMOZ0OmV6gndPSdXQOqIUu z07wvtYcIASZSqrCZJOSKBpBQ2VZpQ7r1cMOhhHtCtNXcMu9QnFDpGGwoPiwkT+V /vmoKziXSX9jeEnzOIIQNQ0H7vVIMEIbJaR0PzjEOiUfotKNzpZkknxRCTbCFfh0 SJSUy9U9g9Gvu/iPz/zHFwrs9P87JbWDbZ5E2rg757HVL8lkFklGBAiqK6J+MmZa hqV2T6cdgNHvgWioL4cbfr9TWuOc38pWpqEeG0gexAEgMpukW2PaGVu63wZFP2E= =sT+0 -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 16:43:31 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 284E0106566B for ; Sat, 21 Apr 2012 16:43:31 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id AFE558FC15 for ; Sat, 21 Apr 2012 16:43:30 +0000 (UTC) Received: by wern13 with SMTP id n13so8733617wer.13 for ; Sat, 21 Apr 2012 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:x-mailer; bh=ob584RjnFi+cMzY8HbaevREPBCQwqH7rm17vgQjCYkw=; b=Zi8edNATkelxBvfTUf09mQi0LCP0RLdz9hTxVYcXEwEYfqUnIF0MV1j9H09vtW4mHh sjYJJ21gjPnnCCtnj6XnaZ+ezqxyA0AtPFY6l7dHZyKWkZZbxji9LBMLNeq8b1VWVwga h5YMw+Fs8oFnHvRpPEAF0HMJLCqjmOgBGosTrnDmaRrnlHMWOjOvs9ZcmpN1HQIeW4Bl /idejiAUBuGibO0iIPU/9k7hqqHKlS1duizr2rou28WOOyvOw1F92P7fz7kstPU0rXPz +Rgq2rkkI6L2l0tkVbnQ1Rt3gXe4boN3otJDJI20s40HlMJ4XAnz0RI8jzUSJQ4TPecF AhAQ== Received: by 10.180.81.166 with SMTP id b6mr7357724wiy.0.1335026609756; Sat, 21 Apr 2012 09:43:29 -0700 (PDT) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id n8sm11103113wix.10.2012.04.21.09.43.23 (version=SSLv3 cipher=OTHER); Sat, 21 Apr 2012 09:43:28 -0700 (PDT) Message-ID: <20120421.164328.068.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Date: Sat, 21 Apr 2012 18:43:28 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable X-Mailer: POP Peeper (3.8.1.0) Cc: Subject: Forgotten debuging flags in 9.0 RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 16:43:31 -0000 Whenever I run:=0D=0A# make distribution=0D=0A=0D=0AI also get:=0D=0A+ ln = -s ../var/named/etc/namedb /usr/TZONE/etc/namedb=0D=0A+ ln -s = mail/aliases /usr/TZONE/etc/aliases=0D=0A=0D=0ALooks like someone forgot = to turn off/remove debuging flags(set -x), before building 9.0 = RELEASE=0D=0A=0D=0A=0D=0A/usr/src/etc/Makefile:=0D=0A----=0D=0A = @if [ ! -e ${DESTDIR}/etc/namedb ]; then \=0D=0A set -x; = \=0D=0A ln -s ../var/named/etc/namedb = ${DESTDIR}/etc/namedb; \=0D=0A fi=0D=0A----=0D=0A @if [ -d = ${DESTDIR}/etc/mail -a -f ${DESTDIR}/etc/mail/aliases -a \=0D=0A = ! -f ${DESTDIR}/etc/aliases ]; then \=0D=0A set -x; = \=0D=0A ln -s mail/aliases ${DESTDIR}/etc/aliases; \=0D=0A = fi=0D=0A----=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6 From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 18:32:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1B1F1065670; Sat, 21 Apr 2012 18:32:25 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 756568FC17; Sat, 21 Apr 2012 18:32:25 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 8FC9D291124; Sat, 21 Apr 2012 13:22:32 -0500 (CDT) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 828C9291120; Sat, 21 Apr 2012 13:22:32 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id em5BmvXjPzVc; Sat, 21 Apr 2012 13:22:32 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id E64E42910E9; Sat, 21 Apr 2012 13:22:31 -0500 (CDT) Message-ID: <4F92FAE7.3090702@rice.edu> Date: Sat, 21 Apr 2012 13:22:31 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Konstantin Belousov References: <1334342264.8672.YahooMailClassic@web180006.mail.gq1.yahoo.com> <20120413214536.GL2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120413214536.GL2358@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Sushanth Rai Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN 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, 21 Apr 2012 18:32:25 -0000 On 04/13/2012 16:45, Konstantin Belousov wrote: > On Fri, Apr 13, 2012 at 11:37:44AM -0700, Sushanth Rai wrote: >> I've attached the simple program that creates 5 threads. Following is the o/p of /proc//map when this program is running. Note that I modified >> sys/fs/procfs/procfs_map.c to print whether a region is wired. As you can see from this o/p, none of stack areas get wired. >> >> 0x400000 0x401000 1 0 0xffffff002d943bd0 r-x 1 0 0x1000 COW NC wired vnode /var/tmp/thread1 >> 0x500000 0x501000 1 0 0xffffff002dd13e58 rw- 2 0 0x3100 NCOW NNC wired default - >> 0x501000 0x600000 255 0 0xffffff002dd13e58 rwx 2 0 0x3100 NCOW NNC wired default - >> 0x800500000 0x800526000 38 0 0xffffff0025574000 r-x 192 46 0x1004 COW NC wired vnode /libexec/ld-elf.so.1 >> 0x800526000 0x800537000 17 0 0xffffff002d9f81b0 rw- 1 0 0x3100 NCOW NNC wired default - >> 0x800626000 0x80062d000 7 0 0xffffff002dd13bd0 rw- 1 0 0x3100 COW NNC wired vnode /libexec/ld-elf.so.1 >> 0x80062d000 0x800633000 6 0 0xffffff002dd145e8 rw- 1 0 0x3100 NCOW NNC wired default - >> 0x800633000 0x800645000 18 0 0xffffff00256d71b0 r-x 63 42 0x4 COW NC wired vnode /lib/libthr.so.3 >> 0x800645000 0x800646000 1 0 0xffffff002d975510 r-x 1 0 0x3100 COW NNC wired vnode /lib/libthr.so.3 >> 0x800646000 0x800746000 0 0 0xffffff002dc5cca8 --- 4 0 0x3100 NCOW NNC not-wired default - >> 0x800746000 0x80074a000 4 0 0xffffff002572a288 rw- 1 0 0x3100 COW NNC wired vnode /lib/libthr.so.3 >> 0x80074a000 0x80074c000 2 0 0xffffff002dc5cca8 rw- 4 0 0x3100 NCOW NNC wired default - >> 0x80074c000 0x80083e000 242 0 0xffffff001cd226c0 r-x 238 92 0x1004 COW NC wired vnode /lib/libc.so.7 >> 0x80083e000 0x80083f000 1 0 0xffffff002dd12000 r-x 1 0 0x3100 COW NNC wired vnode /lib/libc.so.7 >> 0x80083f000 0x80093e000 0 0 0xffffff002dc5cca8 --- 4 0 0x3100 NCOW NNC not-wired default - >> 0x80093e000 0x80095d000 31 0 0xffffff002dddc360 rw- 1 0 0x3100 COW NNC wired vnode /lib/libc.so.7 >> 0x80095d000 0x800974000 23 0 0xffffff002dc5cca8 rw- 4 0 0x3100 NCOW NNC wired default - >> 0x800a00000 0x800b00000 256 0 0xffffff002dbd1798 rw- 1 0 0x3100 NCOW NNC wired default - >> 0x800b00000 0x800c00000 256 0 0xffffff002dd14948 rw- 1 0 0x3100 NCOW NNC wired default - >> 0x7fffff3db000 0x7fffff3fb000 1 0 0xffffff002dbb4360 rw- 1 0 0x3100 NCOW NNC not-wired default - >> 0x7fffff5dc000 0x7fffff5fc000 1 0 0xffffff002dc66af8 rw- 1 0 0x3100 NCOW NNC not-wired default - >> 0x7fffff7dd000 0x7fffff7fd000 1 0 0xffffff002dbea438 rw- 1 0 0x3100 NCOW NNC not-wired default - >> 0x7fffff9de000 0x7fffff9fe000 1 0 0xffffff002dd7fd80 rw- 1 0 0x3100 NCOW NNC not-wired default - >> 0x7fffffbdf000 0x7fffffbff000 1 0 0xffffff002dbe9438 rw- 1 0 0x3100 NCOW NNC not-wired default - >> 0x7fffffbff000 0x7fffffc00000 0 0 0 --- 0 0 0x0 NCOW NNC not-wired none - >> 0x7ffffffe0000 0x800000000000 32 0 0xffffff002dd125e8 rwx 1 0 0x3100 NCOW NNC wired default - >> >> --- On Fri, 4/13/12, Konstantin Belousov wrote: >> >>> From: Konstantin Belousov >>> Subject: Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN >>> To: "Sushanth Rai" >>> Cc: freebsd-hackers@freebsd.org >>> Date: Friday, April 13, 2012, 1:11 AM >>> On Thu, Apr 12, 2012 at 08:10:26PM >>> -0700, Sushanth Rai wrote: >>>>> Then it should be fixed in r190885. >>>>> >>>> Thanks. That works like a charm. >>>> >>>> mlockall() mostly works now. There is still a, issue in >>> wiring the stacks of multithreaded program when the program >>> uses default stack allocation scheme. Thread library >>> allocates stack for each thread by calling mmap() and >>> sending address and size to be mapped. The kernel adjusts >>> the start address to sgrowsz in vm_map_stack() and >>> maps at the adjusted address. But the subsequent wiring is >>> done using the original address, which fails. > Oh, I see. The problem is the VM_MAP_WIRE_NOHOLES flag. Since we > map only the initial stack fragment even for the MCL_WIREFUTURE maps, > there is a hole in the stack region. > > In fact, for MCL_WIREFUTURE, we probably should map the whole > stack at once, prefaulting all pages. > > Below are two patches. The change for vm_mmap.c would fix your immediate > problem by allowing holes in wired region. > > The change for vm_map.c prefaults the whole stack instead of the > initial fragment. The single-threaded programs still get a fault > on stack growth. The vm_mmap.c change looks ok to me. Please commit it. I haven't yet had a chance to think about the other change. Alan > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index 6198629..2fd18d1 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -3259,7 +3259,10 @@ vm_map_stack(vm_map_t map, vm_offset_t addrbos, vm_size_t max_ssize, > addrbos + max_ssize< addrbos) > return (KERN_NO_SPACE); > > - init_ssize = (max_ssize< sgrowsiz) ? max_ssize : sgrowsiz; > + if (map->flags& MAP_WIREFUTURE) > + init_ssize = max_ssize; > + else > + init_ssize = (max_ssize< sgrowsiz) ? max_ssize : sgrowsiz; > > PROC_LOCK(curthread->td_proc); > vmemlim = lim_cur(curthread->td_proc, RLIMIT_VMEM); > diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c > index 2588c85..3fccd9e 100644 > --- a/sys/vm/vm_mmap.c > +++ b/sys/vm/vm_mmap.c > @@ -1561,9 +1561,11 @@ vm_mmap(vm_map_t map, vm_offset_t *addr, vm_size_t size, vm_prot_t prot, > * If the process has requested that all future mappings > * be wired, then heed this. > */ > - if (map->flags& MAP_WIREFUTURE) > + if (map->flags& MAP_WIREFUTURE) { > vm_map_wire(map, *addr, *addr + size, > - VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES); > + VM_MAP_WIRE_USER | ((flags& MAP_STACK) ? > + VM_MAP_WIRE_HOLESOK : VM_MAP_WIRE_NOHOLES)); > + } > } else { > /* > * If this mapping was accounted for in the vnode's From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 20:15:53 2012 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 DAB6F1065672 for ; Sat, 21 Apr 2012 20:15:53 +0000 (UTC) (envelope-from bfiedler@asu.edu) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 684E98FC12 for ; Sat, 21 Apr 2012 20:15:53 +0000 (UTC) Received: by dadz14 with SMTP id z14so45162882dad.17 for ; Sat, 21 Apr 2012 13:15:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=HvixMuliOV/CQbZ+JQdX7bUsU8eZDYZNVB1pnlbuPqQ=; b=edN5ybpS78Vuya5An5Z1ZwRn7EXbOEsrJYrH8yFFWILnuEGYIvNnBWANZ2jvwBoCR+ s0YEdsSQ6EgAkBDzpmjC+9D9mNNhQB2H1M4JXStRPqVOhYajCKgcxmLib5kQrdcoH5AV Oy1ZTJGRDciWAYPFtEQxuGD0g4YGLfNgacS/upWsbi7t8ej8NuPNJAAFaE/B1l9LSElX YBTG/OAgj5IjvdmZgcRlx3DSI4Q0n0tTEqIVMSFAOYxWw7g7AyJcFtehGcjGafQn5REd +lGeCq/oMlqjQ5Z9+7kmDTLshMcJFlDOzMbd09f5/zFos78ql8r2qVAYSi9YDiBcVBdX aQgQ== MIME-Version: 1.0 Received: by 10.68.223.105 with SMTP id qt9mr5883950pbc.162.1335039353193; Sat, 21 Apr 2012 13:15:53 -0700 (PDT) Received: by 10.68.71.163 with HTTP; Sat, 21 Apr 2012 13:15:53 -0700 (PDT) In-Reply-To: References: <4F8E0163.9030009@FreeBSD.org> Date: Sat, 21 Apr 2012 13:15:53 -0700 Message-ID: From: Ben Fiedler To: Matthew Story X-Gm-Message-State: ALoCoQmxoxSwrYwYJeiTyI2QuFqu54RKv6fkoaAQlZhzl2WZr0jPOWYRCqipZkeJcXFwStdisrKI Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Gabor Kovesdan Subject: Re: Status of BSD Diff replacement? 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, 21 Apr 2012 20:15:54 -0000 http://www.public.asu.edu/~bfiedler/bsdtextproc.tar.gz Here's a tar.gz of my project file: I did not include the diff/ directory, but instead gabor_diff/ , as that's where the latest changes are. iirc the original diff/ in my project was taken from the source for Gabor's 'bsdiff' under the ports tree, but then after a few weeks I discovered he had made newer changes to the code under perforce, so I based gabor_diff/ off of that. Sorry if this is all confusing :) -Ben On Tue, Apr 17, 2012 at 8:30 PM, Matthew Story wrote: > > > On Tue, Apr 17, 2012 at 10:01 PM, Ben Fiedler wrote: > >> Gabor, >> >> I made a branch off of your perforce diff code in my work on the diff >> tool: From my understanding you started those modifications from OpenBSD's >> diff in 2008, so Matthew's assertion that "our incomplete BSD diff is >> OpenBSD diff + improvements" is 100% correct. I also ported and started >> work on sdiff and diff3 from OpenBSD, but made minimal headway on each. >> >> The red items on the table here lists the needed argument support to >> match GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff > > > Awesome, thanks for that link. > > >> >> >> Though there's only a few left, they are not trivial by any means. >> >> -Ben >> >> >> >> On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan wrote: >> >>> On 2012.04.17. 23:03, Matthew Story wrote: >>> >>>> Just wondering what the current status is on a BSD diff replacement. >>>> The IdeasPage suggests that a goodly amount of work was done on this for >>>> GSoC 2010 (http://wiki.freebsd.org/**IdeasPage#BSD-licensed_Text-** >>>> Processing_Tools), >>>> but the GPLinBase page says it's unowned and suggests replacement with >>>> OpenBSD diff (http://wiki.freebsd.org/**GPLinBase >>>> ). >>>> >>> Unless OpenBSD folks have changed or developed something, our incomplete >>> BSD diff is OpenBSD diff + improvements. >>> >>>> >>>> Wondering how much is outstanding on this, and where to start reading >>>> to catch up on what's been done? >>>> >>> >>> I worked a bit on that in 2008 along with grep and sort but these got >>> more priorities so lots of features are still missing. Then Ben Fiedler >>> also worked on it in 2010 but I don't exactly know what he accomplished and >>> whether he took my code or chose another way. So for someone who wants to >>> work on it, first it should be checked what's done, maybe merge my version >>> and Ben's version, >> >> > just to verify, these are the correct 2 branches to look at: > > > http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2008/&c=iZC@//depot/projects/soc2008/gabor_textproc/?ac=83 > > http://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2010/&c=QTP@//depot/projects/soc2010/bsdtextproc/?ac=83 > > it looks like gabor_diff in soc2010 is based off the soc2008 work. > > Is there anyway either of you could provide me with an archive of the > working tree for these 2 perforce repos? or make it available in a branch > on svn.freebsd.org? I'd like to look into this more, but after reading > through the P4Web docs, trying to gain anonymous read-only access through > p4 itself, and then reading: > > > http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.html > > it seems there's no real way to accommodate this sort of thing at current. > > >> check whether OpenBSD added something new or fixed somethings and then >>> implement missing features and do lots of testing to ensure compatibility >>> with GNU diff. And performance tests and improvements if necessary. >>> >> > Since 2008/2010 the OpenBSD change logs referencing diff(1) sdiff(1) and > diff(3) are: > > 4.9 > Use scandir(3) instead of getdirentries(2) in diff(1). Call to > getdirentries(2) should be avoided outside of libc > 4.8 > Many diff(1) improvements. > Make diff(1) return 2 on error. > 4.6 > Fix file descriptor leaks in sdiff(1) when diffing regular files. > > I think the many diff(1) improvements is when ray started maintaining diff > (not millert), so perhaps I can ping him as well if I make any headway on > this. > > >> >>> I work on grep/regex related things and recently Oleg Moskalenko took >>> over my incomplete BSD sort code but noone is working on BSD diff so any >>> contribution is very welcome. >> >> >>> >>> Gabor >>> >> >> > > > -- > regards, > matt > From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 21 23:07:16 2012 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 739B1106566C for ; Sat, 21 Apr 2012 23:07:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id D56948FC08 for ; Sat, 21 Apr 2012 23:07:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id q3LN7D3f006463; Sun, 22 Apr 2012 01:07:13 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id q3LN7DVu006460; Sun, 22 Apr 2012 01:07:13 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 22 Apr 2012 01:07:13 +0200 (CEST) From: Wojciech Puchar To: Thomas Schmitt In-Reply-To: <99329673623314@192.168.2.69> Message-ID: References: <99329673623314@192.168.2.69> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 22 Apr 2012 01:07:13 +0200 (CEST) Cc: freebsd-hackers@freebsd.org Subject: Re: what's wrong with cd9660 fs 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, 21 Apr 2012 23:07:16 -0000 > I am currently trying to understand how fs/udf handles multiple extents. > /usr/src/sys/fs/udf/udf_vnops.c > bears in function udf_bmap_internal() a comment: > * If the offset is beyond the current extent, look for the > * next extent. > > > Have a nice day :) > > Thomas > > for now i add -udf when using mkisofs and mount_udf reads fine. anyway i would be happy to see fully working ISO filesystem, which is nearly optimal for read only usage. thank you very much