From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 01:53:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB5C106568B; Sun, 11 Oct 2009 01:53:59 +0000 (UTC) (envelope-from prvs=153544c2be=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 1747D8FC17; Sun, 11 Oct 2009 01:53:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1255225410; x=1255830210; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=0yid1ldt+6v64K47U3XD9 Yp+SivhIAGPpU7rZuqt100=; b=gtPfeQBJeI3WFgenRu+kCpmp19ut92PD1Mle/ hTbnzWjt6gSMyKJvTb5bj5nxxi6sn3tle+rmbVfEDEkf5ULRD7MbVLc7SJxRYO6+ LIC8gnaQP7E98eW4EOVBkZomRKUWPGTbEuGnM2nTKvTXPEIYJ3s6gPHaHOSdZNZE IiDdv0= X-MDAV-Processed: mail1.multiplay.co.uk, Sun, 11 Oct 2009 02:43:30 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008354191.msg; Sun, 11 Oct 2009 02:43:29 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 11 Oct 2009 02:43:29 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=153544c2be=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <261B324A16A2457899A46641FC6A0499@multiplay.co.uk> From: "Steven Hartland" To: "Alex Povolotsky" , , "FreeBSD Stable" , References: <462F15B4.4010201@webmail.sub.ru> Date: Sun, 11 Oct 2009 02:43:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="KOI8-R"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: 6.2-RELEASE does not use second CPU on pentium D X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 01:53:59 -0000 6.2 is really quite old now, does 7.x or even 8.x work? Regards Steve ----- Original Message ----- From: "Alex Povolotsky" > I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 > launched, but I never see any process running on it, and mptable shows ... ================================================ 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-stable@FreeBSD.ORG Sun Oct 11 06:58:12 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77795106566B for ; Sun, 11 Oct 2009 06:58:12 +0000 (UTC) (envelope-from jrhett@netconsonance.com) Received: from mail.netconsonance.com (mail.netconsonance.com [198.207.204.4]) by mx1.freebsd.org (Postfix) with ESMTP id 604208FC22 for ; Sun, 11 Oct 2009 06:58:12 +0000 (UTC) Received: from [172.16.12.13] (c-76-102-113-93.hsd1.ca.comcast.net [76.102.113.93]) (authenticated bits=0) by mail.netconsonance.com (8.14.3/8.14.2) with ESMTP id n9B6bUNG097880 for ; Sat, 10 Oct 2009 23:37:30 -0700 (PDT) (envelope-from jrhett@netconsonance.com) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=3.5 tests=[ALL_TRUSTED=-1.44, AWL=0.007] autolearn=disabled Message-Id: From: Jo Rhett To: freebsd-stable Stable In-Reply-To: <200807151535.m6FFZH4P044840@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 23:37:25 -0700 References: <200807151535.m6FFZH4P044840@lurza.secnetix.de> X-Mailer: Apple Mail (2.936) Cc: Subject: Re: how to get more logging from GEOM? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 06:58:12 -0000 On Jul 15, 2008, at 8:35 AM, Oliver Fromme wrote: > I had exactly the same problems on a machine a few months > ago. It had also been running for about two years, then > started freezing when there was high CPU + disk activity. > > It turned out that the power supply went weak (either the > power supply itself or the voltage regulators on the main- > board). Replacing PS + mainboard solved the problem. I have removed these drives and installed them in another machine and had exactly the same symptoms. I built a new machine fresh with 7.2 (in case it was due to the upgrade process) and installed these ports and experienced the exact same problem. That's why I am here. Physical or localized issues have already been ruled out. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 10:51:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B94106568B for ; Sun, 11 Oct 2009 10:51:15 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 80F588FC12 for ; Sun, 11 Oct 2009 10:51:14 +0000 (UTC) Received: by ewy18 with SMTP id 18so2160308ewy.43 for ; Sun, 11 Oct 2009 03:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :date:message-id:user-agent:mime-version:content-type; bh=Ti4veoh49dCgiDADOQb5DieQz8buZ+R6z1Q6fhV98XM=; b=gtFgG1nyPdOHJ7PotwWQLuRbKdb5fsBsr10EVRKjaIh1zyGMNP6OFaCzOIIGEedNmG oH2LFi9ivyjM1xWwpE89+MXb4Fld0j9PlLiJo28/xQ8UZqLWRgRQm2RguTPcR3hDTvXX Sk4fAEZVCQG7xe6a9xrdDOgAjgTZPTmmpPv08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:date:message-id:user-agent :mime-version:content-type; b=NYoxZbr4wxXPs6Q0a93dsqyOaTO6Jhq6JbXbtb3vFkrcWY0eAbvdBr6z1aGyNQDT/1 rXxwE33kj5F+1QIfv9G2uktku4LeNDqK68WxWrs6H/pUKBWXqhqh3JBZDVW4pNLI/p7B lHxVPqCPk0WjC+wdoaKYzHNIzoRRgLcGuHHqE= Received: by 10.210.3.18 with SMTP id 18mr2636254ebc.80.1255258273511; Sun, 11 Oct 2009 03:51:13 -0700 (PDT) Received: from localhost (vpn-193-138-133-43.customer.onet.com.ua [193.138.133.43]) by mx.google.com with ESMTPS id 10sm1186017eyd.14.2009.10.11.03.51.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Oct 2009 03:51:12 -0700 (PDT) To: freebsd-stable@freebsd.org Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 11 Oct 2009 13:51:09 +0300 Message-ID: <861vla2ogy.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 10:51:15 -0000 Hi, On 8.0-RC1 if you run this command: cat > /dev/null and try to input a long line, the maximum length you can input is 1920 characters. I have investigated a bit how I can increase a tty buffer as this is a problem for me (I have logs with very long lines and I used to copy&past a particular line into input of some script to structure it). According to kern/tty.c:tty_watermarks() the input buffer size is set as ispeed / 5. The default speed is 9600 that is rather low: /usr/include/sys/ttydefaults.h:#define TTYDEF_SPEED (B9600) So to increase the buffer size I need to decrease tty speed. But this does not work: zhuzha:/tmp% stty speed 9600 baud; lflags: echoe echok echoke echoctl iflags: -ixany -imaxbel oflags: tab0 cflags: cs8 parenb eol2 erase status ^@ ^H zhuzha:/tmp% stty ispeed 38400 zhuzha:/tmp% stty speed 9600 baud; lflags: echoe echok echoke echoctl iflags: -ixany -imaxbel oflags: tab0 cflags: cs8 parenb eol2 erase status ^@ ^H I can change tty speed on 7.X but can't on 8.0. I ran this simple dtrace program to see what is going on: tty*:entry /execname == "stty"/ { printf("%s entered; args0-4: %d %d %d %d %d\n", probefunc, arg0, arg1, arg2, arg3, arg4); } tty*:return /execname == "stty"/ { printf("%s returned %d\n", probefunc, arg1); } And here is the relevant part of the output: ttydev_ioctl entered; arguments: 3313875456 2150396948 3363021248 3 3357835264 tty_wait_background entered; arguments: 3354367492 0 3234498062 158 0 tty_wait_background returned 0 tty_ioctl entered; arguments: 3354367488 2150396948 3363021248 3357835264 0 ttydevsw_defioctl entered; arguments: 3354367488 2150396948 3363021248 3357835264 0 ttydevsw_defioctl returned 4294967293 ttydevsw_defparam entered; arguments: 3354367488 3363021248 3363021248 3357835264 0 ttydevsw_defparam returned 0 tty_watermarks entered; arguments: 3354367488 3363021248 3363021248 3357835264 0 ttyinq_setsize entered; arguments: 3354367528 3354367488 1920 0 3875601352 ttyinq_setsize returned 15 ttyoutq_setsize entered; arguments: 3354367572 3354367488 1920 0 3875601352 ttyoutq_setsize returned 3545052638 tty_watermarks returned 858997088 ttydisc_optimize entered; arguments: 3354367488 3363021264 20 3357835264 0 ttydisc_optimize returned 0 tty_ioctl returned 0 ttydev_ioctl returned 0 As you can see, before calling tty_watermarks() and ttyinq_setsize(), ttydevsw_defparam() is called that do only this thing: /* Use a fake baud rate, we're not a real device. */ t->c_ispeed = t->c_ospeed = TTYDEF_SPEED; As a result the speed of terminal is always set to TTYDEF_SPEED and ttyinq_setsize() is always called with size=1920 (TTYDEF_SPEED/5). This all happens in tty_generic_ioctl() in this part: /* * Only call param() when the flags really change. */ if ((t->c_cflag & CIGNORE) == 0 && (tp->t_termios.c_cflag != t->c_cflag || tp->t_termios.c_ispeed != t->c_ispeed || tp->t_termios.c_ospeed != t->c_ospeed)) { error = ttydevsw_param(tp, t); if (error) return (error); /* XXX: CLOCAL? */ tp->t_termios.c_cflag = t->c_cflag & ~CIGNORE; tp->t_termios.c_ispeed = t->c_ispeed; tp->t_termios.c_ospeed = t->c_ospeed; /* Baud rate has changed - update watermarks. */ tty_watermarks(tp); } AFAIR ttydevsw_param() runs tty hooks and ttydevsw_defparam() among them. So you can't change the speed of terminal and the size of input buffer on running system. Only by recompiling the kernel with updated TTYDEF_SPEED. Is this intentional or does it look rather like a bug? -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 10:54:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C1C1065679 for ; Sun, 11 Oct 2009 10:54:07 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id EE3EC8FC15 for ; Sun, 11 Oct 2009 10:54:06 +0000 (UTC) Received: by ewy18 with SMTP id 18so2161245ewy.43 for ; Sun, 11 Oct 2009 03:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=Byq6wHKfZk2LqCPWs6GK8PjZkFX46PMBo6MbjvOI6vo=; b=AdgozaDCkPGKm7GZIwjgzCCfhjKio3lq2sIbiqJ83z6/yl/dLn30vYdMilNGKicUID xjzKeVqlELVPfo5g/a39YX1Wnm+sH+satUuatNIeZJV6yOiEU8P35yfAorgLr1IMNHYI z1Tns39bwLeoQiKQmugPDerjUrJIDo7/oqZGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=XVruQmGeSimuM41U4SVxZqvUInd8pgVe0ZJ/Zz5FUeLZzby3njQzeWXIEqKSJKBcSa pOSdFSzoiQHrUEroeFg6hDoalNCvYE+VR/lte4LjI9iZ5LgLF84RydENCEqxtndZfcEH D7hVPqLBTiJLY1eH4S1QRc4Eq9FXbveISxR0I= Received: by 10.211.161.39 with SMTP id n39mr5713342ebo.29.1255258446106; Sun, 11 Oct 2009 03:54:06 -0700 (PDT) Received: from localhost (vpn-193-138-133-43.customer.onet.com.ua [193.138.133.43]) by mx.google.com with ESMTPS id 10sm1759573eyz.16.2009.10.11.03.54.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Oct 2009 03:54:04 -0700 (PDT) To: freebsd-stable@freebsd.org References: <861vla2ogy.fsf@kopusha.onet> Organization: TOA Ukraine From: Mikolaj Golub Date: Sun, 11 Oct 2009 13:54:02 +0300 In-Reply-To: <861vla2ogy.fsf@kopusha.onet> (Mikolaj Golub's message of "Sun\, 11 Oct 2009 13\:51\:09 +0300") Message-ID: <86ws3219rp.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 10:54:07 -0000 On Sun, 11 Oct 2009 13:51:09 +0300 Mikolaj Golub wrote: MG> So to increase the buffer size I need to decrease tty speed. Sorry, of course I meant "to increase tty speed" :-). -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 14:52:39 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E16C1065692; Sun, 11 Oct 2009 14:52:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8018FC1E; Sun, 11 Oct 2009 14:52:39 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id EC3FA46B09; Sun, 11 Oct 2009 10:52:38 -0400 (EDT) Date: Sun, 11 Oct 2009 15:52:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: freebsd-stable@FreeBSD.ORG, dougb@FreeBSD.ORG In-Reply-To: <200910081823.n98INRVZ082461@lurza.secnetix.de> Message-ID: References: <200910081823.n98INRVZ082461@lurza.secnetix.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: openssh concerns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 14:52:39 -0000 On Thu, 8 Oct 2009, Oliver Fromme wrote: > Are you sure? The majority of BSD machines in my vicinity have multiple > accounts. > > And even if there's only one account, there is no reason to be careless with > potential port-takeover risks. > > Therefore I advise against running critical daemons on unprivileged ports, > especially on machines with shell accounts. And if you need to bind to a > port >= 1024, use mac_portacl(4) to protect it. It's easy to use. > Alternatively you can increase the value of the sysctl > net.inet.ip.portrange.reservedhigh, but this is less flexible and might have > unwanted side effects. And, for those that haven't already noticed, "options MAC" is compiled into GENERIC on 8.0, so working with MAC policies no longer requires a recompile (or in many cases, even a reboot). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 17:54:29 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 427CE10656DE; Sun, 11 Oct 2009 17:54:29 +0000 (UTC) (envelope-from danger@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2E0BA8FC0C; Sun, 11 Oct 2009 17:54:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9BHsTe4004836; Sun, 11 Oct 2009 17:54:29 GMT (envelope-from danger@freefall.freebsd.org) Received: (from danger@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9BHsTI8004835; Sun, 11 Oct 2009 17:54:29 GMT (envelope-from danger) Date: Sun, 11 Oct 2009 17:54:29 +0000 From: Daniel Gerzo To: hackers@FreeBSD.org Message-ID: <20091011175428.GA3626@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Cc: stable@FreeBSD.org, questions@FreeBSD.org, current@FreeBSD.org Subject: FreeBSD Status Reports April - September, 2009 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 17:54:29 -0000 FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between April and September 2009. During that time a lot of work has been done on wide variety of projects, including the Google Summer of Code projects. The BSDCan conference was held in Ottawa, CA, in May. The EuroBSDCon conference was held in Cambridge, UK, in September. Both events were very successful. A new major version of FreeBSD, 8.0 is to be released soon. If you are wondering what's new in this long-awaited release, read Ivan Voras' excellent summary. Thanks to all the reporters for the excellent work! We hope you enjoy the reading. Please note that the next deadline for submissions covering reports between October and December 2009 is January 15th, 2010. __________________________________________________________________ Google Summer of Code * About Google Summer of Code 2009 * BSD-licensed iconv (Summer of Code 2009) * BSD-licensed text-processing tools (Summer of Code 2008) * Ext2fs Status report (Summer of Code 2009) * libnetstat(3) - networking statistics (Summer of Code 2009) * pefs - stacked cryptographic filesystem (Summer of Code 2009) Projects * BSD# Project * Clang replacing GCC in the base system * FreeBSD TDM Framework * Grand Central Dispatch - FreeBSD port * libprocstat(3) - process statistics * New BSD licensed debugger * NFSv4 ACLs * The Newcons project * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Ports Management Team * Release Engineering Status Report * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Modular Congestion Control * Network Stack Virtualization * Stream Control Transmission Protocol (SCTP) Kernel * FreeBSD/ZFS * hwpmc for MIPS Documentation * The FreeBSD Dutch Documentation Project * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * FreeBSD/sparc64 Ports * FreeBSD Gecko Project * Portmaster - utility to assist users with managing ports * Valgrind suite on FreeBSD Miscellaneous * EuroBSDcon 2009 * FreeBSD Developer Summit, Cambridge UK * New approach to the locale database * The FreeBSD Forums __________________________________________________________________ About Google Summer of Code 2009 URL: http://socghop.appspot.com/org/home/google/gsoc2009/freebsd URL: http://wiki.freebsd.org/SummerOfCode2009Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson 2009 was The FreeBSD Project's fifth year of participation in the Google Summer of Code. We had a total of 17 successful projects. Some GSoC code will be shipping with FreeBSD 8.0-RELEASE and others will be integrated into future releases. The FreeBSD GSoC admin team would like to thank Google and our students and mentors of another great year! __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain Tartičre The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. During the past year, the BSD# Team continued to track the Mono development and the lang/mono port have almost always been up-to-date (we however had to skip mono-2.2 because of some regression issues in this release). Most of our patches have been merged in the mono trunk upstream, and should be included in the upcoming mono-2.6 release. In the meantime, a few more .NET related ports have been updated or added to the FreeBSD ports tree. These ports include: * www/xsp and www/mod_mono that make it possible to use FreeBSD for hosting ASP.NET application; * lang/boo, a CLI-targeted programming language similar to Python; * lang/mono-basic, the Visual Basic .NET Framework for Mono; * devel/monodevelop, an Integrated Development Environment for .NET; * and much more... Open tasks: 1. Test mono ports and send feedback (we are especially interested in tests where NOPORTDOCS / WITH_DEBUG is enabled). 2. Port the mono-debugger to FreeBSD. 3. Build a debug live-image of FreeBSD so that Mono hackers without a FreeBSD box can help us fixing bugs more efficiently. __________________________________________________________________ BSD-licensed iconv (Summer of Code 2009) URL: http://wiki.freebsd.org/G%C3%A1borSoC2009 Contact: Gábor Kövesdán The code has been extracted from NetBSD and has been transformed into an independent shared library. The basic encodings are well supported. Almost all forward conversions (foo -> UTF-32) are compatible with GNU but the reverse ones are not so accurate because of GNU's advanced transliteration. Some extra encodings have also been added. There are two modules, which segfault; they need some debugging. I can keep working on this project as part of my BSc thesis, so I hope to be able to solve the remaining issues. Improved GNU compatibility is also very desired (extra command line options for iconv(1), iconvctl(), private interfaces, etc.). Open tasks: 1. Fix segfaults in Big5 and HZ modules 2. Improve transliteration in reverse encodings 3. Improve GNU compatibility by implementing extra features 4. Verify POSIX compatibility 5. Verify GNU compatibility 6. Check performance __________________________________________________________________ BSD-licensed text-processing tools (Summer of Code 2008) URL: http://wiki.freebsd.org/G%C3%A1borSoC2008 Contact: Gábor Kövesdán This project was started as part of Google Summer of Code 2008 but there is still a bit of work to complete some missing parts. The BSD-licensed grep implementation is feature-complete and has a good level of GNU compatibility. Our only current concern about the BSD-licensed version is to improve its performance. The GNU variant is much more complex, has about 8 KSLOC, while BSD grep is tiny, has only 1.5 KSLOC. GNU uses some shortcuts and optimizations to speed-up calls to the regex library; that is why it is significantly faster. My point of view is that such optimizations must be implemented in the regex library, keeping the dependent utilities clean and easy to read. BSD grep is so tiny that there is hardly any optimization opportunity by simplifying the code, so the regex library is the next important TODO. There is another issue with the current regex library. It does not support some invalid regular expressions, which work in GNU. We need to maintain compatibility, so we cannot just drop this feature. Actually, BSD grep is linked to the GNU regex library to maintain this feature but due to the lack of the mentioned shortcuts, it is still slower than GNU. Anyway, if we can live with this little performance hit until we get a modern regex library, I think grep is ready to enter HEAD. As for the regex library, NetBSD's result of the last SoC is worth taking a look. The sort utility has been rewritten from scratch. The existing BSD-licensed implementation could not deal with wide characters by design. The new implementation is still lacking some features but is quite complete. There is a performance issue, though. Sorting is a typical algorithmic subject but I am not an algorithmic expert, so my implementation is not completely optimal. Some help would be welcome with this part. The bc/dc utilities have been ported from OpenBSD. They pass OpenBSD's and GNU's regression tests but they arrived too late to catch 8.X, so they will go to HEAD after the release. Open tasks: 1. Improve sort's sorting and file merging algorithms 2. Complete missing features for sort 3. Get a modern regex library for FreeBSD __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The clang@FreeBSD team presents the status of clang/LLVM being able to compile FreeBSD system. The current status is: * i386 - kernel boots, world needs little hacks but works * amd64 - kernel boots, world needs little hacks but works * ppc - broken because of unknown RTLD bug * other - unknown All other platforms are untested. A lot has happened over the spring/summer: amd64 got proper mcmodel=kernel support, compiler-rt has been introduced (paving the way for libgcc replacement), we have run two experimental port builds to see how clang does there. The C++ support is able to parse devd.cc without warnings. We have got the kernel working with -O2. FreeBSD has been promoted to be an officially supported plaform in LLVM. As a result of all this work, many parts of FreeBSD that did not compile before now build without problems. Open tasks: 1. The "ClangBSD" branch of FreeBSD got a little stale and has not been updated for a while. 2. We also need to get some important fixes into LLVM to get libc compiling and some other smaller issues. 3. We can still appreciate more testers on minor platforms (mostly on ARM, PPC and MIPS, but testing on other platforms is also welcome). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.freebsdfoundation.org/projects.shtml URL: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart TCP appropriate byte counting (RFC 3465) support has been merged into the FreeBSD 8 branch and will ship in FreeBSD 8.0-RELEASE. The reassembly queue auto-tuning and SIFTR work was not ready in time to safely integrate for 8.0-RELEASE. Padding has been added to necessary TCP structs to facilitate MFCing features back to the 8-STABLE branch after 8.0 is released. Candidate patches against FreeBSD-CURRENT will be ready for wider testing in the coming weeks. The freebsd-net mailing list will be solicited for testing/feedback when everything is ready. Open tasks: 1. Solicit review/testing and integrate the ALQ kld and variable length message support patch into FreeBSD-CURRENT. 2. Solicit review/testing and integrate the SIFTR tool into FreeBSD-CURRENT. 3. Complete dynamic reassembly queue auto-tuning patch for FreeBSD-CURRENT. 4. Fix an identified bug in the SACK implementation's fast retransmit/fast recovery behavior. 5. Profit! __________________________________________________________________ EuroBSDcon 2009 URL: http://2009.eurobsdcon.org/ URL: http://2010.eurobsdcon.org/ Contact: Sam Smith Contact: Robert Watson EuroBSDcon 2009 happened in Cambridge, with over 160 users, developers, friends and others. Slides, papers and audio are now up on the website for those who could not make it to Cambridge. Next year's event in 2010 will take place in Karlsruhe from 8 to 10 October 2010. If you are interested in what you missed in 2009, or to join the mailing list so you do not miss out next year, visit http://2009.eurosbsdcon.org. __________________________________________________________________ Ext2fs Status report (Summer of Code 2009) URL: http://wiki.freebsd.org/SOC2009AdityaSarawgi Contact: Aditya Sarawgi FreeBSD's ext2fs had some parts under GPL. The aim of my project was to rewrite those parts and free ext2fs from GPL. I have been successful in rewriting the parts and NetBSD's ext2fs was a great help in this. Certain critical parts under GPL were also removed due to which the write performance suffered. I also implemented Orlov Block Allocator for ext2fs. Currently I am planning to make ext2fs Multiprocessor Safe (MPSAFE). My work resides in truncs_ext2fs branch of Perforce. Open tasks: 1. Ext4 support for FreeBSD 2. Directory indexing for ext2fs 3. Journaling in ext2fs using gjournal __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions. This list contains PRs, mostly with patches, that the Bugbusting Team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. A full list of all the automatically generated reports is also available at one of the cited URLs. Any recommendations for reports which not currently exist but which would be beneficial are welcomed. Gavin Atkinson gave a presentation on "The PR Collection Status" at the EuroBSDCon 2009 DevSummit, and discussed with other participants several other ideas to make the PR database more useful and usable. Several good ideas came from this, and will hopefully lead to more useful tools in the near future. Discussions also took place on how it may be possible to automatically classify non-ports PRs with a view towards notifying interested parties, although investigations into this have not yet begun. Mark Linimon also continues attempting to define the general problem and investigating possible new workflow models, and presented work on this at BSDCan 2009. Since the last status report, the number of open bugs has increased to around the 5900 mark, partially because of an increased focus on getting more information into the existing PRs, in an attempt to make sure all the information required is now available. As a result, although the number of open PRs has increased, they are hopefully of better quality. As always, more help is appreciated, and committers and non-committers alike are always invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Work on suggestions from developers who were at the EuroBSDCon DevSummit. 2. Try to find ways to get more committers helping us with closing the PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Developer Summit, Cambridge UK URL: http://wiki.FreeBSD.org/200909DevSummit Contact: Robert Watson Around 70 FreeBSD developers and guests attended the FreeBSD developer summit prior to EuroBSDCon 2009 in Cambridge, UK. Hosted at the University of Cambridge Computer Laboratory, the workshop-style event consisted of prepared presentations, as well as group hacking and discussion sessions. Talks covered topics including 802.11 mesh networking, virtual network stacks and kernels, a new BSD-licensed debugger, benchmarking, bugbusting, NetFPGA, a port of Apple's GCD (Grand Central Dispatch) to FreeBSD, security policy work, cryptographic signatures, FreeBSD.org system administration, time geeks, a new console driver, and the FreeBSD subversion migration. Slides for many talks are now available on the wiki page. A good time was had by all, including a punting outing on the River Cam! __________________________________________________________________ FreeBSD Gecko Project URL: https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO Contact: Beat Gaetzi Contact: Martin Wilke Contact: Andreas Tobler Andreas Tobler made the classic mistake of sending us a lot of powerpc and sparc64 related patches. The usual punishment, of giving him a commit bit to the Gecko repository, has been applied. We currently have some old ports in the ports tree: * www/mozilla is 5 year old now, no longer supported upstream, and has a lot of security vulnerabilities. We can use www/seamonkey instead. * www/xulrunner is superseeded by www/libxul. A patch that includes the following changes has been tested on pointyhat and is ready for commit: * Remove references to www/mozilla/Makefile.common and www/mozilla/bsd.gecko.mk * Switch USE_GECKO= xulrunner firefox mozilla to USE_GECKO= libxul and remove www/xulrunner We are also working on Firefox 3.6 (Alpha 2), Thunderbird 3.0 (Beta 4), new libxul 1.9.1.3 and Seamonkey 2.0 (Beta 2) ports. All of them are already committed to our Gecko repository. A current status and todo list can be found at http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO. Open tasks: 1. Remove mozilla, xulrunner and firefox2 from the ports tree. 2. The www/firefox35 port should be moved to www/firefox. 3. The old (and somewhat stale) Gecko providers mozilla, nvu, xulrunner, flock and firefox also need to be removed. __________________________________________________________________ FreeBSD KDE Team URL: http://freebsd.kde.org URL: http://miwi.bsdcrew.de/category/kde/ URL: http://blogs.freebsdish.org/tabthorpe/category/kde Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Martin Wilke Since the spring, the FreeBSD KDE team has been busy upgrading KDE from 4.2.0 up through to 4.3.1. As part of the ongoing maintenance of KDE, the team also updated Qt4 from 4.4.3 through to 4.5.2 We added two new committers/maintainers to the team, Kris Moore (kmoore@) and Dima Panov (fluffy@). We also granted enhanced area51 access to contributors Alberto Villa and Raphael Kubo da Costa. Alberto has been our key contributor updating and testing Qt 4.6.0-tp1. Raphael is a KDE developer, who has become our Gitorious liaison, he has been responsible for getting FreeBSD Qt patches merged in upstream. Markus Brüffer (markus@) spent a lot of time patching widgets and system plugins so they would work under FreeBSD. We would like to thank him for all his effort! Open tasks: 1. Update to Qt 4.6.0 2. Update to KDE 4.4.0 3. Work with our userbase on fixing an EOL for KDE3 in the ports tree __________________________________________________________________ FreeBSD Ports Management Team URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has soared to over 20,700. The PR count had been driven below 800 by some extraordinary effort, but once again is back to its usual count of around 900. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, sparc64-7, and sparc64-8. There have been preliminary runs of i386-9; however, to be able to continue builds on -9, we will either need to find places to host a number of new machines, or drop package building for -6. The mailing list discussion of the latter proved quite controversial. We have added some new i386 machines to help speed up the builds, but this only makes up for the disk failures on some of our older, slower, i386 nodes. We also appreciate the loan of more package build machines from several committers, including pgollucci@, gahr@, erwin@, Boris Kochergin, and Craig Butler. The portmgr@ team has also welcomed new members Ion-Mihai Tetcu (itetcu@) and Martin Wilke (miwi@). We also thank departing member Kirill Ponomarew (krion@) for his long service. Ion-Mihai has spent much time working on a system that does automatic Quality Assurance on new commits, called QAT. A second tinderbox called QATty has helped us to fix many problems, especially those involving custom PREFIX and LOCALBASE settings, and documentation inclusion options. Ports conformance to documented features / non-default configuration will follow. Between pav and miwi, over 2 dozen experimental ports runs have been completed and committed. We have added 5 new committers since the last report, and 2 older ones have rejoined. Open tasks: 1. We are currently trying to set up ports tinderboxes that can be made available to committers for pre-testing; those who can loan machines for this should contact Ion-Mihai (itetcu@) with details regarding the hardware and bandwidth. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have almost 4,700 unmaintained ports (see, for instance, the list on portsmon). (The percentage is down to 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk This work's purpose is a generic and flexible framework for systems equipped with Time Division Multiplexing (TDM) units, often found on embedded telecom chips. The framework is designed to support various controllers and many types of TDM channels e.g. voiceband, sound and miscellaneous data channels. Currently, voiceband infrastructure is being developed on Marvell RD-88F6281 reference board. It will serve as an example of how to use the TDM framework for other channel types. The direct objective of using TDM with voiceband channels is bringing a FreeBSD based VoIP system, capable of bridging analog telephone world with digital IP telephony. Together with third party VoIP software (e.g. Asterisk), the design can serve as VoIP Private Branch Exchange (PBX). Current state highlights: * TDM controller interface * TDM channel interface * TDM channel API for kernel modules * codec interface * voiceband channel character device driver * TDM controller driver for Marvell Kirkwood and Discovery SoCs * Si3215 SLIC driver * Si3050 DAA driver Open tasks: 1. Develop demo application showing example usage of voiceband channel. 2. Integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Noteworthy developments regarding FreeBSD/sparc64 since the last Status Reports are: * Cas(4), a driver for Sun Cassini/Cassini+, as well as National Semiconductor DP83065 Saturn Gigabit NICs has been committed and thus will be part of FreeBSD beginning with 8.0-RELEASE and 7.3-RELEASE, respectively. This means that the on-board NICs found in Fire V440, as well as the add-on cards based on these chips, are now supported, including on non-sparc64 machines. Unfortunately, the cas(4) driver triggers what seem to be secondary problems with the on-board NICs found in B100 blades and Fire V480, which due to lack of access to such systems could not be fixed so far. * Initial support for sun4u machines based on the "Fire" Host-PCI-Express bridge like Fire V215, V245, etc. has been completed (including support for the on-board ATA controller, which caused several problems at first, and MSI/MSI-X). Some code like the quirk handling for the ALi/ULi chips found in these machines needs to be revisited though and no stability tests have been conducted so far. If all goes well, the code will hit HEAD some time after FreeBSD 8.0-RELEASE has been released. In theory, machines based on the "Oberon" Host-PCI-Express bridge, at least for the most part, should also be supported with these changes, but due to lack of access to a Mx000 series machine the code could not be tested with these so far. * Some bugs in the snd_t4dwave(4) driver have been fixed, as well as some special handling for sparc64 has been added so it does 32-bit DMA and now generally works with the on-board ALi M5451 found for example in Blade 100 and Blade 1500. Unfortunately, it was only tested to work correctly in two out of three Blade 100. Why it still does not work correctly in the remaining one is currently unknown but at least no longer causes IOMMU-panics so testing snd_t4dwave(4) on sparc64 is no longer harmful. These changes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * Ata-marvell(4) has been fixed to work on sparc64 (actually also on anything that is not x86 with less than 4GB of RAM). These fixes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * A proper and machine-independent fix for the old problem that the loader leaves the NIC opened by the firmware, which could lead to panics during boot when netbooting, has been developed but not committed yet. Open tasks: __________________________________________________________________ FreeBSD/ZFS Contact: Pawel Dawidek We believe that the ZFS file system is now production-ready in FreeBSD 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer tagged as experimental. There is also ongoing work in Perforce to bring the latest ZFS version (v19) to FreeBSD. Open tasks: 1. Download 8.0 release candidates and test, test, test and report any problems to the freebsd-fs@FreeBSD.org mailing list. __________________________________________________________________ Grand Central Dispatch - FreeBSD port URL: http://libdispatch.macosforge.org/ Contact: Robert Watson Contact: Stacey Son Contact: libdispatch mailing list We have ported libdispatch, Apple's Grand Central Dispatch event and concurrency framework to FreeBSD: * Added new kqueue primitives required to support GCD, such as EVFILT_USER and EV_TRIGGER * Created autoconf and automake build framework for libdispatch * Modified libdispatch to use POSIX semaphores instead of Mach semaphores * Adapted libdispatch to use portable POSIX time routines Jordan Hubbard has also prepared a blocks-aware clang compiler package for FreeBSD. When compiled with clang, libdispatch provides blocks-based, as well as function-based callbacks. The port was presented at the FreeBSD Developer Summit in Cambridge, UK in September, and slides are online on the devsummit wiki page. A FreeBSD port is now available in the Ports Collection. After FreeBSD 8.0-RELEASE has shipped, the new kqueue primitives will be MFC'd so that libdispatch works out of the box on FreeBSD 8.1-RELEASE. Open tasks: 1. Complete porting of libdispatch test suite to FreeBSD. 2. Investigate pthread work queue implementation for FreeBSD. 3. Evaluate performance impact of some machine-dependent and OS-dependent optimizations present in the Mac OS X version of libdispatch to decide if they should be done for other platforms and OS's. 4. Explore whether FreeBSD base operating system tools would benefit from being modified to use libdispatch. __________________________________________________________________ hwpmc for MIPS URL: http://wiki.freebsd.org/FreeBSD/mips URL: http://wiki.freebsd.org/FreeBSD/mips/UBNT-RouterStationPro Contact: George Neville-Neil Currently working on board bringup. I have looked over the docs for how MIPS provides performance counters and will begin adding code soon. __________________________________________________________________ libnetstat(3) - networking statistics (Summer of Code 2009) URL: http://wiki.FreeBSD.org/PGJSoc2009 URL: http://p4web.freebsd.org/@md=d&cd=//&c=McZ@//depot/projects/soc2009/pgj _libstat/?ac=83 Contact: Gábor Páli The libnetstat(3) project provides a user-space library API to monitor networking functions with the following benefits: * ABI-robust interface making use of accessor functions in order to divorce monitoring applications from kernel or user ABI changes. * Supports running 32-bit monitoring tools on top of a 64-bit kernel. * Improved consistency for both kvm(3) and sysctl(3) when retrieving information. The supported abstractions are as follows: * Active sockets and socket buffers * Network interfaces and multicast interfaces * mbuf(9) statistics * bpf(4) statistics * Routing statistics, routing tables, multicast routing * Protocol-dependent statistics There is a sample application, called nettop(8), which provides a simple ncurses-based top(1)-like interface for monitoring active connections and network buffer allocations via the library. A modified version of netstat(1) has also been created to use libnetstat(3) as much as possible. __________________________________________________________________ libprocstat(3) - process statistics URL: http://svn.freebsd.org/viewvc/base/projects/libprocstat/ Contact: Stanislav Sedov Contact: Ulf Lilleengen The libprocstat project is an ongoing effort to develop a library that can be used to retrieve information about running processes and open files in the uniform and platform-independent way both from a running system or from core files. This will facilitate the implementation of file- or process-monitoring applications like lsof(1), fstat(1), fuser, etc. The libprocstat repository contains a preliminary version of the library. It also includes rewrites of the fstat and the fuser utilities ported to use this library instead of retrieving all the required information via the kvm(3) interface; one of the important advantages of the versions that use libprocstat is that these utilities are ABI independent. Open tasks: 1. Implement KVM-based namecache lookup to retrieve filesystem paths associated with file descriptors and VM objects. 2. Analyze possible ways of exporting file and process information from the kernel in an extensible and ABI-independent way. __________________________________________________________________ Modular Congestion Control URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/ Contact: Lawrence Stewart The patch has received some significant rototilling in the past few months to prepare it for merging to FreeBSD-CURRENT. Additionally, I completed an implementation of the CUBIC congestion control algorithm to complement the existing NewReno and H-TCP algorithm implementations already available. I have one further intrusive change to make, which will allow congestion control modules to be shared between the TCP and SCTP stacks. Once this is complete, I will be soliciting for review/testing in the hope of committing the patch to FreeBSD-CURRENT in time to be able to backport it for 8.1-RELEASE. Open tasks: 1. Abstract the congestion control specific variables out of the TCP and SCTP control blocks into a new struct that can be passed into the API instead of the control block itself. __________________________________________________________________ Network Stack Virtualization URL: http://wiki.freebsd.org/Image URL: http://wiki.freebsd.org/200909DevSummit Contact: Bjoern A. Zeeb Contact: Marko Zec Contact: Robert Watson The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail environment, each maintaining its private network interfaces, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more. During the last months the remaining pieces of the VIMAGE work were merged by Marko, Julian and Bjoern. Robert Watson developed a vnet allocator to overcome ABI issues. Jamie Gritton merged his hierachical jail framework that now also is the management interface for virtual network stacks. During the FreeBSD Developer Summit that took place at EuroBSDCon 2009 in Cambridge, UK, people virtualized more code. As a result SCTP and another accept filter were virtualized and more people became familiar with the design of VImage and the underlying concepts. Finally getting more hands involved was a crucial first step for the long term success of kernel virtualization. The next steps will be to finish the network stack virtualization, generalize the allocator framework before thinking of virtualizing further subsystems and to update the related documentation. Along with that a proper jail management framework will be worked on. Long term goals, amongst others, will be to virtualize more subsystems like SYS-V IPC, better privilege handling, and resource limits. In the upcoming FreeBSD 8.0 Release, vnets are treated as an experimental feature. As a result, they are not yet recommended for use in production environments. There was lots of time spent to finalize the infrastructure for vnets though, so that further changes can be merged and we are aiming to have things production ready for 8.2. In case you want to help to achieve this goal, feel free to contact us and support or help virtualizing outstanding parts like two firewalls, appletalk, netipx, ... as well as generating regression tests. __________________________________________________________________ New approach to the locale database URL: http://wiki.freebsd.org/LocaleNewApproach URL: svn://svn.freebsd.org/base/user/edwin/locale Contact: Edwin Groothuis Contact: i18n mailinglist Problem: Over the years the FreeBSD locale database (share/colldef, share/monetdef, share/msgdef, share/numericdef, share/timedef) has accumulated a total of 165 definitions (language - country-code - character-set triplets). The contents of the files for Western European languages are often low-ASCII but for Eastern European and Asian languages partly or fully high-ASCII. Without knowing how to display or interpret the character-sets, it is difficult to make sure by the general audience that the local language (language - country-code) definitions are displayed properly in various character-sets. Suggested approach: With the combination of the data in the Unicode project (whose goal is to define all the possible written characters and symbols on this planet) and the Common Locale Data Repository (whose goal is to document all the different data and definitions needed for the locale database), we can easily keep track of the data, without the need of being able to display the data in the required character sets or understand them fully when updates are submitted by third parties. Current status: Conversion of share/monetdef, share/msgdef, share/numericdef, share/timedef to the new design is completed. The Makefile infrastructure is converted. Regression checks are done. Most of the tools are in place, waiting on the import of bsdiconv to the base system. Open tasks: 1. At this moment the system is not self-hosted yet, because of the lack of an iconv-kind of program in the base operating system. Gabor@ is working on bsdiconv as a GSoC project and once that has been imported we will be able to perform a clean install from the definitions in Unicode text format to the required formats and character sets. __________________________________________________________________ New BSD licensed debugger URL: http://wiki.freebsd.org/TheBsdDebugger URL: http://people.freebsd.org/~dfr/ngdb.git URL: http://wiki.freebsd.org/200909DevSummit?action=AttachFile&do=view&targe t=NGDB-200909.pdf Contact: Doug Rabson <> I have been working recently on writing a new debugger, primarily for the FreeBSD platform. For various reasons, I have been writing it in a relatively obscure C-like language called D. So far, I have a pretty useful (if a little raw at the edges) command line debugger which supports ELF, Dwarf debugging information and (currently) 32 bit FreeBSD and Linux. The engine includes parsing and evaluation of arbitrary C expressions along with the usual debugging tools such as breakpoints, source code listing, single-step etc. All the code is new and BSD licensed. Currently, the thing supports userland debugging of i386 targets via ptrace and post-mortem core file debugging of the same. I will be adding amd64 support real soon (TM) and maybe support for GDB's remote debugging protocol later. __________________________________________________________________ NFSv4 ACLs URL: http://wiki.freebsd.org/NFSv4_ACLs Contact: Edward Tomasz Napierala During Google Summer of Code 2008, I have implemented native support for NFSv4 ACLs for both ZFS and UFS. Most of the code has already been merged to CURRENT. NFSv4 ACLs are unconditionally enabled in ZFS and the usual tools, like getfacl(1) and setfacl(1) can be used to view and change them. I plan to merge the remaining bits (UFS support) this month. It should be possible to MFC it in order to ship in FreeBSD 8.1-RELEASE. Open tasks: 1. UFS changes review 2. Support for NFSv4 ACLs in tar(1) __________________________________________________________________ pefs - stacked cryptographic filesystem (Summer of Code 2009) URL: http://blogs.freebsdish.org/gleb/ URL: http://wiki.freebsd.org/SOC2009GlebKurtsov Contact: Gleb Kurtsou Contact: Stanislav Sedov Pefs is a kernel level filesystem for transparently encrypting files on top of other filesystems (like zfs or ufs). It adds no extra information into files (unlike others), doesn't require cipher block sized io operations, supports per directory/file keys and key chaining, uses unique per file tweak for encryption. Supported algorithms: AES, Camellia, Salsa20. The code is ready for testing. Open tasks: 1. Implement encrypted name lookup/readir cache 2. Optimize sparse files handling and file resizing __________________________________________________________________ Portmaster - utility to assist users with managing ports URL: http://dougbarton.us/portmaster.html Contact: Doug Barton I am currently seeking funding for further development work on portmaster. There are several features that are regularly requested by the community (such as support for installing packages) that I would very much like to implement but that will take more time than I can reasonably volunteer to implement correctly. There is information about the funding proposal available at the link above. Meanwhile I have recently completed another round of bug fixes and feature enhancements. The often-requested ability to specify the -x (exclude) option more than once on the command line was added in version 2.12. Also in that version I added the --list-origins option to make it easier to reinstall ports after a major version upgrade, or install the same set of ports on another system. Open tasks: 1. See the funding proposal. __________________________________________________________________ Release Engineering Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team continues to work on FreeBSD 8.0-RELEASE. Public testing has turned up quite a few problems, many related to the low-level network (routing/ARP table) changes and their interactions with IPv6. Progress continues to be made on fixing up the issues that have been identified during the public testing. At this point in time we are shooting for two more public test builds (RC2 and RC3) followed by the release late October or early November. __________________________________________________________________ Stream Control Transmission Protocol (SCTP) Contact: Randall Stewart SCTP continues to have minor fixes added to it as well as some new features. First and foremost, we now have VIMAGE and SCTP working and playing together. This goal was accomplished with the help of bz@, my new mentee tuexen@ and myself working together at the FreeBSD DevSummit in Cambridge, UK. Also the non-renegable SACK feature contributed by the university of Delaware was fixed so that now its safe to turn on (its sysctl). If you are using SCTP with CMT (Conncurrent Multipath Transfer) you will want to enable this option (CMT is also a sysctl). With CMT enabled you will be able to send data to all the destinations of an SCTP peer. We welcomed a new mentee (soon to be a commiter) to FreeBSD. Michael Tuexen is now a mentee of rrs@. Michael has been contributing to the SCTP work for quite some time and also moonlights as a Professor at the University of Muenster in Germany (when not doing SCTP coding). __________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/docproj/translations.html#dutch Contact: René Ladan Contact: Remko Lodder The current translations (Handbook and some articles) are kept up to date with the English versions. Some parts of the website have been translated, more work is in progress. Open tasks: 1. Find more volunteers for translating the remaining parts of the website and the FAQ. __________________________________________________________________ The FreeBSD Forums URL: http://forums.freebsd.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since their public launch in November 2008, the FreeBSD Forums (the most recent addition to the user community and support channels for the FreeBSD Operating System) have witnessed a healthy and steady growth. The user population is now at over 8,000 registered users, who have participated in over 6,000 topics, containing over 40,000 posts in total. The sign-up rate hovers between 50-100 each week. The total number of visitors (including 'guests') is hard to gauge but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the Forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the Forums' success is their 'BSD-style' approach when it comes to administration and moderation. The Forums have a strong and unified identity, they are neatly divided into sub-forums (like 'Networking', 'Installing & Upgrading', etc.), very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. We expect the Forums to be, and to remain, a central hub in FreeBSD's community and support efforts. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.freebsdfoundation.org Contact: Deb Goodkin Kicking off our fall fund-raising campaign! Find out more at http://www.freebsdfoundation.org/donate/. We were a sponsor for EuroBSDCon 2009, and provided travel grants to 8 FreeBSD developers and users. We sponsored Kyiv BSD 2009, in Kiev Ukraine. We were also a sponsor of BSDCan, and sponsored 7 developers. We funded three new projects, New Console Driver by Ed Schouten, AVR32 Support by Arnar Mar Sig, and Wireless Mesh Support by Rui Paulo, which has completed. We continued funding a project that is making improvements to the FreeBSD TCP Stack by Lawrence Stewart. The project that made removing disk devices with mounted filesystems on them safe, by Edward Napierala, is now complete. We recognized the following FreeBSD developers at EuroBSDCon 2009: Poul-Henning Kamp, Bjoern Zeeb, and Simon Nielsen. These developers received limited edition FreeBSD Foundation vests. Follow us on Twitter now! __________________________________________________________________ The FreeBSD German Documentation Project URL: https://doc.bsdgroup.de URL: http://code.google.com/p/bsdcg-trans/wiki/BSDPJTAdede Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke In May 2009, Benedict Reuschling received his commit bit to the www/de and doc/de_DE.ISO8859-1 trees under the mentorship of Johann Kois. Since then, he has been working primarily on the Handbook, updating existing chapters and translating new ones. Most notably, the filesystems and DTrace chapters have been recently translated. Bugs found in the original documents along the way were reported back so that the other translation teams could incorporate them, as well. Christoph Sold has put his time in translating the wiki pages of the BSD Certification Group into the German language. This is very helpful for all German people who want to take the exam and like to read the information about it in their native language. Daniel Seuffert has sent valuable corrections and bugfixes. Thanks to both of them for their time and efforts! The website is translated and updated constantly. Missing parts will be translated as time permits. We appreciate any help from volunteers in proofreading documents, translating new ones and keeping them up to date. Even small error reports are of great help for us. You can find contact information at the above URL. Open tasks: 1. Update the existing documentation set (especially the Handbook). 2. Translate more articles to German. 3. Read the translations. Check for problems and mistakes. Send feedback. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: Gábor Kövesdán Contact: Gábor Páli In the last months, we have not added new translations, although we have been working on the existing ones to have them updated. We need more translators and volunteers to keep the amount of the translated documentation growing, so feel free to contribute. Every line of submission or feedback is appreciated and highly welcome. If you want to join our work, please read the introduction to the project as well as the FDP Primer (both of them are available in Hungarian). Open tasks: 1. Translate news entries, press releases 2. Translate Release Notes for -CURRENT and 8.X 3. Translate articles 4. Translate web pages 5. Read the translations, send feedback __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/es URL: http://www.FreeBSD.org/doc/es URL: http://www.freebsd.org/doc/es/articles/fdp-es/ Contact: José Vicente Carrasco Vayá Contact: Gábor Kövesdán Recently, we have added one new article translation. The existing translations have not been updated, though. We need more human resources to keep up with the work and keep the translations up-to-date. Open tasks: 1. Update the Handbook translation 2. Update the web page translation __________________________________________________________________ The Newcons project URL: http://wiki.FreeBSD.org/Newcons URL: http://people.freebsd.org/~ed/newcons/patches/ Contact: Ed Schouten Some time ago I started writing a new driver for the FreeBSD kernel called vt(4), which is basically a replacement of syscons. There is still a lot of work that needs to be done but it is probably useful to mention what it does (and what does not). Right now there are just two graphics drivers for vt(4), namely a VGA driver for i386 and amd64 and a Microsoft Xbox graphics driver (because it was so easy to implement). I still have to figure out what I am going to do with VESA, because maybe it is better to just ignore VESA and figure out how hard it is to extend DRM to interact with vt(4). Some random features: it already supports both Unicode (UTF-8) input and output, it is MPSAFE and supports per-window graphical fonts of variable dimensions, containing an almost infinite amount of glyphs (both bold and regular). Open tasks: 1. Research needs to be done on DRM's codebase. 2. Syscons should already be migrated to TERM=xterm to make switching between drivers a bit easier. __________________________________________________________________ Valgrind suite on FreeBSD URL: http://wiki.freebsd.org/Valgrind Contact: Stanislav Sedov The Valgrind suite in the FreeBSD ports collection has been updated to version 3.5.0 (the latest available version). Most of the issues of the previous version should be resolved now: we expect memcheck, callgrind and cachegrind to be fully functional on both i386 and amd64 platforms as well as for i386 binaries running on amd64 system. DRD/hellgrind should work too, though they generate a lot of false-positives for now, so their output is a bit messy. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.freebsd.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Juergen Lock Contact: Martin Wilke VirtualBox has been committed to the Ports tree and synchronized with the latest trunk version from Sun. Several known problems are already fixed and some new features have been added: * VT-x support * Bridging support (Big Thanks to Fredrik Lindberg) * Host Serial Support * ACPI Support * Host DVD/CD access * SMP Support We would like to say thanks to all the people who helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox on FreeBSD. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 11 20:17:17 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A812106566B for ; Sun, 11 Oct 2009 20:17:17 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C64908FC19 for ; Sun, 11 Oct 2009 20:17:16 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A9D561CC4D; Sun, 11 Oct 2009 22:17:15 +0200 (CEST) Date: Sun, 11 Oct 2009 22:17:15 +0200 From: Ed Schouten To: Mikolaj Golub Message-ID: <20091011201715.GY71731@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1fZJyN7nFm/tosmV" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 20:17:17 -0000 --1fZJyN7nFm/tosmV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Mikolaj, It is indeed true that the new TTY layer restricts the baud rate to 9600. We could consider clamping the baud rate between a certain range, to prevent the TTY buffer size from growing excessively. So what kind of buffer size are you interested in? Would 115200 / 5 be enough? --=20 Ed Schouten WWW: http://80386.nl/ --1fZJyN7nFm/tosmV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrSPUsACgkQ52SDGA2eCwVpywCcDG1fb9WkGJWcCJtBf14Jqu/Z QJwAnAkk4MS11vVdzq3ljgFWFe2jZvay =kkio -----END PGP SIGNATURE----- --1fZJyN7nFm/tosmV-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 01:55:43 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6271065676 for ; Mon, 12 Oct 2009 01:55:43 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from outgoing01.lava.net (cake.lava.net [IPv6:2001:1888:0:1:230:48ff:fe5b:3b50]) by mx1.freebsd.org (Postfix) with ESMTP id A35368FC12 for ; Mon, 12 Oct 2009 01:55:43 +0000 (UTC) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by outgoing01.lava.net (Postfix) with ESMTP id EF318D0083 for ; Sun, 11 Oct 2009 15:55:42 -1000 (HST) Received: by malasada.lava.net (Postfix, from userid 102) id 9D2D3153882; Sun, 11 Oct 2009 15:55:42 -1000 (HST) Date: Sun, 11 Oct 2009 15:55:42 -1000 From: Clifton Royston To: stable@freebsd.org Message-ID: <20091012015542.GB2096@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: Any recommended Intel server motherboards? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 01:55:44 -0000 A client is asking me to recommend hardware for a mailserver; they're an OEM and whitebox builder, and would prefer to use an Intel server board which seems reasonable. Are there any particularly recommended current models? I seem to recall that Intel's RAID hardware is not that reliable, so I am assuming I should either recommend they use plain SATA or SAS drives, or steer them to an external RAID system with dedicated controller. If that's changed, it would be nice to know. Parameters: The system will not be very high-throughput, primarily fronting and acting as relay and storage queue for initially about 5000 mailboxes in 100+ domains. All spam filtering will be handled on another box. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 06:00:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D05FB1065670 for ; Mon, 12 Oct 2009 06:00:08 +0000 (UTC) (envelope-from kris.weston@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 623648FC14 for ; Mon, 12 Oct 2009 06:00:08 +0000 (UTC) Received: by ewy18 with SMTP id 18so2573540ewy.43 for ; Sun, 11 Oct 2009 23:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=kCrHhc346U6/7PdX+7/PI6H7RNJMr+wEftF0LPrklQs=; b=lfVc0cYMh9C+z/ZO4eHeO4N5/3tBGNuWLs5dYruRaWxFu9TvLPrIzVEltQEskQIXjq OkT1EJ94Yq9Fdt3dVpy0DhPrRKBiheTXUH2m4/W+XD4UyInBB3SlHR5JwSO+uWlvfntW HkNAtFzw6O447AicIYO5USUFzgfDSSidl/icc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HjVyDT3N+eT+yXPh/UTz6/d4+wnQuE+mJEOEWeFCGUmjo9XP/GbDJObxtAyfjfk//p nSoNWK2Ku/xr+NOl8j7rrY/8FjkNw8tDu5XN+azuEA6ms2gWVeY2Ma6AYaQK4A7/G7nL bi6HEvatng56oBx78ehi1Do4uv7xb4NCzTXq8= MIME-Version: 1.0 Received: by 10.216.86.211 with SMTP id w61mr1813868wee.6.1255325650509; Sun, 11 Oct 2009 22:34:10 -0700 (PDT) Date: Mon, 12 Oct 2009 06:34:10 +0100 Message-ID: <72d267bc0910112234v62d2ca79h7aeea8d25789d0cc@mail.gmail.com> From: Kris Weston To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: corrupt GPT tables on open solaris zfs import X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 06:00:08 -0000 hi guys n gals, im getting a problem about corrupt GPT tables upon trying to import my solaris mirror. should i just overwrite the GPT ? and if anyone can tell me how that would be awesome ? im on 7.2 stable zfs v13 ive seen its a known issue on the forums but cant see a solution ? thanks -- )) (( c[_] From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 06:10:42 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF02106568F for ; Mon, 12 Oct 2009 06:10:42 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 91A998FC12 for ; Mon, 12 Oct 2009 06:10:41 +0000 (UTC) Received: by ewy18 with SMTP id 18so2577408ewy.43 for ; Sun, 11 Oct 2009 23:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=nMQ1Yvhfrs4F86SohPKDnrblQtNywB8UnLKdwEsfG68=; b=CIQ9/W/d6200m8knZP4+s/BlgZcLI4KO9Ug3erTgJ0RJMIRRjv2PXVXCHdgZqDFq2O wcYm1VjQ1xQFZVt7Hh275cy8HfLFNGUKC4TMyUC/oSUFyFIk8g67+Rne+Hyr90fMgPar f9U+Ovmzb+teAIBd0V4HxhYY6s63/4gZ6GqZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=xFMJIZEmNAPox2KS44eV0HeezoqXuSYl6D+7fBopWyUmVIC/HNdPI3vZmmw68BxU9H kfnWzxO/fkVtFcR0pZfzSGPAJSdh1STHoqAlIZGsT8Stbrj8oK7vO51XaNz17xr0CYAp 32rC09+AGv3673JlmN9/gZmW5sVmB3tj1/gvw= Received: by 10.210.9.7 with SMTP id 7mr6606067ebi.5.1255326563591; Sun, 11 Oct 2009 22:49:23 -0700 (PDT) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 10sm936683eyd.30.2009.10.11.22.49.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Oct 2009 22:49:22 -0700 (PDT) To: Ed Schouten References: <20091011201715.GY71731@hoeg.nl> Organization: TOA Ukraine From: Mikolaj Golub Date: Mon, 12 Oct 2009 08:49:20 +0300 In-Reply-To: <20091011201715.GY71731@hoeg.nl> (Ed Schouten's message of "Sun\, 11 Oct 2009 22\:17\:15 +0200") Message-ID: <81k4z1p3fj.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stable@FreeBSD.org Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 06:10:42 -0000 On Sun, 11 Oct 2009 22:17:15 +0200 Ed Schouten wrote: > Hello Mikolaj, > > It is indeed true that the new TTY layer restricts the baud rate to > 9600. We could consider clamping the baud rate between a certain range, > to prevent the TTY buffer size from growing excessively. > > So what kind of buffer size are you interested in? Would 115200 / 5 be > enough? I have reviewed my logs for the last period and the line with maximum length I have found was 6521 characters. And if I filter only those lines that I am usually interested in then the maximum lenght has been 3288. So 115200/5=23040 would be more then enough for me :-) Thanks, -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 07:08:31 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1F811065672 for ; Mon, 12 Oct 2009 07:08:31 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 409AD8FC1C for ; Mon, 12 Oct 2009 07:08:31 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 005D81CD0B; Mon, 12 Oct 2009 09:08:29 +0200 (CEST) Date: Mon, 12 Oct 2009 09:08:29 +0200 From: Ed Schouten To: Mikolaj Golub Message-ID: <20091012070829.GA71731@hoeg.nl> References: <20091011201715.GY71731@hoeg.nl> <81k4z1p3fj.fsf@zhuzha.ua1> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9MdG657QzbOEWl1C" Content-Disposition: inline In-Reply-To: <81k4z1p3fj.fsf@zhuzha.ua1> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 07:08:31 -0000 --9MdG657QzbOEWl1C Content-Type: multipart/mixed; boundary="4vu0d+lqoSa2/ZEk" Content-Disposition: inline --4vu0d+lqoSa2/ZEk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Mikolaj Golub wrote: > So 115200/5=3D23040 would be more then enough for me :-) Great. I've attached a patch that should allow the buffer size to be configured. Unfortunately gettytab currently sets the baud rate to 115200, which means we'll always use buffer sizes. I think we'd better just remove the baud rate assignment and let the kernel decide which default baud rate for the console is the best. I'll commit the patch within the next couple of days. Let me know whether you experience any problems with it. --=20 Ed Schouten WWW: http://80386.nl/ --4vu0d+lqoSa2/ZEk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="tty.diff" Content-Transfer-Encoding: quoted-printable Index: etc/gettytab =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- etc/gettytab (revision 197973) +++ etc/gettytab (working copy) @@ -162,7 +162,7 @@ :fd@:nd@:cd@:rw:sp#9600: =20 P|Pc|Pc console:\ - :ht:np:sp#115200: + :ht:np: =20 # # Wierdo special case for fast crt's with hardcopy devices Index: sys/kern/tty.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 --- sys/kern/tty.c (revision 197973) +++ sys/kern/tty.c (working copy) @@ -842,8 +842,19 @@ ttydevsw_defparam(struct tty *tp, struct termios *t) { =20 - /* Use a fake baud rate, we're not a real device. */ - t->c_ispeed =3D t->c_ospeed =3D TTYDEF_SPEED; + /* + * Allow the baud rate to be adjusted for pseudo-devices, but at + * least restrict it to 115200 to prevent excessive buffer + * usage. Also disallow 0, to prevent foot shooting. + */ + if (t->c_ispeed < B50) + t->c_ispeed =3D B50; + else if (t->c_ispeed > B115200) + t->c_ispeed =3D B115200; + if (t->c_ospeed < B50) + t->c_ospeed =3D B50; + else if (t->c_ospeed > B115200) + t->c_ospeed =3D B115200; =20 return (0); } --4vu0d+lqoSa2/ZEk-- --9MdG657QzbOEWl1C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrS1e0ACgkQ52SDGA2eCwWAVQCdE+bmZOAHZjdek3D/+Kg2ylBk lDMAni22ckCPX6k9/tGHC3O52oc2vsdD =kDPP -----END PGP SIGNATURE----- --9MdG657QzbOEWl1C-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 09:01:29 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47AF0106568D for ; Mon, 12 Oct 2009 09:01:29 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id C39698FC1D for ; Mon, 12 Oct 2009 09:01:28 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id d23so932744fga.13 for ; Mon, 12 Oct 2009 02:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=NT9SZ7IeAZGYabzz9v19Je98rWd2bAAc2e5/GCxR7CU=; b=Nf8s8LwPnl0HhT36s0SrwX4tjpkLkOcOF1qDY3oqE+xu1t5/gLo+V0xRAvQMAu1/+4 hAoC3h8waXYJKtu70UMF22xBArP8n5hzzAfPz2DTEwaNirQAkN8eLYIu4qNbzAggB7xO 5G2FqRAx1krvKzys9Yr+BRHkCi9UaNUvyeqLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=eiIvvbTftchuwXRcc33do5KeHlIKUhodXq17aGL2Guku+k5TsoGErxVj7cNQb7xZhL LYo2GY6GM12w+4Fx3eh9LFxOBbVYsrYK15hakw8H5tK0DirzGlAVVAStmip4lXEcYxn0 PQU3XhARVkTJntPtmvjY8ExHsrd5QCwLhZYAM= Received: by 10.86.238.30 with SMTP id l30mr1221793fgh.75.1255338087654; Mon, 12 Oct 2009 02:01:27 -0700 (PDT) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 12sm4042509fgg.16.2009.10.12.02.01.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Oct 2009 02:01:26 -0700 (PDT) To: Ed Schouten References: <20091011201715.GY71731@hoeg.nl> <81k4z1p3fj.fsf@zhuzha.ua1> <20091012070829.GA71731@hoeg.nl> Organization: TOA Ukraine From: Mikolaj Golub Date: Mon, 12 Oct 2009 12:01:24 +0300 In-Reply-To: <20091012070829.GA71731@hoeg.nl> (Ed Schouten's message of "Mon\, 12 Oct 2009 09\:08\:29 +0200") Message-ID: <81iqelhtp7.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: stable@FreeBSD.org, Mikolaj Golub Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:01:29 -0000 On Mon, 12 Oct 2009 09:08:29 +0200 Ed Schouten wrote: > * Mikolaj Golub wrote: >> So 115200/5=23040 would be more then enough for me :-) > > Great. I've attached a patch that should allow the buffer size to be > configured. Unfortunately gettytab currently sets the baud rate to > 115200, which means we'll always use buffer sizes. I think we'd better > just remove the baud rate assignment and let the kernel decide which > default baud rate for the console is the best. > > I'll commit the patch within the next couple of days. Let me know > whether you experience any problems with it. Applied and it works for me. Thanks. If I notice any issues I will let you know :-) -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 09:45:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D0381065697 for ; Mon, 12 Oct 2009 09:45:24 +0000 (UTC) (envelope-from daniel@roe.ch) Received: from calvin.ustdmz.roe.ch (calvin.ustdmz.roe.ch [IPv6:2001:41e0:ff17:face::26]) by mx1.freebsd.org (Postfix) with ESMTP id 98AD98FC1C for ; Mon, 12 Oct 2009 09:45:23 +0000 (UTC) Received: from roe (ssh-from [roe on from]) by calvin.ustdmz.roe.ch (envelope-from ) with LOCAL id 1MxHSx-0007n2-P2 for freebsd-stable@FreeBSD.ORG; Mon, 12 Oct 2009 11:45:19 +0200 Date: Mon, 12 Oct 2009 11:45:19 +0200 From: Daniel Roethlisberger To: freebsd-stable@FreeBSD.ORG Message-ID: <20091012094519.GA29445@calvin.ustdmz.roe.ch> Mail-Followup-To: freebsd-stable@FreeBSD.ORG References: <200910081823.n98INRVZ082461@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: openssh concerns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 09:45:24 -0000 Robert Watson 2009-10-11: > On Thu, 8 Oct 2009, Oliver Fromme wrote: > >Are you sure? The majority of BSD machines in my vicinity > >have multiple accounts. > > > >And even if there's only one account, there is no reason to be > >careless with potential port-takeover risks. > > > >Therefore I advise against running critical daemons on > >unprivileged ports, especially on machines with shell > >accounts. And if you need to bind to a port >= 1024, use > >mac_portacl(4) to protect it. It's easy to use. > >Alternatively you can increase the value of the sysctl > >net.inet.ip.portrange.reservedhigh, but this is less flexible > >and might have unwanted side effects. > > And, for those that haven't already noticed, "options MAC" is > compiled into GENERIC on 8.0, so working with MAC policies no > longer requires a recompile (or in many cases, even a reboot). If your situation allows running pf, then there's an alternative method: bind sshd normally to port 22, but use pf to deny direct connections to port 22, redirecting connections to some high port X to port 22 using a `rdr pass' rule. You can even make exceptions for trusted IP address ranges which are then allowed to SSH in directly on port 22. That way, an unprivileged process will gain nothing by listening on high port X; it won't get to accept() any SSH connections. -- Daniel Roethlisberger http://daniel.roe.ch/ From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 11:50:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A71151065672 for ; Mon, 12 Oct 2009 11:50:31 +0000 (UTC) (envelope-from howard@leadmon.net) Received: from ibm.leadmon.net (ibm.leadmon.net [207.114.24.13]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBF28FC14 for ; Mon, 12 Oct 2009 11:50:30 +0000 (UTC) Received: from HDLDESKTOP64 (hdl-desktop-64.leadmon.net [207.114.24.3]) (authenticated bits=0) by ibm.leadmon.net (8.14.3/8.14.3/LNSG+SCOP+PSBL+LUBL+NJABL+SBL+DSBL+SORBS+CBL+RHSBL) with ESMTP id n9CBVTLs098791 for ; Mon, 12 Oct 2009 07:31:29 -0400 (EDT) (envelope-from howard@leadmon.net) X-DKIM: Sendmail DKIM Filter v2.8.3 ibm.leadmon.net n9CBVTLs098791 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leadmon.net; s=default; t=1255347089; bh=xkIn/ssiB36mx4p5cik8Do9GHiH3ul/GAMSEnUmNV6o=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ZFW1pds5q/zCoeRqdjU5a8qJa8FkP6ApS/kp4ghapk0sV6+3OpLJi48bp5ynOnv9C ROix/LvDDik3P7JY2Gffq06Is5xbeF5zzxfyf/dxvmSeHYHOoGHdbMZru3fyluTtBy pp1m0Q/SDorNjRyrEJAR4yDCun7vXf0TPYGDVccE= X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 ibm.leadmon.net n9CBVTLs098791 DomainKey-Signature: a=rsa-sha1; s=default; d=leadmon.net; c=simple; q=dns; h=x-senderid:authentication-results:from:to:subject:date: message-id:mime-version:content-type:x-mailer:thread-index:content-language; b=Dk1hyn1Qb11jsuJcU0GVX/qC6JPANxF4325CadauL/GZKvuwfXZWXffBig20kWCub /UXGLg+CRu/Y7iPN45hvL92Db3vbAi8oJTkqxjYZm98aDW8t8iip28HreNU/qOSausN cB/RZvXmdYf58VH6VRokSxgOnqc7v7YmZ4VOJxI= X-SenderID: Sendmail Sender-ID Filter v1.0.0 ibm.leadmon.net n9CBVTLs098791 Authentication-Results: ibm.leadmon.net; sender-id=pass header.from=howard@leadmon.net; spf=pass smtp.mfrom=howard@leadmon.net From: "Howard Leadmon" To: Date: Mon, 12 Oct 2009 07:31:26 -0400 Message-ID: <002001ca4b2f$8aa3fef0$9febfcd0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcpLL4i6hrMwEY4wRP+cGKSI4HkmNw== Content-Language: en-us X-Virus-Scanned: clamav-milter 0.95.2 at ibm.leadmon.net X-Virus-Status: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kernel Build Issues with latest cvsup of both a 7.2 system, and a 6.4 system.. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 11:50:31 -0000 Not sure if I am just having a run of bad luck here, but I have a bunch of various free BSD boxen on both 6.4-STABLE, and on 7.2-STABLE. I try and make it a point to do a cvsup and update the machines every month or so to keep things current and any updates/patches installed. I decided a couple days ago, it was again time to do this again. So I ran cvsup on the machines, and set out to rebuild, first doing a 'make buildworld', then a 'make installworld', and finally a 'mergemaster' on the servers. That all went well, then time for a kernel update, so I performed a 'make buildkernel KERNCONF=GENERIC' to create the new kernel, which is where things went bad. On my 6.4-STABLE x86 machine, I received the following: cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/kern/kern_event.c /usr/src/sys/kern/kern_event.c:408: warning: no previous prototype for 'knote_fork' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. On my 7.2-STABLE amd64 machine, I received the following: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/vm/pmap.h:82, from /usr/src/sys/amd64/amd64/genassym.c:61: ./machine/pmap.h:323: error: expected declaration specifiers or '...' before 'vm_memattr_t' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 I have rebuilt the above servers many times over, and I must say it's worked great, so was really thrown that not only one version on a server would blow up, but two different versions of the OS would pop at the same moment. Needless to say I haven't tried to rebuild any of my other 6.4 or 7.2 boxen yet, as I want to get the above two attempts sorted out first. Has something changed I am forgetting to do that is not biting me in the backside, or has some bug been introduced I am now aware of currently causing issues?? If anyone can help sort this out, or if you need additional info, please let me know.. --- Howard Leadmon From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 12:38:45 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12A0D106568F for ; Mon, 12 Oct 2009 12:38:45 +0000 (UTC) (envelope-from lists@mawer.org) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id EB2528FC0C for ; Mon, 12 Oct 2009 12:38:44 +0000 (UTC) Received: by pzk40 with SMTP id 40so9050124pzk.7 for ; Mon, 12 Oct 2009 05:38:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.157.21 with SMTP id f21mr465041rve.48.1255349226693; Mon, 12 Oct 2009 05:07:06 -0700 (PDT) In-Reply-To: <20091012015542.GB2096@lava.net> References: <20091012015542.GB2096@lava.net> Date: Mon, 12 Oct 2009 23:07:06 +1100 Message-ID: From: Antony Mawer To: Clifton Royston Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: Any recommended Intel server motherboards? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 12:38:45 -0000 The Intel boards all in all tend to be pretty well supported... we run a number of S3200SHL boards (about to be EOL'd I believe) and older S2000 series in production without any hitches. The basic Intel soft-RAID on the entry level boards should be avoided (use gmirror or similar if need be). If you are looking at any of the boards with onboard SAS, this is usually an LSI Logic based chipset (mfi driver from memory) and is fine as far as RAID reliability goes (at least in our experience, YMMV)... -- Antony On Mon, Oct 12, 2009 at 12:55 PM, Clifton Royston wrote= : > =A0A client is asking me to recommend hardware for a mailserver; they're > an OEM and whitebox builder, and would prefer to use an Intel server > board which seems reasonable. =A0Are there any particularly recommended > current models? > > =A0I seem to recall that Intel's RAID hardware is not that reliable, so > I am assuming I should either recommend they use plain SATA or SAS > drives, or steer them to an external RAID system with dedicated > controller. =A0If that's changed, it would be nice to know. > > Parameters: > > =A0The system will not be very high-throughput, primarily fronting and > acting as relay and storage queue for initially about 5000 mailboxes in > 100+ domains. =A0All spam filtering will be handled on another box. > > =A0-- Clifton > > -- > =A0 =A0Clifton Royston =A0-- =A0cliftonr@iandicomputing.com / cliftonr@la= va.net > =A0 =A0 =A0 President =A0- I and I Computing * http://www.iandicomputing.= com/ > =A0Custom programming, network design, systems and network consulting ser= vices > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 13:42:19 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A386106568D for ; Mon, 12 Oct 2009 13:42:19 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id F288A8FC0A for ; Mon, 12 Oct 2009 13:42:18 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n9CDg1F4066567; Mon, 12 Oct 2009 15:42:16 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n9CDg19g066566; Mon, 12 Oct 2009 15:42:01 +0200 (CEST) (envelope-from olli) Date: Mon, 12 Oct 2009 15:42:01 +0200 (CEST) Message-Id: <200910121342.n9CDg19g066566@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20091012094519.GA29445@calvin.ustdmz.roe.ch> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 12 Oct 2009 15:42:16 +0200 (CEST) Cc: Subject: Re: openssh concerns X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 13:42:19 -0000 Daniel Roethlisberger wrote: > If your situation allows running pf, then there's an alternative > method: bind sshd normally to port 22, but use pf to deny direct > connections to port 22, redirecting connections to some high port > X to port 22 using a `rdr pass' rule. You can even make > exceptions for trusted IP address ranges which are then allowed > to SSH in directly on port 22. That way, an unprivileged process > will gain nothing by listening on high port X; it won't get to > accept() any SSH connections. Just for completeness sake, the same can be done easily with IPFW and "fwd" rules, of course. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mn- chen, HRB 125758, Geschftsfhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 19:49:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96949106566B for ; Mon, 12 Oct 2009 19:49:14 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id BE02E8FC1A for ; Mon, 12 Oct 2009 19:49:13 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:41729 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MxQsv-0004Sf-5h for freebsd-stable@freebsd.org; Mon, 12 Oct 2009 21:48:51 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 88F2DE734 for ; Mon, 12 Oct 2009 21:48:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) From: Thomas Backman In-Reply-To: Date: Mon, 12 Oct 2009 21:48:42 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: freebsd-stable X-Mailer: Apple Mail (2.1076) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1MxQsv-0004Sf-5h. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MxQsv-0004Sf-5h 5ee14a7e1df82b362179e63cef7d697b Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 19:49:14 -0000 I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. How to reproduce/test: 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a common/average/median/whatever time. 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will squish this into a kilobyte-sized file, thus creating virtually *no* IO. 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency is closer to 4%. A bit better than, oh, 400 times. ;) Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. Regards, Thomas PS. I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a new post with an addition below.) On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > Hey everyone, > I'm having serious trouble with the same thing, and just found this > thread while looking for the correct place to post. Looks like I > found it. (I wrote most of the post before finding the thread, so > some of it will seem a bit odd.) > > I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > 80GB 7200rpm disk. > > My problem is that I get completely unacceptable latency on console > IO (both via SSH and serial console) when the system is performing > disk IO. The worst case I've noticed yet was when I tried copying a > core dump from a lzjb compressed ZFS file system to a gzip-9 > compressed one, to compare the file size/compression ratio. screen > (1) took at LEAST ten seconds - probably a bit more - I'm not > exaggerating here - to switch to another window, and an "ls" in an > empty directory also about 5-10 seconds. > Doing some silly CPU load with two instances of "yes >/dev/null" (on > a single core, remember) doesn't change anything, the system remains > very responsive. "cat /dev/zero > /uncompressed_fs/..." however > produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the > file ends up extremely small - a kilobyte or so - even after a > while, thus performing minimal IO). > > I'm thinking about switching to FreeBSD on my beefier "production" > system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, > single-core, 2GB RAM, 80GB disk), but unless I feel assured this > won't happen there as well, I'm not so sure anymore. I can do any > kind of heavy IO/compilation/whatever on that box, currently running > Linux, and it's always unnoticable. In this case it's impossible > *not* to notice that your key input is lagging behind 5-10 > seconds... I thought multiple times that the box must have panicked. > I do realize that the hardware isn't the best, especially the disks, > but this is far worse than it should be! > > Here's some of the testing done in this thread (or at least > something like it): > > [root@chaos ~]# time file /etc/* >/dev/null > real 0m1.725s > user 0m0.993s > sys 0m0.021s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.008s > user 0m0.990s > sys 0m0.015s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.008s > user 0m0.967s > sys 0m0.038s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.015s > user 0m0.998s > sys 0m0.008s > > So, pretty much exactly 1 second every time once the cache is warmed > up. Now, let's try it 10 seconds after starting heavy disk writing... > > [root@chaos ~]# cat /dev/zero > /DELETE_ME & > (wait for 10 seconds) > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m13.217s > user 0m1.004s > sys 0m0.023s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m24.012s > user 0m1.020s > sys 0m0.008s > > ... the numbers speak for themselves. FWIW I tried the same on the > Linux box: "file" took 0.8 seconds the first time, 0.125s subsequent > times. While running cat, 0.13-0.21 seconds (0.21 being the first, > subsequent runs took 0.13s). The system remained completely > responsive, which cannot be said for the FreeBSD one! > > Any advice? Info below - please ask if you need more! > > Regards, > Thomas > > ----------------------------------------------------------------------------- > > Basic info: > > [root@chaos ~]# uname -a > FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue > Sep 29 15:04:44 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/ > src/sys/DTRACE amd64 > (KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) > > [root@chaos ~]# mount > tank/root on / (zfs, local, noatime) > devfs on /dev (devfs, local, multilabel) > /dev/ad0s1a on /bootdir (ufs, local, soft-updates) > tank/export on /export (zfs, NFS exported, local, noatime) > tank/tmp on /tmp (zfs, local, noatime) > tank/usr on /usr (zfs, local, noatime) > tank/usr/obj on /usr/obj (zfs, local, noatime) > tank/usr/ports on /usr/ports (zfs, local, noatime) > tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) > tank/usr/src on /usr/src (zfs, local, noatime) > tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- > only) > tank/var on /var (zfs, local, noatime) > tank/var/crash on /var/crash (zfs, local, noatime) > tank/var/log on /var/log (zfs, local, noatime) > tank/var/tmp on /var/tmp (zfs, local, noatime) > > dmesg: > > ----------------------------------------------------------------------------- > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 > root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 > > Features > = > 0x78bfbff > < > FPU > ,VME > ,DE > ,PSE > ,TSC > ,MSR > ,PAE > ,MCE > ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > AMD Features=0xe2500800 > AMD Features2=0x1 > real memory = 2147483648 (2048 MB) > avail memory = 2052362240 (1957 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7fef0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xfe02f000-0xfe02ffff irq > 21 at device 2.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ehci0: mem 0xfe02e000-0xfe02e0ff > irq 22 at device 2.1 on pci0 > ehci0: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem > 0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem > 0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > vgapci0: mem 0xfcff8000-0xfcffbfff, > 0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 on > pci1 > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem > 0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl0: Ethernet address: 00:50:da:44:c0:4a > xl0: [ITHREAD] > nfe0: port > 0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on pci0 > miibus1: on nfe0 > e1000phy0: PHY 1 on miibus1 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > nfe0: Ethernet address: 00:13:d3:a2:aa:0f > nfe0: [FILTER] > pcib2: at device 11.0 on pci0 > pci2: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > pcib4: at device 13.0 on pci0 > pci4: on pcib4 > pcib5: at device 14.0 on pci0 > pci5: on pcib5 > amdtemp0: on hostb3 > acpi_tz0: on acpi0 > atrtc0: port 0x70-0x73 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > uart0: [FILTER] > uart0: console (115200,n,8,1) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > cpu0: on acpi0 > powernow0: on cpu0 > device_attach: powernow0 attach returned 6 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, > 0xcc000-0xcc7ff 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 > ZFS NOTICE: system has less than 4GB and prefetch enable is not > set... disabling. > ZFS filesystem version 13 > ZFS storage pool version 13 > Timecounter "TSC" frequency 2009269513 Hz quality 800 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ad0: 76318MB at ata0-master UDMA100 > ugen0.1: at usbus0 > uhub0: on > usbus0 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ad2: 9768MB at ata1-master UDMA100 > GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). > Root mount waiting for: usbus1 usbus0 > uhub0: 10 ports with 10 removable, self powered > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > uhub1: 10 ports with 10 removable, self powered > Trying to mount root from zfs:tank/root > netsmb_dev: loaded > > ----------------------------------------------------------------------------- > The 80GB disk is used for everything except swap (aka. dump device) > for which the 10GB disk is used, exclusively. > > loader.conf has nothing of value (just loading a few modules and a > vfs.root.mountfrom, plus serial console settings). From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 21:41:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAA301065672 for ; Mon, 12 Oct 2009 21:41:14 +0000 (UTC) (envelope-from prvs=1536df4ea9=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 1DE0B8FC14 for ; Mon, 12 Oct 2009 21:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1255383070; x=1255987870; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=gDSuCgrz5Vxn58wVfvvB1 eplerQxB+0vVZLLc8pnQTY=; b=fHhl9yylF8ZbitwfaNSqUqEp1gPFGzxFAe9Ks GpGdZvtk9plLl2CpiQWMIxLdkQwfAM9yXHZ9fRJJwNsnCoPrJ0o3KTSEjPToGmWm b7DW85RUr+TVo9wtmChVeTUeUsnuB+a5bjp0gMllvSOqbVid7QMtWjl+kTyZQ1WQ IoeI48= X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 12 Oct 2009 22:31:10 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008361045.msg for ; Mon, 12 Oct 2009 22:31:10 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 12 Oct 2009 22:31:10 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1536df4ea9=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> From: "Steven Hartland" To: "Thomas Backman" , "freebsd-stable" References: Date: Mon, 12 Oct 2009 22:31:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 21:41:14 -0000 We're not running 8 yet but we do have a 7.x box which its under fairly high IO load doing mrtg graphs which has similar behaviour. When typing a command on ssh it will freeze for may seconds. I even went to far as to write a little C app which just prints out the time to screen and even that sees the big delay. Its always been like and I've never managed to get to the bottom of it, there's something in the IO / disk subsystem which can totally lock up the system under high IO load. Regards Steve ----- Original Message ----- From: "Thomas Backman" To: "freebsd-stable" Sent: Monday, October 12, 2009 8:48 PM Subject: Extreme console latency during disk IO (8.0-RC1,previous releases also affected according to others) > I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am > having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to > switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial > console. > > How to reproduce/test: > 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a > common/average/median/whatever time. > 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will > squish this into a kilobyte-sized file, thus creating virtually *no* IO. > 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. > > I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my > sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the > "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such > as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency > is closer to 4%. A bit better than, oh, 400 times. ;) > > Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these > issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch > to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. > > Regards, > Thomas > > PS. > > I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a > new post with an addition below.) > > On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > >> Hey everyone, >> I'm having serious trouble with the same thing, and just found this thread while looking for the correct place to post. Looks >> like I found it. (I wrote most of the post before finding the thread, so some of it will seem a bit odd.) >> >> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old 80GB 7200rpm disk. >> >> My problem is that I get completely unacceptable latency on console IO (both via SSH and serial console) when the system is >> performing disk IO. The worst case I've noticed yet was when I tried copying a core dump from a lzjb compressed ZFS file >> system to a gzip-9 compressed one, to compare the file size/compression ratio. screen (1) took at LEAST ten seconds - probably >> a bit more - I'm not exaggerating here - to switch to another window, and an "ls" in an empty directory also about 5-10 >> seconds. >> Doing some silly CPU load with two instances of "yes >/dev/null" (on a single core, remember) doesn't change anything, the >> system remains very responsive. "cat /dev/zero > /uncompressed_fs/..." however produces the extreme slowdown. (On a gzip-1 FS >> it doesn't, since the file ends up extremely small - a kilobyte or so - even after a while, thus performing minimal IO). >> >> I'm thinking about switching to FreeBSD on my beefier "production" system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to >> this one, single-core, 2GB RAM, 80GB disk), but unless I feel assured this won't happen there as well, I'm not so sure >> anymore. I can do any kind of heavy IO/compilation/whatever on that box, currently running Linux, and it's always >> unnoticable. In this case it's impossible *not* to notice that your key input is lagging behind 5-10 seconds... I thought >> multiple times that the box must have panicked. >> I do realize that the hardware isn't the best, especially the disks, but this is far worse than it should be! >> >> Here's some of the testing done in this thread (or at least something like it): >> >> [root@chaos ~]# time file /etc/* >/dev/null >> real 0m1.725s >> user 0m0.993s >> sys 0m0.021s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.008s >> user 0m0.990s >> sys 0m0.015s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.008s >> user 0m0.967s >> sys 0m0.038s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.015s >> user 0m0.998s >> sys 0m0.008s >> >> So, pretty much exactly 1 second every time once the cache is warmed up. Now, let's try it 10 seconds after starting heavy >> disk writing... >> >> [root@chaos ~]# cat /dev/zero > /DELETE_ME & >> (wait for 10 seconds) >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m13.217s >> user 0m1.004s >> sys 0m0.023s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m24.012s >> user 0m1.020s >> sys 0m0.008s >> >> ... the numbers speak for themselves. FWIW I tried the same on the Linux box: "file" took 0.8 seconds the first time, 0.125s >> subsequent times. While running cat, 0.13-0.21 seconds (0.21 being the first, subsequent runs took 0.13s). The system >> remained completely responsive, which cannot be said for the FreeBSD one! >> >> Any advice? Info below - please ask if you need more! >> >> Regards, >> Thomas >> >> ----------------------------------------------------------------------------- >> >> Basic info: >> >> [root@chaos ~]# uname -a >> FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 >> root@chaos.exscape.org:/usr/obj/usr/ src/sys/DTRACE amd64 >> (KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) >> >> [root@chaos ~]# mount >> tank/root on / (zfs, local, noatime) >> devfs on /dev (devfs, local, multilabel) >> /dev/ad0s1a on /bootdir (ufs, local, soft-updates) >> tank/export on /export (zfs, NFS exported, local, noatime) >> tank/tmp on /tmp (zfs, local, noatime) >> tank/usr on /usr (zfs, local, noatime) >> tank/usr/obj on /usr/obj (zfs, local, noatime) >> tank/usr/ports on /usr/ports (zfs, local, noatime) >> tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) >> tank/usr/src on /usr/src (zfs, local, noatime) >> tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- only) >> tank/var on /var (zfs, local, noatime) >> tank/var/crash on /var/crash (zfs, local, noatime) >> tank/var/log on /var/log (zfs, local, noatime) >> tank/var/tmp on /var/tmp (zfs, local, noatime) >> >> dmesg: >> >> ----------------------------------------------------------------------------- >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 >> root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 >> Features = 0x78bfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE >> ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> >> AMD Features=0xe2500800 >> AMD Features2=0x1 >> real memory = 2147483648 (2048 MB) >> avail memory = 2052362240 (1957 MB) >> ACPI APIC Table: >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 7fef0000 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: at device 0.0 (no driver attached) >> isab0: at device 1.0 on pci0 >> isa0: on isab0 >> pci0: at device 1.1 (no driver attached) >> ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 >> ohci0: [ITHREAD] >> usbus0: on ohci0 >> ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 >> ehci0: [ITHREAD] >> usbus1: EHCI version 1.0 >> usbus1: on ehci0 >> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on >> pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem >> 0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 >> atapci1: [ITHREAD] >> ata2: on atapci1 >> ata2: [ITHREAD] >> ata3: on atapci1 >> ata3: [ITHREAD] >> atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem >> 0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 >> atapci2: [ITHREAD] >> ata4: on atapci2 >> ata4: [ITHREAD] >> ata5: on atapci2 >> ata5: [ITHREAD] >> pcib1: at device 9.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem 0xfcff8000-0xfcffbfff, 0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 >> on pci1 >> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem 0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 >> miibus0: on xl0 >> xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 >> xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> xl0: Ethernet address: 00:50:da:44:c0:4a >> xl0: [ITHREAD] >> nfe0: port 0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on >> pci0 >> miibus1: on nfe0 >> e1000phy0: PHY 1 on miibus1 >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto >> nfe0: Ethernet address: 00:13:d3:a2:aa:0f >> nfe0: [FILTER] >> pcib2: at device 11.0 on pci0 >> pci2: on pcib2 >> pcib3: at device 12.0 on pci0 >> pci3: on pcib3 >> pcib4: at device 13.0 on pci0 >> pci4: on pcib4 >> pcib5: at device 14.0 on pci0 >> pci5: on pcib5 >> amdtemp0: on hostb3 >> acpi_tz0: on acpi0 >> atrtc0: port 0x70-0x73 irq 8 on acpi0 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart0: console (115200,n,8,1) >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> cpu0: on acpi0 >> powernow0: on cpu0 >> device_attach: powernow0 attach returned 6 >> orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, 0xcc000-0xcc7ff 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 >> ZFS NOTICE: system has less than 4GB and prefetch enable is not set... disabling. >> ZFS filesystem version 13 >> ZFS storage pool version 13 >> Timecounter "TSC" frequency 2009269513 Hz quality 800 >> Timecounters tick every 1.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 480Mbps High Speed USB v2.0 >> ad0: 76318MB at ata0-master UDMA100 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ad2: 9768MB at ata1-master UDMA100 >> GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). >> Root mount waiting for: usbus1 usbus0 >> uhub0: 10 ports with 10 removable, self powered >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> uhub1: 10 ports with 10 removable, self powered >> Trying to mount root from zfs:tank/root >> netsmb_dev: loaded >> >> ----------------------------------------------------------------------------- >> The 80GB disk is used for everything except swap (aka. dump device) for which the 10GB disk is used, exclusively. >> >> loader.conf has nothing of value (just loading a few modules and a vfs.root.mountfrom, plus serial console settings). > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ================================================ 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-stable@FreeBSD.ORG Mon Oct 12 22:28:38 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C515A1065692 for ; Mon, 12 Oct 2009 22:28:38 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 175D48FC08 for ; Mon, 12 Oct 2009 22:28:38 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id D1A4E730DA; Tue, 13 Oct 2009 00:35:29 +0200 (CEST) Date: Tue, 13 Oct 2009 00:35:29 +0200 From: Luigi Rizzo To: Thomas Backman Message-ID: <20091012223529.GA77733@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 22:28:38 -0000 On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > I'm copying this over from the freebsd-performance list, as I'm > looking for a few more opinions - not on the problems *I* am having, > but rather to check whether the problem is universal or not, and if > not, find a possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > Long story short, my version: when the disk is stressed hard enough, > console IO becomes COMPLETELY unbearable. 10+ seconds to switch > between windows in screen(1), running (or even typing) simple > commands, etc. This happens both via SSH and the serial console. hi, this issue (not specific to FreeBSD, and not new -- it has been like this forever) is discussed in some detail here http://www.bsdcan.org/2009/schedule/events/122.en.html The following code (a bit outdated) can help http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html cheers luigi > How to reproduce/test: > 1) time file /etc/* > /dev/null a few times, or something similar that > uses the disk; write down a common/average/median/whatever time. > 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's > uncompressed, since ZFS with lzjb/gzip enabled will squish this into a > kilobyte-sized file, thus creating virtually *no* IO. > 3) When cat has been running say 10 seconds, re-time command #1 and do > some interactive stuff - run commands, edit files, etc. > > I couldn't actually reproduce the *completely* horrific increase in > latency I posted about below just now (I did update my sources and > rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had > no major IO changes in 8-STABLE), and the "time file /etc/*" test > "only" jumped by about 3x (compared to 20-60x+ previously), but it's > still bad enough: commands such as "ls" and "w" take 2-3 seconds to > run, as opposed to 0.005s for ls without the added IO... On Linux, the > increase in latency is closer to 4%. A bit better than, oh, 400 > times. ;) > > Oh, and again: this post is not a complaint; this is a post asking for > your experiences. I know I'm not alone in having these issues - I just > want to know if there are a lot of people that *don't* too, and what > could cause them. I can't possibly switch to FreeBSD in production > with this behaviour - and I've been looking forward to doing so for > quite a while now. > > Regards, > Thomas > > PS. > > I'll leave my post to the original discussion below. (I don't usually > top post, but I don't consider this a reply, more of a new post with > an addition below.) > > On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > > >Hey everyone, > >I'm having serious trouble with the same thing, and just found this > >thread while looking for the correct place to post. Looks like I > >found it. (I wrote most of the post before finding the thread, so > >some of it will seem a bit odd.) > > > >I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > >80GB 7200rpm disk. > > > >My problem is that I get completely unacceptable latency on console > >IO (both via SSH and serial console) when the system is performing > >disk IO. The worst case I've noticed yet was when I tried copying a > >core dump from a lzjb compressed ZFS file system to a gzip-9 > >compressed one, to compare the file size/compression ratio. screen > >(1) took at LEAST ten seconds - probably a bit more - I'm not > >exaggerating here - to switch to another window, and an "ls" in an > >empty directory also about 5-10 seconds. > >Doing some silly CPU load with two instances of "yes >/dev/null" (on > >a single core, remember) doesn't change anything, the system remains > >very responsive. "cat /dev/zero > /uncompressed_fs/..." however > >produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the > >file ends up extremely small - a kilobyte or so - even after a > >while, thus performing minimal IO). > > > >I'm thinking about switching to FreeBSD on my beefier "production" > >system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, > >single-core, 2GB RAM, 80GB disk), but unless I feel assured this > >won't happen there as well, I'm not so sure anymore. I can do any > >kind of heavy IO/compilation/whatever on that box, currently running > >Linux, and it's always unnoticable. In this case it's impossible > >*not* to notice that your key input is lagging behind 5-10 > >seconds... I thought multiple times that the box must have panicked. > >I do realize that the hardware isn't the best, especially the disks, > >but this is far worse than it should be! > > > >Here's some of the testing done in this thread (or at least > >something like it): > > > >[root@chaos ~]# time file /etc/* >/dev/null > >real 0m1.725s > >user 0m0.993s > >sys 0m0.021s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.008s > >user 0m0.990s > >sys 0m0.015s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.008s > >user 0m0.967s > >sys 0m0.038s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.015s > >user 0m0.998s > >sys 0m0.008s > > > >So, pretty much exactly 1 second every time once the cache is warmed > >up. Now, let's try it 10 seconds after starting heavy disk writing... > > > >[root@chaos ~]# cat /dev/zero > /DELETE_ME & > >(wait for 10 seconds) > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m13.217s > >user 0m1.004s > >sys 0m0.023s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m24.012s > >user 0m1.020s > >sys 0m0.008s > > > >... the numbers speak for themselves. FWIW I tried the same on the > >Linux box: "file" took 0.8 seconds the first time, 0.125s subsequent > >times. While running cat, 0.13-0.21 seconds (0.21 being the first, > >subsequent runs took 0.13s). The system remained completely > >responsive, which cannot be said for the FreeBSD one! > > > >Any advice? Info below - please ask if you need more! > > > >Regards, > >Thomas > > > >----------------------------------------------------------------------------- > > > >Basic info: > > > >[root@chaos ~]# uname -a > >FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue > >Sep 29 15:04:44 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/ > >src/sys/DTRACE amd64 > >(KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) > > > >[root@chaos ~]# mount > >tank/root on / (zfs, local, noatime) > >devfs on /dev (devfs, local, multilabel) > >/dev/ad0s1a on /bootdir (ufs, local, soft-updates) > >tank/export on /export (zfs, NFS exported, local, noatime) > >tank/tmp on /tmp (zfs, local, noatime) > >tank/usr on /usr (zfs, local, noatime) > >tank/usr/obj on /usr/obj (zfs, local, noatime) > >tank/usr/ports on /usr/ports (zfs, local, noatime) > >tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) > >tank/usr/src on /usr/src (zfs, local, noatime) > >tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- > >only) > >tank/var on /var (zfs, local, noatime) > >tank/var/crash on /var/crash (zfs, local, noatime) > >tank/var/log on /var/log (zfs, local, noatime) > >tank/var/tmp on /var/tmp (zfs, local, noatime) > > > >dmesg: > > > >----------------------------------------------------------------------------- > >Copyright (c) 1992-2009 The FreeBSD Project. > >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > >1994 > > The Regents of the University of California. All rights reserved. > >FreeBSD is a registered trademark of The FreeBSD Foundation. > >FreeBSD 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 > > root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE > >Timecounter "i8254" frequency 1193182 Hz quality 0 > >CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) > > Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 > > > >Features > >= > >0x78bfbff > >< > >FPU > >,VME > >,DE > >,PSE > >,TSC > >,MSR > >,PAE > >,MCE > >,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > > AMD Features=0xe2500800 > > AMD Features2=0x1 > >real memory = 2147483648 (2048 MB) > >avail memory = 2052362240 (1957 MB) > >ACPI APIC Table: > >ioapic0 irqs 0-23 on motherboard > >kbd1 at kbdmux0 > >acpi0: on motherboard > >acpi0: [ITHREAD] > >acpi0: Power Button (fixed) > >acpi0: reservation of 0, a0000 (3) failed > >acpi0: reservation of 100000, 7fef0000 (3) failed > >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > >acpi_button0: on acpi0 > >pcib0: port 0xcf8-0xcff on acpi0 > >pci0: on pcib0 > >pci0: at device 0.0 (no driver attached) > >isab0: at device 1.0 on pci0 > >isa0: on isab0 > >pci0: at device 1.1 (no driver attached) > >ohci0: mem 0xfe02f000-0xfe02ffff irq > >21 at device 2.0 on pci0 > >ohci0: [ITHREAD] > >usbus0: on ohci0 > >ehci0: mem 0xfe02e000-0xfe02e0ff > >irq 22 at device 2.1 on pci0 > >ehci0: [ITHREAD] > >usbus1: EHCI version 1.0 > >usbus1: on ehci0 > >atapci0: port > >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on > >pci0 > >ata0: on atapci0 > >ata0: [ITHREAD] > >ata1: on atapci0 > >ata1: [ITHREAD] > >atapci1: port > >0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem > >0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 > >atapci1: [ITHREAD] > >ata2: on atapci1 > >ata2: [ITHREAD] > >ata3: on atapci1 > >ata3: [ITHREAD] > >atapci2: port > >0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem > >0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 > >atapci2: [ITHREAD] > >ata4: on atapci2 > >ata4: [ITHREAD] > >ata5: on atapci2 > >ata5: [ITHREAD] > >pcib1: at device 9.0 on pci0 > >pci1: on pcib1 > >vgapci0: mem 0xfcff8000-0xfcffbfff, > >0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 on > >pci1 > >xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem > >0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 > >miibus0: on xl0 > >xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 > >xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >xl0: Ethernet address: 00:50:da:44:c0:4a > >xl0: [ITHREAD] > >nfe0: port > >0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on pci0 > >miibus1: on nfe0 > >e1000phy0: PHY 1 on miibus1 > >e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >1000baseT, 1000baseT-FDX, auto > >nfe0: Ethernet address: 00:13:d3:a2:aa:0f > >nfe0: [FILTER] > >pcib2: at device 11.0 on pci0 > >pci2: on pcib2 > >pcib3: at device 12.0 on pci0 > >pci3: on pcib3 > >pcib4: at device 13.0 on pci0 > >pci4: on pcib4 > >pcib5: at device 14.0 on pci0 > >pci5: on pcib5 > >amdtemp0: on hostb3 > >acpi_tz0: on acpi0 > >atrtc0: port 0x70-0x73 irq 8 on acpi0 > >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > >acpi0 > >uart0: [FILTER] > >uart0: console (115200,n,8,1) > >atkbdc0: port 0x60,0x64 irq 1 on acpi0 > >atkbd0: irq 1 on atkbdc0 > >kbd0 at atkbd0 > >atkbd0: [GIANT-LOCKED] > >atkbd0: [ITHREAD] > >cpu0: on acpi0 > >powernow0: on cpu0 > >device_attach: powernow0 attach returned 6 > >orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, > >0xcc000-0xcc7ff 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 > >ZFS NOTICE: system has less than 4GB and prefetch enable is not > >set... disabling. > >ZFS filesystem version 13 > >ZFS storage pool version 13 > >Timecounter "TSC" frequency 2009269513 Hz quality 800 > >Timecounters tick every 1.000 msec > >usbus0: 12Mbps Full Speed USB v1.0 > >usbus1: 480Mbps High Speed USB v2.0 > >ad0: 76318MB at ata0-master UDMA100 > >ugen0.1: at usbus0 > >uhub0: on > >usbus0 > >ugen1.1: at usbus1 > >uhub1: on > >usbus1 > >ad2: 9768MB at ata1-master UDMA100 > >GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). > >Root mount waiting for: usbus1 usbus0 > >uhub0: 10 ports with 10 removable, self powered > >Root mount waiting for: usbus1 > >Root mount waiting for: usbus1 > >Root mount waiting for: usbus1 > >uhub1: 10 ports with 10 removable, self powered > >Trying to mount root from zfs:tank/root > >netsmb_dev: loaded > > > >----------------------------------------------------------------------------- > >The 80GB disk is used for everything except swap (aka. dump device) > >for which the 10GB disk is used, exclusively. > > > >loader.conf has nothing of value (just loading a few modules and a > >vfs.root.mountfrom, plus serial console settings). > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Oct 12 23:26:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6F201065695 for ; Mon, 12 Oct 2009 23:26:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1D68FC17 for ; Mon, 12 Oct 2009 23:26:56 +0000 (UTC) Received: (qmail 17224 invoked by uid 399); 12 Oct 2009 23:26:55 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 12 Oct 2009 23:26:55 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AD3BB3E.5000809@FreeBSD.org> Date: Mon, 12 Oct 2009 16:26:54 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Mikolaj Golub References: <861vla2ogy.fsf@kopusha.onet> In-Reply-To: <861vla2ogy.fsf@kopusha.onet> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 23:26:56 -0000 Mikolaj Golub wrote: > Hi, > > On 8.0-RC1 if you run this command: > > cat > /dev/null > > and try to input a long line, the maximum length you can input is 1920 > characters. > > I have investigated a bit how I can increase a tty buffer as this is a problem > for me (I have logs with very long lines and I used to copy&past a particular > line into input of some script to structure it). I have no useful input on the buffer size issue, but if you wanted to post a bit of your script we may be able to help you find a different solution that doesn't involve cat. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 03:55:09 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36AC71065670 for ; Tue, 13 Oct 2009 03:55:09 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 99D108FC24 for ; Tue, 13 Oct 2009 03:55:07 +0000 (UTC) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n9D3t4SP072829; Tue, 13 Oct 2009 11:55:04 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n9D3t47O072828; Tue, 13 Oct 2009 11:55:04 +0800 (KRAST) (envelope-from eugen) Date: Tue, 13 Oct 2009 11:55:04 +0800 From: Eugene Grosbein To: stable@freebsd.org Message-ID: <20091013035504.GA72620@svzserv.kemerovo.su> References: <20091011175428.GA3626@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091011175428.GA3626@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: fs@freebsd.org Subject: Re: FreeBSD Status Reports April - September, 2009 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 03:55:09 -0000 On Sun, Oct 11, 2009 at 05:54:29PM +0000, Daniel Gerzo wrote: > FreeBSD/ZFS > > Contact: Pawel Dawidek > > We believe that the ZFS file system is now production-ready in FreeBSD > 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer > tagged as experimental. There is also ongoing work in Perforce to bring > the latest ZFS version (v19) to FreeBSD. That's great news. However, my experience says me not place dot-zero relese under business-critical tasks and load. What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? Eugene Grosbein From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 05:32:51 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1028106568D; Tue, 13 Oct 2009 05:32:51 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 5648A8FC1E; Tue, 13 Oct 2009 05:32:50 +0000 (UTC) Received: by ewy18 with SMTP id 18so3457072ewy.43 for ; Mon, 12 Oct 2009 22:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:cc:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=u4uSOtNcVq1wBzXLELGJahTc3PNexnX5bmtOrskvJZw=; b=wr6PJz/CtULMUxVAdxYc+ey9IVK2H4X77ICpMl2MFfAUC2+qmOeVAxeaIC2KnNQHoO QS2Ls1zygp8sCcb9OHqSK0vxPW9UZsWWN+yUl4WKOhtlUVIyEQBhzzuLuuw+kIhLxQHJ HJjU4BCArHfyIRhXzwZ64hQ8yvhZiKt59FrZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:cc:subject:references:organization:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=IRZmfYoBjDDq3D66EPZ9gT9QWX0SqUJOzEd7FD/oquv3b0dA1loVgXvFHQ6P3IFry+ woyPv2Vr6HJ8VtIYDKP7jrfyp+vWnEB+eNFwV7p1eHj1AtpUvgtSwBow6mLMscaFyWt1 yRDMAAjZNc78HzuWXc0pzEeBj+GdVqgfQDVEc= Received: by 10.210.7.16 with SMTP id 16mr8257609ebg.14.1255411970263; Mon, 12 Oct 2009 22:32:50 -0700 (PDT) Received: from localhost (ms.singlescrowd.net [80.85.90.67]) by mx.google.com with ESMTPS id 7sm2196423eyg.19.2009.10.12.22.32.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Oct 2009 22:32:49 -0700 (PDT) To: Doug Barton References: <861vla2ogy.fsf@kopusha.onet> <4AD3BB3E.5000809@FreeBSD.org> Organization: TOA Ukraine From: Mikolaj Golub Date: Tue, 13 Oct 2009 08:32:47 +0300 In-Reply-To: <4AD3BB3E.5000809@FreeBSD.org> (Doug Barton's message of "Mon\, 12 Oct 2009 16\:26\:54 -0700") Message-ID: <817huzj1ts.fsf@zhuzha.ua1> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: can't change tty speed and buffer size on 8.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 05:32:52 -0000 On Mon, 12 Oct 2009 16:26:54 -0700 Doug Barton wrote: > Mikolaj Golub wrote: >> Hi, >> >> On 8.0-RC1 if you run this command: >> >> cat > /dev/null >> >> and try to input a long line, the maximum length you can input is 1920 >> characters. >> >> I have investigated a bit how I can increase a tty buffer as this is a problem >> for me (I have logs with very long lines and I used to copy&past a particular >> line into input of some script to structure it). > > I have no useful input on the buffer size issue, but if you wanted to > post a bit of your script we may be able to help you find a different > solution that doesn't involve cat. :) Thanks, but cat was taken as a simple example just to illustrate the problem. The real scripts are usually on perl with 'while(<>)' loop or 'perl -ne' one liners. And sure I could find ways to workaround the problem and actually this is what I did until ed@ provided the solution. -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 07:58:31 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9F5C1065676 for ; Tue, 13 Oct 2009 07:58:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 922208FC17 for ; Tue, 13 Oct 2009 07:58:31 +0000 (UTC) Received: from c83-253-248-99.bredband.comhem.se ([83.253.248.99]:52838 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MxcGr-0005f9-4Z; Tue, 13 Oct 2009 09:58:15 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 8A443E736; Tue, 13 Oct 2009 09:58:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Thomas Backman In-Reply-To: <20091012223529.GA77733@onelab2.iet.unipi.it> Date: Tue, 13 Oct 2009 09:58:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> References: <20091012223529.GA77733@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1076) X-Originating-IP: 83.253.248.99 X-Scan-Result: No virus found in message 1MxcGr-0005f9-4Z. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MxcGr-0005f9-4Z 4b657c0df64226fd8f11ffc7a4235081 Cc: freebsd-stable Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 07:58:31 -0000 On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote: > On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > hi, > this issue (not specific to FreeBSD, and not new -- it has been > like this forever) is discussed in some detail here > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > The following code (a bit outdated) can help > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > cheers > luigi Hmm, how stable would you say the code is? (And/or has there been any progress since March?) I'd prefer something that I feel confident in using in production, and the warning in the README clearly says "stay away!". Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 10:13:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0B791065698 for ; Tue, 13 Oct 2009 10:13:20 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5F018FC17; Tue, 13 Oct 2009 10:13:19 +0000 (UTC) Message-ID: <4AD452CB.7040703@FreeBSD.org> Date: Tue, 13 Oct 2009 11:13:31 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Luigi Rizzo References: <20091012223529.GA77733@onelab2.iet.unipi.it> In-Reply-To: <20091012223529.GA77733@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , Thomas Backman Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 10:13:20 -0000 Luigi Rizzo wrote: > On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > hi, > this issue (not specific to FreeBSD, and not new -- it has been > like this forever) is discussed in some detail here > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > The following code (a bit outdated) can help > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html Are you certain? The reported symptoms sound very unusual. Can you reproduce the problem with the provided instructions yourself? Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 12:14:07 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 485F31065672 for ; Tue, 13 Oct 2009 12:14:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 02A9B8FC13 for ; Tue, 13 Oct 2009 12:14:06 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxgFu-0003kh-L2 for freebsd-stable@freebsd.org; Tue, 13 Oct 2009 14:13:30 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 14:13:30 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 14:13:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 13 Oct 2009 14:12:54 +0200 Lines: 19 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:14:07 -0000 Thomas Backman wrote: > I'm copying this over from the freebsd-performance list, as I'm looking > for a few more opinions - not on the problems *I* am having, but rather > to check whether the problem is universal or not, and if not, find a > possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > > Long story short, my version: when the disk is stressed hard enough, > console IO becomes COMPLETELY unbearable. 10+ seconds to switch between > windows in screen(1), running (or even typing) simple commands, etc. > This happens both via SSH and the serial console. Hmm, this looks familiar - I've noticed it before on the physical (VGA) console and I notice it all the time under VMWare. It sort of looks like disk IO really blocks network IO in this case - I use the VMs over ssh. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 12:17:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC3EA1065670 for ; Tue, 13 Oct 2009 12:17:06 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 89DEA8FC15 for ; Tue, 13 Oct 2009 12:17:05 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 7F0D773106; Tue, 13 Oct 2009 14:23:57 +0200 (CEST) Date: Tue, 13 Oct 2009 14:23:57 +0200 From: Luigi Rizzo To: Kris Kennaway Message-ID: <20091013122357.GA91034@onelab2.iet.unipi.it> References: <20091012223529.GA77733@onelab2.iet.unipi.it> <4AD452CB.7040703@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD452CB.7040703@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable , Thomas Backman Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:17:06 -0000 On Tue, Oct 13, 2009 at 11:13:31AM +0100, Kris Kennaway wrote: > Luigi Rizzo wrote: > >On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > >>I'm copying this over from the freebsd-performance list, as I'm > >>looking for a few more opinions - not on the problems *I* am having, > >>but rather to check whether the problem is universal or not, and if > >>not, find a possible common factor. > >>In other words: I want to hear about your experiences, *good or bad*! > >> > >>Here's the original thread (not from the beginning, though): > >>http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > >> > >>Long story short, my version: when the disk is stressed hard enough, > >>console IO becomes COMPLETELY unbearable. 10+ seconds to switch > >>between windows in screen(1), running (or even typing) simple > >>commands, etc. This happens both via SSH and the serial console. > > > >hi, > >this issue (not specific to FreeBSD, and not new -- it has been > >like this forever) is discussed in some detail here > > > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > > >The following code (a bit outdated) can help > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > Are you certain? The reported symptoms sound very unusual. Can you > reproduce the problem with the provided instructions yourself? sure -- with ATA/SATA disks, the test in the original post is enough to trigger cwpart of the problem time file /etc/* # this one is fast cat /dev/zero > /same_disk_as_etc/somedir/somefile & sleep enough_to_flush_disk_cache # 10-30 sec time file /etc/* # this one takes forever Now, getting sluggish behaviour on the console might need something more such as dependencies between the program being run and disk activity (logging, etc.) but the 'capture effect' on the disk is completely reproducible. Perhaps SCSI and various RAID incarnations may have a better behaviour or need a larger number of greedy clients to trigger the problem. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 12:35:42 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F73C106566B for ; Tue, 13 Oct 2009 12:35:42 +0000 (UTC) (envelope-from svein-listmail@stillbilde.net) Received: from mail.stillbilde.net (d80.iso100.no [81.175.61.195]) by mx1.freebsd.org (Postfix) with SMTP id 3A8648FC0A for ; Tue, 13 Oct 2009 12:35:39 +0000 (UTC) Received: from [192.168.4.2] (unknown [192.168.4.2]) (Authenticated sender: svein) by mail.stillbilde.net (Familien Skogens mail) with ESMTPSA id 4BF9D22; Tue, 13 Oct 2009 14:35:41 +0200 (CEST) Message-ID: <4AD4741E.3080108@stillbilde.net> Date: Tue, 13 Oct 2009 14:35:42 +0200 From: "Svein Skogen (listmail account)" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:35:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/00= 3843.html >> >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. >=20 > Hmm, this looks familiar - I've noticed it before on the physical (VGA) > console and I notice it all the time under VMWare. It sort of looks lik= e > disk IO really blocks network IO in this case - I use the VMs over ssh. I've seen some similar behaviour here with my zfs/istgt backend. I "resolved" the issue by reducing the arc_max so that each disk-io cycle would be "short enough" not to cause the istgt to generate timeouts towards my two vmware hosts. The io-backend for the box is a megaraid 8308 (mfi) card with 8 disks on it. This box is running RELENG_7 now (I tried running it with RELENG_8 but it had a nasty tendency of simply locking up, dragging down both my ESXi hosts with it). //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg =C3=98stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrUdB4ACgkQODUnwSLUlKQjtwCcDWA7BqDdwQ6w8zo0shNJDpJW shkAoKK1hN5QVrmg59J4lGV3V45ooiPj =3DnUay -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 13:14:16 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CB461065693; Tue, 13 Oct 2009 13:14:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 15EE88FC25; Tue, 13 Oct 2009 13:14:16 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BBBFB46B2C; Tue, 13 Oct 2009 09:14:15 -0400 (EDT) Date: Tue, 13 Oct 2009 14:14:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:14:16 -0000 On Tue, 13 Oct 2009, Ivan Voras wrote: > Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm looking for >> a few more opinions - not on the problems *I* am having, but rather to >> check whether the problem is universal or not, and if not, find a possible >> common factor. In other words: I want to hear about your experiences, *good >> or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch between >> windows in screen(1), running (or even typing) simple commands, etc. This >> happens both via SSH and the serial console. > > Hmm, this looks familiar - I've noticed it before on the physical (VGA) > console and I notice it all the time under VMWare. It sort of looks like > disk IO really blocks network IO in this case - I use the VMs over ssh. Real hardware and virtual hardware have vastly different performance properties, so I'd be careful not to assume that the issue described by the original reporter and the issue you're experiencing are the same. In our kernel, low level network protocols will essentially always take precedence over disk I/O activity. So on face value "disk IO really blocks network IO" is highly unlikely. There are two much more likely possibilities: (1) poor VM implementation causes the virtual CPU to be suspended behind synchronous host OS I/O or (2) the network stack is running fine but the interactive user application is getting I/O or locks scheduled behind a bulk process. A useful diagnostic here is to compare the behavior of three kinds of network latency tests: (1) ping from the host OS to the guest OS (2) netperf TCP_RR from the host OS to the guest OS (3) ssh interactive latency If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. If (2) but not (1) is highly variable, it may well be a scheduling issue, although under high memory pressure you couldn't rule out paging out of netserver pages/etc causing latency. If (3) but not (1) or (2) is highly variable, it's most likely an I/O scheduling issue, perhaps caused by priority inversion on lockmgr locks on a vnode, disk I/O scheduling leading to starvation, etc. Robert From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 13:33:58 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01CC8106568B for ; Tue, 13 Oct 2009 13:33:58 +0000 (UTC) (envelope-from ivan.anyukov@googlemail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8ACD18FC27 for ; Tue, 13 Oct 2009 13:33:57 +0000 (UTC) Received: by fxm22 with SMTP id 22so9048875fxm.36 for ; Tue, 13 Oct 2009 06:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Sr0iMDtOSg8tPsOMO41FRMAxYsZUo2Eg7UEkWBSrig0=; b=LHgqUfkK0pvx2OThww9fFBPVPZtwk1pOrJJoCu0Avh+8BVxUvZOPNtc9ngRKG+HgBi Bb2sFW3sjZ0Yxbruo0kB35jXPtffm0U/waE9vsVrKR1qMkCEacnO9awMdREQOeYchaIt cJS+XFMHHUX9QtT5PFgfHlFRFOBK8Y5y/yn1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cbE5H/ahEw1DAVmwZvaLHj+bjKyXCIgc3nVLV3bCjkvjgCcA/yYMYbILSHHVbC3aVV 71GlC6hR9gTqfwaxZhuSwTb1iKeMp9f+EzVrhN1ifnFUX13oL4jne1Or2zO5fSCHDSh6 X6zhwxf8MRhyT1ecMd435WxnS64A621Y3qIbg= MIME-Version: 1.0 Received: by 10.204.10.20 with SMTP id n20mr3595359bkn.161.1255439192223; Tue, 13 Oct 2009 06:06:32 -0700 (PDT) Date: Tue, 13 Oct 2009 15:06:32 +0200 Message-ID: <962bea8e0910130606j20db1b61xc5fb8f8f0f333c28@mail.gmail.com> From: ivan anyukov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Spinlock called when not threaded X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:33:58 -0000 Hello, while compiling seamonkey 2.0 rc1 (source tbz from seamonkey website) on freebsd 8.0 rc1 I'm getting this error: Fatal error 'Spinlock called when not threaded.' at line 78 in file /usr/src/lib/libthr/thread/thr_spinlock.c (errno = 2) Abort trap (core dumped) gmake[5]: *** [/tmp/seamonkey/comm-central/mozilla/dist/lib/libsoftokn3.chk] Error 134 gmake[5]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/nss/cmd/shlibsign' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/manager' gmake[3]: *** [libs_tier_toolkit] Error 2 gmake[3]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[2]: *** [tier_toolkit] Error 2 gmake[2]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[1]: *** [default] Error 2 gmake[1]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake: *** [default] Error 2 I'm using following configure arguments: --enable-application=suite --disable-ogg --disable-wave Any ideas how to fix this problem? Thanks From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 13:34:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20FE1065782; Tue, 13 Oct 2009 13:34:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 008D88FC12; Tue, 13 Oct 2009 13:34:17 +0000 (UTC) Received: by ewy18 with SMTP id 18so3765547ewy.43 for ; Tue, 13 Oct 2009 06:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=pWSIOzQHiOjp2hVuFMedxqzOv92eNQu4XENbBZG8t5I=; b=qDCv5jFE5TdMGfnsTOPlkWWtDT4UJmCRonRTsl2xro6RPhpfh+seAOaNSyr+MD3iGm zJt815oqi3GPqd1ozdq9o43pbBM2AOV7VK98UBbPNGK7q93WjU4bkmUUfIXYwD2zmHpQ umFvC58c/0wl6CgdmsIblhA8vq9Yrrg3ZcxHU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=ZJl+NSGdQekvJyfKYUtBsCOI1QPIbPKmDKLNlPgszXZHt1/vS8xXSQddFKvv0S/dTo fd5CCUGMxt2rdxFhme4+KzGKA/d+SixPoAcY3emw7McnQEPmzBYrMY8Mf6bm9Gb6WqFy 5KmozmbljllFdANpVNO/p6rikt57TPPCM8MnQ= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.93.2 with SMTP id k2mr2362870wef.210.1255440856126; Tue, 13 Oct 2009 06:34:16 -0700 (PDT) In-Reply-To: References: From: Ivan Voras Date: Tue, 13 Oct 2009 15:33:56 +0200 X-Google-Sender-Auth: 7f53eec9f23384d2 Message-ID: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:34:18 -0000 2009/10/13 Robert Watson : > > On Tue, 13 Oct 2009, Ivan Voras wrote: > >> Thomas Backman wrote: >>> >>> I'm copying this over from the freebsd-performance list, as I'm looking >>> for a few more opinions - not on the problems *I* am having, but rather= to >>> check whether the problem is universal or not, and if not, find a possi= ble >>> common factor. In other words: I want to hear about your experiences, *= good >>> or bad*! >>> >>> Here's the original thread (not from the beginning, though): >>> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003= 843.html >>> >>> Long story short, my version: when the disk is stressed hard enough, >>> console IO becomes COMPLETELY unbearable. 10+ seconds to switch between >>> windows in screen(1), running (or even typing) simple commands, etc. Th= is >>> happens both via SSH and the serial console. >> >> Hmm, this looks familiar - I've noticed it before on the physical (VGA) >> console and I notice it all the time under VMWare. It sort of looks like >> disk IO really blocks network IO in this case - I use the VMs over ssh. > > Real hardware and virtual hardware have vastly different performance > properties, so I'd be careful not to assume that the issue described by t= he > original reporter and the issue you're experiencing are the same. =C2=A0I= n our > kernel, low level network protocols will essentially always take preceden= ce > over disk I/O activity. =C2=A0So on face value "disk IO really blocks net= work IO" > is highly unlikely. Yes, I agree for both reasons and that is why I wasn't complaining until encountering this thread. > There are two much more likely possibilities: (1) poor VM implementation > causes the virtual CPU to be suspended behind synchronous host OS I/O or = (2) > the network stack is running fine but the interactive user application is > getting I/O or locks scheduled behind a bulk process. > > A useful diagnostic here is to compare the behavior of three kinds of > network latency tests: > > (1) ping from the host OS to the guest OS > (2) netperf TCP_RR from the host OS to the guest OS > (3) ssh interactive latency > > If (1) is highly variable during I/O, it's almost certainly a property of > the VM technology you're using, and there's nought to be done about it in > the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=3D1576 ttl=3D64 time=3D0.383 ms 64 bytes from 161.53.72.188: icmp_seq=3D1577 ttl=3D64 time=3D0.405 ms 64 bytes from 161.53.72.188: icmp_seq=3D1578 ttl=3D64 time=3D0.360 ms 64 bytes from 161.53.72.188: icmp_seq=3D2304 ttl=3D64 time=3D4.194 ms 64 bytes from 161.53.72.188: icmp_seq=3D2305 ttl=3D64 time=3D0.454 ms 64 bytes from 161.53.72.188: icmp_seq=3D2306 ttl=3D64 time=3D0.376 ms note huge packet loss. It looks like it's VM fault or something like it. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 13:42:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF6B1065672; Tue, 13 Oct 2009 13:42:35 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7FA68FC21; Tue, 13 Oct 2009 13:42:34 +0000 (UTC) Received: from lemongrass.sec.cl.cam.ac.uk (lemongrass.sec.cl.cam.ac.uk [128.232.18.47]) by cyrus.watson.org (Postfix) with ESMTPSA id 4A21646B03; Tue, 13 Oct 2009 09:42:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: "Robert N. M. Watson" In-Reply-To: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Date: Tue, 13 Oct 2009 14:42:32 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> To: Ivan Voras X-Mailer: Apple Mail (2.1076) Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 13:42:35 -0000 On 13 Oct 2009, at 14:33, Ivan Voras wrote: >> If (1) is highly variable during I/O, it's almost certainly a >> property of >> the VM technology you're using, and there's nought to be done about >> it in >> the guest OS. > > Here's an example of a ping session with 0.1s resolution during a few > seconds-stall in ssh: > > 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms > 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms > 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms > > 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms > 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms > 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms > > note huge packet loss. It looks like it's VM fault or something like > it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest at about the same time ICMP latency goes up. However, given the above I think I you can reasonable assume that the 4ms jump you're seeing there is due to global host OS/VM scheduling, and not FreeBSD scheduling. Robert From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 14:26:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37ECA106566B for ; Tue, 13 Oct 2009 14:26:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id B75DF8FC13 for ; Tue, 13 Oct 2009 14:26:05 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxiK0-000412-1L for freebsd-stable@freebsd.org; Tue, 13 Oct 2009 16:25:52 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:25:52 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:25:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 13 Oct 2009 16:25:34 +0200 Lines: 31 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:26:06 -0000 Robert N. M. Watson wrote: > > On 13 Oct 2009, at 14:33, Ivan Voras wrote: > >>> If (1) is highly variable during I/O, it's almost certainly a >>> property of >>> the VM technology you're using, and there's nought to be done about >>> it in >>> the guest OS. >> >> Here's an example of a ping session with 0.1s resolution during a few >> seconds-stall in ssh: >> >> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >> >> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >> >> note huge packet loss. It looks like it's VM fault or something like it. > > It sounds like the VM is failing to execute the guest during certain > types of I/O. A bit of scheduler tracing in the host OS probably > wouldn't go amiss to confirm that the VM really is suspending the guest > at about the same time ICMP latency goes up. However, given the above I > think I you can reasonable assume that the 4ms jump you're seeing there > is due to global host OS/VM scheduling, and not FreeBSD scheduling. Btw. it's not a "4 ms jump" - there are 726 lost packets in between. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 14:42:04 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 138CC106566B for ; Tue, 13 Oct 2009 14:42:04 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BEFAE8FC23 for ; Tue, 13 Oct 2009 14:42:03 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MxiZP-0004gg-Rq for freebsd-stable@freebsd.org; Tue, 13 Oct 2009 16:41:47 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:41:47 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 13 Oct 2009 16:41:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 13 Oct 2009 16:41:18 +0200 Lines: 30 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:42:04 -0000 Robert N. M. Watson wrote: > > On 13 Oct 2009, at 14:33, Ivan Voras wrote: > >>> If (1) is highly variable during I/O, it's almost certainly a >>> property of >>> the VM technology you're using, and there's nought to be done about >>> it in >>> the guest OS. >> >> Here's an example of a ping session with 0.1s resolution during a few >> seconds-stall in ssh: >> >> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >> >> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >> >> note huge packet loss. It looks like it's VM fault or something like it. > > It sounds like the VM is failing to execute the guest during certain > types of I/O. A bit of scheduler tracing in the host OS probably > wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 14:42:15 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2A81065676; Tue, 13 Oct 2009 14:42:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 05F9D8FC12; Tue, 13 Oct 2009 14:42:14 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 571F646B2C; Tue, 13 Oct 2009 10:42:14 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A07378A01B; Tue, 13 Oct 2009 10:42:13 -0400 (EDT) From: John Baldwin To: freebsd-smp@freebsd.org Date: Tue, 13 Oct 2009 10:40:55 -0400 User-Agent: KMail/1.9.7 References: <462F15B4.4010201@webmail.sub.ru> In-Reply-To: <462F15B4.4010201@webmail.sub.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910131040.55465.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 13 Oct 2009 10:42:13 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hardware@freebsd.org, FreeBSD Stable Subject: Re: 6.2-RELEASE does not use second CPU on pentium D X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 14:42:15 -0000 On Wednesday 25 April 2007 4:47:48 am Alex Povolotsky wrote: > Hello! > > I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 > launched, but I never see any process running on it, and mptable shows > > cluster-one# mptable -verbose > > =============================================================================== > > MPTable > > looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009e800 > searching CMOS 'top of mem' @ 0x0009e400 (633K) > searching default 'top of mem' @ 0x0009fc00 (639K) > searching BIOS @ 0x000f0000 > > MP FPS found in BIOS @ physical addr: 0x000fe200 > > ------------------------------------------------------------------------------- > > MP Floating Pointer Structure: > > location: BIOS > physical address: 0x000fe200 > signature: '_MP_' > length: 16 bytes > version: 1.4 > checksum: 0x9f > mode: Virtual Wire > > ------------------------------------------------------------------------------- > > MP Config Table Header: > > physical address: 0x000fe210 > signature: 'PCMP' > base table length: 64 > version: 1.4 > checksum: 0x7f > OEM ID: '' > Product ID: '' > OEM table pointer: 0x00000000 > OEM table size: 0 > entry count: 1 > local APIC address: 0xfee00000 > extended table length: 0 > extended table checksum: 0 > > ------------------------------------------------------------------------------- > > MP Config Base Table Entries: > > -- > Processors: APIC ID Version State Family Model Step > Flags > 0 0x14 BSP, usable 15 6 4 > 0xbfebfbff > > =============================================================================== > > while in dmesg > > Copyright (c) 1992-2007 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 6.2-RELEASE-p3 #2: Thu Apr 19 00:19:54 MSD 2007 > tarkhil@cluster-one.zinester.com:/usr/obj/usr/src/sys/P4D > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2808.41-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 > > Features=0xbfebfbff ,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0xe49d,> > AMD Features=0x20100000 > AMD Features2=0x1 > real memory = 1046757376 (998 MB) > avail memory = 1015095296 (968 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > > [...] > SMP: AP CPU #1 Launched! > > The kernel is, of course, SMP. > > What can I do, where can I search for solution? > > Second core IS enabled in BIOS > cluster-one# sysctl hw | grep cpu > hw.ncpu: 2 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > cluster-one# sysctl machdep | grep cpu > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 2 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 2 > > so second CPU is halted, attempt to start it with sysctl does not help > Alex. What does 'sysctl machdep | grep hyper' show? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 15:16:32 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A5FC1065670; Tue, 13 Oct 2009 15:16:32 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 1A1FA8FC15; Tue, 13 Oct 2009 15:16:31 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=cB6qMLH4z2u1Ic+THDG3rAb70a4D1TYU3RWE2hiUb/6SecUeCtWGMO3JkNngBAil3KzKVRqykIeXD3gXXK6vwkHh7KeZZEydMx9BK69YTQvzCS8CZro4Gm3kGq/atbe6jIbdqw4eWO0ImjjELkK25s+ZzOzlEQ/Gu/WH6knO7P0=; Received: from thebighonker.lerctr.org ([192.147.25.65]:61943) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MxipW-0006oD-L0; Tue, 13 Oct 2009 09:58:28 -0500 Date: Tue, 13 Oct 2009 09:58:21 -0500 (CDT) From: Larry Rosenman To: Ivan Voras In-Reply-To: Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 DomainKey-Status: no signature Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:16:32 -0000 On Tue, 13 Oct 2009, Ivan Voras wrote: > Robert N. M. Watson wrote: >> >> On 13 Oct 2009, at 14:33, Ivan Voras wrote: >> >>>> If (1) is highly variable during I/O, it's almost certainly a property of >>>> the VM technology you're using, and there's nought to be done about it in >>>> the guest OS. >>> >>> Here's an example of a ping session with 0.1s resolution during a few >>> seconds-stall in ssh: >>> >>> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >>> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >>> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >>> >>> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >>> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >>> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >>> >>> note huge packet loss. It looks like it's VM fault or something like it. >> >> It sounds like the VM is failing to execute the guest during certain types >> of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >> amiss to confirm that the VM really is suspending the guest > > It's VMWare ESXi underneath, which is *Officially Not Linux* though some > ducks may disagree - anyway, I suspect tracing the host in this way is next > to impossible without some kind of diamondium-level contract. > What information do you need? I have a platinum VMWare contract. What version of ESXi? LER > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 15:57:07 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED1891065672; Tue, 13 Oct 2009 15:57:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by mx1.freebsd.org (Postfix) with ESMTP id 91B278FC22; Tue, 13 Oct 2009 15:57:06 +0000 (UTC) Received: by yxe14 with SMTP id 14so21285990yxe.7 for ; Tue, 13 Oct 2009 08:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=BOCDw0YPyUacEfOROerZ3aElAsd9M4L760LaLHLrhGA=; b=c3ZakIC8uZz2HPbeJsD9kXd2qP0XDs8eSvKH29nZH8RBIJfefGwuDc/3Y+eC1vEq4R mGValAvqGBic844mY/ZRNnuUattdORMf7WJ/qm4jitXMjQ2oQE7GWo7CfvyMhrzaDr3p +NXU0EQFQjvB1V/v2ZrlytYM0GcifqBXEldHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cuOUG0pYvYTLbDaYmzgndWW6IEAckg7zJxkfNev0J6upzd9RCOxRvVMMrUMLom5Xzt L2SlxD6KddG1tUoeNg9FFewRy+2PBpwV1CGSP3XOqi8XG4hzuGX2O6cY4F/70sfmdaGk mu7k7BVRCKhX9pFdqK7/9GWMadX+oNvNIkp0Q= MIME-Version: 1.0 Received: by 10.150.130.38 with SMTP id c38mr12776141ybd.213.1255447934616; Tue, 13 Oct 2009 08:32:14 -0700 (PDT) In-Reply-To: <20091013035504.GA72620@svzserv.kemerovo.su> References: <20091011175428.GA3626@freefall.freebsd.org> <20091013035504.GA72620@svzserv.kemerovo.su> Date: Tue, 13 Oct 2009 08:32:14 -0700 Message-ID: From: Freddie Cash To: stable@freebsd.org, fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD Status Reports April - September, 2009 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:57:07 -0000 On Mon, Oct 12, 2009 at 8:55 PM, Eugene Grosbein wrote: > On Sun, Oct 11, 2009 at 05:54:29PM +0000, Daniel Gerzo wrote: > > FreeBSD/ZFS > > > > Contact: Pawel Dawidek > > > > We believe that the ZFS file system is now production-ready in FreeBSD > > 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer > > tagged as experimental. There is also ongoing work in Perforce to > bring > > the latest ZFS version (v19) to FreeBSD. > > That's great news. However, my experience says me not place dot-zero > relese under business-critical tasks and load. > > What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? > > 7.2-RELEASE includes ZFSv6. 7-STABLE (after the release of 7.2) includes ZFSv13. 8.0-RELEASE will include ZFSv13. IOW, 8.0 and 7.3 will have roughly the same ZFS code, although I believe the plan is to leave it marked as "experimental" in 7.x and only remove that warning in 8.x. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 17:57:39 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B7F1065679 for ; Tue, 13 Oct 2009 17:57:39 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4FEC28FC15 for ; Tue, 13 Oct 2009 17:57:38 +0000 (UTC) Received: by ewy18 with SMTP id 18so4021536ewy.43 for ; Tue, 13 Oct 2009 10:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=J1wthPXcfq7GfEWDG7Na9LwGtPbOxB4scKYyt6H31Lc=; b=j9Gn2JTZpJBOo8cB20W90VRmVQZY3Fck1SnjqDwaSCuddwG4gMrzXWgKSvGTIGVev3 CW8TzcHfCEaNm7XDoL+1c2LY9+a/NFqdsImr0YINmBk1uoF3UudbMi+W+tKi+aD7SqVN oiWuaaBnqYmGRxwTnpUS3D/vpTNaVaPC+Sut8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=PiYkVaYEm5Fw7/dItdnmyGJhBr0yPO4SZWdTt+V9Wm0Zox2moy9qh3W0DnwxBxH5Id qiVZr3OTlqf+MjzDyXD8BSi4TnL4seDSULMJ4vbZh7K7orZIDcGZ2DROP8eBwd5AycRB yguzNTZL79rJGZhwNxH21fgX5jMc8NpdM7f7o= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.91.69 with SMTP id g47mr2740888wef.167.1255456658242; Tue, 13 Oct 2009 10:57:38 -0700 (PDT) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> From: Ivan Voras Date: Tue, 13 Oct 2009 19:57:18 +0200 X-Google-Sender-Auth: 6aa25c7860a9fd9d Message-ID: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> To: Larry Rosenman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:57:40 -0000 2009/10/13 Larry Rosenman : >>>> note huge packet loss. It looks like it's VM fault or something like i= t. >>> >>> It sounds like the VM is failing to execute the guest during certain >>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn= 't go >>> amiss to confirm that the VM really is suspending the guest >> >> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >> ducks may disagree - anyway, I suspect tracing the host in this way is n= ext >> to impossible without some kind of diamondium-level contract. >> > What information do you need? =C2=A0I have a platinum VMWare contract. > > What version of ESXi? Hi, It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, SATA drives on ICH9. As for what data is needed, it depends on what you can get - from this discussion thread it looks like it would be enough to verify that disk IO doesn't leave VM processes waiting (i.e. that disk IO doesn't interfere with CPU-bound or idle virtual machines). Though now when I think of it - doesn't Linux ATA driver poll IO in some funky way, expecting to get lower latency that way? From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 18:30:06 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E4101065679; Tue, 13 Oct 2009 18:30:06 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4BDE48FC12; Tue, 13 Oct 2009 18:30:06 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lerami; d=lerctr.org; h=Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:X-Spam-Score:X-LERCTR-Spam-Score:X-Spam-Report:X-LERCTR-Spam-Report:DomainKey-Status; b=OaAihjrQQjs482/WKO23G9w8sejHNh3jFQwvR6l2vS410R9t3zFgPj3lTEhWl1hEkTgQL9KafxywvMxQ/wA9HEw0jd+PgGAibBrxY0c1eejVhiwsgAPA2//bz8HagNXOaDHyEd5ylvbNPONWayu27CfGMoAWpTG7UgtWzHeQlOs=; Received: from thebighonker.lerctr.org ([192.147.25.65]:62293) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mxm8K-00095c-EV; Tue, 13 Oct 2009 13:30:05 -0500 Date: Tue, 13 Oct 2009 13:30:02 -0500 (CDT) From: Larry Rosenman To: Ivan Voras In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -4.4 (----) X-LERCTR-Spam-Score: -4.4 (----) X-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 X-LERCTR-Spam-Report: SpamScore (-4.4/5.0) ALL_TRUSTED=-1.8,BAYES_00=-2.599 DomainKey-Status: no signature Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:30:06 -0000 On Tue, 13 Oct 2009, Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. > > As for what data is needed, it depends on what you can get - from this > discussion thread it looks like it would be enough to verify that disk > IO doesn't leave VM processes waiting (i.e. that disk IO doesn't > interfere with CPU-bound or idle virtual machines). Though now when I > think of it - doesn't Linux ATA driver poll IO in some funky way, > expecting to get lower latency that way? > Have you looked at the information available via the performance tab(s) in the client pointing at the ESXi server? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 19:21:18 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B64151065676 for ; Tue, 13 Oct 2009 19:21:18 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 528078FC1A for ; Tue, 13 Oct 2009 19:21:17 +0000 (UTC) Received: by ewy18 with SMTP id 18so4101939ewy.43 for ; Tue, 13 Oct 2009 12:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=HZAhVOzX1chUpP4Rfue3zf6zmuLvnQsVMxOkOpxHo1o=; b=NxywQ1dbj/qVqZO+UdNd4j9xWDNn8HNl28QR2TgEFOaaCTUTuvt/O2aJ8GMHdVbXIN UZoSK076uzZ22Dqhu62ux+DorZj8Ex2EnWXJeXnORs+sIBlQxyHa6KvB9Atp04WCGNxw gBsO7uLqkjkz1aVO11iizzwMOeY6cfuGFxig4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UqY6uVF65ACLRtvB3W/g6zXYESvLFJzIm1QhMgivkqPc5tnMAYDvTzdB14CrZdjE5z mVJ0CCI8Xx6BhHss+WhQhH7ngImZRlerRZJvZGEHgw9RcVvcjS8xdIdt9KmyhtPwZpAi wo4nBfOFvuYjrStGv1JLz90kxNHag8K9TpS6E= MIME-Version: 1.0 Received: by 10.211.160.1 with SMTP id m1mr6174608ebo.50.1255461677320; Tue, 13 Oct 2009 12:21:17 -0700 (PDT) Date: Tue, 13 Oct 2009 15:21:17 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: re: 8.0 RC1 cd boot problem [btx/bios] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:21:18 -0000 Played with this some more. Both the add in cards have their own bios. Their bios can't be disabled. Their raid is not configured so they act as dumb paddles. All bios are up to date. Referring to the below map... - If I swap the position of the cards it won't boot from cd. - If I swap the position of the cards and yank the drives off the 20269, its bios doesn't load and the system boots from cd. - Of course removing the 20269 boots from cd. Booting off the hard drive works fine in all combinations. So I'm pretty sure this is a BTX loader problem involving bios scans? BTX stops right after detecting the ich4 devices... bios cd is cd0 bios drive a: is disk0 bios drive c: is disk1 _ This config boots fine from cd and is now in use: mobo: dell bluford onboard pata: pri m: udma66 s: - sec m: cdr s: dvdrw pci nearest cpu: 1: drive 2: - 3: drive 4: - 5: - 6: - 7: - 8: - pci next nearest cpu: pri m: udma100 s: - sec m: - s: - Prior message-id: d2e731a10909301617l1bad5dcbi7e5681e17fde1a04 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 13 19:24:52 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326B61065696 for ; Tue, 13 Oct 2009 19:24:52 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id C20458FC21 for ; Tue, 13 Oct 2009 19:24:51 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so54276eyd.9 for ; Tue, 13 Oct 2009 12:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=3UX2f49fbyxHsUQDbOxaHY7bVDyuq9ZLtAV0AgyE/xs=; b=VA5iZ3cXc16008QyaB0ZTi24HG3nBs9be8kky+bQm0stwIqjw3ruxxhXiW09smJ3J9 X5f7noCpzgnGAOLqcVNoUkajzkxVmNUBt1udiYaLxLDakva4KggEwA5J+uX0Rrg8gjQV Mqt98CG6xlUltxVrecngn/OyeTIxlpj+iB6kA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nY/OcKssK8seR0RpQqzRiIb1DPvnIouDh4WTMLSMkksJOW7RLDOcc8g636DicyHzkp nYrXdsMYea9wHWAiEOvWnw6Yuy/y30h1MI4d4DfEafUcDBwGOXqumV71uHbqwrx0a9bX jfvv55sWl3mHu1u7e9bb0WcfofAv/XnOackWE= MIME-Version: 1.0 Received: by 10.211.141.2 with SMTP id t2mr6202806ebn.59.1255461890333; Tue, 13 Oct 2009 12:24:50 -0700 (PDT) Date: Tue, 13 Oct 2009 15:24:50 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 8.0 RC1 cd sysinstall install.cfg fd0 missing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:24:52 -0000 I'm not seeing the menu option to load an install.cfg from the floppy anymore. The kernel does detect fdc0 and fd0. Regression? From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 11:16:59 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB3D1065672 for ; Wed, 14 Oct 2009 11:16:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 031A78FC21 for ; Wed, 14 Oct 2009 11:16:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1My1qi-00072o-IO for freebsd-stable@freebsd.org; Wed, 14 Oct 2009 13:16:56 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2009 13:16:56 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2009 13:16:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 14 Oct 2009 13:16:29 +0200 Lines: 21 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:16:59 -0000 Larry Rosenman wrote: > On Tue, 13 Oct 2009, Ivan Voras wrote: >> As for what data is needed, it depends on what you can get - from this >> discussion thread it looks like it would be enough to verify that disk >> IO doesn't leave VM processes waiting (i.e. that disk IO doesn't >> interfere with CPU-bound or idle virtual machines). Though now when I >> think of it - doesn't Linux ATA driver poll IO in some funky way, >> expecting to get lower latency that way? >> > Have you looked at the information available via the performance tab(s) > in the > client pointing at the ESXi server? The 20 second time resolution I get in performance charts isn't nearly enough to diagnose something like this. I've now been running iostat in the virtual console (not ssh) during disk IO and I can't seem to get the characteristic "stutter" / pause behaviour so I think that it's very likely there is too much going on in the VM software to accurately conclude anything. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 11:25:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2225710656C5; Wed, 14 Oct 2009 11:25:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from kennaway-macbookpro.config (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4637F8FC1D; Wed, 14 Oct 2009 11:25:32 +0000 (UTC) Message-ID: <4AD5B536.5030507@FreeBSD.org> Date: Wed, 14 Oct 2009 12:25:42 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Ivan Voras References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:25:33 -0000 Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. I recall others having various weird problems in 3.5 that went away when they upgraded to 4.0. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 12:26:43 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFBA41065672 for ; Wed, 14 Oct 2009 12:26:43 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 94D6C8FC25 for ; Wed, 14 Oct 2009 12:26:43 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1My2w9-0002gE-4C for freebsd-stable@freebsd.org; Wed, 14 Oct 2009 14:26:37 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2009 14:26:37 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2009 14:26:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 14 Oct 2009 14:26:05 +0200 Lines: 9 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> <4AD5B536.5030507@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <4AD5B536.5030507@FreeBSD.org> Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 12:26:44 -0000 Kris Kennaway wrote: > Ivan Voras wrote: > > I recall others having various weird problems in 3.5 that went away when > they upgraded to 4.0. It would be a good idea except that apparently my installation is unupgradeable because of "unsupported boot disk" (a SCSI RAID volume). From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 12:51:23 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69CCA106566C for ; Wed, 14 Oct 2009 12:51:23 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1818FC15 for ; Wed, 14 Oct 2009 12:51:22 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CD93F730DA; Wed, 14 Oct 2009 14:58:16 +0200 (CEST) Date: Wed, 14 Oct 2009 14:58:16 +0200 From: Luigi Rizzo To: Thomas Backman Message-ID: <20091014125816.GB42021@onelab2.iet.unipi.it> References: <20091012223529.GA77733@onelab2.iet.unipi.it> <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 12:51:23 -0000 On Tue, Oct 13, 2009 at 09:58:09AM +0200, Thomas Backman wrote: > > On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote: ... > >hi, > >this issue (not specific to FreeBSD, and not new -- it has been > >like this forever) is discussed in some detail here > > > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > > >The following code (a bit outdated) can help > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > > >cheers > >luigi > Hmm, how stable would you say the code is? (And/or has there been any > progress since March?) > I'd prefer something that I feel confident in using in production, and > the warning in the README clearly says "stay away!". Maybe not for production but if you want to use it on a test box to see if it helps then it is definitely reliable (as long as you don't exercise too much the plugging and unplugging schedulers on a mounted filesystems). I have been using the code for perhaps a couple of months on my desktop machine and no data loss, the only reason it is not loaded now is that it is not loaded by default at boot time. cheers luigi From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 13:39:44 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49086106568B for ; Wed, 14 Oct 2009 13:39:44 +0000 (UTC) (envelope-from howard@leadmon.net) Received: from ibm.leadmon.net (ibm.leadmon.net [207.114.24.13]) by mx1.freebsd.org (Postfix) with ESMTP id B14FD8FC31 for ; Wed, 14 Oct 2009 13:39:43 +0000 (UTC) Received: from HDLDESKTOP64 (hdl-desktop-64.leadmon.net [207.114.24.3]) (authenticated bits=0) by ibm.leadmon.net (8.14.3/8.14.3/LNSG+SCOP+PSBL+LUBL+NJABL+SBL+DSBL+SORBS+CBL+RHSBL) with ESMTP id n9EDdgNM069913 for ; Wed, 14 Oct 2009 09:39:42 -0400 (EDT) (envelope-from howard@leadmon.net) X-DKIM: Sendmail DKIM Filter v2.8.3 ibm.leadmon.net n9EDdgNM069913 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leadmon.net; s=default; t=1255527582; bh=FrbA1CSb3yA+XUBUcBpdc2Dq8cI4IW1/E3tw43ItkBw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=l4DDJ+oK4LPHgEXG08YWP+gWYdgkmVvuy3a1XlQNVD9FMGWYBpaxYvcYmlAshrwhL CXpQTB2zu3EhT7pmAzbvv3bAQUABskszkkfYZdjlgnEat+/W9iAgyExOSJhFEV9eU3 VlLKu/COCJPrO6HyLvSXKER+TU1YMLwXx9nrHOvI= X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 ibm.leadmon.net n9EDdgNM069913 DomainKey-Signature: a=rsa-sha1; s=default; d=leadmon.net; c=simple; q=dns; h=x-senderid:authentication-results:from:to:references: in-reply-to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:content-language; b=JFD/P36KOjb/E/nxCnWmJUI90NkZkwFtNAbf71j0l1bre4YV2a+cWLarrawXOZHGT PZzy+1KWFUBc/AoQvL9m/p4Sn4UVMwD6V6LCNJ9quaQzg0EhNJ9DM2ki6CFyTr0EkLF 0GjMsQxnUnqqpdzuFFut8SHaDkpMVq/H3y41OF0= X-SenderID: Sendmail Sender-ID Filter v1.0.0 ibm.leadmon.net n9EDdgNM069913 Authentication-Results: ibm.leadmon.net; sender-id=pass header.from=howard@leadmon.net; spf=pass smtp.mfrom=howard@leadmon.net From: "Howard Leadmon" To: References: <002001ca4b2f$8aa3fef0$9febfcd0$@net> In-Reply-To: <002001ca4b2f$8aa3fef0$9febfcd0$@net> Date: Wed, 14 Oct 2009 09:39:39 -0400 Message-ID: <012f01ca4cd3$c8a57ee0$59f07ca0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcpLL4i6hrMwEY4wRP+cGKSI4HkmNwBo2iAw Content-Language: en-us X-Virus-Scanned: clamav-milter 0.95.2 at ibm.leadmon.net X-Virus-Status: Clean Subject: RE: Kernel Build Issues with latest cvsup of both a 7.2 system, and a 6.4 system.. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 13:39:44 -0000 As a follow-up to my original message, and I thank the couple people that did respond with suggestions. I seem to have found the issue, which is apparently cvsup17.FreeBSD.org and some file inconsistency. I was using cvsup17 as it was a very close site hop/ping wise on my various servers, in fact I even ran the cvsup several times against cvsup17 over a couple different days (this has always been fine in the past). Still neither my 7.2 or 6.4 server would compile a kernel without the errors show in my original message. I then changed my cvsup to point to cvsup8.FreeBSD.org, and of course ran a cvsup against the cvsup8 server which did make a batch of updates. After that I then attempted to build a kernel on both my 7.2 and my 6.4 servers, and bingo it all worked perfectly. So I can only assume from this, something is out of sync and not right with the cvsup17 server, not sure if any others are using cvsup17 and having any issues, but I apparently am. Not sure who this should be reported to, so someone can check on the integrity of cvsup17.. --- Howard Leadmon > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Howard Leadmon > Sent: Monday, October 12, 2009 7:31 AM > To: freebsd-stable@freebsd.org > Subject: Kernel Build Issues with latest cvsup of both a 7.2 system,and a > 6.4 system.. > > Not sure if I am just having a run of bad luck here, but I have a bunch > of > various free BSD boxen on both 6.4-STABLE, and on 7.2-STABLE. I try and > make it a point to do a cvsup and update the machines every month or so to > keep things current and any updates/patches installed. I decided a > couple > days ago, it was again time to do this again. > > > > So I ran cvsup on the machines, and set out to rebuild, first doing a > 'make > buildworld', then a 'make installworld', and finally a 'mergemaster' on > the > servers. That all went well, then time for a kernel update, so I > performed > a 'make buildkernel KERNCONF=GENERIC' to create the new kernel, which is > where things went bad. > > > > > > On my 6.4-STABLE x86 machine, I received the following: > > > > cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/em > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -ffreestanding -Werror /usr/src/sys/kern/kern_event.c > > /usr/src/sys/kern/kern_event.c:408: warning: no previous prototype for > 'knote_fork' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > > > > > On my 7.2-STABLE amd64 machine, I received the following: > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona > -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb - > D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 > --param inline-unit-growth=100 --param large-function-growth=1000 > -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > /usr/src/sys/amd64/amd64/genassym.c > > In file included from /usr/src/sys/vm/pmap.h:82, > > from /usr/src/sys/amd64/amd64/genassym.c:61: > > ./machine/pmap.h:323: error: expected declaration specifiers or '...' > before > 'vm_memattr_t' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > > > > > > > I have rebuilt the above servers many times over, and I must say it's > worked > great, so was really thrown that not only one version on a server would > blow > up, but two different versions of the OS would pop at the same moment. > Needless to say I haven't tried to rebuild any of my other 6.4 or 7.2 > boxen > yet, as I want to get the above two attempts sorted out first. > > > > Has something changed I am forgetting to do that is not biting me in the > backside, or has some bug been introduced I am now aware of currently > causing issues?? If anyone can help sort this out, or if you need > additional info, please let me know.. > > > > > > > > --- > > Howard Leadmon > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 15:01:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D291C1065695 for ; Wed, 14 Oct 2009 15:01:26 +0000 (UTC) (envelope-from michal@sharescope.co.uk) Received: from mail1.sharescope.co.uk (pm1.ionic.co.uk [85.159.80.19]) by mx1.freebsd.org (Postfix) with ESMTP id 823BE8FC15 for ; Wed, 14 Oct 2009 15:01:26 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail1.sharescope.co.uk (Postfix) with ESMTP id 6566AFC0F1 for ; Wed, 14 Oct 2009 14:44:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sharescope.co.uk Received: from mail1.sharescope.co.uk ([127.0.0.1]) by localhost (mail1.sharescope.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UMTN7YSxZyZ for ; Wed, 14 Oct 2009 15:44:33 +0100 (BST) Received: from [192.168.2.37] (office.ionic.co.uk [85.159.85.2]) (Authenticated sender: chris@sharescope.co.uk) by mail1.sharescope.co.uk (Postfix) with ESMTPSA id A0C4EFC01B for ; Wed, 14 Oct 2009 15:44:33 +0100 (BST) Message-ID: <4AD5E3CF.2060902@sharescope.co.uk> Date: Wed, 14 Oct 2009 15:44:31 +0100 From: Michal User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: UVNC Repeater X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 15:01:26 -0000 Good afternoon, I am having a few niggly problems setting up a VNC repeater on my FreeBSD box and I am finding it very hard to find any information anywhere. I freshly installed FreeBSD on the box today and updated ports and system. I then make && make build && make install /usr/ports/net/repeater/ and made a few customer modifications to the uvncrepeater.ini script, I supplied it bellow. I also set-up the UVNC single click app, it was very simple while I testing, also supplied bellow. When I run the listener on my PC, I see these errors in the repeater.log file (please note IP address's have been changed, but they are public) UltraVnc Wed Oct 14 15:29:30 2009 > acceptConnection(): connection accepted ok from ip: 1.2.3.4 UltraVnc Wed Oct 14 15:29:31 2009 > findServerList(): server not found (code = 7001) So when my tester outside my network starts the single click and tries to connect, it just fails. Has anyone seen this, or point me in the right direction?? Many Thanks Chris helpdesk.txt (for singleclick.exe) ----------------------------------- [TITLE] UltraVnc SC [HOST] Internet support -connect 1.2.3.10:5500 -noregistry -id 7001 uvncrepeater.ini ---------------- [general] ;Ports viewerport = 5900 serverport = 5500 ;Repeater's own ip address in case your server happens to have several ;ip addresses (for example, one physical machine running several virtual ;machines each having their own ip address) ;default (0.0.0.0 = INADDR_ANY = uses all addresses) is the same that ;older repeater versions (before 0.12) did --> listens to all interfaces ;Notice ! This IS NOT address of server or viewer, but repeater itself ! ownipaddress = 1.2.3.10 ;How many sessions can we have active at the same time ? ;values can be [1...1000] ;Notice: If you actually *have* computer(s) capable ;of 1000 simultaneous sessions, you are probably a *very big company*, ;so please invite me to visit and admire your server(s) ;-) maxsessions = 100 ;If program is started as root (to allow binding ports below 1024), ;it changes to this user after ports have been bound in startup ;You need to create a suitable (normal, non-privileged) user/group and change name here runasuser = uvncrep ;Allowed modes for repeater ;0=None, 1=Only Mode 1, 2=Only Mode 2, 3=Both modes ;Notice: If you set allowedmodes = 0, repeater will run without listening to any ports, ;it will just wait for your ctlr + c ;-) allowedmodes = 3 ;Logging level ;0 = Very little (fatal() messages, relaying done) ;1 = 0 + Important messages + Connections opened / closed ;2 = 1 + Ini values + exceptions in logic flow ;3 = 2 + Everything else (very detailed and exhaustive logging == BIG log files) logginglevel = 2 [mode1] ;0=All allowedmode1serverport = 0 ;0=Allow connections to all server addressess, ;1=Require that server address (or range of addresses) is listed in ;srvListAllow[0]...srvListAllow[SERVERS_LIST_SIZE-1] requirelistedserver = 0 ;List of allowed server addresses / ranges ;Ranges can be defined by setting corresponding number to 0, e.g. 10.0.0.0 allows all addresses 10.x.x.x ;Address 255.255.255.255 (default) does not allow any connections ;Address 0.0.0.0 allows all connections ;Only IP addresses can be used here, not DNS names ;There can be max SERVERS_LIST_SIZE (default 50) srvListAllow lines srvListAllow0 = 10.0.0.0 ;Allow network 10.x.x.x srvListAllow1 = 192.168.0.0 ;Allow network 192.168.x.x ;List of denied server addresses / ranges ;Ranges can be defined by setting corresponding number to 0, e.g. 10.0.0.0 denies all addresses 10.x.x.x ;Address 255.255.255.255 (default) does not deny any connections ;Address 0.0.0.0 denies all connections ;Only IP addresses can be used here, not DNS names ;If addresss/range is both allowed and denied, it will be denied (deny is stronger) ;There can be max SERVERS_LIST_SIZE (default 50) srvListDeny lines srvListDeny0 = 10.0.0.0 ;Deny network 10.x.x.x srvListDeny1 = 192.168.2.22 ;Deny host 192.168.2.22 [mode2] ;0=Allow all IDs, 1=Allow only IDs listed in idList[0]...idList[ID_LIST_SIZE-1] requirelistedid = 0 ;List of allowed ID: numbers ;Value 0 means "this authenticates negatively" ;If value is not listed, default is 0 ;Values should be between [1...LONG_MAX-1] ;There can be max ID_LIST_SIZE (default 100) idList lines idlist0 = 7000 idlist1 = 7001 idlist2 = 7002 idlist3 = 7003 idlist4 = 7004 idlist5 = 7005 idlist6 = 7006 idlist7 = 7007 idlist8 = 7008 idlist9 = 7009 [eventinterface] ;Use event interface (for reporting repeater events to outside world) ? ;This could be used to send email, write webpage, update database etc. ;Possible values: true/false useeventinterface = false ;Hostname/Ip address + port of event listener we send events to eventlistenerhost = localhost eventlistenerport = 2002 ;Make HTTP/1.0 GET request to event listener (instead of normal write dump) ;Somebody wanted this for making a PHP event listener usehttp = false From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 22:02:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1FD2106568F; Wed, 14 Oct 2009 22:02:34 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 404BD8FC0A; Wed, 14 Oct 2009 22:02:34 +0000 (UTC) Received: by ewy18 with SMTP id 18so262535ewy.43 for ; Wed, 14 Oct 2009 15:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=bOj3B2qWYfS9Qksn0n6pTLKZ3eMU71mmDxcbec7hk3A=; b=VdzmpkITIVLBfPUl9XTSI8zC8N+8wXIFUKuqb2HYb2RlCFdiV2hPD3/yGSuAS+U8SX 4Xuu3xURzfKobMFm3xe3Sff3JptB7Z/9+TROr2xYzEQF8tiPakH1qu/oTKs4lP+ThBNU bC90w3cLNNyzb19+te2UEjjiov3H0vwcEVB4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=d7fcLNedH3tGM3/m9lw/DydRPnMF9at0qAVtlaM0tKgyhBP8tPxHoisNgkbYyE7q1T gd3a/UMQuNrMpaGOoCu8PSBv6qOOaudiszsODIer8ZzwCc0LQtu+1hjJAWkT1xeFWbrm 451oZmJLihlnl+pQrWd7pkN2KpnkmXSSze1Q4= MIME-Version: 1.0 Received: by 10.211.130.15 with SMTP id h15mr8050293ebn.82.1255557753166; Wed, 14 Oct 2009 15:02:33 -0700 (PDT) Date: Wed, 14 Oct 2009 18:02:32 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: ZFS repeatable reboot 8.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 22:02:34 -0000 Hi. I'm running i386 on i386, single P4 cpu, 1GiB RAM. SiI 3114 -> SATA [single disk] -> GELI [AES-128] -> ZFS [sha256] Straight RELENG_8 as of cvsup Oct 12 14:49:00 aka 8.0-RC1 plus. ZFS pool is at v13, ZFS fs is at v3. Hardware seems stable. The only modification to config defaults is: loader.conf.local: vfs.zfs.arc_max=100663296 After boot -v, geli, zpool import, xf86, browser, etc my mem looks like: Mem: 33M Active, 22M Inact, 105M Wired, 676K Cache, 37M Buf, 827M Free When putting load on ZFS it usually grows to about: Mem: 95M Active, 22M Inact, 302M Wired, 468K Cache, 37M Buf, 569M Free Ls -l in one of the dirs takes 10min plus and I get: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 171 ki31 0K 8K RUN 21:24 47.27% idle 1092 user 76 0 77328K 76116K zio->i 3:25 37.89% ls 802 root -8 - 0K 8K geli:w 1:42 8.98% g_eli[0] ad6 9 root -8 - 0K 128K arc_re 0:23 4.88% {arc_reclaim_thre} I did not watch these during rm. I have 1 parent dir holding 4 subdirs. The file count in each subdir is respectively: 256363, 254086, 256017, 178054 Two thirds of files are about 14KiB in size, not many are more than a few MiB nor less than 1KiB though a third are 1 byte. I issue rm -r and after maybe 30 seconds the machine reboots. No syslog, panic or console messages. Dmesg from the prior boot is still present in ram to prove kernel didn't emit any message. memtest86 passes. There are maybe 10 seconds of complete GUI hangup before the reboot occurs. I also see it when make release'ing. Usually during what I _think_ is distributeworld or rolling up the tarballs under /R. This is a big repeatable problem. How can I debug or fix it? Can someone else create some mega sized dirs as above and replicate? Thanks. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 14 22:55:54 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F05601065672; Wed, 14 Oct 2009 22:55:54 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 66D898FC15; Wed, 14 Oct 2009 22:55:54 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so88014eyd.9 for ; Wed, 14 Oct 2009 15:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=i4hDRf+guR0N1BeNCKYiabtliNB6SJkVsj7JX8fAgh0=; b=G5teCFu/W9VUGYKkCtmFQvx8jdInWmWjPlSbeQkz88Xev/FGKex8c2PTC7k1s17vPB bHVp3uIUBrzqgNHgzcWKD+dzgMScHGHlTvJGH7Gzzcq7YnHan62D6+1aKDztiuxO5MDu AkCBKuKBrz/DVu8Et3d6mMaGZIXl1/qkjbQdI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xzLMYj6BApPFUDPRzbsRwJcc8eJ38ukMdtqqHiHqNaJxg9efEBwke2qMxUtmDkVdG0 V7d8MnJG2J8DRM4sdBv4fkoqQDkPPN0Nx6YyODIIyAJ9Wor6CqHYEsVYgwcy+78Id4ic I3FpMcMM6bengheFK+lgXrvRjK+ujAqQppPjc= MIME-Version: 1.0 Received: by 10.211.128.15 with SMTP id f15mr4367366ebn.84.1255560953602; Wed, 14 Oct 2009 15:55:53 -0700 (PDT) Date: Wed, 14 Oct 2009 18:55:53 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: re: ZFS repeatable reboot 8.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 22:55:55 -0000 Happened again :) So some more notes... Watched it this time, it jumped from about 29xMiB straight to 366MiB, then hung and rebooted itself. The first zpool import after reboot takes about a minute more than the usual ten seconds to import. And uses up to maybe 125MiB instead of maybe 40MiB. Could be ZFS fscking itself? Second and further manual reboots are all normal speed and mem use. The fs is fine, I can do all sorts of normal ops on it. Even rm -r , ^C after a few seconds, and repeat ad nauseum until the tree is removed. Only continuous rm -r reboots. I have 1 more GiB RAM I can put in. Sorry to break threads, I'm not on list. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 01:15:14 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0A8D106566B for ; Thu, 15 Oct 2009 01:15:14 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5530F8FC1C for ; Thu, 15 Oct 2009 01:15:14 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so122613qwd.7 for ; Wed, 14 Oct 2009 18:15:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=zQ1chPmXiWhcnxkRCkYFa/FFGhseZ2c37OJh3QgweOA=; b=sjHGzuVI0G6T8X5x2zFjCFyrRLViBDcTFQ5w9GvxWdmpF/PKMLGWUvDlVOIiLzLzzC i6lJrsZtXSEnWcJPP1R+9q+wZHSVC8iSBpOpx/+4enqNkOjl4tnd1dECgEBQH3qN0mi5 rbjGECBdDVYegl3twJyMEtgrKRa+d3CKWwiTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=WkPE75CD48AVEajnar8/eBruQjCXSiBlMOCdI7noeV1ftbCZ1F1I0dHUyvcbWKUWsw adJM7pZTL5zEUvJYsxzjiIlVBma2xkthOQiizPJr7Zi7U3wqfV2EgI1q7/XeHf2LceNK rYvukdEd4Kj2SyIlr4AuXJH5L87l/WSx1nI6w= Received: by 10.224.100.13 with SMTP id w13mr7706460qan.292.1255569313522; Wed, 14 Oct 2009 18:15:13 -0700 (PDT) Received: from dimension.5p.local (adsl-99-19-46-209.dsl.klmzmi.sbcglobal.net [99.19.46.209]) by mx.google.com with ESMTPS id 6sm7812506qwd.45.2009.10.14.18.15.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Oct 2009 18:15:11 -0700 (PDT) Sender: "J. Hellenthal" Date: Wed, 14 Oct 2009 21:15:09 -0400 From: jhell To: grarpamp In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: re: ZFS repeatable reboot 8.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 01:15:14 -0000 On Wed, 14 Oct 2009 18:55, grarpamp@ wrote: > Happened again :) So some more notes... > > Watched it this time, it jumped from about 29xMiB straight to 366MiB, > then hung and rebooted itself. > > The first zpool import after reboot takes about a minute more than > the usual ten seconds to import. And uses up to maybe 125MiB instead > of maybe 40MiB. Could be ZFS fscking itself? Second and further > manual reboots are all normal speed and mem use. > > The fs is fine, I can do all sorts of normal ops on it. Even rm -r > , ^C after a few seconds, and repeat ad nauseum until the > tree is removed. Only continuous rm -r reboots. > > I have 1 more GiB RAM I can put in. > > Sorry to break threads, I'm not on list. > Your machine is starving! what you can do to improve upon performance of the pool is add a separate disk to the machine in which you can configure your ZIL(ZFS Intent Log) and a Cache. Those two things can improve greatly upon performance and reduce eating up so much ram that your system starts to starve itself. Add that other 1G of RAM if you have it just sitting around then put it to good use it will certainly help. The disk that your doing your remove operation on ? is that being done on a ZFS GELI ? PS: You can use thumb drives as caches and intent logs but beware I have had them stop and disappear in my system to only appear again on reboot. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 06:47:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F33B106566C; Thu, 15 Oct 2009 06:47:02 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7778FC17; Thu, 15 Oct 2009 06:47:01 +0000 (UTC) Received: by ewy18 with SMTP id 18so531096ewy.43 for ; Wed, 14 Oct 2009 23:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cwSpgvA4HMkQKW/3/NVKxzSgO/3R0Uzvsfkh3Yq64Nk=; b=JD5QKMXEPYWxt4Q/8jRGL9NSbSLHW/JK/czXtwGIBPJt+QWGbU3bC5v21tCJt4ByPq 1jOCmYYZxuCDFXmh4z8Mrb2Utb1IYJ29jxp32WyvGYK+xxlggg3IQUMmSrkPuAuSVYXB W7dAClA41OW9pwdknLgEW+YVdkL+gtjz/tEJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fPqG8WLQZjZ8DCXbp8bQ9DFZHTKM1ZN1KeTjxfRdgTTW22oVkGs+mqbZBmiBPl8EJl NarGB9mY48svls/EEj9hdLbg0Kv8LikWl2CIXTEfkQgrFXvw/G2Hg3+FV9JwkMWX3Hmn xki2qSeOPwUlKJdi+E6L323xYm78L0C5SxklE= MIME-Version: 1.0 Received: by 10.211.132.28 with SMTP id j28mr11565532ebn.95.1255589220505; Wed, 14 Oct 2009 23:47:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 02:47:00 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS repeatable reboot 8.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 06:47:02 -0000 > Your machine is starving! How can this be, there is over 500MiB free ram at all times? I'm running literally no userland apps other than X and xterms when it reboots. I think I may be hitting some limit with this 366MiB and reboot bit. How can I tell what my kernel limits are on this platform? Don't I have to limit ARC to ( kern + kern headroom + ARC = kern addressablility limit ) or something like that? Anything I should use for that besides sysctl -a and vmstat -z? I thought I looked at my wired history before using zfs and set arc_max to 96MiB so wired wouldn't even get close 512. > what you can do to improve upon performance of the pool Performance is not the problem. Yes, it's dog slow, but it's usable, sortof :) The issue is that it's rebooting spontaneously. No OS should do that. Though unlike a userland process that the kernel kills when out of ram, I don't know how the kernel would recover when its own processes bloat up. I expect slow performance with this setup. Especially if I'm blowing out some cache somewhere. Take UFS2 with dirhash for example. If the size of the directory inode is much bigger than vfs.ufs.dirhash_maxmem, it just slows down to spindle speed ... not reboot, no big deal. > is add a separate disk to the machine in which you can configure > your ZIL(ZFS Intent Log) and a Cache. Those two things can ... > reduce eating up so much ram that your system starts to starve > itself. Reduce ram?, how so? I already have a ZIL in the main pool by default, presumably using just as much ram as a separate one would, so no need for a separate log. Similarly for cache, which is in core in the default case. They just help speed if on 'faster than spindles' devices. I suppose I could as easily set vfs.zfs.zil_disable=0 as a test if it wouldn't risk loss of the entire pool. > Add that other 1G of RAM Isn't that a game of whack a mole? What happens when I rm a dir with 1M files in it? Add more ram? 2M files? ... > The disk that your doing your remove operation on ? is that being > done on a ZFS GELI ? As mentioned, yes. > PS: You can use thumb drives as caches and intent logs I would presume their bit error rate is higher than platters. There was a time when SSD's meant RAM drives, not flash drives. # vmstat -m | egrep -i 'requests|zfs|zil|zio|arc|solaris|geom|eli' Type InUse MemUse HighUse Requests Size(s) GEOM 208 27K - 1708 16,32,64,128,512,1024,2048,4096 solaris 145673 135033K - 3413390 16,32,64,128,256,512,1024,2048,4096 eli data 8 5K - 23628 32,256,512,1024,2048,4096 # vmstat -z | egrep -i 'requests|zfs|zil|zio|arc|solaris|geom|eli' ITEM SIZE LIMIT USED FREE REQUESTS FAILURES zio_cache: 596, 0, 0, 4596, 489861, 0 arc_buf_hdr_t: 136, 0, 9367, 29, 15769, 0 arc_buf_t: 40, 0, 2128, 264, 19641, 0 zil_lwb_cache: 176, 0, 3, 85, 488, 0 zfs_znode_cache: 232, 0, 19298, 473, 62000, 0 # sysctl -a vfs.zfs kstat.zfs vfs.zfs.arc_meta_limit: 25165824 vfs.zfs.arc_meta_used: 39459076 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 16777216 vfs.zfs.arc_max: 100663296 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.arcstats.hits: 102514 kstat.zfs.misc.arcstats.misses: 12662 kstat.zfs.misc.arcstats.demand_data_hits: 8150 kstat.zfs.misc.arcstats.demand_data_misses: 741 kstat.zfs.misc.arcstats.demand_metadata_hits: 94364 kstat.zfs.misc.arcstats.demand_metadata_misses: 11921 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 49617 kstat.zfs.misc.arcstats.mru_ghost_hits: 2511 kstat.zfs.misc.arcstats.mfu_hits: 52897 kstat.zfs.misc.arcstats.mfu_ghost_hits: 1193 kstat.zfs.misc.arcstats.deleted: 1429 kstat.zfs.misc.arcstats.recycle_miss: 5314 kstat.zfs.misc.arcstats.mutex_miss: 0 kstat.zfs.misc.arcstats.evict_skip: 3645 kstat.zfs.misc.arcstats.hash_elements: 9362 kstat.zfs.misc.arcstats.hash_elements_max: 9363 kstat.zfs.misc.arcstats.hash_collisions: 8135 kstat.zfs.misc.arcstats.hash_chains: 2042 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 57449472 kstat.zfs.misc.arcstats.c: 100663296 kstat.zfs.misc.arcstats.c_min: 16777216 kstat.zfs.misc.arcstats.c_max: 100663296 kstat.zfs.misc.arcstats.size: 99728132 kstat.zfs.misc.arcstats.hdr_size: 1273504 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 961 kstat.zfs.misc.vdev_cache_stats.hits: 8593 kstat.zfs.misc.vdev_cache_stats.misses: 3377 From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 09:29:56 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C346106566B for ; Thu, 15 Oct 2009 09:29:56 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 27BAD8FC12 for ; Thu, 15 Oct 2009 09:29:55 +0000 (UTC) Received: by ewy18 with SMTP id 18so622339ewy.43 for ; Thu, 15 Oct 2009 02:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=zqfBoJ5FNX5r9h1PrqG56LI6avMfECR3WXe2AczwL3M=; b=M+xw5bEowALIeATDUeXXLgM4rrsbSlVBYmrzU0brH31SG/xHHMS2tQkf7As+O8OMMc 5e1TojrM3t7Lh/OeEQOiTWV+rDmIEZnniQgE6XY73JO5B1DjVkzcMOUfSfnK7dCXPNwh lEOkGKetw+D6S2V4Wt0fL6aio8JtOQ7cGlCAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bRmQdUT0NeJ0HuG9H9s7xtrhnVUWuZUMwP4BjAn3y46vPlBpbktRJBTo/I8AdECuL2 ojxnLPhxE3dWziaspM7Gq3v/Jutrt5CLEb5AKl47GmBdYpnEpOVV49mz+8PMslxQAZig hk4ttLhXbIRHOBKBpgU7qjBrc/hpRAKC5lLG8= MIME-Version: 1.0 Received: by 10.216.90.135 with SMTP id e7mr3084773wef.34.1255598994996; Thu, 15 Oct 2009 02:29:54 -0700 (PDT) Date: Thu, 15 Oct 2009 11:29:54 +0200 Message-ID: <4e6cba830910150229h7f9c4ccbp2f679ca344a7faed@mail.gmail.com> From: Giovanni Trematerra To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: serenity@exscape.org Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:29:56 -0000 On Oct 12, 2009, at 10:45 AM, Thomas Backman wrote: >Here's the original thread (not from the beginning, though): >http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >Long story short, my version: when the disk is stressed hard enough, >console IO becomes COMPLETELY unbearable. 10+ seconds to switch >between windows in screen(1), running (or even typing) simple >commands, etc. This happens both via SSH and the serial console. >How to reproduce/test: >1) time file /etc/* > /dev/null a few times, or something similar that >uses the disk; write down a common/average/median/whatever time. >2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's >uncompressed, since ZFS with lzjb/gzip enabled will squish this into a >kilobyte-sized file, thus creating virtually *no* IO. >3) When cat has been running say 10 seconds, re-time command #1 and do >some interactive stuff - run commands, edit files, etc. Hi Thomas, I'm trying to reproduce the issue though I don't have any ZFS filesystems. I'm not using SSH neither serial console. My system is quite responsive. I'm using a VmWare system with 2 cpu support, 1MB RAM with FreeBSD 7.2-RELEASE. I don't know if the issue is related to ZFS or your hardware configuration but can you report what top(1) say during the slowdown? -- Giovanni Trematerra From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 09:51:22 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36E6B1065692 for ; Thu, 15 Oct 2009 09:51:22 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4B38FC1A for ; Thu, 15 Oct 2009 09:51:20 +0000 (UTC) Received: by fxm22 with SMTP id 22so845277fxm.36 for ; Thu, 15 Oct 2009 02:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=VYVghe5PG9sNIQjzmJuwhBTv0NA7QV7Z2pnS7uGgX1o=; b=aKcukn/N9xiqeuBI9uwLG7h/hSbWsIRB+gGuMUUTV2Wq63ngzqNsh1HYXa5dL5k5+0 6kgAMgLKpx7l7yDw4YiEc6pUwGk9ELheoYoxJCKtLDtIQOGymqsu2n18yhwJOSqheA1j OX9kessD5LDaR7tv9PgM3bIyQPqgk+Y2/9bDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZQkoXfSZuukN4ppjLowdAk1DqazszV6wLfZvIRqUKeR/3MOIjPGdmci02JpBmH+GUG HKd9BBF3ueugOlRJVHiS5r0TXes+4iJ5Z3wYoYn193N85Lzwh8AU7IQwErFIcZA4Zdba KJknXJkJEhkfACpQ0AqS/IQ/R2QtwMZyzqzUc= MIME-Version: 1.0 Received: by 10.204.13.207 with SMTP id d15mr737721bka.157.1255600279881; Thu, 15 Oct 2009 02:51:19 -0700 (PDT) Date: Thu, 15 Oct 2009 13:51:19 +0400 Message-ID: From: pluknet To: freebsd-stable , freebsd-scsi Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:51:22 -0000 Hi. This is 7.2-R. Seen on IBM x3650M2. During the boot I get those endless looping kernel messages while on mfi(4) attach phase. It's getting more odd since 7.2 booted and worked fine on exactly this server model months ago (on different box though).. Any hints? mfi0: 5428 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5429 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5430 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5431 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5432 (boot + 64s/0x0008/info) - Battery Present mfi0: 5433 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5434 (boot + 64s/0x0020/info) - Board Revision mfi0: 5435 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5436 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5437 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5438 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5439 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5440 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5441 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5442 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5443 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5444 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5445 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5446 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5447 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5448 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5449 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5450 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5451 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5452 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5453 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5454 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5455 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5456 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5457 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5458 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5459 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5460 (308390540s/0x0020/info) - Time established as 10/09/09 8:02:20; (256 seconds since power on) mfi0: 5461 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5462 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5463 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5464 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5465 (boot + 64s/0x0008/info) - Battery Present mfi0: 5466 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5467 (boot + 64s/0x0020/info) - Board Revision mfi0: 5468 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5469 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5470 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5471 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5472 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5473 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5474 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5475 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5476 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5477 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5478 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5479 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5480 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5481 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5482 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5483 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5484 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5485 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5486 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5487 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5488 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5489 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5490 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5491 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5492 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5493 (308391152s/0x0020/info) - Time established as 10/09/09 8:12:32; (256 seconds since power on) mfi0: 5494 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5495 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5496 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5497 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5498 (boot + 64s/0x0008/info) - Battery Present mfi0: 5499 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5500 (boot + 64s/0x0020/info) - Board Revision mfi0: 5501 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5502 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5503 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5504 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5505 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5506 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5507 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5508 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5509 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5510 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5511 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5512 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5513 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5514 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5515 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5516 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5517 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5518 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5519 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5520 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5521 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5522 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5523 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5524 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5525 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5526 (308391765s/0x0020/info) - Time established as 10/09/09 8:22:45; (257 seconds since power on) mfi0: 5527 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5528 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5529 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5530 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5531 (boot + 64s/0x0008/info) - Battery Present mfi0: 5532 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5533 (boot + 64s/0x0020/info) - Board Revision mfi0: 5534 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5535 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5536 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5537 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5538 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5539 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5540 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5541 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5542 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5543 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5544 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5545 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5546 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5547 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5548 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5549 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5550 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5551 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5552 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5553 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5554 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5555 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5556 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5557 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5558 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5559 (308392379s/0x0020/info) - Time established as 10/09/09 8:32:59; (258 seconds since power on) mfi0: 5560 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5561 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5562 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 006 0/1000/0364/1014) mfi0: 5563 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5564 (boot + 64s/0x0008/info) - Battery Present mfi0: 5565 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5566 (boot + 64s/0x0020/info) - Board Revision mfi0: 5567 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5568 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5569 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5570 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5571 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5572 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5573 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5574 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5575 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5576 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5577 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5578 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5579 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5580 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5581 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5582 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5583 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5584 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5585 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5586 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5587 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5588 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5589 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5590 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5591 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5592 (308392995s/0x0020/info) - Time established as 10/09/09 8:43:15; (259 seconds since power on) mfi0: 5593 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5594 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5595 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5596 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5597 (boot + 64s/0x0008/info) - Battery Present mfi0: 5598 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5599 (boot + 64s/0x0020/info) - Board Revision mfi0: 5600 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5601 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5602 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5603 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5604 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5605 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5606 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5607 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5608 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5609 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5610 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5611 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5612 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5613 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5614 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5615 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5616 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5617 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5618 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5619 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5620 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5621 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5622 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5623 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5624 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5625 (308393612s/0x0020/info) - Time established as 10/09/09 8:53:32; (261 seconds since power on) mfi0: 5626 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5627 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5628 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5629 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5630 (boot + 64s/0x0008/info) - Battery Present mfi0: 5631 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5632 (boot + 64s/0x0020/info) - Board Revision mfi0: 5633 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5634 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5635 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5636 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5637 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5638 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5639 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5640 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5641 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5642 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5643 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5644 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5645 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5646 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5647 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5648 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5649 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5650 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5651 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5652 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5653 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5654 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5655 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5656 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5657 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5658 (308394231s/0x0020/info) - Time established as 10/09/09 9:03:51; (262 seconds since power on) mfi0: 5659 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5660 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5661 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5662 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5663 (boot + 64s/0x0008/info) - Battery Present mfi0: 5664 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5665 (boot + 64s/0x0020/info) - Board Revision mfi0: 5666 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5667 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 So on. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 09:55:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF421065672 for ; Thu, 15 Oct 2009 09:55:27 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 82A778FC24 for ; Thu, 15 Oct 2009 09:55:26 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MyN3L-0006g8-Ft for freebsd-stable@freebsd.org; Thu, 15 Oct 2009 11:55:23 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Oct 2009 11:55:23 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Oct 2009 11:55:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 15 Oct 2009 11:55:08 +0200 Lines: 37 Message-ID: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.23 (X11/20090928) In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Sender: news Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 09:55:27 -0000 Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. > > As for what data is needed, it depends on what you can get - from this > discussion thread it looks like it would be enough to verify that disk > IO doesn't leave VM processes waiting (i.e. that disk IO doesn't > interfere with CPU-bound or idle virtual machines). Though now when I > think of it - doesn't Linux ATA driver poll IO in some funky way, > expecting to get lower latency that way? Another data point - the OS in the VM in question hanged today sometime after 5 AM in the following way: * console nonresponsive (also to ctrl-alt-del) * ssh login nonresponsive (timeout) * ping works (!) Judging by the last seen timestamp, the machine should have been in the process of receiving rsync backups - so IO-bound. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 10:38:10 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D462A106566C; Thu, 15 Oct 2009 10:38:10 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id AD4228FC15; Thu, 15 Oct 2009 10:38:09 +0000 (UTC) Received: by fxm22 with SMTP id 22so892893fxm.36 for ; Thu, 15 Oct 2009 03:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=W5YFI8/7dcXRAArtY9UqhRMsdiZX9kgcZJNMH6Lyg38=; b=ZBopWIs8xvy4sLcVNpjcBlkoCQ+vyd/0RxOVu6D+JDSpXr2R+Dp7aZAjxSm7RoIPZW hHgKUbmHW9MzV2NWieJZZ7prAygrO/a0ddGXG6HkayQjiTMoTAhz/KEFcaQ7oY2JPnv+ LVfb+Sjd49I3snPymmHoKbWW1YFJG6LdIQmZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tQZXD2c+NPht7d9NQBDfjzzPQedQzVKQc7pqskGze2wyThqmX1ZlXEEMlD8q4OrNxv bnNqOifKtxD7xo7H0G85XYib5wVxdNhobwqZyqPkTztiUvXoRAqJcr8G2XyboYXgPWeK 8uzg889PO9rkBwIJ6bhMaRucCcUxXZLYn/H7g= MIME-Version: 1.0 Received: by 10.204.152.154 with SMTP id g26mr7982620bkw.54.1255603088402; Thu, 15 Oct 2009 03:38:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 14:38:08 +0400 Message-ID: From: pluknet To: freebsd-stable , freebsd-scsi Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:38:11 -0000 2009/10/15 pluknet : > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? > After the looked endless loop the kernel eventually finished the mfi(4) initialization and continued its booting. Is it expected to do so long initialization? Almost at the end of kernel boot / near to multiuser start it panicked with: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia Though that's offtopic here. >From last part of dmesg: mfi0: 29365 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 29366 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 29367 (boot + 64s/0x0008/info) - Battery Present mfi0: 29368 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 29369 (boot + 64s/0x0020/info) - Board Revision mfi0: 29370 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 29371 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 29372 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 29373 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 29374 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 29375 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 29376 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 29377 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 29378 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 29379 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 29380 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 29381 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 29382 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 29383 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 29384 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 29385 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 29386 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 29387 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 29388 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 29389 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 29390 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 29391 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 29392 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 29393 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 29394 (boot + 144s/0x0008/info) - Battery temperature is normal ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 mfi0: [MPSAFE] mfi0: [ITHREAD] pcib8: irq 16 at device 28.4 on pci0 pcib8: domain 0 pcib8: secondary bus 6 pcib8: subordinate bus 10 pcib8: I/O decode 0xf000-0xfff pcib8: memory decode 0x97000000-0x978fffff pcib8: prefetched decode 0x96000000-0x96ffffff pci6: on pcib8 pci6: domain=0, physical bus=6 found-> vendor=0x101b, dev=0x0452, revid=0x01 domain=0, bus=6, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 pcib8: slot 0 INTA is routed to irq 16 pcib9: irq 16 at device 0.0 on pci6 pcib9: domain 0 pcib9: secondary bus 7 pcib9: subordinate bus 7 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0x97000000-0x978fffff pcib9: prefetched decode 0x96000000-0x96ffffff pci7: on pcib9 pci7: domain=0, physical bus=7 found-> vendor=0x102b, dev=0x0530, revid=0x00 domain=0, bus=7, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0x96000000, size 24, enabled pcib9: requested memory range 0x96000000-0x96ffffff: good pcib8: requested memory range 0x96000000-0x96ffffff: good map[14]: type Memory, range 32, base 0x97800000, size 14, enabled pcib9: requested memory range 0x97800000-0x97803fff: good pcib8: requested memory range 0x97800000-0x97803fff: good map[18]: type Memory, range 32, base 0x97000000, size 23, enabled pcib9: requested memory range 0x97000000-0x977fffff: good pcib8: requested memory range 0x97000000-0x977fffff: good pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 pcib8: slot 0 INTA is routed to irq 16 pcib9: slot 0 INTA is routed to irq 16 vgapci0: mem 0x96000000-0x96ffffff,0x97800000-0x97803fff,0x97000000-0x977fffff irq 16 at device 0.0 on pci7 uhci2: port 0x2060-0x207f irq 17 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x2040-0x205f irq 18 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x2020-0x203f irq 19 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0x97a21000-0x97a213ff irq 17 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0x97a21000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered usb6: handing over full speed device on port 2 to usb3 uhub6: port 2, device disappeared after reset pcib10: at device 30.0 on pci0 pcib10: domain 0 pcib10: secondary bus 41 pcib10: subordinate bus 45 pcib10: I/O decode 0x0-0x0 pcib10: no prefetched decode pcib10: Subtractively decoded bridge. pci41: on pcib10 pci41: domain=0, physical bus=41 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20f0-0x20ff,0x20e0-0x20ef irq 16 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x20f0 atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0x20e0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0x2108-0x210f,0x2124-0x2127,0x2100-0x2107,0x2120-0x2123,0x20d0-0x20df,0x20c0-0x20cf irq 21 at device 31.5 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x20d0 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0x20c0 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2108 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x2124 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2100 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2120 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 sio1: [FILTER] cpu0: on acpi0 cpu0: switching to generic Cx mode est0: on cpu0 est0: Invalid id16 (set, cur) = (16, 17) est0: Invalid freq 2128, ignored. est0: Invalid id16 (set, cur) = (15, 17) est0: Invalid freq 1995, ignored. est0: Invalid id16 (set, cur) = (14, 17) est0: Invalid freq 1862, ignored. est0: Invalid id16 (set, cur) = (13, 17) est0: Invalid freq 1729, ignored. est0: Invalid id16 (set, cur) = (12, 17) est0: Invalid freq 1596, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (16, 17) est1: Invalid freq 2128, ignored. est1: Invalid id16 (set, cur) = (15, 17) est1: Invalid freq 1995, ignored. est1: Invalid id16 (set, cur) = (14, 17) est1: Invalid freq 1862, ignored. est1: Invalid id16 (set, cur) = (13, 17) est1: Invalid freq 1729, ignored. est1: Invalid id16 (set, cur) = (12, 17) est1: Invalid freq 1596, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (16, 17) est2: Invalid freq 2128, ignored. est2: Invalid id16 (set, cur) = (15, 17) est2: Invalid freq 1995, ignored. est2: Invalid id16 (set, cur) = (14, 17) est2: Invalid freq 1862, ignored. est2: Invalid id16 (set, cur) = (13, 17) est2: Invalid freq 1729, ignored. est2: Invalid id16 (set, cur) = (12, 17) est2: Invalid freq 1596, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (16, 17) est3: Invalid freq 2128, ignored. est3: Invalid id16 (set, cur) = (15, 17) est3: Invalid freq 1995, ignored. est3: Invalid id16 (set, cur) = (14, 17) est3: Invalid freq 1862, ignored. est3: Invalid id16 (set, cur) = (13, 17) est3: Invalid freq 1729, ignored. est3: Invalid id16 (set, cur) = (12, 17) est3: Invalid freq 1596, ignored. p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est4: Invalid id16 (set, cur) = (16, 17) est4: Invalid freq 2128, ignored. est4: Invalid id16 (set, cur) = (15, 17) est4: Invalid freq 1995, ignored. est4: Invalid id16 (set, cur) = (14, 17) est4: Invalid freq 1862, ignored. est4: Invalid id16 (set, cur) = (13, 17) est4: Invalid freq 1729, ignored. est4: Invalid id16 (set, cur) = (12, 17) est4: Invalid freq 1596, ignored. p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est5: Invalid id16 (set, cur) = (16, 17) est5: Invalid freq 2128, ignored. est5: Invalid id16 (set, cur) = (15, 17) est5: Invalid freq 1995, ignored. est5: Invalid id16 (set, cur) = (14, 17) est5: Invalid freq 1862, ignored. est5: Invalid id16 (set, cur) = (13, 17) est5: Invalid freq 1729, ignored. est5: Invalid id16 (set, cur) = (12, 17) est5: Invalid freq 1596, ignored. p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est6: Invalid id16 (set, cur) = (16, 17) est6: Invalid freq 2128, ignored. est6: Invalid id16 (set, cur) = (15, 17) est6: Invalid freq 1995, ignored. est6: Invalid id16 (set, cur) = (14, 17) est6: Invalid freq 1862, ignored. est6: Invalid id16 (set, cur) = (13, 17) est6: Invalid freq 1729, ignored. est6: Invalid id16 (set, cur) = (12, 17) est6: Invalid freq 1596, ignored. p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est7: Invalid id16 (set, cur) = (16, 17) est7: Invalid freq 2128, ignored. est7: Invalid id16 (set, cur) = (15, 17) est7: Invalid freq 1995, ignored. est7: Invalid id16 (set, cur) = (14, 17) est7: Invalid freq 1862, ignored. est7: Invalid id16 (set, cur) = (13, 17) est7: Invalid freq 1729, ignored. est7: Invalid id16 (set, cur) = (12, 17) est7: Invalid freq 1596, ignored. p4tcc7: on cpu7 cpu8: on acpi0 est8: on cpu8 est8: Invalid id16 (set, cur) = (16, 17) est8: Invalid freq 2128, ignored. est8: Invalid id16 (set, cur) = (15, 17) est8: Invalid freq 1995, ignored. est8: Invalid id16 (set, cur) = (14, 17) est8: Invalid freq 1862, ignored. est8: Invalid id16 (set, cur) = (13, 17) est8: Invalid freq 1729, ignored. est8: Invalid id16 (set, cur) = (12, 17) est8: Invalid freq 1596, ignored. p4tcc8: on cpu8 cpu9: on acpi0 est9: on cpu9 est9: Invalid id16 (set, cur) = (16, 17) est9: Invalid freq 2128, ignored. est9: Invalid id16 (set, cur) = (15, 17) est9: Invalid freq 1995, ignored. est9: Invalid id16 (set, cur) = (14, 17) est9: Invalid freq 1862, ignored. est9: Invalid id16 (set, cur) = (13, 17) est9: Invalid freq 1729, ignored. est9: Invalid id16 (set, cur) = (12, 17) est9: Invalid freq 1596, ignored. p4tcc9: on cpu9 cpu10: on acpi0 est10: on cpu10 est10: Invalid id16 (set, cur) = (16, 17) est10: Invalid freq 2128, ignored. est10: Invalid id16 (set, cur) = (15, 17) est10: Invalid freq 1995, ignored. est10: Invalid id16 (set, cur) = (14, 17) est10: Invalid freq 1862, ignored. est10: Invalid id16 (set, cur) = (13, 17) est10: Invalid freq 1729, ignored. est10: Invalid id16 (set, cur) = (12, 17) est10: Invalid freq 1596, ignored. p4tcc10: on cpu10 cpu11: on acpi0 est11: on cpu11 est11: Invalid id16 (set, cur) = (16, 17) est11: Invalid freq 2128, ignored. est11: Invalid id16 (set, cur) = (15, 17) est11: Invalid freq 1995, ignored. est11: Invalid id16 (set, cur) = (14, 17) est11: Invalid freq 1862, ignored. est11: Invalid id16 (set, cur) = (13, 17) est11: Invalid freq 1729, ignored. est11: Invalid id16 (set, cur) = (12, 17) est11: Invalid freq 1596, ignored. p4tcc11: on cpu11 cpu12: on acpi0 est12: on cpu12 est12: Invalid id16 (set, cur) = (16, 17) est12: Invalid freq 2128, ignored. est12: Invalid id16 (set, cur) = (15, 17) est12: Invalid freq 1995, ignored. est12: Invalid id16 (set, cur) = (14, 17) est12: Invalid freq 1862, ignored. est12: Invalid id16 (set, cur) = (13, 17) est12: Invalid freq 1729, ignored. est12: Invalid id16 (set, cur) = (12, 17) est12: Invalid freq 1596, ignored. p4tcc12: on cpu12 cpu13: on acpi0 est13: on cpu13 est13: Invalid id16 (set, cur) = (16, 17) est13: Invalid freq 2128, ignored. est13: Invalid id16 (set, cur) = (15, 17) est13: Invalid freq 1995, ignored. est13: Invalid id16 (set, cur) = (14, 17) est13: Invalid freq 1862, ignored. est13: Invalid id16 (set, cur) = (13, 17) est13: Invalid freq 1729, ignored. est13: Invalid id16 (set, cur) = (12, 17) est13: Invalid freq 1596, ignored. p4tcc13: on cpu13 cpu14: on acpi0 est14: on cpu14 est14: Invalid id16 (set, cur) = (16, 17) est14: Invalid freq 2128, ignored. est14: Invalid id16 (set, cur) = (15, 17) est14: Invalid freq 1995, ignored. est14: Invalid id16 (set, cur) = (14, 17) est14: Invalid freq 1862, ignored. est14: Invalid id16 (set, cur) = (13, 17) est14: Invalid freq 1729, ignored. est14: Invalid id16 (set, cur) = (12, 17) est14: Invalid freq 1596, ignored. p4tcc14: on cpu14 cpu15: on acpi0 est15: on cpu15 est15: Invalid id16 (set, cur) = (16, 17) est15: Invalid freq 2128, ignored. est15: Invalid id16 (set, cur) = (15, 17) est15: Invalid freq 1995, ignored. est15: Invalid id16 (set, cur) = (14, 17) est15: Invalid freq 1862, ignored. est15: Invalid id16 (set, cur) = (13, 17) est15: Invalid freq 1729, ignored. est15: Invalid id16 (set, cur) = (12, 17) est15: Invalid freq 1596, ignored. p4tcc15: on cpu15 ex_isa_identify() sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff,0xca800-0xd8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 004d atkbd: keyboard ID 0xffffffff (1) kbdc: RESET_KBD return code:ffffffff kbdc: RESET_KBD return code:ffffffff kbdc: RESET_KBD return code:ffffffff kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd: failed to reset the keyboard. kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:004d kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:ffffffff kbdc: RESET_AUX return code:ffffffff kbdc: RESET_AUX return code:ffffffff kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices cdce0: on uhub3 cdce0: faking MAC address cdce0: WARNING: using obsoleted IFF_NEEDSGIANT flag cdce0: bpf attached cdce0: Ethernet address: 2a:00:00:00:00:00 Device configuration finished. Reducing kern.maxvnodes 382450 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669284 hz Timecounter "TSC" frequency 2266755720 Hz quality -100 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 500 packets/entry by default lo0: bpf attached hptrr: no controller detected. bce0: link state changed to DOWN bce1: link state changed to DOWN ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ata0: reinit done .. Expensive timeout(9) function: 0xffffffff80267220(0xffffff000414c000) 1.400657904 s ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ata0: reinit done .. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc mfi0: 29395 (308927984s/0x0020/info) - Time established as 10/15/09 13:19:44; (210 seconds since power on) ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #10 Launched! cpu10 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #13 Launched! cpu13 AP: ID: 0x15000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #15 Launched! cpu15 AP: ID: 0x17000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #14 Launched! cpu14 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #9 Launched! cpu9 AP: ID: 0x11000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #12 Launched! cpu12 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #8 Launched! cpu8 AP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #11 Launched! cpu11 AP: ID: 0x13000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 2 ioapic0: Assigning ISA IRQ 4 to local APIC 4 ioapic0: Assigning ISA IRQ 9 to local APIC 6 ioapic0: Assigning ISA IRQ 14 to local APIC 16 ioapic0: Assigning ISA IRQ 15 to local APIC 18 ioapic0: Assigning PCI IRQ 16 to local APIC 20 ioapic0: Assigning PCI IRQ 17 to local APIC 22 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 2 ioapic0: Assigning PCI IRQ 21 to local APIC 4 msi: Assigning MSI IRQ 256 to local APIC 6 msi: Assigning MSI IRQ 257 to local APIC 16 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from nfs:194.190.130.130:/home/jails/freebsd7.2 panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia cpuid = 15 KDB: enter: panic [thread pid 1 tid 100001 ] Stopped at kdb_enter_why+0x3d: movq $0,0x649838(%rip) > mfi0: 5428 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5429 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5430 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5431 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5432 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5433 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5434 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5435 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5436 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5437 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5438 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5439 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5440 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5441 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5442 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5443 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5444 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5445 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5446 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5447 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5448 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5449 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5450 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5451 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5452 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5453 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5454 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5455 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5456 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5457 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5458 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5459 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5460 (308390540s/0x0020/info) - Time established as 10/09/09 > 8:02:20; (256 seconds since power on) > mfi0: 5461 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5462 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5463 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5464 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5465 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5466 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5467 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5468 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5469 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5470 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5471 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5472 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5473 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5474 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5475 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5476 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5477 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5478 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5479 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5480 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5481 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5482 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5483 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5484 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5485 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5486 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5487 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5488 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5489 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5490 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5491 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5492 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5493 (308391152s/0x0020/info) - Time established as 10/09/09 > 8:12:32; (256 seconds since power on) > mfi0: 5494 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5495 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5496 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5497 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5498 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5499 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5500 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5501 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5502 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5503 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5504 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5505 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5506 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5507 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5508 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5509 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5510 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5511 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5512 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5513 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5514 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5515 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5516 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5517 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5518 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5519 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5520 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5521 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5522 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5523 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5524 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5525 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5526 (308391765s/0x0020/info) - Time established as 10/09/09 > 8:22:45; (257 seconds since power on) > mfi0: 5527 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5528 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5529 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5530 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5531 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5532 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5533 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5534 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5535 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5536 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5537 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5538 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5539 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5540 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5541 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5542 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5543 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5544 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5545 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5546 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5547 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5548 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5549 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5550 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5551 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5552 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5553 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5554 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5555 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5556 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5557 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5558 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5559 (308392379s/0x0020/info) - Time established as 10/09/09 > 8:32:59; (258 seconds since power on) > mfi0: 5560 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5561 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5562 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 006 > 0/1000/0364/1014) > mfi0: 5563 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5564 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5565 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5566 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5567 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5568 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5569 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5570 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5571 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5572 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5573 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5574 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5575 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5576 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5577 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5578 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5579 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5580 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5581 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5582 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5583 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5584 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5585 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5586 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5587 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5588 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5589 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5590 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5591 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5592 (308392995s/0x0020/info) - Time established as 10/09/09 > 8:43:15; (259 seconds since power on) > mfi0: 5593 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5594 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5595 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5596 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5597 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5598 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5599 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5600 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5601 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5602 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5603 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5604 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5605 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5606 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5607 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5608 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5609 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5610 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5611 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5612 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5613 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5614 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5615 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5616 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5617 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5618 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5619 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5620 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5621 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5622 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5623 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5624 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5625 (308393612s/0x0020/info) - Time established as 10/09/09 > 8:53:32; (261 seconds since power on) > mfi0: 5626 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5627 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5628 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5629 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5630 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5631 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5632 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5633 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5634 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5635 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5636 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5637 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5638 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5639 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5640 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5641 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5642 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5643 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5644 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5645 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5646 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5647 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5648 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5649 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5650 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5651 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5652 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5653 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5654 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5655 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5656 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5657 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5658 (308394231s/0x0020/info) - Time established as 10/09/09 > 9:03:51; (262 seconds since power on) > mfi0: 5659 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5660 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5661 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5662 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5663 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5664 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5665 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5666 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5667 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > > So on. > -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 11:34:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8C6E106566C for ; Thu, 15 Oct 2009 11:34:36 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8E78FC08 for ; Thu, 15 Oct 2009 11:34:36 +0000 (UTC) Received: from [172.16.1.204] (izaro.sarenet.es [192.148.167.11]) by proxypop1.sarenet.es (Postfix) with ESMTP id A1954622C for ; Thu, 15 Oct 2009 13:34:35 +0200 (CEST) From: Borja Marcos Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 15 Oct 2009 13:34:34 +0200 Message-Id: <0854E733-5DCB-4850-9644-2949893C6E65@sarenet.es> To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: 8.0-RC1/amd64, ZFS panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 11:34:36 -0000 panic: mtx_lock() of destroyed mutex @ /usr/src/sys/kern/vfs_subrc:2467 cpuid = 1 I was doing a zfs destroy -r of a dataset. The dataset has had many snapshot receives done. # uname -a FreeBSD 8.0-RC1 FreeBSD 8.0-RC1 #1: Tue Oct 13 14:11:08 CEST 2009 root@:/usr/obj/usr/src/sys/DEBUG amd64 (kernel config: added WITNESS, etc to have debugging information, doing some ZFS send/receive tests) It's a VMWare virtual machine, and I've frozen it. Borja. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 12:46:19 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F93910656AE for ; Thu, 15 Oct 2009 12:46:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 143A78FC30 for ; Thu, 15 Oct 2009 12:46:18 +0000 (UTC) Received: by fxm22 with SMTP id 22so1036519fxm.36 for ; Thu, 15 Oct 2009 05:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XCMbIV/CNSdjrJHvN+GXksD7JfIq+Jr0gSgHCPjiCP8=; b=Ivie37ARN+hd/awMKhCPwR9Dlg/Hzoa65inHat9lbUiBmpYFlkrwfk50W8FsUhFFdi GVLHYnBmtx5w8nbZzLSBZFqsJfMX1rWWGmKbAj0IW6yJi951VdO+ZOTQnHdvyAaW0ml2 jjAD1qpvajW6VLWqSPQ4mZijgc56NF4CocpmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ciVqJrt09bRAfYOz56ZY+OVSZhB6eKcrpiJbp+xavjmVw8uC7ZxQ8l5k2I/Y+zYBWS mrzYLTd2ZxFi2BVhgrl76MPb7a2Hv7MDKCKVVYVS5Af0MWsnGD7jCgZcDfhaSP2+61wF 1vwptWfROnueMi3poe2YFJZIVz1V2Hc6XA0to= MIME-Version: 1.0 Received: by 10.204.153.220 with SMTP id l28mr5135bkw.86.1255610778093; Thu, 15 Oct 2009 05:46:18 -0700 (PDT) In-Reply-To: <4A7A3A4D.2080105@delphij.net> References: <4A7A3A4D.2080105@delphij.net> Date: Thu, 15 Oct 2009 16:46:18 +0400 Message-ID: From: pluknet To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: [bce] panic on boot in bce(4) on 7.2: invalid ife->ifm_data (0xa) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 12:46:19 -0000 2009/8/6 Xin LI : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > pluknet wrote: >> Hi. >> >> I got the following kernel panic on boot: >> invalid ife->ifm_data (0xa) in mii_phy_setmedia >> >> This is near /sys/dev/mii/mii_physubr.c:126 >> =A0 =A0 =A0 =A0 KASSERT(ife->ifm_data >=3D0 && ife->ifm_data < MII_NMEDI= A, >> =A0 =A0 =A0 =A0 =A0 =A0 ("invalid ife->ifm_data (0x%x) in mii_phy_setmed= ia", >> =A0 =A0 =A0 =A0 =A0 =A0 ife->ifm_data)); > > I believe that this was because the (un)merged brgphy bits. =A0Is it > possible for you to use 7.2-STABLE instead? =A0Otherwise you will need a > patched kernel: > > =A0 =A0 =A0 =A0http://people.freebsd.org/~delphij/misc/bce-5709phy.diff > > Please make sure that you have a full kernel build. > I see no panic with this patch on 7.2. Thanks. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 12:53:08 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 503A61065784; Thu, 15 Oct 2009 12:53:08 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B64B8FC0C; Thu, 15 Oct 2009 12:53:06 +0000 (UTC) Received: by fxm22 with SMTP id 22so1044229fxm.36 for ; Thu, 15 Oct 2009 05:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=YsvGJWg7CPQERBef2IBEaYx+2ScJ3dl3rcPkAcLCK+E=; b=msrB7Hcyn0x7C1DgqkSusR4lnvHBqc1kdqZFqPp3Lm/Xf8hoTsBkzKbsRO6OwDgGn9 nfjHDUnXop2uyapRdc8EI8DbQEwy/+EV3ZOdbwE3IvJG4VQCFkGgWkxBHoAUoDvE/FS+ fkw4l+M8Esp9dfCor5ZMrlKYGCiMsVlSYXMf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=a721UL4s6uAmaVqbOuxJLAMKzMeBmkbTZLMulsWZWxMWnbSA22NGyvQRrPhuu5wOnZ esN6KSvsFVmmB13bHFDbH8pXIMPY9z/kWv6NSq036O4rKfdviPPHa7Zr4nJGsaG98mBL lrMVIyuBQH5VgEJrnRoNd0QfOIlQx61ov6gO4= MIME-Version: 1.0 Received: by 10.204.32.213 with SMTP id e21mr23813bkd.34.1255611184791; Thu, 15 Oct 2009 05:53:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Oct 2009 16:53:04 +0400 Message-ID: From: pluknet To: freebsd-stable , freebsd-scsi Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 12:53:08 -0000 >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? >> > > After the looked endless loop the kernel eventually finished > the mfi(4) initialization and continued its booting. > Is it expected to do so long initialization? > Replying to myself. As someone pointed out in the private email, that's due to the large log contained on non-volatile memory in the controller. MegaCli -AdpEventLog -GetEventLogInfo -aAll cleaned up 'em all. Sorry for noise. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 13:32:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82380106566B; Thu, 15 Oct 2009 13:32:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 53CBD8FC08; Thu, 15 Oct 2009 13:32:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 0363746B03; Thu, 15 Oct 2009 09:32:48 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 0B53D8A01B; Thu, 15 Oct 2009 09:32:47 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 15 Oct 2009 08:53:49 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910150853.49850.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Oct 2009 09:32:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-scsi , pluknet Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 13:32:48 -0000 On Thursday 15 October 2009 5:51:19 am pluknet wrote: > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? We just had some boxes die like this (but spewing a different loop of messages on boot related to continuously scheduling patrol reads and consistency checks that finished immediately) at work. We fixed them by swapping out the controller. We might try stick them in a different box and reflashing them using mfiutil(8) to see if it's some sort of corrupted state that flashing the adapter fixes. In your case it looks lik the firmware keeps crashing and restarting. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 15:16:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE75F106566B; Thu, 15 Oct 2009 15:16:24 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by mx1.freebsd.org (Postfix) with ESMTP id 345008FC1B; Thu, 15 Oct 2009 15:16:24 +0000 (UTC) Received: by fxm22 with SMTP id 22so1208245fxm.36 for ; Thu, 15 Oct 2009 08:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GwUcY5ctpHtArn/geu8Oke7gozfxshWiPdCzzelgNc8=; b=QGU0f1CO0RucHjsyrU+tawuvqb67q16ZvOaJRLxR2aGFe3SUjgWpckqAn/cf2ZpRqU 9a3PZUNQLFd7kH4qznmXWVx0W3dqRtnzDxviuM37fFh6+fBCLsiMtqXRUgG/bsorCVJB 6mNfvjmUEnla+1tzGor4pGXkKD/22nM/DG8bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dG4oWH4kjL4nbYn4OzjlBpqh+CuXBe/K35v9MKm5UittSvmbkg0SOUaR5+xvjfDWv0 RiMyQxkT1D3q+Ma1fWB71dlTcs3dbnJbLWGv2CzEhJEI1cVCztpl+7S2/cWsWwGd36ty MFI1OGeu7P+7wapUlrjM7/znzxrRv+9N2EYLA= MIME-Version: 1.0 Received: by 10.204.49.73 with SMTP id u9mr121445bkf.129.1255619783275; Thu, 15 Oct 2009 08:16:23 -0700 (PDT) In-Reply-To: <200910150853.49850.jhb@freebsd.org> References: <200910150853.49850.jhb@freebsd.org> Date: Thu, 15 Oct 2009 19:16:23 +0400 Message-ID: From: pluknet To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi , freebsd-stable@freebsd.org Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 15:16:25 -0000 2009/10/15 John Baldwin : > On Thursday 15 October 2009 5:51:19 am pluknet wrote: >> Hi. >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? > > We just had some boxes die like this (but spewing a different loop of mes= sages > on boot related to continuously scheduling patrol reads and consistency > checks that finished immediately) at work. =A0We fixed them by swapping o= ut the > controller. =A0We might try stick them in a different box and reflashing = them > using mfiutil(8) to see if it's some sort of corrupted state that flashin= g > the adapter fixes. > > In your case it looks lik the firmware keeps crashing and restarting. Probably it is. Though clearing logs helped me. --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 18:18:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664FF106568F for ; Thu, 15 Oct 2009 18:18:35 +0000 (UTC) (envelope-from netgeek@bgp4.net) Received: from mail.bgp4.net (mail.bgp4.net [64.247.24.57]) by mx1.freebsd.org (Postfix) with ESMTP id 252D08FC12 for ; Thu, 15 Oct 2009 18:18:35 +0000 (UTC) Received: from [10.96.8.137] (ip67-88-218-250.z218-88-67.customer.algx.net [67.88.218.250]) (authenticated bits=0) by mail.bgp4.net (8.14.3/8.14.3) with ESMTP id n9FHivP7001634; Thu, 15 Oct 2009 10:45:08 -0700 (PDT) (envelope-from netgeek@bgp4.net) Message-ID: <4AD75F94.20000@bgp4.net> Date: Thu, 15 Oct 2009 10:44:52 -0700 From: Janet Sullivan User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Steven Hartland References: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> In-Reply-To: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> 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.3 (mail.bgp4.net [64.247.24.57]); Thu, 15 Oct 2009 10:45:09 -0700 (PDT) Cc: freebsd-stable , Thomas Backman Subject: Re: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:18:35 -0000 Steven Hartland wrote: > We're not running 8 yet but we do have a 7.x box which its under fairly > high IO load doing mrtg graphs which has similar behaviour. When typing > a command on ssh it will freeze for may seconds. We have a FreeBSD 7.2 cacti box running on a dell 1950 that has the same problems. RRDs are disk i/o hogs, and when disk i/o shoots up, the box becomes non-responsive for a few seconds. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 19:18:27 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52983106568B; Thu, 15 Oct 2009 19:18:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 239C88FC20; Thu, 15 Oct 2009 19:18:27 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B0BCB46B09; Thu, 15 Oct 2009 15:18:26 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DBBA38A01B; Thu, 15 Oct 2009 15:18:25 -0400 (EDT) From: John Baldwin To: pluknet Date: Thu, 15 Oct 2009 11:35:04 -0400 User-Agent: KMail/1.9.7 References: <200910150853.49850.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910151135.04382.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Oct 2009 15:18:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-scsi , freebsd-stable@freebsd.org Subject: Re: mfi(4) endless loop kernel output on attach X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:18:27 -0000 On Thursday 15 October 2009 11:16:23 am pluknet wrote: > 2009/10/15 John Baldwin : > > On Thursday 15 October 2009 5:51:19 am pluknet wrote: > >> Hi. > >> > >> This is 7.2-R. Seen on IBM x3650M2. > >> > >> During the boot I get those endless looping kernel messages while on > >> mfi(4) attach phase. > >> It's getting more odd since 7.2 booted and worked fine on exactly this > >> server model > >> months ago (on different box though).. Any hints? > > > > We just had some boxes die like this (but spewing a different loop of m= essages > > on boot related to continuously scheduling patrol reads and consistency > > checks that finished immediately) at work. =A0We fixed them by swapping= out the > > controller. =A0We might try stick them in a different box and reflashin= g them > > using mfiutil(8) to see if it's some sort of corrupted state that flash= ing > > the adapter fixes. > > > > In your case it looks lik the firmware keeps crashing and restarting. >=20 > Probably it is. Though clearing logs helped me. Well, from your other e-mail it seems it was just dumping lots of old logs since the previous clean shutdown. (I almost mentioned that case in my original e-mail). In that case you can simply let it finish walking through all the logs or you can set loader tunables to raise the minimum class of message so it skips all the lower priority info messages when walking the log. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Oct 15 22:15:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B2D106566B; Thu, 15 Oct 2009 22:15:19 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4C31E8FC15; Thu, 15 Oct 2009 22:15:19 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so325417eyd.9 for ; Thu, 15 Oct 2009 15:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IPGsFErhvgZy9TM194bFffvNcHDTuiLXBgTvndWkfJk=; b=gwBGWyB31QjVz3AMM4aeabtC/92l5Lc5jAqtK+LxctB6u6Kn+8FJDK+l9+z82zusfT FuP8vfBMh9/MDkDtR0hq5Kf+1o7f0IJ2+6vyZtgsTIZQSOQKbASKEe8aiUtCcC3LY97S KavdJcH0gKuDgBC8bHAsTULC9IAXszp0UkJUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Nht2h/WJt7TqvnPo6CwPQKRO+0E1OcB1USTXI70dCnWjcFlGmDV7Hb/JQz332ZVVH9 2FpKm5LpEFs4u2CihkO3D4kvE33ue/b1QG/cfmUPMaQ1wgtv8hNIawBt3vEtqtjJb7v5 hoqLAexK3g1QRYMGFRYjHVDQAnMW87qBRwT5o= MIME-Version: 1.0 Received: by 10.216.88.212 with SMTP id a62mr286083wef.72.1255644918374; Thu, 15 Oct 2009 15:15:18 -0700 (PDT) In-Reply-To: <43425103-6DAE-43FD-82E7-9B71BAB862B0@gothic.net.au> References: <43425103-6DAE-43FD-82E7-9B71BAB862B0@gothic.net.au> Date: Thu, 15 Oct 2009 18:15:18 -0400 Message-ID: From: grarpamp To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS repeatable reboot 8.0-RC1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:15:20 -0000 Note: I tried setting vfs.zfs.arc_max=32M and zfs mem usage still grew past its limits and the machine rebooted. Forwarding a note I received... """"" >> Your machine is starving! > How can this be, there is over 500MiB free ram at all times? I'm sysctl vm.kmem_size_max I've got the following in my kernel configuration file options KVA_PAGES=512 and in /boot/loader.conf vm.kmem_size_max=1536M vm.kmem_size=1536M On two machines with 2G of RAM....both 8.0-RC1/i386 the ZFS tuning guide gives a better idea of how to play with things like that http://wiki.freebsd.org/ZFSTuningGuide """"" Some questions... Am I reading correctly that vm.kmem_size is how much ram the kernel initially allocates for itself on boot? And that vm.kmem_size_min and vm.kmem_size_max are the range that vm.kmem_size is allowed to float naturally within at runtime? Is KVA_PAGES the hard max space the kern is allowed/capable of addressing/using at runtime? Such that I could set kmem_size_max to the KVA_PAGES limit and then vm.kmem_size will grow into it as needed? With the caveat of course that with the below defaults and hardware, if I just bumped vm.kmem_size_max to 1GiB [as per KVA_PAGES limit] I'd have to add maybe another 1GiB ram so that this new vm.kmem_size_max kernel reservation wouldn't conflict with userland memory needs when vm.kmem_size grows to it? And KVA_PAGES is typically say 1/3 of installed ram? If vm.kmem_size starts out being under vm.kmem_size_max, can user apps use the unused space (vm.kmem_size_max - vm.kmem_size) until vm.kmem_size grows to vm.kmem_size_max and the kernel kills them off? Or can user apps only use (ram = user apps + [KVA_PAGES hard limit and/or vm.kmem_size_max])? What is the idea behind setting vm.kmem_size = vm.kmem_size_max? Should not just vm.kmem_size_max be set and allow vm.kmem_size [unset] to grow up to vm.kmem_size_max instead of allocating it all at boot with vm.kmem_size? Maybe someone can wikify these answers? I think I need to find more to read and then test one by one to see what changes. With untuned defaults and 1GiB ram I have: #define KVA_PAGES 256 # gives 1GiB kern address space vm.kmem_size_max: 335544320 # auto calculated by the kernel at boot? Less than KVA_PAGES? vm.kmem_size_min: 0 vm.kmem_size: 335544320 # amount in use at runtime? I'm still figuring out how to find and add all the kernel memory. Here's zfs: vfs.zfs.arc_meta_limit: 52428800 vfs.zfs.arc_meta_used: 56241732 # greater than meta_limit? vfs.zfs.arc_min: 26214400 vfs.zfs.arc_max: 209715200 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 kstat.zfs.misc.arcstats.p: 20589785 # was 104857600 on boot kstat.zfs.misc.arcstats.c: 128292242 # was 209715200 on boot kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 loader(8) vm.kmem_size Sets the size of kernel memory (bytes). This overrides the value determined when the kernel was compiled. Modifies VM_KMEM_SIZE. vm.kmem_size_min vm.kmem_size_max Sets the minimum and maximum (respectively) amount of ker- nel memory that will be automatically allocated by the ker- nel. These override the values determined when the kernel was compiled. Modifies VM_KMEM_SIZE_MIN and VM_KMEM_SIZE_MAX. sys/i386/include/pmap.h /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). * For PAE, the page table page unit size is 2MB. This means that 512 pages * is 1 Gigabyte. Double everything. It must be a multiple of 8 for PAE. */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif sys/i386/conf/NOTES # Change the size of the kernel virtual address space. Due to # constraints in loader(8) on i386, this must be a multiple of 4. # 256 = 1 GB of kernel address space. Increasing this also causes # a reduction of the address space in user processes. 512 splits # the 4GB cpu address space in half (2GB user, 2GB kernel). For PAE # kernels, the value will need to be double non-PAE. A value of 1024 # for PAE kernels is necessary to split the address space in half. # This will likely need to be increased to handle memory sizes >4GB. # PAE kernels default to a value of 512. # options KVA_PAGES=260 From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 15:57:23 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD631065679; Fri, 16 Oct 2009 15:57:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 354048FC12; Fri, 16 Oct 2009 15:57:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n9GFvMUN094687; Fri, 16 Oct 2009 11:57:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n9GFvMY7094686; Fri, 16 Oct 2009 15:57:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 16 Oct 2009 15:57:22 GMT Message-Id: <200910161557.n9GFvMY7094686@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:57:23 -0000 TB --- 2009-10-16 07:46:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 07:46:09 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2009-10-16 07:46:09 - cleaning the object tree TB --- 2009-10-16 07:46:25 - cvsupping the source tree TB --- 2009-10-16 07:46:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2009-10-16 15:57:17 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 15:57:17 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 15:57:17 - 0.83 user 7.98 system 29467.89 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 16:18:21 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E94FE1065695; Fri, 16 Oct 2009 16:18:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B1B5F8FC1A; Fri, 16 Oct 2009 16:18:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n9GGILwt094757; Fri, 16 Oct 2009 12:18:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n9GGIL6F094756; Fri, 16 Oct 2009 16:18:21 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 16 Oct 2009 16:18:21 GMT Message-Id: <200910161618.n9GGIL6F094756@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 16:18:22 -0000 TB --- 2009-10-16 08:08:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 08:08:09 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2009-10-16 08:08:09 - cleaning the object tree TB --- 2009-10-16 08:08:21 - cvsupping the source tree TB --- 2009-10-16 08:08:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2009-10-16 16:18:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 16:18:21 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 16:18:21 - 0.70 user 6.87 system 29411.67 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 16:33:55 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51777106566B for ; Fri, 16 Oct 2009 16:33:55 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id BF6E48FC1A for ; Fri, 16 Oct 2009 16:33:54 +0000 (UTC) Received: from giskard.altus-escon.com (giskard.altus-escon.com [193.78.231.1]) by altus-escon.com (8.14.3/8.14.3) with ESMTP id n9GFwPBk049260 for ; Fri, 16 Oct 2009 17:58:30 +0200 (CEST) (envelope-from ben@altesco.nl) From: Ben Stuyts Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 16 Oct 2009 17:58:25 +0200 Message-Id: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [193.78.231.142]); Fri, 16 Oct 2009 17:58:30 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.95.2 at mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 16:33:55 -0000 Hi, I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has made it into the tree. From what I can tell, the existing 7.2 release & fixit cd's do not support v13 yet. I'd rather not upgrade the pools without a rescue cd available... Are there any 7-stable iso's available which support zfs v13? Ben From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 17:10:06 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF41A1065679 for ; Fri, 16 Oct 2009 17:10:06 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 651EA8FC1C for ; Fri, 16 Oct 2009 17:10:06 +0000 (UTC) Received: by fxm6 with SMTP id 6so2582828fxm.43 for ; Fri, 16 Oct 2009 10:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.98.74 with SMTP id p10mr326302fan.19.1255711629224; Fri, 16 Oct 2009 09:47:09 -0700 (PDT) In-Reply-To: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> Date: Fri, 16 Oct 2009 12:47:08 -0400 Message-ID: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> From: Michael Proto To: Ben Stuyts Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: ZFS v13 on FreeBSD 7 release/fixit iso's? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:10:06 -0000 On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: > Hi, > > I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has > made it into the tree. From what I can tell, the existing 7.2 release & > fixit cd's do not support v13 yet. > > I'd rather not upgrade the pools without a rescue cd available... Are there > any 7-stable iso's available which support zfs v13? > > Ben > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? -Proto From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 18:57:21 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA1BF106566B for ; Fri, 16 Oct 2009 18:57:21 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from ostracod.unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 431598FC19 for ; Fri, 16 Oct 2009 18:57:21 +0000 (UTC) Received: from vhoffman-macbook.local ([10.0.0.173]) (authenticated bits=0) by ostracod.unsane.co.uk (8.14.3/8.14.3) with ESMTP id n9HJvKUg078930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2009 19:57:20 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4AD8C203.2020008@unsane.co.uk> Date: Fri, 16 Oct 2009 19:57:07 +0100 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Michael Proto References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> In-Reply-To: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: ZFS v13 on FreeBSD 7 release/fixit iso's? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:57:21 -0000 Michael Proto wrote: > On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: > >> Hi, >> >> I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has >> made it into the tree. From what I can tell, the existing 7.2 release & >> fixit cd's do not support v13 yet. >> >> I'd rather not upgrade the pools without a rescue cd available... Are there >> any 7-stable iso's available which support zfs v13? >> >> Ben >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? > > > or indeed from http://pub.allbsd.org/FreeBSD-snapshots/ > -Proto > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 16 19:15:35 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D002D1065692 for ; Fri, 16 Oct 2009 19:15:35 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 605748FC1E for ; Fri, 16 Oct 2009 19:15:35 +0000 (UTC) Received: from giskard.stuyts.nl (stuyts.xs4all.nl [82.95.106.42]) by altus-escon.com (8.14.3/8.14.3) with ESMTP id n9GJFRiS052589; Fri, 16 Oct 2009 21:15:32 +0200 (CEST) (envelope-from ben@altesco.nl) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Stuyts In-Reply-To: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> Date: Fri, 16 Oct 2009 21:15:21 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> To: Michael Proto X-Mailer: Apple Mail (2.1076) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [10.0.0.150]); Fri, 16 Oct 2009 21:15:32 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.95.2 at mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: stable@freebsd.org Subject: Re: ZFS v13 on FreeBSD 7 release/fixit iso's? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:15:35 -0000 On 16 okt 2009, at 18:47, Michael Proto wrote: > On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: >> >> I've recently upgraded a few FreeBSD-7-stable servers, and I see >> ZFS v13 has >> made it into the tree. From what I can tell, the existing 7.2 >> release & >> fixit cd's do not support v13 yet. >> >> I'd rather not upgrade the pools without a rescue cd available... >> Are there >> any 7-stable iso's available which support zfs v13? > > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? Thanks! Ben From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 01:13:53 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3D5106566B for ; Sat, 17 Oct 2009 01:13:53 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BFAAD8FC0A for ; Sat, 17 Oct 2009 01:13:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Myxrj-000OM1-RP for freebsd-stable@freebsd.org; Sat, 17 Oct 2009 01:13:51 +0000 Received: from 173.0.128.10.in-addr.arpa.noptr.antlabs.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 5C4FE2B7B1AF for ; Fri, 16 Oct 2009 21:13:51 -0400 (EDT) Date: Fri, 16 Oct 2009 21:13:51 -0400 Message-ID: From: Randy Bush To: FreeBSD-STABLE Mailing List User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 01:13:53 -0000 i386 running 7.2 as of aug 29 twe, gmirrored boot partition, zfs universe cvsupped 24 hours ago new kernel world will not boot. get beastie but stops at first twirly can boot old kernel -s, but not new kernel can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs start am desperate enough that i am flying from dc to seattle see if i can get it revved back to aug 29 with a fixit any clues appreciated. please use From: address, as my normal email is guess where. randy From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 03:27:20 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01E161065692 for ; Sat, 17 Oct 2009 03:27:20 +0000 (UTC) (envelope-from ken.clifford@mirror-image.com) Received: from mail-relay2.mirrorimage.net (mail-relay2.mirrorimage.net [65.219.237.210]) by mx1.freebsd.org (Postfix) with ESMTP id CB1588FC0A for ; Sat, 17 Oct 2009 03:27:19 +0000 (UTC) Received: from triton.mii-us.mirrorimage.net (triton.mii-us.mirrorimage.net [172.17.254.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-relay2.mirrorimage.net (Postfix) with ESMTPS id 45BB99022E; Fri, 16 Oct 2009 23:18:45 -0400 (EDT) Received: from triton.mii-us.mirrorimage.net ([172.17.254.22]) by triton.mii-us.mirrorimage.net ([172.17.254.22]) with mapi; Fri, 16 Oct 2009 23:10:32 -0400 From: "Clifford, Ken" To: Randy Bush , FreeBSD-STABLE Mailing List Date: Fri, 16 Oct 2009 23:10:18 -0400 Thread-Topic: bootless! Thread-Index: AcpOxzqsno6skO1wQNadC0w3dISRzwAECB5k Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 03:27:20 -0000 Take me off this fucking list!@ ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] O= n Behalf Of Randy Bush [randy@iij.ad.jp] Sent: Friday, October 16, 2009 9:13 PM To: FreeBSD-STABLE Mailing List Subject: bootless! i386 running 7.2 as of aug 29 twe, gmirrored boot partition, zfs universe cvsupped 24 hours ago new kernel world will not boot. get beastie but stops at first twirly can boot old kernel -s, but not new kernel can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs start am desperate enough that i am flying from dc to seattle see if i can get it revved back to aug 29 with a fixit any clues appreciated. please use From: address, as my normal email is guess where. randy _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 04:53:33 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C3F1065670 for ; Sat, 17 Oct 2009 04:53:33 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 12E5D8FC1D for ; Sat, 17 Oct 2009 04:53:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mz1IH-000Onv-RD; Sat, 17 Oct 2009 04:53:30 +0000 Received: from 173.0.128.10.in-addr.arpa.noptr.antlabs.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id EF7B12B7B635; Sat, 17 Oct 2009 00:53:28 -0400 (EDT) Date: Sat, 17 Oct 2009 00:53:28 -0400 Message-ID: From: Randy Bush To: FreeBSD-STABLE Mailing List In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 04:53:33 -0000 > i386 running 7.2 as of aug 29 > twe, gmirrored boot partition, zfs universe > cvsupped 24 hours ago > new kernel & world > will not boot. get beastie but stops at first twirly > > can boot old kernel -s, but not new kernel > > can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs > start > > am desperate enough that i am flying from dc to seattle see if i can get > it revved back to aug 29 with a fixit > > any clues appreciated. please use From: address, as my normal email is > guess where. oh, and yes, i did try verbose boot OK boot -v | randy From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 05:14:35 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311C0106566C for ; Sat, 17 Oct 2009 05:14:35 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [99.69.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id EB0278FC12 for ; Sat, 17 Oct 2009 05:14:34 +0000 (UTC) Received: from vixen42.vulpes (unknown [192.168.14.1]) (Authenticated sender: v.velox) by vulpes.vvelox.net (Postfix) with ESMTP id 90678B844 for ; Fri, 16 Oct 2009 23:54:51 -0500 (CDT) Date: Fri, 16 Oct 2009 23:54:40 -0500 From: "Zane C.B." To: freebsd-stable@freebsd.org Message-ID: <20091016235440.69675c10@vixen42.vulpes> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: USB keyboards and extra keys X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 05:14:35 -0000 Any one ever manage to get extra keys to work on a USB keyboard in the RELENG_7 branch? Just looking into it for the first time since switching to 7 and it is still appearing to be non-workable still. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 10:38:34 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08FC61065670 for ; Sat, 17 Oct 2009 10:38:34 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id B6DC08FC33 for ; Sat, 17 Oct 2009 10:38:33 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KRN00COUMVN76A0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 17 Oct 2009 12:38:11 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.215.119]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KRN008XRMVMI6A0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sat, 17 Oct 2009 12:38:11 +0200 (CEST) Date: Sat, 17 Oct 2009 12:38:10 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> In-reply-to: <20091016235440.69675c10@vixen42.vulpes> References: <20091016235440.69675c10@vixen42.vulpes> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: USB keyboards and extra keys X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 10:38:34 -0000 On Fri, 16 Oct 2009 23:54:40 -0500 "Zane C.B." wrote: > Any one ever manage to get extra keys to work on a USB keyboard in > the RELENG_7 branch? In the past, I have used hotkeys[1] from ports for this. I don't have that keyboard now, so I can't test if it still works. HTH References: 1) http://www.freshports.org/misc/hotkeys/ -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 11:51:53 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A41871065692 for ; Sat, 17 Oct 2009 11:51:53 +0000 (UTC) (envelope-from ben@altesco.nl) Received: from altus-escon.com (altesco.xs4all.nl [82.95.106.39]) by mx1.freebsd.org (Postfix) with ESMTP id 332158FC1F for ; Sat, 17 Oct 2009 11:51:53 +0000 (UTC) Received: from giskard.stuyts.nl (stuyts.xs4all.nl [82.95.106.42]) by altus-escon.com (8.14.3/8.14.3) with ESMTP id n9HBphpM066118; Sat, 17 Oct 2009 13:51:49 +0200 (CEST) (envelope-from ben@altesco.nl) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Ben Stuyts In-Reply-To: <4AD8C203.2020008@unsane.co.uk> Date: Sat, 17 Oct 2009 13:51:38 +0200 Content-Transfer-Encoding: 7bit Message-Id: <877E4A5A-0566-44D4-828A-CD8BF54D8C77@altesco.nl> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> <4AD8C203.2020008@unsane.co.uk> To: Vincent Hoffman X-Mailer: Apple Mail (2.1076) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (altus-escon.com [10.0.0.150]); Sat, 17 Oct 2009 13:51:49 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.95.2 at mars.altus-escon.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=3.5 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mars.altus-escon.com Cc: Michael Proto , stable@freebsd.org Subject: Re: ZFS v13 on FreeBSD 7 release/fixit iso's? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 11:51:53 -0000 On 16 okt 2009, at 20:57, Vincent Hoffman wrote: > Michael Proto wrote: >> On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: >> >>> I've recently upgraded a few FreeBSD-7-stable servers, and I see >>> ZFS v13 has >>> made it into the tree. From what I can tell, the existing 7.2 >>> release & >>> fixit cd's do not support v13 yet. >>> >>> I'd rather not upgrade the pools without a rescue cd available... >>> Are there >>> any 7-stable iso's available which support zfs v13? >> >> How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? >> > or indeed from > http://pub.allbsd.org/FreeBSD-snapshots/ Hey, that's neat, thanks! The second site is a lot more up to date than the former. Ben From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 16:46:43 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33189106566C for ; Sat, 17 Oct 2009 16:46:43 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 417608FC18 for ; Sat, 17 Oct 2009 16:46:41 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n9HGkb7S089507 for ; Sat, 17 Oct 2009 12:46:38 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4AD9F4ED.2050002@aldan.algebra.com> Date: Sat, 17 Oct 2009 12:46:37 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 16:46:43 -0000 Hello! I'm investigating a problem caused by (what seems like a spurious) SIGPIPE. The program creates a child process using pipe, exchanges a few messages with the child (via write and read) and closes the pipe. Some times -- in about 60% of the cases -- this causes a SIGPIPE to be delivered to the parent... Now, it is quite possible for the child to have already exited by the time the parent closes its end of the pipe -- but why should that cause a SIGPIPE, unless the parent tries to write something to the widowed pipe, which it does not? >From pipe(2): A pipe that has had an end closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. There is no other mention of SIGPIPE in that manual page... I set SIGPIPE on ignore around the pipe-closing as a work-around, but I think, this is a bug... The thing is part of TclX' self-test (test signal-3.0) -- and it was not dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... It still seems to be fine on Linux... Have there been any changes in this area in FreeBSD? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:27:39 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BACC1065670 for ; Sat, 17 Oct 2009 17:27:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id CEAA38FC0A for ; Sat, 17 Oct 2009 17:27:38 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n9HHRIvH080529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2009 20:27:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n9HHRINL020391; Sat, 17 Oct 2009 20:27:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n9HHRIdf020390; Sat, 17 Oct 2009 20:27:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Oct 2009 20:27:18 +0300 From: Kostik Belousov To: "Mikhail T." Message-ID: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> References: <4AD9F4ED.2050002@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hcut4fGOf7Kh6EdG" Content-Disposition: inline In-Reply-To: <4AD9F4ED.2050002@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:27:39 -0000 --hcut4fGOf7Kh6EdG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 17, 2009 at 12:46:37PM -0400, Mikhail T. wrote: > Hello! >=20 > I'm investigating a problem caused by (what seems like a spurious) > SIGPIPE. The program creates a child process using pipe, exchanges a few > messages with the child (via write and read) and closes the pipe. >=20 > Some times -- in about 60% of the cases -- this causes a SIGPIPE to be > delivered to the parent... >=20 > Now, it is quite possible for the child to have already exited by the > time the parent closes its end of the pipe -- but why should that cause > a SIGPIPE, unless the parent tries to write something to the widowed > pipe, which it does not? >=20 > >From pipe(2): >=20 > A pipe that has had an end closed is considered widowed. Writing > on such > a pipe causes the writing process to receive a SIGPIPE signal. >=20 > There is no other mention of SIGPIPE in that manual page... >=20 > I set SIGPIPE on ignore around the pipe-closing as a work-around, but I > think, this is a bug... >=20 > The thing is part of TclX' self-test (test signal-3.0) -- and it was not > dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... > It still seems to be fine on Linux... >=20 > Have there been any changes in this area in FreeBSD? Thanks! Take ktrace of both parent and child. --hcut4fGOf7Kh6EdG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrZ/nUACgkQC3+MBN1Mb4iPyQCgxoW6eL1fGE0xk7qRu0lqu95M HM8AoOqWj4AgEMscmKywS8CDeI4P6rzd =dy63 -----END PGP SIGNATURE----- --hcut4fGOf7Kh6EdG-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:41:32 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08C9C106566C for ; Sat, 17 Oct 2009 17:41:32 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2DCF18FC13 for ; Sat, 17 Oct 2009 17:41:30 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n9HHfMLl092731; Sat, 17 Oct 2009 13:41:23 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4ADA01C2.3000303@aldan.algebra.com> Date: Sat, 17 Oct 2009 13:41:22 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: Kostik Belousov References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> In-Reply-To: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:41:32 -0000 Kostik Belousov написав(ла): > Take ktrace of both parent and child. > Great idea! Here is the kdump's listing for both (after ktrace -i): http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt (it is large, so be sure to use a compressing browser). Once loaded, look for substring: Error SIGPIPE signal received while closing file5. The parent process-ID is 92722. The child -- 92723. Thanks! Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:54:00 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4657106566B for ; Sat, 17 Oct 2009 17:54:00 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 727008FC0C for ; Sat, 17 Oct 2009 17:53:58 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n9HHrtaG092796; Sat, 17 Oct 2009 13:53:56 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4ADA04B3.1000704@aldan.algebra.com> Date: Sat, 17 Oct 2009 13:53:55 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: Kostik Belousov References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> In-Reply-To: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: stable@FreeBSD.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:54:00 -0000 Kostik Belousov (): > Take ktrace of both parent and child. > I can see the curious piece right here: The child exits: 92723 tclsh8.5 CALL exit(0) The parent masks SIGPIPE (as part of my workaround): 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) 92722 tclsh8.5 RET sigaction 0 This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:55:56 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF65B1065679 for ; Sat, 17 Oct 2009 17:55:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id A00928FC1C for ; Sat, 17 Oct 2009 17:55:56 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3736E35A83E; Sat, 17 Oct 2009 19:55:55 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 25810228BE; Sat, 17 Oct 2009 19:55:55 +0200 (CEST) Date: Sat, 17 Oct 2009 19:55:55 +0200 From: Jilles Tjoelker To: "Mikhail T." Message-ID: <20091017175555.GA76378@stack.nl> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA01C2.3000303@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADA01C2.3000303@aldan.algebra.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Kostik Belousov , stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:55:57 -0000 On Sat, Oct 17, 2009 at 01:41:22PM -0400, Mikhail T. wrote: > Kostik Belousov wrote: > > Take ktrace of both parent and child. > Great idea! Here is the kdump's listing for both (after ktrace -i): > http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt > (it is large, so be sure to use a compressing browser). Once loaded, > look for substring: > Error SIGPIPE signal received while closing file5. > The parent process-ID is 92722. The child -- 92723. Thanks! Yours, The interesting part of the ktrace: 92723 tclsh8.5 CALL exit(0) 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) 92722 tclsh8.5 RET sigaction 0 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 It seems unwise to assume that a write(2) of 0 bytes is a noop. Even if it is, doing it is a waste of a system call. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:58:59 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C654106566B for ; Sat, 17 Oct 2009 17:58:59 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id DDD258FC0A for ; Sat, 17 Oct 2009 17:58:58 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n9HHwrhC092819; Sat, 17 Oct 2009 13:58:55 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4ADA05DD.2080207@aldan.algebra.com> Date: Sat, 17 Oct 2009 13:58:53 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: Jilles Tjoelker References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA01C2.3000303@aldan.algebra.com> <20091017175555.GA76378@stack.nl> In-Reply-To: <20091017175555.GA76378@stack.nl> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Kostik Belousov , stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:58:59 -0000 Jilles Tjoelker (): > It seems unwise to assume that a write(2) of 0 bytes is a noop. > Even if it is, doing it is a waste of a system call. This is not my code -- it is part of the implementation of Tcl's "close" command. I'm trying to unravel, where this write coming from, but, meanwhile, it would be useful to find out, if FreeBSD's handling of such writes changed recently, wouldn't it? Because this self-test used to pass cleanly before, so either FreeBSD changed, or the Tcl did (not the TclX extension, which did not change in years). Thanks for your help... -mi From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 17:59:48 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 480151065695 for ; Sat, 17 Oct 2009 17:59:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id AD5B18FC24 for ; Sat, 17 Oct 2009 17:59:47 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n9HHxfjF082518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Oct 2009 20:59:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n9HHxfV2020504; Sat, 17 Oct 2009 20:59:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n9HHxfDu020503; Sat, 17 Oct 2009 20:59:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Oct 2009 20:59:41 +0300 From: Kostik Belousov To: "Mikhail T." Message-ID: <20091017175941.GK2160@deviant.kiev.zoral.com.ua> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA04B3.1000704@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="D6IIOQQv2Iwyp54J" Content-Disposition: inline In-Reply-To: <4ADA04B3.1000704@aldan.algebra.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 17:59:48 -0000 --D6IIOQQv2Iwyp54J Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 17, 2009 at 01:53:55PM -0400, Mikhail T. wrote: > Kostik Belousov =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > > Take ktrace of both parent and child. > > =20 > I can see the curious piece right here: >=20 > The child exits: >=20 > 92723 tclsh8.5 CALL exit(0) >=20 > The parent masks SIGPIPE (as part of my workaround): >=20 > 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) > 92722 tclsh8.5 RET sigaction 0 >=20 > This 0-size write must be part of the pipe-closing -- descriptors 4 and > 5 must be the pipe's: >=20 > 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) > 92722 tclsh8.5 RET write -1 errno 32 Broken pipe > 92722 tclsh8.5 PSIG SIGPIPE caught handler=3D0x800f126d0 mask=3D0x0 cod= e=3D0x0 > 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) > 92722 tclsh8.5 RET sigreturn JUSTRETURN > 92722 tclsh8.5 CALL close(0x5) > 92722 tclsh8.5 RET close 0 > 92722 tclsh8.5 CALL close(0x4) > 92722 tclsh8.5 RET close 0 >=20 > Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, > perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. --D6IIOQQv2Iwyp54J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkraBgwACgkQC3+MBN1Mb4gvxACg4dINw+O+/SWEBhfX/W0Pr5Nk ydoAoIKZFTxI/jTgwl9hbOLUwyWT4et1 =1+ri -----END PGP SIGNATURE----- --D6IIOQQv2Iwyp54J-- From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 18:03:12 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C9331065679 for ; Sat, 17 Oct 2009 18:03:12 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [99.69.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2785F8FC12 for ; Sat, 17 Oct 2009 18:03:11 +0000 (UTC) Received: from vixen42.vulpes (unknown [192.168.14.1]) (Authenticated sender: v.velox) by vulpes.vvelox.net (Postfix) with ESMTP id 7D8C6B863; Sat, 17 Oct 2009 13:03:00 -0500 (CDT) Date: Sat, 17 Oct 2009 13:02:52 -0500 From: "Zane C.B." To: Torfinn Ingolfsen Message-ID: <20091017130252.5ecce621@vixen42.vulpes> In-Reply-To: <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> References: <20091016235440.69675c10@vixen42.vulpes> <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.6; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: USB keyboards and extra keys X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 18:03:12 -0000 On Sat, 17 Oct 2009 12:38:10 +0200 Torfinn Ingolfsen wrote: > On Fri, 16 Oct 2009 23:54:40 -0500 > "Zane C.B." wrote: > > > Any one ever manage to get extra keys to work on a USB keyboard in > > the RELENG_7 branch? > > In the past, I have used hotkeys[1] from ports for this. I don't > have that keyboard now, so I can't test if it still works. Unfortunately that does not work. The extra keys on USB keyboards don't result in any thing visible to xev. Also usbhidctl does not show any thing happening on the uhid device that is created by the keyboard. From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 18:50:26 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1695C1065693 for ; Sat, 17 Oct 2009 18:50:26 +0000 (UTC) (envelope-from utisoft@googlemail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id A21048FC2C for ; Sat, 17 Oct 2009 18:50:25 +0000 (UTC) Received: by fxm6 with SMTP id 6so3465107fxm.43 for ; Sat, 17 Oct 2009 11:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=wTk6CLvNC2ISfMXT1//zHCp2hR+AxMU2cRL8k+zN84U=; b=n8Y3RT+P86RP3Q3WIjKrQbuhx1xaxIqhgBOkPJesJr0wbdYd6NyPiaQf5G4Jc5TKDY Wxh5RxfFS4RZouroPOmem8+fkb+eEpCYc2fn8qHabSoqSnigqsof5Q6ojVeKS4RxBnsU P4RLjMGwY6adUG7CXtkPnoSs87ygKbMRs3ylo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=lZpz0mJllDfyj333PlaA+Glhg9pAGLDx9LR0OpVtq1tS3giDl4cfMJT6lY+QIureet UBJpGjf/9KShq7tMQzQKiNQQ6lArAh2tyALjpFmmP2KXhXANesclbbBkXN14clv1uZoJ uvEz3xCJJw8tQBEPv9tD5uvk8jEtnuHPZDyBg= MIME-Version: 1.0 Received: by 10.204.24.83 with SMTP id u19mr2816980bkb.22.1255803584255; Sat, 17 Oct 2009 11:19:44 -0700 (PDT) In-Reply-To: References: From: Chris Rees Date: Sat, 17 Oct 2009 19:19:24 +0100 Message-ID: To: "Clifford, Ken" Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-STABLE Mailing List Subject: Re: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 18:50:26 -0000 2009/10/17 Clifford, Ken : > Take me off this fucking list!@ >From the bottom of the email you just sent: freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" You're welcome. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 19:02:45 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9C02106566C for ; Sat, 17 Oct 2009 19:02:45 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 69D348FC16 for ; Sat, 17 Oct 2009 19:02:45 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id F316C48A41; Sat, 17 Oct 2009 19:43:21 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxnt52a3UZ0r; Sat, 17 Oct 2009 19:43:16 +0100 (BST) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id B040A48A28; Sat, 17 Oct 2009 19:43:15 +0100 (BST) Message-ID: <4ADA1018.4050808@tomjudge.com> Date: Sat, 17 Oct 2009 18:42:32 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: "Clifford, Ken" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-STABLE Mailing List Subject: Re: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 19:02:45 -0000 Look at the footers of this email for how to remove yourself. Swearing will not get you any where, and is likely to result in people not helping you. Clifford, Ken wrote: > Take me off this fucking list!@ > ________________________________________ > From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] On Behalf Of Randy Bush [randy@iij.ad.jp] > Sent: Friday, October 16, 2009 9:13 PM > To: FreeBSD-STABLE Mailing List > Subject: bootless! > > i386 running 7.2 as of aug 29 > twe, gmirrored boot partition, zfs universe > cvsupped 24 hours ago > new kernel world > will not boot. get beastie but stops at first twirly > > can boot old kernel -s, but not new kernel > > can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs > start > > am desperate enough that i am flying from dc to seattle see if i can get > it revved back to aug 29 with a fixit > > any clues appreciated. please use From: address, as my normal email is > guess where. > > randy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 21:07:24 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F4AB1065679 for ; Sat, 17 Oct 2009 21:07:24 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 780C38FC0C for ; Sat, 17 Oct 2009 21:07:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MzGUl-0000ws-0m; Sat, 17 Oct 2009 21:07:23 +0000 Received: from 173.0.128.10.in-addr.arpa.noptr.antlabs.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id F40A32B7C87E; Sat, 17 Oct 2009 17:07:22 -0400 (EDT) Date: Sat, 17 Oct 2009 17:07:22 -0400 Message-ID: From: Randy Bush To: tom@tomjudge.com User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD-STABLE Mailing List Subject: Re: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 21:07:24 -0000 is there a recipe for making a 7.2 usb? randy From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 22:00:36 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FCB31065672 for ; Sat, 17 Oct 2009 22:00:36 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id C06248FC1A for ; Sat, 17 Oct 2009 22:00:35 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KRO00AJEIGYVO20@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 18 Oct 2009 00:00:34 +0200 (CEST) Received: from kg-v2.kg4.no ([84.48.215.119]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KRO00FI7IGYMH90@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 18 Oct 2009 00:00:34 +0200 (CEST) Date: Sun, 18 Oct 2009 00:00:34 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20091018000034.f46371ce.torfinn.ingolfsen@broadpark.no> In-reply-to: <20091017130252.5ecce621@vixen42.vulpes> References: <20091016235440.69675c10@vixen42.vulpes> <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> <20091017130252.5ecce621@vixen42.vulpes> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.16.6; amd64-portbld-freebsd7.2) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: USB keyboards and extra keys X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:00:36 -0000 On Sat, 17 Oct 2009 13:02:52 -0500 "Zane C.B." wrote: > Unfortunately that does not work. The extra keys on USB keyboards > don't result in any thing visible to xev. Well, it did on mine. YMMV. > Also usbhidctl does not show any thing happening on the uhid device > that is created by the keyboard. Perhaps that particular keyboard is broken by design? -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 22:01:02 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AFB01065786 for ; Sat, 17 Oct 2009 22:01:02 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id BDFFC8FC1E for ; Sat, 17 Oct 2009 22:01:01 +0000 (UTC) Received: (qmail 86102 invoked from network); 17 Oct 2009 22:01:01 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 17 Oct 2009 22:01:01 -0000 Message-ID: <4ADA3E39.2090200@acm.poly.edu> Date: Sat, 17 Oct 2009 17:59:21 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.23 (X11/20090910) MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tom@tomjudge.com, FreeBSD-STABLE Mailing List Subject: Re: bootless! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:01:02 -0000 Randy Bush wrote: > is there a recipe for making a 7.2 usb? > > randy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > If you mean for converting the ISOs to images you can dd to USB flash drives, http://acm.poly.edu/~spawk/image.sh. I found it somewhere else a long time ago, but it works. Note that you cannot install distributions from it, so you'll have to get those using FTP, another local filesystem, etc. -Boris From owner-freebsd-stable@FreeBSD.ORG Sat Oct 17 22:04:55 2009 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A3C1065670 for ; Sat, 17 Oct 2009 22:04:55 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 18DF58FC1F for ; Sat, 17 Oct 2009 22:04:53 +0000 (UTC) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n9HM4kWp022057; Sat, 17 Oct 2009 18:04:49 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <4ADA3F7E.1070208@aldan.algebra.com> Date: Sat, 17 Oct 2009 18:04:46 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.22 (X11/20090711) MIME-Version: 1.0 To: Kostik Belousov References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA04B3.1000704@aldan.algebra.com> <20091017175941.GK2160@deviant.kiev.zoral.com.ua> In-Reply-To: <20091017175941.GK2160@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org Subject: Re: Can close-ing a pipe trigger a SIGPIPE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 22:04:55 -0000 Kostik Belousov (): >> This 0-size write must be part of the pipe-closing -- descriptors 4 and >> 5 must be the pipe's: >> >> 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) >> 92722 tclsh8.5 RET write -1 errno 32 Broken pipe >> 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 >> 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) >> 92722 tclsh8.5 RET sigreturn JUSTRETURN >> 92722 tclsh8.5 CALL close(0x5) >> 92722 tclsh8.5 RET close 0 >> 92722 tclsh8.5 CALL close(0x4) >> 92722 tclsh8.5 RET close 0 >> >> Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, >> perhaps, didn't use to? >> > > Obviously, I cannot answer the question. This is something that should > be read from source code or asked by authors. > You -- or someone else -- could comment like: a) Yeah, the meaning of write-ing 0 bytes changed in version such and such to conform to such and such standard. or b) No, nothing changed in that area of FreeBSD for years -- there must be something in Tcl itself. Yours, -mi