From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 13 10:36:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7886D846 for ; Sun, 13 Jan 2013 10:36:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id DF4FBEFF for ; Sun, 13 Jan 2013 10:36:46 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0DAaaDi008956; Sun, 13 Jan 2013 11:36:36 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0DAaaZc008953; Sun, 13 Jan 2013 11:36:36 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 13 Jan 2013 11:36:36 +0100 (CET) From: Wojciech Puchar To: Warren Block Subject: Re: SATA disk disappears In-Reply-To: Message-ID: References: <201301120925.55068.c47g@gmx.at> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 13 Jan 2013 11:36:36 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 10:36:47 -0000 >> self tests can not find any errors/bad sectors. > > Hmm. The green drives are supposed to go to sleep for power saving, and then > there's a multiple-second delay when they have to spin back up on access. no it wasn't that. i did long test as you recommended and drive reported fault. Gave it back for replacement. Thank you From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 13 10:39:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1F90AD8 for ; Sun, 13 Jan 2013 10:39:36 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4F938F3B for ; Sun, 13 Jan 2013 10:39:36 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0DAdXlg008966 for ; Sun, 13 Jan 2013 11:39:33 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0DAdXbt008963 for ; Sun, 13 Jan 2013 11:39:33 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 13 Jan 2013 11:39:33 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: /etc/pam.d help Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 13 Jan 2013 11:39:33 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 10:39:36 -0000 i never really understood PAM and would be much happier if it won't be included at all, but i need to allow root login by password with rlogin and rsh. I am not interested in comments like "this is insecure" because it depends. For me it is secure - over my own LAN or encrypted tunnel. What to change in /etc/pam.d to allow rlogin and rsh to work with keyboard typed password when logging as root. i can go passwordless with .rhosts but this is not what i want. Thanks for help! From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 13 10:40:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0CF4BC1 for ; Sun, 13 Jan 2013 10:40:04 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 56FB0F4B for ; Sun, 13 Jan 2013 10:40:04 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0DAe1vT008977; Sun, 13 Jan 2013 11:40:01 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0DAe1s7008974; Sun, 13 Jan 2013 11:40:01 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 13 Jan 2013 11:40:01 +0100 (CET) From: Wojciech Puchar To: Christian Gusenbauer Subject: Re: SATA disk disappears In-Reply-To: <201301120925.55068.c47g@gmx.at> Message-ID: References: <201301120925.55068.c47g@gmx.at> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 13 Jan 2013 11:40:02 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 10:40:04 -0000 >> >> 1T Red here. The firmware is likely very similar. > > The same here: brandnew WD 2T green, 9.1 stable, svn rev. 244773, not using > GEOM. I had that problem two times within the last two weeks, but the smart > self tests can not find any errors/bad sectors. smartctl -t long /dev/disk found an error after few hours. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 13 16:29:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E686DF7F for ; Sun, 13 Jan 2013 16:29:51 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 63C4BDE8 for ; Sun, 13 Jan 2013 16:29:50 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lobhc-1TIMrK0XGs-00gbCg for ; Sun, 13 Jan 2013 17:29:44 +0100 Received: (qmail invoked by alias); 13 Jan 2013 16:29:44 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp029) with SMTP; 13 Jan 2013 17:29:44 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX18L/V58N1cLGS2x0NxbXmiR1m0IF5zRYGNHBojFDi UlI/SS6bg4KXYa From: Christian Gusenbauer To: Warren Block Subject: Re: SATA disk disappears Date: Sun, 13 Jan 2013 17:30:56 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301120925.55068.c47g@gmx.at> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301131730.56352.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-hackers@freebsd.org, Wojciech Puchar X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 16:29:52 -0000 On Saturday 12 January 2013 19:07:17 Warren Block wrote: > On Sat, 12 Jan 2013, Christian Gusenbauer wrote: > > On Friday 11 January 2013 22:47:03 Warren Block wrote: > >> On Fri, 11 Jan 2013, Wojciech Puchar wrote: > >>>>> GEOM_MIRROR: Component ada2 (device home1) broken, skipping. > >>>>> GEOM_MIRROR: Cannot add disk ada2 to home1 (error=22). > >>>>> > >>>>> > >>>>> started gmirror rebuild and it now works at full speed. > >>>>> > >>>>> GEOM_MIRROR: Device home1: rebuilding provider ada2. > >>>>> > >>>>> > >>>>> What kind of hardware failure may it be? smartctl -a /dev/ada2 shows > >>>>> disk is fine. > >>>> > >>>> I had a new WD drive recently that had a write error. Reallocated > >>>> sector count did not go up, but it quickly failed the SMART self-test, > >>>> short or long. See smartctl(8) about the -t parameters. > >>> > >>> this is WD "green" 3TB > >> > >> 1T Red here. The firmware is likely very similar. > > > > The same here: brandnew WD 2T green, 9.1 stable, svn rev. 244773, not > > using GEOM. I had that problem two times within the last two weeks, but > > the smart self tests can not find any errors/bad sectors. > > Hmm. The green drives are supposed to go to sleep for power saving, and > then there's a multiple-second delay when they have to spin back up on > access. That should not be a problem for gmirror, but maybe it is. > sysutils/ataidle can turn on the spindown. Some drives do not accept > that command, or claim to accept it but ignore it. Worth a try, though. I don't think it was the power saving spin down, because I was copying data from/to the drive when it suddenly vanished. So the disk was busy at that time. I'll give ataidle a chance - but it's hard to reproduce. I'm using the drive for five days now without failure. Thanks, Christian. From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 13 21:57:48 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9117643F; Sun, 13 Jan 2013 21:57:48 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by mx1.freebsd.org (Postfix) with ESMTP id C4953F30; Sun, 13 Jan 2013 21:57:47 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id b57so1646387eek.7 for ; Sun, 13 Jan 2013 13:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:organization :x-mailer:mime-version:content-type:content-transfer-encoding; bh=8V6EMSvWZJHUHgX+nB2s8cmYorP75cnsxIo71lYpa9Q=; b=m5CkMLAzJXQ+DDnjIDKqi6G7ahaHL2Cs63ci9ZeOlEft71CYwjPOns1KQLtmte06/k G98GCiCDPuTww2Ry7EIOCBs9E4VuNCCiYSHVaiZMW7slfHNUPmkS2s/zDmBMCH3f9osh L7HMwL9zBlkfPPyU3q4jfGhHGMzg/GqxwcPsArNN33z1LWywuu50tBV0SjaYgIoj7Pqt 0NyGFcmWI/EVIgTiQXRWOu/KcFMuiBUGaMJ1Gu6pWhjqheH9Eh/6pEC58yQn8e3xPXvx bbVAjO5fqtVROlgFqOjsk4W2PeGEiBcjGmECDaCQku2SsfdOCDCeiRR+5xT4qb8zKtNn /UEQ== X-Received: by 10.14.204.70 with SMTP id g46mr198174046eeo.15.1358114261321; Sun, 13 Jan 2013 13:57:41 -0800 (PST) Received: from spongya (catv-80-98-246-83.catv.broadband.hu. [80.98.246.83]) by mx.google.com with ESMTPS id 6sm19115718eea.3.2013.01.13.13.57.39 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 13 Jan 2013 13:57:40 -0800 (PST) Sender: =?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?= Date: Sun, 13 Jan 2013 22:57:14 +0100 From: Gabor Pali To: hackers@freebsd.org Subject: FreeBSD Quarterly Status Report April-June, 2012 Message-ID: <20130113225714.0083627d@spongya> Organization: The FreeBSD Project X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; i386-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jan 2013 21:57:48 -0000 FreeBSD Quarterly Status Report April-June, 2012 Introduction This report covers FreeBSD-related projects between April and June 2012. This quarter was highlighted by having a new Core Team elected, which took office on July 11th to start its work with a relatively high number of new members. Note that this is the second of the three reports planned for 2012. Thanks to all the reporters for the excellent work! This report contains 17 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between July and December 2012 is February 17th, 2013. __________________________________________________________________ Projects Userland Programs * FreeBSD Services Control (fsc) * Replacing the Regular Expression Code FreeBSD Team Reports * FreeBSD Documentation Project * The FreeBSD Core Team * The FreeBSD Port Management Team Kernel * FreeBSD/at91 Improvements Network Infrastructure * Multipath TCP (MPTCP) for FreeBSD * SMP-Friendly pf(4) Documentation * The FreeBSD Japanese Documentation Project Architectures * FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor Ports * BSD-licensed Sort Utility (GNU sort(1) Replacement) * FreeBSD Haskell Ports * KDE/FreeBSD * Portbuilder * Redports * Xorg on FreeBSD Miscellaneous * BSD-Day 2012 __________________________________________________________________ BSD-Day 2012 URL: http://bsdday.eu/2012 URL: http://www.youtube.com/playlist?list=3DPL13D5471D8ECF08C9 URL: https://picasaweb.google.com/116452848880746560170/BSDDay2012?authk= ey=3DGv1sRgCN3twLrxuaeongE Contact: G=C3=A1bor P=C3=A1li For this year, we moved the time of the event earlier by six months, so it was held on May 5, 2012 and it was co-located with the Austrian Linuxweeks (Linuxwochen =C3=96sterreich) in Vienna. We had many sponsors, like the freshly joined FreeBSD Foundation, iXsystems, FreeBSDMall, BSD Magazine, allBSD.de Projekt, that enabled us to continue our previously launched series of multi-project BSD developer summits all around Central Europe. To kick off, there was a "stammtisch" (local beer meetup) organized in the downtown of Vienna, at Kolar on the Friday evening before the event -- as usual. Then it was followed by the event on Saturday that brought many interesting topics from the world of FreeBSD, OpenBSD and NetBSD: running NetBSD as an embedded system for managing VOIP applications, introduction to the Capsicum security framework, relayd(8), the load balancer and proxy solution for OpenBSD, status update of the developments around the FreeBSD ports tree, using DVCSs in clouds, firewalling with pfSense, and mfsBSD. Please consult the links in the report for the details. __________________________________________________________________ BSD-licensed Sort Utility (GNU sort(1) Replacement) URL: http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/bsdsort/ URL: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html Contact: Oleg Moskalenko Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n BSD sort(1) has been made the default sort utility in 10-CURRENT. It is compatible with the latest GNU sort(1), version 8.15, except that the multi-threaded mode is not enabled by default. Open tasks: 1. When the track record of the BSD sort(1) allows, remove GNU sort(1) from -CURRENT. 2. Improve reliability of the multi-threaded sort and investigate the possibility of making it the default compilation mode. 3. Investigate possibility of factoring out the sort functionality into a standalone library so that other utilities can also make use of it. __________________________________________________________________ FreeBSD Documentation Project URL: http://wiki.freebsd.org/GoogleCodeIn/2011Status URL: http://wiki.freebsd.org/201208DevSummit URL: http://wiki.freebsd.org/DocIdeaList Contact: We continue to make progress in committing the work produced as part of Google Code-In 2011; an overview of the status is at http://wiki.freebsd.org/GoogleCodeIn/2011Status. Doc committers and GCIN mentors are encouraged to go through the list and help shepherd outstanding tasks into the tree. We are planning a full day of Documentation Summit on the day preceding the August 2012 DevSummit in Cambridge, UK. This follows a successful DocSummit day held at BSDCan in May 2012. Further details are available at: http://wiki.freebsd.org/201208DevSummit. A doc sprint took place over IRC (#bsddocs on EFnet) in early July, setting out plans for reviving the marketing team and a strong desire for a new, more organized website. A lot of progress and momentum has built up with creating and updating documentation and website content over the last few months. Also read the doceng report for the recent infrastructure improvements. Anyone wishing to help with this effort is welcome to join us and say hello either on the freebsd-doc mailing list, or #bsddocs on EFnet IRC. Open tasks: 1. Review the website content and remove outdated parts or update when applicable. 2. Go through the doc idea list on the wiki and start working them out. __________________________________________________________________ FreeBSD Haskell Ports URL: http://wiki.freebsd.org/Haskell URL: https://github.com/freebsd-haskell/freebsd-haskell/ Contact: G=C3=A1bor P=C3=81LI Contact: Ashish SHUKLA We are proud to announce that the FreeBSD Haskell Team has updated the Haskell Platform to 2012.2.0.0, GHC to 7.4.1 as well as updated existing ports to their latest stable versions. We also added a number of new Haskell ports, and their count in FreeBSD Ports tree is now 336. Open tasks: 1. Test GHC to work with clang/LLVM. 2. Add an option to the lang/ghc port to be able to build it with already installed GHC instead of requiring a separate GHC bootstrap tarball. 3. Commit pending Haskell ports to the FreeBSD Ports tree. 4. Add more ports to the Ports Collection. __________________________________________________________________ FreeBSD Services Control (fsc) Contact: Tom Rhodes FSC has been moved into the ports system (see sysutils/fsc) and continues to improve outside of the ports tree. Some interesting work is being done in the area of services control, system boot, and a simplification of the process. Stay tuned for more information in status reports that follow. Open tasks: 1. Test, test, test. Feedback is really important to this project. __________________________________________________________________ FreeBSD/arm on ARM Fast Models Simulator for Cortex-A15 MPCore Processor URL: http://www.arm.com/products/processors/cortex-a/cortex-a15.php URL: http://www.arm.com/products/tools/models/fast-models.php Contact: Zbigniew Bodek Contact: Rafal Jaworowski Contact: Tomasz Nowicki ARM Fast Models is platform which helps software developers debug systems in parallel with SoC design, speeding up and improving system development. This work is bringing up FreeBSD on ARM Fast Models system based on ARM Cortex-A15 and peripheral components. It works in single user mode, using a compiled-in kernel RAM disk minimal root file system. Current FreeBSD support includes: * L1, L2 cache, Branch Predictor * Dual-core (SMP) support setup in WB cache mode * Cortex-A15 integrated Generic Timer * Drivers for ARM peripheral components: + PL011 UART controller + PL390 GIC - Generic Interrupt Controller + SP804 Dual Timer Next steps: * Quad-core (SMP) support * Multi-user mode __________________________________________________________________ FreeBSD/at91 Improvements URL: http://wiki.freebsd.org/FreeBSDAtmel Contact: Warner Losh FreeBSD's Atmel support has languished for some time. A number of improvements were urgently needed as demand for newer SoCs has materialized. New SoC support is not hard, but it does wind up copying a lot of code. I have started down the path to make it easier to do. I had planned on making it table driven. But then I discovered with dts files that Atmel was producing. So, I plan on moving to using Atmel's .dsti files, or variations on them. They have .dsti files for all the AT91SAM9 parts. This should allow us to support new SoCs and boards faster. However, there are some challenges with this approach. Pin multiplexing seems undefined in Atmel's dts file. Only a few of the devices are well-defined at the present time. And the encoding seems to be immature. So we have a target-rich port that is quite ripe for refactoring. Open tasks: 1. Update the base system libfdt to a version that supports include. 2. Write a .dtsi for Atmel AT91RM9200. 3. Write .dti files for all supported boards. 4. Help sort out the pin multiplexing issue. 5. Refactor existing board files to make new ones easier in the interim. 6. Knock yourself out and implement board support for new CPUs. __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE FreeBSD The team has made many releases and upstreamed many fixes and patches. The latest round of releases include: * KDE SC: 4.8.3, 4.8.4 (in ports) and 4.8.95 (in area51) * Qt: 4.8.1, 4.8.2 * PyQt: 4.9.1; SIP: 4.13.2; QScintilla 2.6.1 * KDevelop: 2.3.1; KDevPlatform: 1.3.1 * Calligra: 2.4.2, 2.4.3 * Amarok: 2.5.90 (in area51) * CMake: 2.8.8 * Digikam (and KIPI-plugins): 2.6.0 As a result -- according to PortScout -- kde@ has 393 ports, of which 91% are up-to-date. The team is always looking for more testers and porters so please contact us and visit our home page. Open tasks: 1. Test KDE SC 4.8.95. 2. Test KDE PIM 4.8.95. 3. Update out-of-date ports, see PortScout for a list. __________________________________________________________________ Multipath TCP (MPTCP) for FreeBSD URL: http://caia.swin.edu.au/newtcp/mptcp/ URL: http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-09 URL: http://mptcp.info.ucl.ac.be/ Contact: Nigel Williams Contact: Lawrence Stewart Contact: Grenville Armitage Work is underway to create an IETF draft-compatible Multipath TCP implementation for the FreeBSD kernel. A key goal of the project is to create a research platform to investigate a range of multipath related transport issues including congestion control, retransmission strategy and packet scheduling policy. We also aim to provide full interoperability with the Linux kernel implementation being developed at Universit=C3=A9 catholique de Louvain. We expect to release code and results at the project's home page as it progresses. __________________________________________________________________ Portbuilder URL: https://github.com/DragonSA/portbuilder URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/README URL: https://github.com/DragonSA/portbuilder/blob/0.1.5.2/TODO Contact: David Naylor Since the last update there has been 2 feature releases and 4 bug-fix releases. A highlight of the changes made: * Support has been added for: * -j: controlling concurrency per stage * pkgng: next generation package manager * installing packages via repository * dynamic defaults (loaded from /etc/make.conf) * new options framework (aka OptionsNG) Some of the fixes include: * correct assertions * correct build logic * retry when kevent receives EINTR * correctly detecting installed ports * many fixes in the build logic A benchmark was run timing portbuilder against a standard ports build of KDE (x11/kde4) in a clean chroot(8) environment. Portbuilder achieved a build time of 2:21:16 compared to ports build time of 4:47:21 for an decreased build time of 51% from using portbuilder. __________________________________________________________________ Redports URL: http://www.redports.org/ Contact: Bernhard Froehlich There was good progress in the last half a year and a lot of support from different parties to make redports a stable and fast service. A long known security concern within tinderbox was raised at the BSD-Day in Vienna which was addressed by beat. That improves security and isolation of the concurrent running jobs a lot and gives me peace of mind. We also recently got two beefy machines from the FreeBSD Foundation which increases computing power a lot. So no more backlogs and your jobs finish much quicker. But as usual now that we have enough power I was able to make another promise come true and integrated Ports QAT functionality into redports. Ports QAT was an automated services that did a buildtest after each commit to the official FreeBSD ports tree. If a build fails it sends out mails and logfiles to the committer. That finds bad commits quickly and allows the committer to fix it before the first user notices. The former service stopped about 2 years ago and we had no proper replacement for that task at hand. Now that this is fully integrated into redports it also gives us all the nice benefits of a common platform. Open tasks: 1. Automatic build incoming patches from Ports PRs in redports and send results to GNATS database. 2. People want an GCC testing environment on redports where all ports are build with lang/gcc47. To make that happen we need to patch the ports framework to handle that and correctly bootstrap with base GCC. This also gives us the possibility to build all our binary packages with a modern gcc and is easy to use for regular users. Contributors? __________________________________________________________________ Replacing the Regular Expression Code URL: http://laurikari.net/tre/ Contact: G=C3=A1bor K=C3=B6vesd=C3=A1n It has been decided to implement the optimizations and extensions as a more isolated layer and not directly in TRE itself. Since the last report there has been some progress in this direction and the code has been significantly refactored. It does not work yet in this new form but it is close to a working state. Apart from this, the multiple pattern matching needs some debugging and some minor features are missing. Open tasks: 1. Finish multiple pattern heuristic regex matching. 2. Implement GNU-specific regex extensions. 3. Test performance, standard-compliance and correct behavior. __________________________________________________________________ SMP-Friendly pf(4) URL: http://svnweb.freebsd.org/base/projects/pf/head/ URL: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html Contact: Gleb Smirnoff The project is aimed at moving the pf(4) packet filter out of single mutex, as well as in general improving of its FreeBSD port. The project is near its finish, the code is planned to go into head after more testing and benchmarking. If you are interested in details, please see the corresponding email thread on freebsd-pf (see links). Open tasks: 1. Rewrite the pf(4) ioctl() interface so that it does not utilize in-kernel structures. That would make ABI more stable and ease future development. __________________________________________________________________ The FreeBSD Core Team URL: http://docs.FreeBSD.org/cgi/mid.cgi?1342030291.6001.80.camel Contact: Core Team The FreeBSD Project is pleased to announce the completion of the 2012 Core Team election. The FreeBSD Core Team acts as the project's "Board of Directors" and is responsible for approving new src committers, resolving disputes between developers, appointing sub-committees for specific purposes (security officer, release engineering, port managers, webmaster, et cetera), and making any other administrative or policy decisions as needed. The Core Team has been elected by FreeBSD developers every 2 years since 2000. Peter Wemm rejoins the Core Team after a two-year hiatus, with new members Thomas Abthorpe, Gavin Atkinson, David Chisnall, Attilio Rao and Martin Wilke joining incumbents John Baldwin, Konstantin Belousov and Hiroki Sato. The complete newly elected core team is: * Thomas Abthorpe * Gavin Atkinson * John Baldwin * Konstantin Belousov * David Chisnall * Attilio Rao * Hiroki Sato * Peter Wemm * Martin Wilke The new Core Team would like to thank outgoing members Wilko Bulte, Brooks Davis, Warner Losh, Pav Lucistnik, Colin Percival and Robert Watson for their service over the past two (and in some cases, many more) years. The Core Team would also especially like to thank Dag-Erling Sm=C3=B8rgr= av for running the election. __________________________________________________________________ The FreeBSD Japanese Documentation Project URL: http://www.FreeBSD.org/ja/ URL: http://www.jp.FreeBSD.org/doc-jp/ Contact: Hiroki Sato Contact: Ryusuke Suzuki Our translation work has slightly moved on to handbook from the www/ja (CVS) or htdocs (SVN) subtree, since almost translated web page contents were updated to the latest English counterparts. During this period, we translated the 8.3-RELEASE announcement and published it in a timely manner. Newsflash and some other updates in the English version were also translated as soon as possible. For FreeBSD Handbook, translation work of the "cutting-edge" and "printing" sections have been completed. Some updates in the "linuxemu" and "serialcomms" section were done. At this moment, "bsdinstall", "cutting-edge", "desktop", "install", "introduction", "kernelconfig", "mirrors", "multimedia", "pgpkeys", "ports", "printing", and "x11" chapters are synchronized with the English versions. Open tasks: 1. Further translation work of outdated documents in ja_JP.eucJP subtree. __________________________________________________________________ The FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr Contact: Thomas Abthorpe Contact: Port Management Team The ports tree slowly approaches 24,000 ports. The PR count still is close to 1200. In Q2 we added 7 new committers and took in one commit bit for safe keeping. The Ports Management team have been running -exp runs on an ongoing basis, verifying how base system updates may affect the ports tree, as well as providing QA runs for major ports updates. Of note, -exp runs were done for: * automake update * cmake update * xorg update * png update * Fix make reinstall * Implement USE_QT4 in bsd.ports.mk * KDE4 update * XFCE4 update * bison update * perl5.14 as default * ruby1.9 as default * ruby1.8 update * bsdsort regression test A lot of focus during this period was put into getting the ports tree into a ready state for FreeBSD 9.1. A significant step forward was the implementation of OptionsNG. A record number of Port Managers attended BSDCan 2012, with five being present to partake in the week of events, culminating in a portmgr PR closing session that dealt with 18 PRs in one day. You can see a group photo at . While you are there, please click on the "Like" icon. Beat Gaetzi has been doing ongoing tests with the ports tree to ensure a smooth transition from CVS to Subversion. The tree was successfully migrated the weekend of June 14, 2012. Open tasks: 1. Looking for help getting ports to build with clang. 2. Looking for help fixing ports broken on CURRENT. (List needs updating, too.) 3. Looking for help with Tier-2 architectures. 4. ports broken by src changes. 5. ports failing on pointyhat. 6. ports failing on pointyhat-west. 7. ports that are marked as BROKEN. 8. When did that port break? 9. Most ports PRs are assigned, we now need to focus on testing, committing and closing. __________________________________________________________________ Xorg on FreeBSD URL: http://wiki.freebsd.org/Xorg URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: Martin Wilke Contact: Koop Mast Contact: Niclas Zeising Contact: Eitan Adler During the beginning of this period, an update to the xorg distribution for FreeBSD was made, dubbed xorg 7.5.2. This update included a new flag, WITH_NEW_XORG, to get a more recent xorg distribution for those with modern hardware. To get KMS support for recent Intel graphics chipsets WITH_KMS must also be set. This requires a recent FreeBSD 10-CURRENT or FreeBSD 9-STABLE. Open tasks: 1. Switch to use FreeGLUT instead of libGLUT, since the latter is old and has there is no upstream support or releases any more. Work on this is mostly done. 2. Update the xorg distribution to what is in the development repository. The xorg project recently did a new release, and the development repository contains this release. It needs more testing before it can be merged, and a CFT was sent out in the beginning of June. Work on this is ongoing. 3. Decide how to handle the new and old xorg distributions. In recent xorg, a lot of legacy driver support has been dropped, therefore we need to maintain two xorg distributions to not loose a lot of hardware drivers. Currently, this is done by setting the flag WITH_NEW_XORG in /etc/make.conf, but a more practical solution is needed. This is especially important since the flag is not very user friendly, and since there currently will be no official packages for the new distribution. __________________________________________________________________ (c) 1995-2013 The FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 14 08:09:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D9118EB; Mon, 14 Jan 2013 08:09:08 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by mx1.freebsd.org (Postfix) with ESMTP id A559FAEF; Mon, 14 Jan 2013 08:09:07 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id c1so2744927lbg.32 for ; Mon, 14 Jan 2013 00:09:06 -0800 (PST) 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=N98fiZL8T2dU3S9sHGC2zPwv69F30MvheBzxKFks+7I=; b=f53blvDS9OVhjKh48S3/FWpqEhoK+3wvZ2YJ4DbiM37w7uDTbsOjQDdK1I3X+KKAQJ 14VbJWz2DcDyD+89+qF7/DdNmxdg4GIif6J0IR0vzy8fYHz/vE76cFaQo3U4dnl1U1Au LLqmNc3lLjRWKARgYTmVjkgmb1as8sLsLgj+OroxOZdb4hPFiIUTw9UBy9fxOzMTvfbU QIhsn8vrkzWWq55cUkWB/t9D27mTJM4jm8hM6gYl7dpLo1dfVTRgRU0nduNzg5zlCrhA 039Xnpt+wQZaZ7P3da43+ynjmfAZrASwSvDI3eekhf13+OMVCFZw2mAxuLsycuUvOjjf JERQ== MIME-Version: 1.0 Received: by 10.152.114.42 with SMTP id jd10mr19146917lab.31.1358150946331; Mon, 14 Jan 2013 00:09:06 -0800 (PST) Received: by 10.152.13.36 with HTTP; Mon, 14 Jan 2013 00:09:06 -0800 (PST) In-Reply-To: References: <20130111081254.GG82815@FreeBSD.org> Date: Mon, 14 Jan 2013 10:09:06 +0200 Message-ID: Subject: Re: Possible bug in m_split() when splitting M_EXT mbufs From: Jacques Fourie To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Hackers freeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 08:09:08 -0000 On Fri, Jan 11, 2013 at 10:53 AM, Jacques Fourie wrote: > > > > On Fri, Jan 11, 2013 at 10:12 AM, Gleb Smirnoff wrote: > >> Jacques, >> >> On Fri, Jan 11, 2013 at 09:34:32AM +0200, Jacques Fourie wrote: >> J> Could someone please verify if m_split as in svn rev 245286 is doing >> the >> J> right thing in the scenario where a mbuf chain is split with len0 >> falling >> J> on a mbuf boundary and the mbuf in question being a M_EXT mbuf? >> Consider >> J> the following example where m0 is a mbuf chain consisting of 2 M_EXT >> mbufs, >> J> both 1448 bytes in length. Let len0 be 1448. The 'len0 > m->m_len' >> check >> J> will be false so the for loop will not be entered in this case. We now >> have >> J> len = 1448 and remain = 0 and m still points to the first mbuf in the >> J> chain. Also assume that m0 is a pkthdr mbuf. A new pkthdr mbuf n will >> be >> J> allocated and initialized before the following piece of code is >> executed : >> J> >> J> extpacket: >> J> if (m->m_flags & M_EXT) { >> J> n->m_data = m->m_data + len; >> J> mb_dupcl(n, m); >> J> } else { >> J> bcopy(mtod(m, caddr_t) + len, mtod(n, caddr_t), >> remain); >> J> } >> J> n->m_len = remain; >> J> m->m_len = len; >> J> n->m_next = m->m_next; >> J> m->m_next = NULL; >> J> return (n); >> J> >> J> As m is a M_EXT mbuf the code in the if() clause will be executed. The >> J> problem is that m still points to the first mbuf so effectively the >> data >> J> pointer for n is assigned to the end of m's data pointer. It should >> J> actually point to the start of the data pointer of the next mbuf in the >> J> original m0 chain, right? >> >> Thanks for analysis, Jacques. >> >> IMHO, the following patch should suffice and won't break anything: >> >> Index: uipc_mbuf.c >> =================================================================== >> --- uipc_mbuf.c (revision 245223) >> +++ uipc_mbuf.c (working copy) >> @@ -1126,7 +1126,7 @@ >> u_int len = len0, remain; >> >> MBUF_CHECKSLEEP(wait); >> - for (m = m0; m && len > m->m_len; m = m->m_next) >> + for (m = m0; m && len >= m->m_len; m = m->m_next) >> len -= m->m_len; >> if (m == NULL) >> return (NULL); >> >> Can you please test it? > > > I think that your patch may cause other issues - m now points to the first > mbuf in the tail portion. The final piece of code under the extpacket: > label will then set m->m_len to 0 for example. > >> > > >> -- >> Totus tuus, Glebius. >> > > I have tested your proposed patch and can confirm that it doesn't work. The issue is probably what I mentioned above - the wrong mbuf is now treated as the last part of the head portion of the original mbuf. Regards, Jacques From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 14 18:58:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 359383CE for ; Mon, 14 Jan 2013 18:58:18 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by mx1.freebsd.org (Postfix) with ESMTP id ADDEEDF9 for ; Mon, 14 Jan 2013 18:58:17 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fe20so4274906lab.29 for ; Mon, 14 Jan 2013 10:58:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=+yrpleQCSlEniC6uiAqJqD4GHG4+2rhGqtvVHSevTWM=; b=RoGPrI5tyn7GHkXEQ+UWcFcYEIIgHXI5h3o5KTYI2X6kJGVOOTkoFf5snBS/FaFlKY 7+6I0J/Os/zPGlxVXqU2mfwyHzAC+2I5OxoD0WYK53uoHy0Ddf7VD5Hx/qIytdiwwzgK YnzLRbBWUG2GQdAvnF9/DJSrLC4MyZE6oVqm7Z2pvapsSWE/3onTm1mmAqB/spdhCrgZ mV44nKYnU9DxITa8wvD2oTDLttPGgcJQ/x6gfwtGsUYCWvqQwpD1OtO9Gg6ldrupSEUZ Jvy3cFr6vaghY0+Oho6MNerpiIOgRLx3g9x2mteOWRR78vkGVA5p3oW8i/1hYgOxz/Fd 5dBw== X-Received: by 10.152.122.133 with SMTP id ls5mr84441104lab.9.1358189896187; Mon, 14 Jan 2013 10:58:16 -0800 (PST) Received: from zont-osx.local (ppp95-165-128-93.pppoe.spdop.ru. [95.165.128.93]) by mx.google.com with ESMTPS id e7sm2185781lbn.1.2013.01.14.10.58.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 10:58:15 -0800 (PST) Sender: Andrey Zonov Message-ID: <50F45542.3070206@FreeBSD.org> Date: Mon, 14 Jan 2013 22:58:10 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Yuri Subject: Re: Is there any modern alternative to pstack? References: <4F775DF5.1020704@rawbw.com> <4F8A8CD2.5020103@rawbw.com> <20120415093029.GR2358@deviant.kiev.zoral.com.ua> <201204160959.29089.jhb@freebsd.org> <50206296.4060802@rawbw.com> In-Reply-To: <50206296.4060802@rawbw.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2OOPONPSGXQRANFISOXJJ" X-Gm-Message-State: ALoCoQmOEG/mxJ/UoZM+TL3+dimKKdvocLltcU+a2Q+OtjdEQJxBjWcbjBgIcnIzMKfXaP/JeYgD Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:58:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OOPONPSGXQRANFISOXJJ Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 8/7/12 4:34 AM, Yuri wrote: > On 04/16/2012 06:59, John Baldwin wrote: >> I'm fine with putting it into the base. If so, we should import 1.2 >> first I >> think and then apply the 1.3 patch. >=20 > So are there plans to import it into the base? Maybe for 9.1? > /usr/ports/sysutils/pstack is still i386 only. >=20 Try this version [1]. I plan to update sysutils/pstack to it. [1] https://github.com/z0nt/pstack --=20 Andrey Zonov ------enig2OOPONPSGXQRANFISOXJJ 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.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQ9FVFAAoJEBWLemxX/CvTUm8H/3iY10xJ5eUYaOQiftibxRTp clXNXPV8rFBPywBqyKRu7AUh7gXc8H1SpGHfngUIc8f1ozkk/uJynIfmr/vTLe0k zhyqLIFkAPFm61FeMOR89RXrOEWPzVqsiGHQ8qXGlz6IOPowQ4DFAEwpp4B2+89e J/7tPdjhwwUe0fckkarBzA/UbytMwhMhVzrXqqGEu6RR7HyxeZOSerYRrO3mb6y0 QjdD/WZyWPWLw40LqqGIYYjsO4Ocbzcpi5C9LoKnBcQwHVGUtwnvP9XQnx/3LoYQ wxeV15F9GhF4uKHHToNFTRNW20K4p8T4HgjWuO/XJTbBAkVvIJnlDgb9Qz7yMGY= =kprN -----END PGP SIGNATURE----- ------enig2OOPONPSGXQRANFISOXJJ-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 14:12:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0FF0CD6 for ; Tue, 15 Jan 2013 14:12:21 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by mx1.freebsd.org (Postfix) with ESMTP id 8F08CA8D for ; Tue, 15 Jan 2013 14:12:21 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id k10so219001iea.1 for ; Tue, 15 Jan 2013 06:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=a2zBCcEYiIvfN4o7y9FAtC7on6cj7UbF+vOiZKlsdlc=; b=UXPbvfMVTrejoSC9Vpl+XwKCoesZ70vsDPw+Ruh0yb3ELW09H90jqGIcYEP1hOP0nT 5pjslq+FNJpwTV+k7K5VdCbfqb+4q3QaDLpnn8H5onPehyEW9v/rvn0V+7LtvByS4Kg/ OlqXI8a2QBxEHQIEGnrwdOW1oF2W66yX7KxfR2BlFDUwvV63RBU8lk8TIs6vUJ2Qosbj blG3b2d8zh+I5eBxhd1JQDvCoc1l+EqCyMr76+qccB0ZuOTDKtZ90F/2S1UQQcFrx2om uzHQhRQ6qE3yxmZYoSFHMgRax4sfW9PuLBqF5C4zduJ1MCgVMMd5XBxcD1VO0uULoW+/ RAnA== X-Received: by 10.50.91.195 with SMTP id cg3mr1730596igb.57.1358259141013; Tue, 15 Jan 2013 06:12:21 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id c3sm2041455igj.1.2013.01.15.06.12.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 06:12:19 -0800 (PST) Message-ID: <50F563BE.7010609@gmail.com> Date: Tue, 15 Jan 2013 09:12:14 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: IBM blade server abysmal disk write performances Content-Type: multipart/mixed; boundary="------------090506050005050808080502" X-Mailman-Approved-At: Tue, 15 Jan 2013 14:48:11 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:12:21 -0000 This is a multi-part message in MIME format. --------------090506050005050808080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server (HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1. CentOS: 100000+0 records in 100000+0 records out 51200000 bytes (51 MB) copied, 1.97883 s, 25.9 MB/s FreeBSD 9.1: 10000+0 records in 10000+0 records out 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) FreeBSD diskinfo output: da0 512 # sectorsize 300000000000 # mediasize in bytes (279G) 585937500 # mediasize in sectors 0 # stripesize 0 # stripeoffset 36472 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. PQJTT0NB # Disk ident. Seek times: Full stroke: 250 iter in 2.690773 sec = 10.763 msec Half stroke: 250 iter in 1.970564 sec = 7.882 msec Quarter stroke: 500 iter in 3.153904 sec = 6.308 msec Short forward: 400 iter in 1.175194 sec = 2.938 msec Short backward: 400 iter in 1.371584 sec = 3.429 msec Seq outer: 2048 iter in 0.125570 sec = 0.061 msec Seq inner: 2048 iter in 0.244062 sec = 0.119 msec Transfer rates: outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec middle: 102400 kbytes in 0.747424 sec = 137004 kbytes/sec inside: 102400 kbytes in 1.051036 sec = 97428 kbytes/sec Both OS with default kernel options. Anyone can give me a hint on whats wrong? I would greatly appreciate. Best Regards, Karim. PS: Attached verbose dmesg of both Linux and FreeBSD. --------------090506050005050808080502 Content-Type: text/plain; charset=windows-1252; name="centos.dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="centos.dmesg" Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.32-279.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jun 22 12:19:21 UTC 2012 Command line: initrd=initrd0.img root=live:CDLABEL=CentOS-6.3-x86_64-LiveCD rootfstype=auto ro liveimg quiet nodiskmount nolvmmount rhgb vga=791 rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009c000 (usable) BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007cf84000 (usable) BIOS-e820: 000000007cf84000 - 000000007d048000 (reserved) BIOS-e820: 000000007d048000 - 000000007d746000 (usable) BIOS-e820: 000000007d746000 - 000000007d7f6000 (reserved) BIOS-e820: 000000007d7f6000 - 000000007f68f000 (usable) BIOS-e820: 000000007f68f000 - 000000007f6df000 (reserved) BIOS-e820: 000000007f6df000 - 000000007f7df000 (ACPI NVS) BIOS-e820: 000000007f7df000 - 000000007f7ff000 (ACPI data) BIOS-e820: 000000007f7ff000 - 000000007f800000 (usable) BIOS-e820: 000000007f800000 - 0000000090000000 (reserved) BIOS-e820: 00000000fc000000 - 00000000fd000000 (reserved) BIOS-e820: 00000000fed1c000 - 00000000fed20000 (reserved) BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000680000000 (usable) DMI 2.5 present. SMBIOS version 2.5 @ 0xFDF40 DMI: IBM BladeCenter HS22 -[7870B6U]-/94Y8600, BIOS -[P9E158AUS-1.19]- 11/25/2012 e820 update range: 0000000000000000 - 0000000000001000 (usable) ==> (reserved) e820 remove range: 00000000000a0000 - 0000000000100000 (usable) last_pfn = 0x680000 max_arch_pfn = 0x400000000 MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-FFFFF uncachable MTRR variable ranges enabled: 0 base 0000000000 mask FF80000000 write-back 1 base 0100000000 mask FF00000000 write-back 2 base 0200000000 mask FE00000000 write-back 3 base 0400000000 mask FC00000000 write-back 4 disabled 5 disabled 6 disabled 7 disabled 8 disabled 9 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 e820 update range: 0000000080000000 - 0000000100000000 (usable) ==> (reserved) last_pfn = 0x7f800 max_arch_pfn = 0x400000000 initial memory mapped : 0 - 20000000 Using GB pages for direct mapping init_memory_mapping: 0000000000000000-000000007f800000 0000000000 - 0040000000 page 1G 0040000000 - 007f800000 page 2M kernel direct mapping tables up to 7f800000 @ 8000-a000 init_memory_mapping: 0000000100000000-0000000680000000 0100000000 - 0680000000 page 1G kernel direct mapping tables up to 680000000 @ 9000-a000 RAMDISK: 7c5ae000 - 7cf6213d ACPI: RSDP 00000000000fdfd0 00024 (v02 IBM ) ACPI: XSDT 000000007f7fe120 00074 (v01 IBM BLADE 00000000 01000013) ACPI: FACP 000000007f7fb000 000F4 (v04 IBM BLADE 00000000 IBM 01000013) ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20090903/tbfadt-607) ACPI: DSDT 000000007f7f8000 0224E (v01 IBM BLADE 00000003 IBM 01000013) ACPI: FACS 000000007f6eb000 00040 ACPI: TCPA 000000007f7fd000 00064 (v00 00000000 00000000) ACPI: APIC 000000007f7f7000 0011E (v02 IBM BLADE 00000000 IBM 01000013) ACPI: MCFG 000000007f7f6000 0003C (v01 IBM BLADE 00000001 IBM 01000013) ACPI: SLIC 000000007f7f5000 00176 (v01 IBM BLADE 00000000 IBM 01000013) ACPI: HPET 000000007f7f4000 00038 (v01 IBM BLADE 00000001 IBM 01000013) ACPI: SSDT 000000007f7f3000 00183 (v02 IBM CPUSCOPE 00004000 IBM 01000013) ACPI: SSDT 000000007f7f2000 00699 (v02 IBM CPUWYVRN 00004000 IBM 01000013) ACPI: SSDT 000000007f7ef000 02B7C (v02 IBM PSTATEPM 00004000 IBM 01000013) ACPI: ERST 000000007f7ee000 00230 (v01 IBM BLADE 00000001 IBM 01000013) ACPI: Local APIC address 0xfee00000 No NUMA configuration found Faking a node at 0000000000000000-0000000680000000 Bootmem setup node 0 0000000000000000-0000000680000000 NODE_DATA [0000000000009000 - 000000000003cfff] bootmap [0000000000100000 - 00000000001cffff] pages d0 (7 early reservations) ==> bootmem [0000000000 - 0680000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 - 0000008000] #2 [0001000000 - 0002012024] TEXT DATA BSS ==> [0001000000 - 0002012024] #3 [007c5ae000 - 007cf6213d] RAMDISK ==> [007c5ae000 - 007cf6213d] #4 [000009c000 - 0000100000] BIOS reserved ==> [000009c000 - 0000100000] #5 [0002013000 - 0002013820] BRK ==> [0002013000 - 0002013820] #6 [0000008000 - 0000009000] PGTABLE ==> [0000008000 - 0000009000] found SMP MP-table at [ffff88000009c140] 9c140 [ffffea0000000000-ffffea0016bfffff] PMD -> [ffff880028600000-ffff88003d5fffff] on node 0 Zone PFN ranges: DMA 0x00000001 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal 0x00100000 -> 0x00680000 Movable zone start PFN for each node early_node_map[6] active PFN ranges 0: 0x00000001 -> 0x0000009c 0: 0x00000100 -> 0x0007cf84 0: 0x0007d048 -> 0x0007d746 0: 0x0007d7f6 -> 0x0007f68f 0: 0x0007f7ff -> 0x0007f800 0: 0x00100000 -> 0x00680000 On node 0 totalpages: 6288567 DMA zone: 56 pages used for memmap DMA zone: 104 pages reserved DMA zone: 3835 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 503124 pages, LIFO batch:31 Normal zone: 78848 pages used for memmap Normal zone: 5688320 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x588 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x10] enabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x12] enabled) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x14] enabled) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x20] disabled) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x22] disabled) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x24] disabled) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x30] disabled) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x32] disabled) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x34] disabled) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x01] enabled) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x03] enabled) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x05] enabled) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x11] enabled) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x13] enabled) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x15] enabled) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x21] disabled) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x23] disabled) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x25] disabled) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x31] disabled) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x33] disabled) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x35] disabled) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[24]) IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8086a301 base: 0xfed00000 SMP: Allowing 24 CPUs, 12 hotplug CPUs nr_irqs_gsi: 48 PM: Registered nosave memory: 000000000009c000 - 00000000000a0000 PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 PM: Registered nosave memory: 000000007cf84000 - 000000007d048000 PM: Registered nosave memory: 000000007d746000 - 000000007d7f6000 PM: Registered nosave memory: 000000007f68f000 - 000000007f6df000 PM: Registered nosave memory: 000000007f6df000 - 000000007f7df000 PM: Registered nosave memory: 000000007f7df000 - 000000007f7ff000 PM: Registered nosave memory: 000000007f800000 - 0000000090000000 PM: Registered nosave memory: 0000000090000000 - 00000000fc000000 PM: Registered nosave memory: 00000000fc000000 - 00000000fd000000 PM: Registered nosave memory: 00000000fd000000 - 00000000fed1c000 PM: Registered nosave memory: 00000000fed1c000 - 00000000fed20000 PM: Registered nosave memory: 00000000fed20000 - 00000000ff800000 PM: Registered nosave memory: 00000000ff800000 - 0000000100000000 Allocating PCI resources starting at 90000000 (gap: 90000000:6c000000) Booting paravirtualized kernel on bare hardware NR_CPUS:4096 nr_cpumask_bits:24 nr_cpu_ids:24 nr_node_ids:1 PERCPU: Embedded 31 pages/cpu @ffff88003d600000 s94424 r8192 d24360 u131072 pcpu-alloc: s94424 r8192 d24360 u131072 alloc=1*2097152 pcpu-alloc: [0] 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 pcpu-alloc: [0] 16 17 18 19 20 21 22 23 -- -- -- -- -- -- -- -- Built 1 zonelists in Zone order, mobility grouping on. Total pages: 6195279 Policy zone: Normal Kernel command line: initrd=initrd0.img root=live:CDLABEL=CentOS-6.3-x86_64-LiveCD rootfstype=auto ro liveimg quiet nodiskmount nolvmmount rhgb vga=791 rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 PID hash table entries: 4096 (order: 3, 32768 bytes) Checking aperture... No AGP bridge found PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000 software IO TLB at phys 0x20000000 - 0x24000000 Memory: 24714236k/27262976k available (5151k kernel code, 2108708k absent, 440032k reserved, 7166k data, 1260k init) Hierarchical RCU implementation. NR_IRQS:33024 nr_irqs:1008 Extended CMOS year: 2000 Console: colour dummy device 80x25 console [tty0] enabled allocated 201326592 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups hpet clockevent registered Fast TSC calibration using PIT Detected 2533.359 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 5066.71 BogoMIPS (lpj=2533359) pid_max: default: 32768 minimum: 301 Security Framework initialized SELinux: Initializing. SELinux: Starting in permissive mode Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes) Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes) Mount-cache hash table entries: 256 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys net_cls Initializing cgroup subsys blkio Initializing cgroup subsys perf_event Initializing cgroup subsys net_prio CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 mce: CPU supports 9 MCE banks CPU0: Thermal monitoring enabled (TM1) using mwait in idle threads. ACPI: Core revision 20090903 ftrace: converting mcount calls to 0f 1f 44 00 00 ftrace: allocating 21015 entries in 83 pages Setting APIC routing to physical flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel(R) Xeon(R) CPU E5649 @ 2.53GHz stepping 02 Performance Events: PEBS fmt1+, Westmere events, Intel PMU driver. ... version: 3 ... bit width: 48 ... generic registers: 4 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 000000070000000f NMI watchdog enabled, takes one hw-pmu counter. Booting Node 0, Processors #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 Brought up 12 CPUs Total of 12 processors activated (60800.61 BogoMIPS). sizeof(vma)=200 bytes sizeof(page)=56 bytes sizeof(inode)=592 bytes sizeof(dentry)=192 bytes sizeof(ext3inode)=800 bytes sizeof(buffer_head)=104 bytes sizeof(skbuff)=232 bytes sizeof(task_struct)=2648 bytes devtmpfs: initialized PM: Registering ACPI NVS region at 7f6df000 (1048576 bytes) regulator: core version 0.5 NET: Registered protocol family 16 ACPI FADT declares the system doesn't support PCIe ASPM, so disable it ACPI: bus type pci registered PCI: MCFG configuration 0: base 80000000 segment 0 buses 0 - 255 PCI: MCFG area at 80000000 reserved in E820 PCI: Using MMCONFIG at 80000000 - 8fffffff PCI: Using configuration type 1 for base access bio: create slab at 0 ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S1 S5) ACPI: Using IOAPIC for interrupt routing ACPI: No dock devices found. HEST: Table not found. PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) pci_root PNP0A08:00: host bridge window [io 0x0000-0x0cf7] pci_root PNP0A08:00: host bridge window [io 0x0d00-0xffff] pci_root PNP0A08:00: host bridge window [mem 0x000a0000-0x000bffff] pci_root PNP0A08:00: host bridge window [mem 0x90000000-0xfdffffff] pci_root PNP0A08:00: host bridge window [mem 0x7f00000000] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold pci 0000:00:00.0: PME# disabled pci 0000:00:01.0: PME# supported from D0 D3hot D3cold pci 0000:00:01.0: PME# disabled pci 0000:00:03.0: PME# supported from D0 D3hot D3cold pci 0000:00:03.0: PME# disabled pci 0000:00:05.0: PME# supported from D0 D3hot D3cold pci 0000:00:05.0: PME# disabled pci 0000:00:07.0: PME# supported from D0 D3hot D3cold pci 0000:00:07.0: PME# disabled pci 0000:00:08.0: PME# supported from D0 D3hot D3cold pci 0000:00:08.0: PME# disabled pci 0000:00:09.0: PME# supported from D0 D3hot D3cold pci 0000:00:09.0: PME# disabled pci 0000:00:16.0: reg 10: [mem 0x9ba00000-0x9ba03fff 64bit] pci 0000:00:16.1: reg 10: [mem 0x9ba04000-0x9ba07fff 64bit] pci 0000:00:16.2: reg 10: [mem 0x9ba08000-0x9ba0bfff 64bit] pci 0000:00:16.3: reg 10: [mem 0x9ba0c000-0x9ba0ffff 64bit] pci 0000:00:16.4: reg 10: [mem 0x9ba10000-0x9ba13fff 64bit] pci 0000:00:16.5: reg 10: [mem 0x9ba14000-0x9ba17fff 64bit] pci 0000:00:16.6: reg 10: [mem 0x9ba18000-0x9ba1bfff 64bit] pci 0000:00:16.7: reg 10: [mem 0x9ba1c000-0x9ba1ffff 64bit] pci 0000:00:1a.0: reg 20: [io 0x2080-0x209f] pci 0000:00:1a.7: reg 10: [mem 0x9ba21000-0x9ba213ff] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold pci 0000:00:1a.7: PME# disabled pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold pci 0000:00:1c.0: PME# disabled pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold pci 0000:00:1c.4: PME# disabled pci 0000:00:1d.0: reg 20: [io 0x2060-0x207f] pci 0000:00:1d.1: reg 20: [io 0x2040-0x205f] pci 0000:00:1d.2: reg 20: [io 0x2020-0x203f] pci 0000:00:1d.7: reg 10: [mem 0x9ba20000-0x9ba203ff] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold pci 0000:00:1d.7: PME# disabled pci 0000:00:1f.3: reg 10: [mem 0x9ba22000-0x9ba220ff 64bit] pci 0000:00:1f.3: reg 20: [io 0x2000-0x201f] pci 0000:0b:00.0: reg 10: [io 0x1000-0x10ff] pci 0000:0b:00.0: reg 14: [mem 0x9b910000-0x9b913fff 64bit] pci 0000:0b:00.0: reg 1c: [mem 0x9b900000-0x9b90ffff 64bit] pci 0000:0b:00.0: reg 30: [mem 0xffe00000-0xffffffff pref] pci 0000:0b:00.0: supports D1 D2 pci 0000:00:01.0: PCI bridge to [bus 0b-0f] pci 0000:00:01.0: bridge window [io 0x1000-0x1fff] pci 0000:00:01.0: bridge window [mem 0x9b900000-0x9b9fffff] pci 0000:00:01.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:00:03.0: PCI bridge to [bus 15-19] pci 0000:00:03.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) pci 0000:00:03.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:00:05.0: PCI bridge to [bus 1a-1e] pci 0000:00:05.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:05.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) pci 0000:00:05.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:10:00.0: reg 10: [mem 0x96000000-0x97ffffff 64bit] pci 0000:10:00.0: PME# supported from D0 D3hot D3cold pci 0000:10:00.0: PME# disabled pci 0000:10:00.1: reg 10: [mem 0x98000000-0x99ffffff 64bit] pci 0000:10:00.1: PME# supported from D0 D3hot D3cold pci 0000:10:00.1: PME# disabled pci 0000:00:07.0: PCI bridge to [bus 10-14] pci 0000:00:07.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:07.0: bridge window [mem 0x96000000-0x99ffffff] pci 0000:00:07.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:00:08.0: PCI bridge to [bus 1f-23] pci 0000:00:08.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:08.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) pci 0000:00:08.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:24:00.0: reg 10: [mem 0x92000000-0x93ffffff 64bit] pci 0000:24:00.0: reg 30: [mem 0xfff80000-0xffffffff pref] pci 0000:24:00.0: PME# supported from D0 D3hot D3cold pci 0000:24:00.0: PME# disabled pci 0000:24:00.1: reg 10: [mem 0x94000000-0x95ffffff 64bit] pci 0000:24:00.1: reg 30: [mem 0xfff80000-0xffffffff pref] pci 0000:24:00.1: PME# supported from D0 D3hot D3cold pci 0000:24:00.1: PME# disabled pci 0000:00:09.0: PCI bridge to [bus 24-28] pci 0000:00:09.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:09.0: bridge window [mem 0x92000000-0x95ffffff] pci 0000:00:09.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:00:1c.0: PCI bridge to [bus 01-05] pci 0000:00:1c.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) pci 0000:00:1c.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:06:00.0: PME# supported from D0 D3hot D3cold pci 0000:06:00.0: PME# disabled pci 0000:00:1c.4: PCI bridge to [bus 06-0a] pci 0000:00:1c.4: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:1c.4: bridge window [mem 0x9b000000-0x9b8fffff] pci 0000:00:1c.4: bridge window [mem 0x9a000000-0x9affffff 64bit pref] pci 0000:07:00.0: reg 10: [mem 0x9a000000-0x9affffff pref] pci 0000:07:00.0: reg 14: [mem 0x9b800000-0x9b803fff] pci 0000:07:00.0: reg 18: [mem 0x9b000000-0x9b7fffff] pci 0000:06:00.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:06:00.0: bridge window [mem 0x9b000000-0x9b8fffff] pci 0000:06:00.0: bridge window [mem 0x9a000000-0x9affffff pref] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0xf000-0x0000] (disabled) pci 0000:00:1e.0: bridge window [mem 0xfff00000-0x000fffff] (disabled) pci 0000:00:1e.0: bridge window [mem 0xfff00000-0x000fffff pref] (disabled) pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (subtractive decode) pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x90000000-0xfdffffff] (subtractive decode) pci 0000:00:1e.0: bridge window [mem 0x7f00000000] (subtractive decode) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] pci0000:00: Requesting ACPI _OSC control (0x1d) Firmware did not grant requested _OSC control Unable to assume _OSC PCIe control. Disabling ASPM ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 *15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled. vgaarb: device added: PCI:0000:07:00.0,decodes=io+mem,owns=io+mem,locks=none vgaarb: loaded vgaarb: bridge control possible 0000:07:00.0 SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: old code would have set cacheline size to 32 bytes, but clflush_size = 64 PCI: pci_cache_line_size set to 64 bytes NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default HPET: 4 timers in total, 0 timers will be used for per-cpu timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0 hpet0: 4 comparators, 64-bit 14.318180 MHz counter Switching to clocksource hpet pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: [io 0x0cf8-0x0cff] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) pnp 00:01: [io 0x0000-0x001f] pnp 00:01: [io 0x0080-0x0091] pnp 00:01: [io 0x0093-0x009f] pnp 00:01: [io 0x00c0-0x00df] pnp 00:01: [dma 4] pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active) pnp 00:02: [io 0x0070-0x0077] pnp 00:02: [irq 8] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active) pnp 00:03: [io 0x00f0] pnp 00:03: [irq 13] pnp 00:03: Plug and Play ACPI device, IDs PNP0c04 (active) pnp 00:04: [io 0x0061] pnp 00:04: Plug and Play ACPI device, IDs PNP0800 (active) pnp 00:05: [mem 0xfed00000-0xfed003ff] pnp 00:05: Plug and Play ACPI device, IDs PNP0103 PNP0c01 (active) pnp 00:06: [io 0x004e-0x004f] pnp 00:06: [io 0x0060] pnp 00:06: [io 0x0062-0x0066] pnp 00:06: [io 0x0070] pnp 00:06: [io 0x0092] pnp 00:06: [io 0x00b2-0x00b3] pnp 00:06: [io 0x00e8-0x00ef] pnp 00:06: [io 0x0400-0x043f] pnp 00:06: [io 0x0440-0x045f] pnp 00:06: [io 0x0460-0x047f] pnp 00:06: [io 0x0580-0x05ff] pnp 00:06: [io 0x05e0-0x05ff] pnp 00:06: [io 0x0cf9] pnp 00:06: Plug and Play ACPI device, IDs PNP0c02 (active) pnp 00:07: [io 0x03f8-0x03ff] pnp 00:07: [irq 4] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active) pnp 00:08: [io 0x02f8-0x02ff] pnp 00:08: [irq 3] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active) pnp 00:09: [mem 0xfed40000-0xfed44fff] pnp 00:09: Plug and Play ACPI device, IDs PNP0c31 (active) pnp 00:0a: [mem 0xfed1c000-0xfed1ffff] pnp 00:0a: [mem 0xfec00000-0xfecfffff] pnp 00:0a: [mem 0xfee00000-0xfeefffff] pnp 00:0a: [mem 0x80000000-0x8fffffff] pnp 00:0a: [mem 0xffc00000-0xffffffff] pnp 00:0a: [mem 0xfeb00000-0xfebfffff] pnp 00:0a: [mem 0xfe710000-0xfe711fff] pnp 00:0a: [mem 0xfe800000-0xfe9fffff] pnp 00:0a: [mem 0xfc000000-0xfcffffff] pnp 00:0a: [mem 0xfea00000-0xfeafffff] pnp 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active) pnp 00:0b: [io 0x0ca0-0x0ca1] pnp 00:0b: [io 0x0ca4-0x0ca9] pnp 00:0b: [io 0x0caa-0x0cab] pnp 00:0b: [io 0x0cac-0x0ccb] pnp 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active) pnp 00:0c: [io 0x0ca2] pnp 00:0c: [io 0x0ca3] pnp 00:0c: Plug and Play ACPI device, IDs IPI0001 PNP0c02 (active) pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered system 00:05: [mem 0xfed00000-0xfed003ff] has been reserved system 00:06: [io 0x0400-0x043f] has been reserved system 00:06: [io 0x0440-0x045f] has been reserved system 00:06: [io 0x0460-0x047f] has been reserved system 00:06: [io 0x0580-0x05ff] has been reserved system 00:06: [io 0x05e0-0x05ff] has been reserved system 00:06: [io 0x0cf9] could not be reserved system 00:0a: [mem 0xfed1c000-0xfed1ffff] has been reserved system 00:0a: [mem 0xfec00000-0xfecfffff] could not be reserved system 00:0a: [mem 0xfee00000-0xfeefffff] has been reserved system 00:0a: [mem 0x80000000-0x8fffffff] has been reserved system 00:0a: [mem 0xffc00000-0xffffffff] has been reserved system 00:0a: [mem 0xfeb00000-0xfebfffff] has been reserved system 00:0a: [mem 0xfe710000-0xfe711fff] has been reserved system 00:0a: [mem 0xfe800000-0xfe9fffff] has been reserved system 00:0a: [mem 0xfc000000-0xfcffffff] has been reserved system 00:0a: [mem 0xfea00000-0xfeafffff] has been reserved system 00:0b: [io 0x0ca0-0x0ca1] has been reserved system 00:0b: [io 0x0ca4-0x0ca9] has been reserved system 00:0b: [io 0x0caa-0x0cab] has been reserved system 00:0b: [io 0x0cac-0x0ccb] has been reserved system 00:0c: [io 0x0ca2] has been reserved system 00:0c: [io 0x0ca3] has been reserved pci 0000:0b:00.0: no compatible bridge window for [mem 0xffe00000-0xffffffff pref] pci 0000:24:00.0: no compatible bridge window for [mem 0xfff80000-0xffffffff pref] pci 0000:24:00.1: no compatible bridge window for [mem 0xfff80000-0xffffffff pref] PCI: max bus depth: 2 pci_try_num: 3 pci 0000:00:01.0: BAR 15: assigned [mem 0x90000000-0x901fffff pref] pci 0000:00:09.0: BAR 15: assigned [mem 0x90200000-0x902fffff pref] pci 0000:0b:00.0: BAR 6: assigned [mem 0x90000000-0x901fffff pref] pci 0000:00:01.0: PCI bridge to [bus 0b-0f] pci 0000:00:01.0: PCI bridge to [bus 0b-0f] pci 0000:00:01.0: bridge window [io 0x1000-0x1fff] pci 0000:00:01.0: bridge window [mem 0x9b900000-0x9b9fffff] pci 0000:00:01.0: bridge window [mem 0x90000000-0x901fffff pref] pci 0000:00:03.0: PCI bridge to [bus 15-19] pci 0000:00:03.0: PCI bridge to [bus 15-19] pci 0000:00:03.0: bridge window [io disabled] pci 0000:00:03.0: bridge window [mem disabled] pci 0000:00:03.0: bridge window [mem pref disabled] pci 0000:00:05.0: PCI bridge to [bus 1a-1e] pci 0000:00:05.0: PCI bridge to [bus 1a-1e] pci 0000:00:05.0: bridge window [io disabled] pci 0000:00:05.0: bridge window [mem disabled] pci 0000:00:05.0: bridge window [mem pref disabled] pci 0000:00:07.0: PCI bridge to [bus 10-14] pci 0000:00:07.0: PCI bridge to [bus 10-14] pci 0000:00:07.0: bridge window [io disabled] pci 0000:00:07.0: bridge window [mem 0x96000000-0x99ffffff] pci 0000:00:07.0: bridge window [mem pref disabled] pci 0000:00:08.0: PCI bridge to [bus 1f-23] pci 0000:00:08.0: PCI bridge to [bus 1f-23] pci 0000:00:08.0: bridge window [io disabled] pci 0000:00:08.0: bridge window [mem disabled] pci 0000:00:08.0: bridge window [mem pref disabled] pci 0000:24:00.0: BAR 6: assigned [mem 0x90200000-0x9027ffff pref] pci 0000:24:00.1: BAR 6: assigned [mem 0x90280000-0x902fffff pref] pci 0000:00:09.0: PCI bridge to [bus 24-28] pci 0000:00:09.0: PCI bridge to [bus 24-28] pci 0000:00:09.0: bridge window [io disabled] pci 0000:00:09.0: bridge window [mem 0x92000000-0x95ffffff] pci 0000:00:09.0: bridge window [mem 0x90200000-0x902fffff pref] pci 0000:00:1c.0: PCI bridge to [bus 01-05] pci 0000:00:1c.0: PCI bridge to [bus 01-05] pci 0000:00:1c.0: bridge window [io disabled] pci 0000:00:1c.0: bridge window [mem disabled] pci 0000:00:1c.0: bridge window [mem pref disabled] pci 0000:06:00.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: PCI bridge to [bus 07-07] pci 0000:06:00.0: bridge window [io disabled] pci 0000:06:00.0: bridge window [mem 0x9b000000-0x9b8fffff] pci 0000:06:00.0: bridge window [mem 0x9a000000-0x9affffff pref] pci 0000:00:1c.4: PCI bridge to [bus 06-0a] pci 0000:00:1c.4: PCI bridge to [bus 06-0a] pci 0000:00:1c.4: bridge window [io disabled] pci 0000:00:1c.4: bridge window [mem 0x9b000000-0x9b8fffff] pci 0000:00:1c.4: bridge window [mem 0x9a000000-0x9affffff 64bit pref] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] pci 0000:00:1e.0: PCI bridge to [bus 29-2d] pci 0000:00:1e.0: bridge window [io disabled] pci 0000:00:1e.0: bridge window [mem disabled] pci 0000:00:1e.0: bridge window [mem pref disabled] alloc irq_desc for 28 on node -1 alloc kstat_irqs on node -1 pci 0000:00:01.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28 pci 0000:00:01.0: setting latency timer to 64 alloc irq_desc for 24 on node -1 alloc kstat_irqs on node -1 pci 0000:00:03.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 pci 0000:00:03.0: setting latency timer to 64 alloc irq_desc for 26 on node -1 alloc kstat_irqs on node -1 pci 0000:00:05.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26 pci 0000:00:05.0: setting latency timer to 64 alloc irq_desc for 30 on node -1 alloc kstat_irqs on node -1 pci 0000:00:07.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30 pci 0000:00:07.0: setting latency timer to 64 alloc irq_desc for 31 on node -1 alloc kstat_irqs on node -1 pci 0000:00:08.0: PCI INT A -> GSI 31 (level, low) -> IRQ 31 pci 0000:00:08.0: setting latency timer to 64 alloc irq_desc for 32 on node -1 alloc kstat_irqs on node -1 pci 0000:00:09.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 pci 0000:00:09.0: setting latency timer to 64 alloc irq_desc for 20 on node -1 alloc kstat_irqs on node -1 pci 0000:00:1c.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 pci 0000:00:1c.0: setting latency timer to 64 pci 0000:00:1c.4: PCI INT A -> GSI 20 (level, low) -> IRQ 20 pci 0000:00:1c.4: setting latency timer to 64 pci 0000:06:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 pci 0000:06:00.0: setting latency timer to 64 pci 0000:00:1e.0: setting latency timer to 64 pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] pci_bus 0000:00: resource 7 [mem 0x90000000-0xfdffffff] pci_bus 0000:00: resource 8 [mem 0x7f00000000] pci_bus 0000:0b: resource 0 [io 0x1000-0x1fff] pci_bus 0000:0b: resource 1 [mem 0x9b900000-0x9b9fffff] pci_bus 0000:0b: resource 2 [mem 0x90000000-0x901fffff pref] pci_bus 0000:10: resource 1 [mem 0x96000000-0x99ffffff] pci_bus 0000:24: resource 1 [mem 0x92000000-0x95ffffff] pci_bus 0000:24: resource 2 [mem 0x90200000-0x902fffff pref] pci_bus 0000:06: resource 1 [mem 0x9b000000-0x9b8fffff] pci_bus 0000:06: resource 2 [mem 0x9a000000-0x9affffff 64bit pref] pci_bus 0000:07: resource 1 [mem 0x9b000000-0x9b8fffff] pci_bus 0000:07: resource 2 [mem 0x9a000000-0x9affffff pref] pci_bus 0000:29: resource 4 [io 0x0000-0x0cf7] pci_bus 0000:29: resource 5 [io 0x0d00-0xffff] pci_bus 0000:29: resource 6 [mem 0x000a0000-0x000bffff] pci_bus 0000:29: resource 7 [mem 0x90000000-0xfdffffff] pci_bus 0000:29: resource 8 [mem 0x7f00000000] NET: Registered protocol family 2 IP route cache hash table entries: 524288 (order: 10, 4194304 bytes) TCP established hash table entries: 524288 (order: 11, 8388608 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 524288 bind 65536) TCP reno registered NET: Registered protocol family 1 alloc irq_desc for 22 on node -1 alloc kstat_irqs on node -1 pci 0000:00:1a.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 pci 0000:00:1a.0: PCI INT A disabled alloc irq_desc for 16 on node -1 alloc kstat_irqs on node -1 pci 0000:00:1a.7: PCI INT C -> GSI 16 (level, low) -> IRQ 16 pci 0000:00:1a.7: PCI INT C disabled pci 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 pci 0000:00:1d.0: PCI INT A disabled pci 0000:00:1d.1: PCI INT B -> GSI 20 (level, low) -> IRQ 20 pci 0000:00:1d.1: PCI INT B disabled alloc irq_desc for 21 on node -1 alloc kstat_irqs on node -1 pci 0000:00:1d.2: PCI INT C -> GSI 21 (level, low) -> IRQ 21 pci 0000:00:1d.2: PCI INT C disabled pci 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 pci 0000:00:1d.7: PCI INT A disabled pci 0000:07:00.0: Boot video device Trying to unpack rootfs image as initramfs... Freeing initrd memory: 9936k freed audit: initializing netlink socket (disabled) type=2000 audit(1358235727.332:1): initialized HugeTLB registered 2 MB page size, pre-allocated 0 pages VFS: Disk quotas dquot_6.5.2 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) msgmni has been set to 32768 SELinux: Registering netfilter hooks alg: No test for stdrng (krng) ksign: Installing public key data Loading keyring - Added public key 4CB4AFE45B2E4608 - User ID: CentOS (Kernel Module GPG key) Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pcieport 0000:00:1c.0: setting latency timer to 64 alloc irq_desc for 48 on node -1 alloc kstat_irqs on node -1 pcieport 0000:00:1c.0: irq 48 for MSI/MSI-X pcieport 0000:00:1c.4: setting latency timer to 64 alloc irq_desc for 49 on node -1 alloc kstat_irqs on node -1 pcieport 0000:00:1c.4: irq 49 for MSI/MSI-X pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp: PCI Express Hot Plug Controller Driver version: 0.4 acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 vesafb: framebuffer at 0x9a000000, mapped to 0xffffc90013e00000, using 3072k, total 16384k vesafb: mode is 1024x768x16, linelength=2048, pages=9 vesafb: scrolling: redraw vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device intel_idle: MWAIT substates: 0x1120 intel_idle: v0.4 model 0x2C intel_idle: lapic_timer_reliable_states 0xffffffff input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 ACPI: Power Button [PWRF] ACPI: acpi_idle yielding to intel_idle [Firmware Bug]: APEI: Invalid bit width in GAR [0x7f6f1038/3/0] GHES: HEST is not enabled! Non-volatile memory driver v1.3 Linux agpgart interface v0.103 tpm_tis 00:09: 1.2 TPM (device-id 0xFE, rev-id 70) crash memory driver: version 1.1 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A brd: module loaded loop: module loaded input: Macintosh mouse button emulation as /devices/virtual/input/input1 Fixed MDIO Bus: probed ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 16 (level, low) -> IRQ 16 ehci_hcd 0000:00:1a.7: setting latency timer to 64 ehci_hcd 0000:00:1a.7: EHCI Host Controller ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:1a.7: debug port 1 ehci_hcd 0000:00:1a.7: cache line size of 64 is not supported ehci_hcd 0000:00:1a.7: irq 16, io mem 0x9ba21000 ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.32-279.el6.x86_64 ehci_hcd usb usb1: SerialNumber: 0000:00:1a.7 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 6 ports detected ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 20 (level, low) -> IRQ 20 ehci_hcd 0000:00:1d.7: setting latency timer to 64 ehci_hcd 0000:00:1d.7: EHCI Host Controller ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 ehci_hcd 0000:00:1d.7: debug port 1 ehci_hcd 0000:00:1d.7: cache line size of 64 is not supported ehci_hcd 0000:00:1d.7: irq 20, io mem 0x9ba20000 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 2.6.32-279.el6.x86_64 ehci_hcd usb usb2: SerialNumber: 0000:00:1d.7 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 6 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver uhci_hcd: USB Universal Host Controller Interface driver uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 uhci_hcd 0000:00:1a.0: setting latency timer to 64 uhci_hcd 0000:00:1a.0: UHCI Host Controller uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 uhci_hcd 0000:00:1a.0: irq 22, io base 0x00002080 usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: UHCI Host Controller usb usb3: Manufacturer: Linux 2.6.32-279.el6.x86_64 uhci_hcd usb usb3: SerialNumber: 0000:00:1a.0 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 uhci_hcd 0000:00:1d.0: setting latency timer to 64 uhci_hcd 0000:00:1d.0: UHCI Host Controller uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4 uhci_hcd 0000:00:1d.0: irq 20, io base 0x00002060 usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: UHCI Host Controller usb usb4: Manufacturer: Linux 2.6.32-279.el6.x86_64 uhci_hcd usb usb4: SerialNumber: 0000:00:1d.0 usb usb4: configuration #1 chosen from 1 choice hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 20 (level, low) -> IRQ 20 uhci_hcd 0000:00:1d.1: setting latency timer to 64 uhci_hcd 0000:00:1d.1: UHCI Host Controller uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5 uhci_hcd 0000:00:1d.1: irq 20, io base 0x00002040 usb usb5: New USB device found, idVendor=1d6b, idProduct=0001 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: UHCI Host Controller usb usb5: Manufacturer: Linux 2.6.32-279.el6.x86_64 uhci_hcd usb usb5: SerialNumber: 0000:00:1d.1 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 21 (level, low) -> IRQ 21 uhci_hcd 0000:00:1d.2: setting latency timer to 64 uhci_hcd 0000:00:1d.2: UHCI Host Controller uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6 uhci_hcd 0000:00:1d.2: irq 21, io base 0x00002020 usb usb6: New USB device found, idVendor=1d6b, idProduct=0001 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: UHCI Host Controller usb usb6: Manufacturer: Linux 2.6.32-279.el6.x86_64 uhci_hcd usb usb6: SerialNumber: 0000:00:1d.2 usb usb6: configuration #1 chosen from 1 choice hub 6-0:1.0: USB hub found hub 6-0:1.0: 2 ports detected PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice rtc_cmos 00:02: RTC can wake from S4 rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 rtc0: alarms up to one month, y3k, 242 bytes nvram, hpet irqs cpuidle: using governor ladder cpuidle: using governor menu EFI Variables Facility v0.08 2004-May-17 usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 registered taskstats version 1 rtc_cmos 00:02: setting system clock to 2013-01-15 07:42:08 UTC (1358235728) Initalizing network drop monitor service Freeing unused kernel memory: 1260k freed Write protecting the kernel read-only data: 10240k Freeing unused kernel memory: 972k freed Freeing unused kernel memory: 1732k freed dracut: dracut-004-283.el6 dracut: root was live:/dev/disk/by-label/CentOS-6.3-x86_64-LiveCD, liveroot is now live:CDLABEL=CentOS-6.3-x86_64-LiveCD usb 1-1: new high speed USB device number 2 using ehci_hcd device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.22.6-ioctl (2011-10-19) initialised: dm-devel@redhat.com udev: starting version 147 Refined TSC clocksource calibration: 2533.422 MHz. dracut: Starting plymouth daemon Switching to clocksource tsc usb 1-1: New USB device found, idVendor=04b3, idProduct=4012 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: IBM Composite Device-0 usb 1-1: Manufacturer: IBM usb 1-1: SerialNumber: 20070221-15 usb 1-1: configuration #2 chosen from 1 choice input: IBM IBM Composite Device-0 as /devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1:2.0/input/input2 generic-usb 0003:04B3:4012.0001: input,hidraw0: USB HID v1.00 Keyboard [IBM IBM Composite Device-0] on usb-0000:00:1a.7-1/input0 input: IBM IBM Composite Device-0 as /devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1:2.1/input/input3 generic-usb 0003:04B3:4012.0002: input,hidraw1: USB HID v1.00 Mouse [IBM IBM Composite Device-0] on usb-0000:00:1a.7-1/input1 input: IBM IBM Composite Device-0 as /devices/pci0000:00/0000:00:1a.7/usb1/1-1/1-1:2.2/input/input4 generic-usb 0003:04B3:4012.0003: input,hidraw2: USB HID v1.00 Mouse [IBM IBM Composite Device-0] on usb-0000:00:1a.7-1/input2 Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. Fusion MPT base driver 3.04.20 Copyright (c) 1999-2008 LSI Corporation usb 2-3: new high speed USB device number 2 using ehci_hcd Fusion MPT SAS Host driver 3.04.20 mptsas 0000:0b:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28 mptbase: ioc0: Initiating bringup usb 2-3: New USB device found, idVendor=04b4, idProduct=6560 usb 2-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 2-3: configuration #1 chosen from 1 choice hub 2-3:1.0: USB hub found hub 2-3:1.0: 2 ports detected ioc0: LSISAS1064E: Capabilities={Initiator} mptsas 0000:0b:00.0: setting latency timer to 64 usb 3-2: new full speed USB device number 2 using uhci_hcd usb 3-2: New USB device found, idVendor=04b3, idProduct=4010 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: RNDIS/CDC ETHER usb 3-2: Manufacturer: IBM usb 3-2: configuration #1 chosen from 2 choices usb 2-3.1: new high speed USB device number 3 using ehci_hcd usb 2-3.1: New USB device found, idVendor=04b4, idProduct=6560 usb 2-3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 2-3.1: configuration #1 chosen from 1 choice hub 2-3.1:1.0: USB hub found hub 2-3.1:1.0: 2 ports detected usb-storage: device scan complete scsi 0:0:0:0: CD-ROM IMM Virtual CD/DVD 0316 PQ: 0 ANSI: 0 usb 2-3.1.2: new high speed USB device number 4 using ehci_hcd usb 2-3.1.2: New USB device found, idVendor=04b4, idProduct=6560 usb 2-3.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 2-3.1.2: configuration #1 chosen from 1 choice hub 2-3.1.2:1.0: USB hub found hub 2-3.1.2:1.0: 4 ports detected scsi1 : ioc0: LSISAS1064E, FwRev=011e0a00h, Ports=1, MaxQ=277, IRQ=28 mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 0, sas_addr 0x5000cca0259dc859 scsi 1:0:0:0: Direct-Access IBM-ESXS HUC106030CSS60 D3A6 PQ: 0 ANSI: 6 sr0: scsi3-mmc drive: 0x/0x cd/rw caddy Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 sd 1:0:0:0: [sda] Disabling DIF Type 2 protection sd 1:0:0:0: [sda] 585937500 512-byte logical blocks: (300 GB/279 GiB) sd 1:0:0:0: [sda] Write Protect is off sd 1:0:0:0: [sda] Mode Sense: f7 00 10 08 sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA sda: unknown partition table sd 1:0:0:0: [sda] Attached SCSI disk ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A squashfs: version 4.0 (2009/01/31) Phillip Lougher EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: dracut: Mounted root filesystem /dev/mapper/live-rw dracut: Loading SELinux policy type=1404 audit(1358235745.225:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 SELinux: 2048 avtab hash slots, 250818 rules. SELinux: 2048 avtab hash slots, 250818 rules. SELinux: 9 users, 12 roles, 3761 types, 187 bools, 1 sens, 1024 cats SELinux: 81 classes, 250818 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev dm-0, type ext4), uses xattr SELinux: initialized (dev loop2, type squashfs), not configured for labeling SELinux: initialized (dev loop0, type squashfs), not configured for labeling SELinux: initialized (dev sr0, type iso9660), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts SELinux: initialized (dev securityfs, type securityfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses transition SIDs SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev devtmpfs, type devtmpfs), uses transition SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts type=1403 audit(1358235747.243:3): policy loaded auid=4294967295 ses=4294967295 dracut: dracut: Switching root readahead: starting udev: starting version 147 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 EDAC MC: Ver: 2.1.0 Jun 22 2012 dca service started, version 1.12.1 ioatdma: Intel(R) QuickData Technology Driver 4.00 ioatdma 0000:00:16.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ioatdma 0000:00:16.0: setting latency timer to 64 alloc irq_desc for 50 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.0: irq 50 for MSI/MSI-X alloc irq_desc for 17 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ioatdma 0000:00:16.1: setting latency timer to 64 alloc irq_desc for 51 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.1: irq 51 for MSI/MSI-X alloc irq_desc for 18 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ioatdma 0000:00:16.2: setting latency timer to 64 alloc irq_desc for 52 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.2: irq 52 for MSI/MSI-X alloc irq_desc for 19 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.3: PCI INT D -> GSI 19 (level, low) -> IRQ 19 ioatdma 0000:00:16.3: setting latency timer to 64 alloc irq_desc for 53 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.3: irq 53 for MSI/MSI-X ioatdma 0000:00:16.4: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ioatdma 0000:00:16.4: setting latency timer to 64 alloc irq_desc for 54 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.4: irq 54 for MSI/MSI-X ioatdma 0000:00:16.5: PCI INT B -> GSI 17 (level, low) -> IRQ 17 ioatdma 0000:00:16.5: setting latency timer to 64 alloc irq_desc for 55 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.5: irq 55 for MSI/MSI-X ioatdma 0000:00:16.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18 ioatdma 0000:00:16.6: setting latency timer to 64 alloc irq_desc for 56 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.6: irq 56 for MSI/MSI-X ioatdma 0000:00:16.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19 ioatdma 0000:00:16.7: setting latency timer to 64 alloc irq_desc for 57 on node -1 alloc kstat_irqs on node -1 ioatdma 0000:00:16.7: irq 57 for MSI/MSI-X iTCO_vendor_support: vendor-support=0 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07rh iTCO_wdt: Found a ICH10 TCO device (Version=2, TCOBASE=0x05e0) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) i801_smbus 0000:00:1f.3: PCI INT B -> GSI 22 (level, low) -> IRQ 22 microcode: CPU0 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU1 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU2 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU3 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU4 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU5 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU6 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU7 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU8 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU9 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU10 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 microcode: CPU11 sig=0x206c2, pf=0x1, revision=0x15 platform microcode: firmware: requesting intel-ucode/06-2c-02 Microcode Update Driver: v2.00 , Peter Oruba usb0: register 'cdc_ether' at usb-0000:00:1a.0-2, CDC Ethernet Device, 36:40:b5:84:00:d7 usbcore: registered new interface driver cdc_ether sr 0:0:0:0: Attached scsi generic sg0 type 5 sd 1:0:0:0: Attached scsi generic sg1 type 0 bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v2.2.1 (Dec 18, 2011) bnx2 0000:10:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30 bnx2 0000:10:00.0: setting latency timer to 64 bnx2 0000:10:00.0: firmware: requesting bnx2/bnx2-mips-09-6.2.1b.fw bnx2 0000:10:00.0: firmware: requesting bnx2/bnx2-rv2p-09-6.0.17.fw bnx2 0000:10:00.0: eth0: Broadcom NetXtreme II BCM5709 1000Base-SX (C0) PCI Express found at mem 96000000, IRQ 30, node addr 34:40:b5:81:00:d4 alloc irq_desc for 37 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: PCI INT B -> GSI 37 (level, low) -> IRQ 37 bnx2 0000:10:00.1: setting latency timer to 64 bnx2 0000:10:00.1: firmware: requesting bnx2/bnx2-mips-09-6.2.1b.fw bnx2 0000:10:00.1: firmware: requesting bnx2/bnx2-rv2p-09-6.0.17.fw bnx2 0000:10:00.1: eth1: Broadcom NetXtreme II BCM5709 1000Base-SX (C0) PCI Express found at mem 98000000, IRQ 37, node addr 34:40:b5:81:00:d6 bnx2 0000:24:00.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 bnx2 0000:24:00.0: setting latency timer to 64 bnx2 0000:24:00.0: firmware: requesting bnx2/bnx2-mips-09-6.2.1b.fw bnx2 0000:24:00.0: firmware: requesting bnx2/bnx2-rv2p-09-6.0.17.fw bnx2 0000:24:00.0: eth2: Broadcom NetXtreme II BCM5709 1000Base-SX (C0) PCI Express found at mem 92000000, IRQ 32, node addr 00:10:18:71:83:78 alloc irq_desc for 42 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: PCI INT B -> GSI 42 (level, low) -> IRQ 42 bnx2 0000:24:00.1: setting latency timer to 64 bnx2 0000:24:00.1: firmware: requesting bnx2/bnx2-mips-09-6.2.1b.fw bnx2 0000:24:00.1: firmware: requesting bnx2/bnx2-rv2p-09-6.0.17.fw bnx2 0000:24:00.1: eth3: Broadcom NetXtreme II BCM5709 1000Base-SX (C0) PCI Express found at mem 94000000, IRQ 42, node addr 00:10:18:71:83:7a SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs NET: Registered protocol family 10 lo: Disabled Privacy Extensions ip6_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ip_tables: (C) 2000-2006 Netfilter Core Team 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller cnic: Broadcom NetXtreme II CNIC Driver cnic v2.5.10 (March 21, 2012) bnx2fc: Broadcom NetXtreme II FCoE Driver bnx2fc v1.0.11 (Apr 24, 2012) alloc irq_desc for 58 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 58 for MSI/MSI-X alloc irq_desc for 59 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 59 for MSI/MSI-X alloc irq_desc for 60 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 60 for MSI/MSI-X alloc irq_desc for 61 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 61 for MSI/MSI-X alloc irq_desc for 62 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 62 for MSI/MSI-X alloc irq_desc for 63 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 63 for MSI/MSI-X alloc irq_desc for 64 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 64 for MSI/MSI-X alloc irq_desc for 65 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 65 for MSI/MSI-X alloc irq_desc for 66 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.0: irq 66 for MSI/MSI-X bnx2 0000:10:00.0: eth0: using MSIX ADDRCONF(NETDEV_UP): eth0: link is not ready alloc irq_desc for 67 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 67 for MSI/MSI-X alloc irq_desc for 68 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 68 for MSI/MSI-X alloc irq_desc for 69 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 69 for MSI/MSI-X alloc irq_desc for 70 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 70 for MSI/MSI-X alloc irq_desc for 71 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 71 for MSI/MSI-X alloc irq_desc for 72 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 72 for MSI/MSI-X alloc irq_desc for 73 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 73 for MSI/MSI-X alloc irq_desc for 74 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 74 for MSI/MSI-X alloc irq_desc for 75 on node -1 alloc kstat_irqs on node -1 bnx2 0000:10:00.1: irq 75 for MSI/MSI-X bnx2 0000:10:00.0: eth0: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON bnx2 0000:10:00.1: eth1: using MSIX ADDRCONF(NETDEV_UP): eth1: link is not ready ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready alloc irq_desc for 76 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 76 for MSI/MSI-X alloc irq_desc for 77 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 77 for MSI/MSI-X alloc irq_desc for 78 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 78 for MSI/MSI-X alloc irq_desc for 79 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 79 for MSI/MSI-X alloc irq_desc for 80 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 80 for MSI/MSI-X alloc irq_desc for 81 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 81 for MSI/MSI-X alloc irq_desc for 82 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 82 for MSI/MSI-X alloc irq_desc for 83 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 83 for MSI/MSI-X alloc irq_desc for 84 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.0: irq 84 for MSI/MSI-X bnx2 0000:24:00.0: eth2: using MSIX ADDRCONF(NETDEV_UP): eth2: link is not ready alloc irq_desc for 85 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 85 for MSI/MSI-X alloc irq_desc for 86 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 86 for MSI/MSI-X alloc irq_desc for 87 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 87 for MSI/MSI-X alloc irq_desc for 88 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 88 for MSI/MSI-X alloc irq_desc for 89 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 89 for MSI/MSI-X alloc irq_desc for 90 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 90 for MSI/MSI-X alloc irq_desc for 91 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 91 for MSI/MSI-X alloc irq_desc for 92 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 92 for MSI/MSI-X alloc irq_desc for 93 on node -1 alloc kstat_irqs on node -1 bnx2 0000:24:00.1: irq 93 for MSI/MSI-X bnx2 0000:10:00.1: eth1: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON bnx2 0000:10:00.0: eth0: NIC SerDes Link is Down bnx2 0000:24:00.1: eth3: using MSIX ADDRCONF(NETDEV_UP): eth3: link is not ready ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready bnx2 0000:24:00.0: eth2: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready bnx2 0000:10:00.0: eth0: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON bnx2 0000:24:00.1: eth3: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready bnx2 0000:24:00.1: eth3: NIC SerDes Link is Down bnx2 0000:24:00.1: eth3: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON bnx2 0000:24:00.0: eth2: NIC SerDes Link is Down bnx2 0000:24:00.0: eth2: NIC SerDes Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts eth3: no IPv6 routers present usb0: no IPv6 routers present eth0: no IPv6 routers present eth1: no IPv6 routers present eth2: no IPv6 routers present SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents pci 0000:07:00.0: Invalid ROM contents fuse init (API version 7.13) --------------090506050005050808080502 Content-Type: text/plain; charset=windows-1252; name="freebsd.dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="freebsd.dmesg" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Xeon(R) CPU E5649 @ 2.53GHz (2533.48-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0xbfebfbff Features2=0x29ee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 25769803776 (24576 MB) avail memory = 24761884672 (23614 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 16 cpu7 (AP): APIC ID: 17 cpu8 (AP): APIC ID: 18 cpu9 (AP): APIC ID: 19 cpu10 (AP): APIC ID: 20 cpu11 (AP): APIC ID: 21 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20110527/tbfadt-638) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 3 range: 1 vs 8100000000 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci11: on pcib1 mpt0: port 0x1000-0x10ff mem 0x9b910000-0x9b913fff,0x9b900000-0x9b90ffff irq 28 at device 0.0 on pci11 mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) pcib2: irq 24 at device 3.0 on pci0 pci21: on pcib2 pcib3: irq 26 at device 5.0 on pci0 pci26: on pcib3 pcib4: irq 30 at device 7.0 on pci0 pci16: on pcib4 bce0: mem 0x96000000-0x97ffffff irq 30 at device 0.0 on pci16 miibus0: on bce0 brgphy0: PHY 2 on miibus0 brgphy0: 1000baseSX-FDX, auto bce0: Ethernet address: 34:40:b5:81:00:d4 bce0: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (6.2.0); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) bce1: mem 0x98000000-0x99ffffff irq 37 at device 0.1 on pci16 miibus1: on bce1 brgphy1: PHY 2 on miibus1 brgphy1: 1000baseSX-FDX, auto bce1: Ethernet address: 34:40:b5:81:00:d6 bce1: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (6.2.0); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib5: irq 31 at device 8.0 on pci0 pci31: on pcib5 pcib6: irq 32 at device 9.0 on pci0 pci36: on pcib6 bce2: mem 0x92000000-0x93ffffff irq 32 at device 0.0 on pci36 miibus2: on bce2 brgphy2: PHY 2 on miibus2 brgphy2: 1000baseSX-FDX, auto bce2: Ethernet address: 00:10:18:71:83:78 bce2: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (6.2.0); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) bce3: mem 0x94000000-0x95ffffff irq 42 at device 0.1 on pci36 miibus3: on bce3 brgphy3: PHY 2 on miibus3 brgphy3: 1000baseSX-FDX, auto bce3: Ethernet address: 00:10:18:71:83:7a bce3: ASIC (0x57092000); Rev (C0); Bus (PCIe x4, 2.5Gbps); B/C (6.2.0); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NCSI 2.0.11) Coal (RX:6,6,18,18; TX:20,20,80,80) pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0x2080-0x209f irq 22 at device 26.0 on pci0 usbus0 on uhci0 ehci0: mem 0x9ba21000-0x9ba213ff irq 16 at device 26.7 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 pcib7: irq 20 at device 28.0 on pci0 pci1: on pcib7 pcib8: irq 20 at device 28.4 on pci0 pci6: on pcib8 pcib9: irq 20 at device 0.0 on pci6 pci7: on pcib9 vgapci0: mem 0x9a000000-0x9affffff,0x9b800000-0x9b803fff,0x9b000000-0x9b7fffff irq 20 at device 0.0 on pci7 uhci1: port 0x2060-0x207f irq 20 at device 29.0 on pci0 usbus2 on uhci1 uhci2: port 0x2040-0x205f irq 20 at device 29.1 on pci0 usbus3 on uhci2 uhci3: port 0x2020-0x203f irq 21 at device 29.2 on pci0 usbus4 on uhci3 ehci1: mem 0x9ba20000-0x9ba203ff irq 20 at device 29.7 on pci0 usbus5: EHCI version 1.0 usbus5 on ehci1 pcib10: at device 30.0 on pci0 pci41: on pcib10 isab0: at device 31.0 on pci0 isa0: on isab0 pci0: at device 31.3 (no driver attached) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 qpi0: on motherboard pcib11: pcibus 255 on qpi0 pci255: on pcib11 orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 est4: on cpu4 p4tcc4: on cpu4 est5: on cpu5 p4tcc5: on cpu5 est6: on cpu6 p4tcc6: on cpu6 est7: on cpu7 p4tcc7: on cpu7 est8: on cpu8 p4tcc8: on cpu8 est9: on cpu9 p4tcc9: on cpu9 est10: on cpu10 p4tcc10: on cpu10 est11: on cpu11 p4tcc11: on cpu11 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub1: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums0: on usbus1 ums0: 3 buttons and [Z] coordinates ID=0 ugen5.2: at usbus5 uhub6: on usbus5 uhub6: MTT enabled ums1: on usbus1 ums1: 3 buttons and [XYZ] coordinates ID=0 umass0: on usbus1 umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 umass0:3:0:-1: Attached to scbus3 uhub6: 2 ports with 2 removable, self powered da0 at mpt0 bus 0 scbus0 target 1 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) cd0 at umass-sim0 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: cd present [351007 x 2048 byte records] SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! Timecounter "TSC-low" frequency 9896399 Hz quality 1000 Root mount waiting for: usbus5 ugen5.3: at usbus5 uhub7: on usbus5 uhub7: MTT enabled uhub7: 2 ports with 2 removable, self powered ugen0.2: at usbus0 Root mount waiting for: usbus5 ugen5.4: at usbus5 uhub8: on usbus5 uhub8: MTT enabled uhub8: 4 ports with 4 removable, self powered Trying to mount root from cd9660:/dev/iso9660/FREEBSD_INSTALL [ro]... umodem0: on usbus0 umodem0: data interface 1, has no CM over data, has no break --------------090506050005050808080502-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 14:59:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 62720A61 for ; Tue, 15 Jan 2013 14:59:56 +0000 (UTC) (envelope-from cheunghonyu@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 48869E32 for ; Tue, 15 Jan 2013 14:59:56 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1Tv7zX-0004WA-Fh for freebsd-hackers@freebsd.org; Tue, 15 Jan 2013 06:59:55 -0800 Date: Tue, 15 Jan 2013 06:59:55 -0800 (PST) From: zeissoctopus To: freebsd-hackers@freebsd.org Message-ID: <1358261995444-5777918.post@n5.nabble.com> In-Reply-To: References: <1357902944481-5776597.post@n5.nabble.com> Subject: Re: dirty hack asmc for Macbook 3,1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 14:59:56 -0000 I filed a PR at kern/175260 Regards, zeissoctopus -- View this message in context: http://freebsd.1045724.n5.nabble.com/dirty-hack-asmc-for-Macbook-3-1-tp5776597p5777918.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 15:13:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FADAE5E for ; Tue, 15 Jan 2013 15:13:09 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id DF988EC0 for ; Tue, 15 Jan 2013 15:13:08 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 70F5137B60E; Tue, 15 Jan 2013 09:06:53 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3Ylvz00JqfzCq3; Tue, 15 Jan 2013 09:06:52 -0600 (CST) Date: Tue, 15 Jan 2013 09:06:52 -0600 From: "Matthew D. Fuller" To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances Message-ID: <20130115150651.GA3400@over-yonder.net> References: <50F563BE.7010609@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50F563BE.7010609@gmail.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:13:09 -0000 On Tue, Jan 15, 2013 at 09:12:14AM -0500 I heard the voice of Karim Fodil-Lemelin, and lo! it spake thus: > > da0: Fixed Direct Access SCSI-6 device That's a 10k RPM drive. > FreeBSD 9.1: > > 10000+0 records in > 10000+0 records out > 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) 10000 ops in 60 seconds is practically the definition of a 10k drive. > CentOS: > > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 1.97883 s, 25.9 MB/s 10k ops in 2 seconds is 300k per second. You could make a flat-out *KILLING* if you could sell a platter drive that can pull that off. Presumably this is an instance of "Linux only has block devices for hard drives, not character devices", so you're getting your writes all buffered over there. Which is to say, nothing's wrong, you're just not measuring the same thing. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 15:21:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8F68EE8 for ; Tue, 15 Jan 2013 15:21:22 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 60F06F35 for ; Tue, 15 Jan 2013 15:21:22 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id C019B37B55A; Tue, 15 Jan 2013 09:21:21 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3YlwHj0hcnzCqv; Tue, 15 Jan 2013 09:21:21 -0600 (CST) Date: Tue, 15 Jan 2013 09:21:21 -0600 From: "Matthew D. Fuller" To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances Message-ID: <20130115152121.GD3400@over-yonder.net> References: <50F563BE.7010609@gmail.com> <20130115150651.GA3400@over-yonder.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130115150651.GA3400@over-yonder.net> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:21:22 -0000 Dur... > 10k ops in 2 seconds is 300k per second. RPM I mean... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 15:40:43 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B30E829 for ; Tue, 15 Jan 2013 15:40:43 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (feld.me [66.170.3.2]) by mx1.freebsd.org (Postfix) with ESMTP id DF7B0B2 for ; Tue, 15 Jan 2013 15:40:42 +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=ncMut0M3p3/Hgb2SnY5C0GWnw2RM8k3svPP4he1f3tc=; b=lpRnLHBk/1IJY/ALvyN2K2gGHHlloMUG5Yt9p7YAi1FHEFC0k7PWumyJ36JOce11OhksM7jOUiT9q8qPi92uN8M04yl371ZISLsvx74jPRWSSjq5nXzkfgapRKvPlK7T; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Tv8cn-000KhO-IV; Tue, 15 Jan 2013 09:40:33 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1358264423-76071-86284/5/1; Tue, 15 Jan 2013 15:40:23 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances References: <50F563BE.7010609@gmail.com> Date: Tue, 15 Jan 2013 09:40:23 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <50F563BE.7010609@gmail.com> User-Agent: Opera Mail/12.12 (FreeBSD) X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 15:40:43 -0000 On Tue, 15 Jan 2013 08:12:14 -0600, Karim Fodil-Lemelin wrote: > Hi, > > I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server > (HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1. > GNU dd is heavily buffered unless you tell it not to be. There really is no reason why you should want dd to be buffered by default. How can you trust that your attempt at writing raw data to a device actually completed if it's buffered? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 16:24:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E31E9F9 for ; Tue, 15 Jan 2013 16:24:34 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 940A534E for ; Tue, 15 Jan 2013 16:24:33 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0FGOO6T001877; Tue, 15 Jan 2013 17:24:24 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0FGOND2001874; Tue, 15 Jan 2013 17:24:23 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 15 Jan 2013 17:24:23 +0100 (CET) From: Wojciech Puchar To: "Matthew D. Fuller" Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <20130115150651.GA3400@over-yonder.net> Message-ID: References: <50F563BE.7010609@gmail.com> <20130115150651.GA3400@over-yonder.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 15 Jan 2013 17:24:24 +0100 (CET) Cc: Karim Fodil-Lemelin , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:24:34 -0000 >> 10000+0 records out >> 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) > > 10000 ops in 60 seconds is practically the definition of a 10k drive. nonsense. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 17:04:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9AE13EC3 for ; Tue, 15 Jan 2013 17:04:32 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8B9820 for ; Tue, 15 Jan 2013 17:04:32 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r0FH4PwT038908; Tue, 15 Jan 2013 17:04:25 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id wm3kze9ufeum8xhyhiynxkahca; Tue, 15 Jan 2013 17:04:25 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: IBM blade server abysmal disk write performances Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: <50F563BE.7010609@gmail.com> Date: Tue, 15 Jan 2013 09:04:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <710B89CC-004B-4766-A7C1-0B8CE45F64CF@kientzle.com> References: <50F563BE.7010609@gmail.com> To: Karim Fodil-Lemelin X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 17:04:32 -0000 On Jan 15, 2013, at 6:12 AM, Karim Fodil-Lemelin wrote: > Hi, >=20 > I'm struggling getting FreeBSD 9.1 properly work on an IBM blade = server (HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1. >=20 > CentOS: >=20 > 100000+0 records in > 100000+0 records out > 51200000 bytes (51 MB) copied, 1.97883 s, 25.9 MB/s >=20 >=20 > FreeBSD 9.1: >=20 > 10000+0 records in > 10000+0 records out > 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) What exactly was the 'dd' command you used? In particular, what block size did you specify? Can you strace the 'dd' command on CentOS to verify that it's using the actual block size you specified? Some programs (I've written at least one) "cheat" by actually doing larger I/O operations than you request. This makes a big difference in performance. So this could reflect optimizations in GNU dd more than any difference in the actual disk I/O. If you want to do a more robust comparison, look for one of the disk benchmarking programs in ports and see if it's available (in the same version) for CentOS. Tim From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 18:15:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A1D4C830 for ; Tue, 15 Jan 2013 18:15:15 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 182B1D1C for ; Tue, 15 Jan 2013 18:15:14 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0FIFAs8002301; Tue, 15 Jan 2013 19:15:10 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0FIFABP002298; Tue, 15 Jan 2013 19:15:10 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 15 Jan 2013 19:15:10 +0100 (CET) From: Wojciech Puchar To: Tim Kientzle Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <710B89CC-004B-4766-A7C1-0B8CE45F64CF@kientzle.com> Message-ID: References: <50F563BE.7010609@gmail.com> <710B89CC-004B-4766-A7C1-0B8CE45F64CF@kientzle.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 15 Jan 2013 19:15:11 +0100 (CET) Cc: Karim Fodil-Lemelin , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:15:15 -0000 >> >> 10000+0 records in >> 10000+0 records out >> 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) > > What exactly was the 'dd' command you used? > > In particular, what block size did you specify? 5120000/10000=512 default if it takes one revolution for one write it means that write caching is disabled. that's all. linux always uses buffered devices, only relatively recently special OPTION was added to have raw ones. Complete nonsense but it's linux. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 18:18:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 380E793B for ; Tue, 15 Jan 2013 18:18:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1B9D44 for ; Tue, 15 Jan 2013 18:18:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0FIIDcZ002317 for ; Tue, 15 Jan 2013 19:18:13 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0FIIDU2002314 for ; Tue, 15 Jan 2013 19:18:13 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 15 Jan 2013 19:18:13 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: off topic but no idea where to ask Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 15 Jan 2013 19:18:13 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:18:16 -0000 does anyone know a PXE image (just like /boot/pxeboot) that can be placed on tftp server and the only thing it will do would be loading first sector from first local disk at 0x07c00 and booting as with normal hard drive. what i need is to be able to decide from server side if given computer boots from NFS or hard disk. thanks From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 18:20:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78F09AAD for ; Tue, 15 Jan 2013 18:20:52 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6955DD6F for ; Tue, 15 Jan 2013 18:20:52 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 6D0491A3D47; Tue, 15 Jan 2013 10:20:50 -0800 (PST) Message-ID: <50F59E01.2050102@mu.org> Date: Tue, 15 Jan 2013 10:20:49 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Wojciech Puchar Subject: Re: off topic but no idea where to ask References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:20:52 -0000 On 1/15/13 10:18 AM, Wojciech Puchar wrote: > does anyone know a PXE image (just like /boot/pxeboot) that can be > placed on tftp server and the only thing it will do would be loading > first sector from first local disk at 0x07c00 and booting as with > normal hard drive. > > what i need is to be able to decide from server side if given computer > boots from NFS or hard disk. > This may not be helpful, but maybe you can have the server just deny the PXE client the infomration needed to boot and set the BIOS to boot order to: 1st: PXE 2nd: local disk ? This way if the server doesn't respond to the pxe option then the client will then try local disk? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 18:22:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57D33BA0 for ; Tue, 15 Jan 2013 18:22:00 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by mx1.freebsd.org (Postfix) with ESMTP id 35E59D82 for ; Tue, 15 Jan 2013 18:22:00 +0000 (UTC) Received: by mail-da0-f53.google.com with SMTP id x6so149888dac.26 for ; Tue, 15 Jan 2013 10:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=52KiksHwnaB9qhhO+OrbONy1GHQGA4Rb/63DfmjTrOo=; b=xw8kBDJx2eVpS5CNwGlW3W38IbnTrRj/BfAmjR57aEV/Bq23Bc72E+OOBVaa0Yep9K eHbh0iegWGrOUgMMuP56EhtgF/WQNquTVB9+J9VjTgMrFdj3M8fbdQTX15rmohM/RHk3 CrM5f/zzJlAPhIR5MbH1nVVhfkWnWOUKp5Fe/ZIuMmGtyr35bF5xr/L+lYIYN0JK7VFs +nPBw4/NnuAd8ze2ad7O/BPv0rbhbaiQG3bVbTGyvF6rNqN+UtP+H3t5a6mcnawYsQFe JQ6jmIokz/SngBvN1sv+3VkrzPJF7VWWgf0ULwzLM/PflWeYyKkODmyFHHHUyySN03af 7q8A== X-Received: by 10.66.78.168 with SMTP id c8mr244383208pax.16.1358274114045; Tue, 15 Jan 2013 10:21:54 -0800 (PST) Received: from [192.168.20.11] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id p10sm11259574pax.27.2013.01.15.10.21.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 10:21:51 -0800 (PST) Subject: Re: off topic but no idea where to ask Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Garrett Cooper In-Reply-To: Date: Tue, 15 Jan 2013 10:21:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D631C34-514E-4296-A3EC-C50F885A705A@gmail.com> References: To: Wojciech Puchar X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:22:00 -0000 On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote: > does anyone know a PXE image (just like /boot/pxeboot) that can be = placed on tftp server and the only thing it will do would be loading = first sector from first local disk at 0x07c00 and booting as with normal = hard drive. >=20 > what i need is to be able to decide from server side if given computer = boots from NFS or hard disk. Sounds like a job for PXE-enabled grub, but you probably can = hack loader (pxeboot to be exact) to do the same thing. It would be nice = to have a feature like this in mainline FreeBSD=85 Thanks, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 18:48:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF2F323E for ; Tue, 15 Jan 2013 18:48:59 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4B3EE9 for ; Tue, 15 Jan 2013 18:48:59 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r0FImwZH009603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 12:48:58 -0600 Received: from [10.0.0.102] (10.14.152.61) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 12:48:57 -0600 Subject: Re: off topic but no idea where to ask MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: Date: Tue, 15 Jan 2013 10:48:56 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Wojciech Puchar X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.61] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_06:2013-01-15,2013-01-15,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 18:48:59 -0000 On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote: > does anyone know a PXE image (just like /boot/pxeboot) that can be placed= on tftp server and the only thing it will do would be loading first sector= from first local disk at 0x07c00 and booting as with normal hard drive. >=20 > what i need is to be able to decide from server side if given computer bo= ots from NFS or hard disk. >=20 Yeah, no prob. NOTE: Our PXE server is Linux (*blech) but I assure you the only thing that= changes is the paths (/etc/dhcpd.conf becomes /usr/local/etc/dhcpd.conf fo= r example -- the pxelinux.0 image works fine served-up by ISC dhcpd on Free= BSD). First part of the recipe: $ awk '/filename/&&!/^[[:space:]]*(#|$)/{print}' /etc/dhcpd.conf filename "pxelinux.0"; $ ls -l /tftpboot/pxelinux.0 lrwxrwxrwx 1 root root 15 May 15 2012 /tftpboot/pxelinux.0 -> pxelinux.0-= 3.84 $ file /tftpboot/pxelinux.0-3.84=20 /tftpboot/pxelinux.0-3.84: data Next part of the recipe=85 The /etc/pxelinux.cfg/default file: DISPLAY /boot/include/boot.msg DEFAULT wpuchar_nfs PROMPT 1 ONTIMEOUT hdd TIMEOUT 50 TOTALTIMEOUT 6000 LABEL hdd LOCALBOOT 0x80 LABEL wpuchar_nfs =85 your nfs boot config =85 Last but not least, =85 $ cat /tftpboot/boot/include/boot.msg Press ENTER to boot from WPuchar's NFS server (defaulting to HDD boot in 5 = seconds)... --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:03:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA049A2E for ; Tue, 15 Jan 2013 20:03:39 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id A300A2C4 for ; Tue, 15 Jan 2013 20:03:39 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so973662iea.7 for ; Tue, 15 Jan 2013 12:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=UrkhlY5lB3kHEG9jmoWSPAxOqGRHbGe5e/oFnsy887s=; b=p3EG+wqQnFQpOeN4gVDgKHvx6MjgK6zL8Zr42a9Pk+XoYA8MM5ERlS46OW0yO7+XXA LX5NQWVxu6/NQEn+Pvne2lVVhEvgW1wU+A1fy+46f9ylOxnUXrpRCpMGqEWn4wNY9mp/ OMyS3/Z6AVf2e2n/3WXrUGZxQln5lYPM8BIjns/dyFMPScRyafCZgjPO8kf8dcO1IhQJ hbabp3D8ddsYl0hvLqp1JZtgKaWGf9SMKkYZiyZCGpMI6RAHvmwYYQ8pTUXEhGy6Jm4z F8p5oRYvohbD71w8cXMBm/5znwQ6BggSt869b6ypcD4yNtVa/ChVa0Y79ArgWpnzetJ6 WeWA== MIME-Version: 1.0 X-Received: by 10.50.184.199 with SMTP id ew7mr2769340igc.84.1358280213264; Tue, 15 Jan 2013 12:03:33 -0800 (PST) Received: by 10.64.107.196 with HTTP; Tue, 15 Jan 2013 12:03:33 -0800 (PST) Date: Tue, 15 Jan 2013 12:03:33 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:03:39 -0000 >>> 5120000 bytes transferred in 60.024997 secs (85298 bytes/sec) >>> mpt0: port 0x1000-0x10ff mem 0x9b910000-0x9b913fff,0x9b900000-0x9b90ffff irq 28 at device 0.0 on pci11 >>> mpt0: MPI Version=1.5.20.0 >>> mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) >>> mpt0: 0 Active Volumes (2 Max) >>> mpt0: 0 Hidden Drive Members (14 Max) >>> da0 at mpt0 bus 0 scbus0 target 1 lun 0 >>> da0: Fixed Direct Access SCSI-6 device >>> da0: 300.000MB/s transfers >>> da0: Command Queueing enabled >>> da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) >> That's a 10k RPM drive. >> 10000 ops in 60 seconds is practically the definition of a 10k drive. Assuming 1 op per rev. > if it takes one revolution for one write it means that write caching is > disabled. Disabling the disks's write cache is *required* for data integrity. One op per rev means write caching is disabled and no queueing. But dmesg claims "Command Queueing enabled", so you should be getting more than one op per rev, and writes should be fast. Is this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) Are you running compression, encryption, or some other feature that might slow things down? Also, try dd with a larger block size, like bs=1m. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:09:38 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 55A9DD5C for ; Tue, 15 Jan 2013 20:09:38 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD34314 for ; Tue, 15 Jan 2013 20:09:37 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r0FK9bHd009824 for ; Tue, 15 Jan 2013 12:09:37 -0800 (PST) (envelope-from yuri@rawbw.com) Message-ID: <50F5B781.4070501@rawbw.com> Date: Tue, 15 Jan 2013 12:09:37 -0800 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: hackers@freebsd.org Subject: Is there a way to prioritize disk operations ? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:09:38 -0000 Currently one can set nice value to the process. But it only affects the CPU scheduling, so if this process is CPU bound it would yield to others. What if the process is disk-bound, like some backup operations? The backup copying large disk seriously affects performance of all other apps accessing the same disk. Is there a way to set the priority value on the process for the disk operations, so that all disk operations originating from the process will be scheduled in similar way how CPU is scheduled based on the nice value of the process? The disk-intense backup process with low disk priority won't affect the other processes at all. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:10:46 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64EC0E81 for ; Tue, 15 Jan 2013 20:10:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by mx1.freebsd.org (Postfix) with ESMTP id EB5F632C for ; Tue, 15 Jan 2013 20:10:45 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id ep20so600381lab.32 for ; Tue, 15 Jan 2013 12:10:39 -0800 (PST) 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=ETpROWYcajYmA57wgCaeouZmN/iykDZ6jZ+geBaozLo=; b=uF848fTmAYwtMFzW7hAug2P1IWViIXPtVStFJxpPMcRIUDCUr3od5FA1MQw5eoto6X pP81kx+JwrQOchcmBKPKFBrbCKFxlt85yNYWP8hfDTEq7R+U41VuuKamH1893p3FtVDN MzdkKIJHFhj+/FhZP1AQCtALVzFmjURgKcKBI8A7/INKZ45EXI5X5yVM0dnqjrM2ZeRn sf5GdEojfDt5A798KDqCmDwon0DUDLsQf1V7rxOJLncMDVSQJvWZsfErhJkJ0+6bISQl CUKY43431ySnuHIgzWERQ9R0tDDcAYII3u5Vy71oobxHm2iZ3WdXRBqJA5kqbSmk6mSO U+9w== MIME-Version: 1.0 Received: by 10.152.125.237 with SMTP id mt13mr87348565lab.45.1358280639287; Tue, 15 Jan 2013 12:10:39 -0800 (PST) Received: by 10.114.81.40 with HTTP; Tue, 15 Jan 2013 12:10:39 -0800 (PST) In-Reply-To: <50F5B781.4070501@rawbw.com> References: <50F5B781.4070501@rawbw.com> Date: Tue, 15 Jan 2013 12:10:39 -0800 Message-ID: Subject: Re: Is there a way to prioritize disk operations ? From: Freddie Cash To: Yuri Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:10:46 -0000 man gsched On Tue, Jan 15, 2013 at 12:09 PM, Yuri wrote: > Currently one can set nice value to the process. But it only affects the > CPU scheduling, so if this process is CPU bound it would yield to others. > What if the process is disk-bound, like some backup operations? The backup > copying large disk seriously affects performance of all other apps > accessing the same disk. > > Is there a way to set the priority value on the process for the disk > operations, so that all disk operations originating from the process will > be scheduled in similar way how CPU is scheduled based on the nice value of > the process? The disk-intense backup process with low disk priority won't > affect the other processes at all. > > Yuri > ______________________________**_________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@** > freebsd.org " > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:29:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2758CF00 for ; Tue, 15 Jan 2013 20:29:03 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id F12BA6B7 for ; Tue, 15 Jan 2013 20:29:02 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 17so1039988iea.16 for ; Tue, 15 Jan 2013 12:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cqY7iluOoqEf+EC26iQaOz0FcqnwHnDiAVI9+q8EA7g=; b=Kkl4WMUx0nAP9uZrbyM5w9SXoyYoh2Ozl+TZ8npOiR22lW9wt+vcwOd2AsuCXweuUu RfrFcdYyb9obdaAj4k66W1sqYYoc29nemGZO8rG2UGCUIAjhmKHpchh/Hq5K/8WV103s HSHxt7IW5vaxAhe+lDvodcFIAqid/M9SQMJ1P/7FVv5uioefl7NWoupmVdP4rrVb7pwE FcBQsrd+TO8/7O4vMsfzB4LkadtRPZ8M5wmPuFhjb0/nu+WLnta50GCwHSt1/LpFfuGf cqKeQB0sAbQQKxQQm3WkBPPd3MG1OywCxO0kb4yEY5HLif+Y3/L+74TgIciCHGiWuZWG lplA== X-Received: by 10.50.41.136 with SMTP id f8mr2399283igl.105.1358281742050; Tue, 15 Jan 2013 12:29:02 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id ez8sm2901215igb.17.2013.01.15.12.28.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 12:29:00 -0800 (PST) Message-ID: <50F5BC08.1060700@gmail.com> Date: Tue, 15 Jan 2013 15:28:56 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jan 2013 20:43:35 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:29:03 -0000 On 15/01/2013 3:03 PM, Dieter BSD wrote: > Disabling the disks's write cache is *required* for data integrity. > One op per rev means write caching is disabled and no queueing. > But dmesg claims "Command Queueing enabled", so you should be getting > more than one op per rev, and writes should be fast. > Is this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) > Are you running compression, encryption, or some other feature > that might slow things down? Also, try dd with a larger block size, > like bs=1m. Hi, Thanks to everyone that answered so far. Here is a follow up. dd to the raw drive and no compression/encryption or some other features, just a naive boot off a live 9.1 CD then dd (see below). The following results have been gathered on the FreeBSD 9.1 system: # dd if=/dev/zero of=toto count=100 100+0 records in 100+0 records out 51200 bytes transferred in 1.057507 secs (48416 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=104 100+0 records in 100+0 records out 10400 bytes transferred in 1.209524 secs (8598 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=1024 100+0 records in 100+0 records out 102400 bytes transferred in 0.844302 secs (121284 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=10240 100+0 records in 100+0 records out 1024000 bytes transferred in 2.173532 secs (471123 bytes/sec) # dd if=/dev/zero of=toto count=100 bs=102400 100+0 records in 100+0 records out 10240000 bytes transferred in 19.915159 secs (514181 bytes/sec) # dd if=/dev/zero of=toto count=100 100+0 records in 100+0 records out 51200 bytes transferred in 1.070473 secs (47829 bytes/sec) # dd if=/dev/zero of=foo count=100 100+0 records in 100+0 records out 51200 bytes transferred in 0.683736 secs (74883 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=1024 100+0 records in 100+0 records out 102400 bytes transferred in 0.682579 secs (150019 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=10240 100+0 records in 100+0 records out 1024000 bytes transferred in 2.431012 secs (421224 bytes/sec) # dd if=/dev/zero of=foo count=100 bs=102400 100+0 records in 100+0 records out 10240000 bytes transferred in 19.963030 secs (512948 bytes/sec) # dd if=/dev/zero of=foo count=10 bs=1024000 10+0 records in 10+0 records out 10240000 bytes transferred in 19.615134 secs (522046 bytes/sec) # dd if=/dev/zero of=foo count=1 bs=10240000 1+0 records in 1+0 records out 10240000 bytes transferred in 19.579077 secs (523007 bytes/sec) Best regards, Karim. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:55:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC42146C for ; Tue, 15 Jan 2013 20:55:16 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 990787D7 for ; Tue, 15 Jan 2013 20:55:16 +0000 (UTC) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub08.exchhosting.com (192.168.11.106) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Jan 2013 12:54:06 -0800 Received: from localhost (35.8.247.10) by exchange.liveoffice.com (192.168.11.214) with Microsoft SMTP Server id 8.3.213.0; Tue, 15 Jan 2013 12:54:05 -0800 Date: Tue, 15 Jan 2013 15:54:03 -0500 From: Trent Nelson To: Subject: Getting the current thread ID without a syscall? Message-ID: <20130115205403.GA52904@snakebite.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:55:16 -0000 Howdy, I have an unusual requirement: I need to get the current thread ID in as few instructions as possible. On Windows, I managed to come up with this glorious hack: #ifdef WITH_INTRINSICS # ifdef MS_WINDOWS # include # if defined(MS_WIN64) # pragma intrinsic(__readgsdword) # define _Py_get_current_process_id() (__readgsdword(0x40)) # define _Py_get_current_thread_id() (__readgsdword(0x48)) # elif defined(MS_WIN32) # pragma intrinsic(__readfsdword) # define _Py_get_current_process_id() (__readfsdword(0x20)) # define _Py_get_current_thread_id() (__readfsdword(0x24)) That exploits the fact that Windows uses the FS/GS registers to store thread/process metadata. Could I use a similar approach on FreeBSD to get the thread ID without the need for syscalls? (I technically don't need the thread ID, I just need to get some form of unique identifier for the current thread such that I can compare it to a known global value that's been set to the "main thread", in order to determine if I'm currently that thread or not. As long as it's unique for each thread, and static for the lifetime of the thread, that's fine.) The "am I the main thread?" comparison is made every ~50-100 opcodes, which is why it needs to have the lowest overhead possible. Regards, Trent. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 20:55:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A07854F for ; Tue, 15 Jan 2013 20:55:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id F029A7DC for ; Tue, 15 Jan 2013 20:55:31 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id o1so577405wic.0 for ; Tue, 15 Jan 2013 12:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=x8e8QgX2hlkXqxrvPqQWCL3Tp5JikLO6BtsRyaNANms=; b=lfo7JrhmYCuStq+qtUhE4xSzs+fe5h9s1N02YBAZPlGGFv2VUAWQkplMQOMxvb8Rhu 9AQC1oAQWL4NV17D3LdVdwGlJlIJl5OJP1QNqY/dqZfFdoDr4CRhSwwxFjPgfNOT0/Pa k03tGTK53pKsnQNOOXmTuVwAgALeqT9VTUNrzt+79e1U2p+Xe30PdO+fMDehBDalmEt3 7jtMsp4tTC2YMzADTAbEBq/XbNi+6vxkcWXjhBvaUMnx9I4TBK/kETNIYj42fv6SjSSw 3iHiGhWxq6wxmLxf4nyHk85zbWRwILKFFKak07YHY97hshGWTWDqqIfcqJXmdAKfQZWy N/lQ== MIME-Version: 1.0 X-Received: by 10.180.33.44 with SMTP id o12mr6055577wii.28.1358283327727; Tue, 15 Jan 2013 12:55:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 12:55:27 -0800 (PST) In-Reply-To: <50F5BC08.1060700@gmail.com> References: <50F5BC08.1060700@gmail.com> Date: Tue, 15 Jan 2013 12:55:27 -0800 X-Google-Sender-Auth: iErstpVOyKx9JbpMwuPsW4Vb1Q8 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Adrian Chadd To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 20:55:32 -0000 Hi, You're only doing one IO at the end. That's just plain silly. There's all kinds of overhead that could show up, that would be amortized over doing many IOs. You should also realise that the raw disk IO on Linux is by default buffered, so you're hitting the buffer cache. The results aren't going to match, not unless you exhaust physical memory and start falling behind on disk IO. At that point you'll see what the fuss is about. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:16:46 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E526BBA9 for ; Tue, 15 Jan 2013 21:16:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5711A8BC for ; Tue, 15 Jan 2013 21:16:46 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0FLGfwe086608; Tue, 15 Jan 2013 23:16:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0FLGfwe086608 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0FLGfM4086607; Tue, 15 Jan 2013 23:16:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jan 2013 23:16:41 +0200 From: Konstantin Belousov To: Trent Nelson Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115211641.GC2522@kib.kiev.ua> References: <20130115205403.GA52904@snakebite.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB" Content-Disposition: inline In-Reply-To: <20130115205403.GA52904@snakebite.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:16:47 -0000 --2/5bycvrmDh4d1IB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote: > Howdy, >=20 > I have an unusual requirement: I need to get the current thread ID > in as few instructions as possible. On Windows, I managed to come > up with this glorious hack: >=20 > #ifdef WITH_INTRINSICS > # ifdef MS_WINDOWS > # include > # if defined(MS_WIN64) > # pragma intrinsic(__readgsdword) > # define _Py_get_current_process_id() (__readgsdword(0x40)) > # define _Py_get_current_thread_id() (__readgsdword(0x48)) > # elif defined(MS_WIN32) > # pragma intrinsic(__readfsdword) > # define _Py_get_current_process_id() (__readfsdword(0x20)) > # define _Py_get_current_thread_id() (__readfsdword(0x24)) >=20 > That exploits the fact that Windows uses the FS/GS registers to > store thread/process metadata. Could I use a similar approach on > FreeBSD to get the thread ID without the need for syscalls? The layout of the per-thread structure used by libthr is private and is not guaranteed to be stable even on the stable branches. Yes, you could obtain the tid this way, but note explicitely that using it makes your application not binary compatible with any version of the FreeBSD except the one you compiled on. You could read the _thread_off_tid integer variable and use the value as offset from the %fs base to the long containing the unique thread id. But don't use this in anything except the private code. >=20 > (I technically don't need the thread ID, I just need to get some > form of unique identifier for the current thread such that I can > compare it to a known global value that's been set to the "main > thread", in order to determine if I'm currently that thread or not. > As long as it's unique for each thread, and static for the lifetime > of the thread, that's fine.) >=20 > The "am I the main thread?" comparison is made every ~50-100 opcodes, > which is why it needs to have the lowest overhead possible. On newer CPUs in amd64 mode, there is getfsbase instruction which reads the %fs register base. System guarantees that %fs base is unique among live threads. --2/5bycvrmDh4d1IB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9cc4AAoJEJDCuSvBvK1BT0sP/39TH2lCuBjWweGlT7Ms7nqg SXmm98UC+jqIblMdCwxg4Nyh9ffaDCJHswOtUxXWKCjR9hNSdArb9EWgXhrD6qNW dYeMpSo+8lLJlTlsg40sYuyo3ykH2GBr9dzz9uFW2j+6WEo4bzhWRunRmTOu8pdY I38cCKmzUqO7211TJpUKOBNWzpmSi5YRGPZ4alW/JHp883irMy03oOyCJit+zvmK 2u+TqA/XWT+p4ZbksCn1BKovjjG3z92lhgnDHpTUXmMkMrIvNNzqpDwtL8eA23JQ WZpamo0JTM7o2ZKAR/8suem+nFz5HO3BNRYLxYdKU3KfKBaqdk7c2p0u8MYvW+Za C8K7Ehxf75RrP86qNZT3+gic5GrZPV1/qbKd5T36S6Kw3sZQi/S/5UdbFGxPScDu 7iOBmWvh2RRRqTLUp3bWwYDTgK73vjQzHHgIKZIPVCkYK6Ic5Mf0Uf0PvFpuaO0q nGiq8XY+h/I4LfHJmVqowVR9kErIjDP3rTH8zbsNdmBuxNi3KsJMNrVmZ3Vs/HOw HaXZ2u89a2SRE56UHAesDIBLP38s2aQkXC23K/iGXMRIs9oPKbInziV35cggPTFC nL/HDrPX8GITJgMmuwrg5ZDnmD3PlwKTPRBZ4bVw1nQIRSjskxDFJjB/vBdFrIne IMhpi4p4+JdEXt7mjJpy =0wRN -----END PGP SIGNATURE----- --2/5bycvrmDh4d1IB-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:26:25 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 66AFBF66 for ; Tue, 15 Jan 2013 21:26:25 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 203C4922 for ; Tue, 15 Jan 2013 21:26:24 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r0FLQNTj022358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 15 Jan 2013 15:26:24 -0600 Received: from dtwin (10.14.152.6) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 15:26:23 -0600 From: Sender: Devin Teske To: Subject: kgzip(1) is broken Date: Tue, 15 Jan 2013 13:27:07 -0800 Message-ID: <09b701cdf367$12737530$375a5f90$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3zZpftr1D6DqQTQ7mtytQk5iHXvg== Content-Language: en-us X-Originating-IP: [10.14.152.6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_07:2013-01-15,2013-01-15,1970-01-01 signatures=0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:26:25 -0000 Hello, I have been sad of-late because kgzip(1) no longer produces a usable kernel. All versions of 9.x suffer this. And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in the 8.x series. I haven't tried the 7 series lately, but if whatever is making the rounds gets MFC'd that far back, I expect the problem to percolate there too. The symptom is that the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader. This is quite troubling and I am looking for someone to help find the culprit. I don't know where to start looking. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:35:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B4A372EE for ; Tue, 15 Jan 2013 21:35:18 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2A4984 for ; Tue, 15 Jan 2013 21:35:17 +0000 (UTC) Received: from EXHUB03.exchhosting.com (192.168.11.104) by exhub05.exchhosting.com (192.168.11.101) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Jan 2013 13:35:17 -0800 Received: from localhost (35.8.247.10) by exchange.liveoffice.com (192.168.11.104) with Microsoft SMTP Server id 8.3.213.0; Tue, 15 Jan 2013 13:35:16 -0800 Date: Tue, 15 Jan 2013 16:35:14 -0500 From: Trent Nelson To: Konstantin Belousov Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115213513.GA53047@snakebite.org> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20130115211641.GC2522@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:35:18 -0000 On Tue, Jan 15, 2013 at 01:16:41PM -0800, Konstantin Belousov wrote: > On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote: > > Howdy, > > > > I have an unusual requirement: I need to get the current thread ID > > in as few instructions as possible. On Windows, I managed to come > > up with this glorious hack: > > > > #ifdef WITH_INTRINSICS > > # ifdef MS_WINDOWS > > # include > > # if defined(MS_WIN64) > > # pragma intrinsic(__readgsdword) > > # define _Py_get_current_process_id() (__readgsdword(0x40)) > > # define _Py_get_current_thread_id() (__readgsdword(0x48)) > > # elif defined(MS_WIN32) > > # pragma intrinsic(__readfsdword) > > # define _Py_get_current_process_id() (__readfsdword(0x20)) > > # define _Py_get_current_thread_id() (__readfsdword(0x24)) > > > > That exploits the fact that Windows uses the FS/GS registers to > > store thread/process metadata. Could I use a similar approach on > > FreeBSD to get the thread ID without the need for syscalls? > The layout of the per-thread structure used by libthr is private and > is not guaranteed to be stable even on the stable branches. > > Yes, you could obtain the tid this way, but note explicitely that using > it makes your application not binary compatible with any version of > the FreeBSD except the one you compiled on. Luckily it's for an open source project (Python), so recompilation isn't a big deal. (I also check the intrinsic result versus the syscall result during startup to verify the same ID is returned, falling back to the syscall by default.) > You could read the _thread_off_tid integer variable and use the value > as offset from the %fs base to the long containing the unique thread id. > But don't use this in anything except the private code. Ah, thanks, that's what I was interested in knowing. > > > > (I technically don't need the thread ID, I just need to get some > > form of unique identifier for the current thread such that I can > > compare it to a known global value that's been set to the "main > > thread", in order to determine if I'm currently that thread or not. > > As long as it's unique for each thread, and static for the lifetime > > of the thread, that's fine.) > > > > The "am I the main thread?" comparison is made every ~50-100 opcodes, > > which is why it needs to have the lowest overhead possible. > On newer CPUs in amd64 mode, there is getfsbase instruction which reads > the %fs register base. System guarantees that %fs base is unique among > live threads. Interesting. I was aware of those instructions, but never assessed them in detail once I'd figured out the readgsdword approach. I definitely didn't realize they return unique values per thread (although it makes sense now that I think about it). Thanks Konstantin, very helpful. Trent. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:43:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4502583 for ; Tue, 15 Jan 2013 21:43:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 42BE89ED for ; Tue, 15 Jan 2013 21:43:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0FLhWHl089341; Tue, 15 Jan 2013 23:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0FLhWHl089341 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0FLhWMW089340; Tue, 15 Jan 2013 23:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jan 2013 23:43:32 +0200 From: Konstantin Belousov To: Trent Nelson Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115214332.GE2522@kib.kiev.ua> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <20130115213513.GA53047@snakebite.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:43:38 -0000 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: > On Tue, Jan 15, 2013 at 01:16:41PM -0800, Konstantin Belousov wrote: > > On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote: > > > Howdy, > > >=20 > > > I have an unusual requirement: I need to get the current thread ID > > > in as few instructions as possible. On Windows, I managed to come > > > up with this glorious hack: > > >=20 > > > #ifdef WITH_INTRINSICS > > > # ifdef MS_WINDOWS > > > # include > > > # if defined(MS_WIN64) > > > # pragma intrinsic(__readgsdword) > > > # define _Py_get_current_process_id() (__readgsdword(0x40)) > > > # define _Py_get_current_thread_id() (__readgsdword(0x48)) > > > # elif defined(MS_WIN32) > > > # pragma intrinsic(__readfsdword) > > > # define _Py_get_current_process_id() (__readfsdword(0x20)) > > > # define _Py_get_current_thread_id() (__readfsdword(0x24)) > > >=20 > > > That exploits the fact that Windows uses the FS/GS registers to > > > store thread/process metadata. Could I use a similar approach on > > > FreeBSD to get the thread ID without the need for syscalls? > > The layout of the per-thread structure used by libthr is private and > > is not guaranteed to be stable even on the stable branches. > >=20 > > Yes, you could obtain the tid this way, but note explicitely that using > > it makes your application not binary compatible with any version of > > the FreeBSD except the one you compiled on. >=20 > Luckily it's for an open source project (Python), so recompilation > isn't a big deal. (I also check the intrinsic result versus the > syscall result during startup to verify the same ID is returned, > falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. >=20 > > You could read the _thread_off_tid integer variable and use the value > > as offset from the %fs base to the long containing the unique thread id. > > But don't use this in anything except the private code. >=20 > Ah, thanks, that's what I was interested in knowing. >=20 > > >=20 > > > (I technically don't need the thread ID, I just need to get some > > > form of unique identifier for the current thread such that I can > > > compare it to a known global value that's been set to the "main > > > thread", in order to determine if I'm currently that thread or n= ot. > > > As long as it's unique for each thread, and static for the lifet= ime > > > of the thread, that's fine.) > > >=20 > > > The "am I the main thread?" comparison is made every ~50-100 opco= des, > > > which is why it needs to have the lowest overhead possible. >=20 > > On newer CPUs in amd64 mode, there is getfsbase instruction which reads > > the %fs register base. System guarantees that %fs base is unique among > > live threads. >=20 > Interesting. I was aware of those instructions, but never assessed > them in detail once I'd figured out the readgsdword approach. I > definitely didn't realize they return unique values per thread > (although it makes sense now that I think about it). >=20 > Thanks Konstantin, very helpful. >=20 > Trent. --FN+gV9K+162wdwwF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9c2DAAoJEJDCuSvBvK1BlGQP/3bBYDeADJMGsnGhkOb0R6JC cSzqyFT5U9eizdMfqeedPL49S7J3WhsEVdmrAHUtVgvqx2f/m9BS7F8jnPK6BIbF 1q6wNZLl1BYoLNffFgPuNotNXbZ3S8S3MtdibFsJt9uIeJNWdnvq6EDZZr6bB7O7 Lc4JsEmzPch1NIcC5SH0VRde9FFZcWtks37reOkLtHQKPorMZDmcRQ/8onF3xpMV oliUCsk2SQPdtfoKG9meRstqRnC+Vq8TlEDKtsG4JBFGlhwX1PNrlZKyMaEWIM3E TzuMS/tOKxv4pOO5DE/sZscQJyMYnsQRT4gnYapQs+00JI9IlB3McacMWUl0PbuL 0tQMO1PwuJzJANhJDIaaWJd0nhdg6OdIhnA3PRf6IKC3ApAky8TJo0MbO24AQR2n alfaMHTjC7p4xjhgyy9hE3l/xra6VqGyb5qtVwcLPtkEA3ESMM4Azi98KrU6+Wnu 9lOD4c1Hzy5b9xM0AVmu/Y5Xo8ENHhiLYb0jDBN5soOpsgqnpilUOZB/9a/O9lqA yP2VOG0kbkjaJZCqeUqFWRt5f0bcqxkJjmeIY2L6pIETE3gJ3Nx8NYTxndQ14Chh U8poz4quf3+cIFakXHCfTbM+gJL05DwFaAvaJ46VSsBdNc4EdkTvkaMqLrx+T2G2 /+M1J5KyEaTWdgnQnsyr =vQZD -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:50:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5FA5838; Tue, 15 Jan 2013 21:50:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3BD65A49; Tue, 15 Jan 2013 21:50:46 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0FLoiH0002956; Tue, 15 Jan 2013 22:50:44 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0FLoieW002953; Tue, 15 Jan 2013 22:50:44 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 15 Jan 2013 22:50:44 +0100 (CET) From: Wojciech Puchar To: Devin Teske Subject: Re: off topic but no idea where to ask In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 15 Jan 2013 22:50:44 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:50:47 -0000 > First part of the recipe: > > $ awk '/filename/&&!/^[[:space:]]*(#|$)/{print}' /etc/dhcpd.conf > filename "pxelinux.0"; > $ ls -l /tftpboot/pxelinux.0 > lrwxrwxrwx 1 root root 15 May 15 2012 /tftpboot/pxelinux.0 -> pxelinux.0-3.84 > $ file /tftpboot/pxelinux.0-3.84 > /tftpboot/pxelinux.0-3.84: data don't care what it will be from linux or not, but if it works. actually it would be just: > DEFAULT wpuchar_nfs > PROMPT 1 > ONTIMEOUT hdd > TIMEOUT 50 > TOTALTIMEOUT 6000 > LABEL hdd > LOCALBOOT 0x80 and i would put pxelinux instead of pxeboot in dhcpd.conf for given workstation when i want disk boot not NFS boot. Thank you very much From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:54:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB25AA35 for ; Tue, 15 Jan 2013 21:54:24 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 31BDAA7E for ; Tue, 15 Jan 2013 21:54:23 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0FLsMd7002973; Tue, 15 Jan 2013 22:54:22 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0FLsMm9002970; Tue, 15 Jan 2013 22:54:22 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 15 Jan 2013 22:54:22 +0100 (CET) From: Wojciech Puchar To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <50F5BC08.1060700@gmail.com> Message-ID: References: <50F5BC08.1060700@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 15 Jan 2013 22:54:22 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:54:24 -0000 > > # dd if=/dev/zero of=foo count=1 bs=10240000 > 1+0 records in > 1+0 records out > 10240000 bytes transferred in 19.579077 secs (523007 bytes/sec) > you write to file not device, so it will be clustered anyway by FreeBSD. 128kB by default, more if you put options MAXPHYS=... in kernel config and recompile. Even with hard drive write cache disabled, it should about one write per revolution but seems to do 4 writes per second. so probably it is not that but much worse failure. Did you rest read speed? dd if=/dev/disk of=/dev/null bs=512 dd if=/dev/disk of=/dev/null bs=4k dd if=/dev/disk of=/dev/null bs=128k ? From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:05:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82BAEDF4 for ; Tue, 15 Jan 2013 22:05:23 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 60013B12 for ; Tue, 15 Jan 2013 22:05:23 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-60-66.hsd1.ms.comcast.net [75.65.60.66]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 5B96537B65A; Tue, 15 Jan 2013 16:05:19 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 3Ym5Fp4gGlzDBD; Tue, 15 Jan 2013 16:05:18 -0600 (CST) Date: Tue, 15 Jan 2013 16:05:18 -0600 From: "Matthew D. Fuller" To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances Message-ID: <20130115220518.GF3400@over-yonder.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.21-fullermd.4 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.6 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:05:23 -0000 On Tue, Jan 15, 2013 at 12:03:33PM -0800 I heard the voice of Dieter BSD, and lo! it spake thus: > > But dmesg claims "Command Queueing enabled", so you should be > getting more than one op per rev, and writes should be fast. Queueing would only help if your load threw multiple ops at the drive before waiting for any of them to complete. I'd expect a dd to a raw device to throw a single, wait for it to return complete, then throw the next, leading to no more than 1 op per rev. (possibly less, with sufficiently fast revs and a sufficiently slow system, but that's a pretty unlikely combo with platter drives and remotely modern hardware unless it's under serious load otherwise) -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:20:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82D50832 for ; Tue, 15 Jan 2013 22:20:00 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF2BCD0 for ; Tue, 15 Jan 2013 22:20:00 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id DC5A11E6DB; Tue, 15 Jan 2013 14:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1358288400; bh=18Vvi4kTRku16zDUz9r7DVW5uTz8n4AYIBTDnTPJR+8=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=swdFC1TE2U0uxBvjSehyAZhR7TrX2JZO7O5zFZj3y9YJ0Bk71NmeY6/M+VVhLMJg+ 6n8/u1QpdyP9OIwmwrsvoCdpzkfdlIz2nrkmzsRecU2MzIsu2wyJL3Xj9JNksoxTjK S6Q6UWc9Aj/aFIbURWkRTu0Z0m4xHoFrJ69ew0BU= Message-ID: <50F5D60E.6050605@delphij.net> Date: Tue, 15 Jan 2013 14:19:58 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: kgzip(1) is broken References: <09b701cdf367$12737530$375a5f90$@freebsd.org> In-Reply-To: <09b701cdf367$12737530$375a5f90$@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:20:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/15/13 13:27, dteske@freebsd.org wrote: > Hello, > > I have been sad of-late because kgzip(1) no longer produces a > usable kernel. > > All versions of 9.x suffer this. > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this > recently broke in the 8.x series. > > I haven't tried the 7 series lately, but if whatever is making the > rounds gets MFC'd that far back, I expect the problem to percolate > there too. > > The symptom is that the machine reboots immediately and > unexpectedly the moment the kernel is executed by the loader. > > This is quite troubling and I am looking for someone to help find > the culprit. I don't know where to start looking. I think this is i386 only? Also, are you trying to avoid loader(8)? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJQ9dYOAAoJEG80Jeu8UPuzPwoH/RRR+SATnzoH/tXz1o+qvg/4 9i5EnGp0lcwhQWHaCvC9vmxFPhDFDQIK6RGjUqzi5IIpRhtgO8sdcLYjYD4sMVVS U/XGNGXeL57EzVwwCmAc1zYXoVHvj8s+ZiEuThF8bXU3L81VxPfosVLp+xdQhyx4 5nOPEjsOtYOx+snBknBR6l1r7Z6bH7Y8pyvXFrz4PV7d5V/i8cIDNFBsjfefuTYL u98ZzXCfQGnMGNRXn+gJ0M+r1r4SxzNWSnfMDBem54EjKrHXReUsmy4ID03VV8R5 RnNK/pupPYEAuK46UcQxjv89fEV/CVUAAshX415QzOdj9qL4Te2TLOUKmBW8c1Y= =uZJa -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:29:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 178D0A0C for ; Tue, 15 Jan 2013 22:29:11 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 00E0AD67 for ; Tue, 15 Jan 2013 22:29:10 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (208.sub-174-253-245.myvzw.com [174.253.245.208]) by elvis.mu.org (Postfix) with ESMTPSA id 4E62C1A3C1C; Tue, 15 Jan 2013 14:29:02 -0800 (PST) Message-ID: <50F5D82C.7070400@mu.org> Date: Tue, 15 Jan 2013 14:29:00 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Getting the current thread ID without a syscall? References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> In-Reply-To: <20130115214332.GE2522@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Trent Nelson , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:29:11 -0000 On 1/15/13 1:43 PM, Konstantin Belousov wrote: > On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: >> >> Luckily it's for an open source project (Python), so recompilation >> isn't a big deal. (I also check the intrinsic result versus the >> syscall result during startup to verify the same ID is returned, >> falling back to the syscall by default.) > For you, may be. For your users, it definitely will be a problem. > And worse, the problem will be blamed on the operating system and not > to the broken application. > Anything we can do to avoid this would be best. The reason is that we are still dealing with an "optimization" that perl did, it reached inside of the opaque struct FILE to "do nasty things". Now it is very difficult for us to fix "struct FILE". We are still paying for this years later. Any way we can make this a supported interface? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:33:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 70C2ECFA for ; Tue, 15 Jan 2013 22:33:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 88ABADCA for ; Tue, 15 Jan 2013 22:33:52 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0FMXjsj059904 for ; Tue, 15 Jan 2013 15:33:45 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0FMXfAM003901; Tue, 15 Jan 2013 15:33:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Getting the current thread ID without a syscall? From: Ian Lepore To: Alfred Perlstein In-Reply-To: <50F5D82C.7070400@mu.org> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> <50F5D82C.7070400@mu.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jan 2013 15:33:41 -0700 Message-ID: <1358289221.32417.129.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Trent Nelson , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:33:56 -0000 On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote: > On 1/15/13 1:43 PM, Konstantin Belousov wrote: > > On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: > >> > >> Luckily it's for an open source project (Python), so recompilation > >> isn't a big deal. (I also check the intrinsic result versus the > >> syscall result during startup to verify the same ID is returned, > >> falling back to the syscall by default.) > > For you, may be. For your users, it definitely will be a problem. > > And worse, the problem will be blamed on the operating system and not > > to the broken application. > > > Anything we can do to avoid this would be best. > > The reason is that we are still dealing with an "optimization" that perl > did, it reached inside of the opaque struct FILE to "do nasty things". > Now it is very difficult for us to fix "struct FILE". > > We are still paying for this years later. > > Any way we can make this a supported interface? > > -Alfred Re-reading the original question, I've got to ask why pthread_self() isn't the right answer? The requirement wasn't "I need to know what the OS calls me" it was "I need a unique ID per thread within a process." -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:45:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8CA58F72 for ; Tue, 15 Jan 2013 22:45:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF16EA0 for ; Tue, 15 Jan 2013 22:45:33 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r0FMjJH3025129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 16:45:19 -0600 Received: from dtwin (10.14.152.6) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 16:45:19 -0600 From: Sender: Devin Teske To: , References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <50F5D60E.6050605@delphij.net> In-Reply-To: <50F5D60E.6050605@delphij.net> Subject: RE: kgzip(1) is broken Date: Tue, 15 Jan 2013 14:46:02 -0800 Message-ID: <09fe01cdf372$193298a0$4b97c9e0$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEm08A5EfxbuxwhGQZ5y0RK5HyMsQGFE9MKmY0OvxA= Content-Language: en-us X-Originating-IP: [10.14.152.6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_07:2013-01-15,2013-01-15,1970-01-01 signatures=0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:45:34 -0000 > -----Original Message----- > From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd- > hackers@freebsd.org] On Behalf Of Xin Li > Sent: Tuesday, January 15, 2013 2:20 PM > To: freebsd-hackers@freebsd.org > Subject: Re: kgzip(1) is broken > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 01/15/13 13:27, dteske@freebsd.org wrote: > > Hello, > > > > I have been sad of-late because kgzip(1) no longer produces a > > usable kernel. > > > > All versions of 9.x suffer this. > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this > > recently broke in the 8.x series. > > > > I haven't tried the 7 series lately, but if whatever is making the > > rounds gets MFC'd that far back, I expect the problem to percolate > > there too. > > > > The symptom is that the machine reboots immediately and > > unexpectedly the moment the kernel is executed by the loader. > > > > This is quite troubling and I am looking for someone to help find > > the culprit. I don't know where to start looking. > > I think this is i386 only? Also, are you trying to avoid loader(8)? > Yes, this is i386 only. We are using loader(8) and have not had a problem in using kgzip'd kernels from loader(8) for any release from 4.8 to 8.3-RELEASE-p1. It's only the 9.x releases and (now recently) 8.3-RELEASE-p5 that's exhibiting this behavior. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:09:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8CFEE5E6 for ; Tue, 15 Jan 2013 22:09:34 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id 624F2BF2 for ; Tue, 15 Jan 2013 22:09:34 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so1226065iea.21 for ; Tue, 15 Jan 2013 14:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BZIdCXRftVbKoVTrZZmHsBMSrjWzFuNThKU3YL4ka5g=; b=iumUrEs0LMTazXUDE+IERabj3yWDiQljJiq7lorTNQXCJwhGBOKfoxTmtvh//vBKpI 4rqusZ2AL7qMngB+EzbbAZG0o7Y1tgp5zsFdyTK4jXKvEW21EurswH/OgFA/mWSbLnpP jHJCktGasfxXRN5YjDJE696gY6sVRQ0RN85YFFAln9HDq45CrZ5MxGDzxmpju/MsLFfA nEHc9nnJEM30yjNi7ZWMsmE30wOziyquAEjOW93kifU1s5pQWwNw0Ytskvl/g2M/uBRy ZsdVCXFZW+2sHgdL+ygddC3W1fCE+3UCDmtjyrUiLMP3Pmz232ikkTmWVNyhRtbNK2U7 7c8w== X-Received: by 10.50.16.144 with SMTP id g16mr3201554igd.2.1358287768668; Tue, 15 Jan 2013 14:09:28 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id fv6sm2874233igc.17.2013.01.15.14.09.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 14:09:27 -0800 (PST) Message-ID: <50F5D393.10704@gmail.com> Date: Tue, 15 Jan 2013 17:09:23 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: <50F5BC08.1060700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jan 2013 22:55:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:09:34 -0000 On 15/01/2013 3:55 PM, Adrian Chadd wrote: > You're only doing one IO at the end. That's just plain silly. There's > all kinds of overhead that could show up, that would be amortized over > doing many IOs. > > You should also realise that the raw disk IO on Linux is by default > buffered, so you're hitting the buffer cache. The results aren't going > to match, not unless you exhaust physical memory and start falling > behind on disk IO. At that point you'll see what the fuss is about. > To put is simply and maybe give a bit more context, here is what we're doing: 1) Boot OS (Linux or FreeBSD in this case) 2) dd some image over to the SAS drive. 3) rinse and repeat for X times. 4) profit. In this case if step 1) is done with Linux we get 100 times more profit. I was wondering if we could close the gap. Karim. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 23:03:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7C24887 for ; Tue, 15 Jan 2013 23:03:38 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from EXHUB04.exchhosting.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8EDA68E for ; Tue, 15 Jan 2013 23:03:35 +0000 (UTC) Received: from localhost (35.8.247.10) by exchange.liveoffice.com (192.168.11.100) with Microsoft SMTP Server id 8.3.213.0; Tue, 15 Jan 2013 15:03:31 -0800 Date: Tue, 15 Jan 2013 18:03:30 -0500 From: Trent Nelson To: Ian Lepore Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115230330.GA53211@snakebite.org> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> <50F5D82C.7070400@mu.org> <1358289221.32417.129.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <1358289221.32417.129.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:03:38 -0000 On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote: > On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote: > > On 1/15/13 1:43 PM, Konstantin Belousov wrote: > > > On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: > > >> > > >> Luckily it's for an open source project (Python), so recompilation > > >> isn't a big deal. (I also check the intrinsic result versus the > > >> syscall result during startup to verify the same ID is returned, > > >> falling back to the syscall by default.) > > > For you, may be. For your users, it definitely will be a problem. > > > And worse, the problem will be blamed on the operating system and not > > > to the broken application. > > > > > Anything we can do to avoid this would be best. > > > > The reason is that we are still dealing with an "optimization" that perl > > did, it reached inside of the opaque struct FILE to "do nasty things". > > Now it is very difficult for us to fix "struct FILE". > > > > We are still paying for this years later. > > > > Any way we can make this a supported interface? > > > > -Alfred > > Re-reading the original question, I've got to ask why pthread_self() > isn't the right answer? The requirement wasn't "I need to know what the > OS calls me" it was "I need a unique ID per thread within a process." The identity check is performed hundreds of times per second. The overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is negligible -- I can't say the same for a system/function call. (I'm experimenting with an idea I had to parallelize Python such that it can exploit all cores without impeding the performance of normal single-threaded execution (like previous-GIL-removal attempts and STM). It's very promising so far -- presuming we can get the current thread ID in a couple of instructions. If not, single-threaded performance suffers too much.) Trent. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 23:05:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D643E98E; Tue, 15 Jan 2013 23:05:00 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id AFAEFAC; Tue, 15 Jan 2013 23:05:00 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0FN50HN062529; Tue, 15 Jan 2013 16:05:00 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0FN4w1k003937; Tue, 15 Jan 2013 16:04:58 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: kgzip(1) is broken From: Ian Lepore To: dteske@freebsd.org In-Reply-To: <09b701cdf367$12737530$375a5f90$@freebsd.org> References: <09b701cdf367$12737530$375a5f90$@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jan 2013 16:04:58 -0700 Message-ID: <1358291098.32417.134.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:05:00 -0000 On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: > Hello, > > I have been sad of-late because kgzip(1) no longer produces a usable kernel. > > All versions of 9.x suffer this. > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently broke in > the 8.x series. > > I haven't tried the 7 series lately, but if whatever is making the rounds gets > MFC'd that far back, I expect the problem to percolate there too. > > The symptom is that the machine reboots immediately and unexpectedly the moment > the kernel is executed by the loader. > > This is quite troubling and I am looking for someone to help find the culprit. I > don't know where to start looking. Here are some possible candidates from the things that were MFC'd to 8 in that timeframe. I haven't looked at what these do, they're just changes that affect files related to booting. r233211 r233377 r233469 r234563 -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 22:46:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5CBBBEE for ; Tue, 15 Jan 2013 22:46:06 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by mx1.freebsd.org (Postfix) with ESMTP id 31C0DEAC for ; Tue, 15 Jan 2013 22:46:05 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id k10so1287910iea.1 for ; Tue, 15 Jan 2013 14:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=J18BBfWl2LpiezjMJWyQhYeE8tN3jkb+XZDl2W1uaWA=; b=Tzz7iI964bhTej5bG6xfrXUBKUZn6Am7c2PWnCoxn4tRUr4+VoIpPy99SUI0zVtRMO z3Y23hDHOPm5pSurdLWXMmh4l0hsR4buEAj5uEYxrLi37Kt6KK28l4H0J3Di3z6N9eER lIamwkhnBeq73ApCCgbBXXYQJpOMy0g7tJj0qOogT52dA35PsdwNaMtn2va4U9qHDp3s MAqOgCuGq0MMjBrBXhiJduTXbsQVs3mrAIs/EP8at+osz0fEX2u8D8p/FE72Q/gJE/vL NCz3ALxHtIR1EPwlhjg3rkTJKz5FHv0+ozmakf3uGGAICrWdMZ8nUYklB9wd8q1Uggyi JvEg== X-Received: by 10.50.7.204 with SMTP id l12mr3187831iga.103.1358289959498; Tue, 15 Jan 2013 14:45:59 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id rd10sm2984662igb.1.2013.01.15.14.45.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 14:45:58 -0800 (PST) Message-ID: <50F5DC22.6040405@gmail.com> Date: Tue, 15 Jan 2013 17:45:54 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: <50F5BC08.1060700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jan 2013 23:08:23 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:46:06 -0000 On 15/01/2013 4:54 PM, Wojciech Puchar wrote: >> >> # dd if=/dev/zero of=foo count=1 bs=10240000 >> 1+0 records in >> 1+0 records out >> 10240000 bytes transferred in 19.579077 secs (523007 bytes/sec) >> > you write to file not device, so it will be clustered anyway by FreeBSD. > > 128kB by default, more if you put options MAXPHYS=... in kernel config > and recompile. > > Even with hard drive write cache disabled, it should about one write > per revolution but seems to do 4 writes per second. > > so probably it is not that but much worse failure. > > Did you rest read speed? > > dd if=/dev/disk of=/dev/null bs=512 > > dd if=/dev/disk of=/dev/null bs=4k > > dd if=/dev/disk of=/dev/null bs=128k > As you mentioned the dd file tests were done UFS and not on raw device. I will get those numbers for you. Thanks, Karim. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 23:08:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5EEE1B9E; Tue, 15 Jan 2013 23:08:53 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2F372E1; Tue, 15 Jan 2013 23:08:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r0FN8mjF023575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 17:08:48 -0600 Received: from dtwin (10.14.152.6) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 17:08:47 -0600 From: Sender: Devin Teske To: "'Ian Lepore'" References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> In-Reply-To: <1358291098.32417.134.camel@revolution.hippie.lan> Subject: RE: kgzip(1) is broken Date: Tue, 15 Jan 2013 15:09:31 -0800 Message-ID: <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEm08A5EfxbuxwhGQZ5y0RK5HyMsQIlPdpzmYgY0kA= Content-Language: en-us X-Originating-IP: [10.14.152.6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_07:2013-01-15,2013-01-15,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org, dteske@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 23:08:53 -0000 > -----Original Message----- > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] > Sent: Tuesday, January 15, 2013 3:05 PM > To: dteske@freebsd.org > Cc: freebsd-hackers@freebsd.org > Subject: Re: kgzip(1) is broken > > On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: > > Hello, > > > > I have been sad of-late because kgzip(1) no longer produces a usable kernel. > > > > All versions of 9.x suffer this. > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently > broke in > > the 8.x series. > > > > I haven't tried the 7 series lately, but if whatever is making the rounds gets > > MFC'd that far back, I expect the problem to percolate there too. > > > > The symptom is that the machine reboots immediately and unexpectedly the > moment > > the kernel is executed by the loader. > > > > This is quite troubling and I am looking for someone to help find the culprit. I > > don't know where to start looking. > > Here are some possible candidates from the things that were MFC'd to 8 > in that timeframe. I haven't looked at what these do, they're just > changes that affect files related to booting. > > r233211 > r233377 > r233469 > r234563 > Thanks Ian! I'll test each one individually to see if regressing any one (or all) addresses the problem. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 00:06:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 070A2153 for ; Wed, 16 Jan 2013 00:06:20 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by mx1.freebsd.org (Postfix) with ESMTP id D6F266F5 for ; Wed, 16 Jan 2013 00:06:19 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id 13so1387601iea.7 for ; Tue, 15 Jan 2013 16:06:17 -0800 (PST) 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=9Q06EAFIL9n7zKrWxXjz4evGrL/yXEq+8F/usvqL82k=; b=y1jjGDbQOtC5eD2yZnaD3XkMiANd829QZODLwPXFyuSoRRMHyPr2c2bfzF9OwCMK/o CGKvnY7v4wQn1jQb1iYA+AJqqgF+rKzBFaEN6qKBM0U3NjV/pGMoGXfjix5o8kcZiQZ2 ScWe7HDOucxlYog64+RhsnEtqdfL/qVyG5gdV4LU7zvP++NSjqPsUydSfDqhe7uzHREX a4OaR9StD03lob/MiC39ATqPPrOyZp6IK3zVX/r4yQ21TKtd+zNA5FD4jdIc09ksel7x Li8GvF8HvNo3/EuVJql6iEMpjevyK7hP/KeYYG7x/2H6649xGCWAeaK3CbEjJyMQhSo2 t/wQ== MIME-Version: 1.0 Received: by 10.50.151.211 with SMTP id us19mr3408858igb.84.1358294777605; Tue, 15 Jan 2013 16:06:17 -0800 (PST) Received: by 10.64.107.196 with HTTP; Tue, 15 Jan 2013 16:06:17 -0800 (PST) Date: Tue, 15 Jan 2013 16:06:17 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:06:20 -0000 Karim writes: > dd to the > raw drive and no compression/encryption or some other features, just a > naive boot off a live 9.1 CD then dd (see below). The following results > have been gathered on the FreeBSD 9.1 system: > > # dd if=/dev/zero of=toto count=100 > 100+0 records in > 100+0 records out > 51200 bytes transferred in 1.057507 secs (48416 bytes/sec) By "raw drive" I meant something like dd if=/dev/zero of=/dev/da0 bs=1m count=1000 "of=toto" implies that you are using a filesystem. (FFS? ZFS? other?) Matthew writes: >> But dmesg claims "Command Queueing enabled", so you should be >> getting more than one op per rev, and writes should be fast. > > Queueing would only help if your load threw multiple ops at the drive > before waiting for any of them to complete. I'd expect a dd to a raw > device to throw a single, wait for it to return complete, then throw > the next, leading to no more than 1 op per rev. I see a huge speedup from NCQ on both raw disks and with FFS/su. Without NCQ I only get 6% of the expected performance, even with a large blocksize. The kernel must be doing write-behind even to a raw disk, otherwise waiting for write(2) to return before issuing the next write would slow it down as Matthew suggests. Writing an entire 3TB disk (raw disk, no fs) gives: 21378.98 real 2.00 user 440.98 sys or 140 MB/s (133 MiB/s) on slow controller in PCIe x1 slot. The same test on the same make & model disk on a much faster controller in the chipset takes over 10x as long because FreeBSD does not support NCQ on that controller. :-( Karim's data sure looks like 1 op per rev. Either it isn't really doing NCQ or the filesystem is doing something to keep NCQ from being effective. For example, mounting the fs with the sync option would probably have that effect. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 00:10:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D5EDB405; Wed, 16 Jan 2013 00:10:05 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id A697D761; Wed, 16 Jan 2013 00:10:05 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id r0G09vTs030606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 18:09:57 -0600 Received: from dtwin (10.14.152.6) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 18:09:56 -0600 From: Devin Teske To: , "'Ian Lepore'" References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> In-Reply-To: <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> Subject: RE: kgzip(1) is broken Date: Tue, 15 Jan 2013 16:10:40 -0800 Message-ID: <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEm08A5EfxbuxwhGQZ5y0RK5HyMsQIlPdpzAkHCD8uZdhJgUA== Content-Language: en-us X-Originating-IP: [10.14.152.6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_07:2013-01-15,2013-01-15,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:10:05 -0000 > -----Original Message----- > From: Devin Teske [mailto:devin.teske@fisglobal.com] On Behalf Of > dteske@freebsd.org > Sent: Tuesday, January 15, 2013 3:10 PM > To: 'Ian Lepore' > Cc: freebsd-hackers@freebsd.org; dteske@freebsd.org > Subject: RE: kgzip(1) is broken > > > > > -----Original Message----- > > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] > > Sent: Tuesday, January 15, 2013 3:05 PM > > To: dteske@freebsd.org > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: kgzip(1) is broken > > > > On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: > > > Hello, > > > > > > I have been sad of-late because kgzip(1) no longer produces a usable kernel. > > > > > > All versions of 9.x suffer this. > > > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently > > broke in > > > the 8.x series. > > > > > > I haven't tried the 7 series lately, but if whatever is making the rounds > gets > > > MFC'd that far back, I expect the problem to percolate there too. > > > > > > The symptom is that the machine reboots immediately and unexpectedly the > > moment > > > the kernel is executed by the loader. > > > > > > This is quite troubling and I am looking for someone to help find the > culprit. I > > > don't know where to start looking. > > > > Here are some possible candidates from the things that were MFC'd to 8 > > in that timeframe. I haven't looked at what these do, they're just > > changes that affect files related to booting. > > > > r233211 > > r233377 > > r233469 > > r234563 > > > > Thanks Ian! > > I'll test each one individually to see if regressing any one (or all) addresses > the problem. Progress... Looks like I found the culprit. Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip seems to never work). I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip to produce non-working kernels. I'm emailing the maintainers (davidch + other Broadcom folk) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 00:27:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6956E865 for ; Wed, 16 Jan 2013 00:27:52 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 456D9868 for ; Wed, 16 Jan 2013 00:27:52 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 17so1437603iea.30 for ; Tue, 15 Jan 2013 16:27:48 -0800 (PST) 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=KKMA0gySXE7qfwAaFI/k99BV8IfUloxW/0g+llstGqo=; b=yX9Dvm5OlRnaG6p70BY2gLpuGnl9ON0mNDdC5ZHpeOMXC+JrDSOkFwRtG7mMH/f40H 83f2ybAWcyHqqAWdFIIrnagq54F4ffxSHUaJpFCyGGddMoRqPUK/BYzb6NwwHiGfG9kX S+SlhS3socuE4qlQHx7tokG2MfKY3O+M9NL7yqMA4DZqQZjmGrMuqaHFlgOLUxJMwuGu xpw3Qn5ccGqB3kRhKOewcHjssGjTmPV3Q5Vs4EqsUskIWP4ev2Y40yS3U+o6Jegx6DX2 +g63MGz777VQO99EKEawEcV6e9XrgxIn5LJwfC9LHf6dqgqGwvc+WxNG7pR423qONI1N h3xg== MIME-Version: 1.0 Received: by 10.50.17.132 with SMTP id o4mr3442840igd.83.1358296068602; Tue, 15 Jan 2013 16:27:48 -0800 (PST) Received: by 10.64.107.196 with HTTP; Tue, 15 Jan 2013 16:27:48 -0800 (PST) Date: Tue, 15 Jan 2013 16:27:48 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:27:52 -0000 I wrote: > The kernel must be doing write-behind even to a raw disk, otherwise > waiting for write(2) to return before issuing the next write would > slow it down as Matthew suggests. And a minute after hitting send, I remembered that FreeBSD does not provide the traditional "raw" disk devices, e.g. /dev/rda0 with an 'r'. (Now if I could just remember *why* it doesn't.) From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 00:42:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9DC4AFBD; Wed, 16 Jan 2013 00:42:53 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3377D944; Wed, 16 Jan 2013 00:42:53 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0G0gnDa063657; Tue, 15 Jan 2013 17:42:49 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0G0glVj004056; Tue, 15 Jan 2013 17:42:47 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: RE: kgzip(1) is broken From: Ian Lepore To: Devin Teske In-Reply-To: <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jan 2013 17:42:47 -0700 Message-ID: <1358296967.32417.137.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dteske@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:42:53 -0000 On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote: > > > -----Original Message----- > > From: Devin Teske [mailto:devin.teske@fisglobal.com] On Behalf Of > > dteske@freebsd.org > > Sent: Tuesday, January 15, 2013 3:10 PM > > To: 'Ian Lepore' > > Cc: freebsd-hackers@freebsd.org; dteske@freebsd.org > > Subject: RE: kgzip(1) is broken > > > > > > > > > -----Original Message----- > > > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] > > > Sent: Tuesday, January 15, 2013 3:05 PM > > > To: dteske@freebsd.org > > > Cc: freebsd-hackers@freebsd.org > > > Subject: Re: kgzip(1) is broken > > > > > > On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: > > > > Hello, > > > > > > > > I have been sad of-late because kgzip(1) no longer produces a usable > kernel. > > > > > > > > All versions of 9.x suffer this. > > > > > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this recently > > > broke in > > > > the 8.x series. > > > > > > > > I haven't tried the 7 series lately, but if whatever is making the rounds > > gets > > > > MFC'd that far back, I expect the problem to percolate there too. > > > > > > > > The symptom is that the machine reboots immediately and unexpectedly the > > > moment > > > > the kernel is executed by the loader. > > > > > > > > This is quite troubling and I am looking for someone to help find the > > culprit. I > > > > don't know where to start looking. > > > > > > Here are some possible candidates from the things that were MFC'd to 8 > > > in that timeframe. I haven't looked at what these do, they're just > > > changes that affect files related to booting. > > > > > > r233211 > > > r233377 > > > r233469 > > > r234563 > > > > > > > Thanks Ian! > > > > I'll test each one individually to see if regressing any one (or all) > addresses > > the problem. > > Progress... > > Looks like I found the culprit. > > Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip > seems to never work). > > I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause kgzip > to produce non-working kernels. > Yeah, it'll be interesting to see how a device driver can lead to "the machine reboots immediately and unexpectedly the moment the kernel is executed by the loader," which I took to mean "before seeing the copyright or anything." > I'm emailing the maintainers (davidch + other Broadcom folk) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 00:56:48 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9F8417C6; Wed, 16 Jan 2013 00:56:48 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 54315A14; Wed, 16 Jan 2013 00:56:47 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r0G0ugJS012414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2013 18:56:42 -0600 Received: from dtwin (10.14.152.6) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 15 Jan 2013 18:56:42 -0600 From: Sender: Devin Teske To: "'Ian Lepore'" References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> <1358296967.32417.137.camel@revolution.hippie.lan> In-Reply-To: <1358296967.32417.137.camel@revolution.hippie.lan> Subject: RE: kgzip(1) is broken Date: Tue, 15 Jan 2013 16:56:25 -0800 Message-ID: <0a4601cdf384$4ff98e40$efecaac0$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEm08A5EfxbuxwhGQZ5y0RK5HyMsQIlPdpzAkHCD8sB74H+fQJX2JE+mVPtD5A= Content-Language: en-us X-Originating-IP: [10.14.152.6] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-15_08:2013-01-16,2013-01-15,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org, dteske@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 00:56:48 -0000 > -----Original Message----- > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] > Sent: Tuesday, January 15, 2013 4:43 PM > To: Devin Teske > Cc: dteske@freebsd.org; freebsd-hackers@freebsd.org > Subject: RE: kgzip(1) is broken > > On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote: > > > > > -----Original Message----- > > > From: Devin Teske [mailto:devin.teske@fisglobal.com] On Behalf Of > > > dteske@freebsd.org > > > Sent: Tuesday, January 15, 2013 3:10 PM > > > To: 'Ian Lepore' > > > Cc: freebsd-hackers@freebsd.org; dteske@freebsd.org > > > Subject: RE: kgzip(1) is broken > > > > > > > > > > > > > -----Original Message----- > > > > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] > > > > Sent: Tuesday, January 15, 2013 3:05 PM > > > > To: dteske@freebsd.org > > > > Cc: freebsd-hackers@freebsd.org > > > > Subject: Re: kgzip(1) is broken > > > > > > > > On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: > > > > > Hello, > > > > > > > > > > I have been sad of-late because kgzip(1) no longer produces a usable > > kernel. > > > > > > > > > > All versions of 9.x suffer this. > > > > > > > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this > recently > > > > broke in > > > > > the 8.x series. > > > > > > > > > > I haven't tried the 7 series lately, but if whatever is making the rounds > > > gets > > > > > MFC'd that far back, I expect the problem to percolate there too. > > > > > > > > > > The symptom is that the machine reboots immediately and unexpectedly > the > > > > moment > > > > > the kernel is executed by the loader. > > > > > > > > > > This is quite troubling and I am looking for someone to help find the > > > culprit. I > > > > > don't know where to start looking. > > > > > > > > Here are some possible candidates from the things that were MFC'd to 8 > > > > in that timeframe. I haven't looked at what these do, they're just > > > > changes that affect files related to booting. > > > > > > > > r233211 > > > > r233377 > > > > r233469 > > > > r234563 > > > > > > > > > > Thanks Ian! > > > > > > I'll test each one individually to see if regressing any one (or all) > > addresses > > > the problem. > > > > Progress... > > > > Looks like I found the culprit. > > > > Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where kgzip > > seems to never work). > > > > I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause > kgzip > > to produce non-working kernels. > > > > Yeah, it'll be interesting to see how a device driver can lead to "the > machine reboots immediately and unexpectedly the moment the kernel is > executed by the loader," which I took to mean "before seeing the > copyright or anything." > Indeed... loader throws up the syms and upon execution *KABOOM* (screen goes black and back to POST) The copyright never appears. > > I'm emailing the maintainers (davidch + other Broadcom folk) > The current dossier is even more interesting... the back-ported driver (with zero modifications mind you from stable/9 to stable/8) exhibits memory failures (example below), and causes terminals to become wedged when attempting to (for example) scp a file over an existing configured network (igb-based -- presumably unrelated to bxe but in practice loading bxe causes igb to misbehave). $ ifconfig bxe0 inet 192.168.1.5/24 bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! $ ifconfig bxe1 inet 192.168.1.6/24 bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill fp[00] RX chain. bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! (as expected, also sent mail off to maintainers w/respect to above notes/errors) -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 01:07:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5E77AAF3; Wed, 16 Jan 2013 01:07:32 +0000 (UTC) (envelope-from prvs=1728d5906c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id A7690AA1; Wed, 16 Jan 2013 01:07:31 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001720955.msg; Wed, 16 Jan 2013 01:07:30 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 16 Jan 2013 01:07:30 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1728d5906c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , "'Ian Lepore'" References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> <1358296967.32417.137.camel@revolution.hippie.lan> <0a4601cdf384$4ff98e40$efecaac0$@freebsd.org> Subject: Re: kgzip(1) is broken Date: Wed, 16 Jan 2013 01:07:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-hackers@freebsd.org, dteske@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 01:07:32 -0000 ----- Original Message ----- From: To: "'Ian Lepore'" Cc: ; Sent: Wednesday, January 16, 2013 12:56 AM Subject: RE: kgzip(1) is broken > > >> -----Original Message----- >> From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] >> Sent: Tuesday, January 15, 2013 4:43 PM >> To: Devin Teske >> Cc: dteske@freebsd.org; freebsd-hackers@freebsd.org >> Subject: RE: kgzip(1) is broken >> >> On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote: >> > >> > > -----Original Message----- >> > > From: Devin Teske [mailto:devin.teske@fisglobal.com] On Behalf Of >> > > dteske@freebsd.org >> > > Sent: Tuesday, January 15, 2013 3:10 PM >> > > To: 'Ian Lepore' >> > > Cc: freebsd-hackers@freebsd.org; dteske@freebsd.org >> > > Subject: RE: kgzip(1) is broken >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] >> > > > Sent: Tuesday, January 15, 2013 3:05 PM >> > > > To: dteske@freebsd.org >> > > > Cc: freebsd-hackers@freebsd.org >> > > > Subject: Re: kgzip(1) is broken >> > > > >> > > > On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: >> > > > > Hello, >> > > > > >> > > > > I have been sad of-late because kgzip(1) no longer produces a usable >> > kernel. >> > > > > >> > > > > All versions of 9.x suffer this. >> > > > > >> > > > > And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this >> recently >> > > > broke in >> > > > > the 8.x series. >> > > > > >> > > > > I haven't tried the 7 series lately, but if whatever is making the > rounds >> > > gets >> > > > > MFC'd that far back, I expect the problem to percolate there too. >> > > > > >> > > > > The symptom is that the machine reboots immediately and unexpectedly >> the >> > > > moment >> > > > > the kernel is executed by the loader. >> > > > > >> > > > > This is quite troubling and I am looking for someone to help find the >> > > culprit. I >> > > > > don't know where to start looking. >> > > > >> > > > Here are some possible candidates from the things that were MFC'd to 8 >> > > > in that timeframe. I haven't looked at what these do, they're just >> > > > changes that affect files related to booting. >> > > > >> > > > r233211 >> > > > r233377 >> > > > r233469 >> > > > r234563 >> > > > >> > > >> > > Thanks Ian! >> > > >> > > I'll test each one individually to see if regressing any one (or all) >> > addresses >> > > the problem. >> > >> > Progress... >> > >> > Looks like I found the culprit. >> > >> > Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where > kgzip >> > seems to never work). >> > >> > I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cause >> kgzip >> > to produce non-working kernels. >> > >> >> Yeah, it'll be interesting to see how a device driver can lead to "the >> machine reboots immediately and unexpectedly the moment the kernel is >> executed by the loader," which I took to mean "before seeing the >> copyright or anything." >> > > Indeed... loader throws up the syms and upon execution *KABOOM* (screen goes > black and back to POST) > > The copyright never appears. > > >> > I'm emailing the maintainers (davidch + other Broadcom folk) >> > > The current dossier is even more interesting... the back-ported driver (with > zero modifications mind you from stable/9 to stable/8) exhibits memory failures > (example below), and causes terminals to become wedged when attempting to (for > example) scp a file over an existing configured network (igb-based -- presumably > unrelated to bxe but in practice loading bxe causes igb to misbehave). > > $ ifconfig bxe0 inet 192.168.1.5/24 > bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill > fp[00] RX chain. > bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! > $ ifconfig bxe1 inet 192.168.1.6/24 > bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Cannot fill > fp[00] RX chain. > bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborting! > > (as expected, also sent mail off to maintainers w/respect to above notes/errors) Sounds like you may be out of mbufs which is easy, on a box with 4 igb's simply booting without tuning with cause this so, if you have igb's and bxe's this could be your cause. Try adding the following to loader.conf and see if it helps:- kern.ipc.nmbclusters=51200 Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 02:46:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2E4A54D7; Wed, 16 Jan 2013 02:46:27 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 91781FB6; Wed, 16 Jan 2013 02:46:26 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so2351988wgb.0 for ; Tue, 15 Jan 2013 18:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=hh7J6OSV78Gi7iZs9o1crZRgGtgVqVY74b3cak55KxY=; b=Xacord8sr05yHht4Db1Pb9H5Upsyvww437JUjfycIWPHwqlWAGGIMYxa6niAGpykEq JtRiHjs9O1KvNdBVNccLkdIyCw5VmVoR4DpZzxELC9M2UaEjdnayGIIzyBlcs0UKt7bJ HxbwDsZnxuY0nXF6QdlKVxlKzOxAdLrSyIBrppsHG3Ah8rpkQ1YoMCvPLKu1pKIYEtkW OQqCOhmrRPhXvFPDNnckOEd5bVdczvQ0zKisyf6EaBwhn5aY2cYiC8v2YRdk7B6l/Hx7 zICBVWsOnzqn/zdp5gd1WyIIKZVpudgEIIsorvEzzJ1UsWGufG+EuZCjHbWOT6+QHpP5 v9kw== MIME-Version: 1.0 Received: by 10.180.100.163 with SMTP id ez3mr7021580wib.32.1358304385825; Tue, 15 Jan 2013 18:46:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 18:46:25 -0800 (PST) Date: Tue, 15 Jan 2013 18:46:25 -0800 X-Google-Sender-Auth: rBt-Ey9jYmq3KphX3ODJwFPlmYI Message-ID: Subject: [RFC] add gdb into the cross-build target From: Adrian Chadd To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 02:46:27 -0000 Hi, I'd like to propose adding gdb into the cross-build target. This way MIPS, ARM, PPC etc targets will have gdb- built in the cross-build environment, so it can be (hopefully) used for cross-build debugging of the kernel, as well as remote debugging out of the box. Here's my example patch. Thanks! Adrian Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 245281) +++ Makefile.inc1 (working copy) @@ -1211,6 +1211,7 @@ ${_clang_libs} \ ${_clang} \ ${_binutils} \ + gnu/usr.bin/gdb \ ${_cc} \ usr.bin/xlint/lint1 usr.bin/xlint/lint2 usr.bin/xlint/xlint \ ${_btxld} \ @@ -1673,6 +1674,7 @@ .for _tool in \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ + gnu/usr.bin/gdb \ usr.bin/ar ${_+_}@${ECHODIR} "===> xdev ${_tool} (obj,depend,all)"; \ cd ${.CURDIR}/${_tool}; \ @@ -1699,6 +1701,7 @@ .for _tool in \ gnu/usr.bin/binutils \ gnu/usr.bin/cc \ + gnu/usr.bin/gdb \ usr.bin/ar ${_+_}@${ECHODIR} "===> xdev ${_tool} (install)"; \ cd ${.CURDIR}/${_tool}; \ From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 03:32:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67033DE5 for ; Wed, 16 Jan 2013 03:32:27 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by mx1.freebsd.org (Postfix) with ESMTP id 29C4D2A3 for ; Wed, 16 Jan 2013 03:32:26 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id e13so1647381iej.4 for ; Tue, 15 Jan 2013 19:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=evBG7CofJuAeSULRVQEOQxZK6yzhQ8uP8QrlTg2Okhc=; b=PuWk7Hv07jc6arDELeFVWKJmxfNX+6lgfFv3+bw0fcKDy3YfyLHuYpNIZRmaBIIPzg vSyaHY/e66TZEsyVwHpsSWV5YTSEqvQ8orbYT+WcobEZ/fdCFTFgPxIbSCQetmAR1AGg yohTG52XvESn94iY6ptFfpytYFhF9oRB3eY9a5XN0tQ01KCDIsCkCPEEQ8izspUr3MWZ gkur1EX2JfCfdVAz7vNeu6l8j4Tp2k9dfpNzhbNWtJUCWo6NP7PP3YnzBQf7BAhboUyN 26t7HCm9v+aPKQcOe9UHYpcRpy8khJUw6wTwwF/FQBem7NJtHj2zxS6eiOlT2XpB6OnP AW1g== MIME-Version: 1.0 X-Received: by 10.50.196.138 with SMTP id im10mr3781243igc.83.1358307145446; Tue, 15 Jan 2013 19:32:25 -0800 (PST) Received: by 10.64.107.196 with HTTP; Tue, 15 Jan 2013 19:32:25 -0800 (PST) Date: Tue, 15 Jan 2013 19:32:25 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:32:27 -0000 > 25.9 MB/s Even Linux is pretty slow. > Transfer rates: > outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec > middle: 102400 kbytes in 0.747424 sec = 137004 kbytes/sec > inside: 102400 kbytes in 1.051036 sec = 97428 kbytes/sec That's more like it. I assume these numbers are reading. You should get numbers nearly this high when writing. Can you try writing to the bare drive without a filesystem? time dd if=/dev/da0 of=/dev/null bs=124k count=250000 time (dd if=/dev/zero if=/dev/da0 bs=124k count=250000; sync) Between writing more data than the size of memory and the sync, this should hopefully reduce any buffering effects down into the noise and make the numbers more comparable between FreeBSD and Linux. (and more honest) Also eliminates any effect from the filesystem, which will be different between FreeBSD and Linux. Writing should be almost as fast as reading. Is the disk healthy? Smartctl might give a clue. If the disk is healthy and you still get numbers that indicate one write per rev without a filesystem, then the question is why does the driver claim queueing but not deliver it? From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 01:26:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6E475105 for ; Wed, 16 Jan 2013 01:26:49 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 41131BF7 for ; Wed, 16 Jan 2013 01:26:49 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id y26so64137iab.37 for ; Tue, 15 Jan 2013 17:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=I0nTBrs4T1x33kcTIljdIl5Y6a/TNVfPZOg2S4fWiqo=; b=TO11UsQyNZAFpcf8sUJdIGLio1mDEeGVBUVwmINc3GRaXzv3GP8aDDNpRwiwVabRn1 TILBq8O+BA3Gv3NdgrG1aS/l1QOiqDe3QBMgaRhoyE5z9sUj/HZEewKuYjkfo3hWLzrI wpy7kU1K9tTggQKeHw603Sl2Fy+ouGps3U8Zv4vGOpnsN5QHNHPnciKhC6O3KthScYiI rC9Qg0xwb/UKu3zHzC5uz0EpCagf1XlF9wMgvB43h6U1CWYgPy6FA6nd+eYK2U0A7R0a XCcrQc+sQ3DCHHf0lMziFE8nFUDjJg6/OG/ES3VAOpztq49iZEk+S8osIZMkZMjjwwvY 71NQ== X-Received: by 10.43.7.7 with SMTP id om7mr100142icb.25.1358299608736; Tue, 15 Jan 2013 17:26:48 -0800 (PST) Received: from [10.0.0.131] ([24.225.136.71]) by mx.google.com with ESMTPS id iw5sm3315952igc.5.2013.01.15.17.26.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jan 2013 17:26:47 -0800 (PST) Message-ID: <50F601D2.3090009@gmail.com> Date: Tue, 15 Jan 2013 20:26:42 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Wojciech Puchar Subject: Re: IBM blade server abysmal disk write performances References: <50F5BC08.1060700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Jan 2013 03:51:41 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 01:26:49 -0000 On 15/01/2013 4:54 PM, Wojciech Puchar wrote: >> >> # dd if=/dev/zero of=foo count=1 bs=10240000 >> 1+0 records in >> 1+0 records out >> 10240000 bytes transferred in 19.579077 secs (523007 bytes/sec) >> > you write to file not device, so it will be clustered anyway by FreeBSD. > > 128kB by default, more if you put options MAXPHYS=... in kernel config > and recompile. > > Even with hard drive write cache disabled, it should about one write > per revolution but seems to do 4 writes per second. > > so probably it is not that but much worse failure. > > Did you rest read speed? > > dd if=/dev/disk of=/dev/null bs=512 > > dd if=/dev/disk of=/dev/null bs=4k > > dd if=/dev/disk of=/dev/null bs=128k > > ? > I'll do the read test as well but if I recall correctly it seemed pretty decent. It is quite obvious that something is awfully slow on SAS drives, whatever it is and regardless of OS comparison. We swapped the SAS drives for SATA and we're seeing much higher speeds. Basically on par with what we were expecting (roughly 300 to 400 times faster then what we see with SAS...). I find it strange that diskinfo reports those transfer rates: Transfer rates: outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec middle: 102400 kbytes in 0.747424 sec = 137004 kbytes/sec inside: 102400 kbytes in 1.051036 sec = 97428 kbytes/sec Yet we get only a tiny fraction of those (it takes 20 seconds to transfer 10MB!) when using dd. I also doubt its dd's behavior since how can we explain the performance going up with SATA when doing the same test? Unfortunately, we'll have to move on soon and we're about to write off SAS and use SATA instead. Thanks, Karim. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 03:54:58 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 443AD411 for ; Wed, 16 Jan 2013 03:54:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id EDF86377 for ; Wed, 16 Jan 2013 03:54:57 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0G3ss5I065909 for ; Tue, 15 Jan 2013 20:54:54 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0G3spjW004215; Tue, 15 Jan 2013 20:54:51 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: IBM blade server abysmal disk write performances From: Ian Lepore To: Karim Fodil-Lemelin In-Reply-To: <50F5BC08.1060700@gmail.com> References: <50F5BC08.1060700@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Jan 2013 20:54:51 -0700 Message-ID: <1358308491.32417.147.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 03:54:58 -0000 On Tue, 2013-01-15 at 15:28 -0500, Karim Fodil-Lemelin wrote: > On 15/01/2013 3:03 PM, Dieter BSD wrote: > > Disabling the disks's write cache is *required* for data integrity. > > One op per rev means write caching is disabled and no queueing. > > But dmesg claims "Command Queueing enabled", so you should be > getting > > more than one op per rev, and writes should be fast. > > Is this dd to the raw drive, to a filesystem? (FFS? ZFS? other?) > > Are you running compression, encryption, or some other feature > > that might slow things down? Also, try dd with a larger block size, > > like bs=1m. > Hi, > > Thanks to everyone that answered so far. Here is a follow up. dd to > the > raw drive and no compression/encryption or some other features, just > a > naive boot off a live 9.1 CD then dd (see below). The following > results > have been gathered on the FreeBSD 9.1 system: You say dd with a raw drive, but as several people have pointed out, linux dd doesn't go directly to the drive by default. It looks like you can make it do so with the "direct" option, which should make it behave the same as freebsd's dd behaves by default (I think, I'm no linux expert). For example, using a usb thumb drive: th2 # dd if=/dev/sdb4 of=/dev/null count=100 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0142396 s, 3.6 MB/s th2 # dd if=/dev/sdb4 of=/dev/null count=100 iflag=direct 100+0 records in 100+0 records out 51200 bytes (51 kB) copied, 0.0628582 s, 815 kB/s Hmm, just before hitting send I saw your other response that SAS drives behave badly, SATA are fine. That does seem to point away from dd behavior. It might still be interesting to see if the direct flag on linux drops performance into the same horrible range as freebsd with SAS. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 05:12:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D5C00684 for ; Wed, 16 Jan 2013 05:12:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3187B861 for ; Wed, 16 Jan 2013 05:12:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0G5CBJm036456; Wed, 16 Jan 2013 07:12:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0G5CBJm036456 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0G5CAQc036455; Wed, 16 Jan 2013 07:12:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 16 Jan 2013 07:12:10 +0200 From: Konstantin Belousov To: Trent Nelson Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130116051210.GF2522@kib.kiev.ua> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> <50F5D82C.7070400@mu.org> <1358289221.32417.129.camel@revolution.hippie.lan> <20130115230330.GA53211@snakebite.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Il7n/DHsA0sMLmDu" Content-Disposition: inline In-Reply-To: <20130115230330.GA53211@snakebite.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Ian Lepore , Alfred Perlstein , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 05:12:24 -0000 --Il7n/DHsA0sMLmDu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 06:03:30PM -0500, Trent Nelson wrote: > On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote: > > On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote: > > > On 1/15/13 1:43 PM, Konstantin Belousov wrote: > > > > On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: > > > >> > > > >> Luckily it's for an open source project (Python), so recompil= ation > > > >> isn't a big deal. (I also check the intrinsic result versus = the > > > >> syscall result during startup to verify the same ID is return= ed, > > > >> falling back to the syscall by default.) > > > > For you, may be. For your users, it definitely will be a problem. > > > > And worse, the problem will be blamed on the operating system and n= ot > > > > to the broken application. > > > > > > > Anything we can do to avoid this would be best. > > >=20 > > > The reason is that we are still dealing with an "optimization" that p= erl=20 > > > did, it reached inside of the opaque struct FILE to "do nasty things"= =2E =20 > > > Now it is very difficult for us to fix "struct FILE". > > >=20 > > > We are still paying for this years later. > > >=20 > > > Any way we can make this a supported interface? > > >=20 > > > -Alfred > >=20 > > Re-reading the original question, I've got to ask why pthread_self() > > isn't the right answer? The requirement wasn't "I need to know what the > > OS calls me" it was "I need a unique ID per thread within a process." >=20 > The identity check is performed hundreds of times per second. The > overhead of (Py_MainThreadId =3D=3D __readgsdword(0x48) ? A() : B()) = is > negligible -- I can't say the same for a system/function call. >=20 > (I'm experimenting with an idea I had to parallelize Python such > that it can exploit all cores without impeding the performance > of normal single-threaded execution (like previous-GIL-removal > attempts and STM). It's very promising so far -- presuming we > can get the current thread ID in a couple of instructions. If > not, single-threaded performance suffers too much.) If the only thing you ever need is to get a unique handle for the current thread, without the requirement that it corresponds to any other identifier, everything becomes much easier. On amd64, use 'movq %fs:0,%register', on i386 'movl %gs:0,%register'. This instruction is guaranteed to return the thread-unique address of the tcb. See an article about ELF TLS for more details. Even better, this instruction is portable among all ELF Unixes which support TLS. --Il7n/DHsA0sMLmDu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9japAAoJEJDCuSvBvK1BjwkQAJ2oQ+UiLC2i7OpafggR2fob c0ICWGwq3bpiMcQke+VymAh0FakVvoMyfir/+K7ResqhPmSGpC61T3yOhUKLa8PB ZLM7YEfgFhFhBHfWFM2j2ejOn3+TkOv1xPYVZyOo9kQtwoj7LnB9u6qTlDdKfVdo o9Mh5eIBTIQ81UxdY9ow7a2X7mZdm1OK2UlIN/TA908eIKN6CW9FWf5+QhTErQTL zEg33QGPJK1OD3yMRIM1ZatXEvF3RtCUqXbM+8DKeuuErPKNws3OeZGYs1UDsBxG kbzjO9TGhwNDPqBoNUw2lJAYV5F4iiOBpcZbvQMwZF4IDstKxOxQ2CeXr5aSu4Lh qY4kb2Vs4WbQBmoEwMTSaRyCckZOU1sAUjabuEpDNxTlmGMOb6XvbBmdHD3cp1Pf DByV2T505uE/8fZUDyy0pserUPaEDHVlNu/IxD8t40kYGUib+qdgGJ8NG1Uq1kpT b0ywigZdXoU1ZwAHvJoa1L27rH7hQWKlaH2bJLxSJq9lzVNaLDXxoFLzPJQd2it/ fI2apBEw4XKMybYriIIAwMCD4+buK4eVtUlWaaE2AkHdhoZZQeiZXIFum93cH71t eP61V0Cc8d1VrMEQkDt1iIjTYOSVpRugoIPR/edDQ0CHl570bPNBMFstBXs13dBb fqM/thjYLkpHF2UajCkw =Cpnh -----END PGP SIGNATURE----- --Il7n/DHsA0sMLmDu-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 05:15:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E7B27A4; Wed, 16 Jan 2013 05:15:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 1B76A87D; Wed, 16 Jan 2013 05:15:17 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so597102wgh.19 for ; Tue, 15 Jan 2013 21:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=nyffFEU7b1yKrcNQVeyY/zr3oNHAng2WWBWoLIwWU1g=; b=pzkfBq7yWVVGHBMvpIBm5RMXV5Y+cGkdaDOMH+iiV+SbCeuJNi1fxKgOxmGnxmtfAa QW3DAmY3WiUJczbzeAdEB40+/J1GnF1TeranCxZ3x8d/zpYfyDOo8tmKwdAJmbYW/Nb2 Loawm0JKrQ1gkm8d3aknt09rR8m3BoM8KPRwa5d2ZgOAD8+HWcPZb1dsR2mD2M/i/gjv fZb3H2vhwXQwYngj8EIrYz86hQH2PodPr06wGHQKRKlvkbgUcuyPUY8e8gVOEuOmzf6v PuP7+CoUybZjv7oBZNBV2HYGySMd0N5iJGUVZ6Z+OGoaZkadlLF4FkhZI9VI/u3KMX5C G6uw== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr7420563wiv.33.1358313311570; Tue, 15 Jan 2013 21:15:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 21:15:11 -0800 (PST) Date: Tue, 15 Jan 2013 21:15:11 -0800 X-Google-Sender-Auth: A98CtrDRxI-7miMqNDazmcNBKHg Message-ID: Subject: [RFC] support -b when starting gdb From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 05:15:18 -0000 Hi, There doesn't seem to be a blessed way to set the baudrate from inside gdb/kgdb. It seems to be set from '-b' on the command line. However kgdb doesn't have this support. This patch adds -b support so kgdb so I can override the default speed (9600 it seems) to speak kgdb over serial to a 115200 console MIPS device. The MIPS stuff has other issues; I'll talk about those later. Thanks, Adrian Index: gnu/usr.bin/gdb/kgdb/main.c =================================================================== --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) @@ -333,11 +333,24 @@ args.argv = malloc(sizeof(char *)); args.argv[0] = argv[0]; - while ((ch = getopt(argc, argv, "ac:d:fn:qr:vw")) != -1) { + while ((ch = getopt(argc, argv, "ab:c:d:fn:qr:vw")) != -1) { switch (ch) { case 'a': annotation_level++; break; + case 'b': + { + int i; + char *p; + + i = strtol (optarg, &p, 0); + if (i == 0 && p == optarg) + warnx("warning: could not set baud rate to `%s'.\n", + optarg); + else + baud_rate = i; + } + break; case 'c': /* use given core file. */ if (vmcore != NULL) { warnx("option %c: can only be specified once", From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 06:30:44 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6A9BC88F; Wed, 16 Jan 2013 06:30:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id DCF73B55; Wed, 16 Jan 2013 06:30:43 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so606245wge.34 for ; Tue, 15 Jan 2013 22:30:37 -0800 (PST) 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=/8uS09CjKBm65kRjO6rRQGIsaPrzoU5E9d/xMY5BKmE=; b=N6rA4sae8eN2PRwo1AZRg4qpzsF6DkP6pU6a7FwBWob9cCjlbWSPbC/omO9zDSVvoG giOQfiq/uvK25ikLRlz220kXAo0kt1qQIz7ehOGIfQa2yJnPTKgrrDyqpu3gbpME44qw hUbN1mb5SZR95EAmaxAhEr4/4dvgs60g0UgOTDkXR0yRUAXlHFJ/j8aPWk8f7ALRyXWI jO3KSmOG8nstmezlq8jsByQMMW72CHS0VuvORweS1JgR+W9PFfDciZ3adOiwWzvPjq0O iRXzKuiV5sCy5nJVlmKCjXcnqu0lf78BRhsgEdTFl++cLlmPLt1nQ5zXMQcc+MypB3Cs weVw== MIME-Version: 1.0 Received: by 10.195.13.67 with SMTP id ew3mr58373093wjd.59.1358317837316; Tue, 15 Jan 2013 22:30:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Tue, 15 Jan 2013 22:30:37 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Jan 2013 22:30:37 -0800 X-Google-Sender-Auth: ehIyRbgPAMOlRWOlEBTI9Hujejo Message-ID: Subject: Re: [RFC] support -b when starting gdb From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 06:30:44 -0000 Also, I found 'set remotebaud' and 'set debug remote 1' to do this. I'd like to add the code just to support the same -b flag as gdb (so -r can also be used with a non-standard serial port.) Thanks, Adrian On 15 January 2013 21:15, Adrian Chadd wrote: > Hi, > > There doesn't seem to be a blessed way to set the baudrate from inside > gdb/kgdb. It seems to be set from '-b' on the command line. > > However kgdb doesn't have this support. > > This patch adds -b support so kgdb so I can override the default speed > (9600 it seems) to speak kgdb over serial to a 115200 console MIPS > device. > > The MIPS stuff has other issues; I'll talk about those later. > > Thanks, > > > > Adrian > > > Index: gnu/usr.bin/gdb/kgdb/main.c > =================================================================== > --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) > +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) > @@ -333,11 +333,24 @@ > args.argv = malloc(sizeof(char *)); > args.argv[0] = argv[0]; > > - while ((ch = getopt(argc, argv, "ac:d:fn:qr:vw")) != -1) { > + while ((ch = getopt(argc, argv, "ab:c:d:fn:qr:vw")) != -1) { > switch (ch) { > case 'a': > annotation_level++; > break; > + case 'b': > + { > + int i; > + char *p; > + > + i = strtol (optarg, &p, 0); > + if (i == 0 && p == optarg) > + warnx("warning: could not set baud > rate to `%s'.\n", > + optarg); > + else > + baud_rate = i; > + } > + break; > case 'c': /* use given core file. */ > if (vmcore != NULL) { > warnx("option %c: can only be specified once", From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 07:20:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 859525D6 for ; Wed, 16 Jan 2013 07:20:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id AB8C1E9D for ; Wed, 16 Jan 2013 07:20:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0G7KEoe004565; Wed, 16 Jan 2013 08:20:14 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0G7KD20004562; Wed, 16 Jan 2013 08:20:13 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 Jan 2013 08:20:13 +0100 (CET) From: Wojciech Puchar To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 Jan 2013 08:20:14 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:20:16 -0000 >> The kernel must be doing write-behind even to a raw disk, otherwise >> waiting for write(2) to return before issuing the next write would >> slow it down as Matthew suggests. > > And a minute after hitting send, I remembered that FreeBSD does not > provide the traditional "raw" disk devices, e.g. /dev/rda0 with an 'r'. > (Now if I could just remember *why* it doesn't.) because they are only raw devices. caching is in filesystem. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 07:20:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B69E6C5 for ; Wed, 16 Jan 2013 07:20:49 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6664EEAA for ; Wed, 16 Jan 2013 07:20:48 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0G7KkOf004574; Wed, 16 Jan 2013 08:20:46 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0G7Kktj004571; Wed, 16 Jan 2013 08:20:46 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 16 Jan 2013 08:20:46 +0100 (CET) From: Wojciech Puchar To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <50F601D2.3090009@gmail.com> Message-ID: References: <50F5BC08.1060700@gmail.com> <50F601D2.3090009@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Wed, 16 Jan 2013 08:20:46 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:20:49 -0000 > Transfer rates: > outside: 102400 kbytes in 0.685483 sec = 149384 kbytes/sec > middle: 102400 kbytes in 0.747424 sec = 137004 kbytes/sec > inside: 102400 kbytes in 1.051036 sec = 97428 kbytes/sec this is right. > Yet we get only a tiny fraction of those (it takes 20 seconds to transfer > 10MB!) when using dd. I also doubt its dd's behavior since how can we explain dd is fine. hardware configuration isn't From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 07:48:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 690EFFB3 for ; Wed, 16 Jan 2013 07:48:26 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id 44BD4FD3 for ; Wed, 16 Jan 2013 07:48:26 +0000 (UTC) Received: by mail-ia0-f177.google.com with SMTP id h8so96715iaa.22 for ; Tue, 15 Jan 2013 23:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=UMWpVG3H/cYmVwNqF5ctGHSxfBri8csGcfbbvpklgz4=; b=SHBneURVTB7yV1qV8Fgp4nefGkiYRjEoy2mmo7l20GVYKVNNgSX0ULkH6jZRMkPC28 PvXJcB4VtSoswbob69YxAWs3SKUucOgoSh/myncDaX6n7gwgztnplN9VsE4Klr4h+S7E +jwo53lpA6r7vGJawMJGdOb0q0lt4LvhMTY8RMyOb3647hiTXOcHRF1cdfZYJa9aY82e 5oozb4QHkpeYBGt5l1tJR397NlIz07oFdbkMj0NCD67C6PlM7hHBEBQ3nf2qKcPKQMF2 iCh+l7vYg4AbWdMPj2Y8iCkQTD3MXs9Mf7jdezu9skdDysvvt25i2RFwZ0u+E7R31LSo vtyA== MIME-Version: 1.0 X-Received: by 10.50.159.165 with SMTP id xd5mr105010igb.82.1358322506005; Tue, 15 Jan 2013 23:48:26 -0800 (PST) Received: by 10.64.107.196 with HTTP; Tue, 15 Jan 2013 23:48:25 -0800 (PST) Date: Tue, 15 Jan 2013 23:48:25 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 07:48:26 -0000 Karim writes: > It is quite obvious that something is awfully slow on SAS drives, > whatever it is and regardless of OS comparison. We swapped the SAS > drives for SATA and we're seeing much higher speeds. Basically on par > with what we were expecting (roughly 300 to 400 times faster then what > we see with SAS...). Major clue there! According to wikipedia: "Most SAS drives provide tagged command queuing, while most newer SATA drives provide native command queuing" [1] Note that the driver says "Command Queueing enabled" without specifying which. If the driver is trying to use SATA's NCQ but the drive only speaks SCSI's TCQ, that could explain it. Or if the TCQ isn't working for some other reason. See if there are any error messages in dmesg or /var/log. If not, perhaps the driver has extra debugging you could turn on. Get TCQ working and make sure your partitions are aligned on 4 KiB boundaries (in case the drive actually has 4 KiB sectors), and you should get the expected performance. [1] http://en.wikipedia.org/wiki/Serial_attached_SCSI From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 10:34:42 2013 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EB2EF92; Wed, 16 Jan 2013 10:34:42 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9F872B61; Wed, 16 Jan 2013 10:34:41 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.6/8.14.6) with ESMTP id r0GAYeBJ047468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 16 Jan 2013 11:34:40 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Wed, 16 Jan 2013 11:34:40 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help Message-ID: <20130116103439.GS35868@acme.spoerlein.net> Mail-Followup-To: current@FreeBSD.org, hackers@FreeBSD.org References: <20121215132246.GH69724@acme.spoerlein.net> <20121230113834.GG69724@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="brEuL7wsLY8+TuWz" Content-Disposition: inline In-Reply-To: <20121230113834.GG69724@acme.spoerlein.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 10:34:42 -0000 --brEuL7wsLY8+TuWz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This has been completed, your next pull will result in a non-fastforwardable change and I'd advise you to re-branch from origin/master instead. If you run into any trouble, don't hesitate to contact me directly. Thanks and sorry for the inconvenience, Uli On Sun, 2012-12-30 at 12:38:34 +0100, Ulrich Sp=C3=B6rlein wrote: > Just a reminder that this re-roll will happen in almost two weeks. >=20 > Thanks to a couple of volunteers, I now have independent confirmation > that the process is deterministic and repeatable and the switch can > progress as planned. >=20 > Regards, > Uli >=20 > On Sat, 2012-12-15 at 14:22:46 +0100, Ulrich Sp=C3=B6rlein wrote: > > Bad news everyone, > >=20 > > tl;dr The git mirror of the source repository needs to be re-rolled to > > make the conversion deterministically repeatable, this will change > > pretty much all git commit hashes. > >=20 > > The re-roll will be done January 15, 2013. > >=20 > > Not affected are the ports and doc repositories, nor is the svn_head > > (for use with git-svn) affected. > >=20 > >=20 > > Background > >=20 > > The converter (svn2git) was handing commits and objects to git's > > fast-import in arbitrary order, this makes merge commits have an > > arbitrary order of their parent commits and thus these merge commits > > have changing commit hashes for each converter run. > >=20 > > This has been fixed, but requires us to move all the branches over to > > this deterministic scheme, which will change all their commit hashes. > > None of the contents of these commits change, so rebasing/remerging your > > work into these branches is possible without running into any merge > > conflicts. > >=20 > >=20 > > We need your help > >=20 > > A goal of these conversions is to have them repeatable by you (yes, > > you!), so the correctness of the conversion can be verified. There are > > also no backups of the conversion runs, as they should be repeatable > > anyway. > >=20 > > We need 2-3 volunteers to run these conversions themselves and verify > > that the produced commit hashes match the published ones. The necessary > > steps to do this are documented on the Wiki under > >=20 > > http://wiki.freebsd.org/GitWorkflow#History > >=20 > > Please send me your output of git show-ref in a private mail, thanks. > >=20 > > Cheers, > > Uli > >=20 > > PS: This re-roll has nothing to do with the recent security incident. >=20 >=20 --brEuL7wsLY8+TuWz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAEBAgAGBQJQ9oI/AAoJEKOmmGRKr4LOZw8H+QHI37qmjUjjiNZuR2HlHCUy oR1vfHi8HxFhHVvklo93K/1Qc6PnuxvzqCaeUPtr2JlqDN8l3HpI6RfGyJ5fw2Ja qy9/EBsyWhLsMHzKUsJhV7rm1Z/2Z0DqpxIhywy4TvghVBdL/5Vwzv/BtzFBrpyD 3kKfbbGStoDEkc54hP+P1/3B/6UUpXk0Hush9xrw2PkwPUWlbwjlz/iBgN6jhOkX KC8UtM9XNz5XOUGVSOR3Qb6psl5Fk9Qg9VcXVHVvtdth5LvvLglEU48WICpo65SP rJ8a3AkEyGjet1oUyiM5YZ5Bc5z1GoZn83iC1PganHA7cOR0HdLC1wCKkUkWrXI= =CSit -----END PGP SIGNATURE----- --brEuL7wsLY8+TuWz-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 11:55:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 084A4D9 for ; Wed, 16 Jan 2013 11:55:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B513975 for ; Wed, 16 Jan 2013 11:55:48 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TvRas-0000Pr-8O; Wed, 16 Jan 2013 13:55:46 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Wojciech Puchar Subject: Re: off topic but no idea where to ask In-reply-to: References: Comments: In-reply-to Wojciech Puchar message dated "Tue, 15 Jan 2013 19:18:13 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jan 2013 13:55:46 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 11:55:49 -0000 > does anyone know a PXE image (just like /boot/pxeboot) that can be placed > on tftp server and the only thing it will do would be loading first sector > from first local disk at 0x07c00 and booting as with normal hard drive. > instead of pxeboot, try giving /boot/boot0 > what i need is to be able to decide from server side if given computer > boots from NFS or hard disk. > > thanks > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 15:35:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 053284B3 for ; Wed, 16 Jan 2013 15:35:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id B3FFC9C for ; Wed, 16 Jan 2013 15:35:55 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so2698398iec.41 for ; Wed, 16 Jan 2013 07:35:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=tAms8dfU28PihyxzJF7t7q0DLQGJ50AMDAga/Tqxtak=; b=UfHEsvIyuve42ypqt5CV4vU5+7R5GEDFiGnCznivo5qSxz4xC1fpIIInWK/dAZm7t4 wud3TZmjMQ/TaGxhjlNVtHEGEb48FHAV7+7jP9mJOUWM2KA395qNHmWYboSOlNaW79b1 SjsVDWTgWEqlCL0CL3zkIs5XCWDlFR1lnh68zXpOWlFtTeMEuwl1zMwgMGnlxuERt4S7 arzRSSHmKgVaREG3Kvz0eG5lgPGSAXoPKwGvcgp3Xwo3T2sUs4lGxL47hNoQ/BPCNZZI gUhuIcDtIc38ncPXNigTPKM68qmjiowA3F8aH9PAhMPWcsotPOgUd2UVTR/XAXGpPDyZ DGDw== X-Received: by 10.50.190.162 with SMTP id gr2mr5105579igc.65.1358350555145; Wed, 16 Jan 2013 07:35:55 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id uj6sm5010562igb.4.2013.01.16.07.35.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 07:35:54 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] support -b when starting gdb Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 16 Jan 2013 08:35:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlUu5Y/Bc5Y2kgUNb1oUevgFZ2qVELU1nXgk0+dH6z1F3g2xXXy8XcQ6NvCB4W58iPUVIYC Cc: freebsd-hackers@freebsd.org, freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 15:35:56 -0000 How does 'set remotebaud' not do what you want? Warner On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: > Hi, >=20 > There doesn't seem to be a blessed way to set the baudrate from inside > gdb/kgdb. It seems to be set from '-b' on the command line. >=20 > However kgdb doesn't have this support. >=20 > This patch adds -b support so kgdb so I can override the default speed > (9600 it seems) to speak kgdb over serial to a 115200 console MIPS > device. >=20 > The MIPS stuff has other issues; I'll talk about those later. >=20 > Thanks, >=20 >=20 >=20 > Adrian >=20 >=20 > Index: gnu/usr.bin/gdb/kgdb/main.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) > +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) > @@ -333,11 +333,24 @@ > args.argv =3D malloc(sizeof(char *)); > args.argv[0] =3D argv[0]; >=20 > - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) { > + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D -1) = { > switch (ch) { > case 'a': > annotation_level++; > break; > + case 'b': > + { > + int i; > + char *p; > + > + i =3D strtol (optarg, &p, 0); > + if (i =3D=3D 0 && p =3D=3D optarg) > + warnx("warning: could not set baud > rate to `%s'.\n", > + optarg); > + else > + baud_rate =3D i; > + } > + break; > case 'c': /* use given core file. */ > if (vmcore !=3D NULL) { > warnx("option %c: can only be specified = once", > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 16:05:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1ED1D5D; Wed, 16 Jan 2013 16:05:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAD92FD; Wed, 16 Jan 2013 16:05:08 +0000 (UTC) Received: by mail-da0-f50.google.com with SMTP id h15so633383dan.9 for ; Wed, 16 Jan 2013 08:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=XYH3yi/pVxg1MX0/aberFWCl9l/GHojyVdJSlz/mxb4=; b=zEsg+t+rcFaJPCSpKOuunuZ/4uLpllfiD8MKUZpffMXZH85BxVSUje3ydhoz2/wRsz OJTjja97Pd00XMvUW7TGXMR5WjwRsclj2rjeOWcIEmoHdWQxxp/zP3POTtXMOFDtIvSO pVLtNYJj7JeSTdp6srmeR/YXjPb8Gj2AJHaepgsfdsClexnE4pAHJj4DX8WRGz7PPWg+ SRQ28oqQxbFGxRoEGCNdm9BHzU3PLQrjhAYLJF4+ClLLyhDDWxaAoR1bE8H2f2ffZxD5 Ut3GxgQ4Ry96tjz00Nr7brvs8DCOFV3EevICuoCfXfkRxDNR5N/zX4Uka6qxkTaFI8Oq 4GvQ== X-Received: by 10.68.245.67 with SMTP id xm3mr3903540pbc.152.1358352308365; Wed, 16 Jan 2013 08:05:08 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id q4sm10179120paz.20.2013.01.16.08.05.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 08:05:07 -0800 (PST) References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> Mime-Version: 1.0 (1.0) In-Reply-To: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: [RFC] support -b when starting gdb Date: Wed, 16 Jan 2013 08:05:06 -0800 To: Warner Losh Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 16:05:08 -0000 On Jan 16, 2013, at 7:35 AM, Warner Losh wrote: > How does 'set remotebaud' not do what you want? >=20 > Warner >=20 > On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: >=20 >> Hi, >>=20 >> There doesn't seem to be a blessed way to set the baudrate from inside >> gdb/kgdb. It seems to be set from '-b' on the command line. >>=20 >> However kgdb doesn't have this support. >>=20 >> This patch adds -b support so kgdb so I can override the default speed >> (9600 it seems) to speak kgdb over serial to a 115200 console MIPS >> device. >>=20 >> The MIPS stuff has other issues; I'll talk about those later. >>=20 >> Thanks, >>=20 >>=20 >>=20 >> Adrian >>=20 >>=20 >> Index: gnu/usr.bin/gdb/kgdb/main.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) >> +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) >> @@ -333,11 +333,24 @@ >> args.argv =3D malloc(sizeof(char *)); >> args.argv[0] =3D argv[0]; >>=20 >> - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) { >> + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D -1) { >> switch (ch) { >> case 'a': >> annotation_level++; >> break; >> + case 'b': >> + { >> + int i; >> + char *p; >> + >> + i =3D strtol (optarg, &p, 0); >> + if (i =3D=3D 0 && p =3D=3D optarg) >> + warnx("warning: could not set baud >> rate to `%s'.\n", >> + optarg); >> + else >> + baud_rate =3D i; >> + } >> + break; >> case 'c': /* use given core file. */ >> if (vmcore !=3D NULL) { >> warnx("option %c: can only be specified onc= e", It's more of a convenience factor and easier to script command line argument= s IMO. Thanks, -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 17:52:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E99D2D91 for ; Wed, 16 Jan 2013 17:52:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC8CE0E for ; Wed, 16 Jan 2013 17:52:47 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id a19so1380606qad.19 for ; Wed, 16 Jan 2013 09:52:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=XAhSP1O+XHJJvMqOsBZuZgAq4miDMH9V8XqZpNoLvxU=; b=OaRkwiDHA3NO2/AtHKRIJp/Ssib8s3yoh9LSTD/vWDWSJx9MF9KBZoLtvY5m2D1vlG ZJjGif6ABQklrpoRegh1ze9jVgjB4GSdg/5fptnfCyVDm6W2cyiyHcP6rJWLdIhmhlO/ FByTpGfNmzUJmcyVuseuTLJEVgvjWd1BQzhjXBrRmnynireec901K5PdCKXttQjj2w/A KGVJiPbp27AfP9p2HngmOq7nkXHDlKjs6JwzNaqvN7P1d/wWHRvfjzG8Qi6HMraf73Xp cMmso9gBk6RicWFldSf1yig+scbBkXC/8wjUb1R+6SzhMuhrlbZxbEF7Ar0CnOUlXKl5 GpVA== X-Received: by 10.49.49.226 with SMTP id x2mr2452224qen.45.1358358761153; Wed, 16 Jan 2013 09:52:41 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x9sm13235807qen.1.2013.01.16.09.52.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jan 2013 09:52:39 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] support -b when starting gdb Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> Date: Wed, 16 Jan 2013 10:52:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlp6qILH8zx5ONsrthZKo0WMcK2geAETqfNIAiJEv1EUgcflckB+fYNge5hDPAcu8M6aZjg Cc: "freebsd-hackers@freebsd.org" , Adrian Chadd , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 17:52:48 -0000 On Jan 16, 2013, at 9:05 AM, Garrett Cooper wrote: > On Jan 16, 2013, at 7:35 AM, Warner Losh wrote: >=20 >> How does 'set remotebaud' not do what you want? >>=20 >> Warner >>=20 >> On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote: >>=20 >>> Hi, >>>=20 >>> There doesn't seem to be a blessed way to set the baudrate from = inside >>> gdb/kgdb. It seems to be set from '-b' on the command line. >>>=20 >>> However kgdb doesn't have this support. >>>=20 >>> This patch adds -b support so kgdb so I can override the default = speed >>> (9600 it seems) to speak kgdb over serial to a 115200 console MIPS >>> device. >>>=20 >>> The MIPS stuff has other issues; I'll talk about those later. >>>=20 >>> Thanks, >>>=20 >>>=20 >>>=20 >>> Adrian >>>=20 >>>=20 >>> Index: gnu/usr.bin/gdb/kgdb/main.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- gnu/usr.bin/gdb/kgdb/main.c (revision 245281) >>> +++ gnu/usr.bin/gdb/kgdb/main.c (working copy) >>> @@ -333,11 +333,24 @@ >>> args.argv =3D malloc(sizeof(char *)); >>> args.argv[0] =3D argv[0]; >>>=20 >>> - while ((ch =3D getopt(argc, argv, "ac:d:fn:qr:vw")) !=3D -1) = { >>> + while ((ch =3D getopt(argc, argv, "ab:c:d:fn:qr:vw")) !=3D = -1) { >>> switch (ch) { >>> case 'a': >>> annotation_level++; >>> break; >>> + case 'b': >>> + { >>> + int i; >>> + char *p; >>> + >>> + i =3D strtol (optarg, &p, 0); >>> + if (i =3D=3D 0 && p =3D=3D optarg) >>> + warnx("warning: could not set baud >>> rate to `%s'.\n", >>> + optarg); >>> + else >>> + baud_rate =3D i; >>> + } >>> + break; >>> case 'c': /* use given core file. */ >>> if (vmcore !=3D NULL) { >>> warnx("option %c: can only be specified = once", >=20 > It's more of a convenience factor and easier to script command line = arguments IMO. True, but he said there was no way to do it... I have this in my setup = scripts when I have to do serial debugging... Warner From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 18:24:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7790727F; Wed, 16 Jan 2013 18:24:57 +0000 (UTC) (envelope-from adrian.chadd@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 DF8FCE1; Wed, 16 Jan 2013 18:24:56 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so1049090wgb.17 for ; Wed, 16 Jan 2013 10:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=V4AO9x+tqfor9DwWeHFvTp+4JaEhu4COJ6yCsQouJAM=; b=RhfRPrsWt+Xtb5gpKhHP62gR22VD0S9/LHWmDdeFUrfpIfgPvsvrccMTw54tMtn/GH 0quYQyZIHJr8k7uSWMwzmkP6Hpd5br4YM/4c8rBO/S3iSahMTZilxWKJgez+Nlzpl9xh vFTHxJ7zGVlh7niiNetrky20wOFXFhs2cBM0BfyLQt1H5QAoac9Jqs7ZqwkLMEy3IGGP MB0nDRfoVXYMNjfQiV91ScrvH0piatdecjvgjsm/jzhVGVQHyAC93L3EH7gW8sL1lR08 BZKEraOg0hoxVf6b6xGUoAmzYJ9aXFdIEcIpSiTdJZ+gpAuJwElo0bdiMNSQGage7GsN KWjQ== MIME-Version: 1.0 X-Received: by 10.180.72.146 with SMTP id d18mr11447670wiv.33.1358360695803; Wed, 16 Jan 2013 10:24:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Wed, 16 Jan 2013 10:24:55 -0800 (PST) In-Reply-To: <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> References: <89207049-41FF-479D-90EE-89652937AB29@bsdimp.com> <816C84A4-BF12-468C-BED8-797A319E9CDC@gmail.com> <52655D4C-6B01-4E62-B639-51142EEE8353@bsdimp.com> Date: Wed, 16 Jan 2013 10:24:55 -0800 X-Google-Sender-Auth: UCnwpyFmMS1Hp84BNE6HyKADy8I Message-ID: Subject: Re: [RFC] support -b when starting gdb From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , "freebsd-hackers@freebsd.org" , freebsd-current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:24:57 -0000 It wasn't listed anywhere in the documentation / wiki. I only found it after I had posted that patch. eg: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-gdb.html I had to do a whole lot of searching to finally discover that particular option. And yes, it'd be nice to have -b so I can use -b and -r to instantly open up a remote gdb session. Adrian From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 18:43:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2D44903; Wed, 16 Jan 2013 18:43:08 +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 815C2219; Wed, 16 Jan 2013 18:43:08 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D9B13B976; Wed, 16 Jan 2013 13:43:07 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: [RFC] support -b when starting gdb Date: Wed, 16 Jan 2013 11:17:23 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; 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: <201301161117.23253.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Jan 2013 13:43:07 -0500 (EST) Cc: freebsd-hackers@freebsd.org, Adrian Chadd X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:43:08 -0000 On Wednesday, January 16, 2013 1:30:37 am Adrian Chadd wrote: > Also, I found 'set remotebaud' and 'set debug remote 1' to do this. > > I'd like to add the code just to support the same -b flag as gdb (so > -r can also be used with a non-standard serial port.) I think adding -b is fine. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 19:05:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 764EA63E; Wed, 16 Jan 2013 19:05:28 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 436F236B; Wed, 16 Jan 2013 19:05:27 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r0GJ4xhS018207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jan 2013 13:04:59 -0600 Received: from [10.0.0.102] (10.14.152.24) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 16 Jan 2013 13:04:59 -0600 Subject: Re: kgzip(1) is broken MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: Date: Wed, 16 Jan 2013 11:04:54 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <23AAEBCB-6438-42EB-9B2E-E657CFC3BA1B@fisglobal.com> References: <09b701cdf367$12737530$375a5f90$@freebsd.org> <1358291098.32417.134.camel@revolution.hippie.lan> <0a0001cdf375$60ddbc40$229934c0$@freebsd.org> <0a2301cdf37d$ebe705a0$c3b510e0$@fisglobal.com> <1358296967.32417.137.camel@revolution.hippie.lan> <0a4601cdf384$4ff98e40$efecaac0$@freebsd.org> To: Steven Hartland X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.24] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-16_06:2013-01-16,2013-01-16,1970-01-01 signatures=0 Cc: 'Ian Lepore' , dteske@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:05:28 -0000 On Jan 15, 2013, at 5:07 PM, Steven Hartland wrote: >=20 > ----- Original Message ----- From: > To: "'Ian Lepore'" > Cc: ; > Sent: Wednesday, January 16, 2013 12:56 AM > Subject: RE: kgzip(1) is broken >=20 >=20 >>> -----Original Message----- >>> From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] >>> Sent: Tuesday, January 15, 2013 4:43 PM >>> To: Devin Teske >>> Cc: dteske@freebsd.org; freebsd-hackers@freebsd.org >>> Subject: RE: kgzip(1) is broken >>> On Tue, 2013-01-15 at 16:10 -0800, Devin Teske wrote: >>>>=20 >>>>> -----Original Message----- >>>>> From: Devin Teske [mailto:devin.teske@fisglobal.com] On Behalf Of >>>>> dteske@freebsd.org >>>>> Sent: Tuesday, January 15, 2013 3:10 PM >>>>> To: 'Ian Lepore' >>>>> Cc: freebsd-hackers@freebsd.org; dteske@freebsd.org >>>>> Subject: RE: kgzip(1) is broken >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ian Lepore [mailto:freebsd@damnhippie.dyndns.org] >>>>>> Sent: Tuesday, January 15, 2013 3:05 PM >>>>>> To: dteske@freebsd.org >>>>>> Cc: freebsd-hackers@freebsd.org >>>>>> Subject: Re: kgzip(1) is broken >>>>>>=20 >>>>>> On Tue, 2013-01-15 at 13:27 -0800, dteske@freebsd.org wrote: >>>>>>> Hello, >>>>>>>=20 >>>>>>> I have been sad of-late because kgzip(1) no longer produces a usable >>>> kernel. >>>>>>>=20 >>>>>>> All versions of 9.x suffer this. >>>>>>>=20 >>>>>>> And somewhere between 8.3-RELEASE-p1 and 8.3-RELEASE-p5 this >>> recently >>>>>> broke in >>>>>>> the 8.x series. >>>>>>>=20 >>>>>>> I haven't tried the 7 series lately, but if whatever is making the >> rounds >>>>> gets >>>>>>> MFC'd that far back, I expect the problem to percolate there too. >>>>>>>=20 >>>>>>> The symptom is that the machine reboots immediately and unexpectedly >>> the >>>>>> moment >>>>>>> the kernel is executed by the loader. >>>>>>>=20 >>>>>>> This is quite troubling and I am looking for someone to help find t= he >>>>> culprit. I >>>>>>> don't know where to start looking. >>>>>>=20 >>>>>> Here are some possible candidates from the things that were MFC'd to= 8 >>>>>> in that timeframe. I haven't looked at what these do, they're just >>>>>> changes that affect files related to booting. >>>>>>=20 >>>>>> r233211 >>>>>> r233377 >>>>>> r233469 >>>>>> r234563 >>>>>>=20 >>>>>=20 >>>>> Thanks Ian! >>>>>=20 >>>>> I'll test each one individually to see if regressing any one (or all) >>>> addresses >>>>> the problem. >>>>=20 >>>> Progress... >>>>=20 >>>> Looks like I found the culprit. >>>>=20 >>>> Turns out it's a back-ported bxe(4) driver (back-ported from 9 -- where >> kgzip >>>> seems to never work). >>>>=20 >>>> I wonder why back-porting bxe(4) from stable/9 to releng/8.3 would cau= se >>> kgzip >>>> to produce non-working kernels. >>>>=20 >>> Yeah, it'll be interesting to see how a device driver can lead to "the >>> machine reboots immediately and unexpectedly the moment the kernel is >>> executed by the loader," which I took to mean "before seeing the >>> copyright or anything." >> Indeed... loader throws up the syms and upon execution *KABOOM* (screen = goes >> black and back to POST) >> The copyright never appears. >>>> I'm emailing the maintainers (davidch + other Broadcom folk) >> The current dossier is even more interesting... the back-ported driver (= with >> zero modifications mind you from stable/9 to stable/8) exhibits memory f= ailures >> (example below), and causes terminals to become wedged when attempting t= o (for >> example) scp a file over an existing configured network (igb-based -- pr= esumably >> unrelated to bxe but in practice loading bxe causes igb to misbehave). >> $ ifconfig bxe0 inet 192.168.1.5/24 >> bxe0: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Canno= t fill >> fp[00] RX chain. >> bxe0: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborti= ng! >> $ ifconfig bxe1 inet 192.168.1.6/24 >> bxe1: ../../../dev/bxe/if_bxe.c(10939): Memory allocation failure! Canno= t fill >> fp[00] RX chain. >> bxe1: ../../../dev/bxe/if_bxe.c(3921): NIC initialization failed, aborti= ng! >> (as expected, also sent mail off to maintainers w/respect to above notes= /errors) >=20 > Sounds like you may be out of mbufs which is easy, on a box with 4 igb's = simply > booting without tuning with cause this so, if you have igb's and bxe's th= is > could be your cause. >=20 > Try adding the following to loader.conf and see if it helps:- > kern.ipc.nmbclusters=3D51200 >=20 Sorry for delayed response -- we had to go through a power cycle. I haven't yet tried bumping the value as suggested, but I suspect it will i= ndeed help greatly -- I noticed that I got 18% into the scp before things t= ook a dive for the worse (hanging terminals and such). Another thing worth noting about the uplifted bxe(4) plopped into RELENG_8= =85 when we rebooted: bxe0: ../../../dev/bxe/if_bxe.c(6419): Slowpath queue is full! bxe0: ---------- Begin crash dump ---------- bxe0: ---------- End crash dump ---------- bxe0: ../../../dev/bxe/if_bxe.c(6419): Slowpath queue is full! bxe0: ---------- Begin crash dump ---------- bxe0: ---------- End crash dump ---------- bxe0: ../../../dev/bxe/if_bxe.c(3262): fp[01] client ramrod halt failed! Heh. The machine had to be hard cycled. --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 19:25:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26C7B530; Wed, 16 Jan 2013 19:25:35 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id D2D39777; Wed, 16 Jan 2013 19:25:34 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so3267126iec.13 for ; Wed, 16 Jan 2013 11:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uyRRoZLItTDyoTZ7rqSnZGmlVCXE6PM1R8fYofsz5Q4=; b=MvePhaCNGXDjwXcQBEaFGidRWf1Yr6q9oO1nQlYkpQS9/dMOgcqNagbZu0Yl0GS/Ze lzfcagIFc5eFZB3IXQT1hjq8edQDOPu2H9gI5j49WrDi+1WDqkepUY3y52xzjEEtA5vR RihitiJt+mUv7L9XAMJlr93eLTao4Nl3UiJ7YjRIdK9K192LfA/GDDeOdmF5C6FqIv7t 4LEzm/WGUTb+VXllu4wheVJqeowKj6v3tPC4X3g3sOqEjopuuhkm0CszMn073Gi07GJO iMQz2eQnHT0XobSBhAxNVxHKnX9wDOWnkGDEDwOJivwGzCLv+Yphm60EnjUS3ldN32QP 7uAA== MIME-Version: 1.0 X-Received: by 10.50.183.227 with SMTP id ep3mr5395288igc.107.1358364334092; Wed, 16 Jan 2013 11:25:34 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 11:25:33 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 11:25:33 -0800 (PST) Date: Wed, 16 Jan 2013 21:25:33 +0200 Message-ID: Subject: Failsafe on kernel panic From: Sami Halabi To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:25:35 -0000 Hi everyone, I have a production box, in which I want to install new kernel without any remotd kvn. my problem is its 2 hours away, and if a kernel panic occurs I got a problem. I woner if I can seg failsafe script to load the old kernel in case of psnic. Sami From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 20:13:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C23CC5B4; Wed, 16 Jan 2013 20:13:28 +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 9F2ACA1B; Wed, 16 Jan 2013 20:13:28 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DCF23B939; Wed, 16 Jan 2013 15:13:27 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Failsafe on kernel panic Date: Wed, 16 Jan 2013 15:13:26 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; 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: <201301161513.27016.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 Jan 2013 15:13:28 -0500 (EST) Cc: freebsd-stable@freebsd.org, Sami Halabi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:13:28 -0000 On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > Hi everyone, > I have a production box, in which I want to install new kernel without any > remotd kvn. > my problem is its 2 hours away, and if a kernel panic occurs I got a > problem. > I woner if I can seg failsafe script to load the old kernel in case of > psnic. man nextboot (if you are using UFS) -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 16 21:27:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0BC4E29; Wed, 16 Jan 2013 21:27:54 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8F998EF7; Wed, 16 Jan 2013 21:27:54 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so3516672iec.13 for ; Wed, 16 Jan 2013 13:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oREYJitDKadiVyVzx9Hb+7pXoBahgQjGGBZlFCQxB+U=; b=s2tYux9KOgPPK3n8/RnctVbdV6jAnnT71t20tbJGKFLUc74/nIOBzt2dmSc1yDxfn/ vGk6pD/g5PVu8M8WP+PPrz4pSTU6W5YgI9nhnhUyh2wjycKZaXODC1XHx6Tjj9BpS1jM O0c5g9hZJe3OKSaq1mxfSdEv0aH9BHelEgV7VTahq6e45mGThEzmMwI6UEr9PPgOcUSD 0Ts/OpHeD6Ti709gm75W1EGXYfHSBfJFQMkhNTRknqr4dm72omec3Ylyioq7hedQVlEd Es4sT7kSfmznxmqfL/s2A+R742pXB4AJIE+t2qt+PSYiGwavhB2hG7rq+nsiZ/3FLGTX 40Xw== MIME-Version: 1.0 X-Received: by 10.50.183.227 with SMTP id ep3mr5663218igc.107.1358371673631; Wed, 16 Jan 2013 13:27:53 -0800 (PST) Received: by 10.64.51.98 with HTTP; Wed, 16 Jan 2013 13:27:53 -0800 (PST) In-Reply-To: <201301161513.27016.jhb@freebsd.org> References: <201301161513.27016.jhb@freebsd.org> Date: Wed, 16 Jan 2013 23:27:53 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 21:27:55 -0000 Thank you for your response, very helpful. one question - how do i configure auto-reboot once kernel panic occurs? Sami On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > Hi everyone, > > I have a production box, in which I want to install new kernel without > any > > remotd kvn. > > my problem is its 2 hours away, and if a kernel panic occurs I got a > > problem. > > I woner if I can seg failsafe script to load the old kernel in case of > > psnic. > > man nextboot (if you are using UFS) > > -- > John Baldwin > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 03:18:56 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0116036E; Thu, 17 Jan 2013 03:18:55 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BD2A2674; Thu, 17 Jan 2013 03:18:55 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0H3Imon083026; Wed, 16 Jan 2013 20:18:49 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0H3Ikks005602; Wed, 16 Jan 2013 20:18:46 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Failsafe on kernel panic From: Ian Lepore To: Sami Halabi In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Jan 2013 20:18:45 -0700 Message-ID: <1358392725.32417.179.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 03:18:56 -0000 On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > Thank you for your response, very helpful. > one question - how do i configure auto-reboot once kernel panic occurs? > > Sami > >From src/sys/conf/NOTES, this may be what you're looking for... # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED But I think it only has meaning if you have option KDB in effect, otherwise it should just reboot itself after a 15 second pause. -- Ian > > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > Hi everyone, > > > I have a production box, in which I want to install new kernel without > > any > > > remotd kvn. > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > > > problem. > > > I woner if I can seg failsafe script to load the old kernel in case of > > > psnic. > > > > man nextboot (if you are using UFS) > > > > -- > > John Baldwin > > > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 04:45:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E590ACB3; Thu, 17 Jan 2013 04:45:55 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by mx1.freebsd.org (Postfix) with ESMTP id E3AE82BB; Thu, 17 Jan 2013 04:45:54 +0000 (UTC) Received: by mail-ee0-f42.google.com with SMTP id b47so978525eek.1 for ; Wed, 16 Jan 2013 20:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XyKU1Aect6zJaoi4QRKjATG61QSb7X5Or0Ikdb/E0u8=; b=jYqjrSrdb5gYfUWwD+SPbslFAq2un/2Cc0hG6mi2ZaasCumXjAahyDNQIZpaY3rVQa XjaByfLpvW1ISJrFL26STmSMu06VuJj3A01b8c8y7rKjoIYwk8n9SnsITPQhADtr6Qkn nuYxyR4G6XETP/02RIbOlyBXjIGD7z9ZZGUXo+yYkW8PYi91dRd4c9SNcwLUUbaW2pNL QzcgQQVJBxOy6UAY3YtZhm3aDD260Ako5VTO63nNzHmfsTScdO6Gal64XtgOeGXZLAL8 JyOB9Rpxr5A3yemX40pKndooA/6qYfBezHANKuDbkOFyn0lYd2kUOi8JBiXFh3kwoRdG dHYw== MIME-Version: 1.0 X-Received: by 10.14.216.70 with SMTP id f46mr9752694eep.12.1358397948295; Wed, 16 Jan 2013 20:45:48 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 20:45:48 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 20:45:48 -0800 (PST) In-Reply-To: <1358392725.32417.179.camel@revolution.hippie.lan> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Date: Thu, 17 Jan 2013 06:45:48 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 04:45:56 -0000 Its only a kernel option? There is no flag to pass to the loader? SAMI =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=99=D7=A0=D7=95 2013 05:18= , =D7=9E=D7=90=D7=AA "Ian Lepore" : > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > > Thank you for your response, very helpful. > > one question - how do i configure auto-reboot once kernel panic occurs? > > > > Sami > > > > From src/sys/conf/NOTES, this may be what you're looking for... > > # > # Don't enter the debugger for a panic. Intended for unattended operation > # where you may want to enter the debugger from the console, but still wa= nt > # the machine to recover from a panic. > # > options KDB_UNATTENDED > > But I think it only has meaning if you have option KDB in effect, > otherwise it should just reboot itself after a 15 second pause. > > -- Ian > > > > > > > > > > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > > > > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > > Hi everyone, > > > > I have a production box, in which I want to install new kernel > without > > > any > > > > remotd kvn. > > > > my problem is its 2 hours away, and if a kernel panic occurs I got = a > > > > problem. > > > > I woner if I can seg failsafe script to load the old kernel in case > of > > > > psnic. > > > > > > man nextboot (if you are using UFS) > > > > > > -- > > > John Baldwin > > > > > > > > > > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 06:45:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 72599297; Thu, 17 Jan 2013 06:45:52 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id 913B1820; Thu, 17 Jan 2013 06:45:51 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b15so1015562eek.39 for ; Wed, 16 Jan 2013 22:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=69I0/3QjPXdUaHeCFXq0MLonfVxOBlFbs3v/31VUX1Q=; b=0K3Fu1dphxP9Pzv6+GkqMoRC/HB+ihBkcTzlhrQz4KgFWiAa9ERTjc/eA3Sram6Kkx AT2P9F0RqbYAasc672XCx6WkmtuWvNR2A9yoVf7qdi4O7TjpFjkVekQ2g3Cv3zqg4hJ1 LmR9BzzkvwnVh5dZ3F3bKAw+DOT7sMRpFd+DOmpHt3yKVxxTgMxkraAzZmIQlUIL2Q27 3LmSr+yBhr2AYIeO/PV7ZJGNfTBWzX6QvMcE4DvXIxDZ7sZe2PHjIxNBoUGQzONPx0Py E/YY0E95CI4CzuVRIuhbN7esflkITFlgfk81afActnUByp3veXAuQ36Jl8dBTpPCp7Lb y9ng== MIME-Version: 1.0 X-Received: by 10.14.221.5 with SMTP id q5mr10489754eep.33.1358404739884; Wed, 16 Jan 2013 22:38:59 -0800 (PST) Received: by 10.14.127.67 with HTTP; Wed, 16 Jan 2013 22:38:59 -0800 (PST) In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Date: Thu, 17 Jan 2013 08:38:59 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 06:45:52 -0000 btw: i don't see any options in my kernel config for KBD / Unatteneded , th eonly thing that mention its is: device ukbd Sami On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > Its only a kernel option? There is no flag to pass to the loader? > > SAMI > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=99=D7=A0=D7=95 2013 05:= 18, =D7=9E=D7=90=D7=AA "Ian Lepore" : > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: >> > Thank you for your response, very helpful. >> > one question - how do i configure auto-reboot once kernel panic occurs= ? >> > >> > Sami >> > >> >> From src/sys/conf/NOTES, this may be what you're looking for... >> >> # >> # Don't enter the debugger for a panic. Intended for unattended operatio= n >> # where you may want to enter the debugger from the console, but still >> want >> # the machine to recover from a panic. >> # >> options KDB_UNATTENDED >> >> But I think it only has meaning if you have option KDB in effect, >> otherwise it should just reboot itself after a 15 second pause. >> >> -- Ian >> >> >> >> >> >> >> > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote= : >> > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: >> > > > Hi everyone, >> > > > I have a production box, in which I want to install new kernel >> without >> > > any >> > > > remotd kvn. >> > > > my problem is its 2 hours away, and if a kernel panic occurs I got= a >> > > > problem. >> > > > I woner if I can seg failsafe script to load the old kernel in cas= e >> of >> > > > psnic. >> > > >> > > man nextboot (if you are using UFS) >> > > >> > > -- >> > > John Baldwin >> > > >> > >> > >> > >> >> >> --=20 Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 12:06:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE3351FE for ; Thu, 17 Jan 2013 12:06:37 +0000 (UTC) (envelope-from kaox.gen@gmail.com) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by mx1.freebsd.org (Postfix) with ESMTP id 73F68828 for ; Thu, 17 Jan 2013 12:06:36 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id r4so4186535qaq.19 for ; Thu, 17 Jan 2013 04:06:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=DHguUv4o45XpsTo8n8bCRytMJ6bsqdHJPbK8vV+aWc8=; b=01XSJ4NWLINpoC2jwrA4v44bvfZiRJolU3bpEMWNR70j+BLC7jvcfUItVWb5lPgPv3 Q9d7DlUDjOZx0JzhZpFkCNLdSpmNFTIsF6T5CLHvMkpjWCcu1x8I3PoJpT8skeoc7VPQ ZwUFzCnKtXIXEWcmeMpbgTLxM4sOJw2dcQ88TskkpBr6Kw7gAXsCOdCYxkMZqwP+5L1b kLQwaG9AaWCtxUuEfwi67TN3y8z+sYkVB3SmQqXdJn+pFcD2gdYq4+E4Z2ezYQT3aU2l Qqu7eSwMQcGfsv83wKQbW90FvNUMWeSl6+FLPuz89Lj1OdYCo4dS9Af8rTjAzrVv3wE2 aAjg== MIME-Version: 1.0 X-Received: by 10.229.174.86 with SMTP id s22mr1187085qcz.123.1358424395703; Thu, 17 Jan 2013 04:06:35 -0800 (PST) Received: by 10.229.116.197 with HTTP; Thu, 17 Jan 2013 04:06:35 -0800 (PST) Date: Thu, 17 Jan 2013 14:06:35 +0200 Message-ID: Subject: disadvantages of running 8.3 kernel on freebsd 8.2 system From: =?ISO-8859-1?Q?Ali_Okan_Y=DCKSEL?= To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:06:37 -0000 I know for UPDATING, it s not correct way, but i tried and 8.2 system works with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 /boot/kernel) and it s not good solution but i want to know; - What are specific disadvantages that i can see clearly, running 8.3 kernel on freebsd 8.2? - What are user land tools those not match with 8.3 kernel on freebsd 8.2 system...? best regards, -- http://www.siyahsapka.org From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 12:41:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5567AA68 for ; Thu, 17 Jan 2013 12:41:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 24261A31 for ; Thu, 17 Jan 2013 12:41:32 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r0HCfQA3035096; Thu, 17 Jan 2013 04:41:26 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r0HCfQYd035095; Thu, 17 Jan 2013 04:41:26 -0800 (PST) (envelope-from david) Date: Thu, 17 Jan 2013 04:41:26 -0800 From: David Wolfskill To: Ali Okan =?iso-8859-1?Q?Y=DCKSEL?= Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system Message-ID: <20130117124126.GA1858@albert.catwhisker.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K/4a4vvARjOsFc7F" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:41:33 -0000 --K/4a4vvARjOsFc7F Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 17, 2013 at 02:06:35PM +0200, Ali Okan Y=DCKSEL wrote: > I know for UPDATING, it s not correct way, but i tried and 8.2 system wor= ks > with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 > /boot/kernel) and it s not good solution but i want to know; >=20 >=20 > - What are specific disadvantages that i can see clearly, running 8.3 > kernel on freebsd 8.2? > - What are user land tools those not match with 8.3 kernel on freebsd > 8.2 system...? > .... Because of ... things I'd really rather not even think about, let alone consider discussing ... there are ceratin machines at $work that are thus configured. (Yes, I'm working on repairing this self-inflicted wound.) The only issue of which I'm aware is that if one wishes to use mfiutil(8), it better be one that was built from 8.3 source; an 8.2 mfiutil run on an 8.3 kernel will panic the box consistently. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --K/4a4vvARjOsFc7F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD38XUACgkQmprOCmdXAD1K2gCfVSYfPYS8FryBM53bHhaHyS/F g1UAn0bKkAB+zfQ1Jo+8DWgeflxxKtz8 =3bHV -----END PGP SIGNATURE----- --K/4a4vvARjOsFc7F-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 12:43:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 951F8BA0 for ; Thu, 17 Jan 2013 12:43:21 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id DD080A4C for ; Thu, 17 Jan 2013 12:43:20 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HChAvf011770; Thu, 17 Jan 2013 13:43:10 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HChAZP011767; Thu, 17 Jan 2013 13:43:10 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 13:43:10 +0100 (CET) From: Wojciech Puchar To: =?ISO-8859-15?Q?Ali_Okan_Y=DCKSEL?= Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 13:43:10 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:43:21 -0000 > > - What are specific disadvantages that i can see clearly, running 8.3 > kernel on freebsd 8.2? no idea. just get latest -8 sources, compile world and kernel and install. all newest and in sync. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 12:44:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B561C9D for ; Thu, 17 Jan 2013 12:44:19 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 64DB6A67 for ; Thu, 17 Jan 2013 12:44:18 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HCiGfH011805; Thu, 17 Jan 2013 13:44:16 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HCiG4b011802; Thu, 17 Jan 2013 13:44:16 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 13:44:15 +0100 (CET) From: Wojciech Puchar To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 13:44:16 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:44:19 -0000 > > Note that the driver says "Command Queueing enabled" without > specifying which. If the driver is trying to use SATA's NCQ but > the drive only speaks SCSI's TCQ, that could explain it. Or if > the TCQ isn't working for some other reason. even without TCQ,NCQ and write cache the write speed is really terrible. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 12:45:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8DBEDFA for ; Thu, 17 Jan 2013 12:45:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDFBA82 for ; Thu, 17 Jan 2013 12:45:26 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HCiw00011817; Thu, 17 Jan 2013 13:44:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HCiwmT011814; Thu, 17 Jan 2013 13:44:58 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 13:44:58 +0100 (CET) From: Wojciech Puchar To: Daniel Braniss Subject: Re: off topic but no idea where to ask In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 13:44:58 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 12:45:28 -0000 >> from first local disk at 0x07c00 and booting as with normal hard drive. >> > instead of pxeboot, try giving /boot/boot0 works, except of delay. fixed from sources for 1s delay :) From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 13:35:33 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 708FBD69; Thu, 17 Jan 2013 13:35:33 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF1DE56; Thu, 17 Jan 2013 13:35:32 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0HDZWVB090566; Thu, 17 Jan 2013 06:35:32 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0HDZSLB006318; Thu, 17 Jan 2013 06:35:29 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: Failsafe on kernel panic From: Ian Lepore To: Sami Halabi In-Reply-To: References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> Content-Type: text/plain; charset="iso-2022-jp" Date: Thu, 17 Jan 2013 06:35:28 -0700 Message-ID: <1358429728.32417.193.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 13:35:33 -0000 On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote: > btw: i don't see any options in my kernel config for KBD / Unatteneded , th > eonly thing that mention its > is: device ukbd > > Sami I think if you don't have any kdb options turned on, then a panic should automatically store a crashdump to swap, then reboot the machine. If that's not working, perhaps it locks up trying to store the dump? If the hardware has a watchdog timer, enabling that might be the best way to ensure a reboot on any kind of crash or hang. -- Ian > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > > > Its only a kernel option? There is no flag to pass to the loader? > > > > SAMI <> 17 2013 05:18, "Ian Lepore" : > > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > >> > Thank you for your response, very helpful. > >> > one question - how do i configure auto-reboot once kernel panic occurs? > >> > > >> > Sami > >> > > >> > >> From src/sys/conf/NOTES, this may be what you're looking for... > >> > >> # > >> # Don't enter the debugger for a panic. Intended for unattended operation > >> # where you may want to enter the debugger from the console, but still > >> want > >> # the machine to recover from a panic. > >> # > >> options KDB_UNATTENDED > >> > >> But I think it only has meaning if you have option KDB in effect, > >> otherwise it should just reboot itself after a 15 second pause. > >> > >> -- Ian > >> > >> > >> > >> > >> > >> > >> > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote: > >> > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > >> > > > Hi everyone, > >> > > > I have a production box, in which I want to install new kernel > >> without > >> > > any > >> > > > remotd kvn. > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I got a > >> > > > problem. > >> > > > I woner if I can seg failsafe script to load the old kernel in case > >> of > >> > > > psnic. > >> > > > >> > > man nextboot (if you are using UFS) > >> > > > >> > > -- > >> > > John Baldwin > >> > > > >> > > >> > > >> > > >> > >> > >> > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 14:14:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B1E3FD0; Thu, 17 Jan 2013 14:14:22 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ia0-x232.google.com (ia-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 3058B118; Thu, 17 Jan 2013 14:14:22 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id y26so432977iab.23 for ; Thu, 17 Jan 2013 06:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CQSYH6ODj4eotZZNPKqtLpHJJJPup32kuHnY8QKUflk=; b=bhxQ+Cqkt955zDY3G5BybRP+fqCe41msO2L0HKqTRHVzTNseQgUsGZVSi8jdlq5xfp jR1rhjDZQUE9Ps/tiZ7G2UpVh2nTjpbnY8+HFLJkDrNNlrRbutdwRvU0z1CyxNnhZW2F u+GEx14HJxh0qh8yN0v+FVR3rkJL4LRG71srUNVuf0tl7AGjv1Z2gZX332uWiq+lNqZB Yc/faG0TVuyhkD869GVp01uD8peqD0F7Gf+ON8/FAlDfJqsK/HemFE7OJ0fXLNxrZkyH H3O1jUYLgoxemSYY03fkWHSkG746/BjCZ0ZqIW+Xc2IUxF2tViV4He4SfoxT2htY+jhf 5LZQ== MIME-Version: 1.0 X-Received: by 10.50.222.226 with SMTP id qp2mr3904780igc.103.1358432061763; Thu, 17 Jan 2013 06:14:21 -0800 (PST) Received: by 10.64.51.98 with HTTP; Thu, 17 Jan 2013 06:14:21 -0800 (PST) Received: by 10.64.51.98 with HTTP; Thu, 17 Jan 2013 06:14:21 -0800 (PST) In-Reply-To: <1358429728.32417.193.camel@revolution.hippie.lan> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> <1358429728.32417.193.camel@revolution.hippie.lan> Date: Thu, 17 Jan 2013 16:14:21 +0200 Message-ID: Subject: Re: Failsafe on kernel panic From: Sami Halabi To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:14:22 -0000 Hi, Upon panic no auto restart occurs. How do I know/activate these watchdogs? Sami =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 17 =D7=91=D7=99=D7=A0=D7=95 2013 15:35= , =D7=9E=D7=90=D7=AA "Ian Lepore" : > On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote: > > btw: i don't see any options in my kernel config for KBD / Unatteneded = , > th > > eonly thing that mention its > > is: device ukbd > > > > Sami > > I think if you don't have any kdb options turned on, then a panic should > automatically store a crashdump to swap, then reboot the machine. If > that's not working, perhaps it locks up trying to store the dump? > > If the hardware has a watchdog timer, enabling that might be the best > way to ensure a reboot on any kind of crash or hang. > > -- Ian > > > > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote= : > > > > > Its only a kernel option? There is no flag to pass to the loader? > > > > > > SAMI > <> 17 2013 05:18, "Ian Lepore" : > > > > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > > >> > Thank you for your response, very helpful. > > >> > one question - how do i configure auto-reboot once kernel panic > occurs? > > >> > > > >> > Sami > > >> > > > >> > > >> From src/sys/conf/NOTES, this may be what you're looking for... > > >> > > >> # > > >> # Don't enter the debugger for a panic. Intended for unattended > operation > > >> # where you may want to enter the debugger from the console, but sti= ll > > >> want > > >> # the machine to recover from a panic. > > >> # > > >> options KDB_UNATTENDED > > >> > > >> But I think it only has meaning if you have option KDB in effect, > > >> otherwise it should just reboot itself after a 15 second pause. > > >> > > >> -- Ian > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin > wrote: > > >> > > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > >> > > > Hi everyone, > > >> > > > I have a production box, in which I want to install new kernel > > >> without > > >> > > any > > >> > > > remotd kvn. > > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I > got a > > >> > > > problem. > > >> > > > I woner if I can seg failsafe script to load the old kernel in > case > > >> of > > >> > > > psnic. > > >> > > > > >> > > man nextboot (if you are using UFS) > > >> > > > > >> > > -- > > >> > > John Baldwin > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > > > > > -- > > Sami Halabi > > Information Systems Engineer > > NMS Projects Expert > > FreeBSD SysAdmin Expert > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 14:55:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 408EFC66 for ; Thu, 17 Jan 2013 14:55:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id E006A397 for ; Thu, 17 Jan 2013 14:55:40 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1TvqsV-000AmB-BS; Thu, 17 Jan 2013 16:55:39 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Wojciech Puchar Subject: Re: off topic but no idea where to ask In-reply-to: References: Comments: In-reply-to Wojciech Puchar message dated "Thu, 17 Jan 2013 13:44:58 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jan 2013 16:55:39 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 14:55:41 -0000 > >> from first local disk at 0x07c00 and booting as with normal hard drive. > >> > > instead of pxeboot, try giving /boot/boot0 > > works, except of delay. > > fixed from sources for 1s delay :) may the source be with you :-) btw, the above works for MBR, if you use GPT then you should use pmbr. danny From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 15:40:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B5877A for ; Thu, 17 Jan 2013 15:40:00 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by mx1.freebsd.org (Postfix) with ESMTP id D3B8B901 for ; Thu, 17 Jan 2013 15:39:59 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id c11so4944171ieb.33 for ; Thu, 17 Jan 2013 07:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W4keJADtBk6v5ycmYJrWjLoLgKcVU1J93sfujSY1Dvo=; b=CTGTSK74W9F38MhNrYIoAOQEaWIMteSFFM5iPIcyP9cG4ugq7a04hAApcR3bB0Jn5r ulAz2kREp5VlUnIRcuhny1r+cqMujkZb5t4QlyYPufIhnGCOKSU7prCdNRyA5Pj9GPxP aKFh74Rxz98YEDlVujgs0FHNdvt02JM3AotjINyIQHbYP+GBHVGHmLg4f1JNh28mlmYj HbIzJbGiZazZk5lPAUxGXUokHy42VUKY2bbj5u+/IxqsX8X174Dqk+wCSv/AMA5p/nWy DwQG9oZ4onTIb+7W0SSLAbPjoAl9TK5nfkE49SpDAH/RfQKdDI5HXaZUmLsy9LYKrDlo yGiA== MIME-Version: 1.0 X-Received: by 10.50.161.169 with SMTP id xt9mr8004797igb.62.1358437199226; Thu, 17 Jan 2013 07:39:59 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 17 Jan 2013 07:39:58 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 17 Jan 2013 07:39:58 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 15:39:58 +0000 Message-ID: Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, =?ISO-8859-1?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 15:40:00 -0000 On 17 Jan 2013 12:43, "Wojciech Puchar" wrote: >> >> >> - What are specific disadvantages that i can see clearly, running 8.3 >> kernel on freebsd 8.2? > > > no idea. just get latest -8 sources, compile world and kernel and install. > > all newest and in sync. I agree; very weird problems sometimes happen with out of sync kernel/world; normally with new world old kernel, but the opposite is possible. Are you simply apprehensive over the time of buildworld? Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 15:57:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47AE95AD for ; Thu, 17 Jan 2013 15:57:06 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 161EB9ED for ; Thu, 17 Jan 2013 15:57:05 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r0HFv4ci014440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jan 2013 09:57:05 -0600 Received: from [10.0.0.102] (10.14.152.24) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 09:57:04 -0600 Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: Date: Thu, 17 Jan 2013 07:57:01 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> References: To: =?iso-8859-1?Q?Ali_Okan_Y=DCKSEL?= X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.24] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17,2013-01-17,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 15:57:06 -0000 On Jan 17, 2013, at 4:06 AM, Ali Okan Y=DCKSEL wrote: > I know for UPDATING, it s not correct way, but i tried and 8.2 system wor= ks > with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 > /boot/kernel) and it s not good solution but i want to know; >=20 >=20 > - What are specific disadvantages that i can see clearly, running 8.3 > kernel on freebsd 8.2? A couple user land tools might barf on you (listed below). Other than that, it's generally considered very safe. The quintessential test-case is running an 8.2 jail under an 8.3 host. We do this all the time with various releases (again, most-problematic util= ities listed below). > - What are user land tools those not match with 8.3 kernel on freebsd > 8.2 system=85? >=20 top and ps might complain about procsize mismatch. netstat has been known to have problems if the gap is too wide. That's about all that I can think off the top of my head. The quick solution is to just grab the 8.3-R copies of top, ps, and netstat= *IFF* they cause problems (e.g., ps immediately dies with "procsize mismat= ch" error). --=20 Devin P.S. Been doing this kind of mismatching of kernel/userland for YEARS (all = the way back to 4.4/4.8) and top and ps always prove to be problematic. _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 16:34:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2ED559B1; Thu, 17 Jan 2013 16:34:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id D368BD8C; Thu, 17 Jan 2013 16:34:26 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id qd14so5061884ieb.34 for ; Thu, 17 Jan 2013 08:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=akRhOIVkjx+KQZgLSmJa9SoH7ttHC3E485UFLayv41M=; b=b1+dDdQMRnUfphmQMTCEoX4Flk94OXXtF32VTzCA4qBKOhhQFx+dZ2uNT/EQ8eLU67 Dz6CdxCwhDRVldeU5SppeBiQxYg2/jisCbcl32xbpZIeUyfZFnWNGYyc3GWFWZUV8viU JXmpYj9UGha0HDkV0YpuAtLBqAt0ORhDrqisT+/g5NIqo1Wf/Xg6gpmLlKrdnner2e4T FJBpy55CtawNmYXpypTQwZ1Uh4fOwQ5+TmHVaEeCjdRsBkSrHiUmbLp3Tc2P/eWDfr1S y13IeCeK3mtIwtiUOzFD3ERyIlGtAJhDHD4SmR1byM4vnl5Xg7Q24QKd+2f/qQsTtbPd sCrw== X-Received: by 10.50.222.228 with SMTP id qp4mr4323865igc.87.1358440460248; Thu, 17 Jan 2013 08:34:20 -0800 (PST) Received: from raichu ([66.11.160.25]) by mx.google.com with ESMTPS id as6sm7178132igc.8.2013.01.17.08.34.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 08:34:19 -0800 (PST) Date: Thu, 17 Jan 2013 11:34:07 -0500 From: Mark Johnston To: Sami Halabi Subject: Re: Failsafe on kernel panic Message-ID: <20130117163407.GA1940@raichu> References: <201301161513.27016.jhb@freebsd.org> <1358392725.32417.179.camel@revolution.hippie.lan> <1358429728.32417.193.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 16:34:27 -0000 On Thu, Jan 17, 2013 at 04:14:21PM +0200, Sami Halabi wrote: > Hi, > Upon panic no auto restart occurs. > How do I know/activate these watchdogs? > Sami You can try starting watchdogd with 'service watchdogd onestart', and have it automatically start during boot by adding 'watchdogd_enable="YES"' to rc.conf. You can test by starting watchdogd and sending SIGKILL to it - if everything's working properly, the system should reboot after the timeout period (16s by default). If you don't have a hardware watchdog (or have one that isn't supported by any drivers), watchdogd will fail to start. -Mark > בת×ריך 17 בינו 2013 15:35, מ×ת "Ian Lepore" : > > > On Thu, 2013-01-17 at 08:38 +0200, Sami Halabi wrote: > > > btw: i don't see any options in my kernel config for KBD / Unatteneded , > > th > > > eonly thing that mention its > > > is: device ukbd > > > > > > Sami > > > > I think if you don't have any kdb options turned on, then a panic should > > automatically store a crashdump to swap, then reboot the machine. If > > that's not working, perhaps it locks up trying to store the dump? > > > > If the hardware has a watchdog timer, enabling that might be the best > > way to ensure a reboot on any kind of crash or hang. > > > > -- Ian > > > > > > > On Thu, Jan 17, 2013 at 6:45 AM, Sami Halabi wrote: > > > > > > > Its only a kernel option? There is no flag to pass to the loader? > > > > > > > > SAMI > > <> 17 2013 05:18, "Ian Lepore" : > > > > > > > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote: > > > >> > Thank you for your response, very helpful. > > > >> > one question - how do i configure auto-reboot once kernel panic > > occurs? > > > >> > > > > >> > Sami > > > >> > > > > >> > > > >> From src/sys/conf/NOTES, this may be what you're looking for... > > > >> > > > >> # > > > >> # Don't enter the debugger for a panic. Intended for unattended > > operation > > > >> # where you may want to enter the debugger from the console, but still > > > >> want > > > >> # the machine to recover from a panic. > > > >> # > > > >> options KDB_UNATTENDED > > > >> > > > >> But I think it only has meaning if you have option KDB in effect, > > > >> otherwise it should just reboot itself after a 15 second pause. > > > >> > > > >> -- Ian > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > >> > On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin > > wrote: > > > >> > > > > >> > > On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote: > > > >> > > > Hi everyone, > > > >> > > > I have a production box, in which I want to install new kernel > > > >> without > > > >> > > any > > > >> > > > remotd kvn. > > > >> > > > my problem is its 2 hours away, and if a kernel panic occurs I > > got a > > > >> > > > problem. > > > >> > > > I woner if I can seg failsafe script to load the old kernel in > > case > > > >> of > > > >> > > > psnic. > > > >> > > > > > >> > > man nextboot (if you are using UFS) > > > >> > > > > > >> > > -- > > > >> > > John Baldwin > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > > > > > > > -- > > > Sami Halabi > > > Information Systems Engineer > > > NMS Projects Expert > > > FreeBSD SysAdmin Expert > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 17:13:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33D7BFAE for ; Thu, 17 Jan 2013 17:13:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9F3E211F for ; Thu, 17 Jan 2013 17:13:26 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HHDNrx000110; Thu, 17 Jan 2013 18:13:23 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HHDNWj000107; Thu, 17 Jan 2013 18:13:23 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 18:13:23 +0100 (CET) From: Wojciech Puchar To: Chris Rees Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 18:13:23 +0100 (CET) Cc: freebsd-hackers@freebsd.org, =?ISO-8859-15?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:13:27 -0000 > > Are you simply apprehensive over the time of buildworld? no idea what you mean - my english isn't perfect. I normally have latest binaries and generic kernel built for FreeBSD 8 which i use on servers (don't upgrade now as it works and there is no need to). I have .tar.gz file with binaries, and compile custom kernel on given machine but with same sys sources. so all always in sync. I once had strange out of sync problems - but with virtualbox kernel module. recompiling this module solved all of them. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 17:19:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F64A3D9 for ; Thu, 17 Jan 2013 17:19:15 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mx1.freebsd.org (Postfix) with ESMTP id 40F65257 for ; Thu, 17 Jan 2013 17:19:15 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id qd14so5028518ieb.6 for ; Thu, 17 Jan 2013 09:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=wj2VQiJx6VQ5fXjU8XfGPj9Fi7kcVoU3CifqGFriIYo=; b=OJv72JGNtoznZZcF5RrUOu9N8J9SlNgE4om4RE9Z3T7Gw3yWDOs5v88b98ATC6+bIg F0Oprh9SkO1Rd+NguWI+9+Aya2pAFoE+GxQZznS02knzslTv1yxPCZRQBev1wrsw7YWg fm7h2Q1ik6SZPdQ6KLhu/5xv1HrQni0Vidwgu8XIBReqtsP2Z+Xu3AiWL7aDuCE4IyPI lknAG9MlJCPdIagaRHYxOhG6qDyMUWri/hhqQh3MB7xcMLcZhF7eXjbYI3uynmNESmmS esgYOlJm0ct1wNwW55VGmgeSJ51McT2mbcqZifDnxlw5/pRlFzyUlN5U7Z62K1ROL9L3 3BLg== MIME-Version: 1.0 X-Received: by 10.50.153.194 with SMTP id vi2mr4552120igb.15.1358443154678; Thu, 17 Jan 2013 09:19:14 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 17 Jan 2013 09:19:14 -0800 (PST) Received: by 10.64.16.73 with HTTP; Thu, 17 Jan 2013 09:19:14 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 17:19:14 +0000 Message-ID: Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system From: Chris Rees To: Wojciech Puchar Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, =?ISO-8859-1?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:19:15 -0000 On 17 Jan 2013 17:13, "Wojciech Puchar" wrote: >> >> >> Are you simply apprehensive over the time of buildworld? > > > no idea what you mean - my english isn't perfect. Sorry, was asking the OP. > I normally have latest binaries and generic kernel built for FreeBSD 8 which i use on servers (don't upgrade now as it works and there is no need to). > > I have .tar.gz file with binaries, and compile custom kernel on given machine but with same sys sources. so all always in sync. > > I once had strange out of sync problems - but with virtualbox kernel module. recompiling this module solved all of them. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 18:19:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EDFE57FE for ; Thu, 17 Jan 2013 18:19:52 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6366381B for ; Thu, 17 Jan 2013 18:19:51 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HIJf4s000273; Thu, 17 Jan 2013 19:19:41 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HIJeCl000270; Thu, 17 Jan 2013 19:19:40 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 19:19:40 +0100 (CET) From: Wojciech Puchar To: Daniel Braniss Subject: Re: off topic but no idea where to ask In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 19:19:41 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:19:53 -0000 > may the source be with you :-) > > btw, the above works for MBR, if you use GPT then you should use > pmbr. they are windoze "work"stations only. and with FreeBSD i too don't have to use GPT strangeness fortunately. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 18:40:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08544572; Thu, 17 Jan 2013 18:40:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 241ED945; Thu, 17 Jan 2013 18:40:55 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7E4B1B95B; Thu, 17 Jan 2013 13:40:54 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org, Devin Teske Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system Date: Thu, 17 Jan 2013 11:03:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> In-Reply-To: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Message-Id: <201301171103.41013.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 Jan 2013 13:40:54 -0500 (EST) Cc: Ali Okan =?windows-1252?q?Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:40:56 -0000 On Thursday, January 17, 2013 10:57:01 am Devin Teske wrote: > On Jan 17, 2013, at 4:06 AM, Ali Okan Y=DCKSEL wrote: >=20 > > I know for UPDATING, it s not correct way, but i tried and 8.2 system=20 works > > with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 > > /boot/kernel) and it s not good solution but i want to know; > >=20 > >=20 > > - What are specific disadvantages that i can see clearly, running 8.3 > > kernel on freebsd 8.2? >=20 > A couple user land tools might barf on you (listed below). >=20 > Other than that, it's generally considered very safe. >=20 > The quintessential test-case is running an 8.2 jail under an 8.3 host. >=20 > We do this all the time with various releases (again, most-problematic=20 utilities listed below). >=20 >=20 >=20 > > - What are user land tools those not match with 8.3 kernel on freebsd > > 8.2 system=85? > >=20 >=20 > top and ps might complain about procsize mismatch. >=20 > netstat has been known to have problems if the gap is too wide. These generally do not have problems in recent release branches. top and p= s=20 haven't complained about procsize since the 4.x days as 5.0 introduced a ne= w=20 kinfo_proc structure that the kernel exports and it hasn't changed in size= =20 since 5.0. The mfiutil issue dhw@ mentioned is real and is due to an mfi(4) driver=20 change. I merged a fix for the panics to 8-stable, but it just makes old mfiutil binaries not work at all. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 18:41:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28CB46DA; Thu, 17 Jan 2013 18:41:00 +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 0617B949; Thu, 17 Jan 2013 18:41:00 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52165B96B; Thu, 17 Jan 2013 13:40:59 -0500 (EST) From: John Baldwin To: Sami Halabi Subject: Re: Failsafe on kernel panic Date: Thu, 17 Jan 2013 13:39:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301161513.27016.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201301171339.15841.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 17 Jan 2013 13:40:59 -0500 (EST) Cc: freebsd-hackers@freebsd.org, "freebsd-stable@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:41:00 -0000 On Wednesday, January 16, 2013 4:27:53 pm Sami Halabi wrote: > Thank you for your response, very helpful. > one question - how do i configure auto-reboot once kernel panic occurs? Unless you've added DDB and KDB to your kernel it will reboot by default on a panic. Stable kernel configs also include the unattended option so that even with the debugger present they reboot by default on a panic. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 18:43:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D375D0E for ; Thu, 17 Jan 2013 18:43:53 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 045599B5 for ; Thu, 17 Jan 2013 18:43:52 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HIhphY000441 for ; Thu, 17 Jan 2013 19:43:51 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HIhpRR000438 for ; Thu, 17 Jan 2013 19:43:51 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 17 Jan 2013 19:43:51 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: stupid UFS behaviour on random writes Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Thu, 17 Jan 2013 19:43:51 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:43:53 -0000 create 10GB file (on 2GB RAM machine, with some swap used to make sure little cache would be available for filesystem. dd if=/dev/zero of=file bs=1m count=10k block size is 32KB, fragment size 4k now test random read access to it (10 threads) randomio test 10 0 0 4096 normal result on such not so fast disk in my laptop. 118.5 | 118.5 5.8 82.3 383.2 85.6 | 0.0 inf nan 0.0 nan 138.4 | 138.4 3.9 72.2 499.7 76.1 | 0.0 inf nan 0.0 nan 142.9 | 142.9 5.4 69.9 297.7 60.9 | 0.0 inf nan 0.0 nan 133.9 | 133.9 4.3 74.1 480.1 75.1 | 0.0 inf nan 0.0 nan 138.4 | 138.4 5.1 72.1 380.0 71.3 | 0.0 inf nan 0.0 nan 145.9 | 145.9 4.7 68.8 419.3 69.6 | 0.0 inf nan 0.0 nan systat shows 4kB I/O size. all is fine. BUT random 4kB writes randomio test 10 1 0 4096 total | read: latency (ms) | write: latency (ms) iops | iops min avg max sdev | iops min avg max sdev --------+-----------------------------------+---------------------------------- 38.5 | 0.0 inf nan 0.0 nan | 38.5 9.0 166.5 1156.8 261.5 44.0 | 0.0 inf nan 0.0 nan | 44.0 0.1 251.2 2616.7 492.7 44.0 | 0.0 inf nan 0.0 nan | 44.0 7.6 178.3 1895.4 330.0 45.0 | 0.0 inf nan 0.0 nan | 45.0 0.0 239.8 3457.4 522.3 45.5 | 0.0 inf nan 0.0 nan | 45.5 0.1 249.8 5126.7 621.0 results are horrific. systat shows 32kB I/O, gstat shows half are reads half are writes. Why UFS need to read full block, change one 4kB part and then write back, instead of just writing 4kB part? From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 18:51:52 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F0C4720B; Thu, 17 Jan 2013 18:51:52 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id BEB5DA29; Thu, 17 Jan 2013 18:51:52 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id r0HIppYo005024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jan 2013 12:51:51 -0600 Received: from [10.0.0.102] (10.14.152.24) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 12:51:50 -0600 Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <201301171103.41013.jhb@freebsd.org> Date: Thu, 17 Jan 2013 10:51:44 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.24] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17,2013-01-17,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org, Devin Teske , =?iso-8859-1?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:51:53 -0000 On Jan 17, 2013, at 8:03 AM, John Baldwin wrote: > On Thursday, January 17, 2013 10:57:01 am Devin Teske wrote: >> On Jan 17, 2013, at 4:06 AM, Ali Okan Y=DCKSEL wrote: >>=20 >>> I know for UPDATING, it s not correct way, but i tried and 8.2 system=20 > works >>> with 8.3 kernel (copied 8.3 /boot/kernel directory to freebsd 8.2 >>> /boot/kernel) and it s not good solution but i want to know; >>>=20 >>>=20 >>> - What are specific disadvantages that i can see clearly, running 8.3 >>> kernel on freebsd 8.2? >>=20 >> A couple user land tools might barf on you (listed below). >>=20 >> Other than that, it's generally considered very safe. >>=20 >> The quintessential test-case is running an 8.2 jail under an 8.3 host. >>=20 >> We do this all the time with various releases (again, most-problematic=20 > utilities listed below). >>=20 >>=20 >>=20 >>> - What are user land tools those not match with 8.3 kernel on freebsd >>> 8.2 system=85? >>>=20 >>=20 >> top and ps might complain about procsize mismatch. >>=20 >> netstat has been known to have problems if the gap is too wide. >=20 > These generally do not have problems in recent release branches. top and= ps=20 > haven't complained about procsize since the 4.x days as 5.0 introduced a = new=20 > kinfo_proc structure that the kernel exports and it hasn't changed in siz= e=20 > since 5.0. >=20 > The mfiutil issue dhw@ mentioned is real and is due to an mfi(4) driver=20 > change. I merged a fix for the panics to 8-stable, but it just makes > old mfiutil binaries not work at all. >=20 You're the perfect person to help us figure out why when we: 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the ti= me of back-port) 2. Succeed in getting 8.3 to boot on Thunderbolt card 3. mfiutil produces Inappropriate ioctl for device Even after=85 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build environm= ent -- back ported headers applied for new macros even) Any hints on where to go next to restore mfiutil access? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 19:13:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E35E9E4B; Thu, 17 Jan 2013 19:13:39 +0000 (UTC) (envelope-from prvs=172911332d=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0E8D3B23; Thu, 17 Jan 2013 19:13:38 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001740565.msg; Thu, 17 Jan 2013 19:13:36 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 17 Jan 2013 19:13:36 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=172911332d=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> From: "Steven Hartland" To: "Devin Teske" , "John Baldwin" References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system Date: Thu, 17 Jan 2013 19:14:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-hackers@freebsd.org, Devin Teske , =?Windows-1252?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:13:40 -0000 ----- Original Message ----- From: "Devin Teske" > You're the perfect person to help us figure out why when we: > > 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the time of back-port) > > 2. Succeed in getting 8.3 to boot on Thunderbolt card > > 3. mfiutil produces Inappropriate ioctl for device > > Even after… > > 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build environment -- back ported headers applied for new macros > even) > > Any hints on where to go next to restore mfiutil access? You also need to backport mfiutil too. I have a patch set for 8.3 which include latest mfi driver, mfiutil and a large set of mfi driver fixes, even head has some rather serious issues although mainly around error handling on tbolt cards. We're running this in production so believe its a good stable set. If you would like the patch set just let me know. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 19:27:42 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4F447533; Thu, 17 Jan 2013 19:27:42 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 14143C3A; Thu, 17 Jan 2013 19:27:41 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id r0HJRfkG014924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jan 2013 13:27:41 -0600 Received: from [10.0.0.102] (10.14.152.24) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 13:27:40 -0600 Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="windows-1252" From: Devin Teske In-Reply-To: <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> Date: Thu, 17 Jan 2013 11:27:39 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> To: Steven Hartland X-Mailer: Apple Mail (2.1283) X-Originating-IP: [10.14.152.24] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_06:2013-01-17,2013-01-17,1970-01-01 signatures=0 Cc: freebsd-hackers@freebsd.org, Devin Teske , =?iso-8859-1?Q?Ali_Okan_Y=DCKSEL?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:27:42 -0000 On Jan 17, 2013, at 11:14 AM, Steven Hartland wrote: > ----- Original Message ----- From: "Devin Teske" >> You're the perfect person to help us figure out why when we: >>=20 >> 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the= time of back-port) >>=20 >> 2. Succeed in getting 8.3 to boot on Thunderbolt card >>=20 >> 3. mfiutil produces Inappropriate ioctl for device >>=20 >> Even after=85 >>=20 >> 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build envir= onment -- back ported headers applied for new macros even) >>=20 >> Any hints on where to go next to restore mfiutil access? >=20 > You also need to backport mfiutil too. >=20 > I have a patch set for 8.3 which include latest mfi driver, mfiutil and > a large set of mfi driver fixes, even head has some rather serious issues > although mainly around error handling on tbolt cards. >=20 > We're running this in production so believe its a good stable set. >=20 > If you would like the patch set just let me know. >=20 I can't resist when you combine words like "production" and "8.3" (smiles) I'm definitely interested in the patch. Can you send it our way, please? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 22:55:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3016A66C for ; Thu, 17 Jan 2013 22:55:22 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id BA633A7D for ; Thu, 17 Jan 2013 22:55:21 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so97817wgb.0 for ; Thu, 17 Jan 2013 14:55:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=w53PWun2eVdwdkgLD8+h20OOUCAFFL8g+zymxoUpk/k=; b=Im5SojOmRNfuKXGqDPGi+VjlsIibv9cmWhXFytXF+Sd9WNlxLGX4TQA18mzbx/Siql 8aTJc3stUdaC5n1bTARzQczm1HimadL4x2pTk3cKyzIpaq02j0ojmvVUTFhjcrAk1cku fRx7uojt8MziVs64qF+mdN/8bgw80R7NjRpPA9AV0EHr9Rkv4CuDZUUzLqZLKqLkG1Fy cc9ypScCjdwbMS1FzPz0aMoCyMsS4StvLX0eS67hHcIRDCxobO8/JeVU49aN8ySZM0Q3 +/E5FjRZDGpXl2o2RQJMD1q10x7wXKhIsuVOOdRZ+WcCaNlA5cFDEjycCCskbgquK4cH a5Dg== X-Received: by 10.194.240.129 with SMTP id wa1mr11135932wjc.21.1358463320845; Thu, 17 Jan 2013 14:55:20 -0800 (PST) Received: from [10.208.188.183] ([92.90.16.102]) by mx.google.com with ESMTPS id w5sm743872wif.11.2013.01.17.14.55.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 14:55:19 -0800 (PST) References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <39477686-B5CC-439B-82A8-EEECBE358A9F@my.gd> X-Mailer: iPhone Mail (9A405) From: Damien Fleuriot Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system Date: Thu, 17 Jan 2013 23:54:18 +0100 To: Devin Teske X-Gm-Message-State: ALoCoQnx6ZRpQWMFJoqfIzvVEOs04ZkBaysnAxqhExpSzLSX1Ku7UAZssqAKMjRlBDq5+CbguXOm Cc: =?utf-8?Q?Ali_Okan_Y=C3=9CKSEL?= , "freebsd-hackers@freebsd.org" , Devin Teske , Steven Hartland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 22:55:22 -0000 On 17 Jan 2013, at 20:27, Devin Teske wrote: >=20 > On Jan 17, 2013, at 11:14 AM, Steven Hartland wrote: >=20 >> ----- Original Message ----- From: "Devin Teske" >>> You're the perfect person to help us figure out why when we: >>>=20 >>> 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at the= time of back-port) >>>=20 >>> 2. Succeed in getting 8.3 to boot on Thunderbolt card >>>=20 >>> 3. mfiutil produces Inappropriate ioctl for device >>>=20 >>> Even after=E2=80=A6 >>>=20 >>> 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build envir= onment -- back ported headers applied for new macros even) >>>=20 >>> Any hints on where to go next to restore mfiutil access? >>=20 >> You also need to backport mfiutil too. >>=20 >> I have a patch set for 8.3 which include latest mfi driver, mfiutil and >> a large set of mfi driver fixes, even head has some rather serious issues= >> although mainly around error handling on tbolt cards. >>=20 >> We're running this in production so believe its a good stable set. >>=20 >> If you would like the patch set just let me know. >>=20 >=20 > I can't resist when you combine words like "production" and "8.3" (smiles)= >=20 ? Are you saying 8.3 isn't production worthy ? Works like a charm here for us. 50+ boxes running 8.x, most of which are 8-s= table. No offence meant, but I'd take 8.3 over 9.x any day. Any night too, for that matter. YMMV but PF + pfsync + carp (and some boxes with nginx or relayd on top) is p= retty good for our workload on 8.3.= From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 23:01:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 08CF3A48 for ; Thu, 17 Jan 2013 23:01:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C51E8AD4 for ; Thu, 17 Jan 2013 23:01:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAH2C+FCDaFvO/2dsb2JhbABFhkW4A3OCHgEBAQQBAQEgKyALGw4KAgINGQIpAQkmBggHBAEcBId4DKlSkgKBI4tugxWBEwOIYYp9gi6BHI8tgxOBUTU X-IronPort-AV: E=Sophos;i="4.84,488,1355115600"; d="scan'208";a="12516162" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 17 Jan 2013 18:01:27 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 410A4B3F19; Thu, 17 Jan 2013 18:01:27 -0500 (EST) Date: Thu, 17 Jan 2013 18:01:27 -0500 (EST) From: Rick Macklem To: Wojciech Puchar Message-ID: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: stupid UFS behaviour on random writes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:01:37 -0000 Wojciech Puchar wrote: > create 10GB file (on 2GB RAM machine, with some swap used to make sure > little cache would be available for filesystem. > > dd if=/dev/zero of=file bs=1m count=10k > > block size is 32KB, fragment size 4k > > > now test random read access to it (10 threads) > > randomio test 10 0 0 4096 > > normal result on such not so fast disk in my laptop. > > 118.5 | 118.5 5.8 82.3 383.2 85.6 | 0.0 inf nan 0.0 nan > 138.4 | 138.4 3.9 72.2 499.7 76.1 | 0.0 inf nan 0.0 nan > 142.9 | 142.9 5.4 69.9 297.7 60.9 | 0.0 inf nan 0.0 nan > 133.9 | 133.9 4.3 74.1 480.1 75.1 | 0.0 inf nan 0.0 nan > 138.4 | 138.4 5.1 72.1 380.0 71.3 | 0.0 inf nan 0.0 nan > 145.9 | 145.9 4.7 68.8 419.3 69.6 | 0.0 inf nan 0.0 nan > > > systat shows 4kB I/O size. all is fine. > > BUT random 4kB writes > > randomio test 10 1 0 4096 > > total | read: latency (ms) | write: latency (ms) > iops | iops min avg max sdev | iops min avg max > sdev > --------+-----------------------------------+---------------------------------- > 38.5 | 0.0 inf nan 0.0 nan | 38.5 9.0 166.5 1156.8 261.5 > 44.0 | 0.0 inf nan 0.0 nan | 44.0 0.1 251.2 2616.7 492.7 > 44.0 | 0.0 inf nan 0.0 nan | 44.0 7.6 178.3 1895.4 330.0 > 45.0 | 0.0 inf nan 0.0 nan | 45.0 0.0 239.8 3457.4 522.3 > 45.5 | 0.0 inf nan 0.0 nan | 45.5 0.1 249.8 5126.7 621.0 > > > > results are horrific. systat shows 32kB I/O, gstat shows half are > reads > half are writes. > > Why UFS need to read full block, change one 4kB part and then write > back, instead of just writing 4kB part? Because that's the way the buffer cache works. It writes an entire buffer cache block (unless at the end of file), so it must read the rest of the block into the buffer, so it doesn't write garbage (the rest of the block) out. I'd argue that using an I/O size smaller than the file system block size is simply sub-optimal and that most apps. don't do random I/O of blocks. OR If you had an app. that does random I/O of 4K blocks (at 4K byte offsets), then using a 4K/1K file system would be better. NFS is the exception, in that it keeps track of a dirty byte range within a buffer cache block and writes that byte range. (NFS writes are byte granular, unlike a disk.) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 23:04:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2531C23 for ; Thu, 17 Jan 2013 23:04:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 85004AF3 for ; Thu, 17 Jan 2013 23:04:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0HN4CwQ006216; Fri, 18 Jan 2013 00:04:12 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0HN4BNd006213; Fri, 18 Jan 2013 00:04:12 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 00:04:11 +0100 (CET) From: Wojciech Puchar To: Rick Macklem Subject: Re: stupid UFS behaviour on random writes In-Reply-To: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 00:04:12 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:04:16 -0000 > I'd argue that using an I/O size smaller than the file system block size is > simply sub-optimal and that most apps. don't do random I/O of blocks. > OR > If you had an app. that does random I/O of 4K blocks (at 4K byte offsets), > then using a 4K/1K file system would be better. i can just use raw partition but it isn't about the question. For me it is just clearly suboptimal behavior, but if it "cannot be fixed" then fine. The case is when you store VM images on filesystem and virtual machine issues writes. Quite common case. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 22:12:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97269B47 for ; Thu, 17 Jan 2013 22:12:26 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 6A07488F for ; Thu, 17 Jan 2013 22:12:26 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id u8so846762iag.3 for ; Thu, 17 Jan 2013 14:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type; bh=LS+j0ANYOad5rgxk0qca4G9OqYZn+1Kqdrb7VPfKhVc=; b=DPoSJoHdEemicAwgoxgmoQN4QQyuEBZlDQeXIQkpO7ViPzQgthUa8nFLtRUkqCO47d M66369x3lgBfC/JGpmNB6ZD4GnJxFc+NWlCxj07kvQO+UTrLhnpK6yUcqBZ/m3Wblp1H YFge610JM5PcFB4oRZdaL0EMgwWSYyBdEjeW14WCxkGc19asmn2W0tu7aGYhi8vrJ6It 2Ob5Y059TUxq6H3jO3RQnvGI/fjQwcIAGo64O4TR4eKrpShQiSoLRESaUcafrRuq5IZe AgvRoDXaTyCac5owA2rsS6T0QYqYbfPX6cgZUZoGxjUjx3V/Lr5LyzTF24HKFrBRwbtm FP4A== X-Received: by 10.50.208.41 with SMTP id mb9mr324254igc.42.1358460745721; Thu, 17 Jan 2013 14:12:25 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id px5sm2399099igc.0.2013.01.17.14.12.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Jan 2013 14:12:24 -0800 (PST) Message-ID: <50F87741.4030201@gmail.com> Date: Thu, 17 Jan 2013 17:12:17 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: In-Reply-To: X-Mailman-Approved-At: Thu, 17 Jan 2013 23:05:40 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 22:12:26 -0000 On 16/01/2013 2:48 AM, Dieter BSD wrote: > Karim writes: >> It is quite obvious that something is awfully slow on SAS drives, >> whatever it is and regardless of OS comparison. We swapped the SAS >> drives for SATA and we're seeing much higher speeds. Basically on par >> with what we were expecting (roughly 300 to 400 times faster then what >> we see with SAS...). > Major clue there! According to wikipedia: "Most SAS drives provide > tagged command queuing, while most newer SATA drives provide native > command queuing" [1] > > Note that the driver says "Command Queueing enabled" without > specifying which. If the driver is trying to use SATA's NCQ but > the drive only speaks SCSI's TCQ, that could explain it. Or if > the TCQ isn't working for some other reason. > > See if there are any error messages in dmesg or /var/log. > If not, perhaps the driver has extra debugging you could turn on. > > Get TCQ working and make sure your partitions are aligned on > 4 KiB boundaries (in case the drive actually has 4 KiB sectors), > and you should get the expected performance. > > [1] http://en.wikipedia.org/wiki/Serial_attached_SCSI > Thanks for the wiki article reference it is very interesting and confirms our current setup. I'm mostly thinking about this line: "SAS controllers may connect to SATA devices, either directly connected using native SATA protocol or through SAS expanders using SATA Tunneled Protocol (STP)." The systems is currently put in place using SATA instead of SAS although its using the same interface and backplane connectors and the drives (SATA) show as da0 in BSD _but_ with the SATA drive we get *much* better performances. I am thinking that something fancy in that SAS drive is not being handled correctly by the FreeBSD driver. I am planning to revisit the SAS drive issue at a later point (sometimes next week). Here is some trimmed and hopefully relevant information (from dmesg): SAS drive: mpt0: port 0x1000-0x10ff mem 0x99910000-0x99913fff,0x99900000-0x9990ffff irq 28 at device 0.0 on pci11 mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) ... da0 at mpt0 bus 0 scbus0 target 1 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C) ... GEOM: da0: the primary GPT table is corrupt or invalid. GEOM: da0: using the secondary instead -- recovery strongly advised. SATA drive: mpt0: port 0x1000-0x10ff mem 0x9b910000-0x9b913fff,0x9b900000-0x9b90ffff irq 28 at device 0.0 on pci11 mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) ... da0 at mpt0 bus 0 scbus0 target 2 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) ... GEOM: da0s1: geometry does not match label (16h,63s != 255h,63s). Please let me know if there is anything you would like me to run on the BSD 9.1 system to help diagnose this issue? Thank you, Karim. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 17 23:11:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 911181E7; Thu, 17 Jan 2013 23:11:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5DA23B6D; Thu, 17 Jan 2013 23:11:34 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id r0HNBXqK006787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Jan 2013 17:11:33 -0600 Received: from dtwin (10.14.152.22) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 17 Jan 2013 17:11:29 -0600 From: Sender: Devin Teske To: "'Damien Fleuriot'" , "'Devin Teske'" References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> <39477686-B5CC-439B-82A8-EEECBE358A9F@my.gd> In-Reply-To: <39477686-B5CC-439B-82A8-EEECBE358A9F@my.gd> Subject: RE: disadvantages of running 8.3 kernel on freebsd 8.2 system Date: Thu, 17 Jan 2013 15:11:28 -0800 Message-ID: <0bbf01cdf507$fddd7e20$f9987a60$@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG17F+kvLKaGGKXIYo9KMIouDrtrgFs29LrAqoL0fECPIraMwFae7ZjAjia+0EB63lyHZgfpf3w Content-Language: en-us X-Originating-IP: [10.14.152.22] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-01-17_09:2013-01-17,2013-01-17,1970-01-01 signatures=0 Cc: =?UTF-8?Q?'Ali_Okan_Y=C3=9CKSEL'?= , freebsd-hackers@freebsd.org, 'Devin Teske' , 'Steven Hartland' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:11:34 -0000 > -----Original Message----- > From: Damien Fleuriot [mailto:ml@my.gd] > Sent: Thursday, January 17, 2013 2:54 PM > To: Devin Teske > Cc: Steven Hartland; freebsd-hackers@freebsd.org; Devin Teske; Ali Okan > Y=C3=9CKSEL > Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system >=20 >=20 > On 17 Jan 2013, at 20:27, Devin Teske wrote: >=20 > > > > On Jan 17, 2013, at 11:14 AM, Steven Hartland wrote: > > > >> ----- Original Message ----- From: "Devin Teske" > >>> You're the perfect person to help us figure out why when we: > >>> > >>> 1. back-port mfi(4) from stable/8 into releng/8.3 (8.3-RELEASE-p5 at = the time > of back-port) > >>> > >>> 2. Succeed in getting 8.3 to boot on Thunderbolt card > >>> > >>> 3. mfiutil produces Inappropriate ioctl for device > >>> > >>> Even after=E2=80=A6 > >>> > >>> 4. Recompiling mfiutil from stable/8 (albeit in a releng/8.3 build en= vironment > -- back ported headers applied for new macros even) > >>> > >>> Any hints on where to go next to restore mfiutil access? > >> > >> You also need to backport mfiutil too. > >> > >> I have a patch set for 8.3 which include latest mfi driver, mfiutil and > >> a large set of mfi driver fixes, even head has some rather serious iss= ues > >> although mainly around error handling on tbolt cards. > >> > >> We're running this in production so believe its a good stable set. > >> > >> If you would like the patch set just let me know. > >> > > > > I can't resist when you combine words like "production" and "8.3" (smil= es) > > >=20 > ? >=20 > Are you saying 8.3 isn't production worthy ? With the right hardware, yes, that's what we're experiencing with latent ha= rdware that we've been tasked with benchmarking. > Works like a charm here for us. 50+ boxes running 8.x, most of which are = 8-stable. >=20 But I bet you're not sitting 88 units of Thunderbolt cards that don't work = in 8.3. 8.3 is also exhibiting major problems with the igb-based NICs on those same= 88 units. > No offence meant, but I'd take 8.3 over 9.x any day. > Any night too, for that matter. >=20 (smiles) > YMMV but PF + pfsync + carp (and some boxes with nginx or relayd on top) = is > pretty good for our workload on 8.3. I do indeed appreciate the vote of confidence. The hope is that when we get= through our mfi and igb problems that 8.3 will be a slammin' victory on th= is hardware (but until then, we're fighting the good fight). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 01:39:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C26D9EBC; Fri, 18 Jan 2013 01:39:08 +0000 (UTC) (envelope-from prvs=17301d565b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 08FDE24E; Fri, 18 Jan 2013 01:39:07 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001744155.msg; Fri, 18 Jan 2013 01:39:05 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 18 Jan 2013 01:39:05 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=17301d565b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: From: "Steven Hartland" To: , "'Damien Fleuriot'" References: <9A20C472-593A-4AAB-A0C0-FE6375011DAD@fisglobal.com> <201301171103.41013.jhb@freebsd.org> <796BC3D0-522A-4E1E-8BC6-96741D96E0A4@fisglobal.com> <259B53A09C4141E384BBA78217DD2BBD@multiplay.co.uk> <39477686-B5CC-439B-82A8-EEECBE358A9F@my.gd> <0bbf01cdf507$fddd7e20$f9987a60$@freebsd.org> Subject: Re: disadvantages of running 8.3 kernel on freebsd 8.2 system Date: Fri, 18 Jan 2013 01:39:27 -0000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_140D_01CDF51C.A7402260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-hackers@freebsd.org, 'Devin Teske' , =?UTF-8?Q?'Ali_Okan_Y=C3=9CKSEL'?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 01:39:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_140D_01CDF51C.A7402260 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit ----- Original Message ----- From: > But I bet you're not sitting 88 units of Thunderbolt cards that don't work in 8.3. > > 8.3 is also exhibiting major problems with the igb-based NICs on those same 88 units. Only effects igb init but might want to make sure you have r245334 back ported to avoid memory leaks when mbuf clusters are exhausted. 8.3 version of the patch attached ;-) For reference not only does this prevent the nic initialising properly it can also hang the boot process as when routing initialises "route" appears to trigger mbuf allocation with wait and as mbufs are exhaused and not freed correctly this hangs forever. This will happen on an untuned kernel if more than 2 igb nics are configured as each igb requires 8k of mbuf clusters (1k per queue x 8 queues on a machine with 8 or more cores) and the default kern.ipc.nmbclusters is only 25600. For clarity by "configured" I mean if the nic is initialised either by assigning an IP or "ifconfig igbX up" the queues are not allocated if the nic is present but unused. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. ------=_NextPart_000_140D_01CDF51C.A7402260 Content-Type: text/plain; format=flowed; name="igb-mbuf-free-patch-8.3-REL.txt"; reply-type=original Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="igb-mbuf-free-patch-8.3-REL.txt" Fixed mbuf free when receive structures fail to allocate.=0A= =0A= This prevents quad igb card on high core machines, without any = nmbcluster or=0A= igb queue tuning wedging the boot process if all nics are configured.=0A= --- sys/dev/e1000/if_igb.c.orig 2013-01-10 21:44:03.017805977 +0000=0A= +++ sys/dev/e1000/if_igb.c 2013-01-10 21:44:55.751355018 +0000=0A= @@ -4335,8 +4335,8 @@=0A= * the rings that completed, the failing case will have=0A= * cleaned up for itself. 'i' is the endpoint.=0A= */=0A= - for (int j =3D 0; j > i; ++j) {=0A= - rxr =3D &adapter->rx_rings[i];=0A= + for (int j =3D 0; j < i; ++j) {=0A= + rxr =3D &adapter->rx_rings[j];=0A= IGB_RX_LOCK(rxr);=0A= igb_free_receive_ring(rxr);=0A= IGB_RX_UNLOCK(rxr);=0A= ------=_NextPart_000_140D_01CDF51C.A7402260-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 02:33:22 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D34F803 for ; Fri, 18 Jan 2013 02:33:22 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 787576B0 for ; Fri, 18 Jan 2013 02:33:22 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0I2XLh8012773 for ; Fri, 18 Jan 2013 02:33:22 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50F8B491.8090303@freebsd.org> Date: Fri, 18 Jan 2013 10:33:53 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-hackers Subject: Fixing grep -D skip Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 02:33:22 -0000 I am trying to fix a bug in GNU grep, the bug is if you want to skip FIFO file, it will not work, for example: grep -D skip aaa . it will be stucked on a FIFO file. Here is the patch: http://people.freebsd.org/~davidxu/patch/grep.c.diff2 Is it fine to be committed ? Regards, David Xu From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 04:03:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FB23A77; Fri, 18 Jan 2013 04:03:57 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 1D86FA56; Fri, 18 Jan 2013 04:03:57 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so1025526iae.25 for ; Thu, 17 Jan 2013 20:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=gda+puCNeEMZMr7iLaneuVyh8P39v7nV9e5VCKfIBL4=; b=Ai4sAax/xWpX8nVqNRNnsczihhQp2F3ia6dB0syc/45F/vplmcdAwvTR0q03IVT2bX lVfDUV6gTnsLpVX5a/ILzN72rcr3B2/ujB3jShinPFOzTcl5vb4kgWE+qhjx1hlpH12p nix1il2P2/8FQ/XiMrWjm3lNUaZFkIz0u7P8T+VzjVusXrwnXRF18pNGqe36x7BhIsRS 8bX2oXDxBK4dNsOquXwXcmMDJM8wrXq2zjWX37QyAhGrFwy0QyFzRyAN4xzHFgr4Ux5O ViytJCvoG6HL1X5r6aOfudeVQgGHWYRkErfPdosDILWDCgzunURige+BR9fDpnUBEiCP 7Beg== MIME-Version: 1.0 X-Received: by 10.50.159.165 with SMTP id xd5mr946901igb.82.1358481836890; Thu, 17 Jan 2013 20:03:56 -0800 (PST) Received: by 10.64.107.196 with HTTP; Thu, 17 Jan 2013 20:03:56 -0800 (PST) Date: Thu, 17 Jan 2013 20:03:56 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 04:03:57 -0000 > I am thinking that something fancy in that SAS drive is > not being handled correctly by the FreeBSD driver. I think so too, and I think the something fancy is "tagged command queuing". The driver prints "da0: Command Queueing enabled" and yet your SAS drive is only getting 1 write per rev, and queuing should get you more than that. Your SATA drive is getting the expected performance, which means that NCQ must be working. > Please let me know if there is anything you would like me to run on the > BSD 9.1 system to help diagnose this issue? Looking at the mpt driver, a verbose boot may give more info. Looks like you can set a "debug" device hint, but I don't see any documentation on what to set it to. I think it is time to ask the driver wizards why TCQ isn't working, so I'm cc-ing the authors listed on the mpt man page. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 05:51:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D372CE6; Fri, 18 Jan 2013 05:51:41 +0000 (UTC) (envelope-from adrian.chadd@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 02A06E7A; Fri, 18 Jan 2013 05:51:40 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so2059697wgb.29 for ; Thu, 17 Jan 2013 21:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=E1JmhH5xfTmmvk8KGZd3oCO8vWKUqoeW5BTWQ1KnL6M=; b=eYHFckS614cTIiTGFV33pjOk0gArABojkhlNjGi5rQsIC6bwmnwAN648t+dArnFm6/ aUxArd7zOK6andP7azlP/SGHADBj/WEAtwDfR4f54fgorKTduvKsCwPuSqBxfQrc3dag 2J7DyGZ4fqBSJTPQVcI/IJTwU/lLLzMw1tvzlyZVYL1eqUdReC9yZqR0rHZSeZYuwzz2 qAbdsJW/JL/yXK/J1o3I7dBM6v0t/eSSrulyV+eOtzwuL+oA1hQHP2JPGCOa4mvsD5VP rJ46DoC8D3OL1DQbmVxYWnQ5ke4EpxEMfKuD/jvdWx41ajACcmDhnRLx7TMWBOrFZfIL nogw== MIME-Version: 1.0 X-Received: by 10.194.109.10 with SMTP id ho10mr12206082wjb.16.1358488294437; Thu, 17 Jan 2013 21:51:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Thu, 17 Jan 2013 21:51:34 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Jan 2013 21:51:34 -0800 X-Google-Sender-Auth: g__H_TTecu3u9vh2danM6ML5HzA Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Adrian Chadd To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 05:51:41 -0000 When you run gstat, how many ops/sec are you seeing? Adrian On 17 January 2013 20:03, Dieter BSD wrote: >> I am thinking that something fancy in that SAS drive is >> not being handled correctly by the FreeBSD driver. > > I think so too, and I think the something fancy is "tagged command queuing". > The driver prints "da0: Command Queueing enabled" and yet your SAS drive > is only getting 1 write per rev, and queuing should get you more than that. > Your SATA drive is getting the expected performance, which means that NCQ > must be working. > >> Please let me know if there is anything you would like me to run on the >> BSD 9.1 system to help diagnose this issue? > > Looking at the mpt driver, a verbose boot may give more info. > Looks like you can set a "debug" device hint, but I don't > see any documentation on what to set it to. > > I think it is time to ask the driver wizards why TCQ isn't working, > so I'm cc-ing the authors listed on the mpt man page. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 06:54:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1F96E6B; Fri, 18 Jan 2013 06:54:09 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6855CB6; Fri, 18 Jan 2013 06:54:08 +0000 (UTC) Received: from [192.168.1.227] (108-85-197-34.lightspeed.irvnca.sbcglobal.net [108.85.197.34]) (authenticated bits=0) by ns1.feral.com (8.14.5/8.14.4) with ESMTP id r0I6q7YD034092 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 22:52:08 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <50F8F111.3060907@feral.com> Date: Thu, 17 Jan 2013 22:52:01 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Thu, 17 Jan 2013 22:52:08 -0800 (PST) Cc: freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 06:54:09 -0000 On 1/17/2013 8:03 PM, Dieter BSD wrote: > I think it is time to ask the driver wizards why TCQ isn't working, so > I'm cc-ing the authors listed on the mpt man page. It is the MPT firmware that implements SATL, but there are probably tweaks that the FreeBSD driver doesn't do that the Linux driver does do. The MPT driver was also worked on years ago and for a variety of reasons is unloved. In general ATA drives have caching enabled, and in fact it is difficult to turn off. There is no info in the email trail that says what the state of the SAS drive is wrt cache enable. There is also no information in the original email as to which direction the I/O was being sent. Let's also get a grip about linux vs. freebsd- using 'dd' is not necessarily and apple-apple comparison where writes are concerned because of the linux heavy write behind policy (plugging I/Os until it gets a large xfer built up and then releasing, which gets larger xfers, while freebsd will use the blocksize you tell it to (whether that's optimal or not). I'll see if I can generate some A/B numbers using fio here and report back. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 08:53:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B04B309 for ; Fri, 18 Jan 2013 08:53:50 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm21-vm6.bullet.mail.ird.yahoo.com (nm21-vm6.bullet.mail.ird.yahoo.com [212.82.109.246]) by mx1.freebsd.org (Postfix) with ESMTP id 712F975D for ; Fri, 18 Jan 2013 08:53:49 +0000 (UTC) Received: from [212.82.105.247] by nm21.bullet.mail.ird.yahoo.com with NNFMP; 18 Jan 2013 08:47:17 -0000 Received: from [217.146.188.167] by tm19.bullet.mail.ird.yahoo.com with NNFMP; 18 Jan 2013 08:47:16 -0000 Received: from [127.0.0.1] by smtp135.mail.ird.yahoo.com with NNFMP; 18 Jan 2013 08:47:16 -0000 X-Yahoo-Newman-Id: 763580.20531.bm@smtp135.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .DrZbX0VM1kIwxnUq708Ui3jrKyytQiY7lPv5U1Tc4Barsu vwlLGJpzp_xzehD5D_k0DjbKTbLV0n2RSfH94XOA8nLyIDHDa2nwr8vveaUJ LpBwZCcvkt7fuupFsQ_ML1XdJrEiNn370HnbAx.XjvYviA8OmyFnJlqY82rj dpORNRyTdoxpFTo3Oo3OhHj89O0PmFnDk15_mPjJErEiVpIXS1HVGAnStFlO 4c2EKVdzrmjnwywjJcorITAUrD4sD5o1eQQhsFNuQRct.ozskyye7HvXNfoz JKvjwaV6U8xr9M5x7JPk83bbdZdCG7X6OFHOtxM63qTqiflzfMKHjSUWmiuG rAAF2FXg6m5U52fzhOQPWsho0d3B9gu01ySWytcsZtjRf8a6mvErblxRRlzR CNEb.KfsvFAkg9XNLovMTfesWxB8xwV.oKbhJFIzFnEe2Z0.s0w-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.26] (se@87.158.25.147 with plain) by smtp135.mail.ird.yahoo.com with SMTP; 18 Jan 2013 00:47:16 -0800 PST Message-ID: <50F90C0F.5010604@freebsd.org> Date: Fri, 18 Jan 2013 09:47:11 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: stupid UFS behaviour on random writes References: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 08:53:50 -0000 Am 18.01.2013 00:01, schrieb Rick Macklem: > Wojciech Puchar wrote: >> create 10GB file (on 2GB RAM machine, with some swap used to make sure >> little cache would be available for filesystem. >> >> dd if=/dev/zero of=file bs=1m count=10k >> >> block size is 32KB, fragment size 4k >> >> >> now test random read access to it (10 threads) >> >> randomio test 10 0 0 4096 >> >> normal result on such not so fast disk in my laptop. >> >> 118.5 | 118.5 5.8 82.3 383.2 85.6 | 0.0 inf nan 0.0 nan >> 138.4 | 138.4 3.9 72.2 499.7 76.1 | 0.0 inf nan 0.0 nan >> 142.9 | 142.9 5.4 69.9 297.7 60.9 | 0.0 inf nan 0.0 nan >> 133.9 | 133.9 4.3 74.1 480.1 75.1 | 0.0 inf nan 0.0 nan >> 138.4 | 138.4 5.1 72.1 380.0 71.3 | 0.0 inf nan 0.0 nan >> 145.9 | 145.9 4.7 68.8 419.3 69.6 | 0.0 inf nan 0.0 nan >> >> >> systat shows 4kB I/O size. all is fine. >> >> BUT random 4kB writes >> >> randomio test 10 1 0 4096 >> >> total | read: latency (ms) | write: latency (ms) >> iops | iops min avg max sdev | iops min avg max >> sdev >> --------+-----------------------------------+---------------------------------- >> 38.5 | 0.0 inf nan 0.0 nan | 38.5 9.0 166.5 1156.8 261.5 >> 44.0 | 0.0 inf nan 0.0 nan | 44.0 0.1 251.2 2616.7 492.7 >> 44.0 | 0.0 inf nan 0.0 nan | 44.0 7.6 178.3 1895.4 330.0 >> 45.0 | 0.0 inf nan 0.0 nan | 45.0 0.0 239.8 3457.4 522.3 >> 45.5 | 0.0 inf nan 0.0 nan | 45.5 0.1 249.8 5126.7 621.0 >> >> >> >> results are horrific. systat shows 32kB I/O, gstat shows half are >> reads >> half are writes. >> >> Why UFS need to read full block, change one 4kB part and then write >> back, instead of just writing 4kB part? > > Because that's the way the buffer cache works. It writes an entire buffer > cache block (unless at the end of file), so it must read the rest of the block into > the buffer, so it doesn't write garbage (the rest of the block) out. Without having looked at the code or testing: I assume using O_DIRECT when opening the file should help for that particular test (on kernels compiled with "options DIRECTIO"). > I'd argue that using an I/O size smaller than the file system block size is > simply sub-optimal and that most apps. don't do random I/O of blocks. > OR > If you had an app. that does random I/O of 4K blocks (at 4K byte offsets), > then using a 4K/1K file system would be better. A 4k/1k file system has higher overhead (more indirect blocks) and is clearly sub-obtimal for most general uses, today. > NFS is the exception, in that it keeps track of a dirty byte range within > a buffer cache block and writes that byte range. (NFS writes are byte granular, > unlike a disk.) I should be easy to add support for a fragment mask to the buffer cache, which allows to identify valid fragments. Such a mask should be set to 0xff for all current uses of the buffer cache (meaning the full block is valid), but a special case could then be added for writes of exactly one or multiple fragments, where only the corresponding valid flag bits were set. In addition, a possible later read from disk must obviously skip fragments for which the valid mask bits are already set. This bit mask could then be used to update the affected fragments only, without a read-modify-write of the containing block. But I doubt that such a change would improve performance in the general case, just in random update scenarios (which might still be relevant, in case of a DBMS knowing the fragment size and using it for DB files). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 09:09:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4826486B; Fri, 18 Jan 2013 09:09:16 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id ABEEB81E; Fri, 18 Jan 2013 09:09:15 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0I99CHv010388; Fri, 18 Jan 2013 10:09:12 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0I99BeB010385; Fri, 18 Jan 2013 10:09:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 10:09:11 +0100 (CET) From: Wojciech Puchar To: Stefan Esser Subject: Re: stupid UFS behaviour on random writes In-Reply-To: <50F90C0F.5010604@freebsd.org> Message-ID: References: <103826787.2103620.1358463687244.JavaMail.root@erie.cs.uoguelph.ca> <50F90C0F.5010604@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 10:09:12 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 09:09:16 -0000 > > But I doubt that such a change would improve performance in the you doubt but i am sure it would improve it a lot. Just imagine multiple VM images on filesystem, running windoze with 4kB cluster size, each writing something. no matter what is written from within VM it ends up as read followed by write, unless blocks are already in buffer cache. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 11:39:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AF2F2912 for ; Fri, 18 Jan 2013 11:39:55 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (olgeni.olgeni.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 7909971 for ; Fri, 18 Jan 2013 11:39:55 +0000 (UTC) Received: from backoffice.colby.local (93-62-141-58.ip22.fastwebnet.it [93.62.141.58]) by olgeni.olgeni.com (Postfix) with ESMTPSA id 0B7B71751EE for ; Fri, 18 Jan 2013 12:39:48 +0100 (CET) Date: Fri, 18 Jan 2013 12:39:47 +0100 (CET) From: Jimmy Olgeni X-X-Sender: olgeni@backoffice.colby.local To: freebsd-hackers@freebsd.org Subject: [GIANT-LOCKED] even without D_NEEDGIANT Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 11:39:55 -0000 Hello list, At $DAILY_JOB I got involved with an ASI board that didn't have any kind of FreeBSD support, so I ended up writing a driver for it. If you try to ignore the blatant style(9) violations (of which there are many, hopefully on the way to be cleaned up) it seems to work fine. However, I noticed that when loading the driver I always get a message about the giant lock being used, even if D_NEEDGIANT is not specified anywhere. The actual output when loading is this (FreeBSD 9-STABLE i386): dektec0: mem 0xfeaff800-0xfeafffff irq 16 at device 13.0 on pci0 dektec0: [GIANT-LOCKED] dektec0: [ITHREAD] dektec0: board model 145, firmware version 2 (tx: 0, rx: 2), tx fifo 16384 MB Source code here: https://github.com/olgeni/freebsd-dektec/blob/master/dektec.c Can anybody offer a clue about what could be triggering the GIANT requirement? Could I be doing something that has this, and possibly other, unintended side effects? -- jimmy From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 12:08:48 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03D1F8CB for ; Fri, 18 Jan 2013 12:08:48 +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 45D56271 for ; Fri, 18 Jan 2013 12:08:47 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA20966; Fri, 18 Jan 2013 14:08:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TwAkU-0001b0-CY; Fri, 18 Jan 2013 14:08:42 +0200 Message-ID: <50F93B49.5080902@FreeBSD.org> Date: Fri, 18 Jan 2013 14:08:41 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jimmy Olgeni Subject: Re: [GIANT-LOCKED] even without D_NEEDGIANT References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 12:08:48 -0000 on 18/01/2013 13:39 Jimmy Olgeni said the following: > > Hello list, > > At $DAILY_JOB I got involved with an ASI board that didn't have any kind of > FreeBSD support, so I ended up writing a driver for it. > > If you try to ignore the blatant style(9) violations (of which there are many, > hopefully on the way to be cleaned up) it seems to work fine. > > However, I noticed that when loading the driver I always get a > message about the giant lock being used, even if D_NEEDGIANT is not > specified anywhere. > > The actual output when loading is this (FreeBSD 9-STABLE i386): > > dektec0: mem 0xfeaff800-0xfeafffff irq 16 at device 13.0 on pci0 > dektec0: [GIANT-LOCKED] > dektec0: [ITHREAD] > dektec0: board model 145, firmware version 2 (tx: 0, rx: 2), tx fifo 16384 MB > > Source code here: > > https://github.com/olgeni/freebsd-dektec/blob/master/dektec.c > > Can anybody offer a clue about what could be triggering the GIANT > requirement? Could I be doing something that has this, and possibly > other, unintended side effects? > See INTR_MPSAFE in bus_setup_intr(9). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 12:24:13 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C96DECBF; Fri, 18 Jan 2013 12:24:13 +0000 (UTC) (envelope-from olgeni@olgeni.com) Received: from olgeni.olgeni.com (olgeni.olgeni.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id 8D25632D; Fri, 18 Jan 2013 12:24:13 +0000 (UTC) Received: from backoffice.colby.local (93-62-141-58.ip22.fastwebnet.it [93.62.141.58]) by olgeni.olgeni.com (Postfix) with ESMTPSA id AE69C17458A; Fri, 18 Jan 2013 13:24:12 +0100 (CET) Date: Fri, 18 Jan 2013 13:24:12 +0100 (CET) From: Jimmy Olgeni X-X-Sender: olgeni@backoffice.colby.local To: Andriy Gapon Subject: Re: [GIANT-LOCKED] even without D_NEEDGIANT In-Reply-To: <50F93B49.5080902@FreeBSD.org> Message-ID: References: <50F93B49.5080902@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 12:24:13 -0000 On Fri, 18 Jan 2013, Andriy Gapon wrote: > See INTR_MPSAFE in bus_setup_intr(9). Thanks! It went away. Back to testing... -- jimmy From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 15:17:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14357337 for ; Fri, 18 Jan 2013 15:17:03 +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 E3A39EFA for ; Fri, 18 Jan 2013 15:17:02 +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=FAhTB+lxb0gCZ9nrRpuEvR2dKDxghX3nFC+5NJ3Ygz8=; b=EeJOekjh2zrkrI1MwelUFHmUgMRlOi6r+c6d8+I/QCv3P/fEhl5GudalNxqZCXZNpE7eanEeGICMfRmZhOEsYAv5Yq1FvOQkXXTh63lw8Z9Wa5a65ookUfmABLNSGy7G; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TwDgj-0008vW-3f; Fri, 18 Jan 2013 09:17:01 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1358522210-12155-89420/5/1; Fri, 18 Jan 2013 15:16:50 +0000 Content-Type: text/plain; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances References: <50F87741.4030201@gmail.com> Date: Fri, 18 Jan 2013 09:16:50 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <50F87741.4030201@gmail.com> User-Agent: Opera Mail/12.12 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:17:03 -0000 On Thu, 17 Jan 2013 16:12:17 -0600, Karim Fodil-Lemelin wrote: > "SAS controllers may connect to SATA devices, either directly connected > using native SATA protocol or through SAS expanders using SATA Tunneled > Protocol (STP)." > The systems is currently put in place using SATA instead of SAS > although its using the same interface and backplane connectors and the > drives (SATA) show as da0 in BSD _but_ with the SATA drive we get *much* > better performances. I am thinking that something fancy in that SAS > drive is not being handled correctly by the FreeBSD driver. I am > planning to revisit the SAS drive issue at a later point (sometimes next > week). Your SATA drives are connected directly not with an interposer such as the LSISS9252, correct? If so, this might be the cause of your problems. Mixing SAS and SATA drives is known to cause serious performance issues for almost every JBOD/controller/expander/what-have-you. Change your configuration so there is only one protocol being spoken on the bus (SAS) by putting your SATA drives behind interposers which translate SAS to SATA just before the disk. This will solve many problems. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 15:29:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DC1CD06 for ; Fri, 18 Jan 2013 15:29:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D3114FFA for ; Fri, 18 Jan 2013 15:29:46 +0000 (UTC) Received: (qmail 54728 invoked from network); 18 Jan 2013 16:51:56 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Jan 2013 16:51:56 -0000 Message-ID: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 16:29:43 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-hackers Subject: kmem_map auto-sizing and size dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:29:47 -0000 The autotuning work is reaching into many places of the kernel and while trying to tie up all lose ends I've got stuck in the kmem_map and how it works or what its limitations are. During startup the VM is initialized and an initial kernel virtual memory map is setup in kmem_init() covering the entire KVM address range. Only the kernel itself is actually allocated within that map. A bit later on a number of other submaps are allocated (clean_map, buffer_map, pager_map, exec_map). Also in kmeminit() (in kern_malloc.c, different from kmem_init) the kmem_map is allocated. The (inital?) size of the kmem_map is determined by some voodoo magic, a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. However it seems to work out to an effective kmem_map_size of about 58MB on my 16GB AMD64 dev machine: vm.kvm_size: 549755809792 vm.kvm_free: 530233421824 vm.kmem_size: 16,594,300,928 vm.kmem_size_min: 0 vm.kmem_size_max: 329,853,485,875 vm.kmem_size_scale: 1 vm.kmem_map_size: 59,518,976 vm.kmem_map_free: 16,534,777,856 The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing else that uses UMA for memory allocation. Mbuf memory too is managed by UMA which obtains the backing kernel memory from the kmem_map. The limits of the various mbuf memory types have been considerably raised recently and may make use of 50-75% of all physically present memory, or available KVM space, whichever is smaller. Now my questions/comments are: Does the kmem_map automatically extend itself if more memory is requested? Should it be set to a larger initial value based on min(physical,KVM) space available? The use of nmbclusters for the initial kmem_map size calculation isn't appropriate anymore due to it being set up later and nmbclusters isn't the only mbuf relevant mbuf type. We make significant use of page sized mbuf clusters too. The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is confusing and not easy to reconcile. Either we need some more detailing more aspects or less. Plus perhaps sysctl subtrees to better describe the hierarchy of the maps. Why are separate kmem submaps being used? Is it to limit memory usage of certain subsystems? Are those limits actually enforced? -- Andre From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 15:45:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9A2664C0; Fri, 18 Jan 2013 15:45:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 21935149; Fri, 18 Jan 2013 15:45:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAE1s+VCDaFvO/2dsb2JhbAA7CoZFuAlzgh4BAQEDAQEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh3IGDKo9kWaBI4tkCgaDD4ETA4hhiXiBBYIugRyPLYMTgUkIFx4 X-IronPort-AV: E=Sophos;i="4.84,493,1355115600"; d="scan'208";a="12615786" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Jan 2013 10:45:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B1A56B3F91; Fri, 18 Jan 2013 10:45:48 -0500 (EST) Date: Fri, 18 Jan 2013 10:45:48 -0500 (EST) From: Rick Macklem To: Stefan Esser Message-ID: <2006598795.2120288.1358523948712.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50F90C0F.5010604@freebsd.org> Subject: Re: stupid UFS behaviour on random writes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 15:45:50 -0000 Stefan Esser wrote: > Am 18.01.2013 00:01, schrieb Rick Macklem: > > Wojciech Puchar wrote: > >> create 10GB file (on 2GB RAM machine, with some swap used to make > >> sure > >> little cache would be available for filesystem. > >> > >> dd if=/dev/zero of=file bs=1m count=10k > >> > >> block size is 32KB, fragment size 4k > >> > >> > >> now test random read access to it (10 threads) > >> > >> randomio test 10 0 0 4096 > >> > >> normal result on such not so fast disk in my laptop. > >> > >> 118.5 | 118.5 5.8 82.3 383.2 85.6 | 0.0 inf nan 0.0 nan > >> 138.4 | 138.4 3.9 72.2 499.7 76.1 | 0.0 inf nan 0.0 nan > >> 142.9 | 142.9 5.4 69.9 297.7 60.9 | 0.0 inf nan 0.0 nan > >> 133.9 | 133.9 4.3 74.1 480.1 75.1 | 0.0 inf nan 0.0 nan > >> 138.4 | 138.4 5.1 72.1 380.0 71.3 | 0.0 inf nan 0.0 nan > >> 145.9 | 145.9 4.7 68.8 419.3 69.6 | 0.0 inf nan 0.0 nan > >> > >> > >> systat shows 4kB I/O size. all is fine. > >> > >> BUT random 4kB writes > >> > >> randomio test 10 1 0 4096 > >> > >> total | read: latency (ms) | write: latency (ms) > >> iops | iops min avg max sdev | iops min avg max > >> sdev > >> --------+-----------------------------------+---------------------------------- > >> 38.5 | 0.0 inf nan 0.0 nan | 38.5 9.0 166.5 1156.8 261.5 > >> 44.0 | 0.0 inf nan 0.0 nan | 44.0 0.1 251.2 2616.7 492.7 > >> 44.0 | 0.0 inf nan 0.0 nan | 44.0 7.6 178.3 1895.4 330.0 > >> 45.0 | 0.0 inf nan 0.0 nan | 45.0 0.0 239.8 3457.4 522.3 > >> 45.5 | 0.0 inf nan 0.0 nan | 45.5 0.1 249.8 5126.7 621.0 > >> > >> > >> > >> results are horrific. systat shows 32kB I/O, gstat shows half are > >> reads > >> half are writes. > >> > >> Why UFS need to read full block, change one 4kB part and then write > >> back, instead of just writing 4kB part? > > > > Because that's the way the buffer cache works. It writes an entire > > buffer > > cache block (unless at the end of file), so it must read the rest of > > the block into > > the buffer, so it doesn't write garbage (the rest of the block) out. > > Without having looked at the code or testing: > > I assume using O_DIRECT when opening the file should help for that > particular test (on kernels compiled with "options DIRECTIO"). > > > I'd argue that using an I/O size smaller than the file system block > > size is > > simply sub-optimal and that most apps. don't do random I/O of > > blocks. > > OR > > If you had an app. that does random I/O of 4K blocks (at 4K byte > > offsets), > > then using a 4K/1K file system would be better. > > A 4k/1k file system has higher overhead (more indirect blocks) and > is clearly sub-obtimal for most general uses, today. > Yes, but if the sysadmin knows that most of the I/O is random 4K blocks, that's his specific case, not a general use. Sorry, I didn't mean to imply that a 4K file system was a good choice, in general. > > NFS is the exception, in that it keeps track of a dirty byte range > > within > > a buffer cache block and writes that byte range. (NFS writes are > > byte granular, > > unlike a disk.) > > I should be easy to add support for a fragment mask to the buffer > cache, which allows to identify valid fragments. Such a mask should > be set to 0xff for all current uses of the buffer cache (meaning the > full block is valid), but a special case could then be added for > writes > of exactly one or multiple fragments, where only the corresponding > valid flag bits were set. In addition, a possible later read from > disk must obviously skip fragments for which the valid mask bits are > already set. > This bit mask could then be used to update the affected fragments > only, without a read-modify-write of the containing block. > > But I doubt that such a change would improve performance in the > general case, just in random update scenarios (which might still > be relevant, in case of a DBMS knowing the fragment size and using > it for DB files). > > Regards, STefan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" Yes. And for some I/O patterns the fragment change would degrade performance. You mentioned that a later read might have to skip fragments with the valid bit. I think this would translate to doing multiple reads for the other fragments, in practice. Also, when an app. goes to write a partial fragment, that fragment would have to be read in and this could result in several reads of fragments instead of one read for the entire block. It's the old "OS doesn't have a crystal ball that predicts future I/O activity". Btw, although I did a "dirty byte range" for NFS for the buffer cache ages (late 1980s) ago, it is also a performance hit for certain cases. The linker/loaders love to write random sized chucks to files. For the NFS code, if the new write isn't contiguous with the old one, a synchronous write of the old dirty byte range is forced to the server. I have a patch that replaces the single byte range with a list in order to avoid this synchronous write, but it has not made it into head. (I hope to do so someday, after more testing and when I figure out all the implications of changing "struct buf" for the rest of the system.) Of course, if someone codes up a patch for the "fragment bits" for the buffer cache code, it might be an interesting enhancement. (One trick here is that the code will need to know the sector size for the underlying storage system, so it can size the fragment. I'm not sure if that can reliably be acquired from the drivers these days?) rick From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 16:25:06 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B081B202; Fri, 18 Jan 2013 16:25:06 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by mx1.freebsd.org (Postfix) with ESMTP id DBE7D389; Fri, 18 Jan 2013 16:25:05 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fk20so4091650lab.36 for ; Fri, 18 Jan 2013 08:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bUjt+EpzYBD1d9QBZu1H3cOP8+CaZ0JU8HdUQSJ0bV0=; b=hDhqozb1v8ZrNcN7u2JqfvPLs8MXwgGCUuDQItjAsaxYDRuueG45m2nZVQssf2NPm1 rYZuE9eA0d0qmHPEnbhXmp6j7OI0FNor6pUCFWdxqRbC8t81afyFY7gsAXlEiyDKyEx2 vgKzGktfa+glEFlWEUXQ5CfCPH4QVVGITrGfR+Cazv9vKNS/Bnd8aG1w9zhbKaM89Z7L mow7gbOye1tEpNCjRG9GL2BWwpSj7WJYo5bQg/SbKRumaOvPtp5oAOXhuFf2wY2wMi9u p3ftVh4ZvtuUlkY5pxf/V2YkcyypprsBMabjkJPxQGnbScunRmijmlJxZIU+Cga2XZyE uHMQ== MIME-Version: 1.0 X-Received: by 10.112.14.46 with SMTP id m14mr4013713lbc.98.1358526304638; Fri, 18 Jan 2013 08:25:04 -0800 (PST) Received: by 10.114.21.197 with HTTP; Fri, 18 Jan 2013 08:25:04 -0800 (PST) In-Reply-To: <50F96A67.9080203@freebsd.org> References: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 10:25:04 -0600 Message-ID: Subject: Re: kmem_map auto-sizing and size dependencies From: Alan Cox To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers , freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:25:06 -0000 I'll follow up with detailed answers to your questions over the weekend. For now, I will, however, point out that you've misinterpreted the tunables. In fact, they say that your kmem map can hold up to 16GB and the current used space is about 58MB. Like other things, the kmem map is auto-sized based on the available physical memory and capped so as not to consume too much of the overall kernel address space. Regards, Alan On Fri, Jan 18, 2013 at 9:29 AM, Andre Oppermann wrote: > The autotuning work is reaching into many places of the kernel and > while trying to tie up all lose ends I've got stuck in the kmem_map > and how it works or what its limitations are. > > During startup the VM is initialized and an initial kernel virtual > memory map is setup in kmem_init() covering the entire KVM address > range. Only the kernel itself is actually allocated within that > map. A bit later on a number of other submaps are allocated (clean_map, > buffer_map, pager_map, exec_map). Also in kmeminit() (in kern_malloc.c, > different from kmem_init) the kmem_map is allocated. > > The (inital?) size of the kmem_map is determined by some voodoo magic, > a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. > However it seems to work out to an effective kmem_map_size of about 58MB > on my 16GB AMD64 dev machine: > > vm.kvm_size: 549755809792 > vm.kvm_free: 530233421824 > vm.kmem_size: 16,594,300,928 > vm.kmem_size_min: 0 > vm.kmem_size_max: 329,853,485,875 > vm.kmem_size_scale: 1 > vm.kmem_map_size: 59,518,976 > vm.kmem_map_free: 16,534,777,856 > > The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing > else that uses UMA for memory allocation. > > Mbuf memory too is managed by UMA which obtains the backing kernel memory > from the kmem_map. The limits of the various mbuf memory types have > been considerably raised recently and may make use of 50-75% of all > physically > present memory, or available KVM space, whichever is smaller. > > Now my questions/comments are: > > Does the kmem_map automatically extend itself if more memory is requested? > > Should it be set to a larger initial value based on min(physical,KVM) > space > available? > > The use of nmbclusters for the initial kmem_map size calculation isn't > appropriate anymore due to it being set up later and nmbclusters isn't the > only mbuf relevant mbuf type. We make significant use of page sized mbuf > clusters too. > > The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is > confusing and not easy to reconcile. Either we need some more detailing > more aspects or less. Plus perhaps sysctl subtrees to better describe the > hierarchy of the maps. > > Why are separate kmem submaps being used? Is it to limit memory usage of > certain subsystems? Are those limits actually enforced? > > -- > Andre > ______________________________**_________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@** > freebsd.org " > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 16:26:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1076A407; Fri, 18 Jan 2013 16:26:11 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9733D3DA; Fri, 18 Jan 2013 16:26:10 +0000 (UTC) Received: by mail-qc0-f169.google.com with SMTP id t2so2537499qcq.14 for ; Fri, 18 Jan 2013 08:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dyi654dEMV3T/5Id1ivoDxrLLhIsmvWJmuXhkMp/Oe4=; b=ON39WagYTPdzEj0v2rBYkmgZFs14G/RJdBSjXOI5Mln0OTO3b3WyHNMykEj+vSJYXV wrte5gxg0ThQE4nt790GDrF3od8RmqMYuIIMiJbaV4Atfb5bpgeUlAIJjfNTcLaCIYHC K8bvKBiwxkn74rGsbgiFZ4sAYFihwJ9LnhzEfNhrfEZqfUrmmCgbJopmn6wYPKUDqH9F Kv2rb9UD0ITBlPZIqE/Kq9WPhJH9OyYzlagNHCsya9aCf5BbQI0BnDHJr4IgFCw547wm ZsLCKmNapqRrH1IjszPsG2fv3wLmExXpX4Sx4ceAFqFn+ErxGbkVp/6ZqDrwhuxlywAK G0qw== MIME-Version: 1.0 X-Received: by 10.224.17.193 with SMTP id t1mr9796155qaa.89.1358526364372; Fri, 18 Jan 2013 08:26:04 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.229.156.18 with HTTP; Fri, 18 Jan 2013 08:26:04 -0800 (PST) In-Reply-To: <50F96A67.9080203@freebsd.org> References: <50F96A67.9080203@freebsd.org> Date: Fri, 18 Jan 2013 08:26:04 -0800 X-Google-Sender-Auth: cv1G1jW4Z8UYSMJow_1pgYk2gzI Message-ID: Subject: Re: kmem_map auto-sizing and size dependencies From: mdf@FreeBSD.org To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers , freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:26:11 -0000 On Fri, Jan 18, 2013 at 7:29 AM, Andre Oppermann wrote: > The (inital?) size of the kmem_map is determined by some voodoo magic, > a sprinkle of nmbclusters * PAGE_SIZE incrementor and lots of tunables. > However it seems to work out to an effective kmem_map_size of about 58MB > on my 16GB AMD64 dev machine: > > vm.kvm_size: 549755809792 > vm.kvm_free: 530233421824 > vm.kmem_size: 16,594,300,928 > vm.kmem_size_min: 0 > vm.kmem_size_max: 329,853,485,875 > vm.kmem_size_scale: 1 > vm.kmem_map_size: 59,518,976 > vm.kmem_map_free: 16,534,777,856 > > The kmem_map serves kernel malloc (via UMA), contigmalloc and everthing > else that uses UMA for memory allocation. > > Mbuf memory too is managed by UMA which obtains the backing kernel memory > from the kmem_map. The limits of the various mbuf memory types have > been considerably raised recently and may make use of 50-75% of all > physically > present memory, or available KVM space, whichever is smaller. > > Now my questions/comments are: > > Does the kmem_map automatically extend itself if more memory is requested? Not that I recall. > Should it be set to a larger initial value based on min(physical,KVM) space > available? It needs to be smaller than the physical space, because the only limit on the kernel's use of (pinned) memory is the size of the map. So if it is too large there is nothing to stop the kernel from consuming all available memory. The lowmem handler is called when running out of virtual space only (i.e. a failure to allocate a range in the map). > The naming and output of the various vm.kmem_* and vm.kvm_* sysctls is > confusing and not easy to reconcile. Either we need some more detailing > more aspects or less. Plus perhaps sysctl subtrees to better describe the > hierarchy of the maps. > > Why are separate kmem submaps being used? Is it to limit memory usage of > certain subsystems? Are those limits actually enforced? I mostly know about memguard, since I added memguard_fudge(). IIRC some of the submaps are used. The memguard_map specifically is used to know whether an allocation is guarded or not, so at free(9) it can be handled as normal malloc() or as memguard. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 17:13:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CB29946B; Fri, 18 Jan 2013 17:13:13 +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 AAC84889; Fri, 18 Jan 2013 17:13:13 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0AB00B993; Fri, 18 Jan 2013 12:13:13 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Fixing grep -D skip Date: Fri, 18 Jan 2013 11:39:00 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <50F8B491.8090303@freebsd.org> In-Reply-To: <50F8B491.8090303@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301181139.00910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Jan 2013 12:13:13 -0500 (EST) Cc: David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:13:13 -0000 On Thursday, January 17, 2013 9:33:53 pm David Xu wrote: > I am trying to fix a bug in GNU grep, the bug is if you > want to skip FIFO file, it will not work, for example: > > grep -D skip aaa . > > it will be stucked on a FIFO file. > > Here is the patch: > http://people.freebsd.org/~davidxu/patch/grep.c.diff2 > > Is it fine to be committed ? I think the first part definitely looks fine. My guess is the non-blocking change is als probably fine, but that should be run by the bsdgrep person at least. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 17:26:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8B368C7A for ; Fri, 18 Jan 2013 17:26:13 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm20.bullet.mail.ne1.yahoo.com (nm20.bullet.mail.ne1.yahoo.com [98.138.90.83]) by mx1.freebsd.org (Postfix) with ESMTP id 49EFDA89 for ; Fri, 18 Jan 2013 17:26:13 +0000 (UTC) Received: from [98.138.90.57] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 17:22:59 -0000 Received: from [98.138.89.169] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 17:22:59 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 17:22:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 32151.48370.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 74387 invoked by uid 60001); 18 Jan 2013 17:22:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358529778; bh=D/8jjl4OZi/A5XTFk2tJcBNEnRF9W+i8s6MiAhROvz4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eJF29s8YISW1MA/ZxpNbzbl4Zf2GFtQCmPaO5n7GD2wCOfO8SxYT2tSkZqnvdnk1IsUzuqXYuCj4DyMTSEq6hSALwEaqzwRa36n3ZLtkVkfLZRqcbre6Z3fmMVqEQedGFAP8SdifFrriPQPrBcSvsdjwqyn3SM/J4eVdRNxmWks= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cUNngRCbtFyJMepHAmQTNN2tyRpoyCmR0Qpp9pFvFa9uJP89y3c/X/IF5LTSMT14ZR/iN2rmFJ89KKYgj14Og0SaImuDsPR+jj5wAoJQza60QzmDsdx+/KkAkIUtVmkJIETI//BYM89U1lmkfwHgtCChTsksiOFbyE7uMsfIiAA=; X-YMail-OSG: 6sazS4gVM1neG4XLSZOSIol1Mg9j.VyzEBGfoTL7orPrun4 Jdhw0QdacN8P5F_gYESY6_BLziaxNFQzejM1774FStXPtxFP0OjC6khOvvl4 TtuOr6opUrD7u1kvIOf9nvAPe1xpAd0LO4tnBqVaMETdT2gNMoFNekLPURX4 tU4YR.IFXPTadKczqmzBlnWG08ZUL74x5Vx8B2DAoYrTVeA8IwiGTglgxLRt uiUkyv8ShTrzwSFE.ILTJ9Y7IWANEEmdq415vANwwQMhjvZoZwnKHn73OLQR yatfjHYw8bGo4ujzQqY0eUs6QVWRz68JTAsfdjakp5N4zfyRnVeQiwNafJkd Z8wLBnnXrMHDCYUFPHqRLQFjkRt8YSMN7Qys1aHkNY_l1Z2_IMs5RRgOusBy JK02Oq2kl5VWdjBcG5zH_BiV03qGPt3pDRa83jeAQdgRoxM6tzJDOwcMr.Ml c648CeUjE4WGeVHMiMGKRnlgolTMFfES3a0lZE.ODn2d6a3UUdVS8Xmfxt1z G2Hh.tLwZHeYhmtO.l9Z_KzLd Received: from [69.53.237.126] by web120304.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 09:22:58 PST X-Rocket-MIMEInfo: 001.001, VHJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHRvIC9ib290L2xvYWRlci5jb25mIGFuZCByZWJvb3Q6Cgpody5tcHQuZW5hYmxlX3NhdGFfd2M9MQoKVGhlIGRlZmF1bHQgdmFsdWUsIC0xLCBpbnN0cnVjdHMgdGhlIGRyaXZlciB0byBsZWF2ZSB0aGUgU1RBIGRyaXZlcyBhdCB0aGVpciBjb25maWd1cmF0aW9uIGRlZmF1bHQuIMKgT2Z0ZW4gdGltZXMgdGhpcyBtZWFucyB0aGF0IHRoZSBNUFQgQklPUyB3aWxsIHR1cm4gb2ZmIHRoZSB3cml0ZSBjYWNoZSBvbiBldmVyeSBzeXN0ZW0gYm9vdCBzZXF1ZW5jZS4gwqABMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: Message-ID: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 09:22:58 -0800 (PST) From: Scott Long Subject: Re: IBM blade server abysmal disk write performances To: Dieter BSD , "freebsd-hackers@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Jan 2013 17:50:25 +0000 Cc: "gibbs@FreeBSD.org" , "scottl@FreeBSD.org" , "mjacob@FreeBSD.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Scott Long List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 17:26:13 -0000 Try adding the following to /boot/loader.conf and reboot:=0A=0Ahw.mpt.enabl= e_sata_wc=3D1=0A=0AThe default value, -1, instructs the driver to leave the= STA drives at their configuration default. =A0Often times this means that = the MPT BIOS will turn off the write cache on every system boot sequence. = =A0IT DOES THIS FOR A GOOD REASON! =A0An enabled write cache is counter to = data reliability. =A0Yes, it helps make benchmarks look really good, and it= 's acceptable if your data can be safely thrown away (for example, you're j= ust caching from a slower source, and the cache can be rebuilt if it gets c= orrupted). =A0And yes, Linux has many tricks to make this benchmark look re= ally good. =A0The tricks range from buffering the raw device to having 'dd'= recognize the requested task and short-circuit the process of going to /de= v/null or pulling from /dev/zero. =A0I can't tell you how bogus these tests= are and how completely irrelevant they are in predicting actual workload p= erformance. =A0But, I'm not going to stop anyone from trying, so give the a= bove tunable a try and let me know how it works.=0A=0ABtw, I'm not subscribed to the hackers = mailing list, so please redistribute this email as needed.=0A=0AScott=0A=0A= =0A=0A=0A>________________________________=0A> From: Dieter BSD =0A>To: freebsd-hackers@freebsd.org =0A>Cc: mjacob@FreeBSD.org; g= ibbs@FreeBSD.org; scottl@FreeBSD.org =0A>Sent: Thursday, January 17, 2013 9= :03 PM=0A>Subject: Re: IBM blade server abysmal disk write performances=0A>= =0A>> I am thinking that something fancy in that SAS drive is=0A>> not bei= ng handled correctly by the FreeBSD driver.=0A>=0A>I think so too, and I th= ink the something fancy is "tagged command queuing".=0A>The driver prints "= da0: Command Queueing enabled" and yet your SAS drive=0A>is only getting 1 = write per rev, and queuing should get you more than that.=0A>Your SATA driv= e is getting the expected performance, which means that NCQ=0A>must be work= ing.=0A>=0A>> Please let me know if there is anything you would like me to = run on the=0A>> BSD 9.1 system to help diagnose this issue?=0A>=0A>Looking = at the mpt driver, a verbose boot may give more info.=0A>Looks like you can= set a "debug" device hint, but I don't=0A>see any documentation on what to= set it to.=0A>=0A>I think it is time to ask the driver wizards why TCQ isn= 't working,=0A>so I'm cc-ing the authors listed on the mpt man page.=0A>=0A= >=0A> From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 18:10:13 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1FE0D5C3; Fri, 18 Jan 2013 18:10:13 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9ADD83; Fri, 18 Jan 2013 18:10:12 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0IIABSY012651; Fri, 18 Jan 2013 19:10:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0IIABul012648; Fri, 18 Jan 2013 19:10:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 19:10:11 +0100 (CET) From: Wojciech Puchar To: Scott Long Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> Message-ID: References: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2456600518-498302207-1358532611=:12638" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 19:10:11 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" , Dieter BSD , "gibbs@FreeBSD.org" , "scottl@FreeBSD.org" , "mjacob@FreeBSD.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:10:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2456600518-498302207-1358532611=:12638 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > > The default value, -1, instructs the driver to leave the STA drives at their configuration default.  Often times this means that the MPT BIOS will turn off the write cache on every system boot sequence.  IT DOES THIS FOR A GOOD REASON!  An enabled write cache is counter to data reliability.  Yes, it helps make benchmarks look really good, and it's acceptable if your data can be safely thrown away (for example, you're just caching from a slower source, and the cache can be rebuilt if it gets corrupted).  And yes, Linux has many tricks to make this benchmark look really good.  The tricks range from buffering the raw device to having 'dd' recognize the requested task and short-circuit the process of going to /dev/null or pulling from /dev/zero.  I can't tell you how bogus these tests are and how completely irrelevant they are in predicting actual workload performance.  But, I'm not going to stop anyone from trying, so give the above tunable a try > and let me know how it works. > If computer have UPS then write caching is fine. even if FreeBSD crash, disk would write data --2456600518-498302207-1358532611=:12638-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 18:19:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D20A88A8 for ; Fri, 18 Jan 2013 18:19:03 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm23-vm2.bullet.mail.ne1.yahoo.com (nm23-vm2.bullet.mail.ne1.yahoo.com [98.138.91.211]) by mx1.freebsd.org (Postfix) with ESMTP id 9AEFCDED for ; Fri, 18 Jan 2013 18:19:03 +0000 (UTC) Received: from [98.138.226.180] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 18:18:57 -0000 Received: from [98.138.89.251] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 18:18:56 -0000 Received: from [127.0.0.1] by omp1043.mail.ne1.yahoo.com with NNFMP; 18 Jan 2013 18:18:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 980127.71061.bm@omp1043.mail.ne1.yahoo.com Received: (qmail 75771 invoked by uid 60001); 18 Jan 2013 18:18:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358533136; bh=hHB3LbEoQLKpgIsN5zv351jdCwlj/MhT6GgHn/7HQRI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ClJUSKncYi2wawBSsNMNMY4zvSFkfByOBGGxuF8WcIro8L2K7jS1Z3fHOk4TwrnQzcQ0c6zU1Chr3EG1SPpCERgPJrZwHlw7NSR6sCreH5iQ5On23o14wlKFfRC9bmXL8jEU6SHRqqypyTf/o+4y9UpHOQdfTmh7vJBI4dq6/Cw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vGOnJ5ic92XbLLxWc9pxk3fxQWWWPlXvEq6XsUNf+UwpaYDTFZvHSB1WRZv9JzlyrXRkYfkX67LCPMJHSaS2gEx33JrLKitmi4LWioThkzBKUiC/ATVopKDdsVaG66hauAa0Yvd5YpiN88zra1a+JVeURgaWKE0342w+FbbZ7Ko=; X-YMail-OSG: iftSZWYVM1kvTKgTBmAjEni.Y4uiZ_8_3ksNFa2g.qsG4w2 UHnLAvaj9kjK2IkaU8OTNcNP8OdiRrN39VniyrvpHj2qrTtfi4y4fJndPkIJ x_vZZd6FG9sJp.423vJ_oX7xJTkkjb63aJ1XDc6fPMR29S9Z3HI7P.ZSnTHh 6xKEZdaqwx7Jkn9KMUYgX7IgqbGPJ7jIQjHapo7pnQycqBpFzF2nZMROiEn3 Zqr27BibI6xi7nCKUxNIQy17n_bXsuNWGSOgxmTby.bjnF5.MnLxwscZKEN3 OGhCibxA5cP9ZZoRNI0r1FcmCSz86kqwSQq1bWkr9UYrr0dTdzrtxW4Fd7eR lORrHqGXtRSZHlmFk7c4CxoqIKzJkI7fq2LrDaPuij47tF7g.nGnudHsEJD0 T6.2X46Vefvv6nvkfzFpgaCScDNCkA0xmwRDdpsGZKETOBmS_oE1deOkugpW bJjchqgHPX7NwvOlHbBAzIfeTEBOSMfiL.1CQY0SF8QR49CupVHQKLj.fCG3 hb5IizpIYCm6nfUx1ArUOtSB0 Received: from [69.53.237.126] by web120302.mail.ne1.yahoo.com via HTTP; Fri, 18 Jan 2013 10:18:56 PST X-Rocket-MIMEInfo: 001.001, LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQoKPiBGcm9tOiBXb2pjaWVjaCBQdWNoYXIgPHdvanRla0B3b2p0ZWsudGVuc29yLmdkeW5pYS5wbD4KPiBUbzogU2NvdHQgTG9uZyA8c2NvdHQ0bG9uZ0B5YWhvby5jb20.Cj4gQ2M6IERpZXRlciBCU0QgPGRpZXRlcmJzZEBnbWFpbC5jb20.OyAiZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnIiA8ZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPjsgImdpYmJzQEZyZWVCU0Qub3JnIiA8Z2liYnNAZnJlZWJzZC5vcmc.OyAic2NvdHRsQEZyZWVCU0Qub3JnIiABMAEBAQE- X-Mailer: YahooMailWebService/0.8.130.494 References: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> Message-ID: <1358533136.41693.YahooMailNeo@web120302.mail.ne1.yahoo.com> Date: Fri, 18 Jan 2013 10:18:56 -0800 (PST) From: Scott Long Subject: Re: IBM blade server abysmal disk write performances To: Wojciech Puchar In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 18 Jan 2013 18:30:48 +0000 Cc: "freebsd-hackers@freebsd.org" , Dieter BSD , "gibbs@FreeBSD.org" , "scottl@FreeBSD.org" , "mjacob@FreeBSD.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Scott Long List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:19:03 -0000 ----- Original Message -----=0A=0A> From: Wojciech Puchar =0A> To: Scott Long =0A> Cc: Dieter BS= D ; "freebsd-hackers@freebsd.org" ; "gibbs@FreeBSD.org" ; "scottl@FreeBSD.org" ; "mjacob@FreeBSD.org" =0A> Sent: Fri= day, January 18, 2013 11:10 AM=0A> Subject: Re: IBM blade server abysmal di= sk write performances=0A> =0A>> =0A>> The default value, -1, instructs the= driver to leave the STA drives at =0A> their configuration default. =A0Oft= en times this means that the MPT BIOS will turn =0A> off the write cache on= every system boot sequence. =A0IT DOES THIS FOR A GOOD =0A> REASON! =A0An = enabled write cache is counter to data reliability. =A0Yes, it helps =0A> m= ake benchmarks look really good, and it's acceptable if your data can be = =0A> safely thrown away (for example, you're just caching from a slower sou= rce, =0A> and the cache can be rebuilt if it gets corrupted). =A0And yes, L= inux has many =0A> tricks to make this benchmark look really good. =A0The t= ricks range from buffering =0A> the raw device to having 'dd' recognize the= requested task and =0A> short-circuit the process of going to /dev/null or= pulling from /dev/zero. =A0I =0A> can't tell you how bogus these tests are= and how completely irrelevant they =0A> are in predicting actual workload = performance. =A0But, I'm not going to stop =0A> anyone from trying, so give= the above tunable a try=0A>> and let me know how it works.=0A>> =0A> If c= omputer have UPS then write caching is fine. even if FreeBSD crash, =0A> di= sk would write data=0A> =0A=0AI suspect that I'm encountering situations ri= ght now at netflix where this advice is not true. =A0I have drives that are= seeing intermittent errors, then being forced into reset after a timeout, = and then coming back up with filesystem problems. =A0It's only a suspicion = at this point, not a confirmed case.=0A=0AScott=0A From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 19:37:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 80050FDC; Fri, 18 Jan 2013 19:37:23 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id D44CC202; Fri, 18 Jan 2013 19:37:22 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0IJbL4R013072; Fri, 18 Jan 2013 20:37:21 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0IJbKeL013069; Fri, 18 Jan 2013 20:37:20 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 20:37:20 +0100 (CET) From: Wojciech Puchar To: Scott Long Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <1358533136.41693.YahooMailNeo@web120302.mail.ne1.yahoo.com> Message-ID: References: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> <1358533136.41693.YahooMailNeo@web120302.mail.ne1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2456600518-1385782499-1358537841=:13066" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 20:37:21 +0100 (CET) Cc: "freebsd-hackers@freebsd.org" , Dieter BSD , "gibbs@FreeBSD.org" , "scottl@FreeBSD.org" , "mjacob@FreeBSD.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 19:37:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2456600518-1385782499-1358537841=:13066 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT >> disk would write data >> > > I suspect that I'm encountering situations right now at netflix where this advice is not true.  I have drives that are seeing intermittent errors, then being forced into reset after a timeout, and then coming back up with filesystem problems.  It's only a suspicion at this point, not a confirmed case. true. I just assumed that anywhere it matters one would use gmirror. As for myself - i always prefer to put different manufacturers drives for gmirror or at least - not manufactured at similar time. 2 fails at the same moment is rather unlikely. Of course - everything is possible so i do proper backups to remote sites. Remote means another city. --2456600518-1385782499-1358537841=:13066-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 20:12:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 02A42C2A; Fri, 18 Jan 2013 20:12:12 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id A9670369; Fri, 18 Jan 2013 20:12:11 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id k13so6799254iea.22 for ; Fri, 18 Jan 2013 12:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=vlKrdXk0EKjr4rKgFz4eK6NWxAp+9FByx7Tm0xKwPrM=; b=eBEfKkfOgZz6FOkSbABqXd6bn7byfzyhskslOH24Q76ylpmDtdei+JMl0tHhxA+o+Y Lg54SDF0TVX0XNGs4E60XUyqAeqFev/TbGbHpn4k6hSMSUBE+mN/eeKFUOToj/+/gXSS 5bWzMXVVwnJ9HbfzxbjeTq5P+EX5VwdpXb8+cK7eeZ4TnZo8QR7cr296PfliikBL9cxh zpJRXLjdqDtHagCdCpenafTCMsFBJxe5DaANWZ8r9yBT0BUI/n8utU3SmE592Zjhg2DV fH/q7GEb6wVlVjZJrIIac9rG0o3RLDOhGYbUdglW9IEJaT6FJc36Am+VCyJLqa0+mqQR uauA== MIME-Version: 1.0 X-Received: by 10.50.159.165 with SMTP id xd5mr3189532igb.82.1358539931237; Fri, 18 Jan 2013 12:12:11 -0800 (PST) Received: by 10.64.107.196 with HTTP; Fri, 18 Jan 2013 12:12:11 -0800 (PST) Date: Fri, 18 Jan 2013 12:12:11 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:12:12 -0000 Wojciech writes: > If computer have UPS then write caching is fine. even if FreeBSD crash, > disk would write data That is incorrect. A UPS reduces the risk, but does not eliminate it. It is impossible to completely eliminate the risk of having the write cache on. If you care about your data you must turn the disk's write cache off. If you are using the drive in an application where the data does not matter, or can easily be regenerated (e.g. disk duplication, if it fails, just start over), then turning the write cache on for that one drive can be ok. There is a patch that allows turning the write cache on and off on a per drive basis. The patch is for ata(4), but should be possible with other drivers. camcontrol(8) may work for SCSI and SAS drives. I have yet to see a USB-to-*ATA bridge that allows turning the write cache off, so USB disks are useless for most applications. But for most applications, you must have the write cache off, and you need queuing (e.g. TCQ or NCQ) for performance. If you have queuing, there is no need to turn the write cache on. It is inexcusable that FreeBSD defaults to leaving the write cache on for SATA & PATA drives. At least the admin can easily fix this by adding hw.ata.wc=0 to /boot/loader.conf. The bigger problem is that FreeBSD does not support queuing on all controllers that support it. Not something that admins can fix, and inexcusable for an OS that claims to care about performance. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 20:34:24 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E302A29C; Fri, 18 Jan 2013 20:34:24 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C8F3D691; Fri, 18 Jan 2013 20:34:17 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0IKYG7q013154; Fri, 18 Jan 2013 13:34:17 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0IKYDpI008123; Fri, 18 Jan 2013 13:34:13 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: IBM blade server abysmal disk write performances From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: <1358529778.71931.YahooMailNeo@web120304.mail.ne1.yahoo.com> <1358533136.41693.YahooMailNeo@web120302.mail.ne1.yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jan 2013 13:34:13 -0700 Message-ID: <1358541253.32417.248.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Scott Long , "freebsd-hackers@freebsd.org" , Dieter BSD , "scottl@FreeBSD.org" , "gibbs@FreeBSD.org" , "mjacob@FreeBSD.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:34:25 -0000 On Fri, 2013-01-18 at 20:37 +0100, Wojciech Puchar wrote: > >> disk would write data > >> > > > > I suspect that I'm encountering situations right now at netflix where this advice is not true. I have drives that are seeing intermittent errors, then being forced into reset after a timeout, and then coming back up with filesystem problems. It's only a suspicion at this point, not a confirmed case. > true. I just assumed that anywhere it matters one would use gmirror. > As for myself - i always prefer to put different manufacturers drives for > gmirror or at least - not manufactured at similar time. > That is good advice. I bought six 1TB drives at the same time a few years ago and received drives with consequtive serial numbers. They were all part of the same array, and they all failed ("click of death") within a six hour timespan of each other. Luckily I noticed the clicking right away and was able to get all the data copied to another array within a few hours, before they all died. -- Ian > 2 fails at the same moment is rather unlikely. Of course - everything is > possible so i do proper backups to remote sites. Remote means another > city. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 20:39:27 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6E2E1427; Fri, 18 Jan 2013 20:39:27 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id CFBE26C4; Fri, 18 Jan 2013 20:39:26 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0IKdOf1013260; Fri, 18 Jan 2013 21:39:24 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0IKdOQ5013257; Fri, 18 Jan 2013 21:39:24 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 21:39:24 +0100 (CET) From: Wojciech Puchar To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 21:39:24 +0100 (CET) Cc: freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:39:27 -0000 > > That is incorrect. A UPS reduces the risk, but does not eliminate it. nothing eliminate all risks. > But for most applications, you must have the write cache off, > and you need queuing (e.g. TCQ or NCQ) for performance. If > you have queuing, there is no need to turn the write cache > on. did you tested the above claim? i have SATA drives everywhere, all in ahci mode, all with NCQ active. > It is inexcusable that FreeBSD defaults to leaving the write cache on > for SATA & PATA drives. At least the admin can easily fix this by > adding hw.ata.wc=0 to /boot/loader.conf. The bigger problem is that > FreeBSD does not support queuing on all controllers that support it. i must be happy as i never had a case of not seeing adaX: Command Queueing enabled on my machines. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 20:29:10 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 01B7270 for ; Fri, 18 Jan 2013 20:29:10 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm24-vm7.bullet.mail.gq1.yahoo.com (nm24-vm7.bullet.mail.gq1.yahoo.com [98.136.217.102]) by mx1.freebsd.org (Postfix) with ESMTP id AF2A565A for ; Fri, 18 Jan 2013 20:29:09 +0000 (UTC) Received: from [98.137.12.174] by nm24.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jan 2013 20:22:28 -0000 Received: from [98.136.185.40] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 18 Jan 2013 20:22:28 -0000 Received: from [127.0.0.1] by smtp101.mail.gq1.yahoo.com with NNFMP; 18 Jan 2013 20:22:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1358540548; bh=J5LrRcDuosRW4/BRdI9bVlOADTipuQlopLr7OlQiXn0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=n/k+MiKUgZQINb6Kpllhvc8Objzgveir/DioHdKVKxyqD9Y8bGc1GRH2waIgtZYXzVUdHctIn+TsFLiP19Srdm9FhT7B+LKM/s2wi0Y54q0+stUhNQWcpLr890fxQExFM4E026U6wqcZyqUZSBpGmZ+DvSOKVcEegDL5ZkscVGY= X-Yahoo-Newman-Id: 575620.47804.bm@smtp101.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: I7smv_sVM1mxLra3HhZ3Kp9aJx.w_a4ML05TZwhzXXovlu6 URbcTq5uTe4kOiqXnuMAk_MlDan4Yghuo1WLj3G7KljrRWxoNFD0T5PrXTYQ 7ui8H9xgLhi6BCCvtRRNySCC4MXR.OSKYhTM4MqaD2ointz1nQw9PpwtjkB5 evqmib0aLJD7jutGtsjcwYNmH_DE8fFo_3y2LjSKfTdq2ZrJl8CHEfvBFhRr K2Br_mMLFF2P8qLnYdypkps6BLF.T8lQb5YKXjlZt7.JjIb2CXvXg5Sc.AX5 blZhanX.PUrzKuZwrMLyi5rwxcIYrYlvaqdGlJY5G6rWNQjkKFT0k56Nzluk Lw_8smlCTmhNZ8T5LOuZ..58Vm.jn6mR6YYe6kOHojqiaO1Ar_wb6cQwRGh8 Cwzn_qyfASa9pZJ_4dW1gpniIXh40ceTTCUq_jKr3.AhOXvyQoFYJvP0MLTu 7MGACUSIgoN1YQu8zQQ70uHRg3t3YyofeMVnznhSGhm0Fvm_iZg4- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Received: from [10.64.24.66] (scott4long@69.53.237.126 with plain) by smtp101.mail.gq1.yahoo.com with SMTP; 18 Jan 2013 12:22:28 -0800 PST Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: IBM blade server abysmal disk write performances From: Scott Long In-Reply-To: Date: Fri, 18 Jan 2013 13:22:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> References: To: Dieter BSD X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Fri, 18 Jan 2013 21:16:57 +0000 Cc: freebsd-hackers@freebsd.org, gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 20:29:10 -0000 On Jan 18, 2013, at 1:12 PM, Dieter BSD wrote: > It is inexcusable that FreeBSD defaults to leaving the write cache on > for SATA & PATA drives. This was completely driven by the need to satisfy idiotic benchmarkers, tech writers, and system administrators. It was a huge deal for FreeBSD 4.4, IIRC. It had been silently enabled it, we turned it off, released 4.4, and then got murdered in the press for being "slow". If I had my way, the WC would be off, everyone would be using SAS, and anyone who enabled SATA WC or complained about I/O slowness would be forced into Siberian salt mines for the remainder of their lives. > At least the admin can easily fix this by > adding hw.ata.wc=0 to /boot/loader.conf. The bigger problem is that > FreeBSD does not support queuing on all controllers that support it. > Not something that admins can fix, and inexcusable for an OS that > claims to care about performance. You keep saying this, but I'm unclear on what you mean. Can you explain? Scott From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 21:18:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 43C4562C; Fri, 18 Jan 2013 21:18:15 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id A13F287D; Fri, 18 Jan 2013 21:18:14 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0ILIBFE001484; Fri, 18 Jan 2013 22:18:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0ILIB3f001481; Fri, 18 Jan 2013 22:18:11 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 18 Jan 2013 22:18:11 +0100 (CET) From: Wojciech Puchar To: Scott Long Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> Message-ID: References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 18 Jan 2013 22:18:11 +0100 (CET) Cc: freebsd-hackers@freebsd.org, Dieter BSD , gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:18:15 -0000 > and anyone who enabled SATA WC or complained about I/O slowness > would be forced into Siberian salt mines for the remainder of their lives. so reserve a place for me there. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 21:24:51 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35FA07F8; Fri, 18 Jan 2013 21:24:51 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 9532D8BA; Fri, 18 Jan 2013 21:24:50 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id r0ILOn8V014004; Fri, 18 Jan 2013 14:24:50 -0700 (MST) (envelope-from ian@FreeBSD.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r0ILOljh008194; Fri, 18 Jan 2013 14:24:47 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: IBM blade server abysmal disk write performances From: Ian Lepore To: Wojciech Puchar In-Reply-To: References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jan 2013 14:24:47 -0700 Message-ID: <1358544287.32417.251.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Scott Long , freebsd-hackers@FreeBSD.org, Dieter BSD , scottl@FreeBSD.org, gibbs@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:24:51 -0000 On Fri, 2013-01-18 at 22:18 +0100, Wojciech Puchar wrote: > > and anyone who enabled SATA WC or complained about I/O slowness > > would be forced into Siberian salt mines for the remainder of their lives. > > so reserve a place for me there. Yeah, me too. I prefer to go for all-out performance with separate risk mitigation strategies. I wouldn't set up a client datacenter that way, but it's wholly appropriate for what I do with this machine. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 21:50:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB8072A3 for ; Fri, 18 Jan 2013 21:50:35 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4873D9A2 for ; Fri, 18 Jan 2013 21:50:34 +0000 (UTC) Received: from server.rulingia.com (c220-239-253-186.belrs5.nsw.optusnet.com.au [220.239.253.186]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r0ILoXZq047371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 19 Jan 2013 08:50:33 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r0ILoSTA064980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jan 2013 08:50:28 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r0ILoRKa064979; Sat, 19 Jan 2013 08:50:27 +1100 (EST) (envelope-from peter) Date: Sat, 19 Jan 2013 08:50:27 +1100 From: Peter Jeremy To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances Message-ID: <20130118215027.GN77852@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zbGR4y+acU1DwHSi" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:50:35 -0000 --zbGR4y+acU1DwHSi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Jan-18 12:12:11 -0800, Dieter BSD wrote: >adding hw.ata.wc=3D0 to /boot/loader.conf. The bigger problem is that >FreeBSD does not support queuing on all controllers that support it. >Not something that admins can fix, and inexcusable for an OS that >claims to care about performance. Apart from continuous whinging and whining on mailing lists, what have you done to add support for queuing? --=20 Peter Jeremy --zbGR4y+acU1DwHSi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlD5w6MACgkQ/opHv/APuIfDnQCgvdgvgg5eEhRz/i6kcAre27nF RD0AoIrekOiX6wmxkFUyT+PWLXojlx99 =IhEV -----END PGP SIGNATURE----- --zbGR4y+acU1DwHSi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 21:58:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 34E9756B for ; Fri, 18 Jan 2013 21:58:58 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E80A1A06 for ; Fri, 18 Jan 2013 21:58:57 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id u8so1883054iag.31 for ; Fri, 18 Jan 2013 13:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XdrpOqpTCsstLxtI0mAw7/1is9pU0w7nesKd4m0utZ0=; b=Qk70mwgUGYjhzo1Nudp+FuV5KlGWBy1usM1O6mK/CLdGFjwEpg/H/zeYm8M234UiY+ KQpqN9jSzMESh5TGeZkNA/Zq9ZI3/ue7CLc4H795aVPCIpQJqhNCrl91/3s9QvXVmGh1 JbF3Y/uQ33vocsNd+5/7nid7OTNpP1Ow3tB9yh9Itdkm3/H6kVuaOQD/998vn1sKzxX2 mAegult4jjO/hU486cVNSLhPAn3ZRD1cJN1bTOBskdLKUwfSImU+Ag1cjwcqrV+khvby SkCb7UrEiFGY2IUFzKlYrpc4IRCTLM/O2HD94nWooqQP7gIL/IiRlkrvxnC3OpDNIZif IzyA== X-Received: by 10.50.163.104 with SMTP id yh8mr3302744igb.112.1358546337662; Fri, 18 Jan 2013 13:58:57 -0800 (PST) Received: from [10.0.0.131] ([24.225.136.71]) by mx.google.com with ESMTPS id df6sm2237395igb.15.2013.01.18.13.58.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 13:58:56 -0800 (PST) Message-ID: <50F9C597.7010608@gmail.com> Date: Fri, 18 Jan 2013 16:58:47 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mark Felder Subject: Re: IBM blade server abysmal disk write performances References: <50F87741.4030201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 18 Jan 2013 22:19:42 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 21:58:58 -0000 On 18/01/2013 10:16 AM, Mark Felder wrote: > On Thu, 17 Jan 2013 16:12:17 -0600, Karim Fodil-Lemelin > wrote: > >> "SAS controllers may connect to SATA devices, either directly >> connected using native SATA protocol or through SAS expanders using >> SATA Tunneled Protocol (STP)." >> The systems is currently put in place using SATA instead of SAS >> although its using the same interface and backplane connectors and >> the drives (SATA) show as da0 in BSD _but_ with the SATA drive we get >> *much* better performances. I am thinking that something fancy in >> that SAS drive is not being handled correctly by the FreeBSD driver. >> I am planning to revisit the SAS drive issue at a later point >> (sometimes next week). > > Your SATA drives are connected directly not with an interposer such as > the LSISS9252, correct? If so, this might be the cause of your > problems. Mixing SAS and SATA drives is known to cause serious > performance issues for almost every > JBOD/controller/expander/what-have-you. Change your configuration so > there is only one protocol being spoken on the bus (SAS) by putting > your SATA drives behind interposers which translate SAS to SATA just > before the disk. This will solve many problems. Not sure what you mean by this but isn't the mpt detecting an interposer in this line: mpt0: port 0x1000-0x10ff mem 0x99910000-0x99913fff,0x99900000-0x9990ffff irq 28 at device 0.0 on pci11 mpt0: MPI Version=1.5.20.0 mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) Also please not SATA speed in that same hardware setup works just fine. In any case I will have a look. Thanks, Karim. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 22:42:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5DB0D547 for ; Fri, 18 Jan 2013 22:42:58 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 2982CB4B for ; Fri, 18 Jan 2013 22:42:57 +0000 (UTC) Received: from [192.168.1.227] (108-85-197-34.lightspeed.irvnca.sbcglobal.net [108.85.197.34]) (authenticated bits=0) by ns1.feral.com (8.14.5/8.14.4) with ESMTP id r0IMgul8054994 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 18 Jan 2013 14:42:57 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <50F9CFEB.5060302@feral.com> Date: Fri, 18 Jan 2013 14:42:51 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> In-Reply-To: <1358544287.32417.251.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Fri, 18 Jan 2013 14:42:57 -0800 (PST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matt Jacob List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 22:42:58 -0000 This is all turning into a bikeshed discussion. As far as I can tell, the basic original question was why a *SAS* (not a SATA) drive was not performing as well as expected based upon experiences with Linux. I still don't know whether reads or writes were being used for dd. This morning, I ran a fio test with a single threaded read component and a multithreaded write component to see if there were differences. All I had connected to my MPT system were ATA drives (Seagate 500GBs) and I'm remote now and won't be back until Sunday to put one of my 'good' SAS drives (140 GB Seagates, i.e., real SAS 15K RPM drives, not "fat SATA" bs drives). The numbers were pretty much the same for both FreeBSD and Linux. In fact, FreeBSD was slightly faster. I won't report the exact numbers right now, but only mention this as a piece of information that at least in my case the differences between the OS platform involved is negligible. This would, at least in my case, rule out issues based upon different platform access methods and different drivers. All of this other discussion, about WCE and what not is nice, but for all intents and purposes it serves could be moved to *-advocacy. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 22:45:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E05063E for ; Fri, 18 Jan 2013 22:45:17 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id DFF01B5E for ; Fri, 18 Jan 2013 22:45:16 +0000 (UTC) Received: from [192.168.1.227] (108-85-197-34.lightspeed.irvnca.sbcglobal.net [108.85.197.34]) (authenticated bits=0) by ns1.feral.com (8.14.5/8.14.4) with ESMTP id r0IMjFU7055020 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 18 Jan 2013 14:45:16 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <50F9D076.7000404@feral.com> Date: Fri, 18 Jan 2013 14:45:10 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: <50F87741.4030201@gmail.com> <50F9C597.7010608@gmail.com> In-Reply-To: <50F9C597.7010608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Fri, 18 Jan 2013 14:45:16 -0800 (PST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Matt Jacob List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 22:45:17 -0000 > > mpt0: port 0x1000-0x10ff mem > 0x99910000-0x99913fff,0x99900000-0x9990ffff irq 28 at device 0.0 on pci11 > mpt0: MPI Version=1.5.20.0 > mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) > mpt0: 0 Active Volumes (2 Max) > mpt0: 0 Hidden Drive Members (14 Max) Ah. Historically IBM systems (the 335, for one) have been very slow with the Integrated Raid software, at least on FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 00:15:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 243A4570; Sat, 19 Jan 2013 00:15:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) by mx1.freebsd.org (Postfix) with ESMTP id 03A97F43; Sat, 19 Jan 2013 00:15:55 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4EAE21ECC9; Fri, 18 Jan 2013 16:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1358554554; bh=u2OIa1sV+eGYu9uRYMHonHMMerbv1PYN4ErCPDSzDUA=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=sXFckvIHK/zmRBnUPZj2ZUK6nOKdcpZfAd0Sv7baOy/wKmDnid6eTGenCY0kz9YHh jBriiI2hOQtwNjdVTmoHtCmQkXWMVUSf0b4Qv9CrqHX1Ngeh2uuxBuUcmc5B5yODWl 4V11gTBA0pTboi2CkmPijBrB+hAglPl3GxmZ3bYI= Message-ID: <50F9E5B9.6020701@delphij.net> Date: Fri, 18 Jan 2013 16:15:53 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing grep -D skip References: <50F8B491.8090303@freebsd.org> <201301181139.00910.jhb@freebsd.org> In-Reply-To: <201301181139.00910.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:15:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/18/13 08:39, John Baldwin wrote: I (disclaimer: not bsdgrep person) have just tested that bsdgrep handle this case just fine. The non-blocking part is required to make the code function, otherwise the system will block on open() if fifo don't have another opener. I'd say "Yes" for this p Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJQ+eW5AAoJEG80Jeu8UPuzB3IH/RmhJionoEWRtczBy2ccA8sl XG1OIvSR60vWNFAGooOF2I66J8xF0/+f/4xDwN3C56kIweN3XgvxSmOCCM3aUab3 eaAdOIoWAkNb3r4iMxFCJNo6YKuiLTiw8vEdcqjXsqrHzzAMtk81jqSpw0ZkVJM2 upPWF9EItlyKDSOfLCVZiL9qxUxppV+xTpVpMd1F/ud7cQMBaAiU2/pyOgcZDLet GVp4dninbxn3+YN7DU/yvjBnhWWVCrHfbOl5C6zNgrfzfLDyxrP+G67DHCFF9VnU 1l31FOXdd6ThChxfiH3F6QZ7KL0ncDd1pH+qvaoQo7KZBq6jEoiwplaq6qKP4xk= =zQj9 -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 00:16:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87B79573; Sat, 19 Jan 2013 00:16:02 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 643A5F44; Sat, 19 Jan 2013 00:16:02 +0000 (UTC) Received: from epsilon.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 4EA131ECC8; Fri, 18 Jan 2013 16:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1358554555; bh=B0QfL/5KgTS/gBdStHsaUwjmXvaqYeqlqhes2IzzPC4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=KOYgwet74QYlPNlod+JiEoN1pDkbc5KfZQ88vMHc3eTCZedNExJeaoVyPU5Z9lBb1 X8XQyzcAwNAvYOlKZZ6Ws+Tqzvk2KUTJT30gr6IRSw4DhrwTo3SYL05ioA1gVtfoCv Q/PpNd305609huBeyEOYe26PbdbXYbnxbL6qrgnc= Message-ID: <50F9E5B9.1050402@delphij.net> Date: Fri, 18 Jan 2013 16:15:53 -0800 From: Xin Li Organization: The FreeBSD Project MIME-Version: 1.0 To: John Baldwin Subject: Re: Fixing grep -D skip References: <50F8B491.8090303@freebsd.org> <201301181139.00910.jhb@freebsd.org> In-Reply-To: <201301181139.00910.jhb@freebsd.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, David Xu X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:16:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/18/13 08:39, John Baldwin wrote: > On Thursday, January 17, 2013 9:33:53 pm David Xu wrote: >> I am trying to fix a bug in GNU grep, the bug is if you want to >> skip FIFO file, it will not work, for example: >> >> grep -D skip aaa . >> >> it will be stucked on a FIFO file. >> >> Here is the patch: >> http://people.freebsd.org/~davidxu/patch/grep.c.diff2 >> >> Is it fine to be committed ? > > I think the first part definitely looks fine. My guess is the > non-blocking change is als probably fine, but that should be run > by the bsdgrep person at least. I (disclaimer: not bsdgrep person) have just tested that bsdgrep handle this case just fine. The non-blocking part is required to make the code function, otherwise the system will block on open() if fifo don't have another opener. I'd say "Yes" for this p Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die a -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJQ+eW5AAoJEG80Jeu8UPuzaPkH/RPnvBg5pDPxmbSXWF3T22s3 XTPNfDns416g6dqig+E+YOhamu+Pz8xFC6JCu3DzPbNcb+OGRh14LBFeZQ6xn648 yxn1j0Y2ZsmjoppMAWg+wuwLtOYX0pK69zZzOxQMepBeA/rkA26hJA/3j6VTPu/X hLFP+bRy+wt8Ni39PuSrBywuPmwg82de+Fuf8WVVVwXgXHnK+yc/Pb1JWgiU6kzz r1tyCAh2rXcM4mg++LUoeYZZhrLuxWKKPrXkzGSbz7NSPXJccwf5rx/ZPB2EysVv Z/CA6wS2jqsOUbyelM01jtvrY6Q6llLIIEc3aGPcjYZbqy/B0VLwyGnR+rElKBo= =M7oI -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 00:48:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1799612F; Sat, 19 Jan 2013 00:48:11 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id B5BAAEA; Sat, 19 Jan 2013 00:48:10 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id c10so7004799ieb.25 for ; Fri, 18 Jan 2013 16:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=bNZTILOqSDrmlZVUlbXQriwObkgWPL614/z0YITuooo=; b=WCuD/zIIG96uPmWpMADJEj6hOnI4yRgQR5tcygU84nKdNh5eFBJhFZKNywSHSpPfnN 27ZLMJV1GQHOg5pzz2H56+CyFYsoRiUTf+2JceKPbqM66Vt/4BRsmqvvbkUDZnYoYu4u S6UhNYpvOsEf6Gd7rXwQIBuVrceiOf8/qgJW4gObvcbkge0ehbm931scQsUxADj3iezm PTdN+q878URYEJAyXtTERAq3RyEHuU/zWjyjf2XDHFBBEKYFo6OhdKuWerQnXBldI5xc 9pXAVOX7c5gVLZVsfb2QJeDydxDRCq6DPkrB7BP9J06jQhVzDt1W2bPX9eOLQ/0BxbM4 KbSw== MIME-Version: 1.0 X-Received: by 10.42.153.70 with SMTP id l6mr7395923icw.50.1358556490296; Fri, 18 Jan 2013 16:48:10 -0800 (PST) Received: by 10.64.107.196 with HTTP; Fri, 18 Jan 2013 16:48:10 -0800 (PST) Date: Fri, 18 Jan 2013 16:48:10 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 00:48:11 -0000 Scott writes: > If I had my way, the WC would be off, everyone would be using SAS, > and anyone who enabled SATA WC or complained about I/O slowness > would be forced into Siberian salt mines for the remainder of their lives. Actually, If you are running SAS, having SATA WC on or off wouldn't matter, it would be SCSI's WC you'd care about. :-) >> The bigger problem is that >> FreeBSD does not support queuing on all controllers that support it. >> Not something that admins can fix, and inexcusable for an OS that >> claims to care about performance. > > You keep saying this, but I'm unclear on what you mean. Can you > explain? For most applications you need the write cache to be off. Having the write cache off is fine as long as you have queuing. But with the write cache off, if you don't have queuing, performance sucks. Like getting only 6% of the performance you should be getting. Some of the early SATA controllers didn't have NCQ. Knowing that queuing was very important, I made sure to choose a mainboard with NCQ, giving up other useful features to get it. But FreeBSD does not support NCQ on the nforce4-ultra's SATA controllers. Even the sad joke of an OS Linux has had NCQ on nforce4 since Oct 2006. But Linux is such crap it is unusable. Linux is slowly improving, but I don't expect to live long enough to see it become usable. Seriously. I've tried it several times but I have completely given up on it. Anyway, even after all these years the supposedly performance oriented FreeBSD still does not support NCQ on nforce4, which isn't some obscure chip. they sold a lot them. I've added 3 additional SATA controllers on expansion cards, and FreeBSD supports NCQ on them, so the slow controllers limited by PCIe-x1 have much better write performance than the much faster controllers in the chipset with all the bandwidth they need. I can't add more controllers, there aren't any free slots. The nforce will remain in service for years, aside from the monetary cost, silicon has a huge amount of environmental cost: embedded energy, water, pollution, etc. And there are a lot of them. Wojciech writes: >> That is incorrect. A UPS reduces the risk, but does not eliminate it. > > nothing eliminate all risks. Turning the write cache off eliminates the risk of having the write cache on. Yes you can still lose data for other reasons. Backups are still a good idea. >> But for most applications, you must have the write cache off, >> and you need queuing (e.g. TCQ or NCQ) for performance. If >> you have queuing, there is no need to turn the write cache >> on. > > did you tested the above claim? i have SATA drives everywhere, all in ahci > mode, all with NCQ active. Yes, turn the write cache off and NCQ will give you the performance. As long as you have queuing you can have the best of both worlds. Which is why Karim's problem is so odd. Driver says there is queuing, but performance (1 write per rev) looks exactly like there is no queuing. Maybe there is something else that causes only 1 write per rev but I don't know what that might be. Peter writes: > Apart from continuous whinging and whining on mailing lists, what have > you done to add support for queuing? Submitted PR, it was closed without being fixed. Looked at code, but Greek to me, even though I have successfully modified a BSD based device driver in the past giving major performance improvement. If I were a C-level exec of a Fortune 500 company I'd just hire some device driver wizard. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 18 23:32:53 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A341934; Fri, 18 Jan 2013 23:32:53 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECC2E08; Fri, 18 Jan 2013 23:32:53 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so3183084iec.2 for ; Fri, 18 Jan 2013 15:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/2iKFgdXoaUaS36OnHTe7YFbD2qoisU1USH1YdS9uWg=; b=W8RmK6g/mydXTrzaRpcNYNSzJX1DGmm48f05JdS7tqJnBVKQKhChif/2aZVb0LWVta 7zMjRuBJcR584CoI47ZjpOaDSzLLwpIyqM7/NnRTCzH5qfhmqzh/3vhSeVSiTHUL7zmt KvFJFenZ2figmX6E7y76qhkvf1vVrHwOL5Rt/ubOeFzxVsrn2oNtTaLmQcOxs0re4+10 PM3RmGaZecFoiwzXNr26XjfEbicfyT5617lWPl+wv1GLEwjCPr6BJtuZssORD6BSGyrV yeCTF+ygd+xGwP+elYy9i5RykiQjgt+TRuChhW2Z2pYdKO/r0JMFGEvXNq42qKEG80Nl ONXQ== X-Received: by 10.50.190.199 with SMTP id gs7mr3496466igc.89.1358551972683; Fri, 18 Jan 2013 15:32:52 -0800 (PST) Received: from [10.0.0.131] ([24.225.136.71]) by mx.google.com with ESMTPS id eo7sm3192101igc.12.2013.01.18.15.32.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jan 2013 15:32:51 -0800 (PST) Message-ID: <50F9DB9A.9050303@gmail.com> Date: Fri, 18 Jan 2013 18:32:42 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: IBM blade server abysmal disk write performances References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> In-Reply-To: <50F9CFEB.5060302@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 19 Jan 2013 02:33:18 +0000 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 23:32:53 -0000 On 18/01/2013 5:42 PM, Matthew Jacob wrote: > This is all turning into a bikeshed discussion. As far as I can tell, > the basic original question was why a *SAS* (not a SATA) drive was not > performing as well as expected based upon experiences with Linux. I > still don't know whether reads or writes were being used for dd. > > This morning, I ran a fio test with a single threaded read component > and a multithreaded write component to see if there were differences. > All I had connected to my MPT system were ATA drives (Seagate 500GBs) > and I'm remote now and won't be back until Sunday to put one of my > 'good' SAS drives (140 GB Seagates, i.e., real SAS 15K RPM drives, not > "fat SATA" bs drives). > > The numbers were pretty much the same for both FreeBSD and Linux. In > fact, FreeBSD was slightly faster. I won't report the exact numbers > right now, but only mention this as a piece of information that at > least in my case the differences between the OS platform involved is > negligible. This would, at least in my case, rule out issues based > upon different platform access methods and different drivers. > > All of this other discussion, about WCE and what not is nice, but for > all intents and purposes it serves could be moved to *-advocacy. > Thanks for the clarifications! I did mention at some point those were write speeds and reads were just fine and those were either writes to the filesystem or direct access (only on SAS again). Here is what I am planning to do next week when I get the chance: 0) I plan on focusing on the SAS driver tests _only_ since SATA is working as expected so nothing to report there. 1) Look carefully at how the drives are physically connected. Although it feels like if the SATA works fine the SAS should also but I'll check anyway. 2) Boot verbose with "boot -v" and send the dmesg output. mpt driver might give us a clue. 3) Run gstat -abc in a loop for the test duration. Although I would think ctlstat(8) might be more interesting here so I'll run it too for good measure :). Please note that in all tests write caching was enabled as I think this is the default with FBSD 9.1 GENERIC but I'll confirm this with camcontrol(8). I've also seen quite a lot of 'quirks' for tagged command queuing in the source code (/sys/cam/scsi/scps_xtp.c) but a particular one got my attention (thanks to whomever writes good comments in source code :) : /* * Slow when tagged queueing is enabled. Write performance * steadily drops off with more and more concurrent * transactions. Best sequential write performance with * tagged queueing turned off and write caching turned on. * * PR: kern/10398 * Submitted by: Hideaki Okada * Drive: DCAS-34330 w/ "S65A" firmware. * * The drive with the problem had the "S65A" firmware * revision, and has also been reported (by Stephen J. * Roznowski ) for a drive with the "S61A" * firmware revision. * * Although no one has reported problems with the 2 gig * version of the DCAS drive, the assumption is that it * has the same problems as the 4 gig version. Therefore * this quirk entries disables tagged queueing for all * DCAS drives. */ { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DCAS*", "*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 So I looked at the kern/10398 pr and got some feeling of 'deja vu' although the original problem was on FreeBSD 3.1 so its most likely not that but I though I would mention it. The issue described is awfully familiar. Basically the SAS drive (scsi back then) is slow on writes but fast on reads with dd. Could be a coincidence or a ghost from the past who knows... Cheers, Karim. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 03:11:59 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EDE7E567; Sat, 19 Jan 2013 03:11:59 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id 868E77D5; Sat, 19 Jan 2013 03:11:59 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c12so7089068ieb.23 for ; Fri, 18 Jan 2013 19:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=Duinsy3+8whC5WfxHaKiVklysqaeST/YFPEi1PShfec=; b=cIRFzsEeTspTj3xr5eLSzDqF4fQkSkXY2DwNa978CZzHhDk5g98x34ZmRG7B7xm9oO Je9Z7Xx3YcQC/KaZLKlZu+lETAsj+5//AitEkZik1rO620Qmz9Dak5KCdv08iNmQPVdW gl9EWHLAq/HpzTS3SQD7dDXPugiTn+5IZunp7cwVnbC8PaxhRkML+jnpITP12C4klZXr yfcuAQ0TJiNIijxEv+wzqMzmgeZSzKilPrsA9y3f/gNzZ5FZr77aIfxTqT7sj+U9mlxd OvAs3GkeUO18Nf34skaxpXX0G/2q0M6KuqkKBDGHxzap5bu6Ys+mq15aACL+jetSx8J+ xREA== MIME-Version: 1.0 X-Received: by 10.50.151.211 with SMTP id us19mr3844362igb.84.1358565113827; Fri, 18 Jan 2013 19:11:53 -0800 (PST) Received: by 10.64.107.196 with HTTP; Fri, 18 Jan 2013 19:11:53 -0800 (PST) Date: Fri, 18 Jan 2013 19:11:53 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 03:12:00 -0000 Matthew writes: > There is also no information in the original email as to which direction > the I/O was being sent. In one of the followups, Karim reported: # dd if=/dev/zero of=foo count=10 bs=1024000 10+0 records in 10+0 records out 10240000 bytes transferred in 19.615134 secs (522046 bytes/sec) 522 KB/s is pathetic. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 03:17:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4FC64875 for ; Sat, 19 Jan 2013 03:17:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0C51A803 for ; Sat, 19 Jan 2013 03:17:10 +0000 (UTC) Received: from jre-mbp-2.int.fusionio.com ([216.51.42.66]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r0J3Gsn6056042 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 18 Jan 2013 19:16:59 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50FA1021.6000303@freebsd.org> Date: Fri, 18 Jan 2013 20:16:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Trent Nelson Subject: Re: Getting the current thread ID without a syscall? References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> <20130115214332.GE2522@kib.kiev.ua> <50F5D82C.7070400@mu.org> <1358289221.32417.129.camel@revolution.hippie.lan> <20130115230330.GA53211@snakebite.org> In-Reply-To: <20130115230330.GA53211@snakebite.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Ian Lepore , Alfred Perlstein , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 03:17:11 -0000 On 1/15/13 4:03 PM, Trent Nelson wrote: > On Tue, Jan 15, 2013 at 02:33:41PM -0800, Ian Lepore wrote: >> On Tue, 2013-01-15 at 14:29 -0800, Alfred Perlstein wrote: >>> On 1/15/13 1:43 PM, Konstantin Belousov wrote: >>>> On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: >>>>> Luckily it's for an open source project (Python), so recompilation >>>>> isn't a big deal. (I also check the intrinsic result versus the >>>>> syscall result during startup to verify the same ID is returned, >>>>> falling back to the syscall by default.) >>>> For you, may be. For your users, it definitely will be a problem. >>>> And worse, the problem will be blamed on the operating system and not >>>> to the broken application. >>>> >>> Anything we can do to avoid this would be best. >>> >>> The reason is that we are still dealing with an "optimization" that perl >>> did, it reached inside of the opaque struct FILE to "do nasty things". >>> Now it is very difficult for us to fix "struct FILE". >>> >>> We are still paying for this years later. >>> >>> Any way we can make this a supported interface? >>> >>> -Alfred >> Re-reading the original question, I've got to ask why pthread_self() >> isn't the right answer? The requirement wasn't "I need to know what the >> OS calls me" it was "I need a unique ID per thread within a process." > The identity check is performed hundreds of times per second. The > overhead of (Py_MainThreadId == __readgsdword(0x48) ? A() : B()) is > negligible -- I can't say the same for a system/function call. > > (I'm experimenting with an idea I had to parallelize Python such > that it can exploit all cores without impeding the performance > of normal single-threaded execution (like previous-GIL-removal > attempts and STM). It's very promising so far -- presuming we > can get the current thread ID in a couple of instructions. If > not, single-threaded performance suffers too much.) TLS? > > Trent. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 03:28:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 337CDC1A; Sat, 19 Jan 2013 03:28:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 45C54858; Sat, 19 Jan 2013 03:28:54 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so3500177wib.13 for ; Fri, 18 Jan 2013 19:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D30pTAiFqKTRb7UYULFy2xrLmmOn78B04uAzzDb1lkA=; b=Apre06AjzEYrqNaFJBge9UVaZNfkdgKnBZntj+4VLfORVoII8RugtPtwq7qZzQ6RGe 0mwMEwBL1Vsd8yKVMCNjg8GwGE/4++AQUsD2CMzsq2xfmX/IZ0T8kCILWAF43KGccrnZ XlPd9hTOg3zx8A33BMxxZQdGWDTaC7qKvVIobGGvH5uHNg9sVKDVIc/f3mtC2d5/yyOy DUt9Eru3p4dkGnlvEfBB4dQw+V7G7DIxIxY139B/XCQ3L/8BHB7z6c+6z+GRINdSURdW sjhvikSc8kckX22ZhU8zPCfFj3uCJsdMetIEYOaLadmBqhLo2wgDlt5ArECeFKxih2Lf 4hVQ== MIME-Version: 1.0 X-Received: by 10.180.100.163 with SMTP id ez3mr6533009wib.32.1358566128659; Fri, 18 Jan 2013 19:28:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 18 Jan 2013 19:28:48 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Jan 2013 19:28:48 -0800 X-Google-Sender-Auth: Jbb1zQDobbAq8z34Nw8GlBtQUbk Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Adrian Chadd To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 03:28:56 -0000 On 18 January 2013 19:11, Dieter BSD wrote: > Matthew writes: >> There is also no information in the original email as to which direction >> the I/O was being sent. > > In one of the followups, Karim reported: > # dd if=/dev/zero of=foo count=10 bs=1024000 > 10+0 records in > 10+0 records out > 10240000 bytes transferred in 19.615134 secs (522046 bytes/sec) > > 522 KB/s is pathetic. When this is running, use gstat and see exactly how many IOPS/sec there are and the average io size is. Yes, 522kbytes/sec is really pathetic, but there's a lot of potential reasons for that. adrian From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 15:06:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 27B63221; Sat, 19 Jan 2013 15:06:09 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7E008F58; Sat, 19 Jan 2013 15:06:08 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0JF679R004339; Sat, 19 Jan 2013 16:06:07 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0JF673j004336; Sat, 19 Jan 2013 16:06:07 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 19 Jan 2013 16:06:07 +0100 (CET) From: Wojciech Puchar To: Dieter BSD Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 19 Jan 2013 16:06:07 +0100 (CET) Cc: freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:06:09 -0000 > Turning the write cache off eliminates the risk of having the write cache > on. this sentence sounds like "not having a car eliminates a risks of driving". From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 15:13:05 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C64D851C; Sat, 19 Jan 2013 15:13:05 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 1106BFBD; Sat, 19 Jan 2013 15:13:04 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c13so2266747eek.0 for ; Sat, 19 Jan 2013 07:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=AknV0tjCXexVs389uWgJMgdZPmGpyEcQAX9YwZdm8P4=; b=XaI0rdgt8FHzwrJooRcySHbjLtWIwFj5mn5O7B+4xGWWssyQ5uaWoOT905tRz5BIUN gr4zPfyZ/7gUgR3WBJvTm1SuwJiLIVKegbwvFrLjQGJz9HZ5BviIEVBjSE+00pj7PcXe pQ1Uo8lFEy3WEStQRdQEKp96N18T9Sn8gtMOwTM/gAOp3rLMxEip/ChsUHavUjNsWkmg +IhLUb2z7se1a3DcJmj5o4wS8d7NsDrfnqpjd44So8af/qhFOznjexQneTPftZnAtT48 O6iorq1RCPyc6fumqJspgnk0xeYZzGtxe4D7KcfZXRGkFDWNre1qcBxKgFD3RZUMo/Wk n/Jw== X-Received: by 10.14.194.195 with SMTP id m43mr39073238een.44.1358608378061; Sat, 19 Jan 2013 07:12:58 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id z8sm12737977eeo.11.2013.01.19.07.12.56 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 19 Jan 2013 07:12:57 -0800 (PST) Sender: Mikolaj Golub Date: Sat, 19 Jan 2013 17:12:54 +0200 From: Mikolaj Golub To: freebsd-hackers@freebsd.org Subject: libprocstat(3): retrieve process command line args and environment Message-ID: <20130119151253.GB88025@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Robert Watson X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:13:05 -0000 Hi, Some time ago Stanislav Sedov suggested to me extending libprocstat(3) with functions to retrieve process command line arguments and environment variables. In the first approach I tried, the newly added functions procstat_getargv/getenvv allocated a buffer of necessary size, stored the values and returned to the caller: http://people.freebsd.org/~trociny/libprocstat.1.patch The problem with this approach was that when I updated procstat(1) to use this interface, I observed noticeable performance degradation (about 30% on systems with MALLOC_PRODUCTION off), due to memory allocation overhead: the original procstat(1) reuses the buffer for all its retrievals. So my second approach was to add internal buffers to struct procstat, which are used by procstat_getargv/getenvv to store values and reused on the subsequent call: http://people.freebsd.org/~trociny/libprocstat.2.patch The drawback of this approach is that a user has to take care and remember that a subsequent call rewrites argument vector obtained from the previous call. On the other hand this is ok for typical use cases while does not add allocation overhead, so I like this approach more. I would like to commit this second patch, if there are no objections or suggestions how to improve the things. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 15:27:54 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8707075C for ; Sat, 19 Jan 2013 15:27:54 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm22-vm7.bullet.mail.ird.yahoo.com (nm22-vm7.bullet.mail.ird.yahoo.com [212.82.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id BF326A6 for ; Sat, 19 Jan 2013 15:27:53 +0000 (UTC) Received: from [212.82.105.244] by nm22.bullet.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 Received: from [217.146.188.172] by tm16.bullet.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 Received: from [127.0.0.1] by smtp140.mail.ird.yahoo.com with NNFMP; 19 Jan 2013 15:27:52 -0000 X-Yahoo-Newman-Id: 276545.61908.bm@smtp140.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 8TgKlNUVM1kP1rLbGWXE6iah7DTlgi3M1ivVIkCi3t2F8S. gQSxEWwK_T9Wauvp33BHiZZP3QA.q1cv15Nt8ca1VG0j8cR9Lb2RAby5zknC yDPX.gwgCtyUdjtkEzsL7D7KybAmcz0lFvldlDRsCbOpSHqOWkhxevB68aE1 bQ_zIvyiGgb7OE.q1Udb4yU_KQ03zvbrkbbBLNGIL5I7QLGz.KSQBIxqlalG cJVklcIx9oAKmrooq1AZCFbGJCJE9RGN9rrLZnLUIQVU7270nHOaVtjiqzkX hzQ.9tll7URh1iILafhK4DaoQZciTvicxyyqkQqw4lGpgzG_LZTgs77_6jiR 9LkXBIPm.igrqF40UdjOcXQMKge2ymaSBhdjvx.jyUxcQJtJhdWoY9ClB_an 3K5uFrWdiIUFkWIJfcWOhRpBb7Uifkg7Lnu_4PpEcMGi6wSl.jQ-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.26] (se@87.158.17.243 with plain) by smtp140.mail.ird.yahoo.com with SMTP; 19 Jan 2013 07:27:52 -0800 PST Message-ID: <50FABB71.6050406@freebsd.org> Date: Sat, 19 Jan 2013 16:27:45 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Karim Fodil-Lemelin Subject: Re: IBM blade server abysmal disk write performances References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> <50F9DB9A.9050303@gmail.com> In-Reply-To: <50F9DB9A.9050303@gmail.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:27:54 -0000 Am 19.01.2013 00:32, schrieb Karim Fodil-Lemelin: > * Although no one has reported problems with the 2 gig > * version of the DCAS drive, the assumption is that it > * has the same problems as the 4 gig version. Therefore > * this quirk entries disables tagged queueing for all > * DCAS drives. > */ > { T_DIRECT, SIP_MEDIA_FIXED, "IBM", "DCAS*", "*" }, > /*quirks*/0, /*mintags*/0, /*maxtags*/0 > > So I looked at the kern/10398 pr and got some feeling of 'deja vu' > although the original problem was on FreeBSD 3.1 so its most likely not > that but I though I would mention it. The issue described is awfully > familiar. Basically the SAS drive (scsi back then) is slow on writes but > fast on reads with dd. Could be a coincidence or a ghost from the past > who knows... I remember those drives from some 20 years ago. Before that time, SCSI and IDE drives were independently developed and SCSI drives offered way better performance and reliability. But at about this time there were SCSI and IDE drives that differed only in their interface electronics. And from that time I and models I remember several SCSI quirks in IBM drives (DCAS and DORS), often with regard to tagged commands. I seem to remember, that drives of that time required the write cache to be enabled to get any speed-up from tagged commands. This was no risk with SCSI drives, since the cache did not make the drives lye about command completion (i.e. the status for the write was only returned when the cached data had been written to disk, independently of the write cache enable). Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 08:27:24 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 669825FF for ; Sat, 19 Jan 2013 08:27:24 +0000 (UTC) (envelope-from abhinavmisra919@gmail.com) Received: from mail-ie0-f196.google.com (mail-ie0-f196.google.com [209.85.223.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2F103EA for ; Sat, 19 Jan 2013 08:27:23 +0000 (UTC) Received: by mail-ie0-f196.google.com with SMTP id k13so2842469iea.3 for ; Sat, 19 Jan 2013 00:27:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ULS3Tv45AU97rnb6lZsEy8VJ6TAjB1Qr1KTiuIn//RM=; b=VBohBEHZgWF+T18kpBHzG1gRolLYKAUwCO4PBsaJpTvaLZqG8DdsSOMnG75x3gZOs5 CcPXyluufzRbFm0z6olowSvG9micWH19Hbr+eo6D6yJxAdNMx4YBX+mHWINZIlOHXJL9 +6KEKk1kc7oL1mEJ8Lspcz78wiz15gWLNn9modWNVODwsUZZAXafU3CpHaJqB9ZNkjm3 3bxtOay5fSkizNRFjYQcNH8oaA7syvV0Lv22pNG14zkAY3gH7/uJIocJ4lyrtqt3bE0N TJKW4xrQInffcUfsteNHuab0R1TTcrtGCeHGN4JpEkinZW02ziiMbtyS4VCBKxoeB6ED igWQ== MIME-Version: 1.0 X-Received: by 10.42.180.65 with SMTP id bt1mr7916940icb.41.1358584043621; Sat, 19 Jan 2013 00:27:23 -0800 (PST) Received: by 10.64.77.101 with HTTP; Sat, 19 Jan 2013 00:27:23 -0800 (PST) Date: Sat, 19 Jan 2013 13:57:23 +0530 Message-ID: Subject: help From: ABHINAV MISRA To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sat, 19 Jan 2013 15:47:51 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 08:27:24 -0000 I am Abhinav, an undergradute from India. i was going through the project idea list of GsoC 2012. i want to take project " unicode support for VI" as my GSoC 2013 project . I am not sure whether this project is completed or not . i know C, python and learning java currently. Please guide me how can i go about this project so that i can bring fruitfull results . thanking you, Abhinav Misra From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 18:32:01 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F24EB1A2; Sat, 19 Jan 2013 18:32:00 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 01556B40; Sat, 19 Jan 2013 18:31:59 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0JIVpHB006050; Sat, 19 Jan 2013 19:31:51 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0JIVpiK006047; Sat, 19 Jan 2013 19:31:51 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sat, 19 Jan 2013 19:31:51 +0100 (CET) From: Wojciech Puchar To: Stefan Esser Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <50FABB71.6050406@freebsd.org> Message-ID: References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> <50F9DB9A.9050303@gmail.com> <50FABB71.6050406@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sat, 19 Jan 2013 19:31:51 +0100 (CET) Cc: Karim Fodil-Lemelin , freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 18:32:01 -0000 > > I remember those drives from some 20 years ago. Before that time, SCSI > and IDE drives were independently developed and SCSI drives offered way yes. 20 years ago it was true. even in 1995, when i had SCSI controller in my 486 and it was great compared to ATA. today SATA and SAS are mostly the same, just protocol are different. the main difference is that SATA is simpler and have less problems. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 22:39:36 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 208167CF; Sat, 19 Jan 2013 22:39:36 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id B8D04284; Sat, 19 Jan 2013 22:39:35 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 9so4209632iec.30 for ; Sat, 19 Jan 2013 14:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=/vhE3+5Vr5jrESFtVkL4Zdt4rq1UIQRvIBFVEh/GuIE=; b=IWrPPZ+js96KjT0ONtxJwqFzIhJLcHOxWt80Dig1gz6pnHpfdR0gzXk4vL3iaKuaFo cm53tpg6U0wD7oWrmA6o2QMChJlBE1APMNkvm3vSaiUfaub/LD9lOmeZX8k+uWhKircX niJVMH/5TxvLH69ND72e+u50ZOxPKOWcC/VZFBnYWHq5If+pVZ/AI7cbJeRMEEFtQ0Cq kQ29m1KexGUfAZ89NReU1fGBDzl39mx5AGpwzMl5HJ8AsMEX2q5Vu/ArxftBRqUZS8dW eXBzTrnxkM6sRQhJbgAXOIu2MVzkiixt2RHhlmI5xBq+w+UhPeVN2yMWuhLksoBZ9kBF d4dA== MIME-Version: 1.0 X-Received: by 10.50.196.138 with SMTP id im10mr5844794igc.83.1358635168975; Sat, 19 Jan 2013 14:39:28 -0800 (PST) Received: by 10.64.107.196 with HTTP; Sat, 19 Jan 2013 14:39:28 -0800 (PST) Date: Sat, 19 Jan 2013 14:39:28 -0800 Message-ID: Subject: Re: IBM blade server abysmal disk write performances From: Dieter BSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: gibbs@FreeBSD.org, scottl@FreeBSD.org, mjacob@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 22:39:36 -0000 Stefan writes: > I seem to remember, that drives of that time required the write cache > to be enabled to get any speed-up from tagged commands. This was no > risk with SCSI drives, since the cache did not make the drives lye > about command completion (i.e. the status for the write was only > returned when the cached data had been written to disk, independently > of the write cache enable). Interesting. Is there a way to tell, other than coming up with some way to actually test it, whether a particular drive waits until the data has been written to non-volatile memory (the platters in conventional disks) before sending the command completion message? I'm having thoughts of putting sensing resistors in the disk's power cable, attaching an oscilloscope, and displaying the timing of data on the data cable along with power usage from seeking. From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 19 23:33:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA72EEA9; Sat, 19 Jan 2013 23:33:58 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id CF6AB3F8; Sat, 19 Jan 2013 23:33:57 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5) with ESMTP id r0JNXr06007890; Sun, 20 Jan 2013 00:33:53 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.5/Submit) with ESMTP id r0JNXqu7007887; Sun, 20 Jan 2013 00:33:52 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 20 Jan 2013 00:33:52 +0100 (CET) From: Wojciech Puchar To: Stefan Esser Subject: Re: IBM blade server abysmal disk write performances In-Reply-To: <50FABB71.6050406@freebsd.org> Message-ID: References: <6C0B86E6-195C-4D35-AE40-3D2F9F6D28FB@yahoo.com> <1358544287.32417.251.camel@revolution.hippie.lan> <50F9CFEB.5060302@feral.com> <50F9DB9A.9050303@gmail.com> <50FABB71.6050406@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 20 Jan 2013 00:33:53 +0100 (CET) Cc: Karim Fodil-Lemelin , freebsd-hackers@freebsd.org, gibbs@freebsd.org, scottl@freebsd.org, mjacob@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 23:33:58 -0000 > to be enabled to get any speed-up from tagged commands. This was no > risk with SCSI drives, since the cache did not make the drives lye i see no correlation between interface type and possibility of lying about command completion.