From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 11:56:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 845FC106564A for ; Sun, 25 Mar 2012 11:56:16 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0BD268FC14 for ; Sun, 25 Mar 2012 11:56:15 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so3010720wib.1 for ; Sun, 25 Mar 2012 04:56:15 -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=ORriogu04o4ArUJqv7iFRCWiS+wQvVS4s3LeTYSikgk=; b=jrIk5UTuHv53SoeGlAcB4yIhZEUYXjTF+oaoSQOVUCPI8FY959iZo932dEr3WEV+x4 CMVgRksRQc1xqcBKgKyRYWL6ABhUO0midcRDEN3KAIE4aDjCReY4ea9gfcHZkqIbkE6K lBZD5eJ4s+6Sdz5Tqywrm+DSReD+iKMdJC00yKXPOfskJvFQiKPg6sSDEoKe8cZKW6IX 7x0eHFPdKYUiwvTHq+8FDtEL5JHCsrWv/tC2yODkl9D3A6t1xl7IljZBoQ6YDiVJ4hS7 /cUhWChrwIzVuAf75FZkZ8mfLvVg33zLY6qJFBJwGQyO+eCZckJQQ/wMnnLgGoX0CEky mDpw== MIME-Version: 1.0 Received: by 10.216.132.30 with SMTP id n30mr10365003wei.52.1332676574849; Sun, 25 Mar 2012 04:56:14 -0700 (PDT) Received: by 10.216.229.10 with HTTP; Sun, 25 Mar 2012 04:56:14 -0700 (PDT) In-Reply-To: <4F6B3B46.4060105@sentex.net> References: <4F6A67C0.7000909@sentex.net> <4F6B3B46.4060105@sentex.net> Date: Sun, 25 Mar 2012 22:26:14 +1030 Message-ID: From: Matt Thyer To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 157k interrupts per second causing 60% CPU load on idle system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 11:56:16 -0000 On 23 March 2012 01:16, Mike Tancsa wrote: > Sorry, what I was getting at was that a bad bios (eg latest could have > introduced a regression) can cause the symptoms you are seeing. The bios > change sure seemed to fix my problem. > I've updated the firmware of the SuperMicro AOC-USAS2-L8i to the latest -IT firmware on the Supermicro FTP site (this is version 11 and I was on 7 before) but this made no difference. I then tried downgrading the motherboard BIOS to the F3 release that I was running previously but again this made no difference. So it would seem that this is a problem is to do with a change in FreeBSD-STABLE between r225723 and r232477. I'm wondering whether this is due to the new LSI authored driver for chips such as the LSI SAS2008 that are used in the SuperMicro AOC-USAS2-L8i. I know this driver is in CURRENT but do not know if it's in 8-STABLE. Does anyone know if and when this driver was merged from current to 8-STABLE ? If I can work out what revision that occurred in I'll go back to just before then to confirm if the problem exists. Matt From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 13:03:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BCC9106566C for ; Sun, 25 Mar 2012 13:03:32 +0000 (UTC) (envelope-from accessprofit@gmail.com) Received: from mx-n03.wc1.ord1.stabletransit.com (mx-n03.wc1.ord1.stabletransit.com [50.57.219.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8378FC08 for ; Sun, 25 Mar 2012 13:03:32 +0000 (UTC) Received: by mx-n03.wc1.ord1.stabletransit.com (Postfix, from userid 99) id A462D1CE0236; Sun, 25 Mar 2012 07:33:16 -0500 (CDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx-n03.wc1.ord1.stabletransit.com X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=6.0 tests=ACT_NOW_CAPS,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.3.1 Received: from mx-n03.wc1.ord1.stabletransit.com (localhost.localdomain [127.0.0.1]) by mx-n03.wc1.ord1.stabletransit.com (Postfix) with ESMTP id EDBDB1CE0236 for ; Sun, 25 Mar 2012 07:33:08 -0500 (CDT) Received: by mx-n03.wc1.ord1.stabletransit.com (Postfix, from userid 300) id EBE85A20002; Sun, 25 Mar 2012 07:33:08 -0500 (CDT) Received: from php5-v34.wc1.ord1.stabletransit.com (unknown [10.187.244.22]) by mx-n03.wc1.ord1.stabletransit.com (Postfix) with ESMTP id DCC151CF011A for ; Sun, 25 Mar 2012 07:33:08 -0500 (CDT) Received: by php5-v34.wc1.ord1.stabletransit.com (Postfix, from userid 30024) id D987614201AE; Sun, 25 Mar 2012 07:33:08 -0500 (CDT) To: freebsd-stable@freebsd.org X-PHP-Script: www.beinfushistore.com/store/cart.php for 27.108.210.14, 184.106.55.233 From: accessprofit@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <20120325123308.D987614201AE@php5-v34.wc1.ord1.stabletransit.com> Date: Sun, 25 Mar 2012 07:33:08 -0500 (CDT) Subject: RUGGIERO RICCI: The Legacy of Cremona - Ruggiero Ricci Plays 18 Contemporary Violins (DYNAMIC) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: accessprofit@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:03:32 -0000 Name: Catherine Jackson Email: accessprofit@gmail.com Start Your Home Business In Your Town! Hello Friend, Your Easy Money Starting $1,000 Commission This Week!!! HOW TO TURN YOUR $20 INTO $1,000 IN 7 DAYS ONLINE! Buy what you want,Build New Home,Travel Anywhere In The World. Cash In On The Local Bandwagon Which Is Hotter And MORE Profitable Than It Has Ever Been Before! WorkFromHome.Start Putting 50 Members Everyday by simple way to join $20 Lifetime Membership.and hurry for the few days before cut-off.Act Now only 8 Members are available Today. IMPORTANT:APPLY NOW or Before March.28,2012 is the Cut-Off date!To lock in your Position! Was Price $47 (today It's only $20 Promo until March-31 -2012) Lifetime Membership. to secure $1,000 instant Commission Send on March-15/2012 Direct to your Personal Paypal Account. Secure your position in the fast growing Powerline above all the people below you! Get Positioned Immediately with Priority Placement in the Fastest Growing TEAM No riches"story because I'm pretty sure you don't want to hear it. http://payspree.com/5308/cashnow2012 , TYPE = Date & Time = New Paid Members=== Country's M March.25 @ 11:19 PM = Sheryl Jackson === United States M March.25 @ 11:19 PM == Rolldan Pacson === United States M March.25 @ 06:23 PM === Stephen Harris === Canada M March.25 @ 11:19 PM ==== Jackie Parkers === United States M March.25 @ 11:19 PM ===== Rowena Harison === United States M March.24 @ 06:23 PM ====== Geralden Roses === New Zealand M March.24 @ 08:26 AM ======= Renee Jenkinse === Australia P March.24 @ 02:31 PM ======== Elizabeth Rios === Singapore M March.24 @ 02:37 PM ========= Karen Schiller === United Kingdom M March.24 @ 04:21 PM ========== Analou Roddman === Germany P March.24 @ 09:38 PM =========== Karen Stephens === Sri Lanka P March.24 @ 10:45 PM ============ Josephen Coper === United States M March.24 @ 10:19 AM ============= Vecky Camptons === United States P March.24 @ 08:32 PM ============ Gaynell Bailey === South Africa M March.24 @ 09:40 PM =========== Barbara Thunder === Netherlands P March.23 @ 10:21 AM ========== James Williams === North Carolina P March.23 @ 11:08 PM ========= David Robinson === United States M March.23 @ 12:39 AM ======== Carolyn Smiths === Hungary M March.23 @ 02:30 AM ======= Andrew Stocton === New Zealand P March.23 @ 02:42 AM ====== Matthew Evander === Portugal M March.23 @ 08:18 AM ===== Steven Hopekin === United States P March.23 @ 02:38 AM ==== Jenny Hamilton === United States P March.23 @ 02:53 AM === Stefany Gibson === Italy P March.23 @ 02:38 AM == Amie Stephenson === United States P March.23 @ 02:53 AM = Roben Mcartney === United Kingdom This are 50 paid referrals, placed DIRECTLY under you.If you are a Powerline member, AND qualified: the $20 x 50 =$1,000 will be yours Any sales this persons make will be passed up DIRECTLY to you in which case, you will receive $1,000 commissions payment this Weekl for that,and be notified by email as well. http://payspree.com/5308/cashnow2012 Once accepted into our team we will hold your hand every step of the way to ensure your journey is a success. To your Success, Catherine Jackson Queens N.Y. P.S. Don't delay and miss out on this incredible opportunity. Be the first in your town to start a local internet marketing business and sweep up all of the business! http://www.beinfushistore.com/store/cart.php?m=product_detail&p=35 From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 14:52:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95763106564A for ; Sun, 25 Mar 2012 14:52:57 +0000 (UTC) (envelope-from prabhpal@digital-infotech.net) Received: from mail.digital-infotech.net (mail.digital-infotech.net [41.211.25.193]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3708FC19 for ; Sun, 25 Mar 2012 14:52:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id 343262E402A for ; Sun, 25 Mar 2012 16:46:39 +0000 (GMT) Received: from mail.digital-infotech.net ([127.0.0.1]) by localhost (mail.digital-infotech.net [127.0.0.1]) (maiad, port 10024) with ESMTP id 01610-03 for ; Sun, 25 Mar 2012 16:46:39 +0000 (GMT) Received: from mail.digital-infotech.net (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id E73DB2E4028 for ; Sun, 25 Mar 2012 16:46:38 +0000 (GMT) Received: from 41.211.0.76 (SquirrelMail authenticated user prabhpal@digital-infotech.net) by mail.digital-infotech.net with HTTP; Sun, 25 Mar 2012 16:46:38 -0000 Message-ID: Date: Sun, 25 Mar 2012 16:46:38 -0000 From: "Prabhpal S. Mavi" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prabhpal@digital-infotech.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 14:52:57 -0000 Greetings Friends, have anyone has come across this warning / error? This occurs when i ssh to my FreeBSD 9.0 System. any help would be greatly appreciated. Warning: /usr/share/games/fortune/freebsd-tips.dat: Too many open files in system [mavi@titan ~]$ su su: pam_start: system error Thanks / Regards Prabhpal From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 15:03:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DED41065670 for ; Sun, 25 Mar 2012 15:03:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 181EC8FC25 for ; Sun, 25 Mar 2012 15:03:41 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id ppv91i0051ap0As5Er3cQR; Sun, 25 Mar 2012 15:03:36 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id pr3b1i00M1t3BNj3ir3bEX; Sun, 25 Mar 2012 15:03:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CA328102C1E; Sun, 25 Mar 2012 08:03:33 -0700 (PDT) Date: Sun, 25 Mar 2012 08:03:33 -0700 From: Jeremy Chadwick To: Alexander Leidinger Message-ID: <20120325150333.GA55108@icarus.home.lan> References: <20120323110847.GA12111@icarus.home.lan> <20120324173230.000045f9@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120324173230.000045f9@unknown> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Debugging periodic scripts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 15:03:42 -0000 On Sat, Mar 24, 2012 at 05:32:30PM +0100, Alexander Leidinger wrote: > On Fri, 23 Mar 2012 04:08:47 -0700 Jeremy Chadwick > wrote: > > > Editing /etc/periodic/security/510.ipfdenied's hashbang line to use -x > > doesn't change the behaviour either (maybe stderr gets sent to > > /dev/null?), whether I run it by hand as a script or via "periodic > > security". > > Use "set -x" instead of modifying the first line (I assume the script > is already started with the correct shell, so the first line is > ignored). I would also add "env" before and after the sourcing of the > periodic.conf to see what is defined or not. I hadn't considered that -- thanks for the tip Alexander. After briefly checking both systems, it appears that Matthew was correct. (I had no idea he sent a follow-up reply until maybe half an hour ago; I never received a copy of his mail. Not sure if I was CC'd or not; please do keep me CC'd as I'm not subscribed to the lists) The problem script is indeed /etc/periodic/security/610.ipf6denied, which is why I was getting no where poking at 510.ipfdenied. The reason only 2 of our systems have this problem is that these 2 systems were rebuilt (bare-bones OS install) fairly recently (02/16 and 03/03 followed by a world rebuild on 03/09). I can tell this from simply doing ls -l /etc/periodic/security. All our systems have the following (and always have): src.conf: WITHOUT_INET6=true WITHOUT_IPFILTER=true make.conf: WITHOUT_IPV6=true NO_INET6=yes The reason the problem doesn't affect the other machines is that they never had a copy of 610.ipf6denied ever installed -- the base installation was from a much older FreeBSD memstick image (either 8.2-STABLE or 8.1, I forget). That explains where the file came from on the newer 2 systems, but doesn't explain why mergemaster or make delete-old isn't nuking the periodic script. So I began to dig into that: Based on what I can see, the crux of the problem is that src/tools/build/mk/OptionalObsoleteFiles.inc is lacking two OLD_FILES lines under the ".if ${MK_IPFILTER} == no" clause: OLD_FILES+=etc/periodic/security/510.ipfdenied OLD_FILES+=etc/periodic/security/610.ipf6denied Based on what I see in that file (ex. the MK_ZFS==no bits), that looks to be the correct solution. Shall I file a PR for this or is there already one? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 15:49:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D228106564A for ; Sun, 25 Mar 2012 15:49:32 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 432188FC19 for ; Sun, 25 Mar 2012 15:49:32 +0000 (UTC) Received: by iahk25 with SMTP id k25so9171236iah.13 for ; Sun, 25 Mar 2012 08:49:31 -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:cc:content-type:x-gm-message-state; bh=5E5Kt1MNtP+wj443to6FouDkJf0dQpjL32jDKUxp5LQ=; b=RM0RWaqhiv9N/otnLrGQZuCTvkhxU5i8v9t36OQSWrrYze7WhkIj6qB5OvtykL4uuc x5uhJxL6ZWwj7a88VP+Sca2TfrpWWAt1TjsL5xUsAkCDwdJGYTBMXQXJabuP6S6hbLNo o18wu4w6X2zWGNscKr5zvyUyNoWA7yXPhnBnoAfomjrnIE5V1ypE4ZsWPqUkeS8gS/CM Nt8PwbrFpc8kEgSL3GXWXJbxzUXS/I07B4k3Amn3hvsgivC10s0sD0ZtO5J7shswxywk EP+JlydPuuyseBqMw5YhahUbCA5qvvhX0VLOhsjQUPssyunmyg/MrVIUo7UnLvZKfZh8 ty5Q== MIME-Version: 1.0 Received: by 10.50.195.131 with SMTP id ie3mr3504404igc.52.1332690571752; Sun, 25 Mar 2012 08:49:31 -0700 (PDT) Received: by 10.231.144.68 with HTTP; Sun, 25 Mar 2012 08:49:31 -0700 (PDT) X-Originating-IP: [93.221.186.31] In-Reply-To: References: Date: Sun, 25 Mar 2012 17:49:31 +0200 Message-ID: From: "C. P. Ghost" To: prabhpal@digital-infotech.net Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQki1QO1EMMikvNxaSe9UbZdUfIvL+88nGHY9nE/B4xpqL7Rb7ik2N1W9ZQZoI9bBQFKqWS9 Cc: freebsd-stable@freebsd.org Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 15:49:32 -0000 On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi wrote: > Greetings Friends, > > have anyone has come across this warning / error? This occurs when i ssh > to my FreeBSD 9.0 System. any help would be greatly appreciated. > > Warning: > /usr/share/games/fortune/freebsd-tips.dat: Too many open files in system > [mavi@titan ~]$ su > su: pam_start: system error > > Thanks / Regards > Prabhpal What does this command say on your system? % sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles You may have exceeded the maximum number of open files in the system. Maybe some ill-conceived program that doesn't close non-needed connections, files, etc is at fault? It's easy to open more and more files, and to gradually fill the open files descriptor table in the kernel this way. -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 16:10:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFC2D106566C for ; Sun, 25 Mar 2012 16:10:02 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 80D408FC24 for ; Sun, 25 Mar 2012 16:10:02 +0000 (UTC) Received: from amd620.ovitrap.com ([103.10.151.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2PG9SQd005760; Sun, 25 Mar 2012 10:09:31 -0600 From: Erich Dollansky To: freebsd-stable@freebsd.org, prabhpal@digital-infotech.net Date: Sun, 25 Mar 2012 23:09:51 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203252309.51264.erichfreebsdlist@ovitrap.com> Cc: Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 16:10:02 -0000 Hi, do you run KDE? Erich On Sunday 25 March 2012 23:46:38 Prabhpal S. Mavi wrote: > Greetings Friends, > > have anyone has come across this warning / error? This occurs when i ssh > to my FreeBSD 9.0 System. any help would be greatly appreciated. > > Warning: > /usr/share/games/fortune/freebsd-tips.dat: Too many open files in system > [mavi@titan ~]$ su > su: pam_start: system error > > Thanks / Regards > Prabhpal > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 21:44:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48265106564A for ; Sun, 25 Mar 2012 21:44:18 +0000 (UTC) (envelope-from jensrasmus@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 BC8CB8FC0C for ; Sun, 25 Mar 2012 21:44:17 +0000 (UTC) Received: by qcsg15 with SMTP id g15so3458492qcs.13 for ; Sun, 25 Mar 2012 14:44: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=KhKaS8QJ8/ngLAYRhfP0gBidxHe7oHwC26DwXEgzTyQ=; b=bUB6nhs3OiskRkPHwNLoIIGnNWJsuQmizZQD+neSATTKdG51dtBD3L9H8Ir+JAc7Wd 0Q035RYOkKMAbifNkrofnYV/NGXNvfGMks/ci1ZHSDzpARgPcdDkcM1/pqSiR7a/aia0 ywBZh6i35jXpHJnaC+iR1dws+PjvZaHiTKSaZNut3Dt5AtXv40w6wSHXb/ZDoF5Vc7ZD IocclGO9WyXOsZun7+zvGQcFJ1bX5J/uJokMdDattPKnZWeviCk9+ViyfdHrlcuNAojG HDeJouzd4HkcbJSurx7u3R3sv+8cOZ2L7yEwDLoiDIMJPjN4hrmiL2Wc2NsP+xXb4SeG MibQ== MIME-Version: 1.0 Received: by 10.229.137.21 with SMTP id u21mr7396077qct.115.1332711857102; Sun, 25 Mar 2012 14:44:17 -0700 (PDT) Received: by 10.229.121.4 with HTTP; Sun, 25 Mar 2012 14:44:17 -0700 (PDT) Date: Sun, 25 Mar 2012 23:44:17 +0200 Message-ID: From: Jens Rasmus Liland To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Buildworld fails on RELENG_8 amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 21:44:18 -0000 Hello. I can not do a make world like before to upgrade my RELENG_8 box to latest 8.3 prerelease and then to RELENG_9. make buildworld just returns this: ----snip----- root@stack ~src # make buildworld -------------------------------------------------------------- >>> World build started on Sun Mar 25 22:45:10 CEST 2012 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 mkdir -p /usr/obj/usr/src/tmp/lib mkdir -p /usr/obj/usr/src/tmp/usr mkdir -p /usr/obj/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/tmp -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/u sr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/ usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION="FreeBSD 8.3-PREREL EASE amd64 803500" MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" make -f Makefile.i nc1 DESTDIR= BOOTSTRAPPING=803500 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT _MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF legacy ===> tools/build (obj,includes,depend,all,install) /usr/obj/usr/src/tmp/usr/src/tools/build created for /usr/src/tools/build cd /usr/src/tools/build; make buildincludes; make installincludes rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/tools/build/dummy.c Abort trap mkdep: compile failed *** Error code 1 Stop in /usr/src/tools/build. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 1 root@stack ~src # ----snip---- I have tried doing make clean, make cleanworld and make buildworld TARGET=amd64. This is my uname -a: FreeBSD stack.flat.home 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #10: Mon Mar 19 19:56:11 CET 2012 root@stack.flat.home:/usr/obj/usr/src/sys/STACK amd64 Since my last upgrade a week ago I was sure I did destroy everything because it did not get dhcp before adding synchronous_dhclient="YES" to /etc/rc.conf. I have searced around a bit, but buildworld failures seems to be pretty specific when they happen and the mailing list is the right place to dicuss errors. I was thinking maybe reinstalling, but it is quite a hassle to manage the whole gpt zroot mirror thing in one evening. With regards, Rasmus From owner-freebsd-stable@FreeBSD.ORG Sun Mar 25 21:51:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59617106566B; Sun, 25 Mar 2012 21:51:37 +0000 (UTC) (envelope-from jensrasmus@gmail.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id D36258FC12; Sun, 25 Mar 2012 21:51:36 +0000 (UTC) Received: by qao25 with SMTP id 25so1965636qao.13 for ; Sun, 25 Mar 2012 14:51:30 -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=2de19Y3r8WqARW0jP8fTktHpJCQ3m9dSCK+8Zokm4ik=; b=XmXvisGcHDhEB/CgB8ulCrDaKY03VWxJbcMyZ9GgU50lEsDLnufTNUS0APnpcGbDip j3tNQCRXz314pvDMdOF4MdqLg02+RiGeBZZq+RroWvkBjSmoIMI/X5/25+XCJPie7ifW YZMkOTZK5ITBZeBsRdscWZvWkIrwyUTHTvmftQkfKPqoldJDSl19ty4wOJzVhZ4wi05S yFDDD0GAcveQawIGiCALmAOM7nHWTEanhJfXqqRSve1ylpjBfsct2n+lUnTPxH9lZLYL 6zLxj11iyb59FILtcBhlK+b+htpMJjA8VeG74tiHPPYs0YUwQwarOla0N1aEvLtwd67w LZ3g== MIME-Version: 1.0 Received: by 10.229.78.86 with SMTP id j22mr7418506qck.95.1332712290534; Sun, 25 Mar 2012 14:51:30 -0700 (PDT) Received: by 10.229.121.4 with HTTP; Sun, 25 Mar 2012 14:51:30 -0700 (PDT) Date: Sun, 25 Mar 2012 23:51:30 +0200 Message-ID: From: Jens Rasmus Liland To: freebsd-usb@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: CAM_BOOT_DELAY option in RELENG_9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 21:51:37 -0000 Hello. I am in the process of upgrading from RELENG_8 to RELENG_9 on my Sheevaplug (arm), but I am using this slow harddrive usb case so in RELENG_8 I have silmply added `options CAM_BOOT_DELAY=4000' to the kernel config file and the kernel has waited for the drive. I believe this option has changed in RELENG_9 because it does not have the same effect, which results in the kernel dropping into the mountroot enviroment waiting for me to specify drives that have not been recognized. With regards, Rasmus From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 07:28:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB24F1065677 for ; Mon, 26 Mar 2012 07:28:06 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by mx1.freebsd.org (Postfix) with ESMTP id 0D10A8FC1D for ; Mon, 26 Mar 2012 07:28:05 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADMacE/LevdH/2dsb2JhbABEuTaCCQEBBThBEAsYCRMDDwkDAgECAUUGDQEFAgEBiAW4M4pZhk8Epg2CeoFC Received: from ppp247-71.static.internode.on.net (HELO leader.local) ([203.122.247.71]) by ipmail06.adl6.internode.on.net with ESMTP; 26 Mar 2012 17:57:51 +1030 Message-ID: <4F7019FC.4090907@ShaneWare.Biz> Date: Mon, 26 Mar 2012 17:55:48 +1030 From: Shane Ambler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120322 Thunderbird/10.0.3 MIME-Version: 1.0 To: "C. P. Ghost" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: prabhpal@digital-infotech.net, freebsd-stable@freebsd.org Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:28:06 -0000 On 26/03/2012 02:19, C. P. Ghost wrote: > On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi > wrote: >> Greetings Friends, >> >> have anyone has come across this warning / error? This occurs when i ssh >> to my FreeBSD 9.0 System. any help would be greatly appreciated. >> >> Warning: >> /usr/share/games/fortune/freebsd-tips.dat: Too many open files in system >> [mavi@titan ~]$ su >> su: pam_start: system error >> >> Thanks / Regards >> Prabhpal > > What does this command say on your system? > > % sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles > > You may have exceeded the maximum number of open files > in the system. Maybe some ill-conceived program that doesn't > close non-needed connections, files, etc is at fault? It's easy > to open more and more files, and to gradually fill the open > files descriptor table in the kernel this way. > > -cpghost. > From knowing that you have too many files open you can increase the maxfile numbers - but if you want to know what uses them try this - lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort lsof outputs open file info, awk then gives us the PID and proc name which gets sorted and uniq gives a count of each which we sort to have the largest file count at the bottom of the list. What you end up with is a list of two numbers and a name - count of files open followed by the PID and proc name that has them open. The catch is that it also includes network connections (I know how to list only network but not sure how to exclude them) ps ax | grep PID will show you the full program name if it has been shortened. lsof -p PID will show all the open files for PID Not sure if this is the best way but it works for me. From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 08:47:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E89C9106566B for ; Mon, 26 Mar 2012 08:47:40 +0000 (UTC) (envelope-from prabhpal@digital-infotech.net) Received: from mail.digital-infotech.net (mail.digital-infotech.net [41.211.25.193]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE1A8FC08 for ; Mon, 26 Mar 2012 08:47:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id E0FA52E402A; Mon, 26 Mar 2012 08:55:17 +0000 (GMT) Received: from mail.digital-infotech.net ([127.0.0.1]) by localhost (mail.digital-infotech.net [127.0.0.1]) (maiad, port 10024) with ESMTP id 06004-07; Mon, 26 Mar 2012 08:55:14 +0000 (GMT) Received: from mail.digital-infotech.net (localhost [127.0.0.1]) by mail.digital-infotech.net (Postfix) with ESMTP id 3FA2B2E4028; Mon, 26 Mar 2012 08:55:14 +0000 (GMT) Received: from 41.211.28.2 (SquirrelMail authenticated user prabhpal@digital-infotech.net) by mail.digital-infotech.net with HTTP; Mon, 26 Mar 2012 08:55:14 -0000 Message-ID: <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> In-Reply-To: <4F7019FC.4090907@ShaneWare.Biz> References: <4F7019FC.4090907@ShaneWare.Biz> Date: Mon, 26 Mar 2012 08:55:14 -0000 From: "Prabhpal S. Mavi" To: "Shane Ambler" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org, prabhpal@digital-infotech.net, "C. P. Ghost" Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: prabhpal@digital-infotech.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:47:41 -0000 Hello Shane, thanks for your valuable response, this is brilliant. this is what i was exactly looking for. very good command indeed. Grateful for your kind assistance Thanks / Regards > On 26/03/2012 02:19, C. P. Ghost wrote: >> On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi >> wrote: >>> Greetings Friends, >>> >>> have anyone has come across this warning / error? This occurs when i >>> ssh >>> to my FreeBSD 9.0 System. any help would be greatly appreciated. >>> >>> Warning: >>> /usr/share/games/fortune/freebsd-tips.dat: Too many open files in >>> system >>> [mavi@titan ~]$ su >>> su: pam_start: system error >>> >>> Thanks / Regards >>> Prabhpal >> >> What does this command say on your system? >> >> % sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles >> >> You may have exceeded the maximum number of open files >> in the system. Maybe some ill-conceived program that doesn't >> close non-needed connections, files, etc is at fault? It's easy >> to open more and more files, and to gradually fill the open >> files descriptor table in the kernel this way. >> >> -cpghost. >> > > From knowing that you have too many files open you can increase the > maxfile numbers - but if you want to know what uses them try this - > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort > > lsof outputs open file info, awk then gives us the PID and proc name > which gets sorted and uniq gives a count of each which we sort to have > the largest file count at the bottom of the list. What you end up with > is a list of two numbers and a name - count of files open followed by > the PID and proc name that has them open. > > The catch is that it also includes network connections (I know how to > list only network but not sure how to exclude them) > > ps ax | grep PID > > will show you the full program name if it has been shortened. > > lsof -p PID > > will show all the open files for PID > > Not sure if this is the best way but it works for me. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 08:56:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10E8A106566C for ; Mon, 26 Mar 2012 08:56:41 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id BCFDD8FC0A for ; Mon, 26 Mar 2012 08:56:40 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC5jE-0000Yq-8z for freebsd-stable@freebsd.org; Mon, 26 Mar 2012 10:56:40 +0200 Date: Mon, 26 Mar 2012 10:56:40 +0200 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20120326085640.GB5335@home.opsec.eu> References: <4F7019FC.4090907@ShaneWare.Biz> <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 08:56:41 -0000 Hi! > > From knowing that you have too many files open you can increase the > > maxfile numbers - but if you want to know what uses them try this - > > > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort On my system, it shows interesting numbers for firefox-instances: 3895 4150 firefox-b 4160 72958 firefox-b 4240 3594 firefox-b 4320 4232 firefox-b 4431 89391 firefox-b This seems to come from threads, where lsof shows the same descriptor as open for multiple times, even if it comes from the same process memory. For example for pid 4232: lsof -n | grep icon-theme.cache | grep 4232 | wc -l firefox-b 4232 pi txt VREG 0,102 10784 924293 /usr/local/share/icons/hicolor/icon-theme.cache This happens on 8.1-REL-p5 amd64. So the method is not fail-safe for the real number of open files. -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 09:16:17 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BFFB106566C for ; Mon, 26 Mar 2012 09:16:17 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 23E2B8FC21 for ; Mon, 26 Mar 2012 09:16:16 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q2Q9G8gN094581 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 10:16:08 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.0 smtp.infracaninophile.co.uk q2Q9G8gN094581 Authentication-Results: smtp.infracaninophile.co.uk/q2Q9G8gN094581; dkim=none (no signature); dkim-adsp=none Message-ID: <4F7033CF.6000308@FreeBSD.org> Date: Mon, 26 Mar 2012 10:15:59 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4F7019FC.4090907@ShaneWare.Biz> <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> <20120326085640.GB5335@home.opsec.eu> In-Reply-To: <20120326085640.GB5335@home.opsec.eu> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58A8A09048353A7D69848B96" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:16:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58A8A09048353A7D69848B96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26/03/2012 09:56, Kurt Jaeger wrote: >>> From knowing that you have too many files open you can increase the >>> > > maxfile numbers - but if you want to know what uses them try this= - >>> > > >>> > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort > On my system, it shows interesting numbers for firefox-instances: >=20 > 3895 4150 firefox-b > 4160 72958 firefox-b > 4240 3594 firefox-b > 4320 4232 firefox-b > 4431 89391 firefox-b >=20 > This seems to come from threads, where lsof shows the same > descriptor as open for multiple times, even if it comes from the > same process memory. >=20 > For example for pid 4232: >=20 > lsof -n | grep icon-theme.cache | grep 4232 | wc -l >=20 > firefox-b 4232 pi txt VREG 0,102 = 10784 924293 /usr/local/share/icons/hicolor/icon-theme.cache >=20 > This happens on 8.1-REL-p5 amd64. So the method is not fail-safe > for the real number of open files. >=20 Does 'procstat -fa' give better results for you? It seems to be one of those little hidden secrets that FreeBSD comes with a bunch of native applications that provide pretty much equivalent functionality to lsof(1). See: fstat(1), procstat(1), sockstat(1). Which is odd, given that since these sort of applications have to read and interpret kernel memory -- an action for which there isn't a nice well defined ABI -- the application has to be kept rigorously in synch with the kernel it is used against. Something that is intrinsically easier to do when kernel and application are compiled at the same time and from the same source tree. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig58A8A09048353A7D69848B96 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9wM9gACgkQ8Mjk52CukIyKdgCghatb6YnDZqEyRZnKFQ9Fk9jJ iPIAn0Hu7ziAHoy5WIjVztQHDllRQ1TL =uVTP -----END PGP SIGNATURE----- --------------enig58A8A09048353A7D69848B96-- From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 09:19:14 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C511106566B for ; Mon, 26 Mar 2012 09:19:14 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1705A8FC26 for ; Mon, 26 Mar 2012 09:19:14 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SC654-0000yt-Cn for freebsd-stable@FreeBSD.org; Mon, 26 Mar 2012 11:19:14 +0200 Date: Mon, 26 Mar 2012 11:19:14 +0200 From: Kurt Jaeger To: freebsd-stable@FreeBSD.org Message-ID: <20120326091914.GC5335@home.opsec.eu> References: <4F7019FC.4090907@ShaneWare.Biz> <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> <20120326085640.GB5335@home.opsec.eu> <4F7033CF.6000308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7033CF.6000308@FreeBSD.org> Cc: Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 09:19:14 -0000 Hi! > >>> > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort > > On my system, it shows interesting numbers for firefox-instances: [...] > Does 'procstat -fa' give better results for you? Yes, much better. -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 14:48:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 062EB106564A; Mon, 26 Mar 2012 14:48:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CEF248FC1E; Mon, 26 Mar 2012 14:48:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 862BA46B0D; Mon, 26 Mar 2012 10:48:12 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C3546B94E; Mon, 26 Mar 2012 10:48:11 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 26 Mar 2012 10:42:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F6DB568.1060604@lexa.ru> In-Reply-To: <4F6DB568.1060604@lexa.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203261042.15948.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Mar 2012 10:48:11 -0400 (EDT) Cc: Alex Tutubalin , Jeff Roberson , freebsd-stable@freebsd.org Subject: Re: 9-STABLE + Infiniband - incorrect interface counters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 14:48:13 -0000 On Saturday, March 24, 2012 7:52:08 am Alex Tutubalin wrote: > Hi, > > I'm playing with two FreeBSD 9-STABLE boxes connected via 10Gbps > Infiniband (more details below) in Infiniband connected mode. > > I see incorrect interface statistics (e.g. in netstat output), output > counters are 2x more than expected. > > EXAMPLE, ftp transfer of 1 GiB file: > > ftp> put file /dev/null > local: file remote: /dev/null > 229 Entering Extended Passive Mode (|||57978|) > 150 Opening BINARY mode data connection for '/dev/null'. > 100% |***********************************| 953 MiB 390.43 MiB/s > 00:00 ETA > 226 Transfer complete. > 1000000000 bytes sent in 00:02 (390.13 MiB/s) > > Netstat on receiving side, counters are correct (for input): > > lexa@home-gw:/home/lexa# netstat -I ib1 5 > input (ib1) output > packets errs idrops bytes packets errs bytes colls > 0 0 0 0 0 0 0 0 > 13955 0 0 222688126 9027 0 1192796 0 > 48921 0 0 780832960 32129 0 4240596 0 > 0 0 0 0 0 0 80 0 > > Sum of bytes (input) is 1003521086, as expected. > > Netstat on sending size, output is 2x more: > > lexa@new-gw:/home/lexa# netstat -I ib0 5 > input (ib0) output > packets errs idrops bytes packets errs bytes colls > 1 0 0 100 0 0 0 0 > 41162 0 0 2305210 62878 0 2008325984 0 > 1 0 0 100 0 0 0 0 > > It looks like packet count is correct (13955+48921=62876, two packets > missed somewhere), while byte count is exact 2x more. Yes, this is a bug. if_obytes already gets incremented in IFQ_HANDOFF(), so the IB code doesn't need to do it again. Try the patch at www.freebsd.org/~jhb/patches/ipoib_obytes.patch I can't speak to the MTU issue though. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 16:54:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75524106564A for ; Mon, 26 Mar 2012 16:54:25 +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 E83FC8FC14 for ; Mon, 26 Mar 2012 16:54:24 +0000 (UTC) Received: by lagv3 with SMTP id v3so5488150lag.13 for ; Mon, 26 Mar 2012 09:54:23 -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=DO0vmCIqeFdfbnIlXtCsjuPwdEVqYFgttGP2f0IteVE=; b=Yc/hn0ml0jQ2STFlVvxsIWCRgbE0RRyRRwssgUX8AbrN/lZmxdimNCE/xiZAqZHlxj u76OS9GKemnnrnCTskP9vJ4gqkW5qi18tVYRPIqVQnCe9sEl14Bynt/hPWIWXidjxyhD OxdfsWM8F7VNSs5cjBSCpt+JPEQhdhjVaeBZ+y8DaxVZvC08YrXC/DqkdZqUUudUgaES vk3xU0eoDJYLCEpQZsKYdtH9xUSCu3phb7aqINkPQlpAMkIAkY6zJNRsPoafmXbkq+vH hw93g8Xkuu9Eew4mxqjtFy1Lv9f1+YMndThPXU8B7ajzJwWtBnTU4CdwQfr54g7Uv8rY sIdg== MIME-Version: 1.0 Received: by 10.152.105.211 with SMTP id go19mr16710095lab.51.1332780863798; Mon, 26 Mar 2012 09:54:23 -0700 (PDT) Received: by 10.112.100.229 with HTTP; Mon, 26 Mar 2012 09:54:23 -0700 (PDT) X-Originating-IP: [64.147.96.250] Date: Mon, 26 Mar 2012 12:54:23 -0400 Message-ID: From: Mark Saad To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmxdZOkrjDjiB93sGVR2wIwwcE2W6Xiz/MY9CTzyyiZQdgR53HZ18Gv9uViASahqWRbLs1o Subject: ACPI Issues in 8-STABLE and on X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:54:25 -0000 All I was wondering if anyone has looking into this ACPI issue noted back in 2010. http://lists.freebsd.org/pipermail/freebsd-acpi/2010-February/006332.html I attempted to upgrade a 7-STABLE DL385g1 with 4G of ram to 9-STABLE and it was a disaster. The box was able to boot once and then on a normal reboot the root filesystem was corrupted beyond repair ( most likely unrelated , but some unknown issue with su+j *) and the system would not get past the point noted in the a fore mentioned thread . I tried to boot this box with 8.2-RELASE amd64 same issue, 9.0-BETA1 , same issue, 9.0-RELEASE same issue , and 9.0-STABLE as I pointed out worked intermittently. So the end result is that this box now only reliably runs 7.0-RELEASE - 7.4-RELEASE and 7-STABLE , 6.2-RELEASE - 6.4-RELEASE and 6-STABLE but nothing else. As a side test , NetBSD 6.0 beta amd64 boots with out issues on this box as well as DragonFlyBSD 3.01 amd64. So my solutions are to migrate back to 7-STABLE or use Net or Dfly. Does anyone know what the root issue is here ? * The su-j issue was most likely caused by me not properly converting the old su slice to su+j . I think I may have done a tunefs -j enable before I did a tunefs -n disable && fsck . -- mark saad | nonesuch@longcount.org From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 19:24:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73D11065674 for ; Mon, 26 Mar 2012 19:24:17 +0000 (UTC) (envelope-from adrian.chadd@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 80D498FC16 for ; Mon, 26 Mar 2012 19:24:17 +0000 (UTC) Received: by yhgm50 with SMTP id m50so5032977yhg.13 for ; Mon, 26 Mar 2012 12:24:17 -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; bh=8Aj+RehZpLtT2N83iKKCGJ83LI9xRfCrLGCJS9vc5ik=; b=JN6NuOSh0L0fN7UXrfpnrGouagq/X7bask64Z+46FyNvkfPXfkldEg7yyagJWlT/DO bk0oppwd/ylxHZ8Vit8ArtmvfTL+ZrufTfeyL3unqAD64VFm6iOfPb1/YoGPK3pkCTiQ a8cjNdSOhLGrL6DdlX9EiyWtt26licXxjLcA/PifGrzf1y5kNgEpYyfQlGnvoIE18kKQ MK26Vqyh/EuzT4LG8ZiCeCmGF5eaYTdrB5ePegezZc5ixoVuNyA2E2o6t7q4OOngrfh6 nw37KeSq7qFqcQcFP4uIWL7lAHk9gl9/8YwyePzrcr8UHhaw0/1LPgz2Xg2VpfXTRBni 0YOw== MIME-Version: 1.0 Received: by 10.68.240.135 with SMTP id wa7mr55669362pbc.7.1332789856665; Mon, 26 Mar 2012 12:24:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Mon, 26 Mar 2012 12:24:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 12:24:16 -0700 X-Google-Sender-Auth: glAtM--UcupLlpF9O-c1XI-NAdQ Message-ID: From: Adrian Chadd To: Mark Saad Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ACPI Issues in 8-STABLE and on X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 19:24:17 -0000 Hi, Have you filed PRs for this? It seems like something you could easily(!) find the offending commit(s) by doing kernel builds of -HEAD around the time that 8 was branched off. If 8.0-RELEASE fails but 7-STABLE does, that's a good starting point to determine the lower/upper bounds for the -HEAD commit(s) that broke things for you. It would be really appreciated if you were able to help track this down as I doubt the ACPI developers have the hardware. Thanks! Adrian From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 21:34:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 504BC106567C for ; Mon, 26 Mar 2012 21:34:58 +0000 (UTC) (envelope-from cowbert@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D57A38FC1F for ; Mon, 26 Mar 2012 21:34:57 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6002750bkc.13 for ; Mon, 26 Mar 2012 14:34:57 -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=QrIe8qOjJ6/tTG4PRxJQCK4oDXY+DOekDKb3fF7XQeA=; b=u6USterAjD6qIIrgNdWG245cQ+Owz+c3BB1dvQyqMDZYv9jLKaWcT5I5P4NRTqyYy5 gQK3FayAR4tRG/lr6iPuYXb4c9RcbnHMy+hllQOfi4WBj4faoBezfUOamiQzM0R2IiBc B/GrHTuBJ3XZqKUhERyMUXabBY01gmbzPQnmAYK0z+NEZmfv4AapteXMRp3UdLMweczH 6XIhfskxjsHj9v84qK/WO4DfdEGl0jtr1xpAbKpkYyWEt4PuZKMZAMIpNyjpI/udhaUL DYERV214mikIh7RHIMP2oj8h4W1hE+NOGiiBOpXdx0sb9dLp5+ad5r75xY7i/yUzCT/t RSCw== MIME-Version: 1.0 Received: by 10.205.130.12 with SMTP id hk12mr9429621bkc.76.1332797696898; Mon, 26 Mar 2012 14:34:56 -0700 (PDT) Received: by 10.204.186.80 with HTTP; Mon, 26 Mar 2012 14:34:56 -0700 (PDT) Date: Mon, 26 Mar 2012 16:34:56 -0500 Message-ID: From: Peter Lai To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: upgrade to 8.3 from 7.2 static root mountpoint disappeared X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 21:34:58 -0000 I just did an upgrade from an old 7.2 installation to 8.3-RC2 last night, and the kernel was only able to mount root from a ufsid label and could not detect any bsdlabels. The 7.2 installation used static bsdlabeled disks (/dev/ad0s1a etc). This seemed to be an unexpected change (I had to get the remote datacenter to connect an ipkvm to fix the problem), particularly because the 7.2 kernel never loaded geom_label but somehow the partitions ended up with labels quite mysteriously; the box was originally installed from 6.x-R from 2006. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 09:10:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D15F106566B for ; Tue, 27 Mar 2012 09:10:35 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: from mail47.e.nsc.no (mail47.e.nsc.no [193.213.115.47]) by mx1.freebsd.org (Postfix) with ESMTP id B45598FC14 for ; Tue, 27 Mar 2012 09:10:34 +0000 (UTC) Received: from terraplane.org (ti0027a380-0343.bb.online.no [80.212.64.89]) by mail47.nsc.no (8.14.4/8.14.4) with ESMTP id q2R8wWba001869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 10:58:32 +0200 (MEST) Received: from terraplane.org (localhost [127.0.0.1]) by terraplane.org (8.14.5/8.14.5) with ESMTP id q2R8wVQY076930; Tue, 27 Mar 2012 10:58:31 +0200 (CEST) (envelope-from rumrunner@terraplane.org) Received: (from rumrunner@localhost) by terraplane.org (8.14.5/8.13.8/Submit) id q2R8wVcR076929; Tue, 27 Mar 2012 10:58:31 +0200 (CEST) (envelope-from rumrunner) Date: Tue, 27 Mar 2012 10:58:31 +0200 From: Eivind Evensen To: Thomas Laus Message-ID: <20120327085831.GA75987@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F64608B.27301.3724F1@lausts.acm.org> Cc: "freebsd-stable@freebsd.org" Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 09:10:35 -0000 On Sat, Mar 17, 2012 at 09:59:39AM -0400, Thomas Laus wrote: > List: > > I keep archival floppy disk copies of EPROM images on CDROM and occasionally > need to DD them back to a floppy disk for my programmer to load. I recently > upgraded two of my shop computers from FreeBSD 7 Stable to FreeBSD 9 Stable > with clean installs. I tried the 'fdformat' command prior to 'dd' of the > image file yesterday. All of my floppy disks showed errors on all tracks. I > used a ^C to abort the command and the PC dropped core. I used the same > disks on my laptop with OpenBSD 5 and everything worked as expected. I was > able to format and diskdupe the image to them. I looked over the Release > Notes for FreeBSD 9 and there wasn't any mention of eliminating floppy disk > support on either FreeBSD 8 or 9. This happened on two different PC's, both > running FreeBSD 9. The hardware isn't suspect because these same two PC's > were able to format and dupe images when running FreeBSD 7. For what it's worth, I had problems writing images back to a floppy disk at around 8.0 prerelease. Dd wrote the image ok, but when closing the device, the machine panicked. Problem is gone on 8.2 and 8.3 (prerelease), and I haven't tried 9 yet. -- Eivind From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 13:14:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C97106566B for ; Tue, 27 Mar 2012 13:14:54 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id D38DF8FC0A for ; Tue, 27 Mar 2012 13:14:53 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=Z8Fu7QtA c=1 sm=0 a=de+ksHeJaPmK8cA12er7Ag==:17 a=VyBCHhcZmHwA:10 a=8JOjVTPaRU0A:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=CzioZpcOACmhTAYLvP8A:9 a=de+ksHeJaPmK8cA12er7Ag==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.31.23.46 Received: from [98.31.23.46] ([98.31.23.46:60807] helo=mail.laus.org) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 85/0F-17707-D4DB17F4; Tue, 27 Mar 2012 13:14:53 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.5/8.14.5) with ESMTP id q2RDEqKN009866 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Mar 2012 09:14:52 -0400 (EDT) (envelope-from lausts@acm.org) From: "Thomas Laus" Organization: ABB To: Eivind Evensen Date: Tue, 27 Mar 2012 09:14:57 -0400 Message-ID: <4F718511.4516.277503@lausts.acm.org> Priority: normal In-reply-to: <20120327085831.GA75987@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org>, <20120327085831.GA75987@klump.hjerdalen.lokalnett> X-mailer: Pegasus Mail for Windows (4.41) Cc: "freebsd-stable@freebsd.org" Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:14:54 -0000 > For what it's worth, I had problems writing images back to a > floppy disk at around 8.0 prerelease. Dd wrote the image ok, > but when closing the device, the machine panicked. Problem is > gone on 8.2 and 8.3 (prerelease), and I haven't tried 9 yet. > My two computers running FreeBSD 9 can't even fdformat the floppy. The format utility runs and marks all tracks bad. If I abort the process, the computer panics. I always fdformat a floppy before running DD because I find that DOS fomatting of the disk does not catch all of the surface errors. The floppy disks that were marked bad by FreeBSD 9 were successfully formatted by my laptop that runs OpenBSD 5. I was able to successfully DD the image from CDROM to the 'bad' floppy disk from the laptop. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 15:48:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 862811065674 for ; Tue, 27 Mar 2012 15:48:31 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 112B78FC12 for ; Tue, 27 Mar 2012 15:48:30 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so48954bkc.13 for ; Tue, 27 Mar 2012 08:48:29 -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:subject :content-type:content-transfer-encoding; bh=4wYqLd/+lQNUJnN6AwZdnpvpq2GLRLsyGLd+h/d3sic=; b=0FWyWc3LyTUgxnQ6tdJ6LbaqTCN7grJenKBFNbujeJ9Bd7pgpHB5ceuYztQHa6L6Hz CGSYI1ezmRehqKyRcriNKr4bqbqzemt4V9HcmJqtH39gvn42auig1gMBAo470eCTVBrV sxcxp4x5F/tt7Q5I0pUh9GXEXzZL+C5pVy8aVDKAhhPNem9KTlZfaPVdiym7K8rngPqf jnm4ZSD0Y+SJ0sWSKSHFz2+4Wx/zV/L+e2xpkiYx9N7a+OlT12KA7/3zTHzDxxWb2IKQ bYWgMWjx7L2HM1NlMnC1SfEafcs3Clr6VFrEJDeT/FGzVp8ggTNl8SezSFSkqDT140b+ 8DXQ== Received: by 10.204.149.204 with SMTP id u12mr5115075bkv.45.1332863309675; Tue, 27 Mar 2012 08:48:29 -0700 (PDT) Received: from green.tandem.local (16-184-132-95.pool.ukrtel.net. [95.132.184.16]) by mx.google.com with ESMTPS id p19sm450864bka.1.2012.03.27.08.48.27 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 08:48:28 -0700 (PDT) Message-ID: <4F71E14A.8010605@gmail.com> Date: Tue, 27 Mar 2012 18:48:26 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: trap 12 on 9.0 when memcache gets some load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:48:31 -0000 Hi all. I'm just puzzled with this. At first I though this happens because of some memory problems. But now project was moved to another server with some other brands for motherboard/memory and different cpu's. And still once in an hour this happens again: == screenshot current_process = 1935 (memcached) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff8038ab38 at kdb_backtrace+0x58 #1 0xffffffff80358f80 at panic+0x190 #2 0xffffffff80567b15 at trap_fatal+0x395 #3 0xffffffff80567ce9 at trap_pfault+0x1c9 #4 0xffffffff80567536 at trap+0x3a6 #5 0xffffffff80552603 at calltrap+0x8 #6 0xffffffff803b2c90 at socow_setup+0xd0 #7 0xffffffff803bc12a at sosend_copyin+0x10a #8 0xffffffff803bc7c6 at sosend_generic+0x4f6 #9 0xffffffff803c2028 at kern_sendit+0x1e8 #10 0xffffffff803c22a1 at sendit+0xd1 #11 0xffffffff803c2331 at sys_sendmsg+0x61 #12 0xffffffff805681c5 at amd64_syscall+0x2a5 #13 0xffffffff805528eb at Xfast_syscall+0xfb GEOM_MIRROR: Device beeb0swap: provider mirror/beeb0swap destroyed. GEOM_MIRROR: Device beeb0swap destroyed. GEOM_MIRROR: Device kohrah0swap: provider mirror/kohrah0swap destroyed. GEOM_MIRROR: Device kohrah0swap destroyed. Uptime: 1d10h46m37s Dumping 9737 out of 12268 MB: == And everything stalls. I have dumpdev_auto set at /etc/rc.conf and selected swap device (kohrah0swap) size is 32Gb so it should save dumps but it doesn't. Next time i'll try to give it raw volume for dump. The most curious thing for me is userland app crashing whole kernel. If I switch to redis everything works like a charm. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 16:08:06 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6EF1065672 for ; Tue, 27 Mar 2012 16:08:06 +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 432558FC1D for ; Tue, 27 Mar 2012 16:08:05 +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 TAA10394; Tue, 27 Mar 2012 19:02:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F71E482.7060509@FreeBSD.org> Date: Tue, 27 Mar 2012 19:02:10 +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: Volodymyr Kostyrko References: <4F71E14A.8010605@gmail.com> In-Reply-To: <4F71E14A.8010605@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: trap 12 on 9.0 when memcache gets some load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:08:07 -0000 on 27/03/2012 18:48 Volodymyr Kostyrko said the following: > Hi all. > > I'm just puzzled with this. At first I though this happens because of some memory > problems. But now project was moved to another server with some other brands for > motherboard/memory and different cpu's. And still once in an hour this happens again: > > == screenshot > current_process = 1935 (memcached) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff8038ab38 at kdb_backtrace+0x58 > #1 0xffffffff80358f80 at panic+0x190 > #2 0xffffffff80567b15 at trap_fatal+0x395 > #3 0xffffffff80567ce9 at trap_pfault+0x1c9 > #4 0xffffffff80567536 at trap+0x3a6 > #5 0xffffffff80552603 at calltrap+0x8 > #6 0xffffffff803b2c90 at socow_setup+0xd0 I think that zero-copy sockets are not regarded as a reliable feature. Not an expert, just my two cents. > #7 0xffffffff803bc12a at sosend_copyin+0x10a > #8 0xffffffff803bc7c6 at sosend_generic+0x4f6 > #9 0xffffffff803c2028 at kern_sendit+0x1e8 > #10 0xffffffff803c22a1 at sendit+0xd1 > #11 0xffffffff803c2331 at sys_sendmsg+0x61 > #12 0xffffffff805681c5 at amd64_syscall+0x2a5 > #13 0xffffffff805528eb at Xfast_syscall+0xfb > GEOM_MIRROR: Device beeb0swap: provider mirror/beeb0swap destroyed. > GEOM_MIRROR: Device beeb0swap destroyed. > GEOM_MIRROR: Device kohrah0swap: provider mirror/kohrah0swap destroyed. > GEOM_MIRROR: Device kohrah0swap destroyed. > Uptime: 1d10h46m37s > Dumping 9737 out of 12268 MB: > == > > And everything stalls. I have dumpdev_auto set at /etc/rc.conf and selected swap > device (kohrah0swap) size is 32Gb so it should save dumps but it doesn't. Next > time i'll try to give it raw volume for dump. > > The most curious thing for me is userland app crashing whole kernel. If I switch > to redis everything works like a charm. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 16:45:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2752B1065672 for ; Tue, 27 Mar 2012 16:45:27 +0000 (UTC) (envelope-from adrian.chadd@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 D51E38FC0A for ; Tue, 27 Mar 2012 16:45:26 +0000 (UTC) Received: by yhgm50 with SMTP id m50so125512yhg.13 for ; Tue, 27 Mar 2012 09:45:26 -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; bh=38RgLcqEkI6KGe9nDAqMm2zVTwnHHoOkr4K9WzRoy4I=; b=1Bna2fC3RKtZN4d1sQ4so9T/ijbIbEyIMaLC1JlGKKtihgumBZEgroGKl1Qwlk8s/X z5061tsH+cam0VE85XGuDUrfUGCBpp0fn9Vd7LOh/6BiMhoN4jQUhk5ABrt2Btmh8gCc X/2TmU9KOiqEzvFrb3VpV6IYLHq+tUxAUbB3dLP2cSySyyun46eFs1YhOLrpBgcl5hoY kawGPriS1FXyGTmcEfD1FUlk6AkAqbNxesjGxTGL37yRr+SyupDbUcXh754YcMJDlgTy WGVjzMclJ33I3M7irTOfA4GKKRTGqzP8IcWbVbJ9AtfAWbS2nsxFP6gPrQGMCcDpoudY DKqw== MIME-Version: 1.0 Received: by 10.68.202.195 with SMTP id kk3mr51645919pbc.96.1332866725794; Tue, 27 Mar 2012 09:45:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Tue, 27 Mar 2012 09:45:25 -0700 (PDT) In-Reply-To: <20120327085831.GA75987@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327085831.GA75987@klump.hjerdalen.lokalnett> Date: Tue, 27 Mar 2012 09:45:25 -0700 X-Google-Sender-Auth: 3H-zrRotF5rBFilSkn5JqUBD638 Message-ID: From: Adrian Chadd To: Eivind Evensen Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" , Thomas Laus Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:45:27 -0000 Hi, can you please try 8-stable and 9-stable, and if it's still failing, file a PR? I don't know who looks after the floppy subsystem but it shouldn't exactly be difficult to fix.. Adrian From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 18:35:01 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05F141065670 for ; Tue, 27 Mar 2012 18:35:01 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 98F8C8FC0A for ; Tue, 27 Mar 2012 18:35:00 +0000 (UTC) Received: from WildRover.lariat.net (IDENT:ppp1000.lariat.net@lariat.net [66.119.58.2] (may be forged)) by lariat.net (8.9.3/8.9.3) with ESMTP id MAA08436 for ; Tue, 27 Mar 2012 12:25:48 -0600 (MDT) Message-Id: <201203271825.MAA08436@lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Mar 2012 12:25:26 -0600 To: stable@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Support for releases X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:35:01 -0000 Everyone: I've just noted that as of this month, there is no release of FreeBSD -- on any branch -- whose EOL is less than a year away. Should there not be at least one release with extended support? --Brett Glass From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 18:59:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 35E3F106566B for ; Tue, 27 Mar 2012 18:59:29 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 963C48FC1D for ; Tue, 27 Mar 2012 18:59:28 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q2RIxOcN030247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 27 Mar 2012 19:59:25 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.0 smtp.infracaninophile.co.uk q2RIxOcN030247 Authentication-Results: smtp.infracaninophile.co.uk/q2RIxOcN030247; dkim=none (no signature); dkim-adsp=none Message-ID: <4F720E0C.1030108@FreeBSD.org> Date: Tue, 27 Mar 2012 19:59:24 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <201203271825.MAA08436@lariat.net> In-Reply-To: <201203271825.MAA08436@lariat.net> X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8EDFDC91CD77F09573241627" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: Support for releases X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 18:59:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EDFDC91CD77F09573241627 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27/03/2012 19:25, Brett Glass wrote: > I've just noted that as of this month, there is no release of FreeBSD -= - > on any branch -- whose EOL is less than a year away. Should there not > be at least one release with extended support? ITYM 'more than a year away' there... 8.3 is due, in fact, over due now, but should be out fairly soon. That should be the extended support version you're looking for. I believe that RE have stated that the lifetime of various branches due to drop out of support soon will be extended due to the delay in getting 8.3-RELEASE out of the door, but that was only to cover any potential gap= =2E Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig8EDFDC91CD77F09573241627 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9yDgwACgkQ8Mjk52CukIxktwCePOMmNCkBjpiEu/T0OOx6bPrN jAgAmgOAvnktemHFCJWZsNKc9IIh4O// =HhsM -----END PGP SIGNATURE----- --------------enig8EDFDC91CD77F09573241627-- From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 19:03:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 406F31065679 for ; Tue, 27 Mar 2012 19:03:58 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id D13078FC18 for ; Tue, 27 Mar 2012 19:03:57 +0000 (UTC) Received: (qmail 89685 invoked by uid 0); 27 Mar 2012 18:57:17 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2012 18:57:17 -0000 Received: (qmail 89678 invoked by uid 90); 27 Mar 2012 18:57:17 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 27 Mar 2012 18:57:17 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Charles Sprickman In-Reply-To: <201203271825.MAA08436@lariat.net> Date: Tue, 27 Mar 2012 14:57:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE377AF-1B90-4985-B87B-BE027B3B9D98@bway.net> References: <201203271825.MAA08436@lariat.net> To: Brett Glass X-Mailer: Apple Mail (2.1084) Cc: stable@freebsd.org Subject: Re: Support for releases X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:03:58 -0000 On Mar 27, 2012, at 2:25 PM, Brett Glass wrote: > Everyone: >=20 > I've just noted that as of this month, there is no release of FreeBSD = -- on any branch -- whose EOL is less than a year away. Should there = not be at least one release with extended support? That will be 8.3: ---- =95 20120205 - Ping SecurityOfficer about expected support for = 8.3 (BjoernZeeb). =95 20120205 - ACK from SecurityOfficer on extended support = (ColinPercival). ---- http://wiki.freebsd.org/Releng/8.3TODO I assume once it's released, this will be updated: http://www.freebsd.org/security/#sup Charles >=20 > --Brett Glass >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 20:11:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D0A106566B; Tue, 27 Mar 2012 20:11:42 +0000 (UTC) (envelope-from rumrunner@terraplane.org) Received: from mail49.e.nsc.no (mail49.e.nsc.no [193.213.115.49]) by mx1.freebsd.org (Postfix) with ESMTP id D5AC38FC08; Tue, 27 Mar 2012 20:11:41 +0000 (UTC) Received: from terraplane.org (ti0027a380-0343.bb.online.no [80.212.64.89]) by mail49.nsc.no (8.14.4/8.14.4) with ESMTP id q2RJvxBJ020351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 21:57:59 +0200 (MEST) Received: from terraplane.org (localhost [127.0.0.1]) by terraplane.org (8.14.5/8.14.5) with ESMTP id q2RJvwEV080217; Tue, 27 Mar 2012 21:57:58 +0200 (CEST) (envelope-from rumrunner@terraplane.org) Received: (from rumrunner@localhost) by terraplane.org (8.14.5/8.13.8/Submit) id q2RJvw6L080216; Tue, 27 Mar 2012 21:57:58 +0200 (CEST) (envelope-from rumrunner) Date: Tue, 27 Mar 2012 21:57:58 +0200 From: Eivind Evensen To: Adrian Chadd Message-ID: <20120327195758.GA78507@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327085831.GA75987@klump.hjerdalen.lokalnett> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "freebsd-stable@freebsd.org" , Thomas Laus Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:11:42 -0000 Hi. On Tue, Mar 27, 2012 at 09:45:25AM -0700, Adrian Chadd wrote: > Hi, > > can you please try 8-stable and 9-stable, and if it's still failing, file a > PR? > > I don't know who looks after the floppy subsystem but it shouldn't > exactly be difficult to fix.. I'm a bit short on free machines, so the closest I can get right now is my everyday machine running from sources cvsupped from RELENG_8 3.rd of March: uname -a FreeBSD elg.hjerdalen.lokalnett 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #42: Sat Mar 3 20:05:21 CET 2012 rumrunner@elg.hjerdalen.lokalnett:/usr/obj/usr/src/sys/RUM amd64 fdformat works fine here with: dmesg |grep fdc fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Using the disk normally also works. Additionally, I tried to mount a DD disk (previously formatted and with files on), which also worked without hassle. I remember back on 6.X or 7.X, I found no other way to make DD disks work after having read/written HD disks than using fdformat -f720 on a disk first. Then again, that was on different hardware, so it may have other reasons. I have an old machine I could install 9.0 on in order to test there, but I'd have to install that machine from floppy and I can't seem to find images for that any more. If it's of interest, I could probably find another machine to install on, then move the harddrive to the other machine, but I'd need to some for that. Regards -- Eivind From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 21:21:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B26E3106566C for ; Tue, 27 Mar 2012 21:21:52 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 0DF4C8FC17 for ; Tue, 27 Mar 2012 21:21:51 +0000 (UTC) Received: (qmail 30176 invoked from network); 27 Mar 2012 17:53:51 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 27 Mar 2012 17:53:51 -0000 Received: (qmail 30167 invoked by uid 599); 27 Mar 2012 17:53:51 -0000 Received: from unknown (HELO hydrogen.icritical.com) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Tue, 27 Mar 2012 18:53:51 +0100 Message-ID: <4F71FEAE.3090506@icritical.com> Date: Tue, 27 Mar 2012 18:53:50 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120204 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F68FC3E.2090401@icritical.com> In-Reply-To: <4F68FC3E.2090401@icritical.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Mar 2012 17:53:50.0918 (UTC) FILETIME=[9153DE60:01CD0C42] X-Virus-Scanned: by iCritical at mail1.icritical.com Subject: Re: SAS Drive identification LEDs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:21:52 -0000 On 03/20/12 21:53, Matt Burke wrote: > I've also tried playing around with Areca's SDK, however > FreeBSDSCSIInterface()->init(i) causes the closed source driver to panic > the kernel. AFAICT that class appears to be closed source too, so that's a > dead end too. Just to follow this up, I got in contact with Areca support, who sent me their new v1.00.00.02 (2012-03-23) arcsas driver and CLI tool, which is now available on their website: http://www.areca.com.tw/support/s_freebsd/nonraid_freebsd.htm The API download has also been updated (dated 2012-03-14) to include separate SAS HBA support, and stuff built against it works correctly for me. As a result I now have management visibility (and ability to toggle drive identification) via the ARC-1320 cards. -- Sorry for the below disclaimer... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 21:45:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05941065672; Tue, 27 Mar 2012 21:45:29 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 873F18FC12; Tue, 27 Mar 2012 21:45:29 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 6A5781E5F2D; Tue, 27 Mar 2012 23:45:28 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 5274D2847A; Tue, 27 Mar 2012 23:45:28 +0200 (CEST) Date: Tue, 27 Mar 2012 23:45:28 +0200 From: Jilles Tjoelker To: Matthew Seaman Message-ID: <20120327214528.GA33932@stack.nl> References: <4F7019FC.4090907@ShaneWare.Biz> <4660483b96cf883fd66b46f4578d1def.squirrel@mail.digital-infotech.net> <20120326085640.GB5335@home.opsec.eu> <4F7033CF.6000308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F7033CF.6000308@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:45:30 -0000 On Mon, Mar 26, 2012 at 10:15:59AM +0100, Matthew Seaman wrote: > Does 'procstat -fa' give better results for you? > It seems to be one of those little hidden secrets that FreeBSD comes > with a bunch of native applications that provide pretty much equivalent > functionality to lsof(1). See: fstat(1), procstat(1), sockstat(1). > Which is odd, given that since these sort of applications have to read > and interpret kernel memory -- an action for which there isn't a nice > well defined ABI -- the application has to be kept rigorously in synch > with the kernel it is used against. Something that is intrinsically > easier to do when kernel and application are compiled at the same time > and from the same source tree. procstat (in all versions that have it) and fstat (in FreeBSD 9.0 and newer) use a well-defined sysctl-based API to access the information. This API was extended in FreeBSD 9.0 and a library libprocstat provides a convenient interface. Reading from kernel memory not only couples the application tightly to the kernel implementation, but also can also be considered a security issue because there is a lot of sensitive information in kernel memory; it cannot be permitted in a jail. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 21:48:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DD6E106564A for ; Tue, 27 Mar 2012 21:48:33 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id BC1FF8FC0C for ; Tue, 27 Mar 2012 21:48:32 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=0 a=de+ksHeJaPmK8cA12er7Ag==:17 a=VyBCHhcZmHwA:10 a=8JOjVTPaRU0A:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=GZF_LLudG7hLcMtJSncA:9 a=98M3dsWYiIjRJUjxKsEA:7 a=de+ksHeJaPmK8cA12er7Ag==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.31.23.46 Received: from [98.31.23.46] ([98.31.23.46:35599] helo=mail.laus.org) by hrndva-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id B5/63-25610-AA5327F4; Tue, 27 Mar 2012 21:48:26 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.5/8.14.5) with ESMTP id q2RLmPgi010890 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Mar 2012 17:48:26 -0400 (EDT) (envelope-from lausts@acm.org) From: "Thomas Laus" Organization: ABB To: Eivind Evensen , "freebsd-stable@freebsd.org" Date: Tue, 27 Mar 2012 17:48:26 -0400 Message-ID: <4F71FD6A.29072.EDF7E@lausts.acm.org> Priority: normal In-reply-to: <20120327195758.GA78507@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org>, , <20120327195758.GA78507@klump.hjerdalen.lokalnett> X-mailer: Pegasus Mail for Windows (4.41) Cc: Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:48:33 -0000 > uname -a > FreeBSD elg.hjerdalen.lokalnett 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #42: Sat > Mar 3 20:05:21 CET 2012 > rumrunner@elg.hjerdalen.lokalnett:/usr/obj/usr/src/sys/RUM amd64 > > fdformat works fine here with: > dmesg |grep fdc > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > > Using the disk normally also works. > I also had floppy disk success with FreeBSD 8.3 RC1. I was able to format the floppy without error and DD a small file to the recently formatted floppy disk. I re-initialized the same computer that had been running OpenBSD 5.1 and FreeBSD 8.3 RC1 and then did a fresh install of FreeBSD 9.0 Release. FreeBSD 9.0-RELEASE: Mar 27 12:12:59 kernel: real memory = 536805376 (511 MB) Mar 27 12:12:59 kernel: avail memory = 515719168 (491 MB) Mar 27 12:12:59 kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 The fdformat shows the entire floppy disk that I previously used as having all blocks marked bad with a whole string of 'wrong cylinder (format mismatch) errors. > Additionally, I tried to mount a DD disk (previously formatted and with > files on), which also worked without hassle. I remember back on 6.X > or 7.X, I found no other way to make DD disks work after having read/written > HD disks than using fdformat -f720 on a disk first. Then again, that was on > different hardware, so it may have other reasons. > > I have an old machine I could install 9.0 on in order to test there, but > I'd have to install that machine from floppy and I can't seem to > find images for that any more. If it's of interest, I could probably > find another machine to install on, then move the harddrive to the other > machine, but I'd need to some for that. > It looks like we both have confirmed that the floppy disk operation works up to FreeBSD 8.3 RC1. I will need to file a PR for FreeBSD 9.0 in the bug system. Thanks for the help. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 22:03:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95943106566B for ; Tue, 27 Mar 2012 22:03:51 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 596CD8FC22 for ; Tue, 27 Mar 2012 22:03:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=d6JuZZtaHOwkIZPezLn1KaJZq2NPl650s6OGjKgWUbo=; b=rw2sTrzx6PVCQtcHL9Ou0g10138QnfOLsxyrliAdTvRkikSBvyyST0+oa0JyOjN+Kb6mqFolr7nZkqyLr3an7cADKI1tXPZvk/NDMABgIEFiZwTzofT0mx4OMJsQJM8j; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SCeUX-0000lE-HV for freebsd-stable@freebsd.org; Tue, 27 Mar 2012 17:03:50 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1332885823-34990-34989/5/46; Tue, 27 Mar 2012 22:03:43 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327195758.GA78507@klump.hjerdalen.lokalnett> <4F71FD6A.29072.EDF7E@lausts.acm.org> Date: Tue, 27 Mar 2012 17:03:43 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <4F71FD6A.29072.EDF7E@lausts.acm.org> User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:03:51 -0000 On Tue, 27 Mar 2012 16:48:26 -0500, Thomas Laus wrote: > > It looks like we both have confirmed that the floppy disk operation > works up > to FreeBSD 8.3 RC1. I will need to file a PR for FreeBSD 9.0 in the bug > system. > Thanks for the help. Could this be related to CAM system issues that shipped with FreeBSD 9.0 and were fixed in -STABLE? Like the CDROM issues? I'd probably test in -STABLE first. Unfortunately I don't have any floppy drives to test this with or I'd lend a hand. From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 01:25:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7A73106566B for ; Wed, 28 Mar 2012 01:25:22 +0000 (UTC) (envelope-from dddaley@yahoo.com) Received: from nm2-vm0.bullet.mail.bf1.yahoo.com (nm2-vm0.bullet.mail.bf1.yahoo.com [98.139.213.127]) by mx1.freebsd.org (Postfix) with SMTP id 3F19E8FC12 for ; Wed, 28 Mar 2012 01:25:22 +0000 (UTC) Received: from [98.139.215.141] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2012 01:25:21 -0000 Received: from [98.139.211.161] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 28 Mar 2012 01:25:21 -0000 Received: from [127.0.0.1] by smtp218.mail.bf1.yahoo.com with NNFMP; 28 Mar 2012 01:25:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332897921; bh=JXJk/EXCQu52fvkNWyxLLKj3eIbP2memMAuCa6Khyzs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=XrdK9nmvOByLXKBpWAbKpkzHBlJ3BWA22KHMNR5zGmSausX8FAumSlTKCKtKsg0eSTXFrMR3bYeuukgCcfDLr+VhpD8qkg8SWZj3XAufLyLb43TP71Wnj3rTPuwEPqT2iVc6tSQsgL0Vlrw+6mo7ZkNijF6WjN6FJ2zuOE/PykY= X-Yahoo-Newman-Id: 504549.63040.bm@smtp218.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WUKRcBoVM1kt0MhWKeeAwsMXQzY51iRAGLtTVbyAunceRJN _8QOnCBQ4grrRawuV5Axx7Hhl.PREHOkav6Ti7B5AricYOAa8PRytxja_BSR _9DhX4KjQ5e2cZtjysZLs3hTxpNgSMvWv1DeeEUMwehwzej.OOHazcnJWSvk h4VIlu7Mc8yGGv_JjHipeMcxwW9_qXs7GuRO_aqkjDI47x15wltAO6q5wxcL cMGeK971uAmxU188JjAv__MhjMTlo1LJreSIfTMgoT273yNjinntS9bBhx8B wU07LqYq3OubBR5g1ZTKbgGxTlFcBkzvsN1.kBh2AzDvGIK7ULwXHL1j4m7y mrhXeyTx4QRHsHXb93CACNmjBQoB9G7ka23S9TQ0Hp_zUvQYfVCC24ciMbCN 89O3IH8e8HfrG1gXwVhbHEveEMMG.o4pJwT3JAnzfO574XM0F X-Yahoo-SMTP: z6dQwTeswBDDR3zJap0nVIllEEY- Received: from shuttlebsd.localdomain (dddaley@107.30.53.54 with plain) by smtp218.mail.bf1.yahoo.com with SMTP; 27 Mar 2012 18:25:21 -0700 PDT Message-ID: <4F726844.5050807@yahoo.com> Date: Tue, 27 Mar 2012 20:24:20 -0500 From: Dan Daley User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120318 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327195758.GA78507@klump.hjerdalen.lokalnett> <4F71FD6A.29072.EDF7E@lausts.acm.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 01:25:22 -0000 Pretty sure I have a brand new, never used floppy drive laying around that I could send to you :) I don't think I have any discs though. On 03/27/2012 17:03, Mark Felder wrote: > On Tue, 27 Mar 2012 16:48:26 -0500, Thomas Laus wrote: > >> >> It looks like we both have confirmed that the floppy disk operation >> works up >> to FreeBSD 8.3 RC1. I will need to file a PR for FreeBSD 9.0 in the bug >> system. >> Thanks for the help. > > > Could this be related to CAM system issues that shipped with FreeBSD > 9.0 and were fixed in -STABLE? Like the CDROM issues? I'd probably > test in -STABLE first. Unfortunately I don't have any floppy drives to > test this with or I'd lend a hand. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 02:02:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61BA8106566B for ; Wed, 28 Mar 2012 02:02:54 +0000 (UTC) (envelope-from jdc@koitsu.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 45E658FC15 for ; Wed, 28 Mar 2012 02:02:54 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta14.emeryville.ca.mail.comcast.net with comcast id qpHJ1i0041ZMdJ4AEq1ojG; Wed, 28 Mar 2012 02:01:48 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id qq1n1i00e1t3BNj8cq1nDM; Wed, 28 Mar 2012 02:01:48 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7B46E102C1E; Tue, 27 Mar 2012 19:01:47 -0700 (PDT) Date: Tue, 27 Mar 2012 19:01:47 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20120328020147.GA18193@icarus.home.lan> References: <20120323110847.GA12111@icarus.home.lan> <20120324173230.000045f9@unknown> <20120325150333.GA55108@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120325150333.GA55108@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: Debugging periodic scripts X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 02:02:54 -0000 On Sun, Mar 25, 2012 at 08:03:33AM -0700, Jeremy Chadwick wrote: > Shall I file a PR for this or is there already one? :-) http://www.freebsd.org/cgi/query-pr.cgi?pr=166460 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 08:08:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 945BF1065670 for ; Wed, 28 Mar 2012 08:08:58 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail2.icritical.com (mail2.icritical.com [212.57.248.50]) by mx1.freebsd.org (Postfix) with SMTP id F1CB38FC15 for ; Wed, 28 Mar 2012 08:08:57 +0000 (UTC) Received: (qmail 28737 invoked from network); 28 Mar 2012 08:02:17 -0000 Received: from localhost (127.0.0.1) by mail2.icritical.com with SMTP; 28 Mar 2012 08:02:17 -0000 Received: (qmail 28720 invoked by uid 599); 28 Mar 2012 08:02:16 -0000 Received: from unknown (HELO hydrogen.icritical.com) (212.57.254.146) by mail2.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 28 Mar 2012 09:02:16 +0100 Message-ID: <4F72C588.2000204@icritical.com> Date: Wed, 28 Mar 2012 09:02:16 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120204 Thunderbird/10.0 MIME-Version: 1.0 To: Fred Liu References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2012 08:02:16.0438 (UTC) FILETIME=[1761C960:01CD0CB9] X-Virus-Scanned: by iCritical at mail2.icritical.com Cc: "freebsd-stable@freebsd.org" Subject: Re: SAS Drive identification LEDs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:08:58 -0000 On 03/28/12 06:11, Fred Liu wrote: > Does ARC-1320 card need specific backplane to work with to identify > HDD's position? Shouldn't imagine so... I'm using a set of 4x four-bay Chenbro 80H10321513C0 jobbies in a 4U box for a total of 16 disks. My original post showed me lighting up an identification LED by poking values at the backplane via the ses device, but the Areca utility seems to do it by poking the drives themselves - which is a much better solution and *should* be backplane-agnostic. -- Sorry for the below disclaimer The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 08:45:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABC0E1065674 for ; Wed, 28 Mar 2012 08:45:34 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC5C8FC1A for ; Wed, 28 Mar 2012 08:45:33 +0000 (UTC) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2S8eHrk014564 for ; Wed, 28 Mar 2012 19:40:17 +1100 Received: from maxwell.mencon.com.au (c122-107-224-152.mckinn3.vic.optusnet.com.au [122.107.224.152]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2S8e9SL000456 for ; Wed, 28 Mar 2012 19:40:10 +1100 Received: from starker.mencon.com.au (starker.mencon.com.au [203.2.73.75]) by maxwell.mencon.com.au (Postfix) with ESMTP id 7F97760A2 for ; Wed, 28 Mar 2012 19:40:09 +1100 (EST) Message-ID: <4F72CE69.3010606@menhennitt.com.au> Date: Wed, 28 Mar 2012 19:40:09 +1100 From: Graham Menhennitt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120320 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327195758.GA78507@klump.hjerdalen.lokalnett> <4F71FD6A.29072.EDF7E@lausts.acm.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:45:34 -0000 On 28/03/2012 09:03, Mark Felder wrote: > On Tue, 27 Mar 2012 16:48:26 -0500, Thomas Laus wrote: > > Could this be related to CAM system issues that shipped with FreeBSD > 9.0 and were fixed in -STABLE? Like the CDROM issues? I'd probably > test in -STABLE first. Unfortunately I don't have any floppy drives to > test this with or I'd lend a hand. I can confirm that the floppy does work on my FreeBSD-9-Stable machine (csup'd about a week ago). Graham From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 12:53:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 227A51065670 for ; Wed, 28 Mar 2012 12:53:58 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 643368FC08 for ; Wed, 28 Mar 2012 12:53:56 +0000 (UTC) Received: (qmail 15256 invoked from network); 28 Mar 2012 12:53:54 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 28 Mar 2012 12:53:54 -0000 Received: (qmail 15242 invoked by uid 599); 28 Mar 2012 12:53:54 -0000 Received: from unknown (HELO hydrogen.icritical.com) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 28 Mar 2012 13:53:54 +0100 Message-ID: <4F7309E2.4000502@icritical.com> Date: Wed, 28 Mar 2012 13:53:54 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120328 Thunderbird/10.0.3 MIME-Version: 1.0 To: Fred Liu References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> <4F72C588.2000204@icritical.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Mar 2012 12:53:54.0075 (UTC) FILETIME=[D4C94EB0:01CD0CE1] X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: "freebsd-stable@freebsd.org" Subject: Re: SAS Drive identification LEDs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:53:58 -0000 On 03/28/12 12:40, Fred Liu wrote: >> Shouldn't imagine so... I'm using a set of 4x four-bay Chenbro >> 80H10321513C0 jobbies in a 4U box for a total of 16 disks. >> >> My original post showed me lighting up an identification LED by poking >> values at the backplane via the ses device, but the Areca utility seems >> to >> do it by poking the drives themselves - which is a much better solution >> and >> *should* be backplane-agnostic. > > Sounds very good! But what if the drive is thoroughly damaged? How would you identify such a drive on any other system? -- Sorry for the disclaimer... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 18:40:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 704B8106564A for ; Wed, 28 Mar 2012 18:40:20 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 260ED8FC18 for ; Wed, 28 Mar 2012 18:40:19 +0000 (UTC) Received: by ghrr20 with SMTP id r20so1207202ghr.13 for ; Wed, 28 Mar 2012 11:40:19 -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=ExS+3eIYgZS0bh+FJIMftbbQLWuyadl7tT2en8neYTQ=; b=qbPY/fXhFg80b6nbwN+JVeCwifxT/b9d9MxXxCfoB6U+x890otYvd+1lajJkfNOCaR UOJ1pYvF+1nYIoCebwNDhAIMYnPmX71OkUf1GFpGd6kA6LOwQ88caXrZ5YEaeO4f71ey qHZHmA3JmEjy7/6dosgEBwyJjOhYv3qAnPiMUEdd6w6gLIjXgs3dYpI9rLeXNNe/JsvC 1O3vu2JIK8oF2cjUC5u5taeZvszp6Q0Z1ZJEcJK7RGSowEIqx5RBgyx1KTGUZYJVugm1 QMIXqrc1Dl6m88pK4XKqfJD0b5dhikEWk+Ex5tqXO5an8V3G4o8Ozlgm8cLsuXc/B7Xo 7ZPQ== Received: by 10.50.155.226 with SMTP id vz2mr144113igb.39.1332960019245; Wed, 28 Mar 2012 11:40:19 -0700 (PDT) Received: from argus.electron-tube.net (173-28-218-168.client.mchsi.com. [173.28.218.168]) by mx.google.com with ESMTPS id gr1sm129245igc.1.2012.03.28.11.40.16 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 11:40:18 -0700 (PDT) Message-ID: <4F735B16.1060907@gmail.com> Date: Wed, 28 Mar 2012 13:40:22 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: Shane Ambler References: <4F7019FC.4090907@ShaneWare.Biz> In-Reply-To: <4F7019FC.4090907@ShaneWare.Biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, prabhpal@digital-infotech.net, "C. P. Ghost" Subject: Re: Too many open files X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:40:20 -0000 1:23:14pm argus(50): lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort lsof: Command not found. 1:35:12pm argus(51): man lsof | cat No manual entry for lsof 1:35:38pm argus(52): find /usr/src -iname \*lsof\* 1:36:42pm argus(53): find /usr/src -type f -iname \*lsof\* 1:36:50pm argus(54): huh??? 9-stable here. is this a -port? Aha! 1:39:07pm argus(1): cd /usr/ports 1:39:11pm argus(2): make search name=lsof Port: lsof-4.86A,6 Path: /usr/ports/sysutils/lsof Info: Lists information about open files (similar to fstat(1)) Maint: ler@lerctr.org B-deps: R-deps: WWW: http://people.freebsd.org/~abe/ Port: p5-Unix-Lsof-0.0.5_1 Path: /usr/ports/sysutils/p5-Unix-Lsof Info: Unix::Lsof -- a wrapper to the Unix lsof utility Maint: gjvc@gjvc.com B-deps: p5-IPC-Run3-0.044 perl-5.12.4_3 R-deps: p5-IPC-Run3-0.044 perl-5.12.4_3 WWW: http://search.cpan.org/dist/Unix-Lsof/ Next time, please state that it is a port and not a builtin. Thanks jim Shane Ambler wrote: > On 26/03/2012 02:19, C. P. Ghost wrote: >> On Sun, Mar 25, 2012 at 6:46 PM, Prabhpal S. Mavi >> wrote: >>> Greetings Friends, >>> >>> have anyone has come across this warning / error? This occurs when i >>> ssh >>> to my FreeBSD 9.0 System. any help would be greatly appreciated. >>> >>> Warning: >>> /usr/share/games/fortune/freebsd-tips.dat: Too many open files in >>> system >>> [mavi@titan ~]$ su >>> su: pam_start: system error >>> >>> Thanks / Regards >>> Prabhpal >> >> What does this command say on your system? >> >> % sysctl kern.maxfiles kern.maxfilesperproc kern.openfiles >> >> You may have exceeded the maximum number of open files >> in the system. Maybe some ill-conceived program that doesn't >> close non-needed connections, files, etc is at fault? It's easy >> to open more and more files, and to gradually fill the open >> files descriptor table in the kernel this way. >> >> -cpghost. >> > > From knowing that you have too many files open you can increase the > maxfile numbers - but if you want to know what uses them try this - > > lsof -n | awk '{print $2 "\t" $1}' | sort | uniq -c | sort > > lsof outputs open file info, awk then gives us the PID and proc name > which gets sorted and uniq gives a count of each which we sort to have > the largest file count at the bottom of the list. What you end up with > is a list of two numbers and a name - count of files open followed by > the PID and proc name that has them open. > > The catch is that it also includes network connections (I know how to > list only network but not sure how to exclude them) > > ps ax | grep PID > > will show you the full program name if it has been shortened. > > lsof -p PID > > will show all the open files for PID > > Not sure if this is the best way but it works for me. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 18:48:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15280106566B for ; Wed, 28 Mar 2012 18:48:09 +0000 (UTC) (envelope-from kc5vdj.freebsd@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 7AC128FC0C for ; Wed, 28 Mar 2012 18:48:08 +0000 (UTC) Received: by iahk25 with SMTP id k25so2381108iah.13 for ; Wed, 28 Mar 2012 11:48:07 -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:subject :content-type:content-transfer-encoding; bh=jaEff0LIAPVUlGiJingU/dNJfwFlVh+/byg0JTKJVgU=; b=haaEHt9I/a49Hm8obTBlNwdacxgjomaBNl3LMVcfzXSY0twb9Mxr56fCyIyz3KC2cF f1u+/pmXK8no79yQRu1EawRis4MkkvcaIJDoV7skcFNXRTvUti0PU9qNV2uDBEqbOcSr 8GdS8ckCF85lFYAOonaS3f0/hrdPEET/o383mJx2Z0uHh5pZaZQ0FVYroqkmTk0dvOTs T2HgwqAmAW+Xvh8aPZFWwPcFqA3v9jPPdzy7eo2FaVZbTEC2AMiLJDW7GUz7SAVt1i4Z RH0h4YxBkMuADMdD6f4S5MxElSAF6+NVk9U67ENAdG99hBorcajRRxI7TQwk/T/0RlBS Xqiw== Received: by 10.50.202.69 with SMTP id kg5mr225792igc.7.1332960487743; Wed, 28 Mar 2012 11:48:07 -0700 (PDT) Received: from argus.electron-tube.net (173-28-218-168.client.mchsi.com. [173.28.218.168]) by mx.google.com with ESMTPS id k8sm3749015igz.4.2012.03.28.11.48.06 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 11:48:07 -0700 (PDT) Message-ID: <4F735CEC.5060101@gmail.com> Date: Wed, 28 Mar 2012 13:48:12 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: ESCape codes displayed instead of processed in pager X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:48:09 -0000 Ever since I have upgraded to 9-stable, I have noticed that the manpages seem to be munged up with displayed instead of processed ESCape codes. an example: 1:41:05pm argus(8): man man MAN(1) FreeBSD General Commands Manual MAN(1) ESC[1mNAMEESC[0m ESC[1mman ESC[22m-- display online manual documentation pages ESC[1mSYNOPSISESC[0m ESC[1mman ESC[22m[ESC[1m-adhoESC[22m] [ESC[1m-t ESC[22m| ESC[1m-wESC[22m] [ESC[1m-M ESC[4mESC[22mmanpathESC[24m] [ESC[1m-P ESC[4mESC[22mpagerESC[24m] [ESC[1m-S ESC[4mESC[22mmansectESC[24m] [ESC[1m-m ESC[4mESC[22marchESC[24m[:ESC[4mmachineESC[24m]] [ESC[1m-p ESC[22m[ESC[4meprtvESC[24m]] [ESC[4mmansectESC[24m] ESC[4mpageESC[24m ESC[4m...ESC[0m ESC[1mman -f ESC[4mESC[22mkeywordESC[24m ESC[4m...ESC[0m ESC[1mman -k ESC[4mESC[22mkeywordESC[24m ESC[4m...ESC[0m ESC[1mDESCRIPTIONESC[0m The ESC[1mman ESC[22mutility finds and displays online manual documentation pages. If ESC[4mmansectESC[24m is provided, ESC[1mman ESC[22mrestricts the search to the specific section of the manual. I have actually ruled out nroff -man, and have determined that this has to do with /usr/bin/more and /usr/bin/less. example: 1:44:45pm argus(9): man man | cat MAN(1) FreeBSD General Commands Manual MAN(1) NAME man -- display online manual documentation pages SYNOPSIS man [-adho] [-t | -w] [-M manpath] [-P pager] [-S mansect] [-m arch[:machine]] [-p [eprtv]] [mansect] page ... man -f keyword ... man -k keyword ... DESCRIPTION The man utility finds and displays online manual documentation pages. If mansect is provided, man restricts the search to the specific section of the manual. So far as I can tell, it is in both more and less. if it relies on termcap, then the issue is bigger, because it does the same thing in syscons as it does an xterm. My bottom line question is what changed, and how do I change my end to make things work as expected again? Honestly, this is a real pain in the ass when I need a manual page. jim From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 19:57:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3BB106566C for ; Wed, 28 Mar 2012 19:57:38 +0000 (UTC) (envelope-from lausts@acm.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id 9615F8FC1D for ; Wed, 28 Mar 2012 19:57:38 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=NYRkJh/4 c=1 sm=0 a=de+ksHeJaPmK8cA12er7Ag==:17 a=VyBCHhcZmHwA:10 a=8JOjVTPaRU0A:10 a=kWQ6D_09QQAA:10 a=kHc8Q_KJ-KsA:10 a=_sO7A42h7UnPPKfoNmkA:9 a=de+ksHeJaPmK8cA12er7Ag==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.31.23.46 Received: from [98.31.23.46] ([98.31.23.46:15005] helo=mail.laus.org) by hrndva-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 02/EC-25610-13D637F4; Wed, 28 Mar 2012 19:57:37 +0000 Received: from [192.168.1.100] (laust2 [192.168.1.100]) by mail.laus.org (8.14.5/8.14.5) with ESMTP id q2SJvbmJ013937 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Mar 2012 15:57:37 -0400 (EDT) (envelope-from lausts@acm.org) From: "Thomas Laus" Organization: ABB To: Eivind Evensen , "freebsd-stable@freebsd.org" Date: Wed, 28 Mar 2012 15:57:37 -0400 Message-ID: <4F7334F1.5214.1516AE@lausts.acm.org> Priority: normal In-reply-to: <20120327195758.GA78507@klump.hjerdalen.lokalnett> References: <4F64608B.27301.3724F1@lausts.acm.org>, , <20120327195758.GA78507@klump.hjerdalen.lokalnett> X-mailer: Pegasus Mail for Windows (4.41) Cc: Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lausts@acm.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:57:38 -0000 > Hi. > > I'm a bit short on free machines, so the closest I can get right now > is my everyday machine running from sources cvsupped from > RELENG_8 3.rd of March: > I 'csuped' to FreeBSD 9.0-STABLE today and still had the same problem. This computer has normal floppy disk operation when using FreeBSD 8.3-RC1 and doesn't have any fd functionality with FreeBSD 9.0-STABLE. I entered a Problem Report in the system today. Thanks for all of the help, we'll let the development team take if from here. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 20:17:57 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7063106566B for ; Wed, 28 Mar 2012 20:17:57 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id BEA768FC14 for ; Wed, 28 Mar 2012 20:17:57 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id E5F051CC73; Wed, 28 Mar 2012 13:41:18 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.30.1.12) (SquirrelMail authenticated user matheus) by 109.169.62.232 with HTTP; Wed, 28 Mar 2012 13:41:18 -0300 Message-ID: Date: Wed, 28 Mar 2012 13:41:18 -0300 From: "Nenhum_de_Nos" To: stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: problem: bsdlabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:17:58 -0000 hail, I partitioned the disk this way: fdisk da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=12161 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=12161 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 166 (0xa6),(OpenBSD) start 126, size 20964699 (10236 Meg), flag 0 beg: cyl 0/ head 2/ sector 1; end: cyl 280/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 20971629, size 8379126 (4091 Meg), flag 0 beg: cyl 281/ head 108/ sector 1; end: cyl 802/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 29350755, size 41929650 (20473 Meg), flag 0 beg: cyl 803/ head 0/ sector 1; end: cyl 340/ head 254/ sector 63 The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 71280405, size 124086060 (60588 Meg), flag 80 (active) beg: cyl 341/ head 0/ sector 1; end: cyl 896/ head 254/ sector 63 but when was time to label it, I did it wrong: bsdlabel -w da0 should have aimed slice 2 now, I just get da0 on /dev and sysinstall only sees da0 also. but fdisk sees it all (as showed above) how can I erase all label info from da0 (not da0s1 or da0s2). I tried to rewrite fdisk and all mbr info, but label info is still there. I'd like not to have to reinstall OpenBSD, if possible. thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 20:29:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A149A106566B for ; Wed, 28 Mar 2012 20:29:03 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 65B0F8FC16 for ; Wed, 28 Mar 2012 20:29:03 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 911101CC71; Wed, 28 Mar 2012 17:28:54 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.30.1.12) (SquirrelMail authenticated user matheus) by 109.169.62.232 with HTTP; Wed, 28 Mar 2012 17:28:54 -0300 Message-ID: <81eca0ddc59eb29ed21bef18724e5b1c.squirrel@109.169.62.232> Date: Wed, 28 Mar 2012 17:28:54 -0300 From: "Nenhum_de_Nos" To: stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: 9.0 Install and serial terminal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:29:03 -0000 hail, I have some problems trying to install 9.0-BETA3 using a serial terminal. I edited to have it boot using serial console, that was fine, but I can't get it to create the slices the size I want. I say 1g to create a swap, and it puts there -56GB as size. Next I try to set 4GB to /var, using 4g or 4GB, and it sets 1.5GB. FreeBSD Installer ────────────────────────────────────────────────────────────────────────────── ┌──────────────────Partition Editor────────────────────┐ │ Create partitions for FreeBSD. No changes will be │ │ made until you select Finish. │ │┌────────────────────────────────────────────────^(-)┐│ ││ ada0s4 59 GB BSD ││ ││ ada0s4a 2.0 GB freebsd-ufs / ││ ││ ada0s4b -56 GB freebsd-swap none ││ ││ ada0s4d 1.5 GB freebsd-ufs /var ││ ││da0 3.8 GB GPT ││ ││ da0p1 64 kB freebsd-boot ││ ││ da0p2 535 MB freebsd-ufs ││ ││ ││ │└────────────────────────────────────────────────────┘│ ├──────────────────────────────────────────────────────┤ │ < Auto > │ └──────────────────────────────────────────────────────┘ Add a new partition to add to this, I couldn't find where to say that I'd like that or this partition to be formatted, and how to create labels to it. is this supposed to happen this way ? Am I doing something wrong ? thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 20:37:13 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C2D5106566C for ; Wed, 28 Mar 2012 20:37:13 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 35C518FC08 for ; Wed, 28 Mar 2012 20:37:13 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 92D231CC73; Wed, 28 Mar 2012 17:37:04 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.30.1.12) (SquirrelMail authenticated user matheus) by 109.169.62.232 with HTTP; Wed, 28 Mar 2012 17:37:04 -0300 Message-ID: <07b017dfee156797eaa3725113bac5f7.squirrel@109.169.62.232> In-Reply-To: <81eca0ddc59eb29ed21bef18724e5b1c.squirrel@109.169.62.232> References: <81eca0ddc59eb29ed21bef18724e5b1c.squirrel@109.169.62.232> Date: Wed, 28 Mar 2012 17:37:04 -0300 From: "Nenhum_de_Nos" To: stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Subject: Re: 9.0 Install and serial terminal X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:37:13 -0000 On Wed, March 28, 2012 17:28, Nenhum_de_Nos wrote: > hail, > > I have some problems trying to install 9.0-BETA3 using a serial terminal. I edited to have it boot > using serial console, that was fine, but I can't get it to create the slices the size I want. I > say 1g to create a swap, and it puts there -56GB as size. Next I try to set 4GB to /var, using 4g > or 4GB, and it sets 1.5GB. > > FreeBSD Installer > ────────────────────────────────────────────────────────────────────────────── > > > ┌──────────────────Partition > Editor────────────────────┐ > │ Create partitions for FreeBSD. No changes will be │ > │ made until you select Finish. │ > │┌────────────────────────────────────────────────^(-)┐│ > ││ ada0s4 59 GB BSD ││ > ││ ada0s4a 2.0 GB freebsd-ufs / ││ > ││ ada0s4b -56 GB freebsd-swap none ││ > ││ ada0s4d 1.5 GB freebsd-ufs /var ││ > ││da0 3.8 GB GPT ││ > ││ da0p1 64 kB freebsd-boot ││ > ││ da0p2 535 MB freebsd-ufs ││ > ││ ││ > │└────────────────────────────────────────────────────┘│ > ├──────────────────────────────────────────────────────┤ > │ < Auto > │ > └──────────────────────────────────────────────────────┘ > > > > Add a new partition > > to add to this, I couldn't find where to say that I'd like that or this partition to be formatted, > and how to create labels to it. > > is this supposed to happen this way ? Am I doing something wrong ? > > thanks, > > matheus as an update, when I deleted the slice and tried again, it worked fine. The partition table was created using sysinstall from the same installation. matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Wed Mar 28 23:56:28 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1286F106566B; Wed, 28 Mar 2012 23:56:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B11D68FC12; Wed, 28 Mar 2012 23:56:27 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q2SNuRKC000763; Wed, 28 Mar 2012 23:56:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q2SNuQMv000745; Wed, 28 Mar 2012 23:56:26 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 28 Mar 2012 23:56:26 GMT Message-Id: <201203282356.q2SNuQMv000745@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 23:56:28 -0000 TB --- 2012-03-28 21:43:24 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-03-28 21:43:24 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2012-03-28 21:43:24 - cleaning the object tree TB --- 2012-03-28 21:43:24 - cvsupping the source tree TB --- 2012-03-28 21:43:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/ia64/ia64/supfile TB --- 2012-03-28 21:44:29 - building world TB --- 2012-03-28 21:44:29 - CROSS_BUILD_TESTING=YES TB --- 2012-03-28 21:44:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-28 21:44:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-28 21:44:29 - SRCCONF=/dev/null TB --- 2012-03-28 21:44:29 - TARGET=ia64 TB --- 2012-03-28 21:44:29 - TARGET_ARCH=ia64 TB --- 2012-03-28 21:44:29 - TZ=UTC TB --- 2012-03-28 21:44:29 - __MAKE_CONF=/dev/null TB --- 2012-03-28 21:44:29 - cd /src TB --- 2012-03-28 21:44:29 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 21:44:30 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Mar 28 23:32:24 UTC 2012 TB --- 2012-03-28 23:32:24 - generating LINT kernel config TB --- 2012-03-28 23:32:24 - cd /src/sys/ia64/conf TB --- 2012-03-28 23:32:24 - /usr/bin/make -B LINT TB --- 2012-03-28 23:32:24 - cd /src/sys/ia64/conf TB --- 2012-03-28 23:32:24 - /usr/sbin/config -m LINT TB --- 2012-03-28 23:32:24 - building LINT kernel TB --- 2012-03-28 23:32:24 - CROSS_BUILD_TESTING=YES TB --- 2012-03-28 23:32:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-28 23:32:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-28 23:32:24 - SRCCONF=/dev/null TB --- 2012-03-28 23:32:24 - TARGET=ia64 TB --- 2012-03-28 23:32:24 - TARGET_ARCH=ia64 TB --- 2012-03-28 23:32:24 - TZ=UTC TB --- 2012-03-28 23:32:24 - __MAKE_CONF=/dev/null TB --- 2012-03-28 23:32:24 - cd /src TB --- 2012-03-28 23:32:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 28 23:32:24 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_inode.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_snapshot.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_softdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_subr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_tables.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/ufs/ffs/ffs_vfsops.c /src/sys/ufs/ffs/ffs_vfsops.c: In function 'ffs_sync': /src/sys/ufs/ffs/ffs_vfsops.c:1508: error: too many arguments to function 'ffs_syncvnode' *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-28 23:56:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-28 23:56:26 - ERROR: failed to build LINT kernel TB --- 2012-03-28 23:56:26 - 5341.05 user 799.21 system 7982.05 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 03:41:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4B3DB1065673 for ; Thu, 29 Mar 2012 03:41:34 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC148FC1B for ; Thu, 29 Mar 2012 03:41:33 +0000 (UTC) Received: from nskntotgx02p.mx.bigpond.com ([58.172.112.105]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20120329034125.OGTI10464.nskntmtas03p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com>; Thu, 29 Mar 2012 03:41:25 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.105]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20120329034125.ECLF26699.nskntotgx02p.mx.bigpond.com@hermes.heuristicsystems.com.au>; Thu, 29 Mar 2012 03:41:25 +0000 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q2T3fEnP092449 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 14:41:15 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Nenhum_de_Nos'" References: Date: Thu, 29 Mar 2012 14:41:14 +1100 Message-ID: <4E34FD0A83F1447A9416E7AB81F7E8D8@white> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0NH/Wla21oEmcPSd6DK9IgCzezjgAO6nOw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-SIH-MSG-ID: rRE2EtL6TAD0zmQv0WC2O1J3yArnq3Mt8ZoaRdJjqwQZTUTduMHbU677NrM8kMz21jdcNhmPOmAqYan0X4/QsOM= Cc: stable@freebsd.org Subject: RE: problem: bsdlabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 03:41:34 -0000 Hi Matheus, You have two options. Option 1. Resync the in-memory and on-disk view of the world Identify the device from # usbconfig list Then power it off and then power on. If this doesn't work then you'll need to dd the device. For example: # usbconfig list ugen4.2:
at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE # usbconfig -d 4.2 power_off # usbconfig -d 4.2 power_on Option 2. Clear the boot blocks # dd if=/dev/zero of=/dev/da0 bs=1M count=1 If this doesn't help then zero the whole device, omit the bs and count arguments. I'd also suggest that you assign 0xa5 to the device, by # fdisk -p da0 > /tmp/fdisk.cf Use a text editor to change the 0xa6 to 0xa5; then write it back to fdisk # fdisk -f /tmp/fdisk.cf /dev/da0 Of course, the excessive option is to reboot... Regards, Dewayne. PS I think this question would be better placed in the FreeBSD Questions mailing list :) From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 04:27:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF260106564A for ; Thu, 29 Mar 2012 04:27:47 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mail.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9088FC0A for ; Thu, 29 Mar 2012 04:27:47 +0000 (UTC) Received: from kas30pipe.localhost (localhost.kirov.so-ups.ru [127.0.0.1]) by mail.kirov.so-ups.ru (Postfix) with SMTP id 9919EB8029; Thu, 29 Mar 2012 08:21:39 +0400 (MSK) Received: from kirov.so-ups.ru (unknown [172.21.81.1]) by mail.kirov.so-ups.ru (Postfix) with ESMTP id 7B98AB8008; Thu, 29 Mar 2012 08:21:39 +0400 (MSK) Received: by ns.kirov.so-ups.ru (Postfix, from userid 1010) id 7807FBA006; Thu, 29 Mar 2012 08:21:39 +0400 (MSK) Received: from [127.0.0.1] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-ups.ru (Postfix) with ESMTP id 3B713B9FF8; Thu, 29 Mar 2012 08:21:39 +0400 (MSK) Message-ID: <4F73E34D.9060302@FreeBSD.org> Date: Thu, 29 Mar 2012 08:21:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Nenhum_de_Nos References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F741C0FA30B1810FC2D6C2D" X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-SpamTest-Info: Not protected Cc: stable@freebsd.org Subject: Re: problem: bsdlabel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 04:27:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F741C0FA30B1810FC2D6C2D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 28.03.2012 20:41, Nenhum_de_Nos wrote: > hail, >=20 > I partitioned the disk this way: >=20 > fdisk da0 > ******* Working on device /dev/da0 ******* > parameters extracted from in-core disklabel are: > cylinders=3D12161 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=3D12161 heads=3D255 sectors/track=3D63 (16065 blks/cyl) >=20 > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 166 (0xa6),(OpenBSD) > start 126, size 20964699 (10236 Meg), flag 0 > beg: cyl 0/ head 2/ sector 1; > end: cyl 280/ head 254/ sector 63 > The data for partition 2 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 20971629, size 8379126 (4091 Meg), flag 0 > beg: cyl 281/ head 108/ sector 1; > end: cyl 802/ head 254/ sector 63 > The data for partition 3 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 29350755, size 41929650 (20473 Meg), flag 0 > beg: cyl 803/ head 0/ sector 1; > end: cyl 340/ head 254/ sector 63 > The data for partition 4 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 71280405, size 124086060 (60588 Meg), flag 80 (active) > beg: cyl 341/ head 0/ sector 1; > end: cyl 896/ head 254/ sector 63 >=20 >=20 > but when was time to label it, I did it wrong: >=20 > bsdlabel -w da0 >=20 > should have aimed slice 2 >=20 > now, I just get da0 on /dev and sysinstall only sees da0 also. but fdis= k sees it all (as showed > above) >=20 > how can I erase all label info from da0 (not da0s1 or da0s2). > I tried to rewrite fdisk and all mbr info, but label info is still ther= e. > I'd like not to have to reinstall OpenBSD, if possible. First of in the future you should use gpart(8) utility to manage partitio= ns and slices. bsdlabel keeps metadata in the second sector. Therefore you should rewrit= e it to destroy label. But to be sure please show output of this command: # gpart show --=20 WBR, Andrey V. Elsukov --------------enig8F741C0FA30B1810FC2D6C2D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJPc+NTAAoJEAHF6gQQyKF68dIH/it0Vf1yRv3jXTPms8Ls94M/ Sa5NGX2SfZpfIEIODwPBequTVnUUw8AEkl8tCSG3aH+zTtoYr3Fkmm1JWZKMe0zZ hzSl8LxsqcZH/Nry96EwtdBFsmE7l7L6h/31CHhf2zOhEDLKu53jyCsAZJwH9PqK /lGz3dAJn+GJFgckRfqXCZy806WceGeIwcFTmJNN7sn/klT+IsE9HbXv0j4eaa8Z f6R0g5CBFwWQpPHnEVIRo00qX1c08kubX73iigCWDdetzQn3h4qtkMYngCmpQiqA HoVjFTwiX2W+DSYy3NYI7u6/jfIUHFm3IlKTUG5h9Xg77T0jCVa9o92CvwFdbYQ= =C/iX -----END PGP SIGNATURE----- --------------enig8F741C0FA30B1810FC2D6C2D-- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 07:55:57 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503581065674; Thu, 29 Mar 2012 07:55:57 +0000 (UTC) (envelope-from c.kworr@gmail.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 A80418FC1A; Thu, 29 Mar 2012 07:55:56 +0000 (UTC) Received: by eaaf13 with SMTP id f13so909255eaa.13 for ; Thu, 29 Mar 2012 00:55:55 -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=fzvAGkzypgfbWHCR1/AxaSxH2xsQPjbNcqr/YtFZHH0=; b=OqSU3H27BaJ35K3pPAOEz+5B75IdFXlmynPAiXJm6scmCX4fNaaL1Hmvj4KtNydLH9 Q1xNXfO6fuzqTIP2N/nlr96bkP5kBp8dHqjuAfIkgrAfahgKedMK4xXKdW2CG1WQfhzi QxqY+bLVFkKkUuHpQeKEyFrgFUTKo/xBt6EggBQJQdSZ9X7LomKssuggVrTbEFVSif8J OYaZLC37Tz8WBh+hIJVXN1FqJuvPHqyKuoffzmGnFqAvmew1stGZPk0Z6JQpPXL0nOYK PkygQHEPNjlXyiorIj1TEZySpP1nl4rEyz9DQlPH7XYqdLHg8YFR+jHmaQI8a9VtO8Ws NIeQ== Received: by 10.180.102.100 with SMTP id fn4mr3149719wib.1.1333007755493; Thu, 29 Mar 2012 00:55:55 -0700 (PDT) Received: from green.tandem.local (39-112-132-95.pool.ukrtel.net. [95.132.112.39]) by mx.google.com with ESMTPS id ff9sm64828212wib.2.2012.03.29.00.55.53 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 00:55:54 -0700 (PDT) Message-ID: <4F741588.9000202@gmail.com> Date: Thu, 29 Mar 2012 10:55:52 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120315 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: Andriy Gapon References: <4F71E14A.8010605@gmail.com> <4F71E482.7060509@FreeBSD.org> In-Reply-To: <4F71E482.7060509@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: trap 12 on 9.0 when memcache gets some load [resolved] ZERO_COPY trap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 07:55:57 -0000 Andriy Gapon wrote: > on 27/03/2012 18:48 Volodymyr Kostyrko said the following: >> Hi all. >> >> I'm just puzzled with this. At first I though this happens because of some memory >> problems. But now project was moved to another server with some other brands for >> motherboard/memory and different cpu's. And still once in an hour this happens again: >> >> == screenshot >> current_process = 1935 (memcached) >> trap number = 12 >> panic: page fault >> cpuid = 2 >> KDB: stack backtrace: >> #0 0xffffffff8038ab38 at kdb_backtrace+0x58 >> #1 0xffffffff80358f80 at panic+0x190 >> #2 0xffffffff80567b15 at trap_fatal+0x395 >> #3 0xffffffff80567ce9 at trap_pfault+0x1c9 >> #4 0xffffffff80567536 at trap+0x3a6 >> #5 0xffffffff80552603 at calltrap+0x8 >> #6 0xffffffff803b2c90 at socow_setup+0xd0 > > I think that zero-copy sockets are not regarded as a reliable feature. > Not an expert, just my two cents. Disabling zero_zopy seems to work as server still runs after 12 hours. Before that one hour was enough to trigger error. kern.ipc.zero_copy.receive: 0 kern.ipc.zero_copy.send: 0 -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 08:13:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B45B4106564A; Thu, 29 Mar 2012 08:13:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 515598FC12; Thu, 29 Mar 2012 08:13:51 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 76ADA4AC32; Thu, 29 Mar 2012 12:13:49 +0400 (MSK) Date: Thu, 29 Mar 2012 12:13:44 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1884361371.20120329121344@serebryakov.spb.ru> To: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: Subject: What is actual status of SUJ in 9-STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:13:51 -0000 Hello, Freebsd-fs. My server crashed today morning due to PSU failure, and now it is checking (in foreground!) 8Tb UFS2+SU volume for 6200 seconds, and it is only "Phase 1b" (!!!). I don't want even think about background check of this FS. Is SUJ stable enough to migrate to it? It was marked as stable some time ago, and was included into 9-RELEASE, but later I seen some messages on fs@ list, that it still has some problems, and even some references to McKusick's message about this instability (but I've failed to find message itself). BTW, this check reveals many softupdate inconsistences (mostly DUPs), and= most of them are in files, which was not written for sure in time of crash (old archives, which could be only read!). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 12:28:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844BE1065673; Thu, 29 Mar 2012 12:28:23 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id CE4E78FC0C; Thu, 29 Mar 2012 12:28:22 +0000 (UTC) Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20120329083100.BMIW12529.nskntmtas05p.mx.bigpond.com@nskntcmgw05p>; Thu, 29 Mar 2012 08:31:00 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.105]) by nskntcmgw05p with BigPond Outbound id rLX01i0032GVmci01LX0NR; Thu, 29 Mar 2012 08:31:00 +0000 X-Authority-Analysis: v=2.0 cv=OYIa/2vY c=1 sm=1 a=0GO/22z+lHYfckWJ4naYnw==:17 a=KL3m0oixo70A:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=muJxhalr8UvCRlZyOGQA:9 a=CjuIK1q_8ugA:10 a=YQIiI1lPELoA:10 a=0GO/22z+lHYfckWJ4naYnw==:117 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q2T8TwTs099284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Mar 2012 19:30:01 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: References: <1884361371.20120329121344@serebryakov.spb.ru> Date: Thu, 29 Mar 2012 19:29:58 +1100 Message-ID: <3F4A33A2FC134615A5DC7A7E455AA177@white> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1884361371.20120329121344@serebryakov.spb.ru> Thread-Index: Ac0Ng/2WimJ23AejR92omKEfS4aRSwAAcwYg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org Subject: RE: What is actual status of SUJ in 9-STABLE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:28:23 -0000 Use of SU+J & use with snapshots is being addressed. Latest update (to 9.0 Stable) was today, please refer to http://lists.freebsd.org/pipermail/svn-src-stable-9/2012-March/001406.html If you mean to use it in production (ie with snapshots), then it is not advisable. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 13:49:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC9B106566B; Thu, 29 Mar 2012 13:49:58 +0000 (UTC) (envelope-from v.a.popov@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 38D638FC1D; Thu, 29 Mar 2012 13:49:57 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1636462qcs.13 for ; Thu, 29 Mar 2012 06:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=5Xz6Zi9ivsJKWmDRe0kEbmx3U5M+rmVMjEG9fAx/ynM=; b=iM4eaSG6yGrEXxDpZBUeFKPmpg4ItlSsBPX0kVgyIolU/lsx4N2VJ/Zon7pUnVSWu+ lIizez2vaP/jtARow5hC0U9/RreJTU3vLDaisEZHJkuvjgUtY9XcyTaUaS1SrJOtSHi5 SWjIvJ06rA/YUkA8YbXJ9LAaFUk9TkMIpW77g2C6jfxNOW9AgIpGH5tLnvaRqaZhitoL RAsASSfac2fw80PTO/agVL99ZfioY+UsQqaXhnOios5NLQTEbZMf7+rTjdyJODkF/iKu q5DIgLxvBmqHSZstOqP7XF+TXcJJ3dA6rCfraiXb/tY6gDVtNZUDE4poKb0f6jy3slzZ j/Xw== Received: by 10.224.173.141 with SMTP id p13mr71950qaz.82.1333028997317; Thu, 29 Mar 2012 06:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.53.149 with HTTP; Thu, 29 Mar 2012 06:49:40 -0700 (PDT) From: Victor Popov Date: Thu, 29 Mar 2012 17:49:40 +0400 Message-ID: To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: scsi@freebsd.org Subject: 9.0-release panics with ASR_COMPAT and raidutil X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:49:58 -0000 Hi, My box panics when I use raidutil tool to turn off write-back for arrays and disks, as advised for database setup (because of no battery) and when getting status. Panic occurs immediately after issuing command 'raidutil -d 0 -w off d0b0t0d0', but sometimes it manages to complete and echo that write-back has been turned off. Several minutes after that it panics anyway, maybe on next disk, maybe on 'raidutil -d 0 -L all' to get information about status, maybe on reboot. Sometimes it panics after only one informational command 'raidutil -d 0 -L all' (immediate and several minutes later). Kernel config: include GENERIC ident CTRL1 options SC_HISTORY_SIZE=2000 options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_FORWARD options DUMMYNET options QUOTA options RACCT options RCTL device smbus device smb device ichsmb device ichwd options ASR_COMPAT raidutil is from port sysutils/asr-utils, ASR_COMPAT is added to kernel config to get it working. Several panic textdumps: http://pastebin.com/pnehc75B http://pastebin.com/NnpijeYJ http://pastebin.com/m8qJPPzD http://pastebin.com/UUUwcFMX http://pastebin.com/bP1BEbzG http://pastebin.com/1CWSEgqL No consistent backtrace among them - all different, so I am not including any in this message. vmcore.* dumps are preserved for a while, so they can be used if needed. I have to say that previously this box was running 7.4-release, and at least informational command 'raidutil -d 0 -L all' did not lead to panic. Any hint to help debugging this issue would be greatly appreciated. -- Best regards, Victor Popov From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 16:49:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10A151065670 for ; Thu, 29 Mar 2012 16:49:07 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id C96988FC18 for ; Thu, 29 Mar 2012 16:49:06 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2TGmd93037913 for ; Thu, 29 Mar 2012 09:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1333039720; bh=DZtpyVO4n/b3aNK0IhCNLdxgjvTgJaclSstcXNtSRA8=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=WRtFzzIm0oT3RlRX3Ag4EKE5qpBV3u5Dv5RI+2L6/wexAotzpdymac3izLPoxXCvn woPBJSV4k2jErHLgh5RzdNSAzhbBu2eGaxWZLdkVbANledKJZAP3K3oYK6gmpeXpKc P18dyJCboWH048Hb/Q+DhdcoO9Ggp+Jf5clIHfT4= From: Sean Bruno To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Mar 2012 09:48:39 -0700 Message-ID: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:49:07 -0000 Noting a failure to attach to the onboard IPMI controller with this dell R815. Not sure what to start poking at and thought I'd though this over here for comment. -bash-4.2$ dmesg |grep ipmi ipmi0: KCS mode found at io 0xca8 on acpi ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 ipmi0: Timed out waiting for GET_DEVICE_ID -bash-4.2$ sysctl -a|grep ipmi device ipmi # IPMI hw.ipmi.on: 1 dev.ipmi.0.%desc: IPMI System Interface dev.ipmi.0.%driver: ipmi dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5 dev.ipmi.0.%parent: acpi0 From owner-freebsd-stable@FreeBSD.ORG Thu Mar 29 17:22:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3A31065674; Thu, 29 Mar 2012 17:22:48 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5E68FC1F; Thu, 29 Mar 2012 17:22:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id q2THMj4k082365; Thu, 29 Mar 2012 21:22:45 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 29 Mar 2012 21:22:45 +0400 (MSK) From: Dmitry Morozovsky To: Steven Hartland In-Reply-To: Message-ID: References: <4EB522A5E2744235B0680BAF97F81862@multiplay.co.uk> <2C9AB504E6DF4024B9DBA68E41144104@multiplay.co.uk> <8C4E15FAFD134E0E82C0A8499D654E27@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (woozle.rinet.ru [0.0.0.0]); Thu, 29 Mar 2012 21:22:46 +0400 (MSK) Cc: mav@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ahci hangs on Supermicro MicroCloud second channel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:22:48 -0000 On Thu, 22 Mar 2012, Dmitry Morozovsky wrote: > > > I have received 1.0b from Mar 19, flashed it, but nothing changes regarding > > > disk subsystem; moreover, now kernel is constantly whining about acpi_tz0. > > > > > > Will investigate further. > > > > Which version of FreeBSD is this on Dmitry? Just checked our machines here > > and not seeing anything in /var/log/messages about this, so curious. > > I'm now testing two blades, one with releng/8, and second with releng/9. Same > effect. For the archives: yes, it seems very strange glitch with these blades and WD Caviar Blue AAKX: quick test with Hitachi 3T revieals expected 130+ Mbps throughput. What puzzles me most is that the very same disks work flawlessly on the very same chipset, but different SuperMicro platform. I just ordered another batch of small disks, will test with them. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 02:32:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48B8B106566C for ; Fri, 30 Mar 2012 02:32:08 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from ultra7.eskimo.com (ultra7.eskimo.com [204.122.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7DB8FC0C for ; Fri, 30 Mar 2012 02:32:07 +0000 (UTC) Received: from shell.eskimo.com (root@shell.eskimo.com [204.122.16.72]) by ultra7.eskimo.com (8.14.0/8.14.3) with ESMTP id q2U2W3fI003130 for ; Thu, 29 Mar 2012 19:32:03 -0700 Received: from shell.eskimo.com (joji@localhost [127.0.0.1]) by shell.eskimo.com (8.14.3/8.14.3) with ESMTP id q2U2S6R2030836 for ; Thu, 29 Mar 2012 19:28:06 -0700 Received: (from joji@localhost) by shell.eskimo.com (8.14.3/8.12.10/Submit) id q2U2S6DY030835 for freebsd-stable@freebsd.org; Thu, 29 Mar 2012 19:28:06 -0700 Date: Thu, 29 Mar 2012 19:28:06 -0700 From: Joseph Olatt To: freebsd-stable@freebsd.org Message-ID: <20120330022806.GA30761@shell.eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Subject: FreeBSD 8.3 and 9.0 freeze with firefox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 02:32:08 -0000 Hi, Starting with 8.3, I've been experiencing FreeBSD freezing up completely after using firefox for a while. Thinking the problem would go away if I upgraded to 9.0, I did that and I am still experiencing the same freezing up. The mouse pointer freezes, the keyboard freezes (caps lock light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only way to get the system back is by pressing and holding down the power button. The problem seems similar to: kern/163145 There is nothing in /var/log/messages to indicate a problem. Output of pciconf -lv and uname -a are at: http://www.eskimo.com/~joji/wisdom/ Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using firefox? From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 03:42:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28161065672 for ; Fri, 30 Mar 2012 03:42:04 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 985CE8FC0C for ; Fri, 30 Mar 2012 03:42:04 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q2U3ftfC012136; Thu, 29 Mar 2012 21:41:58 -0600 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Fri, 30 Mar 2012 10:41:54 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <20120330022806.GA30761@shell.eskimo.com> In-Reply-To: <20120330022806.GA30761@shell.eskimo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203301041.54397.erichfreebsdlist@ovitrap.com> Cc: Joseph Olatt Subject: Re: FreeBSD 8.3 and 9.0 freeze with firefox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 03:42:05 -0000 Hi, On Friday 30 March 2012 09:28:06 Joseph Olatt wrote: > > Starting with 8.3, I've been experiencing FreeBSD freezing up completely > after using firefox for a while. Thinking the problem would go away if I > upgraded to 9.0, I did that and I am still experiencing the same > freezing up. The mouse pointer freezes, the keyboard freezes (caps lock > light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only > way to get the system back is by pressing and holding down the power > button. > > The problem seems similar to: kern/163145 > > > There is nothing in /var/log/messages to indicate a problem. Output of > pciconf -lv and uname -a are at: > > http://www.eskimo.com/~joji/wisdom/ > > Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using > firefox? > I use 8.3 and Firefox without problems. What extension did you install? Are they all properly updated? Earlier, it helped deleting firefox' directory in the user directory. Erich From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 04:13:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 43311106567C for ; Fri, 30 Mar 2012 04:13:34 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 4B5818FC1D for ; Fri, 30 Mar 2012 04:13:31 +0000 (UTC) Received: (qmail 15706 invoked by uid 907); 30 Mar 2012 04:06:47 -0000 Received: from pa114-73-77-4.pa.nsw.optusnet.com.au (HELO [192.168.1.102]) (114.73.77.4) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Fri, 30 Mar 2012 15:06:46 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 15:06:40 +1100 Message-Id: To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: jhb@freebsd.org Subject: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 04:13:34 -0000 Hi, I have a loan LSI MegaRAID SAS 9240-4i controller for testing. According to the LSI documentation, this device provides the MegaRAID = interface and the BIOS message mentions MFI. The LSI driver for this = device also lists support for the 9261 which I know is supported by = mfi(4). Based on all this, I was hopeful that mfi(4) would work with the = 9240. The pciconf -lv output is: none3@pci0:1:0:0: class=3D0x010400 card=3D0x92411000 = chip=3D0x00731000 rev=3D0x03 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D 'MegaRAID SAS 9240' class =3D mass storage subclass =3D RAID I added this line to src/sys/dev/mfi/mfi_pci.c {0x1000, 0x0073, 0xffff, 0xffff, MFI_FLAGS_GEN2, "LSI MegaRAID = SAS 9240"}, It gave this result (tried with hw.mfi.msi set to 0 and to 1): mfi0: port 0xdc00-0xdcff mem = 0xfe7bc000-0xfe7bffff,0xfe7c0000-0xfe7fffff irq 16 at device 0.0 on pci1 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 3.00=20 mfi0: Frame 0xffffff8000285000 timed out command 0x26C8040 mfi0: failed to send init command The firmware is package 20.10.1-0077, which is the latest on the LSI = website. Is this path likely to work out? Any suggestions on where to go from = here? Thanks, Jan Mikkelsen From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 08:38:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E749106566C for ; Fri, 30 Mar 2012 08:38:34 +0000 (UTC) (envelope-from prvs=043690aa12=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC488FC08 for ; Fri, 30 Mar 2012 08:38:34 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDXLq-0001x9-TM for freebsd-stable@freebsd.org; Fri, 30 Mar 2012 10:38:30 +0200 Date: Fri, 30 Mar 2012 10:38:30 +0200 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20120330083830.GB65313@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:38:34 -0000 Hi all, Setup: I'm running 2 machines (amd64, 16GB) with FreeBSD 9-STABLE (Mar 14 so far) acting as NFS servers. They each serve 3 zpools (holding a single zfs, hourly snapshots). The zpools each are 3-way mirrors of ggate devices, each 2 TB, so 2 TB per zpool. Compression is "on" (to save bandwith to the backend, compressratio around 1.05 to 1.15), atime is off. There is no special tuning in loader.conf (except I tried to limit ZFS ARC to 8GB lately, which doesn't change a lot). sysctl.conf has: kern.ipc.maxsockbuf=33554432 net.inet.tcp.sendspace=8388608 net.inet.tcp.recvspace=8388608 kern.maxfiles=64000 vfs.nfsd.maxthreads=254 Without the first three zfs+ggate goes bad after a short time (checksum errors, stall), the latter are mainly for NFS and some regular local cleanup stuff. The machines have 4 em and 2 igb network interfaces. 3 of the are dedicated links (with no switches) to the ggate servers, one is a dedicated link to a third machine which gets feeded with incremental snapshots by ZFS send (as backup and fallaback of last resort), one interface for management tasks and one to an internal network with the NFS clients. The NFS clients are mostly FreeBSD 6, 7 and 9 STABLE machines (migration to 9 is running), no NFSv4 (by now), all tcp NFS links, merely no locking. Data consists of a lot of files, this is mainly mailboxes (IMAP: dovecot, incoming mail with exim, some simple web stuff with apache), so lots of small files, only few bigger ones. Directory structures to a reasonable depth. System is on a SSD (ufs, trim), additionally there are 3 (4 actually, 1 unused by now) 120GB SSDs serving as cache devices for the zpools. I first starting using the whole device, but in my hopes to change something limited cache to partitions of 32GB without change in behaviour. Problem: After about a week of runtime in normal workload the systems starts to swap (with about 300 to 500 MB of RAM free). Lots of swapping in and out, but only very few swap space used (30 to 50 MB). ZFS ARC at that point reaches it's minimum (while using up to it's configured maximum before). Most of the RAM is wired. L2ARC headers, accourding to zfs-stats eat about 1GB, ARC is at 1.8GB at this time. No userland processes using lots of RAM. After some time the system becomes unresponsive, the only way to fix this I had found by now is to reboot the machine (which of course gives a service interruption). >From the start of swapping to unresponsiveness I have about 2 to 4 hours to check several things (if I just knew what!). Workload distribution is not even over the day, from my munin graphs I can see, that wired grows at time of higher workload. At night with lower workload (but far from nothing, let's say about 1/3 to 1/2 in writes, but probably <1/4 in reads from weekday workload) I can barely see any groth of the wired graph. So where is my memory going, any ideas what to change? Kernel is stripped down from GENERIC and then everything I need loaded as modules. Kernel config: http://sysadm.in/zprob/ZSTOR loader.conf : http://sysadm.in/zprob/loader.conf dmesg.boot : http://sysadm.in/zprob/dmesg.boot -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 09:09:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B329106566B for ; Fri, 30 Mar 2012 09:09:07 +0000 (UTC) (envelope-from fred.fliu@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 E136F8FC15 for ; Fri, 30 Mar 2012 09:09:06 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so631806obb.13 for ; Fri, 30 Mar 2012 02:09:05 -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=krUoZZKmW7x/++3t+5AOhAqRPf6ZrbD7Y1kCoBOsDIM=; b=ZXiZIIV6k6WVo3ssXuKBwgOH8PLKEbV/9PkVDsSs0EHxGkm1S+Nuy21XD/8UB/OrEI NInmKCnVutcSfpFl7V7Tj8B8YGlGCLfYf27SR1EoKXJprcPUCQzBilILMrD2Mc/6ej1U oPb5cWFikc+InOaEHewbc0VS6lgQyQp6DOUC7tr5u9MK9CkpGQ+F5IsumhBiIlRv7NJJ wvbUluSh90FoIrh962bNRiYimG1traRVKhisPNYiAfd4jqn5YDXeIkrZQ50acIGP5wF+ Ni0fUMeg11PnhGeFBpsiWkXjXMVzBKlRX6Tae71kb9crNi7qwWVbRlHMlgTST9foMF+X Gd7Q== MIME-Version: 1.0 Received: by 10.60.3.99 with SMTP id b3mr1517704oeb.72.1333098545425; Fri, 30 Mar 2012 02:09:05 -0700 (PDT) Received: by 10.182.59.195 with HTTP; Fri, 30 Mar 2012 02:09:05 -0700 (PDT) In-Reply-To: <4F7309E2.4000502@icritical.com> References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> <4F72C588.2000204@icritical.com> <4F7309E2.4000502@icritical.com> Date: Fri, 30 Mar 2012 17:09:05 +0800 Message-ID: From: Fred Liu To: Matt Burke Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-stable@freebsd.org" , Fred Liu Subject: Re: SAS Drive identification LEDs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:09:07 -0000 > > How would you identify such a drive on any other system? > Normally, there are printed labels as the backup solution. Thanks. Fred From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 09:19:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F585106567A for ; Fri, 30 Mar 2012 09:19:53 +0000 (UTC) (envelope-from mpumford@mpcdata.com) Received: from owa.bsquare.com (vpn.bsquare.com [12.107.117.66]) by mx1.freebsd.org (Postfix) with ESMTP id 650718FC18 for ; Fri, 30 Mar 2012 09:19:53 +0000 (UTC) Received: from [10.150.16.163] (81.2.99.171) by BREAL.camelot.bsquare.com (192.168.100.67) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 30 Mar 2012 02:18:41 -0700 Message-ID: <4F757A67.5080302@mpcdata.com> Date: Fri, 30 Mar 2012 10:18:31 +0100 From: Mike Pumford User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120322 Firefox/12.0 SeaMonkey/2.9 MIME-Version: 1.0 To: References: <4F68FC3E.2090401@icritical.com> <4F71FEAE.3090506@icritical.com> <4F72C588.2000204@icritical.com> <4F7309E2.4000502@icritical.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [81.2.99.171] Subject: Re: SAS Drive identification LEDs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:19:53 -0000 Fred Liu wrote: >> >> How would you identify such a drive on any other system? >> > > Normally, there are printed labels as the backup solution. > You can identify SAS drives in an enclosure if the drive and enclosure provide the information needed. If you issue an INQUIRY EVPD read of page 0x83 on the drive it should give you the WWN and target SAS addresses of the drive. You should then be able to tie this up with the array element in the enclosure by matching it up with data in the SES diagnostic page 0xA from the enclosure. sg3_utils provides command line tools that can perform these queries. Mike -- Mike Pumford, Senior Software Engineer MPC Data Limited e-mail: mpumford@mpcdata.com web: www.mpcdata.com tel: +44 (0) 1225 710600 fax: +44 (0) 1225 710601 ddi: +44 (0) 1225 710635 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 09:57:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B9071065670 for ; Fri, 30 Mar 2012 09:57:15 +0000 (UTC) (envelope-from matt.thyer@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 2486D8FC12 for ; Fri, 30 Mar 2012 09:57:14 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so368385wgb.31 for ; Fri, 30 Mar 2012 02:57:13 -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=BqIZm2Ny5I32VfkVWVwPJ9ABG4LMUqKekY88RP9zkVQ=; b=PDRzTnpZZ7IvYfkbMHj3BXDPLSndsH+JpcLyjN/PMdjLQpmZDRJzKuSkvabwPknlGF 1hpccwyrSLOwKlCB1txdDP33R8FKBc/Ftzrpx86oJV2lm50hQVisKimEL2zhFQOjoHjX La6QfkAb6npjcUjEbw1vQwlV7B/IUhHLX0IeP0VKN9HJCWvUdxq4/i35Kvy2vtR/8LZW nr7WyllZhzPqJJ7zVzYZmLovnYW4NPmrZkq1Y7aCjluNOKflflWgHPuI7zjhnI7LXvMi /d9XVMF5sNQFC6f0wquvThkwa0HIKUzIE0tWFWePBKd4feEfbOVe7mty89dVWVzfdXtq WXDw== MIME-Version: 1.0 Received: by 10.180.82.136 with SMTP id i8mr4733750wiy.19.1333101433785; Fri, 30 Mar 2012 02:57:13 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 30 Mar 2012 02:57:13 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 30 Mar 2012 02:57:13 -0700 (PDT) In-Reply-To: <4F735CEC.5060101@gmail.com> References: <4F735CEC.5060101@gmail.com> Date: Fri, 30 Mar 2012 20:27:13 +1030 Message-ID: From: Matt Thyer To: Jim Bryant Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ESCape codes displayed instead of processed in pager X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:57:15 -0000 On Mar 29, 2012 5:18 AM, "Jim Bryant" wrote: > > Ever since I have upgraded to 9-stable, I have noticed that the manpages seem to be munged up with displayed instead of processed ESCape codes. I believe that this is due to the terminal type of the console changing from "cons25" to "xterm". If you fix your /etc/ttys to reflect this things should be OK. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 14:01:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D51F106568A for ; Fri, 30 Mar 2012 14:01:20 +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 0687B8FC14 for ; Fri, 30 Mar 2012 14:01:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 68C45B90E; Fri, 30 Mar 2012 10:01:19 -0400 (EDT) From: John Baldwin To: Jan Mikkelsen Date: Fri, 30 Mar 2012 10:01:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203301001.18681.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Mar 2012 10:01:19 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:01:20 -0000 On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote: > Hi, > > I have a loan LSI MegaRAID SAS 9240-4i controller for testing. > > According to the LSI documentation, this device provides the MegaRAID interface and the BIOS message mentions MFI. The LSI driver for this device also lists support for the 9261 which I know is supported by mfi(4). Based on all this, I was hopeful that mfi(4) would work with the 9240. > > The pciconf -lv output is: > > none3@pci0:1:0:0: class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03 hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = 'MegaRAID SAS 9240' > class = mass storage > subclass = RAID > > I added this line to src/sys/dev/mfi/mfi_pci.c > > {0x1000, 0x0073, 0xffff, 0xffff, MFI_FLAGS_GEN2, "LSI MegaRAID SAS 9240"}, > > It gave this result (tried with hw.mfi.msi set to 0 and to 1): > > mfi0: port 0xdc00-0xdcff mem 0xfe7bc000-0xfe7bffff,0xfe7c0000-0xfe7fffff irq 16 at device 0.0 on pci1 > mfi0: Using MSI > mfi0: Megaraid SAS driver Ver 3.00 > mfi0: Frame 0xffffff8000285000 timed out command 0x26C8040 > mfi0: failed to send init command > > The firmware is package 20.10.1-0077, which is the latest on the LSI website. > > Is this path likely to work out? Any suggestions on where to go from here? You should try the updated mfi(4) driver that Doug (cc'd) is going to soon merge into HEAD. It syncs up with the mfi(4) driver on LSI's website which supports several cards that the current mfi(4) driver does not. (I'm not fully sure if the 9240 is in that group or not. Doug might know however.) -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 14:14:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5442D106566C; Fri, 30 Mar 2012 14:14:50 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2B9F18FC12; Fri, 30 Mar 2012 14:14:50 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 30 Mar 2012 07:14:51 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2UEEiCi078708; Fri, 30 Mar 2012 07:14:44 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2UEEiNb078707; Fri, 30 Mar 2012 07:14:44 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203301414.q2UEEiNb078707@ambrisko.com> In-Reply-To: <201203301001.18681.jhb@freebsd.org> To: John Baldwin Date: Fri, 30 Mar 2012 07:14:44 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Jan Mikkelsen , freebsd-stable@freebsd.org Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:14:50 -0000 John Baldwin writes: | On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote: | > Hi, | > | > I have a loan LSI MegaRAID SAS 9240-4i controller for testing. | > | > According to the LSI documentation, this device provides the MegaRAID | > interface and the BIOS message mentions MFI. The LSI driver for this device | > also lists support for the 9261 which I know is supported by mfi(4). | > Based on all this, I was hopeful that mfi(4) would work with the 9240. | > | > The pciconf -lv output is: | > | > none3@pci0:1:0:0: class=0x010400 card=0x92411000 chip=0x00731000 rev=0x03 hdr=0x00 | > vendor = 'LSI Logic / Symbios Logic' | > device = 'MegaRAID SAS 9240' | > class = mass storage | > subclass = RAID | > | > I added this line to src/sys/dev/mfi/mfi_pci.c | > | > {0x1000, 0x0073, 0xffff, 0xffff, MFI_FLAGS_GEN2, "LSI MegaRAID SAS 9240"}, | > | > It gave this result (tried with hw.mfi.msi set to 0 and to 1): | > | > mfi0: port 0xdc00-0xdcff mem 0xfe7bc000-0xfe7bffff,0xfe7c0000-0xfe7fffff irq 16 at device 0.0 on pci1 | > mfi0: Using MSI | > mfi0: Megaraid SAS driver Ver 3.00 | > mfi0: Frame 0xffffff8000285000 timed out command 0x26C8040 | > mfi0: failed to send init command | > | > The firmware is package 20.10.1-0077, which is the latest on the LSI website. | > | > Is this path likely to work out? Any suggestions on where to go from here? | | You should try the updated mfi(4) driver that Doug (cc'd) is going to soon | merge into HEAD. It syncs up with the mfi(4) driver on LSI's website which | supports several cards that the current mfi(4) driver does not. (I'm not | fully sure if the 9240 is in that group or not. Doug might know however.) Yes, this card is supported with the mfi(4) in projects/head_mfi. Looks like we fixed a couple of last minute found bugs when trying to create a RAID wth mfiutil. This should be fixed now. I'm going to start the merge to -current today. The version in head_mfi can run on older versions of FreeBSD with the changes that Sean did. Note that I wouldn't recomend the 9240 since it can't have a battery option. NVRAM is the key to the speed of mfi(4) cards. However, that won't stop us from supporting it. Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 16:36:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89171065674; Fri, 30 Mar 2012 16:36:27 +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 7EF278FC0A; Fri, 30 Mar 2012 16:36:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DBBEBB93F; Fri, 30 Mar 2012 12:36:26 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, sbruno@freebsd.org Date: Fri, 30 Mar 2012 12:29:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203301229.45069.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Mar 2012 12:36:27 -0400 (EDT) Cc: Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:36:27 -0000 On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote: > Noting a failure to attach to the onboard IPMI controller with this dell > R815. Not sure what to start poking at and thought I'd though this over > here for comment. > > -bash-4.2$ dmesg |grep ipmi > ipmi0: KCS mode found at io 0xca8 on acpi > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi1: on isa0 > device_attach: ipmi1 attach returned 16 > ipmi0: Timed out waiting for GET_DEVICE_ID > > > -bash-4.2$ sysctl -a|grep ipmi > device ipmi # IPMI > hw.ipmi.on: 1 > dev.ipmi.0.%desc: IPMI System Interface > dev.ipmi.0.%driver: ipmi > dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM > dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5 > dev.ipmi.0.%parent: acpi0 Can you get dmidecode output? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 16:43:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECC62106566C for ; Fri, 30 Mar 2012 16:43:51 +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 C21FE8FC23 for ; Fri, 30 Mar 2012 16:43:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 337A1B922; Fri, 30 Mar 2012 12:43:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, lausts@acm.org Date: Fri, 30 Mar 2012 12:43:48 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F64608B.27301.3724F1@lausts.acm.org> <20120327195758.GA78507@klump.hjerdalen.lokalnett> <4F7334F1.5214.1516AE@lausts.acm.org> In-Reply-To: <4F7334F1.5214.1516AE@lausts.acm.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203301243.48914.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Mar 2012 12:43:51 -0400 (EDT) Cc: Eivind Evensen Subject: Re: Floppy disks don't work with FreeBSD 9.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 16:43:52 -0000 On Wednesday, March 28, 2012 3:57:37 pm Thomas Laus wrote: > > Hi. > > > > I'm a bit short on free machines, so the closest I can get right now > > is my everyday machine running from sources cvsupped from > > RELENG_8 3.rd of March: > > > I 'csuped' to FreeBSD 9.0-STABLE today and still had the same problem. This > computer has normal floppy disk operation when using FreeBSD 8.3-RC1 and > doesn't have any fd functionality with FreeBSD 9.0-STABLE. I entered a > Problem Report in the system today. > > Thanks for all of the help, we'll let the development team take if from here. I just fixed a bug in HEAD yesterday where bounce buffers for ISA DMA were broken in 9. Can you try that change out? Author: jhb Date: Thu Mar 29 18:58:02 2012 New Revision: 233675 URL: http://svn.freebsd.org/changeset/base/233675 Log: Restore proper use of bounce buffers for ISA DMA. When locking was added, the call to pmap_kextract() was moved up, and as a result the code never updated the physical address to use for DMA if a bounce buffer was used. Restore the earlier location of pmap_kextract() so it takes bounce buffers into account. Tested by: kargl MFC after: 1 week Modified: head/sys/x86/isa/isa_dma.c Modified: head/sys/x86/isa/isa_dma.c ============================================================================== --- head/sys/x86/isa/isa_dma.c Thu Mar 29 17:50:01 2012 (r233674) +++ head/sys/x86/isa/isa_dma.c Thu Mar 29 18:58:02 2012 (r233675) @@ -237,8 +237,6 @@ isa_dmastart(int flags, caddr_t addr, u_ caddr_t newaddr; int dma_range_checked; - /* translate to physical */ - phys = pmap_extract(kernel_pmap, (vm_offset_t)addr); dma_range_checked = isa_dmarangecheck(addr, nbytes, chan); #ifdef DIAGNOSTIC @@ -281,6 +279,9 @@ isa_dmastart(int flags, caddr_t addr, u_ addr = newaddr; } + /* translate to physical */ + phys = pmap_extract(kernel_pmap, (vm_offset_t)addr); + if (flags & ISADMA_RAW) { dma_auto_mode |= (1 << chan); } else { -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 17:40:02 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692B51065679 for ; Fri, 30 Mar 2012 17:40:02 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id 08E3B8FC1D for ; Fri, 30 Mar 2012 17:40:01 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 13:39:56 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 13:40:00 -0400 Message-ID: <4F75EF86.6090909@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 13:38:14 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: References: <4F75E404.8000104@cs.stonybrook.edu> In-Reply-To: <4F75E404.8000104@cs.stonybrook.edu> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig184EAF1AF49918C2F5CC19CF" X-Originating-IP: [72.89.250.133] Cc: Subject: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:40:02 -0000 --------------enig184EAF1AF49918C2F5CC19CF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian GNU/kFreeBSD, which has made collaboration difficult. With that said, Gentoo Portage is warning about text relocations in kernel modules. This is in a Gentoo/FreeBSD port of emulators/freebsd-kmod that I wrote. For instance, I see: # readelf -d /boot/modules/virtio.ko Dynamic section at offset 0x2f6c contains 13 entries: Tag Type Name/Value 0x00000004 (HASH) 0xd4 0x6ffffef5 (GNU_HASH) 0x238 0x00000005 (STRTAB) 0x4a8 0x00000006 (SYMTAB) 0x298 0x0000000a (STRSZ) 397 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000011 (REL) 0x638 0x00000012 (RELSZ) 1568 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x00000016 (TEXTREL) 0x0 0x0000001e (FLAGS) TEXTREL 0x6ffffffa (RELCOUNT) 108 0x00000000 (NULL) 0x0 Checking /boot/kernel, it seems that all modules have text relocations. My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations= =2E I don't have a reference i386 install, but according to frogs in ##freebsd on freenode, his i386 FreeBSD also has text relocations. Is this a bug? Yours truly, Richard Yao On 03/30/12 12:49, Richard Yao wrote: > Dear Ports Maintainers and kuriyama, >=20 > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable"= > instead of "loadable". >=20 > In addition, I have done the work necessary to port > emulators/freebsd-kmod to Gentoo/FreeBSD. >=20 > https://bugs.gentoo.org/show_bug.cgi?id=3D410199 >=20 > The ebuild contains a few improvements on the original FreeBSD port > where we copy only the parts of SYSDIR that we need to build the module= =2E > We also do hardlinks instead of copies when Gentoo Portage builds with > user privileges. >=20 > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org a= s > part of Gentoo's review process. I have permission from him to upstream= > the improvements we made on the port. Feel free to adopt any > improvements in the attachments in that bug report. >=20 > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > parts of the portage tree be relicensed under terms of the BSD-2 > license. With a little luck, it will be possible to upstream > improvements made in Gentoo/FreeBSD without any hassle in the future. >=20 > Yours truly, > Richard Yao >=20 --------------enig184EAF1AF49918C2F5CC19CF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPde+KAAoJELFAT5FmjZuENIIP/At2AdwgslMCfDneVx7oG5l1 2VYQAJA92Ca0osizn+t39FBSra9XXTCVcFlfTCdBZhiAaBJxva8hPsBhE/Z+uUPF b55moMncXYmIOgEYssJHk9nEonPI3R30pPVOxHobCLGILpKCpTpqT8rqxfTmAbwQ tQv5/8BVHvH2QDCAn9DhY4AQLOHW66L68x/sUHYWj4ivWQMGr8nQqlu8ssoDg733 5j1/FQwYdHPwvI0ob3Wb66NAQWuyNNYdXfKUdqTwWPKeSljDVYAK85f9W6S9kh2/ ywaruq2VfR69LjFBKNvfRgt3ANkv0/YMFboiwXC2Zn3DnIiYKTw/kAheJE6u4Fc8 6rhkZdV/299mWpdV4IEqSb+3zs0Vz71oWnzTBuCVGrFTd1PkpUPv6V+xwyCpp0hh Whw25Tm0QVqFh0mwvLTgvNhv8+/HVbwZ37npoDc9XZ9R0+UXJ5oz9R0BVZjVaysn r7hI2wjB9MtaKgw3jSbhUa1ZBNXP+xi2kgzYRBDTEICR66Mq2woDBhfxyoQKdryn MgeGycIFmOlrOO3nDZyrR06ZQWBT9F8+rXiL2VJSxMuxFURKMrAYdUvY7D5peM6n x5ojTCDB2l7Mb0w/ed/auNj8ZX6z82gQtkSjRUE1eJzLpFDAGkpp/Bj6kKh8Vwuj B5qMTuOOUkpwNED++g+/ =Wj1E -----END PGP SIGNATURE----- --------------enig184EAF1AF49918C2F5CC19CF-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 18:32:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2AEB106566B for ; Fri, 30 Mar 2012 18:32:58 +0000 (UTC) (envelope-from kc5vdj.freebsd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A15F8FC0C for ; Fri, 30 Mar 2012 18:32:58 +0000 (UTC) Received: by yenl9 with SMTP id l9so658330yen.13 for ; Fri, 30 Mar 2012 11:32:58 -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=kkFX9SZGhnrBQEYvjXwxAH0+4OC2KrEZG7ziEgqFEeA=; b=Zk4vRy2ZGRhuPlInvT+aur5DwWykCPD481DGUkFGlXPRCdI+azbSrxvUMUlSyLCTHv qziR6RurK4ioEopmWYLBINm7e+x8mNv0c6k8cMlC6XB0A5TRmVu9scpEmrMgv/Vy2wUm V3vrXtcT55mHLceTcErrhwZcjx5OZhWEFSHu/U9/t0qXQyHfpxLyNX3jVoigH3b5DqhY P/R+6XOLJmtrHFoQChn7mX/xijEkyL01b+hlVDl6iO4JjZdUpOcdYF4t4jVVkEeM6xd0 KBTF39hCLHP2kRGpF7WZsahsp8iwCt78kZBa0GaLvrM29MXXaf+EIeDD1ZzkuQxt+iKH TMwQ== Received: by 10.50.155.226 with SMTP id vz2mr138804igb.39.1333132377827; Fri, 30 Mar 2012 11:32:57 -0700 (PDT) Received: from argus.electron-tube.net (173-28-218-168.client.mchsi.com. [173.28.218.168]) by mx.google.com with ESMTPS id gf4sm2149635igb.14.2012.03.30.11.32.56 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 11:32:56 -0700 (PDT) Message-ID: <4F75FC5E.5020303@gmail.com> Date: Fri, 30 Mar 2012 13:33:02 -0500 From: Jim Bryant User-Agent: Thunderbird 2.0.0.24 (X11/20100911) MIME-Version: 1.0 To: Matt Thyer References: <4F735CEC.5060101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ESCape codes displayed instead of processed in pager X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 18:32:58 -0000 Matt Thyer wrote: > > On Mar 29, 2012 5:18 AM, "Jim Bryant" > wrote: > > > > Ever since I have upgraded to 9-stable, I have noticed that the > manpages seem to be munged up with displayed instead of processed > ESCape codes. > > I believe that this is due to the terminal type of the console > changing from "cons25" to "xterm". If you fix your /etc/ttys to > reflect this things should be OK. > 1:27:57pm argus(19): tty /dev/pts/7 1:28:03pm argus(20): setenv TERM xterm 1:28:05pm argus(21): man man MAN(1) FreeBSD General Commands Manual MAN(1) ESC[1mNAMEESC[0m ESC[1mman ESC[22m-- display online manual documentation pages same thing going on. that's after switching every vty and the console to xterm in /etc/ttys as well. i'm kinda lost on this one. i have determined that somehow, it's the pager... hang on a sec... lemme try vi. vi seems to be working properly... it's not the termcap/terminfo... the only thing causing this seems to be more and less, both. when i pipe man into cat, everything gets properly interpreted by the tty/vty/pty, when i use the pager, i get this crap....argh.. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 19:07:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA14A106566C for ; Fri, 30 Mar 2012 19:07: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 3E19A8FC1B for ; Fri, 30 Mar 2012 19:07: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 q2UJ7Epu051651; Fri, 30 Mar 2012 22:07:14 +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 q2UJ7E9N026127; Fri, 30 Mar 2012 22:07:14 +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 q2UJ7DJT026126; Fri, 30 Mar 2012 22:07:13 +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: Fri, 30 Mar 2012 22:07:13 +0300 From: Konstantin Belousov To: Richard Yao Message-ID: <20120330190713.GG2358@deviant.kiev.zoral.com.ua> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Aym+Xj7/WQ8n9Mht" Content-Disposition: inline In-Reply-To: <4F75EF86.6090909@cs.stonybrook.edu> 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-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:07:30 -0000 --Aym+Xj7/WQ8n9Mht Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 01:38:14PM -0400, Richard Yao wrote: > As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a > FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian > GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian > GNU/kFreeBSD, which has made collaboration difficult. >=20 > With that said, Gentoo Portage is warning about text relocations in > kernel modules. This is in a Gentoo/FreeBSD port of > emulators/freebsd-kmod that I wrote. For instance, I see: >=20 > # readelf -d /boot/modules/virtio.ko >=20 > Dynamic section at offset 0x2f6c contains 13 entries: > Tag Type Name/Value > 0x00000004 (HASH) 0xd4 > 0x6ffffef5 (GNU_HASH) 0x238 > 0x00000005 (STRTAB) 0x4a8 > 0x00000006 (SYMTAB) 0x298 > 0x0000000a (STRSZ) 397 (bytes) > 0x0000000b (SYMENT) 16 (bytes) > 0x00000011 (REL) 0x638 > 0x00000012 (RELSZ) 1568 (bytes) > 0x00000013 (RELENT) 8 (bytes) > 0x00000016 (TEXTREL) 0x0 > 0x0000001e (FLAGS) TEXTREL > 0x6ffffffa (RELCOUNT) 108 > 0x00000000 (NULL) 0x0 >=20 > Checking /boot/kernel, it seems that all modules have text relocations. > My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of > amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. >=20 > I don't have a reference i386 install, but according to frogs in > ##freebsd on freenode, his i386 FreeBSD also has text relocations. >=20 > Is this a bug? No. This is by design. Why do you consider this a bug ? >=20 > Yours truly, > Richard Yao >=20 > On 03/30/12 12:49, Richard Yao wrote: > > Dear Ports Maintainers and kuriyama, > >=20 > > emulators/freebsd-kmod has a typo in pkg-descr, where it says "lodable" > > instead of "loadable". > >=20 > > In addition, I have done the work necessary to port > > emulators/freebsd-kmod to Gentoo/FreeBSD. > >=20 > > https://bugs.gentoo.org/show_bug.cgi?id=3D410199 > >=20 > > The ebuild contains a few improvements on the original FreeBSD port > > where we copy only the parts of SYSDIR that we need to build the module. > > We also do hardlinks instead of copies when Gentoo Portage builds with > > user privileges. > >=20 > > The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as > > part of Gentoo's review process. I have permission from him to upstream > > the improvements we made on the port. Feel free to adopt any > > improvements in the attachments in that bug report. > >=20 > > Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and > > gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific > > parts of the portage tree be relicensed under terms of the BSD-2 > > license. With a little luck, it will be possible to upstream > > improvements made in Gentoo/FreeBSD without any hassle in the future. > >=20 > > Yours truly, > > Richard Yao > >=20 >=20 >=20 --Aym+Xj7/WQ8n9Mht Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk92BGEACgkQC3+MBN1Mb4gVEQCg4qgh2gjzAM5PG8mMuia0nlYb 66sAn0FF2iPH6jCHyW0EhePYqnGMvRHv =g0l2 -----END PGP SIGNATURE----- --Aym+Xj7/WQ8n9Mht-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 19:45:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15A4D10656B7 for ; Fri, 30 Mar 2012 19:45:11 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge2.cs.stonybrook.edu (edge2.cs.stonybrook.edu [130.245.9.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2C6DC8FC23 for ; Fri, 30 Mar 2012 19:45:09 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge2.cs.stonybrook.edu (130.245.9.211) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 15:46:11 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 15:45:08 -0400 Message-ID: <4F760CDE.2070602@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 15:43:26 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 CC: References: <4F760C9E.6060405@cs.stonybrook.edu> In-Reply-To: <4F760C9E.6060405@cs.stonybrook.edu> X-Enigmail-Version: 1.3.5 X-Forwarded-Message-Id: <4F760C9E.6060405@cs.stonybrook.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC3BF4BF3DA62CCE219855FCE" X-Originating-IP: [72.89.250.133] Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 19:45:11 -0000 --------------enigC3BF4BF3DA62CCE219855FCE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 15:07, Konstantin Belousov wrote: >> Is this a bug? > No. This is by design. >=20 > Why do you consider this a bug ? It occurs on i386, but not amd64. It could be that something is wrong with how things are being compiled i386, or it could be that i386 requires things to be compiled this way. I do not know which. --------------enigC3BF4BF3DA62CCE219855FCE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdgzeAAoJELFAT5FmjZuEUB4P/RzxCtY6BMbGrDrQK50Eu3V3 o8b3vSm7D2WAf70OnbyHCaCrk1q7T8qo1H3Y4FBQ+vy3hykbxYOytoue3sYubalF rXtNDqU9hkZf4kdbZl0qoSJS7CislFNKnIcaYPEgmlVn0vEhJ32ktAL+XZ5kmv/V XTCy7NvVjHE9pK8GqkkjhCwx4crKMqEEOD4Bxc7LhsN7n241I2ynai5XagzBKDGk 3q414meEv40EM9DaXZdcM5Y5J3qhS7g5bwn9giqvy31pH4pFlZV24urMOz0njGxZ B2umOY1+R+ZCCj4wnoc6HEDGTRNPbY4Q+/kUoDKEd+lqvJBNE+FqQ6ovBp08y76I 4DDYDR0wl00BFg4sbz8c8NnEM7VAXnsFNprIg6dhj9Yc/8OeeR+MPEjWpPnKIc+c +ExA6x4LtUFKOjB3XHCWzT4Kd9qJUd2Wki6ud0V6KMGTciTROJVkkmYGBbHb+Vuw /be5Bp3rNok8ufDslKYb9Vxe+OC9DPxKJbAelv/X4B/u2m+JqPK2PPcY0GwJWUlG 13V7/ckedkA1XszP5C9+ty7/Ns95GilhJP//4eb7yY56zkovOKzEdDSFGs9rT0MH ukFwGR6t7Hbn4sZl38b2KtpKCAl1Vu7eFXjaP2qkrtCQXs843dS104QfYOkZLip/ Boma72l632+nFjB3Ebd5 =AaPo -----END PGP SIGNATURE----- --------------enigC3BF4BF3DA62CCE219855FCE-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 20:04:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CCAB106564A; Fri, 30 Mar 2012 20:04:35 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id C232D8FC14; Fri, 30 Mar 2012 20:04:34 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2UK3tWt038926; Fri, 30 Mar 2012 13:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1333137835; bh=s9YStr+bNtlIa1bqVgf37VyheKWbeIQVpZ+OfXk01Hk=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=XsgwZj/7CXLPcpMpbv4cYTZk78OwWAmHyLEqQ4m2i9o6UatXMJLqdWz2kfinQGqdc Xom+IFqfvQnRm2F+SOt+fHaq+8F4+1LUKQWUoWeKDdof4tdbE5or+CtNxSqEd+NvEA 1tgzy7qywC+ixZ+ZNA4T8B2VjVJUySxtcnD7C2PI= From: Sean Bruno To: John Baldwin In-Reply-To: <201203301229.45069.jhb@freebsd.org> References: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> <201203301229.45069.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 30 Mar 2012 13:03:54 -0700 Message-ID: <1333137834.4450.0.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:04:35 -0000 On Fri, 2012-03-30 at 09:29 -0700, John Baldwin wrote: > On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote: > > Noting a failure to attach to the onboard IPMI controller with this dell > > R815. Not sure what to start poking at and thought I'd though this over > > here for comment. > > > > -bash-4.2$ dmesg |grep ipmi > > ipmi0: KCS mode found at io 0xca8 on acpi > > ipmi1: on isa0 > > device_attach: ipmi1 attach returned 16 > > ipmi1: on isa0 > > device_attach: ipmi1 attach returned 16 > > ipmi0: Timed out waiting for GET_DEVICE_ID > > > > > > -bash-4.2$ sysctl -a|grep ipmi > > device ipmi # IPMI > > hw.ipmi.on: 1 > > dev.ipmi.0.%desc: IPMI System Interface > > dev.ipmi.0.%driver: ipmi > > dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM > > dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5 > > dev.ipmi.0.%parent: acpi0 > > Can you get dmidecode output? > http://people.freebsd.org/~sbruno/dmidecode_r815.txt http://people.freebsd.org/~sbruno/pciconf_r815.txt Sean From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 20:13:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61E9C106564A for ; Fri, 30 Mar 2012 20:13:19 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge2.cs.stonybrook.edu (edge2.cs.stonybrook.edu [130.245.9.211]) by mx1.freebsd.org (Postfix) with ESMTP id 005228FC08 for ; Fri, 30 Mar 2012 20:13:18 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge2.cs.stonybrook.edu (130.245.9.211) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 16:14:19 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 16:13:16 -0400 Message-ID: <4F761371.7020606@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 16:11:29 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120330194649.GH2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD28983ED4DAC2DD9BEF3FD00" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:13:19 -0000 --------------enigD28983ED4DAC2DD9BEF3FD00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 15:46, Konstantin Belousov wrote: > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: >> On 03/30/12 15:07, Konstantin Belousov wrote: >>>> Is this a bug? >>> No. This is by design. >>> >>> Why do you consider this a bug ? >> >> It occurs on i386, but not amd64. It could be that something is wrong >> with how things are being compiled i386, or it could be that i386 >> requires things to be compiled this way. I do not know which. >> > Again, let me repeat my question. Why do you consider the presence > of relocations against text section a problem ? The linker emits warnings: i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager= =2E * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xm= l * Please include the following list of files in your report: * TEXTREL boot/modules/if_vtnet.ko * TEXTREL boot/modules/virtio_blk.ko * TEXTREL boot/modules/virtio.ko * TEXTREL boot/modules/virtio_balloon.ko * TEXTREL boot/modules/virtio_pci.ko I wrote that ebuild as part of something entirely unrelated. If it is a feature, I can disable the QA check, but I should at least know why the text relocations are needed. Gentoo maintainers are expected to patch text relocations and send patches upstream. The only exception is in the case of binary packages, which they cannot patch. Investigating the text relocations in my port of emulators/virtio-kmod revealed that all kernel modules on i386 Gentoo/FreeBSD have text relocations, yet none have them on amd64 FreeBSD, so I do not know whether this is a bug or a feature. --------------enigD28983ED4DAC2DD9BEF3FD00 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdhN2AAoJELFAT5FmjZuEqOAQALyYO2l11/G9VxS0XFf12kFo u20lqhWkCrRbhZU3HKc99p5RLfQVcPZsgj63RURBlI1h1Exo/CL6hQzYzSArWTO5 7oZttbSWmzL7wDecfzIr6PbJlM2kpBnGizFj4IDGpYSN7ca1DI3spAO8nCM0rDv4 2rMmgPqgRnNsKwP1hJxjzyxkflaAj36TR0YNBlV9cArbo7c7ZRuYZ8Zaf+9w0WFS zCYkDANA31jHE/5J5j6QWiEKYWVe5axmZvIoYNzhxUeE2708QnYPqL/+SiNyfJfy TxP6b3GT74jSvwJKQBI3Ci5q+gQqro6iQCwGOVT3pceYUpJcAcYzkSnlYT3bZVfu sgtYy6177wTYwUdlXrPBUb7zKQKqTg4R36xvi8XorxABBYmhGVyD57kH/RX7BzMS BsKtxQLiwohJiJ3hSEFEmjiAjTmn9JntCSuluIsRNpkPF/XnQtzptoCSHZY/QQPn bigEIS4la8vJqFtYOzp2ckaX11cZIQwf1Hci/xtRr3ao7bzYPIYH6BGauBALIh1n VAnknxXTc3/WskZFyQXfSq9UAlJMWD0G0nygm0D7q0SNIN2dGLT54JkkBDc6+L67 9U05anPBx1xi7cMREJ/wNIJVHwDtlx6hmX091n4Bv8VnQ3k/JjZTS+uGWMZH7MoP j6MAXkdxlZLC6vSTbEFn =BOcF -----END PGP SIGNATURE----- --------------enigD28983ED4DAC2DD9BEF3FD00-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 20:36:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3791065705 for ; Fri, 30 Mar 2012 20:36:23 +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 339568FC0C for ; Fri, 30 Mar 2012 20:36:22 +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 q2UKa60t057609; Fri, 30 Mar 2012 23:36:06 +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 q2UKa55K026699; Fri, 30 Mar 2012 23:36:05 +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 q2UKa5Zu026698; Fri, 30 Mar 2012 23:36:05 +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: Fri, 30 Mar 2012 23:36:05 +0300 From: Konstantin Belousov To: Richard Yao Message-ID: <20120330203605.GI2358@deviant.kiev.zoral.com.ua> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0xbckOs9ckBzXei" Content-Disposition: inline In-Reply-To: <4F761371.7020606@cs.stonybrook.edu> 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-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 20:36:23 -0000 --i0xbckOs9ckBzXei Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 04:11:29PM -0400, Richard Yao wrote: > On 03/30/12 15:46, Konstantin Belousov wrote: > > On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: > >> On 03/30/12 15:07, Konstantin Belousov wrote: > >>>> Is this a bug? > >>> No. This is by design. > >>> > >>> Why do you consider this a bug ? > >> > >> It occurs on i386, but not amd64. It could be that something is wrong > >> with how things are being compiled i386, or it could be that i386 > >> requires things to be compiled this way. I do not know which. > >> > > Again, let me repeat my question. Why do you consider the presence > > of relocations against text section a problem ? >=20 > The linker emits warnings: > i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. >=20 > Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. >=20 > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml > * Please include the following list of files in your report: > * TEXTREL boot/modules/if_vtnet.ko > * TEXTREL boot/modules/virtio_blk.ko > * TEXTREL boot/modules/virtio.ko > * TEXTREL boot/modules/virtio_balloon.ko > * TEXTREL boot/modules/virtio_pci.ko >=20 > I wrote that ebuild as part of something entirely unrelated. If it is a > feature, I can disable the QA check, but I should at least know why the > text relocations are needed. >=20 > Gentoo maintainers are expected to patch text relocations and send > patches upstream. The only exception is in the case of binary packages, > which they cannot patch. >=20 > Investigating the text relocations in my port of emulators/virtio-kmod > revealed that all kernel modules on i386 Gentoo/FreeBSD have text > relocations, yet none have them on amd64 FreeBSD, so I do not know > whether this is a bug or a feature. >=20 First, there _are_ relocations against text in the amd64 modules, but I suspect that your scripts do not detect this. Most likely, scripts look for DT_TEXTREL dynamic tag, and tags are only present in the executables or shared objects, not in the object files. The amd64 modules are object files, so you just mis-interpret the situation. Second, from what you wrote, I see the issue in either wrong policy being established in your project, or (another) mis-interpretation of the policy. Indeed, having text relocations in the shared objects is bad, because said relocations hinder text pages sharing. Relocated page is modified, so COW mechanism causes it to become private to process. On the other hand, there is only one instance of the loaded kernel module, its text segment (or section, for amd64) is not shared, so modifications to the text pages do not cause increased memory use. More, not compiling modules with -fPIC (absence of -fPIC is what makes the text relocations to appear in the final link result) makes the code faster, esp. on i386. So, there is nothing to report, and fix is outside the FreeBSD domain: either fix your policy by not stating that text relocation in kernel module is banned, or just find that policy only applicable to usermode objects. --i0xbckOs9ckBzXei Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk92GTQACgkQC3+MBN1Mb4g7cQCgnitw46a68Tb8cyxG+6Ze2KOZ MkAAoNetmv8hRzJLz7mBs0pRq8Fqdx+4 =e9HE -----END PGP SIGNATURE----- --i0xbckOs9ckBzXei-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 21:02:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F201106566B for ; Fri, 30 Mar 2012 21:02:09 +0000 (UTC) (envelope-from pgollucci@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 019168FC08 for ; Fri, 30 Mar 2012 21:02:08 +0000 (UTC) Received: by yhgm50 with SMTP id m50so763565yhg.13 for ; Fri, 30 Mar 2012 14:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type; bh=R1SdtW0D09adkcVCXaip4BlarDuXJWZhdpHF+5+zLKI=; b=yzEaT/6TswAQ9fLZ8DiZI5kCxXn7z0YSQ5SZhmw+o5JhPY/ZL8JYWgyBlZyUC45J1i AlDmjfT14PqTZmrpiW0Hlkmg7Z5RVM2CrkWj4v6jYYbY9Mk/oHsaLcjZs8UZV8VhsjiJ BOy/bLA3FxYCEJGT/MIptr3qADfeHJSBoNWzfADCgZ6uQBXKIcO/tSO95KYFQYwfPPAY 5/4u7ZNgltkulHVDSSTzkKNZNQd2AGl3QIcr6RCL3dG2qFClQHDLgIJw4k7ACj22aFwn hPBV0PF2nRZFvUG2R3kgA5+xFaiqp+8S9gHxRKMUXsrVqAq53ChhKzaThxhQK3axLD/V zTkw== Received: by 10.236.72.167 with SMTP id t27mr3332986yhd.79.1333141328217; Fri, 30 Mar 2012 14:02:08 -0700 (PDT) Received: from philip.hq.rws (wsip-174-79-184-239.dc.dc.cox.net. [174.79.184.239]) by mx.google.com with ESMTPS id b4sm13486662anb.22.2012.03.30.14.02.06 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 14:02:07 -0700 (PDT) Message-ID: <4F761F4B.90409@p6m7g8.com> Date: Fri, 30 Mar 2012 21:02:03 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111029 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120330083830.GB65313@e-Gitt.NET> In-Reply-To: <20120330083830.GB65313@e-Gitt.NET> X-Enigmail-Version: undefined Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF63D4A7FF0DE228FE25981AE" Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:02:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF63D4A7FF0DE228FE25981AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.ht= ml Same issue different thread. Different software. Its not NFS, its ZFS. I don't really have a place to try it on 8.2, but my hunch from things I've done rather similarly which don't cause tell me its a new issue in 9.0, though I won't swear by that. On 03/30/12 08:38, Oliver Brandmueller wrote: > Hi all, >=20 > Setup: >=20 > I'm running 2 machines (amd64, 16GB) with FreeBSD 9-STABLE (Mar 14 so=20 > far) acting as NFS servers. They each serve 3 zpools (holding a single = > zfs, hourly snapshots). The zpools each are 3-way mirrors of ggate=20 > devices, each 2 TB, so 2 TB per zpool. Compression is "on" (to save=20 > bandwith to the backend, compressratio around 1.05 to 1.15), atime is=20 > off. >=20 > There is no special tuning in loader.conf (except I tried to limit ZFS = > ARC to 8GB lately, which doesn't change a lot). sysctl.conf has: >=20 > kern.ipc.maxsockbuf=3D33554432 > net.inet.tcp.sendspace=3D8388608 > net.inet.tcp.recvspace=3D8388608 > kern.maxfiles=3D64000 > vfs.nfsd.maxthreads=3D254 >=20 > Without the first three zfs+ggate goes bad after a short time (checksum= =20 > errors, stall), the latter are mainly for NFS and some regular local=20 > cleanup stuff. >=20 > The machines have 4 em and 2 igb network interfaces. 3 of the are=20 > dedicated links (with no switches) to the ggate servers, one is a=20 > dedicated link to a third machine which gets feeded with incremental=20 > snapshots by ZFS send (as backup and fallaback of last resort), one=20 > interface for management tasks and one to an internal network with the = > NFS clients. >=20 > The NFS clients are mostly FreeBSD 6, 7 and 9 STABLE machines (migratio= n=20 > to 9 is running), no NFSv4 (by now), all tcp NFS links, merely no=20 > locking. >=20 > Data consists of a lot of files, this is mainly mailboxes (IMAP:=20 > dovecot, incoming mail with exim, some simple web stuff with apache), s= o=20 > lots of small files, only few bigger ones. Directory structures to a=20 > reasonable depth. >=20 > System is on a SSD (ufs, trim), additionally there are 3 (4 actually, 1= =20 > unused by now) 120GB SSDs serving as cache devices for the zpools. I=20 > first starting using the whole device, but in my hopes to change=20 > something limited cache to partitions of 32GB without change in=20 > behaviour. >=20 >=20 > Problem: >=20 > After about a week of runtime in normal workload the systems starts to = > swap (with about 300 to 500 MB of RAM free). Lots of swapping in and=20 > out, but only very few swap space used (30 to 50 MB). ZFS ARC at that=20 > point reaches it's minimum (while using up to it's configured maximum=20 > before). Most of the RAM is wired. L2ARC headers, accourding to=20 > zfs-stats eat about 1GB, ARC is at 1.8GB at this time. No userland=20 > processes using lots of RAM. >=20 > After some time the system becomes unresponsive, the only way to fix=20 > this I had found by now is to reboot the machine (which of course gives= =20 > a service interruption). >=20 >>From the start of swapping to unresponsiveness I have about 2 to 4 hour= s=20 > to check several things (if I just knew what!). >=20 > Workload distribution is not even over the day, from my munin graphs I = > can see, that wired grows at time of higher workload. At night with=20 > lower workload (but far from nothing, let's say about 1/3 to 1/2 in=20 > writes, but probably <1/4 in reads from weekday workload) I can barely = > see any groth of the wired graph. >=20 > So where is my memory going, any ideas what to change? >=20 > Kernel is stripped down from GENERIC and then everything I need loaded = > as modules. >=20 > Kernel config: http://sysadm.in/zprob/ZSTOR > loader.conf : http://sysadm.in/zprob/loader.conf > dmesg.boot : http://sysadm.in/zprob/dmesg.boot >=20 >=20 --=20 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. --------------enigF63D4A7FF0DE228FE25981AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPdh9NdbiP+9ubjBwRAkZEAJ4rZGmt83oUHdifobQuNVGdUI7GLgCeMJhJ PA65Y/FdyUzcnuqvoSD3Dqg= =7TSj -----END PGP SIGNATURE----- --------------enigF63D4A7FF0DE228FE25981AE-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 21:14:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF36F1065678; Fri, 30 Mar 2012 21:14:38 +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 A24858FC14; Fri, 30 Mar 2012 21:14:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9A4EB93E; Fri, 30 Mar 2012 17:14:37 -0400 (EDT) From: John Baldwin To: Sean Bruno Date: Fri, 30 Mar 2012 17:14:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> <201203301229.45069.jhb@freebsd.org> <1333137834.4450.0.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1333137834.4450.0.camel@powernoodle-l7.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201203301714.37323.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Mar 2012 17:14:37 -0400 (EDT) Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:14:38 -0000 On Friday, March 30, 2012 4:03:54 pm Sean Bruno wrote: > On Fri, 2012-03-30 at 09:29 -0700, John Baldwin wrote: > > On Thursday, March 29, 2012 12:48:39 pm Sean Bruno wrote: > > > Noting a failure to attach to the onboard IPMI controller with this dell > > > R815. Not sure what to start poking at and thought I'd though this over > > > here for comment. > > > > > > -bash-4.2$ dmesg |grep ipmi > > > ipmi0: KCS mode found at io 0xca8 on acpi > > > ipmi1: on isa0 > > > device_attach: ipmi1 attach returned 16 > > > ipmi1: on isa0 > > > device_attach: ipmi1 attach returned 16 > > > ipmi0: Timed out waiting for GET_DEVICE_ID > > > > > > > > > -bash-4.2$ sysctl -a|grep ipmi > > > device ipmi # IPMI > > > hw.ipmi.on: 1 > > > dev.ipmi.0.%desc: IPMI System Interface > > > dev.ipmi.0.%driver: ipmi > > > dev.ipmi.0.%location: handle=\_SB_.PCI0.ISA_.NIPM > > > dev.ipmi.0.%pnpinfo: _HID=IPI0001 _UID=5 > > > dev.ipmi.0.%parent: acpi0 > > > > Can you get dmidecode output? > > > > > http://people.freebsd.org/~sbruno/dmidecode_r815.txt This is the relevant bits: Handle 0x2600, DMI type 38, 18 bytes IPMI Device Information Interface Type: KCS (Keyboard Control Style) Specification Version: 2.0 I2C Slave Address: 0x10 NV Storage Device: Not Present Base Address: 0x0000000000000CA8 (I/O) Register Spacing: 32-bit Boundaries Note the '32-bit' boundaries. I think ACPI doesn't support that for its attachment (well, it does if they specify each port as a separate thing in _CRS). Can you get acpidump -d output? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 21:30:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FA101065674; Fri, 30 Mar 2012 21:30:54 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 24A198FC1B; Fri, 30 Mar 2012 21:30:53 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2ULUZee082660; Fri, 30 Mar 2012 14:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1333143035; bh=jj9JZBaf2s+QMiHUkZT1Brlb0cQFHbMbkiJI/QLgrKE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=aH0OkazLTgvOM/cEKW/T+nF+73/H9haGUSqiDjy7TjiWwn/NrfYpvw278GbOuNxqD wVVlF01sF7YTyeJREYsTNFe7I00dM/JmmWuPzACH2tSXVkpbEAWahVqSEYHd1lesU7 ayYAIBGLYv+4/kGpYCX0VPrA2YZGN4GS99KD9Bjc= From: Sean Bruno To: John Baldwin In-Reply-To: <201203301714.37323.jhb@freebsd.org> References: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> <201203301229.45069.jhb@freebsd.org> <1333137834.4450.0.camel@powernoodle-l7.corp.yahoo.com> <201203301714.37323.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 30 Mar 2012 14:30:34 -0700 Message-ID: <1333143034.4450.1.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:30:54 -0000 > This is the relevant bits: > > Handle 0x2600, DMI type 38, 18 bytes > IPMI Device Information > Interface Type: KCS (Keyboard Control Style) > Specification Version: 2.0 > I2C Slave Address: 0x10 > NV Storage Device: Not Present > Base Address: 0x0000000000000CA8 (I/O) > Register Spacing: 32-bit Boundaries > > Note the '32-bit' boundaries. I think ACPI doesn't support that for its > attachment (well, it does if they specify each port as a separate thing in > _CRS). Can you get acpidump -d output? > Aye, here ya go. http://people.freebsd.org/~sbruno/acpidump_r815.txt sean From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 21:53:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B289B1065672 for ; Fri, 30 Mar 2012 21:53:02 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 0A38C8FC22 for ; Fri, 30 Mar 2012 21:53:01 +0000 (UTC) Received: (qmail 17713 invoked by uid 907); 30 Mar 2012 21:52:58 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.100]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 31 Mar 2012 08:52:58 +1100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jan Mikkelsen In-Reply-To: <201203301414.q2UEEiNb078707@ambrisko.com> Date: Sat, 31 Mar 2012 08:53:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B722CC7-6D84-48A5-811A-4616191ECC96@transactionware.com> References: <201203301414.q2UEEiNb078707@ambrisko.com> To: Doug Ambrisko X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 21:53:02 -0000 Hi, On 31/03/2012, at 1:14 AM, Doug Ambrisko wrote: > John Baldwin writes: > | On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote: > | ... > | > Is this path likely to work out? Any suggestions on where to go = from here? > |=20 > | You should try the updated mfi(4) driver that Doug (cc'd) is going = to soon > | merge into HEAD. It syncs up with the mfi(4) driver on LSI's = website which > | supports several cards that the current mfi(4) driver does not. = (I'm not > | fully sure if the 9240 is in that group or not. Doug might know = however.) >=20 > Yes, this card is supported with the mfi(4) in projects/head_mfi. = Looks > like we fixed a couple of last minute found bugs when trying to create = a > RAID wth mfiutil. This should be fixed now. I'm going to start the > merge to -current today. The version in head_mfi can run on older > versions of FreeBSD with the changes that Sean did. >=20 > Note that I wouldn't recomend the 9240 since it can't have a battery > option. NVRAM is the key to the speed of mfi(4) cards. However, that > won't stop us from supporting=20 Thanks. I don't know what changes Sean did. Are they in 9.0-release, or do I = need -stable after a certain point? I'm assuming I should be able to = take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current. The performance is an interesting thing. The write performance I care = about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on = this controller. The 9261 with a BBU performs well but obviously costs = more. I can see the BBU being important for controller based raid5, but I'm = hoping that ZFS with JBOD will still perform well. I'm ignorant at this = point, so that's why I'm trying it out. Do you have any experience or = expectations with a 9240 being used in a setup like that? Regards, Jan. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 22:21:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 815FF106566C; Fri, 30 Mar 2012 22:21:09 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 571348FC16; Fri, 30 Mar 2012 22:21:08 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 30 Mar 2012 15:21:14 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2UML7Rg055022; Fri, 30 Mar 2012 15:21:07 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2UML7O2055021; Fri, 30 Mar 2012 15:21:07 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203302221.q2UML7O2055021@ambrisko.com> In-Reply-To: <7B722CC7-6D84-48A5-811A-4616191ECC96@transactionware.com> To: Jan Mikkelsen Date: Fri, 30 Mar 2012 15:21:07 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:21:09 -0000 Jan Mikkelsen writes: | Hi, | | On 31/03/2012, at 1:14 AM, Doug Ambrisko wrote: | | > John Baldwin writes: | > | On Friday, March 30, 2012 12:06:40 am Jan Mikkelsen wrote: | > | ... | > | > Is this path likely to work out? Any suggestions on where to go from here? | > | | > | You should try the updated mfi(4) driver that Doug (cc'd) is going to soon | > | merge into HEAD. It syncs up with the mfi(4) driver on LSI's website which | > | supports several cards that the current mfi(4) driver does not. (I'm not | > | fully sure if the 9240 is in that group or not. Doug might know however.) | > | > Yes, this card is supported with the mfi(4) in projects/head_mfi. Looks | > like we fixed a couple of last minute found bugs when trying to create a | > RAID wth mfiutil. This should be fixed now. I'm going to start the | > merge to -current today. The version in head_mfi can run on older | > versions of FreeBSD with the changes that Sean did. | > | > Note that I wouldn't recomend the 9240 since it can't have a battery | > option. NVRAM is the key to the speed of mfi(4) cards. However, that | > won't stop us from supporting | | Thanks. | | I don't know what changes Sean did. Are they in 9.0-release, or do I | need -stable after a certain point? I'm assuming I should be able to | take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current. It's in the SVN project/head_mfi repro. You can browse it via the web at: http://svnweb.freebsd.org/base/projects/head_mfi/ It's not in -current yet. I'm working on the. I just did all the merges to a look try and eye'd them over. Now doing a compile test then I can check it into -current. | The performance is an interesting thing. The write performance I care | about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on | this controller. The 9261 with a BBU performs well but obviously costs more. There will need to be clarification in the future. JBOD is not that same as a single disk RAID. If I remember correctly, when doing some JBOD testing version single disk RAID is that JBOD is slower. A single disk RAID is faster since it can use the RAID. However, without the battery then you risk losing data on power outage etc. Without the battery then performance of a JBOD and single disk RAID should be able the same. A real JBOD as shown by LSI's firmware etc. shows up as a /dev/mfisyspd entries. JBOD by LSI is a newer thing. | I can see the BBU being important for controller based raid5, but I'm | hoping that ZFS with JBOD will still perform well. I'm ignorant at this | point, so that's why I'm trying it out. Do you have any experience or | expectations with a 9240 being used in a setup like that? The battery or NVRAM doesn't matter on the RAID type being used since the cache in NVRAM mode, says done whenever it has space in the cache for the write. Eventually, it will hit the disk. Without the cache working in this mode the write can't be acknowledged until the disk says done. So performance suffers. With a single disk RAID you have been using the cache. Now you can force using the cache without NVRAM but you have to acknowledge the risk of that. Doug A. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 22:36:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9FE106566C for ; Fri, 30 Mar 2012 22:36:45 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id 67E298FC1C for ; Fri, 30 Mar 2012 22:36:44 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 18:36:41 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 18:36:43 -0400 Message-ID: <4F76350F.8000708@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 18:34:55 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120330203605.GI2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA748CAFEF5F455A00C0C8AE8" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:36:45 -0000 --------------enigA748CAFEF5F455A00C0C8AE8 Content-Type: multipart/mixed; boundary="------------080004000109050607090903" This is a multi-part message in MIME format. --------------080004000109050607090903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 16:36, Konstantin Belousov wrote: > First, there _are_ relocations against text in the amd64 modules, but I= > suspect that your scripts do not detect this. Most likely, scripts look= > for DT_TEXTREL dynamic tag, and tags are only present in the executable= s > or shared objects, not in the object files. The amd64 modules are objec= t > files, so you just mis-interpret the situation. readelf is a part of binutils. It is not a script. Here is the version that Gentoo/FreeBSD uses: # readelf --version GNU readelf (GNU Binutils) 2.20.1.20100303 Copyright 2009 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of= the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. In addition, this is what it says when I ask it to look at virtio_blk.ko:= # readelf -d /boot/modules/virtio_blk.ko Dynamic section at offset 0x2f6c contains 13 entries: Tag Type Name/Value 0x00000004 (HASH) 0xd4 0x6ffffef5 (GNU_HASH) 0x480 0x00000005 (STRTAB) 0x9d0 0x00000006 (SYMTAB) 0x4e0 0x0000000a (STRSZ) 1295 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000011 (REL) 0xee0 0x00000012 (RELSZ) 1664 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x00000016 (TEXTREL) 0x0 0x0000001e (FLAGS) TEXTREL 0x6ffffffa (RELCOUNT) 87 0x00000000 (NULL) 0x0 Running the same command on amd64 FreeBSD's version returns nothing. I have attached the result of `readelf -a ...` on both the i386 version and the amd64 version. > Second, from what you wrote, I see the issue in either wrong policy > being established in your project, or (another) mis-interpretation of > the policy. Indeed, having text relocations in the shared objects is > bad, because said relocations hinder text pages sharing. Relocated page= > is modified, so COW mechanism causes it to become private to process. I believe that relocations also cause the linker to work harder when the modules themselves are loaded the first time. They can also cause bugs when code is ported to another architecture. > On the other hand, there is only one instance of the loaded kernel modu= le, > its text segment (or section, for amd64) is not shared, so modification= s > to the text pages do not cause increased memory use. More, not compilin= g > modules with -fPIC (absence of -fPIC is what makes the text relocations= to > appear in the final link result) makes the code faster, esp. on i386. Compiling with -fPIC breaks the build. > So, there is nothing to report, and fix is outside the FreeBSD domain: > either fix your policy by not stating that text relocation in kernel > module is banned, or just find that policy only applicable to usermode > objects. Linux has no such text relocations in its modules. I have checked on both i386 and amd64. I have difficulty believing that FreeBSD needs text relocations when Linux does not. I am fairly certain that this is going to interfere with ASLR in the kernel, which is a security issue. It is definitely something to report. --------------080004000109050607090903 Content-Type: text/plain; name="readelf-gentoo-freebsd-i386" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="readelf-gentoo-freebsd-i386" ELF Header: Magic: 7f 45 4c 46 01 01 01 09 00 00 00 00 00 00 00 00=20 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - FreeBSD ABI Version: 0 Type: DYN (Shared object file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x1560 Start of program headers: 52 (bytes into file) Start of section headers: 12976 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 20 Section header string table index: 17 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk= Inf Al [ 0] NULL 00000000 000000 000000 00 0= 0 0 [ 1] .hash HASH 000000d4 0000d4 0003ac 04 A 3= 0 4 [ 2] .gnu.hash GNU_HASH 00000480 000480 000060 04 A 3= 0 4 [ 3] .dynsym DYNSYM 000004e0 0004e0 0004f0 10 A 4= 1 4 [ 4] .dynstr STRTAB 000009d0 0009d0 00050f 00 A 0= 0 1 [ 5] .rel.dyn REL 00000ee0 000ee0 000680 08 A 3= 0 4 [ 6] .text PROGBITS 00001560 001560 001318 00 AX 0= 0 32 [ 7] .rodata PROGBITS 00002878 002878 0002d6 01 AMS 0= 0 4 [ 8] set_modmetadata_s PROGBITS 00002b50 002b50 000010 00 A 0= 0 4 [ 9] set_sysinit_set PROGBITS 00002b60 002b60 000008 00 A 0= 0 4 [10] .eh_frame PROGBITS 00002b68 002b68 0003e0 00 A 0= 0 4 [11] .dynamic DYNAMIC 00003f6c 002f6c 000088 08 WA 4= 0 4 [12] .got.plt PROGBITS 00003ff4 002ff4 00000c 04 WA 0= 0 4 [13] .data PROGBITS 00004000 003000 000178 00 WA 0= 0 32 [14] .bss NOBITS 00004178 003178 00000c 00 WA 0= 0 4 [15] .comment PROGBITS 00000000 003178 00006c 01 MS 0= 0 1 [16] .gnu_debuglink PROGBITS 00000000 0031e4 00001c 00 0= 0 1 [17] .shstrtab STRTAB 00000000 003200 0000af 00 0= 0 1 [18] .symtab SYMTAB 00000000 0035d0 0008c0 10 19= 62 4 [19] .strtab STRTAB 00000000 003e90 000999 00 0= 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific= ) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align= LOAD 0x000000 0x00000000 0x00000000 0x02f48 0x02f48 R E 0x100= 0 LOAD 0x002f6c 0x00003f6c 0x00003f6c 0x0020c 0x00218 RW 0x100= 0 DYNAMIC 0x002f6c 0x00003f6c 0x00003f6c 0x00088 0x00088 RW 0x4 GNU_RELRO 0x002f6c 0x00003f6c 0x00003f6c 0x00094 0x00094 R 0x1 PAX_FLAGS 0x000000 0x00000000 0x00000000 0x00000 0x00000 0x4 Section to Segment mapping: Segment Sections... 00 .hash .gnu.hash .dynsym .dynstr .rel.dyn .text .rodata set_modm= etadata_set set_sysinit_set .eh_frame=20 01 .dynamic .got.plt .data .bss=20 02 .dynamic=20 03 .dynamic .got.plt=20 04 =20 Dynamic section at offset 0x2f6c contains 13 entries: Tag Type Name/Value 0x00000004 (HASH) 0xd4 0x6ffffef5 (GNU_HASH) 0x480 0x00000005 (STRTAB) 0x9d0 0x00000006 (SYMTAB) 0x4e0 0x0000000a (STRSZ) 1295 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000011 (REL) 0xee0 0x00000012 (RELSZ) 1664 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x00000016 (TEXTREL) 0x0 0x0000001e (FLAGS) TEXTREL 0x6ffffffa (RELCOUNT) 87 0x00000000 (NULL) 0x0 Relocation section '.rel.dyn' at offset 0xee0 contains 208 entries: Offset Info Type Sym.Value Sym. Name 00001625 00000008 R_386_RELATIVE =20 00001649 00000008 R_386_RELATIVE =20 000016a5 00000008 R_386_RELATIVE =20 000016c9 00000008 R_386_RELATIVE =20 00001804 00000008 R_386_RELATIVE =20 00001838 00000008 R_386_RELATIVE =20 0000191f 00000008 R_386_RELATIVE =20 00001b47 00000008 R_386_RELATIVE =20 00001bb5 00000008 R_386_RELATIVE =20 00001d25 00000008 R_386_RELATIVE =20 00001f2d 00000008 R_386_RELATIVE =20 00001f5f 00000008 R_386_RELATIVE =20 0000209a 00000008 R_386_RELATIVE =20 000020bc 00000008 R_386_RELATIVE =20 000020fe 00000008 R_386_RELATIVE =20 00002136 00000008 R_386_RELATIVE =20 00002176 00000008 R_386_RELATIVE =20 0000219a 00000008 R_386_RELATIVE =20 000021b4 00000008 R_386_RELATIVE =20 000021e2 00000008 R_386_RELATIVE =20 000021e9 00000008 R_386_RELATIVE =20 000021f0 00000008 R_386_RELATIVE =20 000021f7 00000008 R_386_RELATIVE =20 000021fe 00000008 R_386_RELATIVE =20 0000221c 00000008 R_386_RELATIVE =20 000022e2 00000008 R_386_RELATIVE =20 00002300 00000008 R_386_RELATIVE =20 00002327 00000008 R_386_RELATIVE =20 0000235c 00000008 R_386_RELATIVE =20 000023e9 00000008 R_386_RELATIVE =20 0000241a 00000008 R_386_RELATIVE =20 00002447 00000008 R_386_RELATIVE =20 000024a9 00000008 R_386_RELATIVE =20 000024f6 00000008 R_386_RELATIVE =20 00002510 00000008 R_386_RELATIVE =20 00002563 00000008 R_386_RELATIVE =20 000025c3 00000008 R_386_RELATIVE =20 00002601 00000008 R_386_RELATIVE =20 000026a1 00000008 R_386_RELATIVE =20 00002743 00000008 R_386_RELATIVE =20 00002778 00000008 R_386_RELATIVE =20 000027e6 00000008 R_386_RELATIVE =20 00002804 00000008 R_386_RELATIVE =20 00002816 00000008 R_386_RELATIVE =20 00002863 00000008 R_386_RELATIVE =20 0000286d 00000008 R_386_RELATIVE =20 00002b50 00000008 R_386_RELATIVE =20 00002b54 00000008 R_386_RELATIVE =20 00002b58 00000008 R_386_RELATIVE =20 00002b5c 00000008 R_386_RELATIVE =20 00002b60 00000008 R_386_RELATIVE =20 00002b64 00000008 R_386_RELATIVE =20 00004008 00000008 R_386_RELATIVE =20 00004014 00000008 R_386_RELATIVE =20 00004020 00000008 R_386_RELATIVE =20 0000402c 00000008 R_386_RELATIVE =20 00004038 00000008 R_386_RELATIVE =20 00004044 00000008 R_386_RELATIVE =20 00004050 00000008 R_386_RELATIVE =20 0000405c 00000008 R_386_RELATIVE =20 00004068 00000008 R_386_RELATIVE =20 00004080 00000008 R_386_RELATIVE =20 00004084 00000008 R_386_RELATIVE =20 00004090 00000008 R_386_RELATIVE =20 00004094 00000008 R_386_RELATIVE =20 000040a4 00000008 R_386_RELATIVE =20 000040b0 00000008 R_386_RELATIVE =20 000040b4 00000008 R_386_RELATIVE =20 000040c0 00000008 R_386_RELATIVE =20 000040c4 00000008 R_386_RELATIVE =20 000040d4 00000008 R_386_RELATIVE =20 000040e8 00000008 R_386_RELATIVE =20 000040f0 00000008 R_386_RELATIVE =20 00004100 00000008 R_386_RELATIVE =20 00004104 00000008 R_386_RELATIVE =20 00004108 00000008 R_386_RELATIVE =20 00004110 00000008 R_386_RELATIVE =20 00004114 00000008 R_386_RELATIVE =20 00004118 00000008 R_386_RELATIVE =20 00004120 00000008 R_386_RELATIVE =20 00004124 00000008 R_386_RELATIVE =20 00004144 00000008 R_386_RELATIVE =20 0000414c 00000008 R_386_RELATIVE =20 00004154 00000008 R_386_RELATIVE =20 0000415c 00000008 R_386_RELATIVE =20 00004164 00000008 R_386_RELATIVE =20 0000416c 00000008 R_386_RELATIVE =20 0000160d 00000202 R_386_PC32 00000000 device_get_softc 0000168d 00000202 R_386_PC32 00000000 device_get_softc 000017ef 00000202 R_386_PC32 00000000 device_get_softc 00001f03 00000202 R_386_PC32 00000000 device_get_softc 00001632 00001502 R_386_PC32 00000000 _mtx_lock_flags 000016b2 00001502 R_386_PC32 00000000 _mtx_lock_flags 00001814 00001502 R_386_PC32 00000000 _mtx_lock_flags 000023f9 00001502 R_386_PC32 00000000 _mtx_lock_flags 000025d3 00001502 R_386_PC32 00000000 _mtx_lock_flags 000026b1 00001502 R_386_PC32 00000000 _mtx_lock_flags 00001656 00002802 R_386_PC32 00000000 _mtx_unlock_flags 000016d6 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00001848 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00001bc5 00002802 R_386_PC32 00000000 _mtx_unlock_flags 0000242a 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00002611 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00002753 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00002788 00002802 R_386_PC32 00000000 _mtx_unlock_flags 00001715 00001d02 R_386_PC32 00000000 bzero 00001c40 00001d02 R_386_PC32 00000000 bzero 00001d08 00001d02 R_386_PC32 00000000 bzero 000023c1 00001d02 R_386_PC32 00000000 bzero 00001791 00002302 R_386_PC32 00000000 virtqueue_drain 000017b8 00003402 R_386_PC32 00000000 biofinish 000018b9 00003402 R_386_PC32 00000000 biofinish 000018eb 00003402 R_386_PC32 00000000 biofinish 000025f1 00003402 R_386_PC32 00000000 biofinish 0000264c 00003402 R_386_PC32 00000000 biofinish 0000266b 00003402 R_386_PC32 00000000 biofinish 00001820 00003302 R_386_PC32 00000000 device_is_attached 0000185e 00000502 R_386_PC32 00000000 taskqueue_drain 00001869 00002a02 R_386_PC32 00000000 taskqueue_free 000018d3 00004002 R_386_PC32 00000000 bioq_takefirst 00001de3 00004002 R_386_PC32 00000000 bioq_takefirst 000018f3 00004702 R_386_PC32 00000000 bioq_first 00001dab 00004702 R_386_PC32 00000000 bioq_first 0000192f 00004602 R_386_PC32 00000000 uma_zfree_arg 00001945 00003d02 R_386_PC32 00000000 disk_destroy 0000195b 00002202 R_386_PC32 00000000 sglist_free 0000196a 00001102 R_386_PC32 00000000 mtx_destroy 00001992 00003602 R_386_PC32 00000000 virtqueue_disable_intr 000019cf 00003602 R_386_PC32 00000000 virtqueue_disable_intr 00001c72 00003602 R_386_PC32 00000000 virtqueue_disable_intr 00001caa 00003602 R_386_PC32 00000000 virtqueue_disable_intr 00002764 00003602 R_386_PC32 00000000 virtqueue_disable_intr 0000199c 00003702 R_386_PC32 00000000 virtio_stop 00001c7c 00003702 R_386_PC32 00000000 virtio_stop 000019e1 00001f02 R_386_PC32 00000000 taskqueue_enqueue_fast 000027a2 00001f02 R_386_PC32 00000000 taskqueue_enqueue_fast 00001a30 00001202 R_386_PC32 00000000 sglist_append 00001a53 00001202 R_386_PC32 00000000 sglist_append 00001a92 00001202 R_386_PC32 00000000 sglist_append 00001a74 00003a02 R_386_PC32 00000000 virtqueue_enqueue 00001ad4 00004502 R_386_PC32 00000000 virtqueue_empty 00001b02 00002602 R_386_PC32 00000000 virtqueue_notify 00001e64 00002602 R_386_PC32 00000000 virtqueue_notify 00001b12 00000602 R_386_PC32 00000000 virtqueue_poll 00001b24 00003c01 R_386_32 00000000 bootverbose 00001b4f 00001402 R_386_PC32 00000000 device_printf 00002106 00001402 R_386_PC32 00000000 device_printf 00002143 00001402 R_386_PC32 00000000 device_printf 000021a7 00001402 R_386_PC32 00000000 device_printf 000021c1 00001402 R_386_PC32 00000000 device_printf 00002451 00001402 R_386_PC32 00000000 device_printf 000024c2 00001402 R_386_PC32 00000000 device_printf 00002503 00001402 R_386_PC32 00000000 device_printf 00002518 00001402 R_386_PC32 00000000 device_printf 00001c9e 00000102 R_386_PC32 00000000 virtio_reinit 00001cb2 00001702 R_386_PC32 00000000 virtio_reinit_complete 00001d2a 00002b02 R_386_PC32 00000000 panic 00001d90 00000902 R_386_PC32 00000000 virtqueue_full 00001ef2 00000b01 R_386_32 00000000 __stack_chk_guard 0000211b 00000b01 R_386_32 00000000 __stack_chk_guard 00001f0f 00001602 R_386_PC32 00000000 device_get_nameunit 00002092 00001602 R_386_PC32 00000000 device_get_nameunit 00002318 00001602 R_386_PC32 00000000 device_get_nameunit 00001f32 00001802 R_386_PC32 00000000 mtx_init 00001f3d 00001c02 R_386_PC32 00000000 bioq_init 00001f67 00002d02 R_386_PC32 00000000 virtio_set_feature_des 00001f81 00003002 R_386_PC32 00000000 virtio_negotiate_featu 00001f9f 00004402 R_386_PC32 00000000 virtio_with_feature 00001fbf 00004402 R_386_PC32 00000000 virtio_with_feature 00002002 00004402 R_386_PC32 00000000 virtio_with_feature 00002031 00004402 R_386_PC32 00000000 virtio_with_feature 0000224f 00004402 R_386_PC32 00000000 virtio_with_feature 00002292 00004402 R_386_PC32 00000000 virtio_with_feature 000022c4 00004402 R_386_PC32 00000000 virtio_with_feature 00001fea 00001902 R_386_PC32 00000000 virtio_read_device_con 00002076 00003b02 R_386_PC32 00000000 sglist_alloc 000020ae 00000a02 R_386_PC32 00000000 snprintf 000020f0 00004302 R_386_PC32 00000000 virtio_alloc_virtqueue 00002150 00001a02 R_386_PC32 00000000 virtqueue_size 0000218e 00001302 R_386_PC32 00000000 uma_zalloc_arg 000021d6 00003502 R_386_PC32 00000000 disk_alloc 00002206 00002702 R_386_PC32 00000000 device_get_unit 000022f1 00000d01 R_386_32 00000000 taskqueue_thread_enque 00002305 00003902 R_386_PC32 00000000 taskqueue_create_fast 0000233c 00003802 R_386_PC32 00000000 taskqueue_start_thread 0000234c 00003102 R_386_PC32 00000000 virtio_setup_intr 00002491 00001e02 R_386_PC32 00000000 __udivdi3 000024d2 00003202 R_386_PC32 00000000 disk_create 000024dd 00002402 R_386_PC32 00000000 virtqueue_enable_intr 0000272b 00002402 R_386_PC32 00000000 virtqueue_enable_intr 00002531 00002002 R_386_PC32 00000000 __stack_chk_fail 0000254c 00002102 R_386_PC32 00000000 virtio_get_device_type 0000256b 00000402 R_386_PC32 00000000 device_set_desc 0000262b 00001002 R_386_PC32 00000000 bioq_disksort 000026da 00000c02 R_386_PC32 00000000 biodone 000026f7 00002902 R_386_PC32 00000000 virtqueue_dequeue 000027ee 00002e02 R_386_PC32 00000000 uma_zone_get_cur 00002810 00000702 R_386_PC32 00000000 uma_zdestroy 00002868 00003f02 R_386_PC32 00000000 uma_zcreate 000040a0 00001b01 R_386_32 00000000 module_register_init 000040d0 00002c01 R_386_32 00000000 tunable_int_init 000040ec 00002501 R_386_32 00000000 driver_module_handler 00004140 00004201 R_386_32 00000000 device_probe_desc 00004148 00000f01 R_386_32 00000000 device_attach_desc 00004150 00003e01 R_386_32 00000000 device_detach_desc 00004158 00000801 R_386_32 00000000 device_suspend_desc 00004160 00002f01 R_386_32 00000000 device_resume_desc 00004168 00000301 R_386_32 00000000 device_shutdown_desc There are no unwind sections in this file. Symbol table '.dynsym' contains 79 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND=20 1: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit 2: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_softc 3: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_shutdown_desc 4: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_set_desc 5: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_drain 6: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_poll 7: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zdestroy 8: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_suspend_desc 9: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_full 10: 00000000 0 NOTYPE GLOBAL DEFAULT UND snprintf 11: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_guard 12: 00000000 0 NOTYPE GLOBAL DEFAULT UND biodone 13: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_thread_enque= ue 14: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stop_set_pcpu 15: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_attach_desc 16: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_disksort 17: 00000000 0 NOTYPE GLOBAL DEFAULT UND mtx_destroy 18: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_append 19: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zalloc_arg 20: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_printf 21: 00000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_lock_flags 22: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_nameunit 23: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit_complete= 24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mtx_init 25: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_read_device_con= fig 26: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_size 27: 00000000 0 NOTYPE GLOBAL DEFAULT UND module_register_init 28: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_init 29: 00000000 0 NOTYPE GLOBAL DEFAULT UND bzero 30: 00000000 0 NOTYPE GLOBAL DEFAULT UND __udivdi3 31: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_enqueue_fast= 32: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fail 33: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_get_device_type= 34: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_free 35: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_drain 36: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enable_intr 37: 00000000 0 NOTYPE GLOBAL DEFAULT UND driver_module_handler 38: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_notify 39: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_unit 40: 00000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_unlock_flags 41: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_dequeue 42: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_free 43: 00000000 0 NOTYPE GLOBAL DEFAULT UND panic 44: 00000000 0 NOTYPE GLOBAL DEFAULT UND tunable_int_init 45: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_set_feature_des= c 46: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zone_get_cur 47: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_resume_desc 48: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_negotiate_featu= res 49: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_setup_intr 50: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_create 51: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_is_attached 52: 00000000 0 NOTYPE GLOBAL DEFAULT UND biofinish 53: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_alloc 54: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_disable_intr= 55: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_stop 56: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_start_thread= s 57: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_create_fast 58: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enqueue 59: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_alloc 60: 00000000 0 NOTYPE GLOBAL DEFAULT UND bootverbose 61: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_destroy 62: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_detach_desc 63: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zcreate 64: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_takefirst 65: 00000000 0 NOTYPE GLOBAL DEFAULT UND __start_set_pcpu 66: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_probe_desc 67: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_alloc_virtqueue= s 68: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_with_feature 69: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_empty 70: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zfree_arg 71: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_first 72: 00002b50 0 NOTYPE GLOBAL DEFAULT ABS __start_set_modmetadat= a_s 73: 00004178 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 74: 00004178 0 NOTYPE GLOBAL DEFAULT ABS _edata 75: 00002b68 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_sysinit_set= 76: 00004184 0 NOTYPE GLOBAL DEFAULT ABS _end 77: 00002b60 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_modmetadata= _se 78: 00002b60 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sysinit_se= t Symbol table '.symtab' contains 140 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND=20 1: 00001560 3 FUNC LOCAL DEFAULT 6 vtblk_shutdown 2: 00001580 33 FUNC LOCAL DEFAULT 6 vtblk_open 3: 000015c0 17 FUNC LOCAL DEFAULT 6 vtblk_close 4: 000015e0 20 FUNC LOCAL DEFAULT 6 vtblk_ioctl 5: 00001600 98 FUNC LOCAL DEFAULT 6 vtblk_resume 6: 00001680 98 FUNC LOCAL DEFAULT 6 vtblk_suspend 7: 00001700 85 FUNC LOCAL DEFAULT 6 vtblk_enqueue_request 8: 00001760 106 FUNC LOCAL DEFAULT 6 vtblk_drain_vq 9: 000017e0 453 FUNC LOCAL DEFAULT 6 vtblk_detach 10: 0000417c 4 OBJECT LOCAL DEFAULT 14 vtblk_req_zone 11: 000019c0 47 FUNC LOCAL DEFAULT 6 vtblk_vq_intr 12: 00001a00 165 FUNC LOCAL DEFAULT 6 vtblk_execute_request 13: 00001ac0 153 FUNC LOCAL DEFAULT 6 vtblk_poll_request 14: 00001b60 462 FUNC LOCAL DEFAULT 6 vtblk_dump 15: 00001d40 394 FUNC LOCAL DEFAULT 6 vtblk_startio 16: 00001ee0 1621 FUNC LOCAL DEFAULT 6 vtblk_attach 17: 00004000 120 OBJECT LOCAL DEFAULT 13 vtblk_feature_desc 18: 00002580 241 FUNC LOCAL DEFAULT 6 vtblk_strategy 19: 00002680 304 FUNC LOCAL DEFAULT 6 vtblk_intr_task 20: 00004178 4 OBJECT LOCAL DEFAULT 14 vtblk_no_ident 21: 00002540 54 FUNC LOCAL DEFAULT 6 vtblk_probe 22: 000027c0 184 FUNC LOCAL DEFAULT 6 vtblk_modevent 23: 00002b50 4 OBJECT LOCAL DEFAULT 8 __set_modmetadata_set_= sym 24: 00004078 16 OBJECT LOCAL DEFAULT 13 _mod_metadata_md_virti= o_b 25: 00002b54 4 OBJECT LOCAL DEFAULT 8 __set_modmetadata_set_= sym 26: 00004088 16 OBJECT LOCAL DEFAULT 13 _mod_metadata_virtio_b= lk_ 27: 00002b60 4 OBJECT LOCAL DEFAULT 9 __set_sysinit_set_sym_= vir 28: 00004098 16 OBJECT LOCAL DEFAULT 13 virtio_blk_virtio_pcim= odu 29: 00002b58 4 OBJECT LOCAL DEFAULT 8 __set_modmetadata_set_= sym 30: 000040a8 16 OBJECT LOCAL DEFAULT 13 _mod_metadata_md_virti= o_b 31: 00002b5c 4 OBJECT LOCAL DEFAULT 8 __set_modmetadata_set_= sym 32: 000040b8 16 OBJECT LOCAL DEFAULT 13 _mod_metadata_md_virti= o_b 33: 00002b64 4 OBJECT LOCAL DEFAULT 9 __set_sysinit_set_sym_= __T 34: 000040c8 16 OBJECT LOCAL DEFAULT 13 __Tunable_init_168_sys= _in 35: 000040d8 12 OBJECT LOCAL DEFAULT 13 _virtio_blk_depend_on_= vir 36: 000040e4 4 OBJECT LOCAL DEFAULT 13 _virtio_blk_version 37: 000040e8 12 OBJECT LOCAL DEFAULT 13 virtio_blk_virtio_pci_= mod 38: 000040f4 12 OBJECT LOCAL DEFAULT 13 _virtio_blk_virtio_pci= _de 39: 00004100 8 OBJECT LOCAL DEFAULT 13 __tunable_int_168 40: 00004108 24 OBJECT LOCAL DEFAULT 13 virtio_blk_virtio_pci_= dri 41: 00004120 24 OBJECT LOCAL DEFAULT 13 vtblk_driver 42: 00004180 4 OBJECT LOCAL DEFAULT 14 vtblk_devclass 43: 00004140 56 OBJECT LOCAL DEFAULT 13 vtblk_methods 44: 00003f6c 0 OBJECT LOCAL HIDDEN ABS _DYNAMIC 45: 00003ff4 0 OBJECT LOCAL HIDDEN ABS _GLOBAL_OFFSET_TABLE_ 46: 000000d4 0 SECTION LOCAL DEFAULT 1=20 47: 00000480 0 SECTION LOCAL DEFAULT 2=20 48: 000004e0 0 SECTION LOCAL DEFAULT 3=20 49: 000009d0 0 SECTION LOCAL DEFAULT 4=20 50: 00000ee0 0 SECTION LOCAL DEFAULT 5=20 51: 00001560 0 SECTION LOCAL DEFAULT 6=20 52: 00002878 0 SECTION LOCAL DEFAULT 7=20 53: 00002b50 0 SECTION LOCAL DEFAULT 8=20 54: 00002b60 0 SECTION LOCAL DEFAULT 9=20 55: 00002b68 0 SECTION LOCAL DEFAULT 10=20 56: 00003f6c 0 SECTION LOCAL DEFAULT 11=20 57: 00003ff4 0 SECTION LOCAL DEFAULT 12=20 58: 00004000 0 SECTION LOCAL DEFAULT 13=20 59: 00004178 0 SECTION LOCAL DEFAULT 14=20 60: 00000000 0 SECTION LOCAL DEFAULT 15=20 61: 00000000 0 SECTION LOCAL DEFAULT 16=20 62: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit 63: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_softc 64: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_shutdown_desc 65: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_set_desc 66: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_drain 67: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_poll 68: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zdestroy 69: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_suspend_desc 70: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_full 71: 00000000 0 NOTYPE GLOBAL DEFAULT UND snprintf 72: 00002b50 0 NOTYPE GLOBAL DEFAULT ABS __start_set_modmetadat= a_s 73: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_guard 74: 00000000 0 NOTYPE GLOBAL DEFAULT UND biodone 75: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_thread_enque= ue 76: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stop_set_pcpu 77: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_attach_desc 78: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_disksort 79: 00000000 0 NOTYPE GLOBAL DEFAULT UND mtx_destroy 80: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_append 81: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zalloc_arg 82: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_printf 83: 00000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_lock_flags 84: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_nameunit 85: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit_complete= 86: 00000000 0 NOTYPE GLOBAL DEFAULT UND mtx_init 87: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_read_device_con= fig 88: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_size 89: 00000000 0 NOTYPE GLOBAL DEFAULT UND module_register_init 90: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_init 91: 00000000 0 NOTYPE GLOBAL DEFAULT UND bzero 92: 00000000 0 NOTYPE GLOBAL DEFAULT UND __udivdi3 93: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_enqueue_fast= 94: 00000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fail 95: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_get_device_type= 96: 00002b68 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_sysinit_set= 97: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_free 98: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_drain 99: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enable_intr 100: 00000000 0 NOTYPE GLOBAL DEFAULT UND driver_module_handler 101: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_notify 102: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_get_unit 103: 00000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_unlock_flags 104: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_dequeue 105: 00002b60 0 NOTYPE GLOBAL DEFAULT ABS __start_set_sysinit_se= t 106: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_free 107: 00000000 0 NOTYPE GLOBAL DEFAULT UND panic 108: 00000000 0 NOTYPE GLOBAL DEFAULT UND tunable_int_init 109: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_set_feature_des= c 110: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zone_get_cur 111: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_resume_desc 112: 00004178 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 113: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_negotiate_featu= res 114: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_setup_intr 115: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_create 116: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_is_attached 117: 00000000 0 NOTYPE GLOBAL DEFAULT UND biofinish 118: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_alloc 119: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_disable_intr= 120: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_stop 121: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_start_thread= s 122: 00000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_create_fast 123: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enqueue 124: 00000000 0 NOTYPE GLOBAL DEFAULT UND sglist_alloc 125: 00000000 0 NOTYPE GLOBAL DEFAULT UND bootverbose 126: 00004178 0 NOTYPE GLOBAL DEFAULT ABS _edata 127: 00004184 0 NOTYPE GLOBAL DEFAULT ABS _end 128: 00000000 0 NOTYPE GLOBAL DEFAULT UND disk_destroy 129: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_detach_desc 130: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zcreate 131: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_takefirst 132: 00000000 0 NOTYPE GLOBAL DEFAULT UND __start_set_pcpu 133: 00000000 0 NOTYPE GLOBAL DEFAULT UND device_probe_desc 134: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_alloc_virtqueue= s 135: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtio_with_feature 136: 00002b60 0 NOTYPE GLOBAL DEFAULT ABS __stop_set_modmetadata= _se 137: 00000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_empty 138: 00000000 0 NOTYPE GLOBAL DEFAULT UND uma_zfree_arg 139: 00000000 0 NOTYPE GLOBAL DEFAULT UND bioq_first Histogram for bucket list length (total of 154 buckets): Length Number % of total Coverage 0 91 ( 59.1%) 1 48 ( 31.2%) 61.5% 2 15 ( 9.7%) 100.0% Histogram for `.gnu.hash' bucket list length (total of 11 buckets): Length Number % of total Coverage 0 5 ( 45.5%) 1 5 ( 45.5%) 71.4% 2 1 ( 9.1%) 100.0% No version information found in this file. --------------080004000109050607090903 Content-Type: text/plain; name="readelf-upstream-freebsd-amd64" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="readelf-upstream-freebsd-amd64" ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00=20 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - FreeBSD ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 6504 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 18 Section header string table index: 15 Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000000000 00000040 000000000000120e 0000000000000000 AX 0 0 16 [ 2] .rela.text RELA 0000000000000000 000033e8 0000000000000e28 0000000000000018 16 1 8 [ 3] .rodata.str1.8 PROGBITS 0000000000000000 00001250 0000000000000145 0000000000000001 AMS 0 0 8 [ 4] .rodata.str1.1 PROGBITS 0000000000000000 00001395 00000000000001a0 0000000000000001 AMS 0 0 1 [ 5] set_modmetadata_s PROGBITS 0000000000000000 00001538 0000000000000020 0000000000000000 A 0 0 8 [ 6] .relaset_modmetad RELA 0000000000000000 00004210 0000000000000060 0000000000000018 16 5 8 [ 7] set_sysinit_set PROGBITS 0000000000000000 00001558 0000000000000010 0000000000000000 A 0 0 8 [ 8] .relaset_sysinit_ RELA 0000000000000000 00004270 0000000000000030 0000000000000018 16 7 8 [ 9] .data PROGBITS 0000000000000000 00001580 00000000000002b0 0000000000000000 WA 0 0 32 [10] .rela.data RELA 0000000000000000 000042a0 0000000000000420 0000000000000018 16 9 8 [11] .bss NOBITS 0000000000000000 00001830 0000000000000018 0000000000000000 WA 0 0 8 [12] .comment PROGBITS 0000000000000000 00001830 000000000000006f 0000000000000000 0 0 1 [13] .note.GNU-stack PROGBITS 0000000000000000 0000189f 0000000000000000 0000000000000000 0 0 1 [14] .gnu_debuglink PROGBITS 0000000000000000 0000189f 000000000000001c 0000000000000000 0 0 1 [15] .shstrtab STRTAB 0000000000000000 000018bb 00000000000000aa 0000000000000000 0 0 1 [16] .symtab SYMTAB 0000000000000000 00001de8 0000000000000c60 0000000000000018 17 58 8 [17] .strtab STRTAB 0000000000000000 00002a48 000000000000099d 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific= ) There are no section groups in this file. There are no program headers in this file. Relocation section '.rela.text' at offset 0x33e8 contains 151 entries: Offset Info Type Sym. Value Sym. Name += Addend 000000000122 003b00000002 R_X86_64_PC32 0000000000000000 device_get_= softc - 4 000000000135 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 00000000013f 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 000000000152 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000000159 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 000000000182 003b00000002 R_X86_64_PC32 0000000000000000 device_get_= softc - 4 000000000195 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 00000000019f 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 0000000001b2 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 0000000001b9 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 0000000001e1 007100000002 R_X86_64_PC32 0000000000000000 virtqueue_d= isable_intr - 4 000000000220 005700000002 R_X86_64_PC32 0000000000000000 bzero - 4 0000000002ba 005d00000002 R_X86_64_PC32 0000000000000000 virtqueue_d= rain - 4 0000000002ff 003b00000002 R_X86_64_PC32 0000000000000000 device_get_= softc - 4 000000000314 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 00000000031c 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 00000000032a 006e00000002 R_X86_64_PC32 0000000000000000 device_is_a= ttached - 4 000000000343 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000000348 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 000000000362 003e00000002 R_X86_64_PC32 0000000000000000 taskqueue_d= rain - 4 00000000036f 006500000002 R_X86_64_PC32 0000000000000000 taskqueue_f= ree - 4 0000000003c5 008300000002 R_X86_64_PC32 0000000000000000 bioq_first = - 4 0000000003d4 007b00000002 R_X86_64_PC32 0000000000000000 bioq_takefi= rst - 4 0000000003e9 008300000002 R_X86_64_PC32 0000000000000000 bioq_first = - 4 000000000411 000500000002 R_X86_64_PC32 0000000000000000 .bss + 4 000000000416 008200000002 R_X86_64_PC32 0000000000000000 uma_zfree_a= rg - 4 000000000432 007800000002 R_X86_64_PC32 0000000000000000 disk_destro= y - 4 00000000044a 005c00000002 R_X86_64_PC32 0000000000000000 sglist_free= - 4 00000000045b 004b00000002 R_X86_64_PC32 0000000000000000 mtx_destroy= - 4 000000000491 007100000002 R_X86_64_PC32 0000000000000000 virtqueue_d= isable_intr - 4 0000000004a4 005800000002 R_X86_64_PC32 0000000000000000 taskqueue_e= nqueue_fast - 4 0000000004f8 004c00000002 R_X86_64_PC32 0000000000000000 sglist_appe= nd - 4 00000000051b 004c00000002 R_X86_64_PC32 0000000000000000 sglist_appe= nd - 4 00000000055e 004c00000002 R_X86_64_PC32 0000000000000000 sglist_appe= nd - 4 0000000005a3 008100000002 R_X86_64_PC32 0000000000000000 virtqueue_e= mpty - 4 0000000005da 006000000002 R_X86_64_PC32 0000000000000000 virtqueue_n= otify - 4 0000000005e4 003f00000002 R_X86_64_PC32 0000000000000000 virtqueue_p= oll - 4 000000000601 007700000002 R_X86_64_PC32 0000000000000000 bootverbose= - 4 00000000060f 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 68 000000000619 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000685 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 00000000068c 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 0000000006db 003a00000002 R_X86_64_PC32 0000000000000000 virtio_rein= it - 4 0000000006ef 007100000002 R_X86_64_PC32 0000000000000000 virtqueue_d= isable_intr - 4 0000000006f7 005100000002 R_X86_64_PC32 0000000000000000 virtio_rein= it_complete - 4 000000000751 005700000002 R_X86_64_PC32 0000000000000000 bzero - 4 0000000007c4 005700000002 R_X86_64_PC32 0000000000000000 bzero - 4 0000000007e9 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 90 0000000007f0 006600000002 R_X86_64_PC32 0000000000000000 panic - 4 000000000851 004200000002 R_X86_64_PC32 0000000000000000 virtqueue_f= ull - 4 000000000871 008300000002 R_X86_64_PC32 0000000000000000 bioq_first = - 4 000000000896 007b00000002 R_X86_64_PC32 0000000000000000 bioq_takefi= rst - 4 0000000009db 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 0000000009e3 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 000000000a12 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000000a28 004a00000002 R_X86_64_PC32 0000000000000000 bioq_diskso= rt - 4 000000000a6a 004500000002 R_X86_64_PC32 0000000000000000 __stack_chk= _guard - 4 000000000a75 003b00000002 R_X86_64_PC32 0000000000000000 device_get_= softc - 4 000000000a87 005000000002 R_X86_64_PC32 0000000000000000 device_get_= nameunit - 4 000000000a90 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 0 000000000a9b 005200000002 R_X86_64_PC32 0000000000000000 mtx_init - = 4 000000000aa4 005600000002 R_X86_64_PC32 0000000000000000 bioq_init -= 4 000000000aaf 00040000000b R_X86_64_32S 0000000000000000 .data + 0 000000000adc 006800000002 R_X86_64_PC32 0000000000000000 virtio_set_= feature_des - 4 000000000aea 006b00000002 R_X86_64_PC32 0000000000000000 virtio_nego= tiate_featu - 4 000000000afb 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000b11 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000b30 005300000002 R_X86_64_PC32 0000000000000000 virtio_read= _device_con - 4 000000000b3d 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000b5f 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000b7d 007600000002 R_X86_64_PC32 0000000000000000 sglist_allo= c - 4 000000000b9a 005000000002 R_X86_64_PC32 0000000000000000 device_get_= nameunit - 4 000000000ba7 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 23 000000000bb3 004300000002 R_X86_64_PC32 0000000000000000 snprintf - = 4 000000000bcf 00010000000b R_X86_64_32S 0000000000000000 .text + 480= 000000000be3 007e00000002 R_X86_64_PC32 0000000000000000 virtio_allo= c_virtqueue - 4 000000000bf0 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 2e 000000000bfa 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000c0d 004500000002 R_X86_64_PC32 0000000000000000 __stack_chk= _guard - 4 000000000c69 005400000002 R_X86_64_PC32 0000000000000000 virtqueue_s= ize - 4 000000000ca0 000500000002 R_X86_64_PC32 0000000000000000 .bss + 4 000000000cac 004d00000002 R_X86_64_PC32 0000000000000000 uma_zalloc_= arg - 4 000000000cb8 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 49 000000000cc7 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000cd3 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + c0 000000000ce2 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000cfc 007000000002 R_X86_64_PC32 0000000000000000 disk_alloc = - 4 000000000d0b 00010000000b R_X86_64_32S 0000000000000000 .text + 10 000000000d13 00010000000b R_X86_64_32S 0000000000000000 .text + 40 000000000d1b 00010000000b R_X86_64_32S 0000000000000000 .text + 60 000000000d26 00010000000b R_X86_64_32S 0000000000000000 .text + 990= 000000000d2e 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + b3 000000000d33 006100000002 R_X86_64_PC32 0000000000000000 device_get_= unit - 4 000000000d4c 00010000000b R_X86_64_32S 0000000000000000 .text + 620= 000000000d68 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000da8 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000dcd 007f00000002 R_X86_64_PC32 0000000000000000 virtio_with= _feature - 4 000000000dfb 00010000000b R_X86_64_32S 0000000000000000 .text + 100= 0 000000000e09 00470000000b R_X86_64_32S 0000000000000000 taskqueue_t= hread_enque + 0 000000000e18 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 66 000000000e1d 007400000002 R_X86_64_PC32 0000000000000000 taskqueue_c= reate_fast - 4 000000000e35 005000000002 R_X86_64_PC32 0000000000000000 device_get_= nameunit - 4 000000000e42 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 8d 000000000e53 007300000002 R_X86_64_PC32 0000000000000000 taskqueue_s= tart_thread - 4 000000000e60 006c00000002 R_X86_64_PC32 0000000000000000 virtio_setu= p_intr - 4 000000000e70 000500000002 R_X86_64_PC32 0000000000000000 .bss - 4 000000000ea1 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 96 000000000eab 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000eb8 006d00000002 R_X86_64_PC32 0000000000000000 disk_create= - 4 000000000ec1 005e00000002 R_X86_64_PC32 0000000000000000 virtqueue_e= nable_intr - 4 000000000ecd 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + b 000000000eda 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000ef2 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + f8 000000000efc 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000f08 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + 72 000000000f15 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000f5c 005700000002 R_X86_64_PC32 0000000000000000 bzero - 4 000000000f6f 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000000f92 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 000000000fa4 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000000fb9 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 000000000fe3 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 120 000000000fea 004e00000002 R_X86_64_PC32 0000000000000000 device_prin= tf - 4 000000000ff4 005900000002 R_X86_64_PC32 0000000000000000 __stack_chk= _fail - 4 00000000100b 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 000000001028 004f00000002 R_X86_64_PC32 0000000000000000 _mtx_lock_f= lags - 4 000000001044 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 00000000105b 004600000002 R_X86_64_PC32 0000000000000000 biodone - 4= 000000001070 006300000002 R_X86_64_PC32 0000000000000000 virtqueue_d= equeue - 4 0000000010ac 005e00000002 R_X86_64_PC32 0000000000000000 virtqueue_e= nable_intr - 4 0000000010bd 007100000002 R_X86_64_PC32 0000000000000000 virtqueue_d= isable_intr - 4 0000000010ce 00020000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.8 + 0 0000000010d3 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 00000000110d 005a00000002 R_X86_64_PC32 0000000000000000 virtio_get_= device_type - 4 00000000112a 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + b8 00000000112f 003d00000002 R_X86_64_PC32 0000000000000000 device_set_= desc - 4 000000001183 000500000002 R_X86_64_PC32 0000000000000000 .bss + 4 000000001188 006900000002 R_X86_64_PC32 0000000000000000 uma_zone_ge= t_cur - 4 0000000011d5 00030000000b R_X86_64_32S 0000000000000000 .rodata.str= 1.1 + cd 0000000011da 007a00000002 R_X86_64_PC32 0000000000000000 uma_zcreate= - 4 0000000011e1 000500000002 R_X86_64_PC32 0000000000000000 .bss + 4 0000000011f3 000500000002 R_X86_64_PC32 0000000000000000 .bss + 4 0000000011f8 004000000002 R_X86_64_PC32 0000000000000000 uma_zdestro= y - 4 000000001201 000500000002 R_X86_64_PC32 0000000000000000 .bss + 0 0000000001ef 007200000002 R_X86_64_PC32 0000000000000000 virtio_stop= - 4 00000000027a 006f00000002 R_X86_64_PC32 0000000000000000 biofinish -= 4 000000000548 007500000002 R_X86_64_PC32 0000000000000000 virtqueue_e= nqueue - 4 00000000093b 006000000002 R_X86_64_PC32 0000000000000000 virtqueue_n= otify - 4 000000000a19 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 00000000104e 006200000002 R_X86_64_PC32 0000000000000000 _mtx_unlock= _flags - 4 0000000010f0 005800000002 R_X86_64_PC32 0000000000000000 taskqueue_e= nqueue_fast - 4 Relocation section '.relaset_modmetadata_set' at offset 0x4210 contains 4= entries: Offset Info Type Sym. Value Sym. Name += Addend 000000000000 000400000001 R_X86_64_64 0000000000000000 .data + a0 000000000008 000400000001 R_X86_64_64 0000000000000000 .data + c0 000000000010 000400000001 R_X86_64_64 0000000000000000 .data + 100= 000000000018 000400000001 R_X86_64_64 0000000000000000 .data + 120= Relocation section '.relaset_sysinit_set' at offset 0x4270 contains 2 ent= ries: Offset Info Type Sym. Value Sym. Name += Addend 000000000000 000400000001 R_X86_64_64 0000000000000000 .data + e0 000000000008 000400000001 R_X86_64_64 0000000000000000 .data + 140= Relocation section '.rela.data' at offset 0x42a0 contains 44 entries: Offset Info Type Sym. Value Sym. Name += Addend 000000000008 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + db 000000000018 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + e7 000000000028 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + f2 000000000038 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + fd 000000000048 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 10a 000000000058 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 113 000000000068 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 11d 000000000078 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 126 000000000088 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 12f 0000000000a8 000400000001 R_X86_64_64 0000000000000000 .data + 158= 0000000000b0 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 138 0000000000c8 000400000001 R_X86_64_64 0000000000000000 .data + 164= 0000000000d0 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 13f 0000000000e8 005500000001 R_X86_64_64 0000000000000000 module_regi= ster_init + 0 0000000000f0 000400000001 R_X86_64_64 0000000000000000 .data + 170= 000000000108 000400000001 R_X86_64_64 0000000000000000 .data + 170= 000000000110 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 14a 000000000128 000400000001 R_X86_64_64 0000000000000000 .data + 188= 000000000130 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 160 000000000148 006700000001 R_X86_64_64 0000000000000000 tunable_int= _init + 0 000000000150 000400000001 R_X86_64_64 0000000000000000 .data + 1a0= 000000000170 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 167 000000000178 005f00000001 R_X86_64_64 0000000000000000 driver_modu= le_handler + 0 000000000180 000400000001 R_X86_64_64 0000000000000000 .data + 1c0= 0000000001a0 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 17d 0000000001a8 000500000001 R_X86_64_64 0000000000000000 .bss + 0 0000000001c0 000100000001 R_X86_64_64 0000000000000000 .text + 115= 0 0000000001d0 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 18f 0000000001d8 000400000001 R_X86_64_64 0000000000000000 .data + 200= 0000000001e0 000500000001 R_X86_64_64 0000000000000000 .bss + 10 000000000200 000300000001 R_X86_64_64 0000000000000000 .rodata.str= 1.1 + 19a 000000000208 000400000001 R_X86_64_64 0000000000000000 .data + 240= 000000000240 007d00000001 R_X86_64_64 0000000000000000 device_prob= e_desc + 0 000000000248 000100000001 R_X86_64_64 0000000000000000 .text + 110= 0 000000000250 004900000001 R_X86_64_64 0000000000000000 device_atta= ch_desc + 0 000000000258 000100000001 R_X86_64_64 0000000000000000 .text + a50= 000000000260 007900000001 R_X86_64_64 0000000000000000 device_deta= ch_desc + 0 000000000268 000100000001 R_X86_64_64 0000000000000000 .text + 2f0= 000000000270 004100000001 R_X86_64_64 0000000000000000 device_susp= end_desc + 0 000000000278 000100000001 R_X86_64_64 0000000000000000 .text + 170= 000000000280 006a00000001 R_X86_64_64 0000000000000000 device_resu= me_desc + 0 000000000288 000100000001 R_X86_64_64 0000000000000000 .text + 110= 000000000290 003c00000001 R_X86_64_64 0000000000000000 device_shut= down_desc + 0 000000000298 000100000001 R_X86_64_64 0000000000000000 .text + 0 There are no unwind sections in this file. Symbol table '.symtab' contains 132 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND=20 1: 0000000000000000 0 SECTION LOCAL DEFAULT 1=20 2: 0000000000000000 0 SECTION LOCAL DEFAULT 3=20 3: 0000000000000000 0 SECTION LOCAL DEFAULT 4=20 4: 0000000000000000 0 SECTION LOCAL DEFAULT 9=20 5: 0000000000000000 0 SECTION LOCAL DEFAULT 11=20 6: 0000000000000000 8 FUNC LOCAL DEFAULT 1 vtblk_shutdown= 7: 0000000000000010 39 FUNC LOCAL DEFAULT 1 vtblk_open 8: 0000000000000040 19 FUNC LOCAL DEFAULT 1 vtblk_close 9: 0000000000000060 22 FUNC LOCAL DEFAULT 1 vtblk_ioctl 10: 0000000000000080 62 FUNC LOCAL DEFAULT 1 vtblk_dequeue_= request 11: 00000000000000c0 65 FUNC LOCAL DEFAULT 1 vtblk_dequeue_= ready 12: 0000000000000110 90 FUNC LOCAL DEFAULT 1 vtblk_resume 13: 0000000000000170 90 FUNC LOCAL DEFAULT 1 vtblk_suspend 14: 00000000000001d0 35 FUNC LOCAL DEFAULT 1 vtblk_stop 15: 0000000000000200 99 FUNC LOCAL DEFAULT 1 vtblk_enqueue_= request 16: 0000000000000270 14 FUNC LOCAL DEFAULT 1 vtblk_bio_erro= r 17: 0000000000000280 106 FUNC LOCAL DEFAULT 1 vtblk_drain_vq= 18: 00000000000002f0 391 FUNC LOCAL DEFAULT 1 vtblk_detach 19: 0000000000000008 8 OBJECT LOCAL DEFAULT 11 vtblk_req_zone= 20: 0000000000000480 52 FUNC LOCAL DEFAULT 1 vtblk_vq_intr 21: 00000000000004c0 176 FUNC LOCAL DEFAULT 1 vtblk_execute_= request 22: 0000000000000570 175 FUNC LOCAL DEFAULT 1 vtblk_poll_req= uest 23: 0000000000000620 468 FUNC LOCAL DEFAULT 1 vtblk_dump 24: 0000000000000800 389 FUNC LOCAL DEFAULT 1 vtblk_startio 25: 0000000000000990 192 FUNC LOCAL DEFAULT 1 vtblk_strategy= 26: 0000000000000a50 1448 FUNC LOCAL DEFAULT 1 vtblk_attach 27: 0000000000000000 160 OBJECT LOCAL DEFAULT 9 vtblk_feature_= desc 28: 0000000000001000 244 FUNC LOCAL DEFAULT 1 vtblk_intr_tas= k 29: 0000000000000000 4 OBJECT LOCAL DEFAULT 11 vtblk_no_ident= 30: 0000000000001100 65 FUNC LOCAL DEFAULT 1 vtblk_probe 31: 0000000000001150 190 FUNC LOCAL DEFAULT 1 vtblk_modevent= 32: 0000000000000000 8 OBJECT LOCAL DEFAULT 5 __set_modmetad= ata_set_sym 33: 00000000000000a0 24 OBJECT LOCAL DEFAULT 9 _mod_metadata_= md_virtio_b 34: 0000000000000008 8 OBJECT LOCAL DEFAULT 5 __set_modmetad= ata_set_sym 35: 00000000000000c0 24 OBJECT LOCAL DEFAULT 9 _mod_metadata_= virtio_blk_ 36: 0000000000000000 8 OBJECT LOCAL DEFAULT 7 __set_sysinit_= set_sym_vir 37: 00000000000000e0 24 OBJECT LOCAL DEFAULT 9 virtio_blk_vir= tio_pcimodu 38: 0000000000000010 8 OBJECT LOCAL DEFAULT 5 __set_modmetad= ata_set_sym 39: 0000000000000100 24 OBJECT LOCAL DEFAULT 9 _mod_metadata_= md_virtio_b 40: 0000000000000018 8 OBJECT LOCAL DEFAULT 5 __set_modmetad= ata_set_sym 41: 0000000000000120 24 OBJECT LOCAL DEFAULT 9 _mod_metadata_= md_virtio_b 42: 0000000000000008 8 OBJECT LOCAL DEFAULT 7 __set_sysinit_= set_sym___T 43: 0000000000000140 24 OBJECT LOCAL DEFAULT 9 __Tunable_init= _168_sys_in 44: 0000000000000158 12 OBJECT LOCAL DEFAULT 9 _virtio_blk_de= pend_on_vir 45: 0000000000000164 4 OBJECT LOCAL DEFAULT 9 _virtio_blk_ve= rsion 46: 0000000000000170 24 OBJECT LOCAL DEFAULT 9 virtio_blk_vir= tio_pci_mod 47: 0000000000000188 12 OBJECT LOCAL DEFAULT 9 _virtio_blk_vi= rtio_pci_de 48: 00000000000001a0 16 OBJECT LOCAL DEFAULT 9 __tunable_int_= 168 49: 00000000000001c0 48 OBJECT LOCAL DEFAULT 9 virtio_blk_vir= tio_pci_dri 50: 0000000000000200 48 OBJECT LOCAL DEFAULT 9 vtblk_driver 51: 0000000000000010 8 OBJECT LOCAL DEFAULT 11 vtblk_devclass= 52: 0000000000000240 112 OBJECT LOCAL DEFAULT 9 vtblk_methods 53: 0000000000000000 0 SECTION LOCAL DEFAULT 5=20 54: 0000000000000000 0 SECTION LOCAL DEFAULT 7=20 55: 0000000000000000 0 SECTION LOCAL DEFAULT 12=20 56: 0000000000000000 0 SECTION LOCAL DEFAULT 13=20 57: 0000000000000000 0 SECTION LOCAL DEFAULT 14=20 58: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit 59: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_get_sof= tc 60: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_shutdow= n_desc 61: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_set_des= c 62: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_drai= n 63: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_poll= 64: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND uma_zdestroy 65: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_suspend= _desc 66: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_full= 67: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND snprintf 68: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __start_set_mo= dmetadata_s 69: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_gu= ard 70: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND biodone 71: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_thre= ad_enqueue 72: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stop_set_pcp= u 73: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_attach_= desc 74: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bioq_disksort 75: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND mtx_destroy 76: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sglist_append 77: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND uma_zalloc_arg= 78: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_printf 79: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_lock_flag= s 80: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_get_nam= eunit 81: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_reinit_= complete 82: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND mtx_init 83: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_read_de= vice_config 84: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_size= 85: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND module_registe= r_init 86: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bioq_init 87: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bzero 88: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_enqu= eue_fast 89: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stack_chk_fa= il 90: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_get_dev= ice_type 91: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stop_set_sys= init_set 92: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sglist_free 93: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_drai= n 94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enab= le_intr 95: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND driver_module_= handler 96: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_noti= fy 97: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_get_uni= t 98: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _mtx_unlock_fl= ags 99: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_dequ= eue 100: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __start_set_sy= sinit_set 101: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_free= 102: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND panic 103: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND tunable_int_in= it 104: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_set_fea= ture_desc 105: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND uma_zone_get_c= ur 106: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_resume_= desc 107: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_negotia= te_features 108: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_setup_i= ntr 109: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND disk_create 110: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_is_atta= ched 111: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND biofinish 112: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND disk_alloc 113: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_disa= ble_intr 114: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_stop 115: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_star= t_threads 116: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND taskqueue_crea= te_fast 117: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_enqu= eue 118: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND sglist_alloc 119: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bootverbose 120: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND disk_destroy 121: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_detach_= desc 122: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND uma_zcreate 123: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bioq_takefirst= 124: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __start_set_pc= pu 125: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND device_probe_d= esc 126: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_alloc_v= irtqueues 127: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtio_with_fe= ature 128: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __stop_set_mod= metadata_se 129: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND virtqueue_empt= y 130: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND uma_zfree_arg 131: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bioq_first No version information found in this file. --------------080004000109050607090903-- --------------enigA748CAFEF5F455A00C0C8AE8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdjUVAAoJELFAT5FmjZuEtw0QAJkkOecOQ/4cBrjqGvG9HxLV W+WuqV3eegfP+u6yUwZQLr20wLVnIwT7c3x7fnOxuYYA84s7zVkmIZ3Sz/QJqho7 4mihzSfOK1+xIUQfdMvLVzXg1IGVLaYG5ScKzCV+hYmgrRl1fvAoD/q3+3KFuMR+ pVlD+Ohdyz36tGlibAULd0v99mRrZXzj1m/2Me8I3Hf6UKYub+S7JubVa49jMidA ARX2MxdmYukho/uw51g4rXGhtWsdq29K7YhZoNgtZVVJsBN2BR3i7utAgglKX63U sR2HizAON9+KHCoV+g7yQXzGS7ng63kc2kjWdZYCO5svngvSO9aLZrH4aJ7YI3KY TrXb6KysjaBpfF4BJGHKdmUKjD8tLKFbH1nd/2BnB9islfhy99Yaul0O8oOlwkSU NkJiMYom2r01Ns3SpuQIKzjfK3kytmkKZnWrK/t3NchdOtPTgvjWStKpqIVyBPl+ PGtzP8V+STydZvoX8xyPulyA7ctb3ro33iWHfMU/DD1E4tlnsfHP9EARtpctUCxy uJzGl/cgAHuKSRE+BBTFWoIDpdpsAKzwyEl3T14RiHyzTcAn3PJG725SKNVQl2RJ /M2LlPp0Vu9jQpGrt1OxlCI5VEI58Vs37fPcg4veLmuBDOZYlUMOMJqrsolyPET5 il9sX/EcfeHecDpclWI1 =EBFF -----END PGP SIGNATURE----- --------------enigA748CAFEF5F455A00C0C8AE8-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 22:46:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54B40106566C for ; Fri, 30 Mar 2012 22:46:39 +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 DDB978FC16 for ; Fri, 30 Mar 2012 22:46:38 +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 q2UMkVfJ069396; Sat, 31 Mar 2012 01:46:31 +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 q2UMkVxq027384; Sat, 31 Mar 2012 01:46:31 +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 q2UMkVnf027383; Sat, 31 Mar 2012 01:46:31 +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: Sat, 31 Mar 2012 01:46:31 +0300 From: Konstantin Belousov To: Richard Yao Message-ID: <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//MD+r6UUJvz0X/C" Content-Disposition: inline In-Reply-To: <4F76350F.8000708@cs.stonybrook.edu> 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-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:46:39 -0000 --//MD+r6UUJvz0X/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2012 at 06:34:55PM -0400, Richard Yao wrote: > On 03/30/12 16:36, Konstantin Belousov wrote: > > First, there _are_ relocations against text in the amd64 modules, but I > > suspect that your scripts do not detect this. Most likely, scripts look > > for DT_TEXTREL dynamic tag, and tags are only present in the executables > > or shared objects, not in the object files. The amd64 modules are object > > files, so you just mis-interpret the situation. >=20 > readelf is a part of binutils. It is not a script. Here is the version > that Gentoo/FreeBSD uses: So you completely missed what I told you. >=20 > # readelf --version > GNU readelf (GNU Binutils) 2.20.1.20100303 > Copyright 2009 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) any later > version. > This program has absolutely no warranty. >=20 > In addition, this is what it says when I ask it to look at virtio_blk.ko: >=20 > # readelf -d /boot/modules/virtio_blk.ko >=20 > Dynamic section at offset 0x2f6c contains 13 entries: > Tag Type Name/Value > 0x00000004 (HASH) 0xd4 > 0x6ffffef5 (GNU_HASH) 0x480 > 0x00000005 (STRTAB) 0x9d0 > 0x00000006 (SYMTAB) 0x4e0 > 0x0000000a (STRSZ) 1295 (bytes) > 0x0000000b (SYMENT) 16 (bytes) > 0x00000011 (REL) 0xee0 > 0x00000012 (RELSZ) 1664 (bytes) > 0x00000013 (RELENT) 8 (bytes) > 0x00000016 (TEXTREL) 0x0 > 0x0000001e (FLAGS) TEXTREL > 0x6ffffffa (RELCOUNT) 87 > 0x00000000 (NULL) 0x0 >=20 > Running the same command on amd64 FreeBSD's version returns nothing. I > have attached the result of `readelf -a ...` on both the i386 version > and the amd64 version. Reread what I wrote to you. Also, it pays off learning how ELF works before making conclusion from the absence of the output of readelf -d. Amd64 modules _are not_ shared objects. >=20 > > Second, from what you wrote, I see the issue in either wrong policy > > being established in your project, or (another) mis-interpretation of > > the policy. Indeed, having text relocations in the shared objects is > > bad, because said relocations hinder text pages sharing. Relocated page > > is modified, so COW mechanism causes it to become private to process. >=20 > I believe that relocations also cause the linker to work harder when the > modules themselves are loaded the first time. They can also cause bugs > when code is ported to another architecture. I can only answer that this is your fantasy, however ample. I see that conversation is going nowhere, I will not reply further. >=20 > > On the other hand, there is only one instance of the loaded kernel modu= le, > > its text segment (or section, for amd64) is not shared, so modifications > > to the text pages do not cause increased memory use. More, not compiling > > modules with -fPIC (absence of -fPIC is what makes the text relocations= to > > appear in the final link result) makes the code faster, esp. on i386. >=20 > Compiling with -fPIC breaks the build. >=20 > > So, there is nothing to report, and fix is outside the FreeBSD domain: > > either fix your policy by not stating that text relocation in kernel > > module is banned, or just find that policy only applicable to usermode > > objects. >=20 > Linux has no such text relocations in its modules. I have checked on > both i386 and amd64. I have difficulty believing that FreeBSD needs text > relocations when Linux does not. >=20 > I am fairly certain that this is going to interfere with ASLR in the > kernel, which is a security issue. It is definitely something to report. --//MD+r6UUJvz0X/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk92N8cACgkQC3+MBN1Mb4i32wCeILV0GitT3U/Z5bgGfdyecQ8K MdcAoM9n3gz5fZBqoupD0SJdSGDOEvcf =CXW4 -----END PGP SIGNATURE----- --//MD+r6UUJvz0X/C-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 22:49:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47293106564A for ; Fri, 30 Mar 2012 22:49:01 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id DFBF28FC16 for ; Fri, 30 Mar 2012 22:49:00 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 18:48:58 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 18:49:00 -0400 Message-ID: <4F7637F3.2060502@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 18:47:15 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Konstantin Belousov References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1A225317806B90D4877912FC" X-Originating-IP: [72.89.250.133] Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:49:01 -0000 --------------enig1A225317806B90D4877912FC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 18:46, Konstantin Belousov wrote: > Reread what I wrote to you. Also, it pays off learning how ELF works > before making conclusion from the absence of the output of readelf -d. > Amd64 modules _are not_ shared objects. Whether or not they are shared objects is irrelevant. The fact is that they have text relocations, which interfere with ASLR. Do I need to produce exploit code before you take me seriously? --------------enig1A225317806B90D4877912FC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdjf2AAoJELFAT5FmjZuEp4QP/2BpjIDJku1yxnrZA0E3QH31 u1VD3UCWcVZfk9q/HaCO8UCcUYZjN8ehVBfmenEFaOB0J0mXz42rvgdZD4iNDyEo ykhIOadc4kSycpfCaD7/0hquqbXlxLWLOVzkNP9xXthZfLZ6hP6w9J2M9F0koWoY P+MV33PznHa/5s+QV7oQfw/amlufQ2YlwSfBC+Bh4twcCXdUX7HvO+AG+1RVi6a6 60s/PgOC52k5hmyo1H3tbkufsxXcPowVYzaoYlms4h2IuaUvwScsz05YRggg28sH 6ukRkzeZgYE72Q6hBtJfVVu9eEUPik8mchBUQ/io1Nv0oA12aD1kRlRv3k94uWbX 7ILd1xNzTb11bGxpFXpHXLOBuCVyd0fYhcyLYARJIDz9GTm6fAdnquKj4w6Cad7J M6/PzlBdFvmt7p/bG7Llk/QMGaQyPX5bwIpM49ti6lUIxrDbOcxtlPkD3bxFANeB PP4zopHCiSPJQXxdKT/RdXKN52N5fAcFCBkJgx2hCxrdnWPnAsJJuy2vv7FfplwO KRw7MuIsn4iXM1nNWdgKzMf8yxae077KD97Xhh3x0sDYMsXv29uOd4xLABHnc57V XOf/gtnz8UGGyllhqWsMut2vL2ZtTWiKrXYzR0paDJx3Hrc+0/gBncss/pErpc8D yO1Ca7ysyJV6TLPAUltS =zqaZ -----END PGP SIGNATURE----- --------------enig1A225317806B90D4877912FC-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 22:52:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24151106566B for ; Fri, 30 Mar 2012 22:52:01 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 6603F8FC17 for ; Fri, 30 Mar 2012 22:51:59 +0000 (UTC) Received: (qmail 78919 invoked by uid 907); 30 Mar 2012 22:51:58 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.100]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 31 Mar 2012 09:51:58 +1100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jan Mikkelsen In-Reply-To: <201203302221.q2UML7O2055021@ambrisko.com> Date: Sat, 31 Mar 2012 09:52:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A241FF0-6CB6-430B-877A-46E7982F7149@transactionware.com> References: <201203302221.q2UML7O2055021@ambrisko.com> To: Doug Ambrisko X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:52:01 -0000 On 31/03/2012, at 9:21 AM, Doug Ambrisko wrote: > Jan Mikkelsen writes: > | I don't know what changes Sean did. Are they in 9.0-release, or do I=20= > | need -stable after a certain point? I'm assuming I should be able to=20= > | take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current. >=20 > It's in the SVN project/head_mfi repro. You can browse it via the web = at: > http://svnweb.freebsd.org/base/projects/head_mfi/ >=20 > It's not in -current yet. I'm working on the. I just did all the > merges to a look try and eye'd them over. Now doing a compile test > then I can check it into -current. OK, will check it out. > | The performance is an interesting thing. The write performance I = care=20 > | about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) = on=20 > | this controller. The 9261 with a BBU performs well but obviously = costs more. >=20 > There will need to be clarification in the future. JBOD is not that > same as a single disk RAID. If I remember correctly, when doing some > JBOD testing version single disk RAID is that JBOD is slower. A=20 > single disk RAID is faster since it can use the RAID. However, = without > the battery then you risk losing data on power outage etc. Without = the > battery then performance of a JBOD and single disk RAID should be able > the same. >=20 > A real JBOD as shown by LSI's firmware etc. shows up as a = /dev/mfisyspd > entries. JBOD by LSI is a newer thing. Ok, interesting. I was told by the distributor that the 9240 supports = JBOD mode, but the 9261 doesn't. I'm interested to test it out with ZFS. >=20 > | I can see the BBU being important for controller based raid5, but = I'm=20 > | hoping that ZFS with JBOD will still perform well. I'm ignorant at = this=20 > | point, so that's why I'm trying it out. Do you have any experience = or=20 > | expectations with a 9240 being used in a setup like that? >=20 > The battery or NVRAM doesn't matter on the RAID type being used since = the > cache in NVRAM mode, says done whenever it has space in the cache for = the > write. Eventually, it will hit the disk. Without the cache working = in > this mode the write can't be acknowledged until the disk says done. = So > performance suffers. With a single disk RAID you have been using the > cache. With RAID-5 it is important because a single update requires two writes = and a failure in the window where one write has completed and one write = has not could cause data corruption. I don't know whether the controller = really handles this case. I guess I'm hopeful that ZFS will perform the function performed by the = NVRAM on the controller. I can see how the controller in isolation is = clearly slower without a BBU because it has to expose the higher layers = to the disk latency. > Now you can force using the cache without NVRAM but you have to = acknowledge > the risk of that. Yes, I understand the risk, and it is one I do not want to take. All the = 9261s I have deployed have a BBU and go into write through mode if the = battery has a problem. I think I need to test it in the context of ZFS and see how it works = without controller NVRAM. Regards, Jan. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 30 23:24:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28FF1065672; Fri, 30 Mar 2012 23:24:05 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 9982E8FC08; Fri, 30 Mar 2012 23:24:05 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 30 Mar 2012 16:24:11 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2UNO3bg064760; Fri, 30 Mar 2012 16:24:03 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2UNO3bI064753; Fri, 30 Mar 2012 16:24:03 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203302324.q2UNO3bI064753@ambrisko.com> In-Reply-To: <2A241FF0-6CB6-430B-877A-46E7982F7149@transactionware.com> To: Jan Mikkelsen Date: Fri, 30 Mar 2012 16:24:03 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 23:24:05 -0000 Jan Mikkelsen writes: | On 31/03/2012, at 9:21 AM, Doug Ambrisko wrote: | | > Jan Mikkelsen writes: | > | I don't know what changes Sean did. Are they in 9.0-release, or do I | > | need -stable after a certain point? I'm assuming I should be able to | > | take src/sys/dev/mfi/... and src/usr.sbin/mfiutil/... from -current. | > | > It's in the SVN project/head_mfi repro. You can browse it via the web at: | > http://svnweb.freebsd.org/base/projects/head_mfi/ | > | > It's not in -current yet. I'm working on the. I just did all the | > merges to a look try and eye'd them over. Now doing a compile test | > then I can check it into -current. | | OK, will check it out. | | > | The performance is an interesting thing. The write performance I care | > | about is ZFS raidz2 with 6 x JBOD disks (or 6 x single disk raid0) on | > | this controller. The 9261 with a BBU performs well but obviously costs more. | > | > There will need to be clarification in the future. JBOD is not that | > same as a single disk RAID. If I remember correctly, when doing some | > JBOD testing version single disk RAID is that JBOD is slower. A | > single disk RAID is faster since it can use the RAID. However, without | > the battery then you risk losing data on power outage etc. Without the | > battery then performance of a JBOD and single disk RAID should be able | > the same. | > | > A real JBOD as shown by LSI's firmware etc. shows up as a /dev/mfisyspd | > entries. JBOD by LSI is a newer thing. | | Ok, interesting. I was told by the distributor that the 9240 supports | JBOD mode, but the 9261 doesn't. I'm interested to test it out with ZFS. Correct, JBOD is not supported on all cards and depending on how the card comes needs to be enabled. Again JBOD is not RAID on a single disk. Also to clarify mfiutil create jbod does a RAID for each drive which isn't the same definition of JBOD that LSI talks about. They are 2 different animals. MegaCli can configure LSI JBOD's to enable the feature and create them. I'm not really sure what the value of JBOD support is. I haven't seen any kind of performance gains. | > | I can see the BBU being important for controller based raid5, but I'm | > | hoping that ZFS with JBOD will still perform well. I'm ignorant at this | > | point, so that's why I'm trying it out. Do you have any experience or | > | expectations with a 9240 being used in a setup like that? | > | > The battery or NVRAM doesn't matter on the RAID type being used since the | > cache in NVRAM mode, says done whenever it has space in the cache for the | > write. Eventually, it will hit the disk. Without the cache working in | > this mode the write can't be acknowledged until the disk says done. So | > performance suffers. With a single disk RAID you have been using the | > cache. | | With RAID-5 it is important because a single update requires two writes | and a failure in the window where one write has completed and one write | has not could cause data corruption. I don't know whether the controller | really handles this case. That shouldn't be a problem since the acknowledge won't happen until the writes are all done and if any fail then the I/O should fail back to the OS. | I guess I'm hopeful that ZFS will perform the function performed by the | NVRAM on the controller. I can see how the controller in isolation is | clearly slower without a BBU because it has to expose the higher layers | to the disk latency. All the ZFS should really be doing is adding another level of caching. Without an NVRAM cache, you can't really get the performance gain. | > Now you can force using the cache without NVRAM but you have to acknowledge | > the risk of that. | | Yes, I understand the risk, and it is one I do not want to take. All | the 9261s I have deployed have a BBU and go into write through mode if | the battery has a problem. | | I think I need to test it in the context of ZFS and see how it works | without controller NVRAM. Well, then you can do the performance test of the 9240 on the 9261s by disabling the battery and the cache! Feel free to do the test on the 9240. I can't see anything being faster without the NVRAM cache. Doug A. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 00:01:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B6DE106566C for ; Sat, 31 Mar 2012 00:01:29 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 1F01A8FC19 for ; Sat, 31 Mar 2012 00:01:27 +0000 (UTC) Received: (qmail 82484 invoked by uid 907); 31 Mar 2012 00:01:23 -0000 Received: from eth222.nsw.adsl.internode.on.net (HELO [192.168.1.100]) (150.101.196.221) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 31 Mar 2012 11:01:23 +1100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jan Mikkelsen In-Reply-To: <201203302324.q2UNO3bI064753@ambrisko.com> Date: Sat, 31 Mar 2012 11:01:44 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C3D20D2-74BB-455D-9A45-BFFBCE1C5868@transactionware.com> References: <201203302324.q2UNO3bI064753@ambrisko.com> To: Doug Ambrisko X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: LSI MegaRAID SAS 9240 with mfi driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 00:01:29 -0000 On 31/03/2012, at 10:24 AM, Doug Ambrisko wrote: > Well, then you can do the performance test of the 9240 on the 9261s > by disabling the battery and the cache! Feel free to do the test on > the 9240. I can't see anything being faster without the NVRAM cache. The other critical part of the test was making sure the 9240 worked with = FreeBSD! On performance and NVRAM, yes, agree on disabling the cache in the 9261 = to figure out how is will basically perform. Still interested to give = the JBOD mode a try with ZFS. Thanks, Jan. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 02:02:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC9E106566C for ; Sat, 31 Mar 2012 02:02:30 +0000 (UTC) (envelope-from matt.thyer@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 E97678FC12 for ; Sat, 31 Mar 2012 02:02:29 +0000 (UTC) Received: by wern13 with SMTP id n13so897083wer.13 for ; Fri, 30 Mar 2012 19:02:28 -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=tk1JsGpRg2m4yqHCThWjQ/ey0gVebZQ+yGK78lnppyk=; b=pfRaom17SuSrbXxO+7wjjWXwiQYgmD9Xjia4O0YifD3MTHrzVEfWjdOB5XnKSjsI7C cvTmGylt8fl5q913yVGNKd7/O1HUwdAKWiGYxVilRmJxnedbUJdv2f+vtb2NAa7KPfoS c6wc1KBLQ0YB9N4BF668Xs3yrjXK49f/hzQ0O1h/7TqJCTW7rUolRNQMmHEhX+eQsFZ/ /GZ+01qbZV25wagy5/rDYgx0cPL+cAjALKM1rpDlQERK+cVakB0jKMTmKEF4B2kPgLsk 7vhCLStKaqXZl38TixgKpvVKRkEoDAhN1QUQzuHyodYAS5LHEhJjZe03q1YIr+1wd8Qi 4Zyw== MIME-Version: 1.0 Received: by 10.180.20.47 with SMTP id k15mr1954389wie.19.1333159348544; Fri, 30 Mar 2012 19:02:28 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 30 Mar 2012 19:02:28 -0700 (PDT) Received: by 10.216.190.219 with HTTP; Fri, 30 Mar 2012 19:02:28 -0700 (PDT) In-Reply-To: <4F75FC5E.5020303@gmail.com> References: <4F735CEC.5060101@gmail.com> <4F75FC5E.5020303@gmail.com> Date: Sat, 31 Mar 2012 12:32:28 +1030 Message-ID: From: Matt Thyer To: Jim Bryant Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: ESCape codes displayed instead of processed in pager X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:02:30 -0000 On Mar 31, 2012 5:02 AM, "Jim Bryant" @ gmail.com > wrote: > > Matt Thyer wrote: > >> >> On Mar 29, 2012 5:18 AM, "Jim Bryant" @ gmail.com @ gmail.com >> wrote: >> > >> > Ever since I have upgraded to 9-stable, I have noticed that the manpages seem to be munged up with displayed instead of processed ESCape codes. >> >> I believe that this is due to the terminal type of the console changing from "cons25" to "xterm". If you fix your /etc/ttys to reflect this things should be OK. >> > 1:27:57pm argus(19): tty > /dev/pts/7 > 1:28:03pm argus(20): setenv TERM xterm > 1:28:05pm argus(21): man man > > MAN(1) FreeBSD General Commands Manual MAN(1) > > ESC[1mNAMEESC[0m > ESC[1mman ESC[22m-- display online manual documentation pages > > same thing going on. that's after switching every vty and the console to xterm in /etc/ttys as well. > > i'm kinda lost on this one. i have determined that somehow, it's the pager... hang on a sec... lemme try vi. > > vi seems to be working properly... it's not the termcap/terminfo... the only thing causing this seems to be more and less, both. > > when i pipe man into cat, everything gets properly interpreted by the tty/vty/pty, when i use the pager, i get this crap....argh.. > Some suggestions: Test with a clean environment (most easily done by creating a new user account). If that doesn't fix it then you have a problem with your upgrade that may be fixed by mergemaster. You may need to back up your data and do a clean install. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 02:15:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A87E1065674 for ; Sat, 31 Mar 2012 02:15:50 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 332828FC14 for ; Sat, 31 Mar 2012 02:15:50 +0000 (UTC) Received: by iahk25 with SMTP id k25so2319577iah.13 for ; Fri, 30 Mar 2012 19:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NzdTflizNmXcZWPr8CKNuA+RkizWijLcywOWyUznScQ=; b=b2b9DpsYPTgpLI+XZ5gR/XuE8oUn9UHucjgXLF0RFgrJaZqq3SaDQe9hbhQXwxwYkY am9k5zo6TsZis9k4EkcuyE7HCvqOHs0HYMVKskkP886WXz+PYBPvb3FYY/IcfgH/8teA lph3xzVAwxlXumKuWgjCunVtsr5nrB8scXNS8= 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=NzdTflizNmXcZWPr8CKNuA+RkizWijLcywOWyUznScQ=; b=Vv4p6rOJA9J6B9wDNh7UZZXA9vLgPOrb8QNx/5c1uHTYN8zPKfAfaGPoqbT1Oeea4a FtZCK3Bjv5CGQa9PnLYQsG7aFuNJnioiKPB+CmKS6KsjRYbw9P2cLbPTVrSnM85Cihns AkSduBehMeUmu8m7x1Yxgu+YIZJWRpvdFQmjwpl3gMt4DxJq4PrQxgQaRxHce2WdQSz0 Z3ufHQjjnQivQjT3TGRNofhHjXQtwKCXzQkbz13u9huW5DtDMlWP8Whr+8oevvekE3YC IFshMdVgO/EXLoyehZCGevof+dVL6Xu0iSqWp81Sbr9Xdwpng2Zk7eZ8y0n2hfik1rU8 kseA== MIME-Version: 1.0 Received: by 10.50.216.132 with SMTP id oq4mr495210igc.6.1333160149570; Fri, 30 Mar 2012 19:15:49 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Fri, 30 Mar 2012 19:15:49 -0700 (PDT) In-Reply-To: <4F7637F3.2060502@cs.stonybrook.edu> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 19:15:49 -0700 Message-ID: From: Peter Wemm To: Richard Yao Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmDUjY/5TTLEW3LYv4Al75me0BodOwdWuGAYauGqfCWoNCHjT+KwpmEbQrxRY6n1kVrUJwb Cc: Konstantin Belousov , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:15:50 -0000 On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao wrote: > On 03/30/12 18:46, Konstantin Belousov wrote: >> Reread what I wrote to you. Also, it pays off learning how ELF works >> before making conclusion from the absence of the output of readelf -d. >> Amd64 modules _are not_ shared objects. > > Whether or not they are shared objects is irrelevant. The fact is that > they have text relocations, which interfere with ASLR. Do I need to > produce exploit code before you take me seriously? > I am the person who wrote it and deliberately chose to cause text relocations to be generated on i386. It is by design, not a bug. All of your concerns are perfectly valid if they were for userland. For the record, our amd64 modules ALSO do this, but your tools simply do not detect it. Here is what happens, and here is why it is not a problem: When you compile with -fpic on an architecture that doesn't support PC-relative addressing adequately, the compiler generates code to do indirect memory references via the global offset table. This is so that all the relocations can be collected into a single location in order to not dirty the MAP_PRIVATE data pages. example: if there is an function at 0x12345, and another function in a different .so file that wants to call it at 0x22345, then the call instruction would have to be relocated. The asm instructions would look like: 0xE8FFEFFFFF (offset is -0x10000) If the same .so file was loaded in another user process at 0x32345, then the relocation would be different. An entire page would be dirtied by the dynamic linker so that the second instance of the .so file had 0xE8FFDFFFFF (-0x20000). This is a waste of memory and causes a storm of VM faults at startup. Instead, the code is compiled with -fPIC, which causes an extra memory reference via the global offset table. Instead of the relocations being spread over the text segment, the relocations are in a single page. The dynamic linker has to dirty one page only in order to set up a whole host of relocations. The cost is i386 doesn't have native pc-relative mode, so it has to waste an entire register. We dedicate one of the 6 general purpose registers which costs a hefty performance hit. This is why crypto code tends to be compiled without -fpic, for example. For KERNEL modules, all this changes. In userland, there is a dynamic linker. In the kernel, there is none. In userland, the .so files are mapped with mmap(MAP_PRIVATE), the kernel does not use mmap and always uses a private copy. In userland, the .so files are shared, the kernel NEVER shares them. In userland, doing a relocation causes a copy on write fault, this never happens to the kernel because its using private, exclusive malloc() pages. In userland, we make the performance tradeoff from -fpic in order to share memory pages, the kernel never shares pages so -fpic is a waste. In userland, ASLR has security benefits. The kernel already does this.. if you load a module on one machine it'll ALWAYS be at different address space compared to another. In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non pic .o files into a container that was more convenient at the time to parse. There is no global-offset-table. In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same non-pic code into a less convenient form that we can feed back into the linker if we wish. There is no global offset table. Both i386 and amd64 use raw relocations, regardless of where the came from. Text, data, anywhere. This has nothing to do with ASLR, because they are kernel objects, not shared libraries. You posted: * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. The key here is "dynamic linker". There is no dynamic linker to process this stuff. This is simply a tools problem on your end. It's not a bug. There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. I have given you a detailed explanation of why it's not a problem. If you want to continue, then reply with details, not hearsay or theories. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 02:37:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8CF6C106564A for ; Sat, 31 Mar 2012 02:37:04 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 43B6C8FC0A for ; Sat, 31 Mar 2012 02:37:04 +0000 (UTC) Received: by iahk25 with SMTP id k25so2337238iah.13 for ; Fri, 30 Mar 2012 19:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2FM2LsrOUvB4nKpQrv1qLV8r+ED14PuOtd/FAa+wnX0=; b=1WYEx7esJeoA96uyVE+bXRmiFFwx5OoTbhiupPCTLkVrNweDFLiypHKwkKZw/iAQ8z uRrTYFxFkv9nC+1HLFxBjKImSk3MDBi1Y72e+08PuIsAB+/kWIPebcXgsJKDclRBOfc9 +uds7vJ0Dl4IaeS7T/KfA71JmJMwEQ2N5HdHo= 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=2FM2LsrOUvB4nKpQrv1qLV8r+ED14PuOtd/FAa+wnX0=; b=OP6R4p9Ls+QfjWilHpnig6/nQzx6EWXXtUnD5ByBHxIcPSI6bcTktjRFQbUYK3S1qB po7gXh6XLgzTjs0zdBkEAqfQNdSd8HujM+hcRkfob9Of1n0gqMXbY53nPhiM+qWiscxh MSj+htACdM0BHRGl2Zl/2EgsL/jPI8PPJor//hNxjeC6wKyWV3eLJ8LL3X1M1DqGr5oK AgsKx0pOUrmgtp0AK8ivo/yy25O6DOSwZqYLmWb7dOjinjc0rUsRmQTXgFDvVZmmPYNG qRJwVEYOBJh9u0ULCtcUR8lSBhzJqEbi0u3DjHGkdZZ4QQ2IuM9Ly7cKhhJ8KQ9WcR/n BZGA== MIME-Version: 1.0 Received: by 10.50.219.200 with SMTP id pq8mr520226igc.6.1333161423886; Fri, 30 Mar 2012 19:37:03 -0700 (PDT) Received: by 10.231.172.138 with HTTP; Fri, 30 Mar 2012 19:37:03 -0700 (PDT) In-Reply-To: <20120331015112.GA37889@neutralgood.org> References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> <20120331015112.GA37889@neutralgood.org> Date: Fri, 30 Mar 2012 19:37:03 -0700 Message-ID: From: Peter Wemm To: kpneal@pobox.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmuWvU204Wk+3ptMdYbGbNufalCqjBHNbnutrd3MoF0Vf4HbjEBaf0zBZVWFhipST/Nuo1z Cc: freebsd-stable@freebsd.org, Richard Yao Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:37:04 -0000 On Fri, Mar 30, 2012 at 6:51 PM, wrote: > On Fri, Mar 30, 2012 at 06:47:15PM -0400, Richard Yao wrote: >> On 03/30/12 18:46, Konstantin Belousov wrote: >> > Reread what I wrote to you. Also, it pays off learning how ELF works >> > before making conclusion from the absence of the output of readelf -d. >> > Amd64 modules _are not_ shared objects. >> >> Whether or not they are shared objects is irrelevant. The fact is that >> they have text relocations, which interfere with ASLR. Do I need to >> produce exploit code before you take me seriously? > > Any time you have any reference from a single compilation's object module > to any code or data in a different compilation you need some way for one > object to find that code/data. > > Think about it: if a function call is going to branch to another function > it needs to know the address of the target function. How can it get this > target address? Relocations. > > Now, move up a bit to kernel objects which typically consist of multiple > compilations all linked together. If a function in a kernel object wants > to call a function in the main part of the kernel it needs the address. > How can it get this target address? Relocations. > > When code is linked together into a single file it is possible to have > compilations have patched into them the offsets to functions or data from > other compilations. But this only works when the relative locations are > fixed. > > If you want different kernel objects to get random addresses when loaded > at run time then you _must_ have some way for the kernel object to call > back into the main kernel. It is possible to, at the C language level, > pass around structs holding pointers to functions and pointers to data. > But this does the same thing as relocations and it does it less efficiently. When a chunk of code is compiled with -fpic, function calls are produced with a special relocation type. When it is linked, all these calls are gathered into an indirect PLT (procedure linkage table). In userland, the PLT is dirtied at startup and varies depending on the random load address. But all the indirect calls are PC-relative to the PLT. eg: if the kernel bzero is at 0xc0201230, and we load a .ko file at 0xc100000 which has three "call bzero" references, then: -fpic case: all three calls to bzero will pc-relative "call" a slot in the PLT, which is resolved and created at "ld -shared" time, which will be run time relocated to "jmp 0xc0201230". ie: "call bzero@PLT" -> "jmp bzero" -> bzero() non-fpic case: each instance of the three "call bzero" will be relocated without making an indirect bounce through the PLT, which we don't need. ie: "call bzero" -> bzero() there would be three symbol lookups at .ko load time instead of one. The big difference (besides the loss of the %ebx register) is those extra memory hits to do a bzero(), that are paid for every single time. Meanwhile the non-pic case has an up-front cost of invoking some extremely unoptimized code at load time and never has the runtime overhead. Linux doesn't use 'ld -shared' format. They used something vaguely like what we did with the old LKM system, ie: running ld incrementally and loading the results. That was a long time ago, but they sure don't take the overhead of PLT/GOT/-fpic mode either. There's just no need. We provoke a warning on the gentoo tools on i386 because we simply used 'ld -shared' output as a container or transport. We use a different format by default on amd64, but the code is generated exactly the same way as on i386 and has exactly the same relocations in the same places. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 02:44:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C580D106564A for ; Sat, 31 Mar 2012 02:44:39 +0000 (UTC) (envelope-from ryao@cs.stonybrook.edu) Received: from edge1.cs.stonybrook.edu (edge1.cs.stonybrook.edu [130.245.9.210]) by mx1.freebsd.org (Postfix) with ESMTP id 589B68FC0A for ; Sat, 31 Mar 2012 02:44:38 +0000 (UTC) Received: from HUBCAS1.cs.stonybrook.edu (130.245.9.206) by edge1.cs.stonybrook.edu (130.245.9.210) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 30 Mar 2012 22:44:33 -0400 Received: from [192.168.1.2] (72.89.250.133) by hubcas1.cs.stonybrook.edu (130.245.9.212) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 22:44:36 -0400 Message-ID: <4F766F29.2030803@cs.stonybrook.edu> Date: Fri, 30 Mar 2012 22:42:49 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120301 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Wemm References: <4F75E404.8000104@cs.stonybrook.edu> <4F75EF86.6090909@cs.stonybrook.edu> <20120330190713.GG2358@deviant.kiev.zoral.com.ua> <4F760C9E.6060405@cs.stonybrook.edu> <20120330194649.GH2358@deviant.kiev.zoral.com.ua> <4F761371.7020606@cs.stonybrook.edu> <20120330203605.GI2358@deviant.kiev.zoral.com.ua> <4F76350F.8000708@cs.stonybrook.edu> <20120330224631.GJ2358@deviant.kiev.zoral.com.ua> <4F7637F3.2060502@cs.stonybrook.edu> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEABF9CB5010413DE1E789077" X-Originating-IP: [72.89.250.133] Cc: Konstantin Belousov , freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:44:39 -0000 --------------enigEABF9CB5010413DE1E789077 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/30/12 22:15, Peter Wemm wrote: > On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao w= rote: >> On 03/30/12 18:46, Konstantin Belousov wrote: >>> Reread what I wrote to you. Also, it pays off learning how ELF works >>> before making conclusion from the absence of the output of readelf -d= =2E >>> Amd64 modules _are not_ shared objects. >> >> Whether or not they are shared objects is irrelevant. The fact is that= >> they have text relocations, which interfere with ASLR. Do I need to >> produce exploit code before you take me seriously? >> >=20 > I am the person who wrote it and deliberately chose to cause text > relocations to be generated on i386. It is by design, not a bug. >=20 > All of your concerns are perfectly valid if they were for userland. >=20 > For the record, our amd64 modules ALSO do this, but your tools simply > do not detect it. >=20 > Here is what happens, and here is why it is not a problem: >=20 > When you compile with -fpic on an architecture that doesn't support > PC-relative addressing adequately, the compiler generates code to do > indirect memory references via the global offset table. This is so > that all the relocations can be collected into a single location in > order to not dirty the MAP_PRIVATE data pages. >=20 > example: > if there is an function at 0x12345, and another function in a > different .so file that wants to call it at 0x22345, then the call > instruction would have to be relocated. The asm instructions would > look like: > 0xE8FFEFFFFF (offset is -0x10000) >=20 > If the same .so file was loaded in another user process at 0x32345, > then the relocation would be different. An entire page would be > dirtied by the dynamic linker so that the second instance of the .so > file had 0xE8FFDFFFFF (-0x20000). This is a waste of memory and > causes a storm of VM faults at startup. >=20 > Instead, the code is compiled with -fPIC, which causes an extra memory > reference via the global offset table. Instead of the relocations > being spread over the text segment, the relocations are in a single > page. The dynamic linker has to dirty one page only in order to set > up a whole host of relocations. >=20 > The cost is i386 doesn't have native pc-relative mode, so it has to > waste an entire register. We dedicate one of the 6 general purpose > registers which costs a hefty performance hit. This is why crypto > code tends to be compiled without -fpic, for example. >=20 > For KERNEL modules, all this changes. >=20 > In userland, there is a dynamic linker. In the kernel, there is none. > In userland, the .so files are mapped with mmap(MAP_PRIVATE), the > kernel does not use mmap and always uses a private copy. > In userland, the .so files are shared, the kernel NEVER shares them. > In userland, doing a relocation causes a copy on write fault, this > never happens to the kernel because its using private, exclusive > malloc() pages. > In userland, we make the performance tradeoff from -fpic in order to > share memory pages, the kernel never shares pages so -fpic is a waste. > In userland, ASLR has security benefits. The kernel already does > this.. if you load a module on one machine it'll ALWAYS be at > different address space compared to another. >=20 > In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non > pic .o files into a container that was more convenient at the time to > parse. There is no global-offset-table. > In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same > non-pic code into a less convenient form that we can feed back into > the linker if we wish. There is no global offset table. >=20 > Both i386 and amd64 use raw relocations, regardless of where the came > from. Text, data, anywhere. >=20 > This has nothing to do with ASLR, because they are kernel objects, not > shared libraries. Most people seem to think that I am unaware of these things, but I already knew most of it. Note that this mostly applies to remarks people are sending me privately. With that said, thank you for the detailed explanation. It filled in a few blanks that I had, specifically in how FreeBSD does things. > You posted: > * QA Notice: The following files contain runtime text relocations > * Text relocations force the dynamic linker to perform extra > * work at startup, waste system resources, and may pose a security > * risk. On some architectures, the code may not even function > * properly, if at all. > The key here is "dynamic linker". There is no dynamic linker to > process this stuff. > This is simply a tools problem on your end. It's not a bug. My tools are doing what they were supposed to do. However, people on the list seem to think that the idea that they are checking for a problem to be a matter of opinion. > There are no security implications, no system resources to be wasted. >=20 > And if you think there are security implications, then lets see a > proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. You can argue otherwise, but for all I know, exploit code that ASLR breaks is already in the wild. I believe that nothing short of full disclosure would be beneficial to your users' security. > I have given you a detailed explanation of why it's not a problem. If > you want to continue, then reply with details, not hearsay or > theories. I asked why things were one way and certain people were rather rude. There is no need to join them in that. Anyway, my question is answered. Thanks. --------------enigEABF9CB5010413DE1E789077 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPdm8vAAoJELFAT5FmjZuEdBEQAM2+/ab+BamQhtWwcOMx/GMY /oqxCec4dwxUIMCqQGcATEsqUeHtJK0kjcJ+xsY8nc3UGsfzGQum4bqYxRY4JWHv iL7vXHYMpxmynys2jFtpcjS7Fx/wru5X1aMPbOzbZLmYy6UUHpPYXNKA+mVgLYYH j0cCRhKyhfSy/n5gx7wvRwDULEW5HLetsdrw3wgDj0VfDXwwEVZ3G22fiL+w8UsU i1QDxA9kB0agxQRuMO/kAEFDE2A9xP0b26G1ZtXz2dMNlq6T2701pVeXPJDw1Lf6 P6ifpgQuxnaxZPDtT3OXpTpPGIS5WyMppnfE6po7iHNNm9dMXYBH5CoJXjz5ewVo 4g1xoibeLQ6AQr7xf+d6JUh21s1Zv6aHaQB8Q32DNGmklOuSUs84xcP/dpoudjfB NxNfjC27L+tnD9y9rKI9d9NRshsPLRBhAI49yurB/nWvGEjkqGJDAGjJrn2blNdf 8igqV4OEYxRHc3AHbcdkcdq1lQ/lh+oko0mbrg1SIpNZ+hzyeZoohxpEcgWEDNko YW7Iwa9dZRLmsffvAhRAusleePwcViOHeUoAxlF/W4ahKwne5ckWJyroloKjB0tH 2EGBBJzkQcYlvHNawUTFTf20obOXXdr2dw22VIcfqdWuTCFwOYXFadEk20WyIrUx ETc+D3g3loc6G1jAkkVx =jykJ -----END PGP SIGNATURE----- --------------enigEABF9CB5010413DE1E789077-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 02:54:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C937E106566B for ; Sat, 31 Mar 2012 02:54:50 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from ultra7.eskimo.com (ultra7.eskimo.com [204.122.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id A1ACC8FC0A for ; Sat, 31 Mar 2012 02:54:50 +0000 (UTC) Received: from shell.eskimo.com (root@shell.eskimo.com [204.122.16.72]) by ultra7.eskimo.com (8.14.0/8.14.3) with ESMTP id q2V2wehK012985; Fri, 30 Mar 2012 19:58:40 -0700 Received: from shell.eskimo.com (joji@localhost [127.0.0.1]) by shell.eskimo.com (8.14.3/8.14.3) with ESMTP id q2V2siMC018704; Fri, 30 Mar 2012 19:54:44 -0700 Received: (from joji@localhost) by shell.eskimo.com (8.14.3/8.12.10/Submit) id q2V2sh4H018703; Fri, 30 Mar 2012 19:54:43 -0700 Date: Fri, 30 Mar 2012 19:54:43 -0700 From: Joseph Olatt To: Erich Dollansky Message-ID: <20120331025443.GA18661@shell.eskimo.com> References: <20120330022806.GA30761@shell.eskimo.com> <201203301041.54397.erichfreebsdlist@ovitrap.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203301041.54397.erichfreebsdlist@ovitrap.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.3 and 9.0 freeze with firefox X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:54:50 -0000 On Fri, Mar 30, 2012 at 10:41:54AM +0700, Erich Dollansky wrote: > Hi, > > On Friday 30 March 2012 09:28:06 Joseph Olatt wrote: > > > > Starting with 8.3, I've been experiencing FreeBSD freezing up completely > > after using firefox for a while. Thinking the problem would go away if I > > upgraded to 9.0, I did that and I am still experiencing the same > > freezing up. The mouse pointer freezes, the keyboard freezes (caps lock > > light will not come on; Ctrl-Alt-F[1-10] does not work etc.). The only > > way to get the system back is by pressing and holding down the power > > button. > > > > The problem seems similar to: kern/163145 > > > > > > There is nothing in /var/log/messages to indicate a problem. Output of > > pciconf -lv and uname -a are at: > > > > http://www.eskimo.com/~joji/wisdom/ > > > > Anybody else experiencing similar freeze ups with 8.3 or 9.0 while using > > firefox? > > > I use 8.3 and Firefox without problems. What extension did you install? Are they all properly updated? > > Earlier, it helped deleting firefox' directory in the user directory. > > Erich Erich, Thanks for your response. I've removed the .mozilla directory from my home directory. Let's see if it will make a difference. It is quite possible it will. I had updated the firefox port when I updated from 8.2 to 8.3. Thanks for the suggestion. joseph From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 19:25:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E794106566B; Sat, 31 Mar 2012 19:25:49 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 24AEF8FC15; Sat, 31 Mar 2012 19:25:49 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 31 Mar 2012 12:25:55 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2VJPm4q056071; Sat, 31 Mar 2012 12:25:48 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2VJPmCB056070; Sat, 31 Mar 2012 12:25:48 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203311925.q2VJPmCB056070@ambrisko.com> In-Reply-To: <1333039719.3948.3.camel@powernoodle-l7.corp.yahoo.com> To: sbruno@freebsd.org Date: Sat, 31 Mar 2012 12:25:48 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 19:25:49 -0000 Sean Bruno writes: | Noting a failure to attach to the onboard IPMI controller with this dell | R815. Not sure what to start poking at and thought I'd though this over | here for comment. | | -bash-4.2$ dmesg |grep ipmi | ipmi0: KCS mode found at io 0xca8 on acpi | ipmi1: on isa0 | device_attach: ipmi1 attach returned 16 | ipmi1: on isa0 | device_attach: ipmi1 attach returned 16 | ipmi0: Timed out waiting for GET_DEVICE_ID I've run into this recently. A quick hack to fix it is: Index: ipmi.c =================================================================== RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v retrieving revision 1.14 diff -u -p -r1.14 ipmi.c --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 +++ ipmi.c 31 Mar 2012 19:18:35 -0000 @@ -695,7 +695,6 @@ ipmi_startup(void *arg) if (error == EWOULDBLOCK) { device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); ipmi_free_request(req); - return; } else if (error) { device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); ipmi_free_request(req); The issue is that the wakeup doesn't actually wake up the msleep in ipmi_submit_driver_request. The error being reported is that the msleep timed out. This doesn't seem to be critical problem since after this things seemed to work work. I saw this on 9.X. Haven't seen it on 8.2. Not sure about -current. It doesn't happen on all machines. Doug A. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 20:59:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3DC106564A for ; Sat, 31 Mar 2012 20:59:02 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD5C8FC0C for ; Sat, 31 Mar 2012 20:59:02 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id BCFB92289E for ; Sat, 31 Mar 2012 21:58:54 +0100 (BST) Message-ID: <4F77700A.40404@rewt.org.uk> Date: Sat, 31 Mar 2012 21:58:50 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F776DE5.5020507@rewt.org.uk> In-Reply-To: <4F776DE5.5020507@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kern.eventtimer.periodic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 20:59:02 -0000 Joe Holden wrote: > Hey, > > So I have another box that has time issues since being upgraded to > 9.0-REL, again kern.eventtimer.periodic=1 seems to be the fix. > > Should this perhaps be a default in future releases? Sigh... correct list this time. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 31 23:13:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B7D281065675; Sat, 31 Mar 2012 23:13:59 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 8F26B8FC0A; Sat, 31 Mar 2012 23:13:59 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 31 Mar 2012 16:13:55 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2VNDn5Q098550; Sat, 31 Mar 2012 16:13:49 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2VNDnE5098549; Sat, 31 Mar 2012 16:13:49 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203312313.q2VNDnE5098549@ambrisko.com> In-Reply-To: To: sbruno@freebsd.org Date: Sat, 31 Mar 2012 16:13:48 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: "freebsd-stable@freebsd.org" Subject: Re: [stable-ish 9] Dell R815 ipmi(4) attach failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 23:13:59 -0000 Doug Ambrisko writes: | Sean Bruno writes: | | Noting a failure to attach to the onboard IPMI controller with this dell | | R815. Not sure what to start poking at and thought I'd though this over | | here for comment. | | | | -bash-4.2$ dmesg |grep ipmi | | ipmi0: KCS mode found at io 0xca8 on acpi | | ipmi1: on isa0 | | device_attach: ipmi1 attach returned 16 | | ipmi1: on isa0 | | device_attach: ipmi1 attach returned 16 | | ipmi0: Timed out waiting for GET_DEVICE_ID | | I've run into this recently. A quick hack to fix it is: | | Index: ipmi.c | =================================================================== | RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v | retrieving revision 1.14 | diff -u -p -r1.14 ipmi.c | --- ipmi.c 14 Apr 2011 07:14:22 -0000 1.14 | +++ ipmi.c 31 Mar 2012 19:18:35 -0000 | @@ -695,7 +695,6 @@ ipmi_startup(void *arg) | if (error == EWOULDBLOCK) { | device_printf(dev, "Timed out waiting for GET_DEVICE_ID\n"); | ipmi_free_request(req); | - return; Correction get rid of the ipmi_free_request as well. If you kldload then it doesn't have this issue. I've been doing that on -current for a while so I didn't notice the regression when it happened. | } else if (error) { | device_printf(dev, "Failed GET_DEVICE_ID: %d\n", error); | ipmi_free_request(req); | | The issue is that the wakeup doesn't actually wake up the msleep | in ipmi_submit_driver_request. The error being reported is that | the msleep timed out. This doesn't seem to be critical problem | since after this things seemed to work work. I saw this on 9.X. | Haven't seen it on 8.2. Not sure about -current. | | It doesn't happen on all machines. | | Doug A.