From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 00:54:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9550B106564A for ; Sun, 12 Feb 2012 00:54:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 208D48FC0C for ; Sun, 12 Feb 2012 00:54:38 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4251533wib.13 for ; Sat, 11 Feb 2012 16:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VALDAJEW2mflsazkAIj7v+wWJIXIVJnjxyz/QzeH/ss=; b=OcSJtzka6DE+ifYwG7bk4ye7pwFLNe/Zk1l4sLGScn0A+5TehtsyoL/oqJns/nlYMA 9lLAYdBXhvPLdecUsY3bGfLau1pE2Ye2nlsRmb8a82e66R1+b43quoN3js+XEV9R30ay V0HxC4zIT+4MmTGvJP0JvE3QamkgLQ/kg4vvY= MIME-Version: 1.0 Received: by 10.216.133.205 with SMTP id q55mr2840656wei.6.1329008077813; Sat, 11 Feb 2012 16:54:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sat, 11 Feb 2012 16:54:37 -0800 (PST) In-Reply-To: <4F27C7C7.3060807@os2.kiev.ua> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> Date: Sat, 11 Feb 2012 16:54:37 -0800 X-Google-Sender-Auth: kBcra9gatvZ4Dhjy-Ut49A4NjfY Message-ID: From: Adrian Chadd To: Alex Samorukov Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 12 Feb 2012 00:54:39 -0000 Hi, What about the disk access is unaligned? Do you mean not sector aligned? or? This is a common problem people face doing disk IO analysis. The whole point about not allowing unaligned access is to make the disk IO path cleaner. It does mean that the filesystem code (and GEOM modules involved) need to be smarter. If the filesystem is doing ridiculously unaligned access then it likely should be fixed. Adrian From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 04:12:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD37106564A; Sun, 12 Feb 2012 04:12:55 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id EF0048FC08; Sun, 12 Feb 2012 04:12:54 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1C4CsIQ026668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 11 Feb 2012 20:12:54 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1C4CshR026667; Sat, 11 Feb 2012 20:12:54 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA12280; Sat, 11 Feb 12 20:06:03 PST Date: Sun, 12 Feb 2012 03:05:02 -0800 From: perryh@pluto.rain.com To: Alexander@Leidinger.net Message-Id: <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> In-Reply-To: <20120211183308.00007579@unknown> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: thierry@freebsd.org, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 12 Feb 2012 04:12:55 -0000 Alexander Leidinger wrote: > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas > wrote: > > is there another place to put options to atkbd and sc, like > > these ones: > > > > options ATKBD_DFLT_KEYMAP # specify the built-in keymap > > makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > ... > > No, there is no other way to add the keymap to the kernel directly > (if you want to have it working correctly in single-user mode) > instead of loading it with rc.conf. Might it be feasible to make it into a sysctl, so it could be set in loader.conf? From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 06:44:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F3DE106566B for ; Sun, 12 Feb 2012 06:44:01 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 49A1D8FC17 for ; Sun, 12 Feb 2012 06:43:59 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-202-187.lns20.adl6.internode.on.net [118.210.202.187]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id q1C6hnn3065228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Feb 2012 17:13:55 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: "Daniel O'Connor" In-Reply-To: <4F3577C9.6050401@rewt.org.uk> Date: Sun, 12 Feb 2012 17:13:48 +1030 Content-Transfer-Encoding: quoted-printable Message-Id: <4F7A77DF-BA0B-4A75-A5EF-3CCDA314AD93@gsoft.com.au> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F35762D.60908@rewt.org.uk> <4F3577C9.6050401@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1257) X-Spam-Score: 2.161 (**) BAYES_00,KHOP_DYNAMIC,LOTS_OF_MONEY,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable Mailing List , Alex Samorukov Subject: Re: New BSD Installer 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, 12 Feb 2012 06:44:01 -0000 On 11/02/2012, at 6:32, Joe Holden wrote: > On a related note - does the new installer have any kind of config = file for unattended installs a la sysinstall? No it doesn't, that said since the new release CD is a live file system = (vs the old MFS on a CD kludge) it is much much easier to script your = own install. Especially with gpart it is fairly easy to setup a working system. I use this at work - image.txz.?? is created from a chroot where I = pre-build rather than using packages since it is a lot faster. The original also does things like put certain settings in sysctl.conf, = loader.conf and rc.conf. I found it was a lot simpler to set this up vs doing something similar = with sysinstall because sysinstall's environment was so restrictive. Currently the user selects shell and then runs the script, but I am = looking at modifying the release rc.local to add a menu option to make = it simpler. #!/bin/sh PATH=3D/bin:/usr/bin:/sbin:/usr/sbin export PATH BLOCKSIZE=3D10240 ROSINST=3D"/ros-install.sh" if [ $# -ne 1 ]; then devs=3D`camcontrol devlist | sed -nEe 's,<(.*)> +at = scbus.*\((.*)\,(.*)\),\1|\2 \3,p' | sed -Ee 's,pass[0-9]+,,' | sed -Ee = 's,(.*)\| ?(.*),/dev/\2 \\\"\1\\\",' | xargs echo` eval dialog --backtitle \"FreeBSD Installer\" --title \"Device = selection\" --menu \"Select device to install onto\" 20 50 40 $devs = 2>/tmp/devselection if [ $? -ne 0 ]; then echo echo "Aborting installation" exit 1 fi DEV=3D`cat /tmp/devselection` rm -f /tmp/devselection else DEV=3D"${1}" fi if [ ! -c "${DEV}" ]; then echo "${DEV} isn't a device" exit 1 fi set -e echo "Installing to ${DEV}" echo echo "Please enter the fully qualified hostname" echo "If you just press enter default values for networking will be = used" read hostname if [ -z "$hostname" ]; then hostname=3D"newradar.local" ifconfig=3D"DHCP" else echo "Please enter the ifconfig line (DHCP or a static IP)" read ifconfig=20 if [ "$ifconfig" !=3D "DHCP" ]; then echo "Please enter the default router" read defrouter echo "Please enter the DNS search domain" read dnssearch echo "Please enter the DNS server" read dnsserver fi fi echo "WARNING WARNING WARNING WARNING WARNING WARNING" echo "Continuing will destroy all data on ${DEV}" echo "WARNING WARNING WARNING WARNING WARNING WARNING" echo "Do you wish to continue? (y/n)" read answer if [ $answer !=3D "y" ]; then echo "Aborting" exit 0 fi TMPDIR=3D`mktemp -d -q /tmp/installos.XXXXXX` if [ $? -ne 0 ]; then echo "Unable to create temporary directory" exit 1 fi mkdir "${TMPDIR}/mnt" gpart destroy -F ${DEV} || echo -n gpart create -s GPT ${DEV} gpart add -t freebsd-boot -s 64K ${DEV} gpart bootcode -b ${SRC}/boot/pmbr -p ${SRC}/boot/gptboot -i 1 ${DEV} gpart add -t freebsd-ufs -s 1G -l slash ${DEV} gpart add -t freebsd-swap -s 4G -l swap ${DEV} gpart add -t freebsd-ufs -s 1G -l var ${DEV} gpart add -t freebsd-ufs -s 20G -l usr ${DEV} gpart add -t freebsd-ufs -l local0 ${DEV} for d in 2 4 5 6; do newfs -j "${DEV}p${d}" done mount "${DEV}p2" "${TMPDIR}/mnt" mkdir "${TMPDIR}/mnt/var" "${TMPDIR}/mnt/usr" "${TMPDIR}/mnt/local0" mount "${DEV}p4" "${TMPDIR}/mnt/var" mount "${DEV}p5" "${TMPDIR}/mnt/usr" mount "${DEV}p6" "${TMPDIR}/mnt/local0" for d in base doc games kernel lib32 src; do echo "Extracting $d" tar -C "${TMPDIR}/mnt" -pxf /usr/freebsd-dist/${d}.txz done echo "Extracting port image" # Disable exit on error because tar will complain about chflag'd stuff set +e cat /image.txz.* | tar -C "${TMPDIR}/mnt" -pUxf - if [ $? -ne 0 ]; then echo "Warning unpack return an error" fi set -e echo "# Device Mountpoint FStype Options Dump Pass#" = >${TMPDIR}/mnt/etc/fstab echo '/dev/gpt/slash / ufs rw 1 1' = >>${TMPDIR}/mnt/etc/fstab echo '/dev/gpt/swap none swap sw 0 0' = >>${TMPDIR}/mnt/etc/fstab echo '/dev/gpt/var /var ufs rw 2 2' = >>${TMPDIR}/mnt/etc/fstab echo '/dev/gpt/usr /usr ufs rw 2 2' = >>${TMPDIR}/mnt/etc/fstab echo '/dev/gpt/local0 /local0 ufs rw 2 2' = >>${TMPDIR}/mnt/etc/fstab echo '/dev/cd0 /cdrom cd9660 ro,noauto 0 0' = >>${TMPDIR}/mnt/etc/fstab echo 'linprocfs /compat/linux/proc linprocfs rw 0 0' = >>${TMPDIR}/mnt/etc/fstab echo 'procfs /proc procfs rw,noauto 0 0' = >>${TMPDIR}/mnt/etc/fstab # Put your customisation stuff here if [ "$ifconfig" !=3D "DHCP" ]; then cat >${TMPDIR}/mnt/etc/resolv.conf <>${TMPDIR}/mnt/etc/aliases < 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 9D590106566C; Sun, 12 Feb 2012 08:29:51 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id F3E898FC13; Sun, 12 Feb 2012 08:29:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1C7qbSX096664; Sun, 12 Feb 2012 18:52:38 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 12 Feb 2012 18:52:37 +1100 (EST) From: Ian Smith To: "Bjoern A. Zeeb" In-Reply-To: Message-ID: <20120212173339.G93710@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <4F353E4A.6030903@noc.ntua.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@freebsd.org, ipfw@freebsd.org, Panagiotis Christias Subject: Re: Reducing the need to compile a custom kernel 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, 12 Feb 2012 08:29:51 -0000 On Fri, 10 Feb 2012 16:12:00 +0000, Bjoern A. Zeeb wrote: > On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: > > > On 10/2/2012 15:56, Alexander Leidinger wrote: > >> Hi, > >> > >> during some big discussions in the last monts on various lists, one of > >> the problems was that some people would like to use freebsd-update but > >> can't as they are using a custom kernel. With all the kernel modules we > >> provide, the need for a custom kernel should be small, but on the other > >> hand, we do not provide a small kernel-skeleton where you can load just > >> the modules you need. > >> > >> This should be easy to change. As a first step I took the generic kernel > >> and removed all devices which are available as modules, e.g. the USB > >> section consists now only of the USB_DEBUG option (so that the module is > >> build like with the current generic kernel). I also removed some storage > >> drivers which are not available as a module. The rationale is, that I > >> can not remove CAM from the kernel config if I let those drivers inside > >> (if those drivers are important enough, someone will probably fix the > >> problem and add the missing pieces to generate a module). > >> > >> Such a kernel would cover situations where people compile their own > >> kernel because they want to get rid of some unused kernel code (and > >> maybe even need the memory this frees up). > >> > >> The question is, is this enough? Or asked differently, why are you > >> compiling a custom kernel in a production environment (so I rule out > >> debug options which are not enabled in GENERIC)? Are there options which > >> you add which you can not add as a module (SW_WATCHDOG comes to my > >> mind)? If yes, which ones and how important are they for you? > > > > Hello, > > > > we are currently using on every server (in order to maintain a single custom kernel) the following options: > > > > IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT > > loadable, tunable there for this Copying this to ipfw@ on finding that net.inet.ip.fw.default_to_accept tunable is not mentioned in any of ipfw(8), loader(8) nor tuning(7). > > IPFIREWALL_FORWARD Unless something's changed, julian@ has pointed out (paraphrasing) that this adds bits of code to various parts of the stack and was thought to impact performance too much when unused to conditionalise each instance. I'm unsure if this is the only case ipfw still needs building in kernel? cheers, Ian > > ROUTETABLES=n > > melifaro and I are working on this; he'll fix the netgraph netflow part and I'll fix the #ifdefs and the tunable will be enough. > > > > Soon, we will also add: > > > > IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc > > IPSEC_FILTERTUNNEL has long been obsolete. > > > > Finally, once we upgrade our jail setup VIMAGE will be also a must. > > I have read that multiple times already and I'd love to but that's a looong way. > The plan might be to one day provide a 2nd kernel to install from and that freebsd-update can handle but we'll see. > > /bz From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 09:30:03 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FFC6106566C for ; Sun, 12 Feb 2012 09:30:03 +0000 (UTC) (envelope-from PETER@PEAN.ORG) Received: from system.jails.se (system.jails.se [IPv6:2001:16d8:cc1e:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 361AC8FC15 for ; Sun, 12 Feb 2012 09:30:03 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id CDE2C217F49 for ; Sun, 12 Feb 2012 10:30:00 +0100 (CET) Received: from [172.25.0.33] (c-9406e155.166-7-64736c14.cust.bredbandsbolaget.se [85.225.6.148]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 607ED217F43; Sun, 12 Feb 2012 10:29:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <4F36D0DA.4050208@FreeBSD.org> Date: Sun, 12 Feb 2012 10:29:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F36D0DA.4050208@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1251.1) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Feb 12 10:30:00 2012 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 4f37869826811132619246 X-DSPAM-Factors: 27, but, 0.40000, That, 0.40000, right, 0.40000, Received*cipher+AES128, 0.40000, Message-Id*49F9, 0.40000, Mime-Version*Message, 0.40000, or, 0.40000, computer+boot, 0.40000, Message-Id*BF3A+CB325395453D, 0.40000, machine+boots, 0.40000, X+is, 0.40000, Date*12, 0.40000, 9+0, 0.40000, 9+0, 0.40000, when+the, 0.40000, Received*9406e155.166, 0.40000, But, 0.40000, Received*2012, 0.40000, the+CF, 0.40000, 0+you, 0.40000, Received*12, 0.40000, else+that, 0.40000, Received*client+certificate, 0.40000, Cc*freebsd+stable, 0.40000, From*, 0.40000, after+the, 0.40000, From*Peter_Ankerst%e5l+ List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 09:30:03 -0000 On Feb 11, 2012, at 9:34 PM, Alexander Motin wrote: > On 02/11/12 20:15, Peter Ankerst=E5l wrote: >> In FreeBSD 8 i used the loader-variable hw.ata.ata_dma=3D0 to get my = computer boot on a CF card. But >> in FreeBSD 9.0 it doesn't seem to work. Could it be another variable = or is it something else that doesn't work >> in 9? The machine boots up the installer when the CF-card is not = present but when it is present it stops right >> after the "Timecounter" stuff. >=20 > On 9.0 you can to it with > hint.ata.X.mode=3DPIO4 > , where X is a bus number. >=20 > In recent 8/9-STABLE I've also resurrected hw.ata.ata_dma=3D0. >=20 That works, thanks! From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 11:06:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68E85106564A; Sun, 12 Feb 2012 11:06:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 20C238FC08; Sun, 12 Feb 2012 11:06:51 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC429F4.dip.t-dialin.net [79.196.41.244]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1E97E8447FD; Sun, 12 Feb 2012 12:06:37 +0100 (CET) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id 5D4A82E1A; Sun, 12 Feb 2012 12:06:34 +0100 (CET) Date: Sun, 12 Feb 2012 12:06:33 +0100 From: Alexander Leidinger To: perryh@pluto.rain.com Message-ID: <20120212120633.0000302d@unknown> In-Reply-To: <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> X-Mailer: Claws Mail 3.7.10cvs42 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1E97E8447FD.A4165 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.933, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.08, TW_KB 0.08, TW_TK 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329649599.26412@y5DioEOL0JSWYhwvDpIB5g X-EBL-Spam-Status: No Cc: thierry@freebsd.org, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 12 Feb 2012 11:06:52 -0000 On Sun, 12 Feb 2012 03:05:02 -0800 perryh@pluto.rain.com wrote: > Alexander Leidinger wrote: > > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas > > wrote: > > > is there another place to put options to atkbd and sc, like > > > these ones: > > > > > > options ATKBD_DFLT_KEYMAP # specify the built-in > > > keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > > ... > > > > No, there is no other way to add the keymap to the kernel directly > > (if you want to have it working correctly in single-user mode) > > instead of loading it with rc.conf. > > Might it be feasible to make it into a sysctl, so it could be set in > loader.conf? There is already a way to configure this as soon as you have a working userland. What this setting is doing is to replace the compiled-in default keymap with a different one, so that you have the one which matches your keyboard even when you enter the very first keystrokes in single-user mode (root-pw, path to shell, ...). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 11:31:20 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0427E106566C for ; Sun, 12 Feb 2012 11:31:20 +0000 (UTC) (envelope-from thierry@pompo.net) Received: from mx1b.lautre.net (mx1b.lautre.net [80.67.160.72]) by mx1.freebsd.org (Postfix) with ESMTP id B3B0C8FC12 for ; Sun, 12 Feb 2012 11:31:19 +0000 (UTC) Received: from graf.pompo.net (graf.pompo.net [78.225.128.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thierry@pompo.net) by mx1b.lautre.net (Postfix) with ESMTPSA id 746017F096 for ; Sun, 12 Feb 2012 12:31:18 +0100 (CET) Received: by graf.pompo.net (Postfix, from userid 1001) id E484D1145A; Sun, 12 Feb 2012 12:31:01 +0100 (CET) Date: Sun, 12 Feb 2012 12:31:01 +0100 From: Thierry Thomas To: stable@freebsd.org Message-ID: <20120212113101.GG64566@graf.pompo.net> Mail-Followup-To: stable@freebsd.org References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> <20120212120633.0000302d@unknown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <20120212120633.0000302d@unknown> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 9.0-STABLE i386 Organization: Kabbale Eros X-Face: (hRbQnK~Pt7$ct`!fupO(`y_WL4^-Iwn4@ly-.,[4xC4xc; y=\ipKMNm<1J>lv@PP~7Z<.t KjAnXLs: X-PGP: 0xC71405A2 Cc: Subject: Re: Reducing the need to compile a custom kernel 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, 12 Feb 2012 11:31:20 -0000 --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le dim 12 f=E9v 12 =E0 12:06:33 +0100, Alexander Leidinger =E9crivait=A0: > There is already a way to configure this as soon as you have a working > userland. What this setting is doing is to replace the compiled-in > default keymap with a different one, so that you have the one which > matches your keyboard even when you enter the very first keystrokes in > single-user mode (root-pw, path to shell, ...). That's why I use it: when you enter is this mode to solve some problem, it reduces the risk of errors and the stress to blindly type on a non- QWERTY keyboard. Regards, --=20 Th. Thomas. --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk83ovUACgkQc95pjMcUBaKSVwCfck69qBKVpvnOhDtLRSkUD1nW MZ0An2eLg7EseFmZJjgSfb+WyKPlA/9S =SvGB -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 15:12:23 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92799106564A for ; Sun, 12 Feb 2012 15:12:23 +0000 (UTC) (envelope-from luke-lists@hybrid-logic.co.uk) Received: from hybrid-sites.com (ns225413.hybrid-sites.com [176.31.225.127]) by mx1.freebsd.org (Postfix) with ESMTP id 54B498FC16 for ; Sun, 12 Feb 2012 15:12:22 +0000 (UTC) Received: from [127.0.0.1] (helo=youse) by hybrid-sites.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Rwait-000HNU-Fj; Sun, 12 Feb 2012 14:48:16 +0000 From: Luke Marsden To: Peter =?ISO-8859-1?Q?Ankerst=E5l?= In-Reply-To: References: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> Content-Type: text/plain; charset="UTF-8" Date: Sun, 12 Feb 2012 14:48:11 +0000 Message-ID: <1329058091.2541.104.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: quoted-printable X-Spam-bar: - Cc: stable@freebsd.org Subject: Re: Swap on zvol - recommendable? 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, 12 Feb 2012 15:12:23 -0000 > On Feb 6, 2012, at 11:57 AM, Patrick M. Hausen wrote: >=20 > > Hi, all, > >=20 > > is it possible to make a definite statement about swap on zvols? > >=20 > > I found some older discussions about a resource starvation > > scenario when ZFS arc would be the cause of the system > > running out of memory, trying to swap, yet the ZFS would > > not be accessible until some memory was freed - leading to > > a deadlock. > >=20 > > Is this still the case with RELENG_8? The various Root on > > ZFS guides mention both choices (decicated or gmirror > > partition vs. zvol), yet don't say anything about the respective > > merits or risks. I am aware of the fact that I cannot dump to > > a raidz2 zvol ... > >=20 On Tue, 2012-02-07 at 20:53 +0100, Peter Ankerst=C3=A5l wrote: > I can just tell you I had this problem still in 8.1 and it was a HUGE > problem. System stalled every two weeks or so. Now when the swap is > moved away from zfs it works fine. >=20 I can confirm that this is still a problem on 8.2 and 9.0. --=20 CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com=20 From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 15:18:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E811106566B; Sun, 12 Feb 2012 15:18:27 +0000 (UTC) (envelope-from gregoire.leroy@retenodus.net) Received: from slow3-v.mail.gandi.net (slow3-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id CEA968FC19; Sun, 12 Feb 2012 15:18:26 +0000 (UTC) X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay X-WhiteListed: mail was accepted with no delay Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by slow3-v.mail.gandi.net (Postfix) with ESMTP id DD77839A52; Sun, 12 Feb 2012 15:48:17 +0100 (CET) X-Originating-IP: 217.70.178.136 Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 36EB1172605; Sun, 12 Feb 2012 15:48:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ZilxPrjy6+hU; Sun, 12 Feb 2012 15:48:03 +0100 (CET) X-Originating-IP: 212.234.55.192 Received: from rena.localnet (unknown [212.234.55.192]) (Authenticated sender: gregoire.leroy@retenodus.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 83C3417228F; Sun, 12 Feb 2012 15:47:59 +0100 (CET) From: =?iso-8859-1?q?Gr=E9goire_Leroy?= To: freebsd-ipfw@freebsd.org Date: Sun, 12 Feb 2012 15:47:57 +0100 User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; ) References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120212173339.G93710@sola.nimnet.asn.au> In-Reply-To: <20120212173339.G93710@sola.nimnet.asn.au> X-KMail-Markup: true MIME-Version: 1.0 Message-Id: <201202121547.57404.gregoire.leroy@retenodus.net> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Bjoern A. Zeeb" , stable@freebsd.org, ipfw@freebsd.org, Ian Smith , Panagiotis Christias Subject: Re: Reducing the need to compile a custom kernel 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, 12 Feb 2012 15:18:27 -0000 > > >> The question is, is this enough? Or asked differently, why are you > > >> compiling a custom kernel in a production environment (so I rule out > > >> debug options which are not enabled in GENERIC)? Are there options > > >> which you add which you can not add as a module (SW_WATCHDOG comes > > >> to my mind)? If yes, which ones and how important are they for you? > > >=20 > > > Hello, > > >=20 > > > we are currently using on every server (in order to maintain a single > > > custom kernel) the following options: > > >=20 > > > IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT > >=20 > > loadable, tunable there for this Hi, On my gateway I use these options with FreeBSD 8.2 : options IPFIREWALL=20 options IPFIREWALL_VERBOSE=20 options IPFIREWALL_VERBOSE_LIMIT=3D5=20 options IPFIREWALL_DEFAULT_TO_ACCEPT=20 options IPDIVERT=20 options IPFIREWALL_FORWARD=20 options DUMMYNET=20 options HZ=3D1000=20 Regards, Gr=E9goire Leroy From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 15:32:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35316106564A for ; Sun, 12 Feb 2012 15:32:53 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B89E48FC1D for ; Sun, 12 Feb 2012 15:32:52 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id B2FBFE6410; Sun, 12 Feb 2012 15:32:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=z1yUBmSkY2rE 2/GnW9OEujqkQKY=; b=enjEyi4rZJK4Twi06GgyeTfq3dFfYAMf625PfVcuqM/+ V3N2d3/cWC9o6TFD+kF+TdrA4NdxEx5aruLu5MFoPOjYvlyzmaWHPq+1AaRZJNqW N82bHNlGKfOqyCOTF2j5brU8amP+MajCNSRs2lJX5Nb0lmZbqtnxvUYM2ZoGml4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=G46z/g jg1B8vYB8Yu8KnmGYyN3h68vBg13UQ8jLcekxWE/d2YyQ1TLzaUd555ASQEKjlwI GkcMqv5CMAQpmFciNrbTOoZnAkPKSsfoP3JgPZSpNYaa9UqNDlWL55CZGXpAsmU2 e4GUs/RNwxAaz5XdDtmmxlmMMnQgKE/yH4t/k= Received: from [192.168.1.92] (188-222-18-231.zone13.bethere.co.uk [188.222.18.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 71313E640F; Sun, 12 Feb 2012 15:32:51 +0000 (GMT) Message-ID: <4F37DBA3.7030304@cran.org.uk> Date: Sun, 12 Feb 2012 15:32:51 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Alex Samorukov References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> In-Reply-To: <4F35743B.4020302@os2.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joe Holden , FreeBSD Stable Mailing List Subject: Re: New BSD Installer 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, 12 Feb 2012 15:32:53 -0000 On 2/10/2012 7:47 PM, Alex Samorukov wrote: > I am highly against reverting. Old installer is not GPT aware and in > fact is unmaintained for a very long time. That's not really correct: quite a lot of work was done on it last year. -- Bruce From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 17:34:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E02FA106567B; Sun, 12 Feb 2012 17:34:33 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [IPv6:2a01:d0:81f8::2]) by mx1.freebsd.org (Postfix) with ESMTP id 95D698FC22; Sun, 12 Feb 2012 17:34:33 +0000 (UTC) Received: from [2001:470:6f:26:226:b9ff:fedd:5cf1] by s1.sdv.com.ua with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RwdJh-0001A0-SO; Sun, 12 Feb 2012 19:34:31 +0200 Message-ID: <4F37F81E.7070100@os2.kiev.ua> Date: Sun, 12 Feb 2012 18:34:22 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 12 Feb 2012 17:34:34 -0000 On 02/12/2012 01:54 AM, Adrian Chadd wrote: > Hi, > > What about the disk access is unaligned? Do you mean not sector aligned? or? Hi. Sector aligned. > This is a common problem people face doing disk IO analysis. > > The whole point about not allowing unaligned access is to make the > disk IO path cleaner. It does mean that the filesystem code (and GEOM > modules involved) need to be smarter. > > If the filesystem is doing ridiculously unaligned access then it > likely should be fixed. Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 18:09:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF637106564A for ; Sun, 12 Feb 2012 18:09:15 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id 53E038FC12 for ; Sun, 12 Feb 2012 18:09:15 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.129]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RwdrL-0003x6-2y for freebsd-stable@freebsd.org; Sun, 12 Feb 2012 19:09:12 +0100 Received: from dhcp-077-251-052-224.chello.nl ([77.251.52.224] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RwdrL-0000sC-DI for freebsd-stable@freebsd.org; Sun, 12 Feb 2012 19:09:11 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <20120211060207.GK5775@dan.emsphone.com> <20120211073527.GQ3283@deviant.kiev.zoral.com.ua> Date: Sun, 12 Feb 2012 19:09:10 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.61 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: 9090f8a1960d7f777b94d17b6f36e747 Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 18:09:15 -0000 On Sat, 11 Feb 2012 10:58:30 +0100, Randy Bush wrote: >> These statements are false, esp. worrying is that they are >> interwinned with some facts that get tilted to support false >> presumption. >> >> Kernel do not care about which interpreter is /libexec/ld-elf.so. >> The path to the interpreter is specified in the binary itself. So if you >> have 32bit binary that put '/libexec/ld-elf.so.1' into PH_INTERP, >> and /libexec/ld-elf.so.1 is 32bit, then amd64 kernel properly executes >> that combination. >> >> Kernel has a hack that falls back to try to use /libexec/ld-elf32.so.1 >> for some 'brands' of ELF images, in particular, for 32bit binaries. This >> is done to help in situation when 32bit binaries also specified the >> same path for interpreter. >> >> If you have 32bit world installed and booted 64bit kernel, it will boot. >> It is the same as running 32bit world in the jail. >> The management functions, like configuring network interfaces, ZFS >> and many other system setup functionality does not work, indeed. > > as the system in this case is half the planet away and without console > access, it might be helpful to have network interfaces working. > > so do you have direct suggestion(s) on how to hack the system (while the > 32-bit kernel is running) so that i can boot the 64-bit kernel and get > the 64-bit world up? Do you have a spare partition? Probably use the swap partition temporarily. Install the 64 bits stuff into it. Boot from it and than install the 64 bits stuff over the (now unused) 32 bits stuff and reboot into that. If something fails you can always go back to a bootable system. NB: disclaimer: I have never done this. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sun Feb 12 18:13:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B9610656B0 for ; Sun, 12 Feb 2012 18:13:57 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 41B378FC14 for ; Sun, 12 Feb 2012 18:13:56 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id Z6051i0041Y3wxoAD6Dwo2; Sun, 12 Feb 2012 18:13:56 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta15.emeryville.ca.mail.comcast.net with comcast id Z6Dv1i0054NgCEG8b6DvPZ; Sun, 12 Feb 2012 18:13:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q1CIDr9U036938; Sun, 12 Feb 2012 11:13:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Peter =?ISO-8859-1?Q?Ankerst=E5l?= In-Reply-To: References: <4F36D0DA.4050208@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" Date: Sun, 12 Feb 2012 11:13:53 -0700 Message-Id: <1329070433.7556.4.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Disable DMA. 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, 12 Feb 2012 18:13:57 -0000 On Sun, 2012-02-12 at 10:29 +0100, Peter Ankerstål wrote: > On Feb 11, 2012, at 9:34 PM, Alexander Motin wrote: > > > On 02/11/12 20:15, Peter Ankerstål wrote: > >> In FreeBSD 8 i used the loader-variable hw.ata.ata_dma=0 to get my computer boot on a CF card. But > >> in FreeBSD 9.0 it doesn't seem to work. Could it be another variable or is it something else that doesn't work > >> in 9? The machine boots up the installer when the CF-card is not present but when it is present it stops right > >> after the "Timecounter" stuff. > > > > On 9.0 you can to it with > > hint.ata.X.mode=PIO4 > > , where X is a bus number. > > > > In recent 8/9-STABLE I've also resurrected hw.ata.ata_dma=0. > > > That works, thanks! It's also useful to try modes other than PIO4 when using the finer-grained mode= control. We've been disabling dma completely on SBCs with CF sockets for years due to the kind of lockup you mention, but I recently discovered that some units run just fine with mode=WDMA2 (but not any dma modes faster than that). -- Ian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 02:04:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804531065670 for ; Mon, 13 Feb 2012 02:04:40 +0000 (UTC) (envelope-from pol@leissner.se) Received: from mailgate.leissner.se (mailgate.leissner.se [212.3.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id DEFAE8FC0C for ; Mon, 13 Feb 2012 02:04:39 +0000 (UTC) Received: from mailgate.leissner.se (localhost [127.0.0.1]) by mailgate.leissner.se (8.14.5/8.14.5) with ESMTP id q1D1oHBH061528 for ; Mon, 13 Feb 2012 02:50:17 +0100 (CET) (envelope-from pol@leissner.se) Received: (from uucp@localhost) by mailgate.leissner.se (8.14.5/8.14.5/Submit) id q1D1oHw7061527 for ; Mon, 13 Feb 2012 02:50:17 +0100 (CET) (envelope-from pol@leissner.se) Received: from pol.leissner.se(192.71.29.17), claiming to be "pol-server.leissner.se" via SMTP by mailgate.leissner.se, id smtpd5f7egA; Mon Feb 13 02:50:14 2012 Received: from pol-server.leissner.se (localhost [127.0.0.1]) by pol-server.leissner.se (8.14.5/8.14.5) with ESMTP id q1D1oD5q072463 for ; Mon, 13 Feb 2012 02:50:13 +0100 (CET) (envelope-from pol@leissner.se) Received: (from pol@localhost) by pol-server.leissner.se (8.14.5/8.14.5/Submit) id q1D1oDGS072462 for freebsd-stable@freebsd.org; Mon, 13 Feb 2012 02:50:13 +0100 (CET) (envelope-from pol@leissner.se) X-Authentication-Warning: pol-server.leissner.se: pol set sender to pol@leissner.se using -f Date: Mon, 13 Feb 2012 02:50:13 +0100 From: Peter Olsson To: freebsd-stable@freebsd.org Message-ID: <20120213015013.GA71062@pol-server.leissner.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2 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, 13 Feb 2012 02:04:40 -0000 Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, running Openbox. My WAN is about 1.2 Mbps, and I try to run RDP to windows servers beyond my WAN. RDP to a Windows Server 2003 SP2 is fast and works without problems. RDP to a Windows Server 2008 R2 is very slow, and sometimes just disconnects. I tried changing a couple of net.inet.tcp sysctl: net.inet.tcp.recvbuf_max=10485760 net.inet.tcp.recvbuf_inc=65535 net.inet.tcp.sendbuf_max=10485760 net.inet.tcp.sendbuf_inc=65535 net.inet.tcp.recvbuf_auto=0 net.inet.tcp.sendbuf_auto=0 net.inet.tcp.sendspace=65536 net.inet.tcp.ecn.enable=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.tso=0 net.inet.tcp.sack.enable=0 net.inet.tcp.path_mtu_discovery=0 Some in combination with others, and some by themselves. I also tried net.link.ifqmaxlen=1024 in /boot/loader.conf. Nothing has helped, do you have any ideas what I should tune? Thanks! -- Peter Olsson pol@leissner.se From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 03:25:23 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA40F1065672; Mon, 13 Feb 2012 03:25:23 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 7499B8FC14; Mon, 13 Feb 2012 03:25:23 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q1D3PLFg016316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 12 Feb 2012 19:25:22 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q1D3PLxG016313; Sun, 12 Feb 2012 19:25:21 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA16261; Sun, 12 Feb 12 19:18:47 PST Date: Mon, 13 Feb 2012 02:17:46 -0800 From: perryh@pluto.rain.com To: Alexander@Leidinger.net Message-Id: <4f38e34a.lZtNaNETBImp/XiD%perryh@pluto.rain.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> <20120212120633.0000302d@unknown> In-Reply-To: <20120212120633.0000302d@unknown> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: thierry@freebsd.org, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 03:25:23 -0000 Alexander Leidinger wrote: > On Sun, 12 Feb 2012 03:05:02 -0800 perryh@pluto.rain.com wrote: > > Alexander Leidinger wrote: > > > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas > > > wrote: > > > > is there another place to put options to atkbd and sc, like > > > > these ones: > > > > > > > > options ATKBD_DFLT_KEYMAP # specify the built-in > > > > keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc > > > > ... > > > > > > No, there is no other way to add the keymap to the kernel > > > directly (if you want to have it working correctly in > > > single-user mode) instead of loading it with rc.conf. > > > > Might it be feasible to make it into a sysctl, so it could be > > set in loader.conf? > > There is already a way to configure this as soon as you have a > working userland. What this setting is doing is to replace the > compiled-in default keymap with a different one, so that you have > the one which matches your keyboard even when you enter the very > first keystrokes in single-user mode (root-pw, path to shell, ...). My point is, if it were made into a sysctl, it could presumably be set in loader.conf -- thereby providing the correct keymap for those "very first keystrokes" without needing a custom kernel. I know that's not how it works _now_, but is there some reason why this approach is not feasible? It seems like something that could potentially go on the the list of projects to reduce the need for custom kernels. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 05:27:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BA71065690 for ; Mon, 13 Feb 2012 05:27:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 40A348FC12 for ; Mon, 13 Feb 2012 05:27:09 +0000 (UTC) Received: by werm13 with SMTP id m13so5013313wer.13 for ; Sun, 12 Feb 2012 21:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=S2/AErIZVP/+qVw7OGCxiUI1EwFjbr98+Y+gDXBXpE4=; b=Zk3J5kMaEw/2nW0J4cja/mFT+NsoVnd+hRlHSm1bIHgsNOcdVUqXdZmZL0Zy+JgGDS DaETSuXEVZT5Nd6PM31RITOyFAA/KH1YRulFguJfDle3II6FJxb6nguQwG/tbw+MtbUZ EFVHoogTgz0efPpD1fy1iJ7tvRvc5b0rEkF9s= MIME-Version: 1.0 Received: by 10.180.107.34 with SMTP id gz2mr21863471wib.21.1329110829161; Sun, 12 Feb 2012 21:27:09 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Sun, 12 Feb 2012 21:27:09 -0800 (PST) In-Reply-To: <4F37F81E.7070100@os2.kiev.ua> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> Date: Sun, 12 Feb 2012 21:27:09 -0800 X-Google-Sender-Auth: O6WHhg3Bofu5qgtIY8gHPek9YwI Message-ID: From: Adrian Chadd To: Alex Samorukov Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 05:27:10 -0000 On 12 February 2012 09:34, Alex Samorukov wrote: > Yes. But it will nit fix non-cached access to the disk (raw) devices. And > this is the main reason why ntfs-3g and exfat are much slower then working > on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. So if there are alignment issues, let's fix those up first so filesystems act sensibly with the block device layer. Then yes, adding a caching layer that works. I didn't get very good performance with g_cache when i last tried it. Adrian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 06:36:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41E44106564A; Mon, 13 Feb 2012 06:36:34 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [IPv6:2a01:d0:81f8::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1BBF8FC12; Mon, 13 Feb 2012 06:36:33 +0000 (UTC) Received: from [2001:470:6f:26:226:b9ff:fedd:5cf1] by s1.sdv.com.ua with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RwpWV-000CAR-74; Mon, 13 Feb 2012 08:36:29 +0200 Message-ID: <4F38AF69.6010506@os2.kiev.ua> Date: Mon, 13 Feb 2012 07:36:25 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 06:36:34 -0000 On 02/13/2012 06:27 AM, Adrian Chadd wrote: > On 12 February 2012 09:34, Alex Samorukov wrote: > >> Yes. But it will nit fix non-cached access to the disk (raw) devices. And >> this is the main reason why ntfs-3g and exfat are much slower then working >> on Linux. > But _that_ can be fixed with the appropriate application of a sensible > caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. Also, caching in user-land is much slower and more dangerous. There is a libublio utility which is done to provide userland caching (it implements pwrite/pread replacement) and it is in use by this 2 ports. > > So if there are alignment issues, let's fix those up first so > filesystems act sensibly with the block device layer. Then yes, adding > a caching layer that works. I didn't get very good performance with > g_cache when i last tried it. Because its very primitive. Once again - try to compare performance of the exfat or ntfs-3g on Linux and FreeBSD. Raw device speed (i used USB) is pretty the same, but resulting speed is very different, as well as I/O characteristic. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 09:36:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41D0D106566C for ; Mon, 13 Feb 2012 09:36:15 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id DA7D88FC14 for ; Mon, 13 Feb 2012 09:36:14 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RwsKS-0004VA-Fj; Mon, 13 Feb 2012 09:36:12 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RwsKS-000Da2-F2; Mon, 13 Feb 2012 09:36:12 +0000 To: freebsd-stable@freebsd.org, ronald-freebsd8@klop.yi.org In-Reply-To: Message-Id: From: Pete French Date: Mon, 13 Feb 2012 09:36:12 +0000 Cc: Subject: Re: 9-stable from i386 to amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 09:36:15 -0000 > Do you have a spare partition? Probably use the swap partition temporarily. > Install the 64 bits stuff into it. Boot from it and than install the 64 > bits stuff over the (now unused) 32 bits stuff and reboot into that. If > something fails you can always go back to a bootable system. > NB: disclaimer: I have never done this. You may not, but I have, several times, and it works fine - indeed it is how I originally moved all my 32 bit systems over to 64 bit. Doing this remotely, as the original poster wanted, is tricky though without some kind of iLo-style access. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 10:04:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2201D1065670 for ; Mon, 13 Feb 2012 10:04:01 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BECC8FC0C for ; Mon, 13 Feb 2012 10:04:00 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4247855bkc.13 for ; Mon, 13 Feb 2012 02:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+grW9zGywhbKknBAiCs9IKh9RfYkGnxdsCgHWXmufYM=; b=AhhrK2d/eArOCFNKhxbtiahS5PjD+BAyUI3divE8wZKxsRa0f3F0LdcdNPKA3AftFO /+GmOA7sg/35+v8guqr3NyPkwQ/qzWQKsI8zRrIpMPR2KRLvpxqZmKKBF+jR287tQZi8 bNwH6j39NTAxqJTLRJ7vNjgxyHy3MlmmDqIhg= Received: by 10.204.129.203 with SMTP id p11mr6612086bks.109.1329127439394; Mon, 13 Feb 2012 02:03:59 -0800 (PST) Received: from [192.168.50.103] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id y9sm44569747bkw.5.2012.02.13.02.03.58 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 02:03:58 -0800 (PST) Message-ID: <4F38E00B.2020408@gmail.com> Date: Mon, 13 Feb 2012 11:03:55 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Kenneth D. Merry" References: <20120202191105.GA55719@nargothrond.kdm.org> In-Reply-To: <20120202191105.GA55719@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 10:04:01 -0000 Kenneth D. Merry schreef: > Hi folks, > > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. > > Please test it out and let me and Kashyap (CCed) know if you run into > any problems. > > In addition to supporting WarpDrive, the driver also supports Integrated > RAID. > > Thanks to LSI for doing the work on this driver! > > Note that the CAM infrastructure changes that went into FreeBSD/head along > with this driver have not gone into either stable/9 or stable/8. Only the > driver itself has been merged. > > The CAM infrastructure changes depend on some other da(4) driver changes > that will need to get merged before they can go back. If that merge > happens, it will probably only be into stable/9. > > A couple of notes about issues with this driver: > > - Unlike the previous mps(4) driver, it probes sequentially. If you have > a lot of drives in your system, it will take a while to probe them all. > - You may see warning messages like this: > > _mapping_add_new_device: failed to add the device with handle 0x0019 to persiste > nt table because there is no free space available > _mapping_add_new_device: failed to add the device with handle 0x001a to persiste > nt table because there is no free space available > > - The driver is not endian safe. (It assumes a little endian machine.) > This is not new, the previous version of the driver had the same issue. > > The LSI folks know about these issues. The driver has passed their testing > process. > > Many thanks to LSI for going through the effort to support FreeBSD. > > Ken Hello all. I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 On FreeBSD 9.0RELEASE i have the following order. Seen from the front of the case. da3 da7 da11 da15 da2 da6 da10 da14 da1 da5 da9 da13 da0 da4 da8 da12 But now it has shuffled the order. da8 da 14 da12 da10 da9 da15 da13 da11 da1 da6 da2 da5 da0 da7 da3 da4 There is no logic at all, and it is very hard to figure out when a disk dies which one it is. regards Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 10:42:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167DE1065672 for ; Mon, 13 Feb 2012 10:42:40 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by mx1.freebsd.org (Postfix) with ESMTP id 892538FC0C for ; Mon, 13 Feb 2012 10:42:39 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTzjpHrRRX/LjVWNRaPrLQp7vhcspDrob@postini.com; Mon, 13 Feb 2012 02:42:39 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 05:47:46 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 05:42:37 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 13 Feb 2012 16:12:33 +0530 From: "Desai, Kashyap" To: Johan Hendriks , "Kenneth D. Merry" Date: Mon, 13 Feb 2012 16:12:33 +0530 Thread-Topic: LSI supported mps(4) driver in stable/9 and stable/8 Thread-Index: AczqNvQfGgJuzfC3SjORNC5BGNsApQAAtC0g Message-ID: References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> In-Reply-To: <4F38E00B.2020408@gmail.com> 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: freebsd-stable Subject: RE: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 10:42:40 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Johan Hendriks > Sent: Monday, February 13, 2012 3:34 PM > To: Kenneth D. Merry > Cc: freebsd-stable > Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 >=20 > Kenneth D. Merry schreef: > > Hi folks, > > > > The LSI-supported version of the mps(4) driver that supports their 6Gb > SAS > > HBAs as well as WarpDrive controllers, is now in stable/9 and > stable/8. > > > > Please test it out and let me and Kashyap (CCed) know if you run into > > any problems. > > > > In addition to supporting WarpDrive, the driver also supports > Integrated > > RAID. > > > > Thanks to LSI for doing the work on this driver! > > > > Note that the CAM infrastructure changes that went into FreeBSD/head > along > > with this driver have not gone into either stable/9 or stable/8. Only > the > > driver itself has been merged. > > > > The CAM infrastructure changes depend on some other da(4) driver > changes > > that will need to get merged before they can go back. If that merge > > happens, it will probably only be into stable/9. > > > > A couple of notes about issues with this driver: > > > > - Unlike the previous mps(4) driver, it probes sequentially. If you > have > > a lot of drives in your system, it will take a while to probe them > all. > > - You may see warning messages like this: > > > > _mapping_add_new_device: failed to add the device with handle 0x0019 > to persiste > > nt table because there is no free space available > > _mapping_add_new_device: failed to add the device with handle 0x001a > to persiste > > nt table because there is no free space available > > > > - The driver is not endian safe. (It assumes a little endian > machine.) > > This is not new, the previous version of the driver had the same > issue. > > > > The LSI folks know about these issues. The driver has passed their > testing > > process. > > > > Many thanks to LSI for going through the effort to support FreeBSD. > > > > Ken > Hello all. >=20 > I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a > 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 > On FreeBSD 9.0RELEASE i have the following order. > Seen from the front of the case. > da3 da7 da11 da15 > da2 da6 da10 da14 > da1 da5 da9 da13 > da0 da4 da8 da12 >=20 > But now it has shuffled the order. > da8 da 14 da12 da10 > da9 da15 da13 da11 > da1 da6 da2 da5 > da0 da7 da3 da4 >=20 > There is no logic at all, and it is very hard to figure out when a disk > dies which one it is. Can you attach dmesg logs ? Basically now Drive will not ask CAM layer to add device using XPT_ASYC cal= l. It will ask CAM layer to rescan the bus.=20 So how CAM layer detects Drives is beyond Low level driver and it is obviou= sly no guaranty of sequence of daX. If you have some X Drives attached to enclosure, target IDs of those Drive = will be generated by Driver based on=20 which mode mapping table is.=20 1. Enclosure slot mapping 2. Device mapping. For your case best choice will be Enclosure slot mapping. Assume you have E= nclosure slop mapping. Target ID assignment is part of Driver which will consistence across all re= boot. _but_ when Driver call rescan bus (as part of device add), it will scan bus= in sequence and later peripher layer will assing device naming. So it is completely unsure which device will get what device name. e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, Drive-C= and Drive-D. (Consider alphabetical order is mapped to slot number ) So Driver will assign below target id. (target id 0-7 is reserved for local= port of HBA) Drive- A Target ID -8=20 Drive- B Target ID -9 Drive- C Target ID -10 Drive- D Target ID -11 You cannot expect Drive-A will be assigned to da0. (and similar Drive-D wil= l get da3). In summary, This behavior is visible just because of new change in driver, = but it is never *must* follow condition for any driver. Device naming is part of CAM layer. >=20 >=20 > regards > Johan Hendriks >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 11:05:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 249EC106566C; Mon, 13 Feb 2012 11:05:34 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id BE2268FC18; Mon, 13 Feb 2012 11:05:33 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC42309.dip.t-dialin.net [79.196.35.9]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 951E6844A43; Mon, 13 Feb 2012 12:05:18 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id C3F0B2F1D; Mon, 13 Feb 2012 12:05:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329131115; bh=XuPMgc0Oe4pZ838EEiClTRYkLqbnsijZPGDpTtteOp4=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=QRFaem7DNfnZb4ZwQpNWl/kcdZmXFfCS5xoy/kfTmgh+GkSggKCj81SNfAJUuo+uI PGcftlccQwUpfxwu0sj+d2Ajx2hvXeZxa3gtPPxlB81j4yvxBTgl15s1yl9f5KvyyY KaThn3fPjhR1VhpgPZVpdXOVvFVHw9JqvkS7PVqHkLssooDLIGCzK3Ksps1TxqAM3d CYNSWWn6kvDjqHXsTIY/PXlGCY7CMAiP8uZTfZlXarAHyc3sm4B7JVnoDUUdeuIZOa wwU23St8Z1ASfcVVhQpnotUoZLTmwyKgPrmMSHx1T/4y7eIk1qN4EJ+4Sl7d2Ce9ho 6HtA5SPZy4P/Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1DB5Enf040281; Mon, 13 Feb 2012 12:05:14 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.20 ([85.94.224.20]) by webmail.leidinger.net (Horde Framework) with HTTP; Mon, 13 Feb 2012 12:05:14 +0100 Date: Mon, 13 Feb 2012 12:05:14 +0100 Message-ID: <20120213120514.Horde.LMNbOJjmRSRPOO5qpDYJzWA@webmail.leidinger.net> From: Alexander Leidinger To: perryh@pluto.rain.com References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> <20120212120633.0000302d@unknown> <4f38e34a.lZtNaNETBImp/XiD%perryh@pluto.rain.com> In-Reply-To: <4f38e34a.lZtNaNETBImp/XiD%perryh@pluto.rain.com> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 951E6844A43.AF03C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.128, required 6, autolearn=disabled, AWL -1.53, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_SORBS 1.00, RCVD_IN_SORBS_WEB 0.61, TW_KB 0.08, TW_TK 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329735920.31264@iKl0oM9vEKLrUUe87Qi9eg X-EBL-Spam-Status: No Cc: thierry@freebsd.org, stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 11:05:34 -0000 Quoting perryh@pluto.rain.com (from Mon, 13 Feb 2012 02:17:46 -0800): > Alexander Leidinger wrote: >> On Sun, 12 Feb 2012 03:05:02 -0800 perryh@pluto.rain.com wrote: >> > Alexander Leidinger wrote: >> > > On Sat, 11 Feb 2012 13:40:41 +0100 Thierry Thomas >> > > wrote: >> > > > is there another place to put options to atkbd and sc, like >> > > > these ones: >> > > > >> > > > options ATKBD_DFLT_KEYMAP # specify the built-in >> > > > keymap makeoptions ATKBD_DFLT_KEYMAP=fr.iso.acc >> > > > ... >> > > >> > > No, there is no other way to add the keymap to the kernel >> > > directly (if you want to have it working correctly in >> > > single-user mode) instead of loading it with rc.conf. >> > >> > Might it be feasible to make it into a sysctl, so it could be >> > set in loader.conf? >> >> There is already a way to configure this as soon as you have a >> working userland. What this setting is doing is to replace the >> compiled-in default keymap with a different one, so that you have >> the one which matches your keyboard even when you enter the very >> first keystrokes in single-user mode (root-pw, path to shell, ...). > > My point is, if it were made into a sysctl, it could presumably > be set in loader.conf -- thereby providing the correct keymap for > those "very first keystrokes" without needing a custom kernel. > > I know that's not how it works _now_, but is there some reason why > this approach is not feasible? It seems like something that could > potentially go on the the list of projects to reduce the need for > custom kernels. Feasible: depend upon your definition of "feasible". You would have to add all keymaps statically into the kernel. No idea which parts exactly we talk about, but: ---snip--- % du -h /usr/share/syscons/ 40k /usr/share/syscons/scrnmaps 570k /usr/share/syscons/fonts 1.1M /usr/share/syscons/keymaps 1.8M /usr/share/syscons/ ---snip--- I wouldn't mind for 40k, but 1.8M looks more like the value to calculate with. Anyway, this is out of the scope of the original question. Bye, Alexander. -- On successive charts of the same organization, the number of boxes will never decrease. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 11:11:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64472106566C for ; Mon, 13 Feb 2012 11:11:36 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D20E28FC14 for ; Mon, 13 Feb 2012 11:11:35 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4314129bkc.13 for ; Mon, 13 Feb 2012 03:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GFuNi9joe+F1zSUO42x+jVHiJkca/o5cehLYuQHnnXw=; b=pa1DqVUiBsvHOaexMTXS/qfqZ4/X2HW1v47b0k1DB6Erw8V+i3g/ClnHsJl8RtErUm OBnT0uUnlYQ94BgJvojj1Wmdyk+xa00HOVvIckN1GW0dm3IfCTP5RjYmYM44awuIBPDh lKM1uzsnBc/EfkcGLH0Fa31DYIIROq4j/GBC0= Received: by 10.205.125.12 with SMTP id gq12mr7042378bkc.39.1329131494437; Mon, 13 Feb 2012 03:11:34 -0800 (PST) Received: from [192.168.50.103] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id cg2sm45101550bkb.12.2012.02.13.03.11.32 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 03:11:33 -0800 (PST) Message-ID: <4F38EFE2.7010905@gmail.com> Date: Mon, 13 Feb 2012 12:11:30 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Desai, Kashyap" References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 11:11:36 -0000 Desai, Kashyap schreef: > >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Johan Hendriks >> Sent: Monday, February 13, 2012 3:34 PM >> To: Kenneth D. Merry >> Cc: freebsd-stable >> Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 >> >> Kenneth D. Merry schreef: >>> Hi folks, >>> >>> The LSI-supported version of the mps(4) driver that supports their 6Gb >> SAS >>> HBAs as well as WarpDrive controllers, is now in stable/9 and >> stable/8. >>> Please test it out and let me and Kashyap (CCed) know if you run into >>> any problems. >>> >>> In addition to supporting WarpDrive, the driver also supports >> Integrated >>> RAID. >>> >>> Thanks to LSI for doing the work on this driver! >>> >>> Note that the CAM infrastructure changes that went into FreeBSD/head >> along >>> with this driver have not gone into either stable/9 or stable/8. Only >> the >>> driver itself has been merged. >>> >>> The CAM infrastructure changes depend on some other da(4) driver >> changes >>> that will need to get merged before they can go back. If that merge >>> happens, it will probably only be into stable/9. >>> >>> A couple of notes about issues with this driver: >>> >>> - Unlike the previous mps(4) driver, it probes sequentially. If you >> have >>> a lot of drives in your system, it will take a while to probe them >> all. >>> - You may see warning messages like this: >>> >>> _mapping_add_new_device: failed to add the device with handle 0x0019 >> to persiste >>> nt table because there is no free space available >>> _mapping_add_new_device: failed to add the device with handle 0x001a >> to persiste >>> nt table because there is no free space available >>> >>> - The driver is not endian safe. (It assumes a little endian >> machine.) >>> This is not new, the previous version of the driver had the same >> issue. >>> The LSI folks know about these issues. The driver has passed their >> testing >>> process. >>> >>> Many thanks to LSI for going through the effort to support FreeBSD. >>> >>> Ken >> Hello all. >> >> I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and a >> 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 >> On FreeBSD 9.0RELEASE i have the following order. >> Seen from the front of the case. >> da3 da7 da11 da15 >> da2 da6 da10 da14 >> da1 da5 da9 da13 >> da0 da4 da8 da12 >> >> But now it has shuffled the order. >> da8 da 14 da12 da10 >> da9 da15 da13 da11 >> da1 da6 da2 da5 >> da0 da7 da3 da4 >> >> There is no logic at all, and it is very hard to figure out when a disk >> dies which one it is. > Can you attach dmesg logs ? > Basically now Drive will not ask CAM layer to add device using XPT_ASYC call. > It will ask CAM layer to rescan the bus. > > So how CAM layer detects Drives is beyond Low level driver and it is obviously no guaranty of sequence of daX. > If you have some X Drives attached to enclosure, target IDs of those Drive will be generated by Driver based on > which mode mapping table is. > 1. Enclosure slot mapping > 2. Device mapping. > > For your case best choice will be Enclosure slot mapping. Assume you have Enclosure slop mapping. > > Target ID assignment is part of Driver which will consistence across all reboot. > _but_ when Driver call rescan bus (as part of device add), it will scan bus in sequence and later peripher layer will assing device naming. > So it is completely unsure which device will get what device name. > > e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, Drive-C and Drive-D. (Consider alphabetical order is mapped to slot number ) > So Driver will assign below target id. (target id 0-7 is reserved for local port of HBA) > > Drive- A Target ID -8 > Drive- B Target ID -9 > Drive- C Target ID -10 > Drive- D Target ID -11 > > You cannot expect Drive-A will be assigned to da0. (and similar Drive-D will get da3). > > In summary, This behavior is visible just because of new change in driver, but it is never *must* follow condition for any driver. > Device naming is part of CAM layer. > > >> >> regards >> Johan Hendriks >> >> >> _______________________________________________ >> 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" Ok so it is not the mps driver who does the naming but cam, and that also has changed on 9.0 Stable. Well i use gpart labels for the pool, so i can use the gpart labels to yank the right disk. But it would be nicer if there was some kind of logic in the numbering of the devices. Here is the dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #0: Mon Feb 13 10:22:44 CET 2012 root@filer01.testdomain.local:/usr/obj/usr/src/sys/KRNL amd64 CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x15bae3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16493441024 (15729 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 19 at device 6.0 on pci0 pci1: on pcib1 mps0: port 0xe000-0xe0ff mem 0xfb600000-0xfb603fff irq 19 at device 0.0 on pci1 mps0: Firmware: 11.00.00.00, Driver: 11.255.03.00-fbsd mps0: IOCCapabilities: 1285c em0: port 0xf020-0xf03f mem 0xfb800000-0xfb81ffff,0xfb824000-0xfb824fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:25:90:57:20:bd ehci0: mem 0xfb823000-0xfb8233ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 em1: port 0xd000-0xd01f mem 0xfb700000-0xfb71ffff,0xfb720000-0xfb723fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 3 vectors em1: Ethernet address: 00:25:90:57:20:bc ehci1: mem 0xfb822000-0xfb8223ff irq 23 at device 29.0 on pci0 usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 vgapci0: mem 0xf9000000-0xf9ffffff,0xfb000000-0xfb003fff,0xfa800000-0xfaffffff irq 23 at device 3.0 on pci4 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f mem 0xfb821000-0xfb8217ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff 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 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered da0 at mps0 bus 0 scbus0 target 8 lun 0 da0: Fixed Direct Access SCSI-6 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da1 at mps0 bus 0 scbus0 target 9 lun 0 da1: Fixed Direct Access SCSI-6 device da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da2 at mps0 bus 0 scbus0 target 10 lun 0 da2: Fixed Direct Access SCSI-6 device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da3 at mps0 bus 0 scbus0 target 11 lun 0 da3: Fixed Direct Access SCSI-6 device da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da4 at mps0 bus 0 scbus0 target 12 lun 0 da4: Fixed Direct Access SCSI-6 device da4: 300.000MB/s transfers da4: Command Queueing enabled da4: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da5 at mps0 bus 0 scbus0 target 13 lun 0 da5: Fixed Direct Access SCSI-6 device da5: 150.000MB/s transfers da5: Command Queueing enabled da5: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da8 at mps0 bus 0 scbus0 target 19 lun 0 da8: Fixed Direct Access SCSI-6 device da8: 300.000MB/s transfers da8: Command Queueing enabled da8: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da9 at mps0 bus 0 scbus0 target 20 lun 0 da9: Fixed Direct Access SCSI-6 device da9: 300.000MB/s transfers da9: Command Queueing enabled da9: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) da11 at mps0 bus 0 scbus0 target 22 lun 0 da11: Fixed Direct Access SCSI-6 device da11: 150.000MB/s transfers da11: Command Queueing enabled da11: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da12 at mps0 bus 0 scbus0 target 23 lun 0 da12: Fixed Direct Access SCSI-6 device da12: 150.000MB/s transfers da12: Command Queueing enabled da12: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da13 at mps0 bus 0 scbus0 target 24 lun 0 da13: Fixed Direct Access SCSI-6 device da13: 150.000MB/s transfers da13: Command Queueing enabled da13: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da14 at mps0 bus 0 scbus0 target 27 lun 0 da14: Fixed Direct Access SCSI-6 device da14: 300.000MB/s transfers da14: Command Queueing enabled da14: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) da15 at mps0 bus 0 scbus0 target 28 lun 0 da15: Fixed Direct Access SCSI-6 device da15: 150.000MB/s transfers da15: Command Queueing enabled da15: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) ses0 at mps0 bus 0 scbus0 target 16 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 600.000MB/s transfers ses0: Command Queueing enabled ses0: SCSI-3 SES Device da6 at mps0 bus 0 scbus0 target 17 lun 0 da6: Fixed Direct Access SCSI-6 device da6: 150.000MB/s transfers da6: Command Queueing enabled da6: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) cd0 at ahcich2 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 da7 at mps0 bus 0 scbus0 target 18 lun 0 da7: Fixed Direct Access SCSI-6 device da7: 150.000MB/s transfers da7: Command Queueing enabled da7: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! Timecounter "TSC-low" frequency 12082198 Hz quality 1000 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 da10 at mps0 bus 0 scbus0 target 21 lun 0 da10: Fixed Direct Access SCSI-6 device da10: 300.000MB/s transfers da10: Command Queueing enabled da10: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) uhub3: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=0 ukbd0: on usbus0 kbd2 at ukbd0 Trying to mount root from ufs:/dev/ada0p2 [rw]... em0: link state changed to UP Camcontrol devlist filer01 ~ # camcontrol devlist at scbus0 target 8 lun 0 (pass0,da0) at scbus0 target 9 lun 0 (pass1,da1) at scbus0 target 10 lun 0 (pass2,da2) at scbus0 target 11 lun 0 (pass3,da3) at scbus0 target 12 lun 0 (pass4,da4) at scbus0 target 13 lun 0 (pass5,da5) at scbus0 target 16 lun 0 (ses0,pass6) at scbus0 target 17 lun 0 (pass7,da6) at scbus0 target 18 lun 0 (pass8,da7) at scbus0 target 19 lun 0 (pass9,da8) at scbus0 target 20 lun 0 (pass10,da9) at scbus0 target 21 lun 0 (pass11,da10) at scbus0 target 22 lun 0 (pass12,da11) at scbus0 target 23 lun 0 (pass13,da12) at scbus0 target 24 lun 0 (pass14,da13) at scbus0 target 27 lun 0 (pass15,da14) at scbus0 target 28 lun 0 (pass16,da15) at scbus1 target 0 lun 0 (ada0,pass17) at scbus3 target 0 lun 0 (pass18,cd0) regards johan From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 11:21:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B20B106566C for ; Mon, 13 Feb 2012 11:21:46 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by mx1.freebsd.org (Postfix) with ESMTP id 65AA38FC08 for ; Mon, 13 Feb 2012 11:21:45 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTzjySFuAHPuP2nihgKtIS12UFi+BX7ea@postini.com; Mon, 13 Feb 2012 03:21:45 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 06:26:52 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 06:21:43 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Mon, 13 Feb 2012 16:51:40 +0530 From: "Desai, Kashyap" To: Johan Hendriks Date: Mon, 13 Feb 2012 16:51:38 +0530 Thread-Topic: LSI supported mps(4) driver in stable/9 and stable/8 Thread-Index: AczqQEOtOOb6fdzaRei5UgrKq8V69wAAHgiw Message-ID: References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> <4F38EFE2.7010905@gmail.com> In-Reply-To: <4F38EFE2.7010905@gmail.com> 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: freebsd-stable Subject: RE: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 11:21:46 -0000 > -----Original Message----- > From: Johan Hendriks [mailto:joh.hendriks@gmail.com] > Sent: Monday, February 13, 2012 4:42 PM > To: Desai, Kashyap > Cc: freebsd-stable > Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 > > Desai, Kashyap schreef: > > > >> -----Original Message----- > >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > >> stable@freebsd.org] On Behalf Of Johan Hendriks > >> Sent: Monday, February 13, 2012 3:34 PM > >> To: Kenneth D. Merry > >> Cc: freebsd-stable > >> Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 > >> > >> Kenneth D. Merry schreef: > >>> Hi folks, > >>> > >>> The LSI-supported version of the mps(4) driver that supports their > 6Gb > >> SAS > >>> HBAs as well as WarpDrive controllers, is now in stable/9 and > >> stable/8. > >>> Please test it out and let me and Kashyap (CCed) know if you run > into > >>> any problems. > >>> > >>> In addition to supporting WarpDrive, the driver also supports > >> Integrated > >>> RAID. > >>> > >>> Thanks to LSI for doing the work on this driver! > >>> > >>> Note that the CAM infrastructure changes that went into FreeBSD/head > >> along > >>> with this driver have not gone into either stable/9 or stable/8. > Only > >> the > >>> driver itself has been merged. > >>> > >>> The CAM infrastructure changes depend on some other da(4) driver > >> changes > >>> that will need to get merged before they can go back. If that merge > >>> happens, it will probably only be into stable/9. > >>> > >>> A couple of notes about issues with this driver: > >>> > >>> - Unlike the previous mps(4) driver, it probes sequentially. If > you > >> have > >>> a lot of drives in your system, it will take a while to probe > them > >> all. > >>> - You may see warning messages like this: > >>> > >>> _mapping_add_new_device: failed to add the device with handle 0x0019 > >> to persiste > >>> nt table because there is no free space available > >>> _mapping_add_new_device: failed to add the device with handle 0x001a > >> to persiste > >>> nt table because there is no free space available > >>> > >>> - The driver is not endian safe. (It assumes a little endian > >> machine.) > >>> This is not new, the previous version of the driver had the > same > >> issue. > >>> The LSI folks know about these issues. The driver has passed their > >> testing > >>> process. > >>> > >>> Many thanks to LSI for going through the effort to support FreeBSD. > >>> > >>> Ken > >> Hello all. > >> > >> I am running FreeBSD 9.0 STABLE now, on a LSI 9211-8i controller and > a > >> 16 ports backplane identified as LSI CORP SAS2X28 0717 ses0 pass6 > >> On FreeBSD 9.0RELEASE i have the following order. > >> Seen from the front of the case. > >> da3 da7 da11 da15 > >> da2 da6 da10 da14 > >> da1 da5 da9 da13 > >> da0 da4 da8 da12 > >> > >> But now it has shuffled the order. > >> da8 da 14 da12 da10 > >> da9 da15 da13 da11 > >> da1 da6 da2 da5 > >> da0 da7 da3 da4 > >> > >> There is no logic at all, and it is very hard to figure out when a > disk > >> dies which one it is. > > Can you attach dmesg logs ? > > Basically now Drive will not ask CAM layer to add device using > XPT_ASYC call. > > It will ask CAM layer to rescan the bus. > > > > So how CAM layer detects Drives is beyond Low level driver and it is > obviously no guaranty of sequence of daX. > > If you have some X Drives attached to enclosure, target IDs of those > Drive will be generated by Driver based on > > which mode mapping table is. > > 1. Enclosure slot mapping > > 2. Device mapping. > > > > For your case best choice will be Enclosure slot mapping. Assume you > have Enclosure slop mapping. > > > > Target ID assignment is part of Driver which will consistence across > all reboot. > > _but_ when Driver call rescan bus (as part of device add), it will > scan bus in sequence and later peripher layer will assing device naming. > > So it is completely unsure which device will get what device name. > > > > e.a I have four Drive in "Enclosure slot mapping" Drive-A, Drive-B, > Drive-C and Drive-D. (Consider alphabetical order is mapped to slot > number ) > > So Driver will assign below target id. (target id 0-7 is reserved for > local port of HBA) > > > > Drive- A Target ID -8 > > Drive- B Target ID -9 > > Drive- C Target ID -10 > > Drive- D Target ID -11 > > > > You cannot expect Drive-A will be assigned to da0. (and similar Drive- > D will get da3). > > > > In summary, This behavior is visible just because of new change in > driver, but it is never *must* follow condition for any driver. > > Device naming is part of CAM layer. > > > > > >> > >> regards > >> Johan Hendriks > >> > >> > >> _______________________________________________ > >> 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" > > Ok so it is not the mps driver who does the naming but cam, and that > also has changed on 9.0 Stable. Nope... change is not in CAM, but Driver used rescan API instead of asynchr= onous reporting of device. At the end *YES* device naming is not guaranteed. > Well i use gpart labels for the pool, so i can use the gpart labels to > yank the right disk. > But it would be nicer if there was some kind of logic in the numbering > of the devices. > > > Here is the dmesg > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-STABLE #0: Mon Feb 13 10:22:44 CET 2012 > root@filer01.testdomain.local:/usr/obj/usr/src/sys/KRNL amd64 > CPU: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (3093.04-MHz K8-class CPU) > Origin =3D "GenuineIntel" Id =3D 0x206a7 Family =3D 6 Model =3D 2a > Stepping =3D 7 > > Features=3D0xbfebfbff ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=3D0x15bae3ff SE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,AVX> > AMD Features=3D0x28100800 > AMD Features2=3D0x1 > TSC: P-state invariant, performance statistics > real memory =3D 17179869184 (16384 MB) > avail memory =3D 16493441024 (15729 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 6 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 19 at device 6.0 on pci0 > pci1: on pcib1 > mps0: port 0xe000-0xe0ff mem 0xfb600000-0xfb603fff irq 19 > at device 0.0 on pci1 > mps0: Firmware: 11.00.00.00, Driver: 11.255.03.00-fbsd > mps0: IOCCapabilities: > 1285c c> > em0: port 0xf020-0xf03f mem > 0xfb800000-0xfb81ffff,0xfb824000-0xfb824fff irq 20 at device 25.0 on > pci0 > em0: Using an MSI interrupt > em0: Ethernet address: 00:25:90:57:20:bd > ehci0: mem 0xfb823000-0xfb8233ff irq > 16 at device 26.0 on pci0 > usbus0: EHCI version 1.0 > usbus0: on ehci0 > pcib2: irq 17 at device 28.0 on pci0 > pci2: on pcib2 > pcib3: irq 17 at device 28.4 on pci0 > pci3: on pcib3 > em1: port 0xd000-0xd01f mem > 0xfb700000-0xfb71ffff,0xfb720000-0xfb723fff irq 16 at device 0.0 on pci3 > em1: Using MSIX interrupts with 3 vectors > em1: Ethernet address: 00:25:90:57:20:bc > ehci1: mem 0xfb822000-0xfb8223ff irq > 23 at device 29.0 on pci0 > usbus1: EHCI version 1.0 > usbus1: on ehci1 > pcib4: at device 30.0 on pci0 > pci4: on pcib4 > vgapci0: mem > 0xf9000000-0xf9ffffff,0xfb000000-0xfb003fff,0xfa800000-0xfaffffff irq 23 > at device 3.0 on pci4 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port > 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf000-0xf01f > mem 0xfb821000-0xfb8217ff irq 19 at device 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > Event timer "HPET4" frequency 14318180 Hz quality 440 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart2: <16550 or compatible> port 0x3e8-0x3ef irq 10 on acpi0 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc87ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > ppc0: cannot reserve I/O port range > est0: on cpu0 > p4tcc0: on cpu0 > est1: on cpu1 > p4tcc1: on cpu1 > est2: on cpu2 > p4tcc2: on cpu2 > est3: on cpu3 > p4tcc3: on cpu3 > ZFS filesystem version 5 > ZFS storage pool version 28 > Timecounters tick every 1.000 msec > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > da0 at mps0 bus 0 scbus0 target 8 lun 0 > da0: Fixed Direct Access SCSI-6 device > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > da1 at mps0 bus 0 scbus0 target 9 lun 0 > da1: Fixed Direct Access SCSI-6 device > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > da2 at mps0 bus 0 scbus0 target 10 lun 0 > da2: Fixed Direct Access SCSI-6 device > da2: 300.000MB/s transfers > da2: Command Queueing enabled > da2: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da3 at mps0 bus 0 scbus0 target 11 lun 0 > da3: Fixed Direct Access SCSI-6 device > da3: 300.000MB/s transfers > da3: Command Queueing enabled > da3: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da4 at mps0 bus 0 scbus0 target 12 lun 0 > da4: Fixed Direct Access SCSI-6 device > da4: 300.000MB/s transfers > da4: Command Queueing enabled > da4: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da5 at mps0 bus 0 scbus0 target 13 lun 0 > da5: Fixed Direct Access SCSI-6 device > da5: 150.000MB/s transfers > da5: Command Queueing enabled > da5: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da8 at mps0 bus 0 scbus0 target 19 lun 0 > da8: Fixed Direct Access SCSI-6 device > da8: 300.000MB/s transfers > da8: Command Queueing enabled > da8: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > da9 at mps0 bus 0 scbus0 target 20 lun 0 > da9: Fixed Direct Access SCSI-6 device > da9: 300.000MB/s transfers > da9: Command Queueing enabled > da9: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > da11 at mps0 bus 0 scbus0 target 22 lun 0 > da11: Fixed Direct Access SCSI-6 device > da11: 150.000MB/s transfers > da11: Command Queueing enabled > da11: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da12 at mps0 bus 0 scbus0 target 23 lun 0 > da12: Fixed Direct Access SCSI-6 device > da12: 150.000MB/s transfers > da12: Command Queueing enabled > da12: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da13 at mps0 bus 0 scbus0 target 24 lun 0 > da13: Fixed Direct Access SCSI-6 device > da13: 150.000MB/s transfers > da13: Command Queueing enabled > da13: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da14 at mps0 bus 0 scbus0 target 27 lun 0 > da14: Fixed Direct Access SCSI-6 device > da14: 300.000MB/s transfers > da14: Command Queueing enabled > da14: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > da15 at mps0 bus 0 scbus0 target 28 lun 0 > da15: Fixed Direct Access SCSI-6 device > da15: 150.000MB/s transfers > da15: Command Queueing enabled > da15: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > ses0 at mps0 bus 0 scbus0 target 16 lun 0 > ses0: Fixed Enclosure Services SCSI-5 device > ses0: 600.000MB/s transfers > ses0: Command Queueing enabled > ses0: SCSI-3 SES Device > da6 at mps0 bus 0 scbus0 target 17 lun 0 > da6: Fixed Direct Access SCSI-6 device > da6: 150.000MB/s transfers > da6: Command Queueing enabled > da6: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > cd0 at ahcich2 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO > 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > - tray closed > ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 > ada0: ATA-7 SATA 1.x device > ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) > ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > da7 at mps0 bus 0 scbus0 target 18 lun 0 > da7: Fixed Direct Access SCSI-6 device > da7: 150.000MB/s transfers > da7: Command Queueing enabled > da7: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > Timecounter "TSC-low" frequency 12082198 Hz quality 1000 > ugen0.2: at usbus0 > uhub2: > on usbus0 > ugen1.2: at usbus1 > uhub3: > on usbus1 > da10 at mps0 bus 0 scbus0 target 21 lun 0 > da10: Fixed Direct Access SCSI-6 device > da10: 300.000MB/s transfers > da10: Command Queueing enabled > da10: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) > uhub3: 6 ports with 6 removable, self powered > uhub2: 6 ports with 6 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > ums0: rev 1.10/0.01, addr 3> on usbus0 > ums0: 3 buttons and [Z] coordinates ID=3D0 > ukbd0: rev 1.10/0.01, addr 3> on usbus0 > kbd2 at ukbd0 > Trying to mount root from ufs:/dev/ada0p2 [rw]... > em0: link state changed to UP > > > Camcontrol devlist > > filer01 ~ # camcontrol devlist > at scbus0 target 8 lun 0 (pass0,da0) > at scbus0 target 9 lun 0 (pass1,da1) > at scbus0 target 10 lun 0 (pass2,da2) > at scbus0 target 11 lun 0 (pass3,da3) > at scbus0 target 12 lun 0 (pass4,da4) > at scbus0 target 13 lun 0 (pass5,da5) > at scbus0 target 16 lun 0 > (ses0,pass6) > at scbus0 target 17 lun 0 (pass7,da6) > at scbus0 target 18 lun 0 (pass8,da7) > at scbus0 target 19 lun 0 (pass9,da8) > at scbus0 target 20 lun 0 > (pass10,da9) > at scbus0 target 21 lun 0 > (pass11,da10) > at scbus0 target 22 lun 0 > (pass12,da11) > at scbus0 target 23 lun 0 > (pass13,da12) > at scbus0 target 24 lun 0 > (pass14,da13) > at scbus0 target 27 lun 0 > (pass15,da14) > at scbus0 target 28 lun 0 > (pass16,da15) > at scbus1 target 0 lun 0 > (ada0,pass17) > at scbus3 target 0 lun 0 (pass18,cd0) If you observe your device naming is in sequence of target id. ( I mean tar= get 8 start with device da0 and target id 28 ends with da15 in between foll= owing sequential order) For my server below is sample output where CAM layer change the sequence. (= you can observe target 8 sequence does not match with device name) at scbus0 target 8 lun 0 (pass3,da3) at scbus0 target 9 lun 0 (pass0,da0) at scbus0 target 10 lun 0 (pass2,da2) at scbus0 target 11 lun 0 (pass1,da1) So looks like you are not running under "enclosure slot mapping". If you ru= n LSI controller under Enclosure slot mapping your problem of getting out o= f sequence target id will be at list resolved. (still no guarantee of devic= e naming and best is to use gpart lable. I am not familiar with it, but loo= ks like similar to udev rule of Linux.) You need to contact some of the LSI support team to know how to convert Car= d from device mapping to enclosure slot mapping. ~ Kashyap > > regards > johan From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 11:49:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E29D106566C for ; Mon, 13 Feb 2012 11:49:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 32C748FC14 for ; Mon, 13 Feb 2012 11:49:42 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta02.emeryville.ca.mail.comcast.net with comcast id ZPpe1i0010b6N64A2Ppi1D; Mon, 13 Feb 2012 11:49:42 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id ZPph1i00r1t3BNj8PPpisv; Mon, 13 Feb 2012 11:49:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7A7EF102C1E; Mon, 13 Feb 2012 03:49:41 -0800 (PST) Date: Mon, 13 Feb 2012 03:49:41 -0800 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20120213114941.GA71078@icarus.home.lan> References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> <4F38EFE2.7010905@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F38EFE2.7010905@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , "Desai, Kashyap" Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 11:49:43 -0000 On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: > Ok so it is not the mps driver who does the naming but cam, and that > also has changed on 9.0 Stable. > Well i use gpart labels for the pool, so i can use the gpart labels > to yank the right disk. > But it would be nicer if there was some kind of logic in the > numbering of the devices. "Wire them down" in FreeBSD using loader.conf variables and this issue will cease to be a problem. Example is below, despite being for SATA with AHCI -- really doesn't matter, just change the appropriate bits and it should be fine for you. # "Wire down" device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at="ahcich0" hint.scbus.1.at="ahcich1" hint.scbus.2.at="ahcich2" hint.scbus.3.at="ahcich3" hint.scbus.4.at="ahcich4" hint.scbus.5.at="ahcich5" hint.ada.0.at="scbus0" hint.ada.1.at="scbus1" hint.ada.2.at="scbus2" hint.ada.3.at="scbus3" hint.ada.4.at="scbus4" hint.ada.5.at="scbus5" -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 12:19:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31472106566B for ; Mon, 13 Feb 2012 12:19:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id D02E88FC0C for ; Mon, 13 Feb 2012 12:19:19 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZQHd1i00327AodY51QKKfW; Mon, 13 Feb 2012 12:19:19 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.westchester.pa.mail.comcast.net with comcast id ZQKJ1i0091t3BNj3fQKKKC; Mon, 13 Feb 2012 12:19:19 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7A504102C1E; Mon, 13 Feb 2012 04:19:17 -0800 (PST) Date: Mon, 13 Feb 2012 04:19:17 -0800 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20120213121917.GA71490@icarus.home.lan> References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> <4F38EFE2.7010905@gmail.com> <20120213114941.GA71078@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213114941.GA71078@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable , "Desai, Kashyap" Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 12:19:20 -0000 On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: > > Ok so it is not the mps driver who does the naming but cam, and that > > also has changed on 9.0 Stable. > > Well i use gpart labels for the pool, so i can use the gpart labels > > to yank the right disk. > > But it would be nicer if there was some kind of logic in the > > numbering of the devices. > > "Wire them down" in FreeBSD using loader.conf variables and this issue > will cease to be a problem. Example is below, despite being for SATA > with AHCI -- really doesn't matter, just change the appropriate bits and > it should be fine for you. > > > # "Wire down" device names (ada[0-5]) to each individual port > # on the SATA/AHCI controller. This ensures that if we reboot > # with a disk missing, the device names stay the same, and stay > # attached to the same SATA/AHCI controller. > # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html > # > hint.scbus.0.at="ahcich0" > hint.scbus.1.at="ahcich1" > hint.scbus.2.at="ahcich2" > hint.scbus.3.at="ahcich3" > hint.scbus.4.at="ahcich4" > hint.scbus.5.at="ahcich5" > hint.ada.0.at="scbus0" > hint.ada.1.at="scbus1" > hint.ada.2.at="scbus2" > hint.ada.3.at="scbus3" > hint.ada.4.at="scbus4" > hint.ada.5.at="scbus5" To be more specific: please see the CAM(4) man page and look at some of the example hint settings shown there. In your case I believe you'd want the below (which is a static map that matches your provided dmesg in the previous mail). If you want different device names tied to the different targets, it should be pretty obvious what to change. hint.scbus.0.at="mps0" hint.da.0.at="scbus0" hint.da.0.target="8" hint.da.0.unit="0" hint.da.1.at="scbus0" hint.da.1.target="9" hint.da.1.unit="0" hint.da.2.at="scbus0" hint.da.2.target="10" hint.da.2.unit="0" hint.da.3.at="scbus0" hint.da.3.target="11" hint.da.3.unit="0" hint.da.4.at="scbus0" hint.da.4.target="12" hint.da.4.unit="0" hint.da.5.at="scbus0" hint.da.5.target="13" hint.da.5.unit="0" hint.da.8.at="scbus0" hint.da.8.target="19" hint.da.8.unit="0" hint.da.9.at="scbus0" hint.da.9.target="20" hint.da.9.unit="0" hint.da.11.at="scbus0" hint.da.11.target="22" hint.da.11.unit="0" hint.da.12.at="scbus0" hint.da.12.target="23" hint.da.12.unit="0" hint.da.13.at="scbus0" hint.da.13.target="24" hint.da.13.unit="0" hint.da.14.at="scbus0" hint.da.14.target="27" hint.da.14.unit="0" hint.da.15.at="scbus0" hint.da.15.target="28" hint.da.15.unit="0" Naturally you can do the same for your AHCI controller bits too, though understand that each channel/port on the controller there matches to a separate scbusX unit, so you may want to start the numbering higher (in the case the LSI controller could ever have more scbusX entries added; e.g. LVMs or similar -- not sure how those are implemented there, but it doesn't matter, you get my drift I hope). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 12:52:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 718261065670 for ; Mon, 13 Feb 2012 12:52:37 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EEBB48FC15 for ; Mon, 13 Feb 2012 12:52:36 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4413979bkc.13 for ; Mon, 13 Feb 2012 04:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0USaEA9WmfbCEmZMEyljTU1vjaXI0Py6rH/ecE3IvKU=; b=Qk/CcxAXnKVS7PM+tNxItw8qgmQHCy9yS7dqtKvdxJ1+vucM1E+JfJtO0qieczB4J+ GBlJh5MqgUzoZHr1H8XRIZu5Cvo+vXaCt8mV3qbJEAi//Av8x4K5dhqv7W7uVIh1+0OR twjvQb0if5siaIFzjSDo61ua3T8kAkhNu3Zyo= Received: by 10.204.156.207 with SMTP id y15mr7190192bkw.83.1329137530873; Mon, 13 Feb 2012 04:52:10 -0800 (PST) Received: from [192.168.50.103] (double-l.xs4all.nl. [80.126.205.144]) by mx.google.com with ESMTPS id jd17sm46009028bkb.4.2012.02.13.04.52.09 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 04:52:10 -0800 (PST) Message-ID: <4F390777.9010902@gmail.com> Date: Mon, 13 Feb 2012 13:52:07 +0100 From: Johan Hendriks User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable References: <20120202191105.GA55719@nargothrond.kdm.org> <4F38E00B.2020408@gmail.com> <4F38EFE2.7010905@gmail.com> <20120213114941.GA71078@icarus.home.lan> <20120213121917.GA71490@icarus.home.lan> In-Reply-To: <20120213121917.GA71490@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 12:52:37 -0000 Jeremy Chadwick schreef: > On Mon, Feb 13, 2012 at 03:49:41AM -0800, Jeremy Chadwick wrote: >> On Mon, Feb 13, 2012 at 12:11:30PM +0100, Johan Hendriks wrote: >>> Ok so it is not the mps driver who does the naming but cam, and that >>> also has changed on 9.0 Stable. >>> Well i use gpart labels for the pool, so i can use the gpart labels >>> to yank the right disk. >>> But it would be nicer if there was some kind of logic in the >>> numbering of the devices. >> "Wire them down" in FreeBSD using loader.conf variables and this issue >> will cease to be a problem. Example is below, despite being for SATA >> with AHCI -- really doesn't matter, just change the appropriate bits and >> it should be fine for you. >> >> >> # "Wire down" device names (ada[0-5]) to each individual port >> # on the SATA/AHCI controller. This ensures that if we reboot >> # with a disk missing, the device names stay the same, and stay >> # attached to the same SATA/AHCI controller. >> # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html >> # >> hint.scbus.0.at="ahcich0" >> hint.scbus.1.at="ahcich1" >> hint.scbus.2.at="ahcich2" >> hint.scbus.3.at="ahcich3" >> hint.scbus.4.at="ahcich4" >> hint.scbus.5.at="ahcich5" >> hint.ada.0.at="scbus0" >> hint.ada.1.at="scbus1" >> hint.ada.2.at="scbus2" >> hint.ada.3.at="scbus3" >> hint.ada.4.at="scbus4" >> hint.ada.5.at="scbus5" > To be more specific: please see the CAM(4) man page and look at some of > the example hint settings shown there. In your case I believe you'd > want the below (which is a static map that matches your provided dmesg > in the previous mail). If you want different device names tied to the > different targets, it should be pretty obvious what to change. > > hint.scbus.0.at="mps0" > hint.da.0.at="scbus0" > hint.da.0.target="8" > hint.da.0.unit="0" > hint.da.1.at="scbus0" > hint.da.1.target="9" > hint.da.1.unit="0" > hint.da.2.at="scbus0" > hint.da.2.target="10" > hint.da.2.unit="0" > hint.da.3.at="scbus0" > hint.da.3.target="11" > hint.da.3.unit="0" > hint.da.4.at="scbus0" > hint.da.4.target="12" > hint.da.4.unit="0" > hint.da.5.at="scbus0" > hint.da.5.target="13" > hint.da.5.unit="0" > hint.da.8.at="scbus0" > hint.da.8.target="19" > hint.da.8.unit="0" > hint.da.9.at="scbus0" > hint.da.9.target="20" > hint.da.9.unit="0" > hint.da.11.at="scbus0" > hint.da.11.target="22" > hint.da.11.unit="0" > hint.da.12.at="scbus0" > hint.da.12.target="23" > hint.da.12.unit="0" > hint.da.13.at="scbus0" > hint.da.13.target="24" > hint.da.13.unit="0" > hint.da.14.at="scbus0" > hint.da.14.target="27" > hint.da.14.unit="0" > hint.da.15.at="scbus0" > hint.da.15.target="28" > hint.da.15.unit="0" > > Naturally you can do the same for your AHCI controller bits too, though > understand that each channel/port on the controller there matches to a > separate scbusX unit, so you may want to start the numbering higher (in > the case the LSI controller could ever have more scbusX entries added; > e.g. LVMs or similar -- not sure how those are implemented there, but > it doesn't matter, you get my drift I hope). > Thanks i will look into this, and the enclosure slot mapping. Thank you all for your time. And sorry for using this topic as it was not related. regards Johan From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 13:28:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E1C1065673; Mon, 13 Feb 2012 13:28:41 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id D60118FC1A; Mon, 13 Feb 2012 13:28:40 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rwvx7-0005F8-Uw; Mon, 13 Feb 2012 08:28:21 -0500 Date: Mon, 13 Feb 2012 08:28:21 -0500 From: Gary Palmer To: Alex Samorukov Message-ID: <20120213132821.GA78733@in-addr.com> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F38AF69.6010506@os2.kiev.ua> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Harald Schmalzbauer , Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 13:28:41 -0000 On Mon, Feb 13, 2012 at 07:36:25AM +0100, Alex Samorukov wrote: > On 02/13/2012 06:27 AM, Adrian Chadd wrote: > >On 12 February 2012 09:34, Alex Samorukov wrote: > > > >>Yes. But it will nit fix non-cached access to the disk (raw) devices. And > >>this is the main reason why ntfs-3g and exfat are much slower then working > >>on Linux. > >But _that_ can be fixed with the appropriate application of a sensible > >caching layer. > With every application? :) Are you know anyone who wants to do this? At > least for 3 fuse filesystems. The filesystem is the *BEST* place to do caching. It knows what metadata is most effective to cache and what other data (e.g. file contents) doesn't need to be cached. Any attempt to do this in layers between the FS and the disk won't achieve the same gains as a properly written filesystem. e.g. in a UFS implementation the disk layer may see a lot of I/Os for blocks, not necessarily sequential, as a program lists a directory and stats all the files which pulls in the inode tables. The filesystem knows that it needs the inode tables and is likely to need not only the current inode table disk block but subsequent ones also, and instead of requesting the disk sector that it needs to service the immediate stat(2) request but maybe the next few also. Without that insight into whats going on it is difficult to see how a highly effective cache could be done at the geom layer. Gary From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 14:08:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB5A106566B for ; Mon, 13 Feb 2012 14:08:56 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 824048FC18 for ; Mon, 13 Feb 2012 14:08:56 +0000 (UTC) Received: from roberto-aw.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 6804D1380E for ; Mon, 13 Feb 2012 15:08:53 +0100 (CET) Date: Mon, 13 Feb 2012 15:08:45 +0100 From: Ollivier Robert To: freebsd-stable@freebsd.org Message-ID: <20120213140844.GA61050@roberto-aw.eurocontrol.fr> References: <20120202191105.GA55719@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120202191105.GA55719@nargothrond.kdm.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 13 Feb 2012 14:08:56 -0000 According to Kenneth D. Merry: > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. Thanks. > Note that the CAM infrastructure changes that went into FreeBSD/head along > with this driver have not gone into either stable/9 or stable/8. Only the > driver itself has been merged. > > The CAM infrastructure changes depend on some other da(4) driver changes > that will need to get merged before they can go back. If that merge > happens, it will probably only be into stable/9. Got an ETA for this? Saying differently, is it reasonable to run stable/9 with the new driver but w/o the CAM changes? What do these changes bring BTW? Sorry, been out-of-touch these days :( Thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 14:52:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 418A0106564A for ; Mon, 13 Feb 2012 14:52:00 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [77.120.97.61]) by mx1.freebsd.org (Postfix) with ESMTP id EE53D8FC16 for ; Mon, 13 Feb 2012 14:51:59 +0000 (UTC) Received: from 94-105-243-80.cust.centrio.cz ([80.243.105.94] helo=[192.168.101.203]) by s1.sdv.com.ua with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RwxEk-000G2j-2O; Mon, 13 Feb 2012 16:50:43 +0200 Message-ID: <4F39233C.9090600@os2.kiev.ua> Date: Mon, 13 Feb 2012 15:50:36 +0100 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Gary Palmer References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> In-Reply-To: <20120213132821.GA78733@in-addr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 Cc: Harald Schmalzbauer , Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 14:52:00 -0000 On 02/13/2012 02:28 PM, Gary Palmer wrote: >>> >>>> Yes. But it will nit fix non-cached access to the disk (raw) devices. And >>>> this is the main reason why ntfs-3g and exfat are much slower then working >>>> on Linux. >>> But _that_ can be fixed with the appropriate application of a sensible >>> caching layer. >> With every application? :) Are you know anyone who wants to do this? At >> least for 3 fuse filesystems. > The filesystem is the *BEST* place to do caching. It knows what metadata > is most effective to cache and what other data (e.g. file contents) doesn't > need to be cached. Any attempt to do this in layers between the FS and > the disk won't achieve the same gains as a properly written filesystem. > e.g. in a UFS implementation the disk layer may see a lot of I/Os for > blocks, not necessarily sequential, as a program lists a directory and stats > all the files which pulls in the inode tables. The filesystem knows that it > needs the inode tables and is likely to need not only the current inode table > disk block but subsequent ones also, and instead of requesting the disk sector > that it needs to service the immediate stat(2) request but maybe the next few > also. Without that insight into whats going on it is difficult to see how a > highly effective cache could be done at the geom layer. I think we are playing in a "captain obvious". I have nothing against statement that FS is a "best place for caching". Also - i am absolutely sure that its better to have kernel space fs driver then FUSE one. But unfortunately there is no kernel space driver for the exfat, kernel driver for ntfs is ugly and buggy (and r/o) and i don`t think that anyone is going to change this. And i really don`t understand why are you trying to tell that it cannot be effective when its so easy to proof that it can. Just try this with fuse based filesystems in Linux, and you will get speed compared to underlying device (especially on relatively slow USB devices). Then try the same code on FreeBSD to see how ugly things are. And yes, in ideal world ever fs needs to have good written cache implementation and kernel should not care about caching raw devices at all. But as i mentioned before - there is no kernel-space drivers with a good cache implementation for this 2 widely used systems (and probably not only). Linux is a good example that device-level caching works, and works fine. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 14:58:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C14C106566B for ; Mon, 13 Feb 2012 14:58:49 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C918E8FC0C for ; Mon, 13 Feb 2012 14:58:48 +0000 (UTC) Received: by iaeo4 with SMTP id o4so5471413iae.13 for ; Mon, 13 Feb 2012 06:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ISCOG+B24xGJZLQcCH3POb5HpPGSGXcGh2+SuSenzpY=; b=rTz1vkViB3vHo8AXcAn6v/1OCSoO0ja1VuiDAaZ/Eot5p1A78V4vhChJKrEHEftubE 4fTuprypXftIBcNFl4Lvk1KEot7SP1eXkQXRWJRcdvJkJhpbN0tFRRIYr5XGTEcuYWGf kI5LmOdOFZ6Xe+8bXLZstOT3F7KvGRrPKVLSo= MIME-Version: 1.0 Received: by 10.50.153.133 with SMTP id vg5mr20024542igb.8.1329145128207; Mon, 13 Feb 2012 06:58:48 -0800 (PST) Received: by 10.231.231.17 with HTTP; Mon, 13 Feb 2012 06:58:48 -0800 (PST) In-Reply-To: <4F37DBA3.7030304@cran.org.uk> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> Date: Mon, 13 Feb 2012 16:58:48 +0200 Message-ID: From: George Kontostanos To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: New BSD Installer 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, 13 Feb 2012 14:58:49 -0000 I don't think that reverting is either an option or a solution at this point. You can consider filing PRs. -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:05:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D21B106566C for ; Mon, 13 Feb 2012 15:05:47 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A34568FC22 for ; Mon, 13 Feb 2012 15:05:46 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4561142bkc.13 for ; Mon, 13 Feb 2012 07:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qehbF/LrNFUwpVO36tYdzvdi4+wa6dHZpzlueZOiAGY=; b=EpnljPJIb/XInJmgEGnceSZAulCD+M735QoDS2pXi9D5JSsDLHAWEZcR2lgPvbOtFl RseEPvucKT6ll8Xwf6JtG2FZtoxQn7ugGBPBiq933k0JTAYGua8h/Y4F1qVA7OeJJG4U xOJuEPO0UFESYA7ab3l0jS0doZKPBo84MbAos= Received: by 10.204.157.148 with SMTP id b20mr7357479bkx.89.1329145545450; Mon, 13 Feb 2012 07:05:45 -0800 (PST) Received: from green.tandem.local (43-24-132-95.pool.ukrtel.net. [95.132.24.43]) by mx.google.com with ESMTPS id i2sm47049037bkd.10.2012.02.13.07.05.43 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 07:05:44 -0800 (PST) Message-ID: <4F3926C5.3010403@gmail.com> Date: Mon, 13 Feb 2012 17:05:41 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120213 Firefox/10.0.1 SeaMonkey/2.7.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> In-Reply-To: <20120210231059.GA25777@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 15:05:47 -0000 Jeremy Chadwick wrote: > I want to note here: the pf ALTQ options are a pain in the butt, quite > honestly. I've found in the past that removing the ones you don't use > won't result in a successful build, thus one must include them all. We > do need ALTQ support though, for rate-limiting capability. The NOPCC > option is needed for SMP builds, which makes me wonder what the state of > SMP is in this regard -- meaning, on non-SMP builds, is it still safe > to include ALTQ_NOPCC? It seems like I'm missing something. What is good about using non-SMP kernel? -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:11:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73C0F1065675 for ; Mon, 13 Feb 2012 15:11:12 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2BEC48FC08 for ; Mon, 13 Feb 2012 15:11:11 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1RwxXB-0007jN-Mn for freebsd-stable@freebsd.org; Mon, 13 Feb 2012 16:09:41 +0100 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 ; Mon, 13 Feb 2012 16:09:41 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Feb 2012 16:09:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 13 Feb 2012 16:09:05 +0100 Lines: 43 Message-ID: References: <20120213015013.GA71062@pol-server.leissner.se> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE64DB5DF89C76D8488EB4860" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <20120213015013.GA71062@pol-server.leissner.se> X-Enigmail-Version: 1.3.5 Subject: Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2 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, 13 Feb 2012 15:11:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE64DB5DF89C76D8488EB4860 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13/02/2012 02:50, Peter Olsson wrote: > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > running Openbox. My WAN is about 1.2 Mbps, and I try > to run RDP to windows servers beyond my WAN. >=20 > RDP to a Windows Server 2003 SP2 is fast and works > without problems. >=20 > RDP to a Windows Server 2008 R2 is very slow, > and sometimes just disconnects. >=20 > I tried changing a couple of net.inet.tcp sysctl: > Nothing has helped, do you have any ideas what I > should tune? It is highly unlikely that any network tuning will help here - this is almost certainly an application-level problem. For what it's worth, I'm using rdesktop to a Win2k8 R2 server without any lag other problems. --------------enigE64DB5DF89C76D8488EB4860 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85J5EACgkQldnAQVacBcgFbgCeNIn4PP5tmx/wvA2BfpIqer3z VzQAnRjpJhoUvl7EIqPzfAbHO5dm01fO =QKuM -----END PGP SIGNATURE----- --------------enigE64DB5DF89C76D8488EB4860-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:30:30 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B6D01065678 for ; Mon, 13 Feb 2012 15:30:30 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC978FC19 for ; Mon, 13 Feb 2012 15:30:29 +0000 (UTC) Received: by ghbg15 with SMTP id g15so3081391ghb.13 for ; Mon, 13 Feb 2012 07:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Iu8mYvRNrajgY35iO4BPmb+thBHCCMAaOiqzFvtHfM0=; b=BvMxBcnyEGS9d7op+f5icq5tFrwOXsLEoaidhrCXpxIDT5TVJI+F0FVb8TPvAG6v6D 5X/OioaCYmw43p9wMpyNebUH0GXldVM+OI/qfob9sMULXM3RL17XxIHIbeLAIBTjir1S hQoworuSltDExu774G5k2Iv7Pe2E1B8MjXLgk= MIME-Version: 1.0 Received: by 10.50.216.231 with SMTP id ot7mr27490078igc.8.1329145320882; Mon, 13 Feb 2012 07:02:00 -0800 (PST) Received: by 10.231.231.17 with HTTP; Mon, 13 Feb 2012 07:02:00 -0800 (PST) In-Reply-To: <1329058091.2541.104.camel@pow> References: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> <1329058091.2541.104.camel@pow> Date: Mon, 13 Feb 2012 17:02:00 +0200 Message-ID: From: George Kontostanos To: Luke Marsden Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Subject: Re: Swap on zvol - recommendable? 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, 13 Feb 2012 15:30:30 -0000 > > I can confirm that this is still a problem on 8.2 and 9.0. > > -- > CTO, Hybrid Logic > +447791750420 =A0| =A0+1-415-449-1165 =A0| www.hybrid-cluster.com > > > _______________________________________________ > 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 can not compare 8.2 with 9.0 per ZFS. What problems are you facing with your swap in 9.0 ? --=20 George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:32:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A421065680 for ; Mon, 13 Feb 2012 15:32:40 +0000 (UTC) (envelope-from pol@leissner.se) Received: from mailgate.leissner.se (mailgate.leissner.se [212.3.1.210]) by mx1.freebsd.org (Postfix) with ESMTP id 24BA28FC0C for ; Mon, 13 Feb 2012 15:32:39 +0000 (UTC) Received: from mailgate.leissner.se (localhost [127.0.0.1]) by mailgate.leissner.se (8.14.5/8.14.5) with ESMTP id q1DFWcXS086251; Mon, 13 Feb 2012 16:32:38 +0100 (CET) (envelope-from pol@leissner.se) Received: (from uucp@localhost) by mailgate.leissner.se (8.14.5/8.14.5/Submit) id q1DFWcN2086250; Mon, 13 Feb 2012 16:32:38 +0100 (CET) (envelope-from pol@leissner.se) Received: from pol.leissner.se(192.71.29.17), claiming to be "pol-server.leissner.se" via SMTP by mailgate.leissner.se, id smtpdygt0J5; Mon Feb 13 16:32:32 2012 Received: from pol-server.leissner.se (localhost [127.0.0.1]) by pol-server.leissner.se (8.14.5/8.14.5) with ESMTP id q1DFWVH2092733; Mon, 13 Feb 2012 16:32:31 +0100 (CET) (envelope-from pol@leissner.se) Received: (from pol@localhost) by pol-server.leissner.se (8.14.5/8.14.5/Submit) id q1DFWVGq092732; Mon, 13 Feb 2012 16:32:31 +0100 (CET) (envelope-from pol@leissner.se) X-Authentication-Warning: pol-server.leissner.se: pol set sender to pol@leissner.se using -f Date: Mon, 13 Feb 2012 16:32:31 +0100 From: Peter Olsson To: Ivan Voras Message-ID: <20120213153231.GW53927@pol-server.leissner.se> References: <20120213015013.GA71062@pol-server.leissner.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2 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, 13 Feb 2012 15:32:40 -0000 On Mon, Feb 13, 2012 at 04:09:05PM +0100, Ivan Voras wrote: > On 13/02/2012 02:50, Peter Olsson wrote: > > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > > running Openbox. My WAN is about 1.2 Mbps, and I try > > to run RDP to windows servers beyond my WAN. > > > > RDP to a Windows Server 2003 SP2 is fast and works > > without problems. > > > > RDP to a Windows Server 2008 R2 is very slow, > > and sometimes just disconnects. > > > > I tried changing a couple of net.inet.tcp sysctl: > > > Nothing has helped, do you have any ideas what I > > should tune? > > It is highly unlikely that any network tuning will help here - this is > almost certainly an application-level problem. > > For what it's worth, I'm using rdesktop to a Win2k8 R2 server without > any lag other problems. I have a colleague who runs Crunchbang (ie Debian) desktop. He had exactly the same performance problem until he used these sysctl: net.core.rmem_max=1048576 net.core.rmem_default=1048576 net.core.wmem_max=1048576 net.core.wmem_default=1048576 net.ipv4.tcp_rmem=1048576 1048576 3444736 net.ipv4.tcp_wmem=1048576 1048576 3444736 I don't know where he got those values, or what they could be translated to in FreeBSD, but they did solve the problem for him. That's why I'm hoping to find a similar sysctl solution for FreeBSD. I did sysctl -a | grep mem and grep buf, but find nothing obvious, except the net.inet.tcp.recvbuf and sendbuf values I have already tried changing. Also, I run Win7 in Virtualbox in my desktop, and from that Win7 I don't have the performance problem towards that RDP server. -- Peter Olsson pol@leissner.se From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:34:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4621106566B for ; Mon, 13 Feb 2012 15:34:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8B9208FC16 for ; Mon, 13 Feb 2012 15:34:47 +0000 (UTC) Received: from omta02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by qmta04.emeryville.ca.mail.comcast.net with comcast id ZTYd1i0020QkzPwA4TanKr; Mon, 13 Feb 2012 15:34:47 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta02.emeryville.ca.mail.comcast.net with comcast id ZTam1i00L1t3BNj8NTamcS; Mon, 13 Feb 2012 15:34:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 02916102C1E; Mon, 13 Feb 2012 07:34:46 -0800 (PST) Date: Mon, 13 Feb 2012 07:34:45 -0800 From: Jeremy Chadwick To: Peter Olsson Message-ID: <20120213153445.GA74834@icarus.home.lan> References: <20120213015013.GA71062@pol-server.leissner.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213015013.GA71062@pol-server.leissner.se> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Tuning needed for slow RDP FreeBSD 9 -> Win 2008 R2 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, 13 Feb 2012 15:34:47 -0000 On Mon, Feb 13, 2012 at 02:50:13AM +0100, Peter Olsson wrote: > Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel, > running Openbox. My WAN is about 1.2 Mbps, and I try > to run RDP to windows servers beyond my WAN. > > RDP to a Windows Server 2003 SP2 is fast and works > without problems. > > RDP to a Windows Server 2008 R2 is very slow, > and sometimes just disconnects. > > I tried changing a couple of net.inet.tcp sysctl: > net.inet.tcp.recvbuf_max=10485760 > net.inet.tcp.recvbuf_inc=65535 > net.inet.tcp.sendbuf_max=10485760 > net.inet.tcp.sendbuf_inc=65535 > net.inet.tcp.recvbuf_auto=0 > net.inet.tcp.sendbuf_auto=0 > net.inet.tcp.sendspace=65536 > net.inet.tcp.ecn.enable=1 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.tso=0 > net.inet.tcp.sack.enable=0 > net.inet.tcp.path_mtu_discovery=0 > > Some in combination with others, and some by themselves. > > I also tried net.link.ifqmaxlen=1024 in /boot/loader.conf. > > Nothing has helped, do you have any ideas what I > should tune? The above things you've tinkered with have probably done more damage than good. I strongly recommend you not "flail around" when it comes to adjustments like this; just guessing at seemingly random sysctls is a really bad idea. Please don't do this, for your own sake. You should probably engage a networking resource within your company or upstream from you, and provide them packet captures taken from both the FreeBSD machine as well as the Windows machine. Also, you specify 9.0 -- does using 8.2 to RDP to the same W2K8 R2 server work/behave fine, and thus the problem started with 9.0? The only thing I can think of is possibly RFC1323 "quirks" causing some kind of problem across a WAN link, or some very bizarre behaviour in the Ethernet/NIC driver on FreeBSD. You should probably try to reproduce this problem on a LAN, because I can assure you if you're using RDP across the Internet, you will have zero (I repeat: ZERO) chance of figuring this one out without every peering provider getting involved (both forward path and return path). Remember: the Internet is broken 24x7x365, and dedicated links/circuits are often neglected by providers regardless of who they are or where they are. You really didn't give any hard evidence or technical information besides "I see this problem, what is the cause?" Engaging network engineers on your side would probably be a good first step. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:37:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8833106566B; Mon, 13 Feb 2012 15:37:04 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 966438FC18; Mon, 13 Feb 2012 15:37:04 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RwxxQ-0005Qx-TB; Mon, 13 Feb 2012 10:36:48 -0500 Date: Mon, 13 Feb 2012 10:36:48 -0500 From: Gary Palmer To: Alex Samorukov Message-ID: <20120213153648.GB78733@in-addr.com> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <4F39233C.9090600@os2.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F39233C.9090600@os2.kiev.ua> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Harald Schmalzbauer , Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 15:37:05 -0000 On Mon, Feb 13, 2012 at 03:50:36PM +0100, Alex Samorukov wrote: > On 02/13/2012 02:28 PM, Gary Palmer wrote: > >>> > >>>>Yes. But it will nit fix non-cached access to the disk (raw) devices. > >>>>And > >>>>this is the main reason why ntfs-3g and exfat are much slower then > >>>>working > >>>>on Linux. > >>>But _that_ can be fixed with the appropriate application of a sensible > >>>caching layer. > >>With every application? :) Are you know anyone who wants to do this? At > >>least for 3 fuse filesystems. > >The filesystem is the *BEST* place to do caching. It knows what metadata > >is most effective to cache and what other data (e.g. file contents) doesn't > >need to be cached. Any attempt to do this in layers between the FS and > >the disk won't achieve the same gains as a properly written filesystem. > >e.g. in a UFS implementation the disk layer may see a lot of I/Os for > >blocks, not necessarily sequential, as a program lists a directory and > >stats > >all the files which pulls in the inode tables. The filesystem knows that > >it > >needs the inode tables and is likely to need not only the current inode > >table > >disk block but subsequent ones also, and instead of requesting the disk > >sector > >that it needs to service the immediate stat(2) request but maybe the next > >few > >also. Without that insight into whats going on it is difficult to see how > >a > >highly effective cache could be done at the geom layer. > I think we are playing in a "captain obvious". > > I have nothing against statement that FS is a "best place for caching". > Also - i am absolutely sure that its better to have kernel space fs > driver then FUSE one. > > But unfortunately there is no kernel space driver for the exfat, kernel > driver for ntfs is ugly and buggy (and r/o) and i don`t think that > anyone is going to change this. > > And i really don`t understand why are you trying to tell that it cannot > be effective when its so easy to proof that it can. Just try this with > fuse based filesystems in Linux, and you will get speed compared to > underlying device (especially on relatively slow USB devices). Then try > the same code on FreeBSD to see how ugly things are. > > And yes, in ideal world ever fs needs to have good written cache > implementation and kernel should not care about caching raw devices at > all. But as i mentioned before - there is no kernel-space drivers with a > good cache implementation for this 2 widely used systems (and probably > not only). Linux is a good example that device-level caching works, and > works fine. Please re-read my message. At no time did I say that caching below the FS could not provide speed improvements. I said it could not be as effective as a properly implemented filesystem. I'm sure if you throw memory at it, a geom layer cache can provide substantial speed ups. However I strongly suspect that a proper FS cache would provide a better memory/hit ratio than a geom layer cache. Gary From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:38:18 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4B641065670 for ; Mon, 13 Feb 2012 15:38:18 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 698AC8FC24 for ; Mon, 13 Feb 2012 15:38:18 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4599151bkc.13 for ; Mon, 13 Feb 2012 07:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ghv1n34ESHjcuY81/rVtsNRQDUBwgCeqDWMqJBQZqPo=; b=TwDJ6uUtceKgX4OrURRmcACixF3Y/B41tyVx/mAyi6hb61QFRpwcyB6klA7fpUNX01 CGlnHHpB2JHi/VCVS8zB2WYgCjOCjHV2slwokjjR9/fGHksJe8bcPnLMo9pDpC6RekJO tiAF+bBzSEjDAA5lMJikjQd+f+EOo7/A01W/I= Received: by 10.204.136.197 with SMTP id s5mr7495254bkt.9.1329147497341; Mon, 13 Feb 2012 07:38:17 -0800 (PST) Received: from green.tandem.local (43-24-132-95.pool.ukrtel.net. [95.132.24.43]) by mx.google.com with ESMTPS id cz3sm47375854bkb.3.2012.02.13.07.38.15 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 07:38:16 -0800 (PST) Message-ID: <4F392E66.5070403@gmail.com> Date: Mon, 13 Feb 2012 17:38:14 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120213 Firefox/10.0.1 SeaMonkey/2.7.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> <4F3926C5.3010403@gmail.com> <20120213152928.GA74772@icarus.home.lan> In-Reply-To: <20120213152928.GA74772@icarus.home.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 15:38:19 -0000 Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote: >> Jeremy Chadwick wrote: >>> I want to note here: the pf ALTQ options are a pain in the butt, quite >>> honestly. I've found in the past that removing the ones you don't use >>> won't result in a successful build, thus one must include them all. We >>> do need ALTQ support though, for rate-limiting capability. The NOPCC >>> option is needed for SMP builds, which makes me wonder what the state of >>> SMP is in this regard -- meaning, on non-SMP builds, is it still safe >>> to include ALTQ_NOPCC? >> >> It seems like I'm missing something. What is good about using >> non-SMP kernel? > > Nothing. It's a question of whether or not use of ALTQ_NOPCC causes > breakage on non-SMP kernels, or if FreeBSD even bothers to support > non-SMP at this point. "Non-SMP" means "without options SMP". You got my point. I'm a single core user today but I run SMP-enabled kernel. > Rephrased: if SMP is the default, and "options SMP" works just fine on > systems without multiple processors/cores, then the ALTQ_NOPCC option > should probably be removed. Yep, works for me. However I had found some cruft about extra processing power which would be used in expense of correct work. Can this be something like IPFIREWALL_FORWARD that adds some latency to most cases providing some use only for chosen ones? -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:42:46 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F19C21065674 for ; Mon, 13 Feb 2012 15:42:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8228FC08 for ; Mon, 13 Feb 2012 15:42:46 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id ZTA71i0060vyq2s51TVXuh; Mon, 13 Feb 2012 15:29:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta05.westchester.pa.mail.comcast.net with comcast id ZTVV1i00K1t3BNj3RTVWvb; Mon, 13 Feb 2012 15:29:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 95F66102C1E; Mon, 13 Feb 2012 07:29:28 -0800 (PST) Date: Mon, 13 Feb 2012 07:29:28 -0800 From: Jeremy Chadwick To: Volodymyr Kostyrko Message-ID: <20120213152928.GA74772@icarus.home.lan> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> <4F3926C5.3010403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3926C5.3010403@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Leidinger , stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 15:42:47 -0000 On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote: > Jeremy Chadwick wrote: > >I want to note here: the pf ALTQ options are a pain in the butt, quite > >honestly. I've found in the past that removing the ones you don't use > >won't result in a successful build, thus one must include them all. We > >do need ALTQ support though, for rate-limiting capability. The NOPCC > >option is needed for SMP builds, which makes me wonder what the state of > >SMP is in this regard -- meaning, on non-SMP builds, is it still safe > >to include ALTQ_NOPCC? > > It seems like I'm missing something. What is good about using > non-SMP kernel? Nothing. It's a question of whether or not use of ALTQ_NOPCC causes breakage on non-SMP kernels, or if FreeBSD even bothers to support non-SMP at this point. "Non-SMP" means "without options SMP". Rephrased: if SMP is the default, and "options SMP" works just fine on systems without multiple processors/cores, then the ALTQ_NOPCC option should probably be removed. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:44:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 890051065670 for ; Mon, 13 Feb 2012 15:44:17 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 170FB8FC08 for ; Mon, 13 Feb 2012 15:44:16 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4606076bkc.13 for ; Mon, 13 Feb 2012 07:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=j+5zUeJh5CzBZXRF0nfUwsdc8uBHMBGq4ZH5DDkQpgg=; b=BMXJSh+P9AcNmcpNAdF1qSQGn+UBZhmn6QTPk/x5KV6JuoRGXm+Usj4SFERHoCxs8V eZNAji1TWRRQ3r68OnersRZJId+MaHe7l1YGanmaGbrJLr6Xw6/clQItszqQSDvsXxIJ Cb1htItFHmvAbRdS0X35iHTG3J37M4KnJGWcw= MIME-Version: 1.0 Received: by 10.204.152.75 with SMTP id f11mr7155413bkw.127.1329147854422; Mon, 13 Feb 2012 07:44:14 -0800 (PST) Received: by 10.204.187.17 with HTTP; Mon, 13 Feb 2012 07:44:14 -0800 (PST) In-Reply-To: References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> Date: Mon, 13 Feb 2012 16:44:14 +0100 Message-ID: From: Andreas Nilsson Cc: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: New BSD Installer 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, 13 Feb 2012 15:44:17 -0000 On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos wrote: > I don't think that reverting is either an option or a solution at this > point. You can consider filing PRs. > How compatible is bsdinstaller with pc-sysinstaller? Are there any notes on why a new installer was created over reusing pc-sysinstall? Regards Andreas Nilsson > > -- > George Kontostanos > Aicom telecoms ltd > http://www.aisecure.net > _______________________________________________ > 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 Feb 13 15:44:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EE4F1065741 for ; Mon, 13 Feb 2012 15:44:38 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AA2628FC1F for ; Mon, 13 Feb 2012 15:44:37 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id jg1so4606076bkc.13 for ; Mon, 13 Feb 2012 07:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BYZL+6+A9Yl4WLkiIf4SwB9nqpH2SuVM16FiOj3MY54=; b=BulZK9XFGoKC6tNc5rhpJpk7YFxmyGiQ3EaTGxd9te+LKHT60RZmdaTCZV/fkrbiYO JbxdF5oFRd/LeZ1XsPrZG6so22AvpitD85AKuSeYu2wZMOgtW8LYKL5wgFGRjVyB4CN+ FohdGYEoyMyn8vMQIC0/jzBZUUTdrWL24cWF0= Received: by 10.204.149.209 with SMTP id u17mr7567263bkv.46.1329147877156; Mon, 13 Feb 2012 07:44:37 -0800 (PST) Received: from green.tandem.local (43-24-132-95.pool.ukrtel.net. [95.132.24.43]) by mx.google.com with ESMTPS id x11sm44513578bkd.2.2012.02.13.07.44.35 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 07:44:36 -0800 (PST) Message-ID: <4F392FE1.5070901@gmail.com> Date: Mon, 13 Feb 2012 17:44:33 +0200 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.1) Gecko/20120213 Firefox/10.0.1 SeaMonkey/2.7.1 MIME-Version: 1.0 To: Alexander Leidinger References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> <20120212120633.0000302d@unknown> <4f38e34a.lZtNaNETBImp/XiD%perryh@pluto.rain.com> <20120213120514.Horde.LMNbOJjmRSRPOO5qpDYJzWA@webmail.leidinger.net> In-Reply-To: <20120213120514.Horde.LMNbOJjmRSRPOO5qpDYJzWA@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: thierry@freebsd.org, stable@freebsd.org, perryh@pluto.rain.com Subject: Re: Reducing the need to compile a custom kernel 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, 13 Feb 2012 15:44:38 -0000 Alexander Leidinger wrote: > Feasible: depend upon your definition of "feasible". You would have to > add all keymaps statically into the kernel. No idea which parts exactly > we talk about, but: > ---snip--- > % du -h /usr/share/syscons/ > 40k /usr/share/syscons/scrnmaps > 570k /usr/share/syscons/fonts > 1.1M /usr/share/syscons/keymaps > 1.8M /usr/share/syscons/ > ---snip--- > > I wouldn't mind for 40k, but 1.8M looks more like the value to calculate > with. Anyway, this is out of the scope of the original question. Correct me if I'm wrong but zfs already fetches plain file /boot/zfs/zpool.cache on load. Can't this be: 1. Postponed to later processing. 2. After filesystems are mounted the keymap is loaded. Or even: 1. Put all viable files on the / partition. 2. Select and load correct one before kernel is fired. -- Sphinx of black quartz judge my vow. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 16:08:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1B5106564A for ; Mon, 13 Feb 2012 16:08:14 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 588538FC18 for ; Mon, 13 Feb 2012 16:08:14 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 3ABB8E640B; Mon, 13 Feb 2012 16:08:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=references :in-reply-to:mime-version:content-transfer-encoding:content-type :message-id:cc:from:subject:date:to; s=mail; bh=InKuiazFLm/gAQc/ L8obB+XJMsc=; b=Mlg2XlGrNh8qQmCJuDI18caCZ5/1V5fkGyP+StK1cmyuN6L1 1kOsTqhIGXnXsaBM/vLRK0p9h6BPxby2FcWKtVE+jW9irYFrKrOj6695NvX5JCGE fOk2TC7U4yRPzYSplNq/iX9fVLsB0rwDppIjJFLsoxQZ69mdWcob7wY84NI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=references :in-reply-to:mime-version:content-transfer-encoding:content-type :message-id:cc:from:subject:date:to; q=dns; s=mail; b=uCo4Q2mWPf Hq+qjzFVGE70fUXN9+lKIYBdM+vKa/YFjYYQ6XuHNMsrTLg4869EzOEcyY1g75/v 2TEfW27Zn8HKA+MFrwJJ0irLfcQC1mmzsDGCxpG6faAd79dkqycvB0rvtn1XQfTU nOR59QhfZIpqJBlP2BbWrXmF0BwzXTYOc= Received: from [10.161.135.60] (unknown [213.205.224.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id CF1F3E633C; Mon, 13 Feb 2012 16:08:12 +0000 (GMT) References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <47A9AE85-1DD8-4E07-B69D-97A4D7933602@cran.org.uk> X-Mailer: iPhone Mail (9A405) From: Bruce Cran Date: Mon, 13 Feb 2012 16:08:05 +0000 To: Andreas Nilsson Cc: FreeBSD Stable Subject: Re: New BSD Installer 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, 13 Feb 2012 16:08:14 -0000 pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was cr= eated as an interim solution.=20 --=20 Bruce Cran Sent from my iPhone On 13 Feb 2012, at 15:44, Andreas Nilsson wrote: > On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos > wrote: >=20 >> I don't think that reverting is either an option or a solution at this >> point. You can consider filing PRs. >>=20 >=20 > How compatible is bsdinstaller with pc-sysinstaller? Are there any notes o= n > why a new installer was created over reusing pc-sysinstall? >=20 > Regards > Andreas Nilsson >=20 >=20 >>=20 >> -- >> George Kontostanos >> Aicom telecoms ltd >> http://www.aisecure.net >> _______________________________________________ >> 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"= >>=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 16:11:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95C2C106564A for ; Mon, 13 Feb 2012 16:11:35 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from rustug.science.ru.nl (rustug.science.ru.nl [131.174.16.158]) by mx1.freebsd.org (Postfix) with ESMTP id 138868FC13 for ; Mon, 13 Feb 2012 16:11:34 +0000 (UTC) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by rustug.science.ru.nl (8.13.7/5.31) with ESMTP id q1DFx6Db015470 for ; Mon, 13 Feb 2012 16:59:06 +0100 (MET) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id q1DFx3MI014283; Mon, 13 Feb 2012 16:59:03 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id F0AE62E04A; Mon, 13 Feb 2012 16:59:02 +0100 (CET) Date: Mon, 13 Feb 2012 16:59:02 +0100 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20120213155902.GE867@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: ZFS faulted pool problem 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, 13 Feb 2012 16:11:35 -0000 Hi there, I run in production a FreeBSD-8 stable server with a ZFS file system. It used raidz2, so that ought to be very safe, I thought. Recently a disk failed, and it was replaced today. However, the file pool doesn't want to come back. Below is the status. da4 was bad and was replaced (by a somewhat bigger disk) in-place. The raidz2 shows to be DEGRADED but somehow the pool as a whole is FAULTED? And whatever I do, the new disk isn't recognised. I cut and pasted some commands below. In all cases it complains that pool "tank" is unavailable... What to do? No I/O errors show up in /var/log/messages. Previously, I had some weird directory where there were CRC errors in the directory entries, and as long as you didn't try to do anything with the files, there was no problem. Removing them was impossible though. I hope it isn't that what is holding my whole pool hostage... I don't mind losing that one directory. fourquid.1:/lib$ sudo zpool status Password: pool: tank state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scan: scrub repaired 0 in 49h3m with 2 errors on Fri Jan 20 15:10:35 2012 config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 2 raidz2-0 DEGRADED 0 0 8 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 3758301462980058947 UNAVAIL 0 0 0 was /dev/da4 da5 ONLINE 0 0 0 fourquid.1:/lib$ sudo zpool replace tank da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool replace raidz2-0 da4 cannot open 'raidz2-0': no such pool fourquid.1:/lib$ sudo zpool replace tank da4 da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool online tank da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool clear tank da4 cannot clear errors for da4: I/O error fourquid.1:/lib$ sudo zpool clear tank cannot clear errors for tank: I/O error fourquid.1:/lib$ sudo zpool replace tank 3758301462980058947 da4 cannot open 'tank': pool is unavailable fourquid.1:/lib$ sudo zpool scrub tank cannot scrub 'tank': pool is currently unavailable -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 16:15:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE61C106566B for ; Mon, 13 Feb 2012 16:15:49 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 331208FC18 for ; Mon, 13 Feb 2012 16:15:49 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3789515343C; Mon, 13 Feb 2012 17:15:48 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoAOeW1S4RcC; Mon, 13 Feb 2012 17:15:46 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id DE44915343A; Mon, 13 Feb 2012 17:15:46 +0100 (CET) Message-ID: <4F39372E.5030105@digiware.nl> Date: Mon, 13 Feb 2012 17:15:42 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jeremy Chadwick , "stable@freebsd.org" References: <4F2940C1.10901@digiware.nl> <20120201143942.GA96012@icarus.home.lan> <4F2960A7.8040705@digiware.nl> <20120201163556.GA97343@icarus.home.lan> <4F297FD5.7090809@digiware.nl> In-Reply-To: <4F297FD5.7090809@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Troube with SSD 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, 13 Feb 2012 16:15:50 -0000 On 2012-02-01 19:09, Willem Jan Withagen wrote: > On 2012-02-01 17:35, Jeremy Chadwick wrote: Hi Jeremy, Took a little longer, since "holidays got in the way". But even in the original server connected to regular intel sataports, the device is not known and 2 commands failed. Flash SSD is connected for about 1 hour now. --WjW >>> The output of the first one command, but it contains some real weird >>> values.....?? >> >> All the values below look fine to me. I will try my best to explain. > >>> SMART Attributes Data Structure revision number: 10 >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE >>> 1 Raw_Read_Error_Rate 0x000f 082 082 050 Pre-fail Always - 897651373777 >>> 5 Reallocated_Sector_Ct 0x0033 100 100 003 Pre-fail Always - 0 >>> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 121242631799621 >>> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31 >>> 171 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 0 >>> 172 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 0 >>> 174 Unknown_Attribute 0x0030 000 000 000 Old_age Offline - 19 >>> 177 Wear_Leveling_Count 0x0000 000 000 000 Old_age Offline - 0 >>> 181 Program_Fail_Cnt_Total 0x0032 000 000 000 Old_age Always - 0 >>> 182 Erase_Fail_Count_Total 0x0032 000 000 000 Old_age Always - 0 >>> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 >>> 194 Temperature_Celsius 0x0022 026 035 000 Old_age Always - 26 (Min/Max 21/35) >>> 195 Hardware_ECC_Recovered 0x001c 120 120 000 Old_age Offline - 897651373777 >>> 196 Reallocated_Event_Count 0x0033 100 100 003 Pre-fail Always - 0 >>> 201 Soft_Read_Error_Rate 0x001c 120 120 000 Old_age Offline - 897651373777 >>> 204 Soft_ECC_Correction 0x001c 120 120 000 Old_age Offline - 897651373777 >>> 230 Head_Amplitude 0x0013 100 100 000 Pre-fail Always - 429496729700 >>> 231 Temperature_Celsius 0x0013 100 100 010 Pre-fail Always - 0 >>> 233 Media_Wearout_Indicator 0x0000 000 000 000 Old_age Offline - 1260 >>> 234 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 1925 >>> 241 Total_LBAs_Written 0x0032 000 000 000 Old_age Always - 1925 >>> 242 Total_LBAs_Read 0x0032 000 000 000 Old_age Always - 1032 >>>> * smartctl -l devstat /dev/whatever >>>> * smartctl -l sataphy /dev/whatever >>>> * smartctl -l ssd /dev/whatever > > It'll have to wait until later this evening, before I able to swap the > disk back in the old box. [~wjw] root@zfs.digiware.nl# smartctl -l devstat /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported [~wjw] root@zfs.digiware.nl# smartctl -l sataphy /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 4 0 Command failed due to ICRC error 0x0003 4 0 R_ERR response for device-to-host data FIS 0x0004 4 0 R_ERR response for host-to-device data FIS 0x0006 4 0 R_ERR response for device-to-host non-data FIS 0x0007 4 0 R_ERR response for host-to-device non-data FIS 0x0008 4 0 Device-to-host non-data FIS retries 0x0009 4 0 Transition from drive PhyRdy to drive PhyNRdy 0x000a 4 11 Device-to-host register FISes sent due to a COMRESET 0x000f 4 0 R_ERR response for host-to-device data FIS, CRC 0x0010 4 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 4 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC 0x0002 4 0 R_ERR response for data FIS 0x0005 4 0 R_ERR response for non-data FIS 0x000b 4 0 CRC errors within host-to-device FIS 0x000d 4 0 Non-CRC errors within host-to-device FIS [~wjw] root@zfs.digiware.nl# smartctl -l ssd /dev/ada2 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 16:28:12 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D27D4106566C for ; Mon, 13 Feb 2012 16:28:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 925808FC17 for ; Mon, 13 Feb 2012 16:28:12 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id ZTrf1i0021ap0As5CUUCD5; Mon, 13 Feb 2012 16:28:12 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.westchester.pa.mail.comcast.net with comcast id ZUUB1i01Q1t3BNj3iUUCTi; Mon, 13 Feb 2012 16:28:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 53FBB102C1E; Mon, 13 Feb 2012 08:28:10 -0800 (PST) Date: Mon, 13 Feb 2012 08:28:10 -0800 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20120213162810.GA75832@icarus.home.lan> References: <4F2940C1.10901@digiware.nl> <20120201143942.GA96012@icarus.home.lan> <4F2960A7.8040705@digiware.nl> <20120201163556.GA97343@icarus.home.lan> <4F297FD5.7090809@digiware.nl> <4F39372E.5030105@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F39372E.5030105@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "stable@freebsd.org" Subject: Re: Troube with SSD 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, 13 Feb 2012 16:28:12 -0000 On Mon, Feb 13, 2012 at 05:15:42PM +0100, Willem Jan Withagen wrote: > On 2012-02-01 19:09, Willem Jan Withagen wrote: > > On 2012-02-01 17:35, Jeremy Chadwick wrote: > > Hi Jeremy, > > Took a little longer, since "holidays got in the way". > But even in the original server connected to regular intel sataports, > the device is not known and 2 commands failed. > > Flash SSD is connected for about 1 hour now. > > --WjW > > > >>> The output of the first one command, but it contains some real weird > >>> values.....?? > >> > >> All the values below look fine to me. I will try my best to explain. > > > >>> SMART Attributes Data Structure revision number: 10 > >>> Vendor Specific SMART Attributes with Thresholds: > >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > >>> 1 Raw_Read_Error_Rate 0x000f 082 082 050 Pre-fail Always - 897651373777 > >>> 5 Reallocated_Sector_Ct 0x0033 100 100 003 Pre-fail Always - 0 > >>> 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 121242631799621 > >>> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 31 > >>> 171 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 0 > >>> 172 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 0 > >>> 174 Unknown_Attribute 0x0030 000 000 000 Old_age Offline - 19 > >>> 177 Wear_Leveling_Count 0x0000 000 000 000 Old_age Offline - 0 > >>> 181 Program_Fail_Cnt_Total 0x0032 000 000 000 Old_age Always - 0 > >>> 182 Erase_Fail_Count_Total 0x0032 000 000 000 Old_age Always - 0 > >>> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > >>> 194 Temperature_Celsius 0x0022 026 035 000 Old_age Always - 26 (Min/Max 21/35) > >>> 195 Hardware_ECC_Recovered 0x001c 120 120 000 Old_age Offline - 897651373777 > >>> 196 Reallocated_Event_Count 0x0033 100 100 003 Pre-fail Always - 0 > >>> 201 Soft_Read_Error_Rate 0x001c 120 120 000 Old_age Offline - 897651373777 > >>> 204 Soft_ECC_Correction 0x001c 120 120 000 Old_age Offline - 897651373777 > >>> 230 Head_Amplitude 0x0013 100 100 000 Pre-fail Always - 429496729700 > >>> 231 Temperature_Celsius 0x0013 100 100 010 Pre-fail Always - 0 > >>> 233 Media_Wearout_Indicator 0x0000 000 000 000 Old_age Offline - 1260 > >>> 234 Unknown_Attribute 0x0032 000 000 000 Old_age Always - 1925 > >>> 241 Total_LBAs_Written 0x0032 000 000 000 Old_age Always - 1925 > >>> 242 Total_LBAs_Read 0x0032 000 000 000 Old_age Always - 1032 > > >>>> * smartctl -l devstat /dev/whatever > >>>> * smartctl -l sataphy /dev/whatever > >>>> * smartctl -l ssd /dev/whatever > > > > It'll have to wait until later this evening, before I able to swap the > > disk back in the old box. > > [~wjw] root@zfs.digiware.nl# smartctl -l devstat /dev/ada2 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > Device Statistics (GP Log 0x04) not supported > [~wjw] root@zfs.digiware.nl# smartctl -l sataphy /dev/ada2 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x0001 4 0 Command failed due to ICRC error > 0x0003 4 0 R_ERR response for device-to-host data FIS > 0x0004 4 0 R_ERR response for host-to-device data FIS > 0x0006 4 0 R_ERR response for device-to-host non-data FIS > 0x0007 4 0 R_ERR response for host-to-device non-data FIS > 0x0008 4 0 Device-to-host non-data FIS retries > 0x0009 4 0 Transition from drive PhyRdy to drive PhyNRdy > 0x000a 4 11 Device-to-host register FISes sent due to a COMRESET > 0x000f 4 0 R_ERR response for host-to-device data FIS, CRC > 0x0010 4 0 R_ERR response for host-to-device data FIS, non-CRC > 0x0012 4 0 R_ERR response for host-to-device non-data FIS, CRC > 0x0013 4 0 R_ERR response for host-to-device non-data FIS, non-CRC > 0x0002 4 0 R_ERR response for data FIS > 0x0005 4 0 R_ERR response for non-data FIS > 0x000b 4 0 CRC errors within host-to-device FIS > 0x000d 4 0 Non-CRC errors within host-to-device FIS > > [~wjw] root@zfs.digiware.nl# smartctl -l ssd /dev/ada2 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > Device Statistics (GP Log 0x04) not supported The SATA PHY counters for the disk, kept in GP log area 0x11, look perfectly fine. The 11 you see at offset 0xa are completely fine; nothing to worry about there. Sadly the SSD does not support GP log area 0x04. Overall I see no real problems with the drive itself given the information above, which is literally all I can go off of. Sorry I can't be of more assistance past this point; honestly your drive looks fine given what I can tell. Only Corsair would be able to help at this point, but it's unlikely any Tier 1 individual would know how to troubleshoot this kind of thing. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 16:45:26 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 422981065673; Mon, 13 Feb 2012 16:45:26 +0000 (UTC) (envelope-from bsd@kobyla.org) Received: from kobyla.org (out.kobyla.org [109.206.180.180]) by mx1.freebsd.org (Postfix) with ESMTP id 842D78FC1A; Mon, 13 Feb 2012 16:45:24 +0000 (UTC) Received: from pp ([172.29.3.120]) by kobyla.org (8.14.5/8.14.5) with ESMTP id q1D9FRfS058479; Mon, 13 Feb 2012 11:15:45 +0200 (EET) (envelope-from bsd@kobyla.org) Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes To: stable@freebsd.org Date: Mon, 13 Feb 2012 11:15:24 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Pavel Polyakov" Message-ID: User-Agent: Opera Mail/11.61 (FreeBSD) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (kobyla.org [172.29.0.117]); Mon, 13 Feb 2012 11:15:47 +0200 (EET) Cc: daichi@freebsd.org, bsd@kobyla.org Subject: lock violation in unionfs (9.0-STABLE r230270) 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, 13 Feb 2012 16:45:26 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=165087 Occurs simply trying to use unionfs: mount -t unionfs -o noatime /usr /mnt insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is not exclusive locked but should be KDB: enter: lock violation Its possible to continue tho. Then locks encounter on every file/dir access under mounted path. It can be resumed from KDB, but sometimes leads to deadlock and system freezes at "db> " prompt. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 17:41:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEEA81065670 for ; Mon, 13 Feb 2012 17:41:15 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3AE8FC15 for ; Mon, 13 Feb 2012 17:41:15 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4742489bkc.13 for ; Mon, 13 Feb 2012 09:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=2JXpcBEFbDi1ZcSK6UBqv0/IUeIApAgTDcZ94Rs6Hbc=; b=qqLmLsbiM2E13Q6qnEJRkJZS9CCFEJI0GdQgfb5C36Sp1KjJcUURC8GYtDih3SxMTD eWvBmoXBrDuPrVo3ygAjrx2qsjhl4feB7eoXO/ruZoygYglLpc3VqS3x/zC4Y3vJvwee AKA0mJvB6Y+j/8QMgmQGhJqKJO287CWumu+nU= Received: by 10.205.135.146 with SMTP id ig18mr7354934bkc.73.1329154873026; Mon, 13 Feb 2012 09:41:13 -0800 (PST) References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <47A9AE85-1DD8-4E07-B69D-97A4D7933602@cran.org.uk> In-Reply-To: <47A9AE85-1DD8-4E07-B69D-97A4D7933602@cran.org.uk> Mime-Version: 1.0 (1.0) From: Andreas Nilsson Date: Mon, 13 Feb 2012 18:41:06 +0100 Message-ID: <1100607767819762110@unknownmsgid> To: Bruce Cran Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Subject: Re: New BSD Installer 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, 13 Feb 2012 17:41:15 -0000 On 13 feb 2012, at 17:08, Bruce Cran wrote: > pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was created as an interim solution. I'll take your word for it, but as far as I know the backend is shell-based as well. /Andreas > > -- > Bruce Cran > > Sent from my iPhone > > On 13 Feb 2012, at 15:44, Andreas Nilsson wrote: > >> On Mon, Feb 13, 2012 at 3:58 PM, George Kontostanos >> wrote: >> >>> I don't think that reverting is either an option or a solution at this >>> point. You can consider filing PRs. >>> >> >> How compatible is bsdinstaller with pc-sysinstaller? Are there any notes on >> why a new installer was created over reusing pc-sysinstall? >> >> Regards >> Andreas Nilsson >> >> >>> >>> -- >>> George Kontostanos >>> Aicom telecoms ltd >>> http://www.aisecure.net >>> _______________________________________________ >>> 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 Mon Feb 13 17:45:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0945D106566C for ; Mon, 13 Feb 2012 17:45:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8E95C8FC19 for ; Mon, 13 Feb 2012 17:45:57 +0000 (UTC) Received: by werm13 with SMTP id m13so5642059wer.13 for ; Mon, 13 Feb 2012 09:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OqVrUUx8DBnZa9cW9Gbc5OOpTUMjWL9QIEFeLaUEgXc=; b=Z4ptCK+OA0jsr8hXOhXmukfD8N1cPutRjrqjNZs0NX6yLHdie3JrTkZ6V0v0fvNOqO Di/ROCeJyrTOWYQLI6ZBpyZDiotL6rcg+qiEfWW8V4oDIvK0w/EGCs6uzhC8txS7YExo EasQnBroe5cLopAXqPkoySLCLEGRi8dCVvOas= MIME-Version: 1.0 Received: by 10.180.99.100 with SMTP id ep4mr25695887wib.7.1329153369316; Mon, 13 Feb 2012 09:16:09 -0800 (PST) Received: by 10.223.62.70 with HTTP; Mon, 13 Feb 2012 09:16:09 -0800 (PST) In-Reply-To: References: <99FFD8AE-F4E0-4BD9-92BC-45D8C8A31383@punkt.de> <1329058091.2541.104.camel@pow> Date: Mon, 13 Feb 2012 11:16:09 -0600 Message-ID: From: Adam Vande More To: George Kontostanos Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, Luke Marsden , =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Subject: Re: Swap on zvol - recommendable? 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, 13 Feb 2012 17:45:58 -0000 On Mon, Feb 13, 2012 at 9:02 AM, George Kontostanos wrote: > > > > I can confirm that this is still a problem on 8.2 and 9.0. > > > > > You can not compare 8.2 with 9.0 per ZFS. What problems are you facing > with your swap in 9.0 ? > I suppose you are having problems similar to the following: http://lists.freebsd.org/pipermail/freebsd-fs/2012-January/013546.html Perhaps setting vfs.zfs.arc_max to some reasonable value might help, but that is just a guess. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 20:21:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 350E4106567A for ; Mon, 13 Feb 2012 20:21:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B50E78FC18 for ; Mon, 13 Feb 2012 20:21:12 +0000 (UTC) Received: by werm13 with SMTP id m13so5786480wer.13 for ; Mon, 13 Feb 2012 12:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=T66PtBHN/VOF0+FV/Hkl7fcSi6Ci7PGxprjJTSnzeHs=; b=kaolSkd0b+i6kNDffA/sI9JEjtwvhPf7/hkAK99Uuz7XLZ2Fxvn+C3JIQJ6axv7KaZ ZjC2BYqyWx4u3HFbDVnD28l0vNlyUz4AD1AbLKKQY/9RXzZRh5DzAtBhBxyGECgrzuYR DfUoGj5SdoA4d2c2FXzXmBd32GxJDhm/3WJjM= MIME-Version: 1.0 Received: by 10.180.78.6 with SMTP id x6mr20208949wiw.18.1329164471580; Mon, 13 Feb 2012 12:21:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Mon, 13 Feb 2012 12:21:11 -0800 (PST) In-Reply-To: <4F38AF69.6010506@os2.kiev.ua> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> Date: Mon, 13 Feb 2012 12:21:11 -0800 X-Google-Sender-Auth: rJsg_5grRbAyZe7Nct3oV5yao5Q Message-ID: From: Adrian Chadd To: Alex Samorukov Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 13 Feb 2012 20:21:13 -0000 I tend to say "the right solution to a problem is to not do it wrong." But.. given that Linux is fine with all the unaligned accesses, is the major sticking point here the fact that Linux's block dev layer is doing all the caching that FreeBSD's direct device layer isn't, and all of those (cached) accesses are what is improving performance? So perhaps it'd be worthwhile investing some time in a geom caching layer to see if that's at all feasible. I had the same problem with userland cyclic filesystems on FreeBSD versus Linux - the Linux FS performed better in synthetic tests because it did caching of the blockdev data. FreeBSD was doing direct IO. Tuning the direct IO sizes and fixing the filesystem code to do everything correctly aligned eliminated a lot of the ridiculous issues. Making Squid cache reads from disk would've improved it too. :-) Finally - I've seen this same issue under linux, especially when you stick a filesystem on a RAID device with the stripe/alignment all wrong. It's not just a BSD problem. :) Adrian From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 20:31:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E032B106566B; Mon, 13 Feb 2012 20:31:10 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9F46B8FC13; Mon, 13 Feb 2012 20:31:10 +0000 (UTC) Received: from roadkill.tharned.org (11008@roadkill.tharned.org [75.145.12.185]) (authenticated bits=0) by roadkill.tharned.org (8.14.5/8.14.5) with ESMTP id q1DK9Ph8011816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2012 14:09:25 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2012; t=1329163765; bh=0n7CC4/Mv4N6uoHO7QfJUuS7hvK9+dtPBMIVrT/LQK4=; h=Date:From:To:cc:Subject:Message-ID:MIME-Version:Content-Type; b=JRcVf8BOJKahGeniPGH3UmG4LttkeJJXiql0ERIeem7DpohGjxKmAyUjnjEIzmSW3 CdtLW8Ivo8VyJfaZRbwY2OiT5OrtiKBao5KfvCB6YqmFRHDsjg+OFU+nLIv1baA2mO lJn17nV1lw9iSCLZ/Acb8J4x4C/M/aa2c9SoApsk= Date: Mon, 13 Feb 2012 14:09:25 -0600 (CST) From: Greg Rivers To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (roadkill.tharned.org [75.145.12.185]); Mon, 13 Feb 2012 14:09:25 -0600 (CST) Cc: mlaier@freebsd.org Subject: sysutils/pftop on 9.x+ 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, 13 Feb 2012 20:31:11 -0000 sysutils/pftop was marked broken on 9.x and above last March[1]. Are there any plans to fix it soon? It's a really handy utility. [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 21:02:40 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id CDCAA106566B; Mon, 13 Feb 2012 21:02:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 7109414E780; Mon, 13 Feb 2012 21:02:40 +0000 (UTC) Message-ID: <4F397A70.3080104@FreeBSD.org> Date: Mon, 13 Feb 2012 13:02:40 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Why won't 8.2 umount -f? 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, 13 Feb 2012 21:02:40 -0000 Is there some magic I'm missing to convince an 8.2 system to umount -f? I had an NFS server crash, so I'm trying to get the mounts updated. All of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly 8.2-pN) are just hanging forever. Is this a bug, or is it something I'm missing? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 21:16:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3492C106567A for ; Mon, 13 Feb 2012 21:16:52 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id B1B068FC1F for ; Mon, 13 Feb 2012 21:16:51 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id C6AFAE6411; Mon, 13 Feb 2012 21:16:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=hAoCUdj6pw8z lkeMcAJBBtGPPTA=; b=L2bhV8cfGLF+WBP5MShI6Mhsz2sjMRGEpFCmjcWua7lu u15/Gnb5PGJzxUUcZYQbrcXAjnYcs2J0JQukYYgGXXgkhHtdmF14QAdHqRDVYblA fveLN2d/zKnWoMfqrP/VE0TFVreIdbrFQOtE9GT5mn0NZnsIMX7dNv3cNZ83Etc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=rumtc0 g/6qVHexneEdH8QD79TTmfONIhdsfxYZeWjVbaQzubqr+dpNme2w22chDRxVL5tf ToI+/5HoZBFh1Oja61FJr1EQ3wFJh99puZ5n6QRQoK32/9mGrREval58UCqPGmUS 2Tw06g4n9Qaw1ihgwX+ikHj7NjglNQV+pvMnw= Received: from [192.168.1.72] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 94EBAE633C; Mon, 13 Feb 2012 21:16:50 +0000 (GMT) Message-ID: <4F397DC1.4000601@cran.org.uk> Date: Mon, 13 Feb 2012 21:16:49 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Andreas Nilsson References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <47A9AE85-1DD8-4E07-B69D-97A4D7933602@cran.org.uk> <1100607767819762110@unknownmsgid> In-Reply-To: <1100607767819762110@unknownmsgid> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: New BSD Installer 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, 13 Feb 2012 21:16:52 -0000 On 13/02/2012 17:41, Andreas Nilsson wrote: > On 13 feb 2012, at 17:08, Bruce Cran wrote: > >> pc-sysinstall doesn't work (well?) on non-x86 platforms so bsdinstall was created as an interim solution. > I'll take your word for it, but as far as I know the backend is > shell-based as well. Yes, they're both written in shell script - that's the only compatibility there is between bsdinstall and pc-sysinstall. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 21:21:20 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 298F41065672; Mon, 13 Feb 2012 21:21:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id EBAA1203270; Mon, 13 Feb 2012 21:20:55 +0000 (UTC) Message-ID: <4F397EB7.1010402@FreeBSD.org> Date: Mon, 13 Feb 2012 13:20:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <4F397A70.3080104@FreeBSD.org> In-Reply-To: <4F397A70.3080104@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 13 Feb 2012 21:21:20 -0000 On 02/13/2012 13:02, Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount -f? > I had an NFS server crash, so I'm trying to get the mounts updated. All > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > 8.2-pN) are just hanging forever. ... and it gets worse. I just 'shutdown -r now'ed one of my less-critical 8.2 systems, and it hung for several minutes after "All buffers synced." After a power cycle it came back, but the buffers weren't actually synced because it's still fsck'ing some pretty large file systems. What the heck? -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 22:12:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56F16106566C for ; Mon, 13 Feb 2012 22:12:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id D8E708FC08 for ; Mon, 13 Feb 2012 22:12:42 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 58B20153434; Mon, 13 Feb 2012 23:12:41 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kreoVUjkjySI; Mon, 13 Feb 2012 23:12:40 +0100 (CET) Received: from [192.168.10.10] (vaio [192.168.10.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id D596D153433; Mon, 13 Feb 2012 23:12:40 +0100 (CET) Message-ID: <4F398AD8.7010609@digiware.nl> Date: Mon, 13 Feb 2012 23:12:40 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F2940C1.10901@digiware.nl> <20120201143942.GA96012@icarus.home.lan> <4F2960A7.8040705@digiware.nl> <20120201163556.GA97343@icarus.home.lan> <4F297FD5.7090809@digiware.nl> <4F39372E.5030105@digiware.nl> <20120213162810.GA75832@icarus.home.lan> In-Reply-To: <20120213162810.GA75832@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "stable@freebsd.org" Subject: Re: Troube with SSD 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, 13 Feb 2012 22:12:43 -0000 On 13-2-2012 17:28, Jeremy Chadwick wrote: > On Mon, Feb 13, 2012 at 05:15:42PM +0100, Willem Jan Withagen wrote: >> On 2012-02-01 19:09, Willem Jan Withagen wrote: >>> On 2012-02-01 17:35, Jeremy Chadwick wrote: > The SATA PHY counters for the disk, kept in GP log area 0x11, look > perfectly fine. The 11 you see at offset 0xa are completely fine; > nothing to worry about there. > > Sadly the SSD does not support GP log area 0x04. > > Overall I see no real problems with the drive itself given the > information above, which is literally all I can go off of. Sorry I > can't be of more assistance past this point; honestly your drive looks > fine given what I can tell. Only Corsair would be able to help at this > point, but it's unlikely any Tier 1 individual would know how to > troubleshoot this kind of thing. I'll let it run, until it disconnects again, and I'll check to see what the SATA stats are. Perhaps there is something that triggers. But that might take a few days.... Last time it took 23 days under my regular load to be dropped from the bus. --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 22:14:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E82D1065673; Mon, 13 Feb 2012 22:14:14 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-lpp01m020-f182.google.com (mail-lpp01m020-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id C61428FC0C; Mon, 13 Feb 2012 22:14:13 +0000 (UTC) Received: by lbbgj3 with SMTP id gj3so3996955lbb.13 for ; Mon, 13 Feb 2012 14:14:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Why2PvYEvQ8zEAy0gHmBjsTg84PA4/YydzfNfB4Ahxs=; b=YVY7hQ09Qbr3oZrSgSqyzUhQm0qHcf62HQEpvbSQWydc6kPr39p8/AiSb2aeJsbF+Y UbKpYjJO5YdCThm0aCn3ItkjhC2KDzY8LHO5J2fEFuvVFUw8YDjsTaDm7ZaoY+JMKORg iVzEguumb04xuzjetNG8YkFFIsTriYBrToz70= MIME-Version: 1.0 Received: by 10.152.136.20 with SMTP id pw20mr12678718lab.32.1329169549195; Mon, 13 Feb 2012 13:45:49 -0800 (PST) Received: by 10.152.114.197 with HTTP; Mon, 13 Feb 2012 13:45:49 -0800 (PST) In-Reply-To: <4F397EB7.1010402@FreeBSD.org> References: <4F397A70.3080104@FreeBSD.org> <4F397EB7.1010402@FreeBSD.org> Date: Mon, 13 Feb 2012 22:45:49 +0100 Message-ID: From: claudiu vasadi To: Doug Barton , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Why won't 8.2 umount -f? 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, 13 Feb 2012 22:14:14 -0000 On Mon, Feb 13, 2012 at 10:20 PM, Doug Barton wrote: > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > Ok, I remember another bug we had some while ago ... so, humor me on this: reproduce the problem where you "shutdown -r now", actually do "shutdown -r now" and leave it be, but check the time at which you issued the cmd. If this is the old but I was told about, the system should reboot exactly after 60 minutes (1 hour). PS: I might be wrong, It's just a hunch. -- Best regards, Claudiu Vasadi From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 22:40:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EF21065672; Mon, 13 Feb 2012 22:40:26 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6B38FC13; Mon, 13 Feb 2012 22:40:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1DMe9pR023171 ; Mon, 13 Feb 2012 23:40:09 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1DMd7PL074483; Mon, 13 Feb 2012 23:39:07 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1DMd6tg074479; Mon, 13 Feb 2012 23:39:06 +0100 (CET) (envelope-from arno) To: freebsd-stable@freebsd.org From: "Arno J. Klaassen" References: Date: Mon, 13 Feb 2012 23:39:06 +0100 In-Reply-To: (Arno J. Klaassen's message of "Sat\, 11 Feb 2012 16\:53\:10 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F399149.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F399149.001/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 13 Feb 2012 22:40:26 -0000 hello, to eventually gain interest in this issue : I updated to today's -stable, tested with vfs.zfs.debug=1 and vfs.zfs.prefetch_disable=0, no difference. I also tested to read the raw partition : [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror 103746636+0 records in 103746636+0 records out 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) [root@cc /usr/ports]# Disk is brand new, looks ok, either my setup is not good or there is a bug somewhere; I can play around with this box for some more time, please feel free to provide me with some hints what to do to be useful for you. Best, Arno "Arno J. Klaassen" writes: > Hello, > > > I finally decided to 'play' a bit with ZFS on a notebook, some years > old, but I installed a brand new disk and memtest passes OK. > > I installed base+ports on partition 2, using 'classical' UFS. > > I crypted partition 3 and created a single zpool on it containing > 4 Z-"file-systems" : > > [root@cc ~]# zfs list > NAME USED AVAIL REFER MOUNTPOINT > zfiles 10.7G 377G 152K /zfiles > zfiles/home 10.6G 377G 119M /zfiles/home > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito > > > I export the ZFS's via nfs and rsynced on the other machine some backup > of my current note-book (geli + UFS, (almost) same 9-stable version, no > problem) to the ZFS's. > > > Quite fast, I see on the notebook : > > > [root@cc /usr/temp]# zpool status -v > pool: zfiles > state: ONLINE > status: One or more devices has experienced an error resulting in data > corruption. Applications may be affected. > action: Restore the file in question if possible. Otherwise restore the > entire pool from backup. > see: http://www.sun.com/msg/ZFS-8000-8A > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 > 2012 > config: > > NAME STATE READ WRITE CKSUM > zfiles ONLINE 0 0 11 > ada0s3.eli ONLINE 0 0 23 > > errors: Permanent errors have been detected in the following files: > > /zfiles/home/arno/.scito/contrib/XNAT.tar > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error > [root@cc /usr/temp]# > > > As said, memtest is OK, nothing is logged to the console, UFS on the > same disk works OK (I did some tests copying and comparing random data) > and smartctl as well seems to trust the disk : > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > # 1 Extended offline Completed without error 00% 388 > # 2 Short offline Completed without error 00% 387 > > > Am I doing something wrong and/or let me know what I could provide as > extra info to try to solve this (dmesg.boot at the end of this mail). > > Thanx a lot in advance, > > best, Arno > > > > ################### demsg.boot ####### > > Table 'FACP' at 0xbdd90200 > Table 'APIC' at 0xbdd90390 > APIC: Found table at 0xbdd90390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 130 ACPI ID 3: disabled > MADT: Found CPU APIC ID 131 ACPI ID 4: disabled > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-STABLE #0: Fri Feb 3 22:48:57 CET 2012 > toor@cc:/usr/obj/raid1/bsd/9/src/sys/VR603 amd64 > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bba000. > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80bba200. > Calibrating TSC clock ... TSC clock: 2161296371 Hz > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz (2161.30-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > Features=0xbfebfbff > Features2=0xe39d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 3221225472 (3072 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x0000000000095fff, 610304 bytes (149 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x0000000000be9000 - 0x00000000b8402fff, 3078725632 bytes (751642 pages) > avail memory = 3057152000 (2915 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 > x86bios: SSEG 0x001000-0x001fff at 0xffffff8000210000 > x86bios: EBDA 0x099000-0x09ffff at 0xfffffe0000099000 > x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf9420 00014 (v00 ACPIAM) > ACPI: RSDT 0xbdd90000 00048 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: FACP 0xbdd90200 00084 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: DSDT 0xbdd905c0 072D3 (v01 1ADTS 1ADTS012 00000012 INTL 20051117) > ACPI: FACS 0xbdd9e000 00040 > ACPI: APIC 0xbdd90390 0006C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: MCFG 0xbdd90400 0003C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: SLIC 0xbdd90440 00176 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: OEMB 0xbdd9e040 00072 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > ACPI: HPET 0xbdd9a5c0 00038 (v01 MSI_NB OEMHPET 20091013 MSFT 00000097) > ACPI: ASF! 0xbdd9a600 00099 (v32 LEGEND I865PASF 00000001 INTL 20051117) > ACPI: GSCI 0xbdd9e0c0 02024 (v01 MSI_NB GMCHSCI 20091013 MSFT 00000097) > ACPI: SSDT 0xbdda0a50 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > wlan: <802.11 Link Layer> > random: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > nfslock: pseudo-device > io: > null: > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > ACPI: Executed 1 blocks of module-level executable AML code > acpi0: Power Button (fixed) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bdd00000 (3) failed > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > ACPI: SSDT 0xbdda04b0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > cpu1: on acpi0 > ACPI: SSDT 0xbdda0420 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > ACPI: Dynamic OEM Table Load: > ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > acpi_ec0: port 0x62,0x66 on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 5 > Validation 0 5 N 0 5 > After Disable 0 255 N 0 5 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 > Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: decoding 4 range 0-0xcf7 > pcib0: decoding 4 range 0xd00-0xffff > pcib0: decoding 3 range 0xa0000-0xbffff > pcib0: decoding 3 range 0xd0000-0xdffff > pcib0: decoding 3 range 0xbde00000-0xdfffffff > pcib0: decoding 3 range 0xf0000000-0xfed8ffff > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x2a40, revid=0x07 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2a42, revid=0x07 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 64, base 0xfd800000, size 22, enabled > pcib0: allocated type 3 (0xfd800000-0xfdbfffff) for rid 10 of pci0:0:2:0 > map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled > pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 > map[20]: type I/O Port, range 32, base 0xb400, size 3, enabled > pcib0: allocated type 4 (0xb400-0xb407) for rid 20 of pci0:0:2:0 > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2a43, revid=0x07 > domain=0, bus=0, slot=2, func=1 > class=03-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 3 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfdd00000, size 20, enabled > pcib0: allocated type 3 (0xfdd00000-0xfddfffff) for rid 10 of pci0:0:2:1 > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled > pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:0 > pcib0: matched entry for 0.26.INTA > pcib0: slot 26 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=7 > map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled > pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:26:1 > pcib0: matched entry for 0.26.INTB > pcib0: slot 26 INTB hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdefec00, size 10, enabled > pcib0: allocated type 3 (0xfdefec00-0xfdefefff) for rid 10 of pci0:0:26:7 > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xfdef8000, size 14, enabled > pcib0: allocated type 3 (0xfdef8000-0xfdefbfff) for rid 10 of pci0:0:27:0 > pcib0: matched entry for 0.27.INTA > pcib0: slot 27 INTA hardwired to IRQ 22 > found-> vendor=0x8086, dev=0x2940, revid=0x03 > domain=0, bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTA > pcib0: slot 28 INTA hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x2942, revid=0x03 > domain=0, bus=0, slot=28, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTB > pcib0: slot 28 INTB hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x2946, revid=0x03 > domain=0, bus=0, slot=28, func=3 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > intpin=d, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > pcib0: matched entry for 0.28.INTD > pcib0: slot 28 INTD hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=14 > map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled > pcib0: allocated type 4 (0xc000-0xc01f) for rid 20 of pci0:0:29:0 > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled > pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:29:1 > pcib0: matched entry for 0.29.INTB > pcib0: slot 29 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled > pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:29:2 > pcib0: matched entry for 0.29.INTC > pcib0: slot 29 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=14 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xfdeff000, size 10, enabled > pcib0: allocated type 3 (0xfdeff000-0xfdeff3ff) for rid 10 of pci0:0:29:7 > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2448, revid=0x93 > domain=0, bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2919, revid=0x03 > domain=0, bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2929, revid=0x03 > domain=0, bus=0, slot=31, func=2 > class=01-06-01, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 16 messages > map[10]: type I/O Port, range 32, base 0xcc00, size 3, enabled > pcib0: allocated type 4 (0xcc00-0xcc07) for rid 10 of pci0:0:31:2 > map[14]: type I/O Port, range 32, base 0xc880, size 2, enabled > pcib0: allocated type 4 (0xc880-0xc883) for rid 14 of pci0:0:31:2 > map[18]: type I/O Port, range 32, base 0xc800, size 3, enabled > pcib0: allocated type 4 (0xc800-0xc807) for rid 18 of pci0:0:31:2 > map[1c]: type I/O Port, range 32, base 0xc480, size 2, enabled > pcib0: allocated type 4 (0xc480-0xc483) for rid 1c of pci0:0:31:2 > map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled > pcib0: allocated type 4 (0xc400-0xc41f) for rid 20 of pci0:0:31:2 > map[24]: type Memory, range 32, base 0xfdeff800, size 11, enabled > pcib0: allocated type 3 (0xfdeff800-0xfdefffff) for rid 24 of pci0:0:31:2 > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=15 > map[10]: type Memory, range 64, base 0xfdeff400, size 8, enabled > pcib0: allocated type 3 (0xfdeff400-0xfdeff4ff) for rid 10 of pci0:0:31:3 > map[20]: type I/O Port, range 32, base 0x400, size 5, enabled > pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 > pcib0: matched entry for 0.31.INTC > pcib0: slot 31 INTC hardwired to IRQ 18 > vgapci0: port 0xb400-0xb407 mem 0xfd800000-0xfdbfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > agp0: on vgapci0 > agp0: aperture size is 256M, detected 32764k stolen memory > vgapci1: mem 0xfdd00000-0xfddfffff at device 2.1 on pci0 > pci0: at device 26.0 (no driver attached) > pci0: at device 26.1 (no driver attached) > pci0: at device 26.7 (no driver attached) > pci0: at device 27.0 (no driver attached) > pcib1: irq 17 at device 28.0 on pci0 > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 > pcib0: allocated type 3 (0xfdf00000-0xfdffffff) for rid 20 of pcib1 > pcib0: allocated type 3 (0xf9f00000-0xf9ffffff) for rid 24 of pcib1 > pcib1: domain 0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode 0xd000-0xdfff > pcib1: memory decode 0xfdf00000-0xfdffffff > pcib1: prefetched decode 0xf9f00000-0xf9ffffff > pci2: on pcib1 > pci2: domain=0, physical bus=2 > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > domain=0, bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 2 messages in map 0x20 > map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled > pcib1: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 > map[18]: type Memory, range 64, base 0xfdfff000, size 12, enabled > pcib1: allocated memory range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 > map[20]: type Prefetchable Memory, range 64, base 0xf9ff0000, size 16, enabled > pcib1: allocated prefetch range (0xf9ff0000-0xf9ffffff) for rid 20 of pci0:2:0:0 > pcib1: matched entry for 2.0.INTA > pcib1: slot 0 INTA hardwired to IRQ 16 > pci2: at device 0.0 (no driver attached) > pcib2: irq 16 at device 28.1 on pci0 > pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 > pcib0: allocated type 3 (0xfe000000-0xfeafffff) for rid 20 of pcib2 > pcib0: allocated type 3 (0xfa000000-0xfcffffff) for rid 24 of pcib2 > pcib2: domain 0 > pcib2: secondary bus 3 > pcib2: subordinate bus 4 > pcib2: I/O decode 0xe000-0xefff > pcib2: memory decode 0xfe000000-0xfeafffff > pcib2: prefetched decode 0xfa000000-0xfcffffff > pci3: on pcib2 > pci3: domain=0, physical bus=3 > pcib3: irq 19 at device 28.3 on pci0 > pcib0: allocated type 3 (0xfeb00000-0xfebfffff) for rid 20 of pcib3 > pcib3: domain 0 > pcib3: secondary bus 5 > pcib3: subordinate bus 5 > pcib3: memory decode 0xfeb00000-0xfebfffff > pcib3: no prefetched decode > pci5: on pcib3 > pci5: domain=0, physical bus=5 > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > map[10]: type Memory, range 64, base 0xfebf0000, size 16, enabled > pcib3: allocated memory range (0xfebf0000-0xfebfffff) for rid 10 of pci0:5:0:0 > pcib3: matched entry for 5.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 19 > pci5: at device 0.0 (no driver attached) > pci0: at device 29.0 (no driver attached) > pci0: at device 29.1 (no driver attached) > pci0: at device 29.2 (no driver attached) > pci0: at device 29.7 (no driver attached) > pcib4: at device 30.0 on pci0 > pcib4: domain 0 > pcib4: secondary bus 1 > pcib4: subordinate bus 1 > pcib4: no prefetched decode > pcib4: Subtractively decoded bridge. > pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND > pci1: on pcib4 > pci1: domain=0, physical bus=1 > isab0: at device 31.0 on pci0 > isa0: on isab0 > ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfdeff800-0xfdefffff irq 19 at device 31.2 on pci0 > ahci0: attempting to allocate 1 MSI vectors (16 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > ahci0: using IRQ 256 for MSI > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported > ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 4ports > ahci0: Caps2: > ahci0: EM Caps: ALHD XMT SMB LED > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: > ahcich2: not probed (disabled) > ahcich3: not probed (disabled) > ahcich4: at channel 4 on ahci0 > ahcich4: Caps: > ahcich5: at channel 5 on ahci0 > ahcich5: Caps: > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 51 > Event timer "RTC" frequency 32768 Hz quality 0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 52 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0065 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 53 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route > hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic > hpet0: t1: irqs 0x00f00000 (0) > hpet0: t2: irqs 0x00f00800 (0) > hpet0: t3: irqs 0x00f01000 (0) > Timecounter "HPET" frequency 14318180 Hz quality 950 > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 440 > Event timer "HPET2" frequency 14318180 Hz quality 440 > Event timer "HPET3" frequency 14318180 Hz quality 440 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > acpi_button1: on acpi0 > acpi0: wakeup code va 0xffffff80d4544000 pa 0x4000 > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 > pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 > pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 > pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 > isa_probe_children: disabling PnP devices > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xc0000-0xcf7ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > ppc0 failed to probe at irq 7 on isa0 > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > Device configuration finished. > procfs registered > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > ahcich0: AHCI reset... > ahcich0: SATA connect time=100us status=00000123 > ahcich0: AHCI reset: device found > ahcich1: AHCI reset... > ahcich1: SATA offline status=00000004 > ahcich1: AHCI reset: device not found > ahcich4: AHCI reset... > ahcich4: SATA offline status=00000004 > ahcich4: AHCI reset: device not found > ahcich5: AHCI reset... > ahcich5: SATA connect time=900us status=00000113 > ahcich5: AHCI reset: device found > ahcich5: AHCI reset: device ready after 0ms > (aprobe1:ahcich5:0:0:0): SIGNATURE: eb14 > acpi_acad0: acline initialization start > battery0: battery initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > ahcich5: SNTF 0x0001 > ahcich0: AHCI reset: device ready after 100ms > (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-8 SATA 2.x device > GEOM: new disk cd0 > pass0: Serial Number 5YX0J5YD > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number 30651780 1165921Q111 > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > pass1 at ahcich5 bus 0 scbus3 target 0 lun 0 > pass1: Removable CD-ROM SCSI-0 device > pass1: Serial Number 30651780 1165921Q111 > pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > ada0: ATA-8 SATA 2.x device > ada0: Serial Number 5YX0J5YD > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > TSC timecounter disabled: C3 enabled. > Timecounter "TSC" frequency 2161296371 Hz quality -1000 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:battery0: battery initialization done, tried 1 times > 0:0): Error 6, Unretryable error > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > GEOM: new disk ada0 > GEOM: ada0s3: media size does not match label. > Trying to mount root from ufs:/dev/ada0s2a [rw,noatime]... > start_init: trying /sbin/init > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > ZFS filesystem version 5 > ZFS storage pool version 28 > (cd0:ahcich5:0:0:0): SCSI status error > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > tap0: bpf attached > tap0: Ethernet address: 00:bd:0b:07:00:00 > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > domain=0, bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 1 message, 64 bit > MSI-X supports 2 messages in map 0x20 > pci0:2:0:0: reprobing on driver added > re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xf9ff0000-0xf9ffffff irq 16 at device 0.0 on pci2 > re0: MSI count : 1 > re0: MSI-X count : 2 > re0: attempting to allocate 1 MSI-X vectors (2 supported) > msi: routing MSI-X IRQ 257 to local APIC 0 vector 55 > re0: using IRQ 257 for MSI-X > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: bpf attached > re0: Ethernet address: 00:24:21:61:e0:20 > pci3: driver added > pci5: driver added > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=19 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > pci0:5:0:0: reprobing on driver added > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > pci3: driver added > pci5: driver added > found-> vendor=0x168c, dev=0x001c, revid=0x01 > domain=0, bus=5, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=19 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > MSI-X supports 1 message in map 0x10 > pci0:5:0:0: reprobing on driver added > ath0: mem 0xfebf0000-0xfebfffff irq 19 at device 0.0 on pci5 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 56 > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > ath0: Use hw queue 1 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 2 for WME_AC_VI traffic > ath0: Use hw queue 3 for WME_AC_VO traffic > ath0: Use hw queue 8 for CAB traffic > ath0: Use hw queue 9 for beacons > ath0: using multicast key search > crypto: > cryptosoft0: on motherboard > crypto: assign cryptosoft0 driver id 0, flags 100663296 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > GEOM_ELI: Device ada0s3.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: software > pci0: driver added > found-> vendor=0x8086, dev=0x2937, revid=0x03 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=16 > pci0:0:26:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2938, revid=0x03 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=21 > pci0:0:26:1: reprobing on driver added > found-> vendor=0x8086, dev=0x293c, revid=0x03 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > powerspec 2 supports D0 D3 current D0 > pci0:0:26:7: reprobing on driver added > found-> vendor=0x8086, dev=0x293e, revid=0x03 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=22 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > pci0:0:27:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2934, revid=0x03 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > pci0:0:29:0: reprobing on driver added > found-> vendor=0x8086, dev=0x2935, revid=0x03 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=19 > pci0:0:29:1: reprobing on driver added > found-> vendor=0x8086, dev=0x2936, revid=0x03 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:29:2: reprobing on driver added > found-> vendor=0x8086, dev=0x293a, revid=0x03 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=23 > powerspec 2 supports D0 D3 current D0 > pci0:0:29:7: reprobing on driver added > found-> vendor=0x8086, dev=0x2930, revid=0x03 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=18 > pci0:0:31:3: reprobing on driver added > pci1: driver added > pci2: driver added > pci3: driver added > pci5: driver added > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > coretemp0: on cpu0 > coretemp0: Setting TjMax=100 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est0 attach returned 6 > coretemp1: on cpu1 > coretemp1: Setting TjMax=100 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > device_attach: est1 attach returned 6 > > _______________________________________________ > 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" > -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 23:36:34 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1071065672; Mon, 13 Feb 2012 23:36:34 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 3114D8FC19; Mon, 13 Feb 2012 23:36:33 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id q1DMQuUT013743; Mon, 13 Feb 2012 17:01:06 -0600 Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa03.fnfis.com with ESMTP id 12y9b7gk2x-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Feb 2012 17:01:06 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.17) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 13 Feb 2012 17:01:05 -0600 From: Devin Teske To: Doug Barton References: <4F3993C9.1040506@fisglobal.com> In-Reply-To: <4F3993C9.1040506@fisglobal.com> Date: Mon, 13 Feb 2012 15:01:08 -0800 Message-ID: <08c101cceaa3$5ff9d880$1fed8980$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFdwB4ZmQ9SgfWzRn8l+XRpwNy7FJcZxISg Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-13_05:2012-02-13, 2012-02-13, 1970-01-01 signatures=0 Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org, "Robison, Dave" Subject: RE: Re: Why won't 8.2 umount -f? 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, 13 Feb 2012 23:36:34 -0000 > -------- Original Message -------- > Subject: Re: Why won't 8.2 umount -f? > Date: Mon, 13 Feb 2012 13:20:55 -0800 > From: Doug Barton > Organization: http://SupersetSolutions.com/ > To: > CC: > Cross posting? (gasp!) > On 02/13/2012 13:02, Doug Barton wrote: > > Is there some magic I'm missing to convince an 8.2 system to umount -f? > > I had an NFS server crash, so I'm trying to get the mounts updated. All > > of the 7.x systems happily did 'umount -f', but the 8.x systems (mostly > > 8.2-pN) are just hanging forever. > > ... and it gets worse. I just 'shutdown -r now'ed one of my > less-critical 8.2 systems, and it hung for several minutes after "All > buffers synced." After a power cycle it came back, but the buffers > weren't actually synced because it's still fsck'ing some pretty large > file systems. > > What the heck? We've noticed this behavior too (on 8.1-RELEASE-p6). The work-around (to avoid long fsck) is to: 1. Drop to the kernel debugger (Ctrl+Alt+ESC -- requires DDB to be enabled in kernel) 2. Type: call boot(0) This causes the system to attempt a second sync of the buffers. This second attempt ends up timing out but succeeds in resetting the CPU (after 3x 60s timeouts). The price (waiting 180s before cpu_reset() is called) can be well worth it (avoiding multi-hour fsck) because the disks will be marked clean. For us, this is a serious issue and like Doug, we too exclaim "what the heck?" Shouldn't have to drop to kernel debugger and [redundantly] invoke boot(0) after syncer's hang just prior to cpu_reset(). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 02:23:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08BD9106566C; Tue, 14 Feb 2012 02:23:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2248FC08; Tue, 14 Feb 2012 02:23:39 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPXEOU+DaFvO/2dsb2JhbAA7CIUQrB2BcgEBAQMBAQEBICsgCxsYAgINGQIpAQkmBggHBAEcBIdbCac/kh6BL4dpgjAVFwUKBwEDAgQHAh0BAwIUBIMeAQYBDQYCg0CBFgSISopAgiiTAg X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="156285400" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 21:23:38 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 82976B3F0E; Mon, 13 Feb 2012 21:23:38 -0500 (EST) Date: Mon, 13 Feb 2012 21:23:38 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F397A70.3080104@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 02:23:40 -0000 Doug Barton wrote: > Is there some magic I'm missing to convince an 8.2 system to umount > -f? > I had an NFS server crash, so I'm trying to get the mounts updated. > All > of the 7.x systems happily did 'umount -f', but the 8.x systems > (mostly > 8.2-pN) are just hanging forever. > > Is this a bug, or is it something I'm missing? > Well, I didn't realize that a 7.n system would "umount -f" an NFS mount when the server was down and there were dirty blocks that needed to be written back, but I don't know. (I seem to recall that someone encouraged me to MFC one of my changes related to this back to stable/7, but I'm not sure if it mattered?) I have pretty well fixed the new client w.r.t. this except for the case where you do a "umount " and that gets hung. Once a non "-f" umount gets hung, there is nothing you can do, because the mount point is locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). My guess is that the old (default for 8.n) client isn't fixed for this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it used some in the old/regular client, but not as much as the new one. You also need a fairly recent (can't remember if that is in 8.2) version of umount.c, since the code had a "sync();" at the beginning of it that would hang before even getting to the umount(2) syscall. Bottom line, I think the newnfs client (the default for 9.0) can do this, but I'm doubtful the old/reguler one can. (I also wouldn't be surprised if there is still a bug other than the above mentioned one w.r.t. doing a "umount /mnt" and getting that hung before trying "umount -f /mnt". rick > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 02:41:14 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 29C77106566B; Tue, 14 Feb 2012 02:41:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1A63014EB5A; Tue, 14 Feb 2012 02:41:13 +0000 (UTC) Message-ID: <4F39C9C8.7060700@FreeBSD.org> Date: Mon, 13 Feb 2012 18:41:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Rick Macklem References: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <318799457.1320617.1329186218494.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 02:41:14 -0000 On 02/13/2012 18:23, Rick Macklem wrote: > Doug Barton wrote: >> Is there some magic I'm missing to convince an 8.2 system to umount >> -f? >> I had an NFS server crash, so I'm trying to get the mounts updated. >> All >> of the 7.x systems happily did 'umount -f', but the 8.x systems >> (mostly >> 8.2-pN) are just hanging forever. >> >> Is this a bug, or is it something I'm missing? >> > Well, I didn't realize that a 7.n system would "umount -f" an NFS > mount when the server was down and there were dirty blocks that > needed to be written back, but I don't know. I'm doubtful that any of those systems had dirty blocks. > (I seem to recall that > someone encouraged me to MFC one of my changes related to this back > to stable/7, but I'm not sure if it mattered?) Please don't unless you can verify that it doesn't make this situation worse. :) > I have pretty well fixed the new client w.r.t. this except for the > case where you do a "umount " and that gets hung. Once a non "-f" > umount gets hung, there is nothing you can do, because the mount point is > locked up, so a subsequent "umount -f" can't get as far as nfs_umount(). I'm aware of this issue, and I did 'umount -f' first. But I wonder if this isn't something that should be fixed because I think most users would expect that 'umount -> umount -f' would be the natural progression, similar to 'kill -> kill -9'. > My guess is that the old (default for 8.n) client isn't fixed for > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > used some in the old/regular client, but not as much as the new one. > > You also need a fairly recent (can't remember if that is in 8.2) > version of umount.c, since the code had a "sync();" at the beginning > of it that would hang before even getting to the umount(2) syscall. > > Bottom line, I think the newnfs client (the default for 9.0) can > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > be surprised if there is still a bug other than the above mentioned > one w.r.t. doing a "umount /mnt" and getting that hung before trying > "umount -f /mnt". Is the new client in 8-stable up to date relevant to 9.0, and/or is it considered safe to use in production? Thanks, Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 03:13:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 131C1106564A; Tue, 14 Feb 2012 03:13:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 925378FC12; Tue, 14 Feb 2012 03:13:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACLQOU+DaFvO/2dsb2JhbAA7CIUQrB6BcgEBBAEjBFIbGAICDQgCDwJZBogPp0KSHYEvh2mCPggKBgUHARgNAQICCAMOBAYDBQwVAoM7gS0CgXSBFgSISoxokwI X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="159429863" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 22:13:29 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 80EC1B3F33; Mon, 13 Feb 2012 22:13:29 -0500 (EST) Date: Mon, 13 Feb 2012 22:13:29 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39C9C8.7060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:13:31 -0000 Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > sbruno did the MFC. I don't think the changes would make it worse. > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > I just looked and at least some of the fixes were MFC'd to stable/8 about 8months ago. So, they aren't in 8.2, but will be in 8.3. > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > It looks like stable/8 might be ok using either client. The newnfs in stable/8 should be up to date w.r.t. bugfixes in the new/regular client in 9.0. > > Thanks, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 03:18:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A2B8106564A; Tue, 14 Feb 2012 03:18:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id EE2C98FC08; Tue, 14 Feb 2012 03:18:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANnROU+DaFvO/2dsb2JhbAA7CIUQrB6BcgEBBAEjBFIbGAICDQgCDwJZBogPp0CSGoEvh2mCQAYKBgMCBAQBJAECAggDDgQGAwUMF4M7gS0CgXSBFgSISoxokwI X-IronPort-AV: E=Sophos;i="4.73,414,1325480400"; d="scan'208";a="156290538" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 13 Feb 2012 22:18:33 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 43B14B3F3B; Mon, 13 Feb 2012 22:18:33 -0500 (EST) Date: Mon, 13 Feb 2012 22:18:33 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <627799650.1324962.1329189513227.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39C9C8.7060700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:18:34 -0000 Doug Barton wrote: > On 02/13/2012 18:23, Rick Macklem wrote: > > Doug Barton wrote: > >> Is there some magic I'm missing to convince an 8.2 system to umount > >> -f? > >> I had an NFS server crash, so I'm trying to get the mounts updated. > >> All > >> of the 7.x systems happily did 'umount -f', but the 8.x systems > >> (mostly > >> 8.2-pN) are just hanging forever. > >> > >> Is this a bug, or is it something I'm missing? > >> > > Well, I didn't realize that a 7.n system would "umount -f" an NFS > > mount when the server was down and there were dirty blocks that > > needed to be written back, but I don't know. > > I'm doubtful that any of those systems had dirty blocks. > > > (I seem to recall that > > someone encouraged me to MFC one of my changes related to this back > > to stable/7, but I'm not sure if it mattered?) > > Please don't unless you can verify that it doesn't make this situation > worse. :) > > > I have pretty well fixed the new client w.r.t. this except for the > > case where you do a "umount " and that gets hung. Once a non > > "-f" > > umount gets hung, there is nothing you can do, because the mount > > point is > > locked up, so a subsequent "umount -f" can't get as far as > > nfs_umount(). > > I'm aware of this issue, and I did 'umount -f' first. But I wonder if > this isn't something that should be fixed because I think most users > would expect that 'umount -> umount -f' would be the natural > progression, similar to 'kill -> kill -9'. > I suspect that is "very difficult" to fix. The regular "umount /mnt" will stuck somewhere inside vinvalbuf() trying to flush blocks back to the server while holding a lock on the mount point. Although kib@ is the guy who would most likely know, I don't think it would be easy to get it to come out ok. For example, one approach might be to make all the sleeps interruptible and then add code to gracefully handle an EINTR return from them and then release locks as they return and..... well it's not something I would want to tackle. > > My guess is that the old (default for 8.n) client isn't fixed for > > this. If you "grep MNTK_UNMOUNTF" in the sources, you'll see it > > used some in the old/regular client, but not as much as the new one. > > > > You also need a fairly recent (can't remember if that is in 8.2) > > version of umount.c, since the code had a "sync();" at the beginning > > of it that would hang before even getting to the umount(2) syscall. > > > > Bottom line, I think the newnfs client (the default for 9.0) can > > do this, but I'm doubtful the old/reguler one can. (I also wouldn't > > be surprised if there is still a bug other than the above mentioned > > one w.r.t. doing a "umount /mnt" and getting that hung before trying > > "umount -f /mnt". > > Is the new client in 8-stable up to date relevant to 9.0, and/or is it > considered safe to use in production? > > > Thanks, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 03:22:44 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 086C6106564A; Tue, 14 Feb 2012 03:22:44 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C3B4B14ED12; Tue, 14 Feb 2012 03:22:42 +0000 (UTC) Message-ID: <4F39D382.50209@FreeBSD.org> Date: Mon, 13 Feb 2012 19:22:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0) Gecko/20120201 Thunderbird/10.0 MIME-Version: 1.0 To: Rick Macklem References: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <2040914240.1324793.1329189209494.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 03:22:44 -0000 On 02/13/2012 19:13, Rick Macklem wrote: > I just looked and at least some of the fixes were MFC'd to stable/8 about > 8months ago. So, they aren't in 8.2, but will be in 8.3. Well 8.3 is about to enter code freeze, any way we can check to be sure all of the relevant fixes can be mfc'ed? Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 04:55:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89850106564A for ; Tue, 14 Feb 2012 04:55:31 +0000 (UTC) (envelope-from jflemingeds@yahoo.com) Received: from nm1.bullet.mail.sp2.yahoo.com (nm1.bullet.mail.sp2.yahoo.com [98.139.91.71]) by mx1.freebsd.org (Postfix) with SMTP id 5B3EC8FC12 for ; Tue, 14 Feb 2012 04:55:31 +0000 (UTC) Received: from [98.139.91.69] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 04:43:09 -0000 Received: from [98.139.91.9] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 04:43:09 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 04:43:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 259173.50545.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 15851 invoked by uid 60001); 14 Feb 2012 04:43:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1329194588; bh=qG/nmWdH7Ou//3ka5auTHL0LkUMIWZzpFTokuhh2ZjI=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PadhSzQtKW2vEwm7JuuA+DA4RC0rtqA1wzR+vlZwcSzCyJkdUP7IJtJMaLCaO/PCQYsfDFWJQ3Hb52dPIrXddvOVZCAlJaFMNmOwCcR0jT7qFKPkbS/sIglo0njOh0EeQIPcgR4kdYxCrVGdHaBc6VsMTQ+HZHNKF2xDuaNs+os= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MY6cEnmyvjMK61HfldGoA7Z4gRPC9xuNa5Y9hKnOC/7yL9cmh/+lgYFbzQ++bHTV7/y8aLVlyAsUTaCw9aH6NI4z3stkTKdTcWUUcf5k693wz49vdYc/zdADTlxL7Na8iJy3HlQemGqppGcjp0yuqmtaRY2P/APpOaLsoDQfd08=; X-YMail-OSG: nTT3nl0VM1mOKbgTUjW4ctLH15o5iEeWNSNAqocDoAteeRg JPxm1CllrWxG4ZjxXY2YbMcqfcRkueq7hNipr53FoId6_W4BuX0nPaPzKR3x NNNMl5csTqN.huTdOTON5.fmeVIXCTzfkTRkZCjBPw01flR1N0UvaX.qwYSp 6qVCISiavh29WymsRc7F6gkVYB3TcNtWDOk.ffZOGA4ioPBptm9BHyagn_gN fubsVdi.7GnqLTZ47GnyRLwODUz4.9mhxBl4n4dMJBYb42K6Zo9OGs.SrEJl B.gZfHa5sC_72LqzdoVhe8Iftsd.EGwP_TntvFq6uoFaQfq7h49JGcr.joEX 2_8LtuGDWuDCqVmhg1wKhya3pN3YTpnwNf9B2IPjS4vsTL4ZVMe2M0jtNRg7 93nNYcvEzNxC3hi8d.USC2cIuyqPjZ0moOgFgaDz3gVMQT6WFyapj.5jrZN1 cCgoF Received: from [99.8.58.116] by web111720.mail.gq1.yahoo.com via HTTP; Mon, 13 Feb 2012 20:43:08 PST X-Mailer: YahooMailWebService/0.8.116.338427 Message-ID: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> Date: Mon, 13 Feb 2012 20:43:08 -0800 (PST) From: john fleming To: "freebsd-stable@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 6.2-Release ..ish.. CF + ata == freeze? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john fleming List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 04:55:31 -0000 Just thought i would post over here as i'm not getting a warm fuzzy from ch= eckpoint about being able to find the root cause of an issue. I have a larg= e install base of IPSO checkpoint firewalls, which are based on FreeBSD 6.2= . I've had 3 firewalls hang basically the same way, with something that loo= ks like a filesystem issue or an=A0issue with a CF card. =0A=A0=0ADoes anyo= ne happen to know of any bugs (i've been looking around) that could cause s= omething like that? Granted, it could be a batch of bad CF cards, but its o= dd that i'm seeing the same thing on 3 different boxes and once rebooted th= ey seem ok.=0A=A0=0AAlso is it possible to get useful info form the atacont= roller when things go south like this from the ddb prompt?=0A=A0=0AThis is = what shows in show msgbuf=0Aad0: timeout waiting to issue command=0Aad0: er= ror issuing WRITE command=0Aad0: timeout waiting to issue command=0Aad0: er= ror issuing WRITE command=0Aad0: timeout waiting to issue command=0Aad0: er= ror issuing WRITE command=0Aad0: timeout waiting to issue command=0Aad0: er= ror issuing WRITE command=0Ag_vfs_done():ad0s4h[WRITE(offset=3D33849344, le= ngth=3D131072)]error =3D 5 =0Ag_vfs_done():ad0s4h[WRITE(offset=3D33980416, = length=3D131072)]error =3D 5 =0Ag_vfs_done():ad0s4h[WRITE(offset=3D34111488= , length=3D131072)]error =3D 5=0A=A0g_vfs_done():ad0s4h[WRITE(offset=3D3424= 2560, length=3D131072)]error =3D 5 =0Ag_vfs_done():ad0s4h[WRITE(offset=3D34= 373632, length=3D131072)]error =3D 5 =0A=A0=0Aad0: 1882MB at ata0-master PIO4=0Aatapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x8= 03013ff at device 31.1 on pci0=0Aata0: on atapci0=0Aata1: <= ATA channel 1> on atapci0=0Aatapci1: por= t 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq= 15 at device 31.2 on pci0=0Aata2: on atapci1=0Aata3: on atapci1ad0s4h is basically a r/w ufs partition on the box whe= re almost anything that needs to be written goes.=0Atrace=0ATracing pid 110= 1 tid 100043 td 0x656d8460=0Akdb_enter(608cc388,6246,656d8460,64ba1400,6095= d580,...) at kdb_enter+0x2b=0Asiointr1(64ba1400) at siointr1+0xf0=0Asiointr= (64ba1400) at siointr+0x38=0Aintr_execute_handler(6095d580,f0a4ab04,6,6095d= 580,f0a4aafc,...) at intr_execute_handler+0x61=0Aintr_execute_handlers(6095= d580,f0a4ab04,6,0,656d8460,...) at intr_execute_handlers+0x40=0Aatpic_handl= e_intr(4) at atpic_handle_intr+0x96=0AXatpic_intr4() at Xatpic_intr4+0x20= =0A--- interrupt, eip =3D 0x606044af, esp =3D 0xf0a4ab48, ebp =3D 0xf0a4ab5= c ---=0Alockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f=0Agetdirtybuf(e1456= 9a4,60a405e4,1) at getdirtybuf+0x2e2=0Aflush_deplist(68b30850,1,f0a4abb8) a= t flush_deplist+0x30=0Aflush_inodedep_deps(656fa28c,1f235) at flush_inodede= p_deps+0xcf=0Asoftdep_sync_metadata(65964618) at softdep_sync_metadata+0x61= =0Affs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2=0Affs_fsync(f0a4ac74) a= t ffs_fsync+0x12=0AVOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38= =0Afsync(656d8460,f0a4acb4) at fsync+0x170=0Asyscall(805003b,806003b,5fbf00= 3b,8050000,288be450,...) at syscall+0x2ee=0AXint0x80_syscall() at Xint0x80_= syscall+0x1f=0A--More-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 05:13:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C82E10656D0 for ; Tue, 14 Feb 2012 05:13:02 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0685E8FC08 for ; Tue, 14 Feb 2012 05:13:01 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so10052608obc.13 for ; Mon, 13 Feb 2012 21:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to; bh=pThsUeb5HfWShF64lhSLnOkPCjcIJYQ66zW1edFxix8=; b=t+ZZNWA+HOoAF0Aqf0zC88uDWRWeLaAKQSkVHk9+Yzu0hE6W0faQofmdMoY/z2rJHq 19lK8StzkGwmoXBZUXodPOOiSeSbLrD7MeKWise3kvL5JkRACM7mSB9YcB7D/Ll1KD6x 26sX46g/LMGmqqVWRdCgUu2nE4fp0K7IUV2os= Received: by 10.50.6.194 with SMTP id d2mr31774427iga.24.1329196381289; Mon, 13 Feb 2012 21:13:01 -0800 (PST) Received: from DataIX.net (adsl-99-181-131-91.dsl.klmzmi.sbcglobal.net. [99.181.131.91]) by mx.google.com with ESMTPS id h9sm32376846ibh.11.2012.02.13.21.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 21:13:00 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1E5Cu82064461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 00:12:56 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1E5CtPw064212; Tue, 14 Feb 2012 00:12:55 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Tue, 14 Feb 2012 00:12:55 -0500 From: Jason Hellenthal To: john fleming Message-ID: <20120214051255.GA82468@DataIX.net> References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? 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, 14 Feb 2012 05:13:02 -0000 On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from checkpoint about being able to find the root cause of an issue. I have a large install base of IPSO checkpoint firewalls, which are based on FreeBSD 6.2. I've had 3 firewalls hang basically the same way, with something that looks like a filesystem issue or an issue with a CF card. >   > Does anyone happen to know of any bugs (i've been looking around) that could cause something like that? Granted, it could be a batch of bad CF cards, but its odd that i'm seeing the same thing on 3 different boxes and once rebooted they seem ok. >   > Also is it possible to get useful info form the atacontroller when things go south like this from the ddb prompt? >   > This is what shows in show msgbuf > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 >  g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 >   > ad0: 1882MB at ata0-master PIO4 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1ad0s4h is basically a r/w ufs partition on the box where almost anything that needs to be written goes. > trace > Tracing pid 1101 tid 100043 td 0x656d8460 > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > siointr1(64ba1400) at siointr1+0xf0 > siointr(64ba1400) at siointr+0x38 > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at intr_execute_handler+0x61 > intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at intr_execute_handlers+0x40 > atpic_handle_intr(4) at atpic_handle_intr+0x96 > Xatpic_intr4() at Xatpic_intr4+0x20 > --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- > lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f > getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 > flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 > flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf > softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 > ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 > ffs_fsync(f0a4ac74) at ffs_fsync+0x12 > VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 > fsync(656d8460,f0a4acb4) at fsync+0x170 > syscall(805003b,806003b,5fbf003b,8050000,288be450,...) at syscall+0x2ee > Xint0x80_syscall() at Xint0x80_syscall+0x1f This looks to be a problem with softupdates and CF cards. Can you get this to repeat on a brand new (good) card ? -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 05:18:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74893106566B for ; Tue, 14 Feb 2012 05:18:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 55D948FC13 for ; Tue, 14 Feb 2012 05:18:29 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id Zh6D1i0011Y3wxoA3hJV5F; Tue, 14 Feb 2012 05:18:29 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id ZhJU1i0071t3BNj8bhJU9E; Tue, 14 Feb 2012 05:18:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 38971102C1E; Mon, 13 Feb 2012 21:18:28 -0800 (PST) Date: Mon, 13 Feb 2012 21:18:28 -0800 From: Jeremy Chadwick To: john fleming Message-ID: <20120214051828.GA89777@icarus.home.lan> References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? 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, 14 Feb 2012 05:18:29 -0000 On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from checkpoint about being able to find the root cause of an issue. I have a large install base of IPSO checkpoint firewalls, which are based on FreeBSD 6.2. I've had 3 firewalls hang basically the same way, with something that looks like a filesystem issue or an?issue with a CF card. FreeBSD 6.2 was EOL'd in early-to-mid-2008. The ATA driver has changed significantly since then (present-day uses CAM). > Does anyone happen to know of any bugs (i've been looking around) that could cause something like that? Granted, it could be a batch of bad CF cards, but its odd that i'm seeing the same thing on 3 different boxes and once rebooted they seem ok. > ? > Also is it possible to get useful info form the atacontroller when things go south like this from the ddb prompt? Not particularly. What's shown below indicates that the driver had issued some form of ATA write command (there are multiple kinds per ATA specification), and either the underlying media (CF/disk) or controller stalled/locked up/took too long. I forget what the timeout value is in 6.2; I can't be bothered to remember such from 6 years ago. :-) > This is what shows in show msgbuf > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > ad0: timeout waiting to issue command > ad0: error issuing WRITE command > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 > ?g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 error 5 = EIO = Input/output error. But this isn't too big of a surprise given the timeouts you see prior. Are these CF cards brand new -- meaning, are they completely unused (having never had any writes done to them), or have they been in use a while? I'm betting they've been in use a while, and have probably been doing many writes over the years. Two things to note here: 1) The errors you've shown are only happening on writes, not reads. Of course if you omitted information then this isn't an accurate statement. 2) Timeouts are seen when issuing writes to some LBA regions. How full is the CF card, disk-space-wise? Not just ad0s4h, I'm talking about the entire card. How much space is roughly available? They're very small CF cards (1.8GByte roughly), and the less space available, the less effectiveness of wear levelling (and in some cases the slower the writes are). Reason I ask: given that these are CF cards, this smells of cards which are simply "worn down". CF cards have limited numbers of writes, and the card may be "freaking out" internally when attempting to write to some LBAs which map to CF sectors that are, in effect, "bad". The CF cards' ECC implementation may be buggy, or may simply be "spinning hard" for too long. You can read about this sort of behaviour on Wikipedia's CompactFlash article. You wouldn't be able to verify this with dd if=/dev/ad0, because those are read operations. You could zero the media (dd if=/dev/zero of=/dev/ad0) as a form of verification if you wanted. Do you happen to know if these CF cards support SMART? If so, installing smartmontools (version 5.42 or newer please) and providing output from "smartctl -a /dev/ad0" may be helpful to me, but I make no guarantees anything of use will be shown there. Overall my advice would be to replace the CF cards, especially if they have been in use for a long while. It really doesn't matter to me that it's happening on 3 machines (honest), especially if these are 6.2 machines with CF cards that have been in use for years. We're lucky to get 2 years out of our CF cards on our Juniper M120/320s before they start spitting I/O errors. Pick larger CF cards as well; more space = more room for effective wear levelling. > ? > ad0: 1882MB at ata0-master PIO4 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1ad0s4h is basically a r/w ufs partition on the box where almost anything that needs to be written goes. > trace > Tracing pid 1101 tid 100043 td 0x656d8460 > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > siointr1(64ba1400) at siointr1+0xf0 > siointr(64ba1400) at siointr+0x38 > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at intr_execute_handler+0x61 > intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at intr_execute_handlers+0x40 > atpic_handle_intr(4) at atpic_handle_intr+0x96 > Xatpic_intr4() at Xatpic_intr4+0x20 > --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- > lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f > getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 > flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 > flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf > softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 > ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 > ffs_fsync(f0a4ac74) at ffs_fsync+0x12 > VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 > fsync(656d8460,f0a4acb4) at fsync+0x170 > syscall(805003b,806003b,5fbf003b,8050000,288be450,...) at syscall+0x2ee > Xint0x80_syscall() at Xint0x80_syscall+0x1f -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 05:21:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77E77106566C for ; Tue, 14 Feb 2012 05:21:50 +0000 (UTC) (envelope-from jflemingeds@yahoo.com) Received: from nm1-vm0.bullet.mail.sp2.yahoo.com (nm1-vm0.bullet.mail.sp2.yahoo.com [98.139.91.202]) by mx1.freebsd.org (Postfix) with SMTP id 478518FC16 for ; Tue, 14 Feb 2012 05:21:50 +0000 (UTC) Received: from [98.139.91.67] by nm1.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 05:21:49 -0000 Received: from [98.139.91.22] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 05:20:49 -0000 Received: from [127.0.0.1] by omp1022.mail.sp2.yahoo.com with NNFMP; 14 Feb 2012 05:20:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 798644.64784.bm@omp1022.mail.sp2.yahoo.com Received: (qmail 92486 invoked by uid 60001); 14 Feb 2012 05:20:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1329196849; bh=DnmISk6qPX5jTJXLxi2i+tCjeKhYR4cWNwlReezNTDs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ii6hATKZD+OFjYZe4z7lSAGKXyVt0ZAwmCF+HIQR36jdmUYc3/LPv+Q14dzDWGo8DJDVrnRbS+t3gRwB+XgqMu1suAIu1t0RV+duRbBPAACk4rl+6AN/RhmuhRcD5yZv3m7CG8FnHa34chhxtrEVqUo7XWPCUg63VpLYMOTOHQI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1bq8W9YOsIAApdHCVpxQdOWnQ/nj1hIusY6ymENdTYmSYLFnQGqN3bjjlKr0f+g3k8ZkGliohDBY1qFSKzwhLneEx4MQ9KS9KjI+qGBjutS+RUCP4s5jKZv66ekpqrPYPIhWxLJoVXnXXgegmeiDCEMlB/Rn2Ezqdm+87zSoGKg=; X-YMail-OSG: 92mbQasVM1myRuLtMFhaoPvjeeoby24usceE.tkq_cTMJ06 uG8PngZkW_5XEw_aui7bNDpGiUJvsDKSI2YzwRJSyYKpPkakGzTYIVVYVo6H T0sK6wLlDVXS24KogMzB8077gOzVhDvWlkVKc2toI9u7lH5JyszZywpzHypP a8QC1a4g17sP2aOFa7UgvzUefttWEePnfQr2jdvPPcxVC3ef1rY6XlaPUc3j IzfnuRBoMJ1YEqNesDv6cnPMhn4BppKjMB3nUXMI8IRViX0ojM8cHe4IFhLH wDVl68ZfV89yjL11uiK4XbTMWDu1NKEem4zlXaDy.zEMgFUOAPTnvWiI9BRe g86i6cTFqZZEBwQLR1X_Dhyn7G4sy5QhLP4E4UP_r7hY6h_4o9_jJVZMY0F_ F9R1zv_YJsEo4Srq4O6nZMetSvC9l4HvflOnGW.uecZ2P0ikD.k_OPXkUQ6w DYicZ Received: from [99.8.58.116] by web111721.mail.gq1.yahoo.com via HTTP; Mon, 13 Feb 2012 21:20:49 PST X-Mailer: YahooMailWebService/0.8.116.338427 References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> <20120214051255.GA82468@DataIX.net> Message-ID: <1329196849.78744.YahooMailNeo@web111721.mail.gq1.yahoo.com> Date: Mon, 13 Feb 2012 21:20:49 -0800 (PST) From: john fleming To: Jason Hellenthal In-Reply-To: <20120214051255.GA82468@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john fleming List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 05:21:50 -0000 I can't seem to replicate it at all. I've seen it happen on 3 different IPS= O boxes so far. The last machine it happened on is maybe 4 months old. Basi= cally on all 3 machines once rebooted the problem doesn't come back. Checkp= oint so far is telling me its a known issue and they don't know what the fi= x is.=0A=A0=0AWhat makes you think its softupdates? Would that cause the wr= ite timeout as well? Just not sure what level of this is failing, filesyste= m, flash or ata controller.=0A=A0=0A=A0=0Athanks for the reply! From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 05:38:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1665B106566B for ; Tue, 14 Feb 2012 05:38:08 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 947038FC0C for ; Tue, 14 Feb 2012 05:38:07 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so6123655wib.13 for ; Mon, 13 Feb 2012 21:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rmm5RMQb/gFwdoT37Npz1imaeuQxQD2Tyde7mcY22BE=; b=Y3oWZiSkNM8fpRDRqLrVA8iJUvmrwHd7tFBc88hl62cqNasAfsN8kmONFryJhoJnx5 eLfm/psX+U2dy0EX2DFs/BpinVpSju49titmE7A7oxu+YT72FaNeUNvA6F/MbpWxoGXI sKt94ickY7urKh1obLx3Bx0/wcKjT7ArsY2iU= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr1358359wif.10.1329197886426; Mon, 13 Feb 2012 21:38:06 -0800 (PST) Received: by 10.223.62.70 with HTTP; Mon, 13 Feb 2012 21:38:06 -0800 (PST) In-Reply-To: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> Date: Mon, 13 Feb 2012 23:38:06 -0600 Message-ID: From: Adam Vande More To: john fleming Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? 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, 14 Feb 2012 05:38:08 -0000 On Mon, Feb 13, 2012 at 10:43 PM, john fleming wrote: > Just thought i would post over here as i'm not getting a warm fuzzy from > checkpoint about being able to find the root cause of an issue. I have a > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > 6.2. I've had 3 firewalls hang basically the same way, with something that > looks like a filesystem issue or an issue with a CF card. > There was a thread just the other day mentioned lockup problems with DMA and CF cards. Disabling DMA or reducing the mode helped. Not sure if applicable to that old of FreeBSD version. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 07:40:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C3E9106566B for ; Tue, 14 Feb 2012 07:40:55 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 18F028FC15 for ; Tue, 14 Feb 2012 07:40:54 +0000 (UTC) Received: by iaeo4 with SMTP id o4so6805140iae.13 for ; Mon, 13 Feb 2012 23:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=n6jkMHZGbfCoo8nNvDp2Cz5+3pO24ddYvshImkJ9Lec=; b=b6Atvb4/eu2XJO1DkNsxnLp22CvtgWC/V+qAsyvW/S8bT4fmG7vNsqXTL0DHpiCDKR fl4beb0DVcpqVMEuE01moWXSlWv/Yt47ae5eVi3T9OKNGq4gWEGQKj+TqeBgADqFOoUR cGelULuXxpS2nx1m5rGEYqjbxW/Y/OBEvX8ms= Received: by 10.50.155.133 with SMTP id vw5mr32319682igb.1.1329205254461; Mon, 13 Feb 2012 23:40:54 -0800 (PST) Received: from DataIX.net ([99.181.131.91]) by mx.google.com with ESMTPS id wn7sm18415591igc.0.2012.02.13.23.40.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 23:40:53 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1E7eowt012420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 02:40:50 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1E7emJW011412; Tue, 14 Feb 2012 02:40:48 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Tue, 14 Feb 2012 02:40:48 -0500 From: Jason Hellenthal To: Adam Vande More Message-ID: <20120214074048.GA2385@DataIX.net> References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: john fleming , "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? 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, 14 Feb 2012 07:40:55 -0000 On Mon, Feb 13, 2012 at 11:38:06PM -0600, Adam Vande More wrote: > On Mon, Feb 13, 2012 at 10:43 PM, john fleming wrote: > > > Just thought i would post over here as i'm not getting a warm fuzzy from > > checkpoint about being able to find the root cause of an issue. I have a > > large install base of IPSO checkpoint firewalls, which are based on FreeBSD > > 6.2. I've had 3 firewalls hang basically the same way, with something that > > looks like a filesystem issue or an issue with a CF card. > > > > There was a thread just the other day mentioned lockup problems with DMA > and CF cards. Disabling DMA or reducing the mode helped. Not sure if > applicable to that old of FreeBSD version. > I seen that thread. Doubt it is related to his issue since he is running 6.2. And besides his dmesg proves otherwise. ad0: 1882MB at ata0-master PIO4 -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 07:47:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D175F106566B; Tue, 14 Feb 2012 07:47:06 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76AE38FC12; Tue, 14 Feb 2012 07:47:06 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so10243439obc.13 for ; Mon, 13 Feb 2012 23:47:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=wvJYBKjVxu907WbRybFc34lU5cX0mOxCwcA/BLBWDQ0=; b=fbodwfs3Ki7dgE2bT7Rm4+OqKK1Zq9y/ngK1oNxRqruk3S7orn/SMYkKm2Ww6gTKma OEzVvnTI9yi0tOB6QnEkZLGIefBl1sXS/68tk1bPWL9N1Y0OlvgW7scmG5RtwrEw+oli NCPPty5/ped8p4JT1bgooJLprIcA9cVvD2O5g= Received: by 10.50.11.129 with SMTP id q1mr32183276igb.23.1329205625769; Mon, 13 Feb 2012 23:47:05 -0800 (PST) Received: from DataIX.net ([99.181.131.91]) by mx.google.com with ESMTPS id d15sm33250248ibf.7.2012.02.13.23.47.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 23:47:04 -0800 (PST) Sender: Jason Hellenthal Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1E7l1d0056969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 02:47:01 -0500 (EST) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1E7l14j056585; Tue, 14 Feb 2012 02:47:01 -0500 (EST) (envelope-from jhell@DataIX.net) Date: Tue, 14 Feb 2012 02:47:00 -0500 From: Jason Hellenthal To: stable@freebsd.org Message-ID: <20120214074700.GA89794@DataIX.net> References: <20120211065857.GA66606@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120211065857.GA66606@DataIX.net> Cc: bapt@freebsd.org, dougb@freebsd.org Subject: Re: dhclient script adjustments 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, 14 Feb 2012 07:47:06 -0000 Anyone ? On Sat, Feb 11, 2012 at 01:58:57AM -0500, Jason Hellenthal wrote: > > After recent merges to stable/8 I am now seeing errors on bootup of > the following for three interfaces that will never see the light of > DHCP. ? > > /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface > > Can someone please revert these changes or some other action. ? > > -- > ;s =; -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 08:10:59 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A42B4106564A; Tue, 14 Feb 2012 08:10:59 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 32C648FC14; Tue, 14 Feb 2012 08:10:58 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4218C.dip.t-dialin.net [79.196.33.140]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B55808448CD; Tue, 14 Feb 2012 09:10:44 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id E2D1E2FDD; Tue, 14 Feb 2012 09:10:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329207042; bh=r2Rj77zamOYbteSQ848/66GKuI/OEzv2OVpv6f71/0A=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=VeeUIck29fps995DUSYtXbb4FR7ZCz5YN4yNeeFLew/Ml+UPQTBHbOOimOSBhrtE/ jL60nT2i4jbMC2UGCSTtRtucSJK+pHgE7WXWATREOP5w4vxgCT487NCD/nmtV8TZZZ S9aDifyA/wgr/sxSsnln6nVnfkYImvSk+UlL2feM4zZe4rP2ELTvp96KcLokcZrPVJ TSe5DXFxFIGR3duNEFK0+8qKIPbuyyXYsYz28YkpwQc0FLBMg/YOM5n0XdeJZuTaDM kN4JO8R41i1rv6Emo+5NT03QnVYkUlVC2pYz5hkeZefpAfvtclkSET30UMqPkUzBu6 XZpKMQUTFkWvg== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1E8Ae5h005161; Tue, 14 Feb 2012 09:10:40 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 14 Feb 2012 09:10:40 +0100 Date: Tue, 14 Feb 2012 09:10:40 +0100 Message-ID: <20120214091040.Horde.Lwy6S5jmRSRPOhcAha9RNLA@webmail.leidinger.net> From: Alexander Leidinger To: Volodymyr Kostyrko References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120211124041.GF32360@graf.pompo.net> <20120211183308.00007579@unknown> <4f379cde.l6lDd9rduQzDU/xx%perryh@pluto.rain.com> <20120212120633.0000302d@unknown> <4f38e34a.lZtNaNETBImp/XiD%perryh@pluto.rain.com> <20120213120514.Horde.LMNbOJjmRSRPOO5qpDYJzWA@webmail.leidinger.net> <4F392FE1.5070901@gmail.com> In-Reply-To: <4F392FE1.5070901@gmail.com> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B55808448CD.A2436 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.698, required 6, autolearn=disabled, AWL -0.67, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329811845.66728@gIzJEP6ypPwluGqq48ActA X-EBL-Spam-Status: No Cc: thierry@freebsd.org, stable@freebsd.org, perryh@pluto.rain.com Subject: Re: Reducing the need to compile a custom kernel 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, 14 Feb 2012 08:10:59 -0000 Quoting Volodymyr Kostyrko (from Mon, 13 Feb 2012 17:44:33 +0200): > Alexander Leidinger wrote: >> Feasible: depend upon your definition of "feasible". You would have to >> add all keymaps statically into the kernel. No idea which parts exactly >> we talk about, but: >> ---snip--- >> % du -h /usr/share/syscons/ >> 40k /usr/share/syscons/scrnmaps >> 570k /usr/share/syscons/fonts >> 1.1M /usr/share/syscons/keymaps >> 1.8M /usr/share/syscons/ >> ---snip--- >> >> I wouldn't mind for 40k, but 1.8M looks more like the value to calculate >> with. Anyway, this is out of the scope of the original question. > > Correct me if I'm wrong but zfs already fetches plain file > /boot/zfs/zpool.cache on load. Can't this be: > > 1. Postponed to later processing. > 2. After filesystems are mounted the keymap is loaded. This is already the case. you can set the keymap in rc.conf. > Or even: > > 1. Put all viable files on the / partition. > 2. Select and load correct one before kernel is fired. This is not the same as compiling it in the kernel. Think about a problem where parts of your FS are corrupt / damaged / overwritten with nonsense. Yes you can minimize the problem by loading it more early, but having it in the kernel removes the keyboard problem completely. Bye, Alexander. -- A lost ounce of gold may be found, a lost moment of time never. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 08:22:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F38FD1065672 for ; Tue, 14 Feb 2012 08:22:27 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id AB3CE8FC12 for ; Tue, 14 Feb 2012 08:22:27 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1E8MOrP095392 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 14 Feb 2012 00:22:26 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3A1A19.7010803@freebsd.org> Date: Tue, 14 Feb 2012 00:23:53 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: freebsd 9-stable TOP problem from around Jan 10 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, 14 Feb 2012 08:22:28 -0000 Has anyone else seen a problem with top -H -S? after a short while the screen gets more and more corrupted.. hitting ^L or turning off S & H modes helps .. for a while. If this is a known fixed problem, let me know but I need to co-ordinate with others to upgrade the machine in question. Julian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 08:26:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEDD5106564A for ; Tue, 14 Feb 2012 08:26:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6848FC13 for ; Tue, 14 Feb 2012 08:26:02 +0000 (UTC) Received: by daec6 with SMTP id c6so6252797dae.13 for ; Tue, 14 Feb 2012 00:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=sELMP0YWcWGbeMZai4vQzaiVoy+KMO64kcX9aoJgRXw=; b=IJ1Fyc5G1jNOrnW0b3ffz+VQXk7bovPuRB4SJzkqaUN15lCPj82B8/RpdpD5XK9Zue vudTGi/dOFdNR8Q6hGyPnudf+4A/GzYBVoAyWiyXNc10DoxyLS1Hl07vP9iE91YIo32s 3XvaclVLJtDRKp2uxeiC0tdaaLhFa/JcldPOU= Received: by 10.68.241.70 with SMTP id wg6mr56017899pbc.6.1329206164316; Mon, 13 Feb 2012 23:56:04 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id e10sm1746715pbv.0.2012.02.13.23.56.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 23:56:02 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 14 Feb 2012 16:56:00 -0800 From: YongHyeon PYUN Date: Tue, 14 Feb 2012 16:56:00 -0800 To: "Michael L. Squires" Message-ID: <20120215005600.GB1336@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Regression in 8.2-STABLE bge code (from 7.4-STABLE) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:26:02 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 28, 2012 at 09:24:53PM -0500, Michael L. Squires wrote: Sorry for late reply. Had been busy due to relocation. > There is a bug in the Tyan S4881/S4882 PCI-X bridges that was fixed with a > patch in 7.x (thank you very much). This patch is not present in the > 8.2-STABLE code and the symptoms (watchdog timeouts) have recurred. > Hmm, I thought the mailbox reordering bug was avoided by limiting DMA address space to 32bits but it seems it was not right workaround for AMD 8131 PCI-X Bridge. > The watchdog timeouts do not appear to be present after I switched to an > Intel gigabit PCI-X card. > > I did a brute-force patch of the 8.2-STABLE bge code using the patches for > 7.4-STABLE; the resulting code compiled and, other than odd behavior at > startup, seems to be working normally. > > This is using FreeBSD 8.2-STABLE amd64; I don't know what happens with > i386. > > Given the age of the boards it may be easier if I just continue using the > Intel gigabit card but am happy to test anything that comes my way. > Try attached patch and let me know how it goes. I didn't enable 64bit DMA addressing though. I think the AMD-8131 PCI-X bridge needs both workarounds. > Thanks, > > Mike Squires > mikes at siralan.org --azLHFNyN32YCQGCU Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="bge.mbox.reorder.diff" Index: sys/dev/bge/if_bgereg.h =================================================================== --- sys/dev/bge/if_bgereg.h (revision 231621) +++ sys/dev/bge/if_bgereg.h (working copy) @@ -2828,6 +2828,7 @@ #define BGE_FLAG_RX_ALIGNBUG 0x04000000 #define BGE_FLAG_SHORT_DMA_BUG 0x08000000 #define BGE_FLAG_4K_RDMA_BUG 0x10000000 +#define BGE_FLAG_MBOX_REORDER 0x20000000 uint32_t bge_phy_flags; #define BGE_PHY_NO_WIRESPEED 0x00000001 #define BGE_PHY_ADC_BUG 0x00000002 Index: sys/dev/bge/if_bge.c =================================================================== --- sys/dev/bge/if_bge.c (revision 231621) +++ sys/dev/bge/if_bge.c (working copy) @@ -380,6 +380,8 @@ static int bge_dma_ring_alloc(struct bge_softc *, bus_size_t, bus_size_t, bus_dma_tag_t *, uint8_t **, bus_dmamap_t *, bus_addr_t *, const char *); +static int bge_mbox_reorder(struct bge_softc *); + static int bge_get_eaddr_fw(struct bge_softc *sc, uint8_t ether_addr[]); static int bge_get_eaddr_mem(struct bge_softc *, uint8_t[]); static int bge_get_eaddr_nvram(struct bge_softc *, uint8_t[]); @@ -635,6 +637,8 @@ off += BGE_LPMBX_IRQ0_HI - BGE_MBX_IRQ0_HI; CSR_WRITE_4(sc, off, val); + if ((sc->bge_flags & BGE_FLAG_MBOX_REORDER) != 0) + CSR_READ_4(sc, off); } /* @@ -2609,8 +2613,8 @@ * XXX * watchdog timeout issue was observed on BCM5704 which * lives behind PCI-X bridge(e.g AMD 8131 PCI-X bridge). - * Limiting DMA address space to 32bits seems to address - * it. + * Both limiting DMA address space to 32bits and flushing + * mailbox write seem to address the issue. */ if (sc->bge_flags & BGE_FLAG_PCIX) lowaddr = BUS_SPACE_MAXADDR_32BIT; @@ -2775,6 +2779,42 @@ } static int +bge_mbox_reorder(struct bge_softc *sc) +{ + /* Lists of PCI bridges that are known to reorder mailbox writes. */ + static const struct mbox_reorder { + const uint16_t vendor; + const uint16_t device; + const char *desc; + } const mbox_reorder_lists[] = { + { 0x1022, 0x7450, "AMD-8131 PCI-X Bridge" }, + }; + devclass_t pcib; + device_t dev; + int i, count, unit; + + count = sizeof(mbox_reorder_lists) / sizeof(mbox_reorder_lists[0]); + pcib = devclass_find("pcib"); + for (unit = 0; unit < devclass_get_maxunit(pcib); unit++) { + dev = devclass_get_device(pcib, unit); + if (dev == NULL) + continue; + for (i = 0; i < count; i++) { + if (pci_get_vendor(dev) == + mbox_reorder_lists[i].vendor && + pci_get_device(dev) == + mbox_reorder_lists[i].device) { + device_printf(sc->bge_dev, + "enabling MBOX workaround for %s\n", + mbox_reorder_lists[i].desc); + return (1); + } + } + } + return (0); +} + +static int bge_attach(device_t dev) { struct ifnet *ifp; @@ -3094,6 +3134,14 @@ if (BGE_IS_5714_FAMILY(sc) && (sc->bge_flags & BGE_FLAG_PCIX)) sc->bge_flags |= BGE_FLAG_40BIT_BUG; /* + * Some PCI-X bridges are known to trigger write reordering to + * the mailbox registers. Typical phenomena is watchdog timeouts + * caused by out-of-order TX completions. Enable workaround for + * PCI-X devices that live behind these bridges. + */ + if (sc->bge_flags & BGE_FLAG_PCIX && bge_mbox_reorder(sc) != 0) + sc->bge_flags |= BGE_FLAG_MBOX_REORDER; + /* * Allocate the interrupt, using MSI if possible. These devices * support 8 MSI messages, but only the first one is used in * normal operation. --azLHFNyN32YCQGCU-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 09:19:15 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2872106564A for ; Tue, 14 Feb 2012 09:19:15 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id BC59F8FC0A for ; Tue, 14 Feb 2012 09:19:12 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id D162A39844; Tue, 14 Feb 2012 10:19:09 +0100 (CET) Date: Tue, 14 Feb 2012 10:19:09 +0100 From: Victor Balada Diaz To: stable@FreeBSD.org Message-ID: <20120214091909.GP2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 09:19:15 -0000 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: ahcich0: Timeout on slot 8 ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=18ms ahcich0: AHCI reset done: device found (ada0:ahcich0:0:0:0): Request requeued (ada0:ahcich0:0:0:0): Retrying command (ada0:ahcich0:0:0:0): Command timed out (ada0:ahcich0:0:0:0): Retrying command ahcich0: Timeout on slot 8 ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=84ms ahcich0: AHCI reset done: device found (ada0:ahcich0:0:0:0): Request requeued (ada0:ahcich0:0:0:0): Retrying command (ada0:ahcich0:0:0:0): Command timed out (ada0:ahcich0:0:0:0): Retrying command (ada0:ahcich0:0:0:0): Request requeued [...] If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we got the above error. If we use both disks in gmirror with old ata driver, no problems. Attached are both dmesgs with ata driver and with ahci. Any ideas on what could be wrong? Thanks a lot. Regards. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Description: dmesg-ata.txt Content-Disposition: attachment; filename="dmesg-ata.txt" Copyright (c) 1992-2010 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.1-RELEASE-p5 #0: Tue Sep 27 16:49:00 UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80ead000. Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0xffffffff80ead230. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80ead8e0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3086610956 Hz CPU: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz (3086.61-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 12884901888 (12288 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000ee4000 - 0x00000000bf77ffff, 3196698624 bytes (780444 pages) 0x0000000100000000 - 0x00000003278effff, 9253617664 bytes (2259184 pages) avail memory = 12388929536 (11815 MB) ACPI APIC Table: <7522MS A7522800> INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x010000-0x01ffff at 0xffffff800005b000 x86bios: EBDA 0x09e000-0x09ffff at 0xffffff000009e000 x86bios: ROM 0x0a0000-0x0effff at 0xffffff00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 5 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 6 APIC: CPU 4 has ACPI ID 3 APIC: CPU 5 has ACPI ID 7 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 8 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0xfa590 00014 (v0 ACPIAM) ACPI: RSDT 0xbf780000 0003C (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: FACP 0xbf780200 00084 (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: DSDT 0xbf780480 06E82 (v1 A7522 A7522800 00000800 INTL 20051117) ACPI: FACS 0xbf78e000 00040 ACPI: APIC 0xbf780390 000AC (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: MCFG 0xbf780440 0003C (v1 7522MS OEMMCFG 20110319 MSFT 00000097) ACPI: OEMB 0xbf78e040 0007A (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: HPET 0xbf78a480 00038 (v1 7522MS OEMHPET 20110319 MSFT 00000097) ACPI: SSDT 0xbf790980 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: <7522MS A7522800> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000026000 pa 0x4000 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed ACPI timer: 1/0 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xBB, should be 0xBA (20100331/tbutils-354) ACPI: SSDT 0xbf78e0c0 0223C (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf790300 00678 (v1 PmRef P001Cst 00003001 INTL 20051117) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 4 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3405, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbbfe000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfbbfe000 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbbfc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfbbfc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfbbfa000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 map[10]: type Memory, range 64, base 0xfbbf9c00, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfbc00000-0xfbcfffff pcib2: prefetched decode 0xd0000000-0xdfffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x68f9, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib2: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfbce0000, size 17, enabled pcib2: requested memory range 0xfbce0000-0xfbcfffff: good map[20]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib2: requested I/O range 0xc000-0xc0ff: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0xaa68, revid=0x00 domain=0, bus=2, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfbcbc000, size 14, enabled pcib2: requested memory range 0xfbcbc000-0xfbcbffff: good pcib2: matched entry for 2.0.INTB pcib2: slot 0 INTB hardwired to IRQ 17 vgapci0: port 0xc000-0xc0ff mem 0xd0000000-0xdfffffff,0xfbce0000-0xfbcfffff irq 16 at device 0.0 on pci2 pci2: at device 0.1 (no driver attached) pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfbbfe000-0xfbbfe3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib4: irq 17 at device 28.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 17 at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 6 pcib5: subordinate bus 6 pcib5: I/O decode 0xe000-0xefff pcib5: memory decode 0xfbe00000-0xfbefffff pcib5: prefetched decode 0xfaf00000-0xfaffffff pci6: on pcib5 pci6: domain=0, physical bus=6 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=6, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib5: requested I/O range 0xe800-0xe8ff: in range map[18]: type Memory, range 64, base 0xfbeff000, size 12, enabled pcib5: requested memory range 0xfbeff000-0xfbefffff: good map[20]: type Prefetchable Memory, range 64, base 0xfaff0000, size 16, enabled pcib5: requested memory range 0xfaff0000-0xfaffffff: good pcib5: matched entry for 6.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xfaff0000-0xfaffffff irq 16 at device 0.0 on pci6 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfbeff000 re0: MSI count : 1 re0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 53 re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 8c:89:a5:15:6b:de re0: [MPSAFE] re0: [FILTER] uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfbbfc000-0xfbbfc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 7 pcib6: subordinate bus 7 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci7: on pcib6 pci7: domain=0, physical bus=7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfbbfa000-0xfbbfa7ff irq 19 at device 31.2 on pci0 atapci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xa480 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfbbfa000 atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported atapci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000123 ata2: ready wait time=50ms ata2: software reset port 0... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect timeout status=00000000 ata3: AHCI reset done: phy reset found no device ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: AHCI reset... ata4: hardware reset ... ata4: SATA connect timeout status=00000000 ata4: AHCI reset done: phy reset found no device ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect time=0ms status=00000123 ata5: ready wait time=138ms ata5: software reset port 0... ata5: ready wait time=0ms ata5: SIGNATURE: 00000101 ata5: AHCI reset done: devices=00000001 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci0 ata6: AHCI reset... ata6: hardware reset ... ata6: SATA connect timeout status=00000000 ata6: AHCI reset done: phy reset found no device ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci0 ata7: AHCI reset... ata7: hardware reset ... ata7: SATA connect timeout status=00000000 ata7: AHCI reset done: phy reset found no device ata7: [MPSAFE] ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 55 uart0: [FILTER] uart0: fast interrupt atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ ex_isa_identify() ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 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 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est0: Invalid id16 (set, cur) = (22, 23) est0: Can't check freq 2933, it may be invalid est0: Invalid id16 (set, cur) = (21, 23) est0: Can't check freq 2800, it may be invalid est0: Invalid id16 (set, cur) = (20, 23) est0: Can't check freq 2667, it may be invalid est0: Invalid id16 (set, cur) = (19, 23) est0: Can't check freq 2533, it may be invalid est0: Invalid id16 (set, cur) = (18, 23) est0: Can't check freq 2400, it may be invalid est0: Invalid id16 (set, cur) = (17, 23) est0: Can't check freq 2267, it may be invalid est0: Invalid id16 (set, cur) = (16, 23) est0: Can't check freq 2133, it may be invalid est0: Invalid id16 (set, cur) = (15, 23) est0: Can't check freq 2000, it may be invalid est0: Invalid id16 (set, cur) = (14, 23) est0: Can't check freq 1867, it may be invalid est0: Invalid id16 (set, cur) = (13, 23) est0: Can't check freq 1733, it may be invalid est0: Invalid id16 (set, cur) = (12, 23) est0: Can't check freq 1600, it may be invalid p4tcc0: on cpu0 est1: on cpu1 est1: Invalid id16 (set, cur) = (22, 23) est1: Can't check freq 2933, it may be invalid est1: Invalid id16 (set, cur) = (21, 23) est1: Can't check freq 2800, it may be invalid est1: Invalid id16 (set, cur) = (20, 23) est1: Can't check freq 2667, it may be invalid est1: Invalid id16 (set, cur) = (19, 23) est1: Can't check freq 2533, it may be invalid est1: Invalid id16 (set, cur) = (18, 23) est1: Can't check freq 2400, it may be invalid est1: Invalid id16 (set, cur) = (17, 23) est1: Can't check freq 2267, it may be invalid est1: Invalid id16 (set, cur) = (16, 23) est1: Can't check freq 2133, it may be invalid est1: Invalid id16 (set, cur) = (15, 23) est1: Can't check freq 2000, it may be invalid est1: Invalid id16 (set, cur) = (14, 23) est1: Can't check freq 1867, it may be invalid est1: Invalid id16 (set, cur) = (13, 23) est1: Can't check freq 1733, it may be invalid est1: Invalid id16 (set, cur) = (12, 23) est1: Can't check freq 1600, it may be invalid p4tcc1: on cpu1 est2: on cpu2 est2: Invalid id16 (set, cur) = (22, 23) est2: Can't check freq 2933, it may be invalid est2: Invalid id16 (set, cur) = (21, 23) est2: Can't check freq 2800, it may be invalid est2: Invalid id16 (set, cur) = (20, 23) est2: Can't check freq 2667, it may be invalid est2: Invalid id16 (set, cur) = (19, 23) est2: Can't check freq 2533, it may be invalid est2: Invalid id16 (set, cur) = (18, 23) est2: Can't check freq 2400, it may be invalid est2: Invalid id16 (set, cur) = (17, 23) est2: Can't check freq 2267, it may be invalid est2: Invalid id16 (set, cur) = (16, 23) est2: Can't check freq 2133, it may be invalid est2: Invalid id16 (set, cur) = (15, 23) est2: Can't check freq 2000, it may be invalid est2: Invalid id16 (set, cur) = (14, 23) est2: Can't check freq 1867, it may be invalid est2: Invalid id16 (set, cur) = (13, 23) est2: Can't check freq 1733, it may be invalid est2: Invalid id16 (set, cur) = (12, 23) est2: Can't check freq 1600, it may be invalid p4tcc2: on cpu2 est3: on cpu3 est3: Invalid id16 (set, cur) = (22, 23) est3: Can't check freq 2933, it may be invalid est3: Invalid id16 (set, cur) = (21, 23) est3: Can't check freq 2800, it may be invalid est3: Invalid id16 (set, cur) = (20, 23) est3: Can't check freq 2667, it may be invalid est3: Invalid id16 (set, cur) = (19, 23) est3: Can't check freq 2533, it may be invalid est3: Invalid id16 (set, cur) = (18, 23) est3: Can't check freq 2400, it may be invalid est3: Invalid id16 (set, cur) = (17, 23) est3: Can't check freq 2267, it may be invalid est3: Invalid id16 (set, cur) = (16, 23) est3: Can't check freq 2133, it may be invalid est3: Invalid id16 (set, cur) = (15, 23) est3: Can't check freq 2000, it may be invalid est3: Invalid id16 (set, cur) = (14, 23) est3: Can't check freq 1867, it may be invalid est3: Invalid id16 (set, cur) = (13, 23) est3: Can't check freq 1733, it may be invalid est3: Invalid id16 (set, cur) = (12, 23) est3: Can't check freq 1600, it may be invalid p4tcc3: on cpu3 est4: on cpu4 est4: Invalid id16 (set, cur) = (22, 23) est4: Can't check freq 2933, it may be invalid est4: Invalid id16 (set, cur) = (21, 23) est4: Can't check freq 2800, it may be invalid est4: Invalid id16 (set, cur) = (20, 23) est4: Can't check freq 2667, it may be invalid est4: Invalid id16 (set, cur) = (19, 23) est4: Can't check freq 2533, it may be invalid est4: Invalid id16 (set, cur) = (18, 23) est4: Can't check freq 2400, it may be invalid est4: Invalid id16 (set, cur) = (17, 23) est4: Can't check freq 2267, it may be invalid est4: Invalid id16 (set, cur) = (16, 23) est4: Can't check freq 2133, it may be invalid est4: Invalid id16 (set, cur) = (15, 23) est4: Can't check freq 2000, it may be invalid est4: Invalid id16 (set, cur) = (14, 23) est4: Can't check freq 1867, it may be invalid est4: Invalid id16 (set, cur) = (13, 23) est4: Can't check freq 1733, it may be invalid est4: Invalid id16 (set, cur) = (12, 23) est4: Can't check freq 1600, it may be invalid p4tcc4: on cpu4 est5: on cpu5 est5: Invalid id16 (set, cur) = (22, 23) est5: Can't check freq 2933, it may be invalid est5: Invalid id16 (set, cur) = (21, 23) est5: Can't check freq 2800, it may be invalid est5: Invalid id16 (set, cur) = (20, 23) est5: Can't check freq 2667, it may be invalid est5: Invalid id16 (set, cur) = (19, 23) est5: Can't check freq 2533, it may be invalid est5: Invalid id16 (set, cur) = (18, 23) est5: Can't check freq 2400, it may be invalid est5: Invalid id16 (set, cur) = (17, 23) est5: Can't check freq 2267, it may be invalid est5: Invalid id16 (set, cur) = (16, 23) est5: Can't check freq 2133, it may be invalid est5: Invalid id16 (set, cur) = (15, 23) est5: Can't check freq 2000, it may be invalid est5: Invalid id16 (set, cur) = (14, 23) est5: Can't check freq 1867, it may be invalid est5: Invalid id16 (set, cur) = (13, 23) est5: Can't check freq 1733, it may be invalid est5: Invalid id16 (set, cur) = (12, 23) est5: Can't check freq 1600, it may be invalid p4tcc5: on cpu5 est6: on cpu6 est6: Invalid id16 (set, cur) = (22, 23) est6: Can't check freq 2933, it may be invalid est6: Invalid id16 (set, cur) = (21, 23) est6: Can't check freq 2800, it may be invalid est6: Invalid id16 (set, cur) = (20, 23) est6: Can't check freq 2667, it may be invalid est6: Invalid id16 (set, cur) = (19, 23) est6: Can't check freq 2533, it may be invalid est6: Invalid id16 (set, cur) = (18, 23) est6: Can't check freq 2400, it may be invalid est6: Invalid id16 (set, cur) = (17, 23) est6: Can't check freq 2267, it may be invalid est6: Invalid id16 (set, cur) = (16, 23) est6: Can't check freq 2133, it may be invalid est6: Invalid id16 (set, cur) = (15, 23) est6: Can't check freq 2000, it may be invalid est6: Invalid id16 (set, cur) = (14, 23) est6: Can't check freq 1867, it may be invalid est6: Invalid id16 (set, cur) = (13, 23) est6: Can't check freq 1733, it may be invalid est6: Invalid id16 (set, cur) = (12, 23) est6: Can't check freq 1600, it may be invalid p4tcc6: on cpu6 est7: on cpu7 est7: Invalid id16 (set, cur) = (22, 23) est7: Can't check freq 2933, it may be invalid est7: Invalid id16 (set, cur) = (21, 23) est7: Can't check freq 2800, it may be invalid est7: Invalid id16 (set, cur) = (20, 23) est7: Can't check freq 2667, it may be invalid est7: Invalid id16 (set, cur) = (19, 23) est7: Can't check freq 2533, it may be invalid est7: Invalid id16 (set, cur) = (18, 23) est7: Can't check freq 2400, it may be invalid est7: Invalid id16 (set, cur) = (17, 23) est7: Can't check freq 2267, it may be invalid est7: Invalid id16 (set, cur) = (16, 23) est7: Can't check freq 2133, it may be invalid est7: Invalid id16 (set, cur) = (15, 23) est7: Can't check freq 2000, it may be invalid est7: Invalid id16 (set, cur) = (14, 23) est7: Can't check freq 1867, it may be invalid est7: Invalid id16 (set, cur) = (13, 23) est7: Can't check freq 1733, it may be invalid est7: Invalid id16 (set, cur) = (12, 23) est7: Can't check freq 1600, it may be invalid p4tcc7: on cpu7 Device configuration finished. Reducing kern.maxvnodes 766109 -> 100000 procfs registered lapic: Divisor 2, Frequency 67100238 Hz Timecounter "TSC" frequency 3086610956 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata2: Identifying devices: 00000001 ata2: New devices: 00000001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: setting UDMA100 ad4: 1430799MB at ata2-master UDMA100 SATA 3Gb/s ad4: 2930277168 sectors [2907021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ad4: Intel check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00000000 ata3: New devices: 00000000 ata4: Identifying devices: 00000000 ata4: New devices: 00000000 ata5: Identifying devices: 00000001 ata5: New devices: 00000001 ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad10: setting UDMA100 ad10: 1430799MB at ata5-master UDMA100 SATA 3Gb/s ad10: 2930277168 sectors [2907021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad10 ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed GEOM_MIRROR: Device mirror/os launched (2/2).ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6: Identifying devices: 00000000 ata6: New devices: 00000000 ata7: Identifying devices: 00000000 ata7: New devices: 00000000 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 3 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 4 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 5 vector 48 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 6 vector 48 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 7 vector 48 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered GEOM_JOURNAL: Journal 2464011986: mirror/oss1g contains data. GEOM_JOURNAL: Journal 2464011986: mirror/oss1g contains journal. GEOM_JOURNAL: Journal mirror/oss1g clean. Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/mirror/oss1a ct_to_ts([2012-02-13 09:56:29]) = 1329126989.000000000 start_init: trying /sbin/init --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-ahci.txt" Copyright (c) 1992-2010 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.1-RELEASE-p5 #0: Tue Sep 27 16:49:00 UTC 2011 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80ebd000. Preloaded elf obj module "/boot/kernel/geom_journal.ko" at 0xffffffff80ebd230. Preloaded elf obj module "/boot/kernel/geom_mirror.ko" at 0xffffffff80ebd8e0. Preloaded elf obj module "/boot/kernel/ahci.ko" at 0xffffffff80ebdf90. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3083534484 Hz CPU: Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz (3083.53-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 12884901888 (12288 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000ef5000 - 0x00000000bf77ffff, 3196628992 bytes (780427 pages) 0x0000000100000000 - 0x00000003278effff, 9253617664 bytes (2259184 pages) avail memory = 12388859904 (11814 MB) ACPI APIC Table: <7522MS A7522800> INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 5 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 6 APIC: CPU 4 has ACPI ID 3 APIC: CPU 5 has ACPI ID 7 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 8 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x010000-0x01ffff at 0xffffff800005b000 x86bios: EBDA 0x09e000-0x09ffff at 0xffffff000009e000 x86bios: ROM 0x0a0000-0x0effff at 0xffffff00000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0xfa590 00014 (v0 ACPIAM) ACPI: RSDT 0xbf780000 0003C (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: FACP 0xbf780200 00084 (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: DSDT 0xbf780480 06E82 (v1 A7522 A7522800 00000800 INTL 20051117) ACPI: FACS 0xbf78e000 00040 ACPI: APIC 0xbf780390 000AC (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: MCFG 0xbf780440 0003C (v1 7522MS OEMMCFG 20110319 MSFT 00000097) ACPI: OEMB 0xbf78e040 0007A (v1 7522MS A7522800 20110319 MSFT 00000097) ACPI: HPET 0xbf78a480 00038 (v1 7522MS OEMHPET 20110319 MSFT 00000097) ACPI: SSDT 0xbf790980 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: <7522MS A7522800> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000026000 pa 0x4000 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed ACPI timer: 1/2 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0xBB, should be 0xBA (20100331/tbutils-354) ACPI: SSDT 0xbf78e0c0 0223C (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf790300 00678 (v1 PmRef P001Cst 00003001 INTL 20051117) cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 Validation 0 5 N 0 5 After Disable 0 255 N 0 5 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 4 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3405, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbbfe000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfbbfe000 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfbbfc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfbbfc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfbbfa000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=14 map[10]: type Memory, range 64, base 0xfbbf9c00, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfbc00000-0xfbcfffff pcib2: prefetched decode 0xd0000000-0xdfffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x1002, dev=0x68f9, revid=0x00 domain=0, bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib2: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfbce0000, size 17, enabled pcib2: requested memory range 0xfbce0000-0xfbcfffff: good map[20]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib2: requested I/O range 0xc000-0xc0ff: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0xaa68, revid=0x00 domain=0, bus=2, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfbcbc000, size 14, enabled pcib2: requested memory range 0xfbcbc000-0xfbcbffff: good pcib2: matched entry for 2.0.INTB pcib2: slot 0 INTB hardwired to IRQ 17 vgapci0: port 0xc000-0xc0ff mem 0xd0000000-0xdfffffff,0xfbce0000-0xfbcfffff irq 16 at device 0.0 on pci2 pci2: at device 0.1 (no driver attached) pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfbbfe000-0xfbbfe3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib4: irq 17 at device 28.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 pcib5: irq 17 at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 6 pcib5: subordinate bus 6 pcib5: I/O decode 0xe000-0xefff pcib5: memory decode 0xfbe00000-0xfbefffff pcib5: prefetched decode 0xfaf00000-0xfaffffff pci6: on pcib5 pci6: domain=0, physical bus=6 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=6, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xe800, size 8, enabled pcib5: requested I/O range 0xe800-0xe8ff: in range map[18]: type Memory, range 64, base 0xfbeff000, size 12, enabled pcib5: requested memory range 0xfbeff000-0xfbefffff: good map[20]: type Prefetchable Memory, range 64, base 0xfaff0000, size 16, enabled pcib5: requested memory range 0xfaff0000-0xfaffffff: good pcib5: matched entry for 6.0.INTA pcib5: slot 0 INTA hardwired to IRQ 16 re0: port 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xfaff0000-0xfaffffff irq 16 at device 0.0 on pci6 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfbeff000 re0: MSI count : 1 re0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 53 re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 8c:89:a5:15:6b:de re0: [MPSAFE] re0: [FILTER] uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfbbfc000-0xfbbfc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 7 pcib6: subordinate bus 7 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci7: on pcib6 pci7: domain=0, physical bus=7 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfbbfa000-0xfbbfa7ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfbbfa000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 64 ahci0: using IRQ 257 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahci0: Caps2: ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: HPCP ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich1: Caps: HPCP ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich2: Caps: HPCP ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich3: Caps: HPCP ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich4: Caps: HPCP ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] ahcich5: Caps: HPCP pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 55 uart0: [FILTER] uart0: fast interrupt atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ ex_isa_identify() ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 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 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices est0: on cpu0 est0: Invalid id16 (set, cur) = (22, 23) est0: Can't check freq 2933, it may be invalid est0: Invalid id16 (set, cur) = (21, 23) est0: Can't check freq 2800, it may be invalid est0: Invalid id16 (set, cur) = (20, 23) est0: Can't check freq 2667, it may be invalid est0: Invalid id16 (set, cur) = (19, 23) est0: Can't check freq 2533, it may be invalid est0: Invalid id16 (set, cur) = (18, 23) est0: Can't check freq 2400, it may be invalid est0: Invalid id16 (set, cur) = (17, 23) est0: Can't check freq 2267, it may be invalid est0: Invalid id16 (set, cur) = (16, 23) est0: Can't check freq 2133, it may be invalid est0: Invalid id16 (set, cur) = (15, 23) est0: Can't check freq 2000, it may be invalid est0: Invalid id16 (set, cur) = (14, 23) est0: Can't check freq 1867, it may be invalid est0: Invalid id16 (set, cur) = (13, 23) est0: Can't check freq 1733, it may be invalid est0: Invalid id16 (set, cur) = (12, 23) est0: Can't check freq 1600, it may be invalid p4tcc0: on cpu0 est1: on cpu1 est1: Invalid id16 (set, cur) = (22, 23) est1: Can't check freq 2933, it may be invalid est1: Invalid id16 (set, cur) = (21, 23) est1: Can't check freq 2800, it may be invalid est1: Invalid id16 (set, cur) = (20, 23) est1: Can't check freq 2667, it may be invalid est1: Invalid id16 (set, cur) = (19, 23) est1: Can't check freq 2533, it may be invalid est1: Invalid id16 (set, cur) = (18, 23) est1: Can't check freq 2400, it may be invalid est1: Invalid id16 (set, cur) = (17, 23) est1: Can't check freq 2267, it may be invalid est1: Invalid id16 (set, cur) = (16, 23) est1: Can't check freq 2133, it may be invalid est1: Invalid id16 (set, cur) = (15, 23) est1: Can't check freq 2000, it may be invalid est1: Invalid id16 (set, cur) = (14, 23) est1: Can't check freq 1867, it may be invalid est1: Invalid id16 (set, cur) = (13, 23) est1: Can't check freq 1733, it may be invalid est1: Invalid id16 (set, cur) = (12, 23) est1: Can't check freq 1600, it may be invalid p4tcc1: on cpu1 est2: on cpu2 est2: Invalid id16 (set, cur) = (22, 23) est2: Can't check freq 2933, it may be invalid est2: Invalid id16 (set, cur) = (21, 23) est2: Can't check freq 2800, it may be invalid est2: Invalid id16 (set, cur) = (20, 23) est2: Can't check freq 2667, it may be invalid est2: Invalid id16 (set, cur) = (19, 23) est2: Can't check freq 2533, it may be invalid est2: Invalid id16 (set, cur) = (18, 23) est2: Can't check freq 2400, it may be invalid est2: Invalid id16 (set, cur) = (17, 23) est2: Can't check freq 2267, it may be invalid est2: Invalid id16 (set, cur) = (16, 23) est2: Can't check freq 2133, it may be invalid est2: Invalid id16 (set, cur) = (15, 23) est2: Can't check freq 2000, it may be invalid est2: Invalid id16 (set, cur) = (14, 23) est2: Can't check freq 1867, it may be invalid est2: Invalid id16 (set, cur) = (13, 23) est2: Can't check freq 1733, it may be invalid est2: Invalid id16 (set, cur) = (12, 23) est2: Can't check freq 1600, it may be invalid p4tcc2: on cpu2 est3: on cpu3 est3: Invalid id16 (set, cur) = (22, 23) est3: Can't check freq 2933, it may be invalid est3: Invalid id16 (set, cur) = (21, 23) est3: Can't check freq 2800, it may be invalid est3: Invalid id16 (set, cur) = (20, 23) est3: Can't check freq 2667, it may be invalid est3: Invalid id16 (set, cur) = (19, 23) est3: Can't check freq 2533, it may be invalid est3: Invalid id16 (set, cur) = (18, 23) est3: Can't check freq 2400, it may be invalid est3: Invalid id16 (set, cur) = (17, 23) est3: Can't check freq 2267, it may be invalid est3: Invalid id16 (set, cur) = (16, 23) est3: Can't check freq 2133, it may be invalid est3: Invalid id16 (set, cur) = (15, 23) est3: Can't check freq 2000, it may be invalid est3: Invalid id16 (set, cur) = (14, 23) est3: Can't check freq 1867, it may be invalid est3: Invalid id16 (set, cur) = (13, 23) est3: Can't check freq 1733, it may be invalid est3: Invalid id16 (set, cur) = (12, 23) est3: Can't check freq 1600, it may be invalid p4tcc3: on cpu3 est4: on cpu4 est4: Invalid id16 (set, cur) = (22, 23) est4: Can't check freq 2933, it may be invalid est4: Invalid id16 (set, cur) = (21, 23) est4: Can't check freq 2800, it may be invalid est4: Invalid id16 (set, cur) = (20, 23) est4: Can't check freq 2667, it may be invalid est4: Invalid id16 (set, cur) = (19, 23) est4: Can't check freq 2533, it may be invalid est4: Invalid id16 (set, cur) = (18, 23) est4: Can't check freq 2400, it may be invalid est4: Invalid id16 (set, cur) = (17, 23) est4: Can't check freq 2267, it may be invalid est4: Invalid id16 (set, cur) = (16, 23) est4: Can't check freq 2133, it may be invalid est4: Invalid id16 (set, cur) = (15, 23) est4: Can't check freq 2000, it may be invalid est4: Invalid id16 (set, cur) = (14, 23) est4: Can't check freq 1867, it may be invalid est4: Invalid id16 (set, cur) = (13, 23) est4: Can't check freq 1733, it may be invalid est4: Invalid id16 (set, cur) = (12, 23) est4: Can't check freq 1600, it may be invalid p4tcc4: on cpu4 est5: on cpu5 est5: Invalid id16 (set, cur) = (22, 23) est5: Can't check freq 2933, it may be invalid est5: Invalid id16 (set, cur) = (21, 23) est5: Can't check freq 2800, it may be invalid est5: Invalid id16 (set, cur) = (20, 23) est5: Can't check freq 2667, it may be invalid est5: Invalid id16 (set, cur) = (19, 23) est5: Can't check freq 2533, it may be invalid est5: Invalid id16 (set, cur) = (18, 23) est5: Can't check freq 2400, it may be invalid est5: Invalid id16 (set, cur) = (17, 23) est5: Can't check freq 2267, it may be invalid est5: Invalid id16 (set, cur) = (16, 23) est5: Can't check freq 2133, it may be invalid est5: Invalid id16 (set, cur) = (15, 23) est5: Can't check freq 2000, it may be invalid est5: Invalid id16 (set, cur) = (14, 23) est5: Can't check freq 1867, it may be invalid est5: Invalid id16 (set, cur) = (13, 23) est5: Can't check freq 1733, it may be invalid est5: Invalid id16 (set, cur) = (12, 23) est5: Can't check freq 1600, it may be invalid p4tcc5: on cpu5 est6: on cpu6 est6: Invalid id16 (set, cur) = (22, 23) est6: Can't check freq 2933, it may be invalid est6: Invalid id16 (set, cur) = (21, 23) est6: Can't check freq 2800, it may be invalid est6: Invalid id16 (set, cur) = (20, 23) est6: Can't check freq 2667, it may be invalid est6: Invalid id16 (set, cur) = (19, 23) est6: Can't check freq 2533, it may be invalid est6: Invalid id16 (set, cur) = (18, 23) est6: Can't check freq 2400, it may be invalid est6: Invalid id16 (set, cur) = (17, 23) est6: Can't check freq 2267, it may be invalid est6: Invalid id16 (set, cur) = (16, 23) est6: Can't check freq 2133, it may be invalid est6: Invalid id16 (set, cur) = (15, 23) est6: Can't check freq 2000, it may be invalid est6: Invalid id16 (set, cur) = (14, 23) est6: Can't check freq 1867, it may be invalid est6: Invalid id16 (set, cur) = (13, 23) est6: Can't check freq 1733, it may be invalid est6: Invalid id16 (set, cur) = (12, 23) est6: Can't check freq 1600, it may be invalid p4tcc6: on cpu6 est7: on cpu7 est7: Invalid id16 (set, cur) = (22, 23) est7: Can't check freq 2933, it may be invalid est7: Invalid id16 (set, cur) = (21, 23) est7: Can't check freq 2800, it may be invalid est7: Invalid id16 (set, cur) = (20, 23) est7: Can't check freq 2667, it may be invalid est7: Invalid id16 (set, cur) = (19, 23) est7: Can't check freq 2533, it may be invalid est7: Invalid id16 (set, cur) = (18, 23) est7: Can't check freq 2400, it may be invalid est7: Invalid id16 (set, cur) = (17, 23) est7: Can't check freq 2267, it may be invalid est7: Invalid id16 (set, cur) = (16, 23) est7: Can't check freq 2133, it may be invalid est7: Invalid id16 (set, cur) = (15, 23) est7: Can't check freq 2000, it may be invalid est7: Invalid id16 (set, cur) = (14, 23) est7: Can't check freq 1867, it may be invalid est7: Invalid id16 (set, cur) = (13, 23) est7: Can't check freq 1733, it may be invalid est7: Invalid id16 (set, cur) = (12, 23) est7: Can't check freq 1600, it may be invalid p4tcc7: on cpu7 Device configuration finished. Reducing kern.maxvnodes 766105 -> 100000 procfs registered lapic: Divisor 2, Frequency 67033358 Hz Timecounter "TSC" frequency 3083534484 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=2ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: AHCI reset... ahcich1: SATA connect timeout status=00000000 ahcich1: AHCI reset done: phy reset found no device ahcich2: AHCI reset... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset found no device ahcich3: AHCI reset... ahcich3: SATA connect time=0ms status=00000123 ahcich3: ready wait time=7ms ahcich3: AHCI reset done: device found (aprobe0:ahcich3:0:0:0): SIGNATURE: 0000 ahcich4: AHCI reset... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: Serial Number S24EJ9BB200080 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich3 bus 0 scbus3 target 0 lun 0 ada1: ATA-7 SATA 2.x device ada1: Serial Number S24EJ9BB200082 ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number S24EJ9BB200080GEOM: new disk ada0 GEOM: new disk ada1 pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled pass1 at ahcich3 bus 0 scbus3 target 0 lun 0 pass1: ATA-7 SATA 2.x device pass1: Serial Number S24EJ9BB200082 pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass1: Command Queueing enabled 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 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: 0x000000f0 pmc: 0x00010400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 3 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 4 vector 48 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 5 vector 48 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 6 vector 48 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 7 vector 48 msi: Assigning MSI IRQ 257 to local APIC 1 vector 49 GEOM_MIRROR: Device mirror/os launched (2/2). GEOM_JOURNAL: Journal 2464011986: mirror/oss1g contains data. GEOM_JOURNAL: Journal 2464011986: mirror/oss1g contains journal. GEOM_JOURNAL: Journal mirror/oss1g clean. Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 uhub7: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/mirror/oss1a ct_to_ts([2012-02-13 10:04:58]) = 1329127498.000000000 start_init: trying /sbin/init re0: link state changed to UP --L6iaP+gRLNZHKoI4-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 09:32:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C0C106564A; Tue, 14 Feb 2012 09:32:56 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 69C478FC08; Tue, 14 Feb 2012 09:32:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1E9Wut0089186; Tue, 14 Feb 2012 09:32:56 GMT (envelope-from bapt@freebsd.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1E9Wu00089185; Tue, 14 Feb 2012 09:32:56 GMT (envelope-from bapt@freebsd.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@freebsd.org using -f Date: Tue, 14 Feb 2012 10:32:52 +0100 From: Baptiste Daroussin To: Jason Hellenthal Message-ID: <20120214093252.GB7132@azathoth.lan> References: <20120211065857.GA66606@DataIX.net> <20120214074700.GA89794@DataIX.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Pd0ReVV5GZGQvF3a" Content-Disposition: inline In-Reply-To: <20120214074700.GA89794@DataIX.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, dougb@freebsd.org Subject: Re: dhclient script adjustments 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, 14 Feb 2012 09:32:56 -0000 --Pd0ReVV5GZGQvF3a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 02:47:00AM -0500, Jason Hellenthal wrote: >=20 > Anyone ? >=20 Sorry for mess, I'm working on this to figure out why it does that. Thanks for reporting, regards, Bapt --Pd0ReVV5GZGQvF3a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86KkQACgkQ8kTtMUmk6Ex9jwCfQq9Ih8YsVCFHmIvWyfs0HdGN G9gAoK9MSxtIt1ytdntcwU8GhJBoghT9 =LPMu -----END PGP SIGNATURE----- --Pd0ReVV5GZGQvF3a-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 09:48:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80DF01065672; Tue, 14 Feb 2012 09:48:31 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCC98FC14; Tue, 14 Feb 2012 09:48:31 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so324448pbc.13 for ; Tue, 14 Feb 2012 01:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=u+cSH77srS7UDnzv7ro7WbttPm+s0473Mz+HXjx8fXU=; b=NCUdmqi6zhMn0tK3SnqDrmjNvPM6fQBpDlN5O9XcpugLxuRF/cd/EBstPJkWh9erUa nBgBOJGQRIRPH++UPWygJlQIu4h6mdxOeE7ZnsCMCbWaTPxhax4j+L5Qq3dXzmZR8pSt Kz6N02XPSM/kpzhgEax89Q0kVVihWFsCmTb74= Received: by 10.68.222.131 with SMTP id qm3mr57152825pbc.34.1329211415307; Tue, 14 Feb 2012 01:23:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.12.18 with HTTP; Tue, 14 Feb 2012 01:23:15 -0800 (PST) In-Reply-To: <20120212173339.G93710@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <4F353E4A.6030903@noc.ntua.gr> <20120212173339.G93710@sola.nimnet.asn.au> From: n j Date: Tue, 14 Feb 2012 10:23:15 +0100 Message-ID: To: stable@freebsd.org, ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Reducing the need to compile a custom kernel 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, 14 Feb 2012 09:48:31 -0000 On Sun, Feb 12, 2012 at 8:52 AM, Ian Smith wrote: > On Fri, 10 Feb 2012 16:12:00 +0000, Bjoern A. Zeeb wrote: > =A0> > IPFIREWALL_FORWARD > > Unless something's changed, julian@ has pointed out (paraphrasing) that > this adds bits of code to various parts of the stack and was thought to > impact performance too much when unused to conditionalise each instance. > > I'm unsure if this is the only case ipfw still needs building in kernel? If something's changed, I'd really love to hear it. IPFIREWALL_FORWARD is the most common reason I need a custom kernel (usually to solve the issues around asymmetric/source-based policy routing on multihomed hosts). Really miss Linux' "ip rule... table" functionality. Regards, --=20 Nino From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 10:00:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A399106566B for ; Tue, 14 Feb 2012 10:00:22 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 21AF88FC14 for ; Tue, 14 Feb 2012 10:00:11 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so5404078bkc.13 for ; Tue, 14 Feb 2012 02:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LaocPwf+wCFEGQnQ5SLV4TEamfxDvp5xf091nu21JFU=; b=QZjpTqrpHJaSSqaKmRDbHDXb4B2QEmwPuWi3tPpAZOXNRwv1SUnr7L9O9g4a81mERf l63vC+dih8IXhvJ8d/8XlwahGcjl/CTQoQ5fVlzp1YMYg0U8alSSIMluomfi+IAhCoqw ArJDIudo8q1oLWmjXm9AfxjUDiS4vCmdU81tw= Received: by 10.204.157.17 with SMTP id z17mr8578799bkw.37.1329213611072; Tue, 14 Feb 2012 02:00:11 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id i2sm54847427bkd.10.2012.02.14.02.00.09 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 02:00:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3A30A7.1000601@FreeBSD.org> Date: Tue, 14 Feb 2012 12:00:07 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Victor Balada Diaz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 10:00:22 -0000 On 02/14/12 11:19, Victor Balada Diaz wrote: > We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: > > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=18ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=84ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Request requeued > [...] > > If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, > no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we > got the above error. If we use both disks in gmirror with old ata driver, no problems. In both cases controller reports command status as 0xc0, that means device is busy with the command. For NCQ commands it means that device in in stage of processing command itself, not a head positioning or data transfer. Enabling AHCI enables NCQ for the devices. That increases load on both devices and the controller, and it is difficult to say who's fault is here. SAMSUNG HD154UI disks AFAIR have 4k sectors that may have big performance penalties when accessing small/misaligned data. I am not sure how big that penalty can be in the worst case, especially since disks by default cache writes, hiding the real load level. Relations with gmirror is harder to explain. Depending on how you created it and partitions it could cause more misaligned I/Os during rebuild. Using gmirror also double concurrent load on the controller, but at this point I have nothing to blame it for. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 10:05:15 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71E571065672 for ; Tue, 14 Feb 2012 10:05:15 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 563EA8FC16 for ; Tue, 14 Feb 2012 10:05:14 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta08.emeryville.ca.mail.comcast.net with comcast id Zm4V1i0011HpZEsA8m5EhU; Tue, 14 Feb 2012 10:05:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id Zm5D1i00i1t3BNj8am5DV2; Tue, 14 Feb 2012 10:05:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5B9EA102C1E; Tue, 14 Feb 2012 02:05:13 -0800 (PST) Date: Tue, 14 Feb 2012 02:05:13 -0800 From: Jeremy Chadwick To: Victor Balada Diaz Message-ID: <20120214100513.GA94501@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120214091909.GP2010@equilibrium.bsdes.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 10:05:15 -0000 On Tue, Feb 14, 2012 at 10:19:09AM +0100, Victor Balada Diaz wrote: > We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: > > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=18ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > ahcich0: Timeout on slot 8 > ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 > ahcich0: AHCI reset... > ahcich0: SATA connect time=0ms status=00000123 > ahcich0: ready wait time=84ms > ahcich0: AHCI reset done: device found > (ada0:ahcich0:0:0:0): Request requeued > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Command timed out > (ada0:ahcich0:0:0:0): Retrying command > (ada0:ahcich0:0:0:0): Request requeued > [...] > > If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, > no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we > got the above error. If we use both disks in gmirror with old ata driver, no problems. Please provide SMART statistics for both disks by installing ports/sysutils/smartmontools (5.42 or newer please) and running "smartctl -a" against both disks (ada0/ada1, or ad4/ad10 -- doesn't matter which driver you're using). I will review the output. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 10:10:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DEE31065673 for ; Tue, 14 Feb 2012 10:10:48 +0000 (UTC) (envelope-from jhugo@meraka.csir.co.za) Received: from marge.meraka.csir.co.za (marge.meraka.csir.co.za [IPv6:2001:4200:7000:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id C47938FC14 for ; Tue, 14 Feb 2012 10:10:41 +0000 (UTC) Received: from jeep.localnet (unknown [IPv6:2001:4200:7000:3:223:aeff:fea7:a3c2]) by marge.meraka.csir.co.za (Postfix) with ESMTP id F2551D0CC3D for ; Tue, 14 Feb 2012 12:10:38 +0200 (SAST) From: Johann Hugo To: "freebsd-stable@freebsd.org" Date: Tue, 14 Feb 2012 12:10:37 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-RELEASE; KDE/4.7.3; amd64; ; ) X-KMail-Markup: true MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_dMjOPi/dzL7RXJ5" Message-Id: <201202141210.37059.jhugo@meraka.csir.co.za> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: USB keybord - random freeze 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, 14 Feb 2012 10:10:48 -0000 --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I get random usb keyboard freezes from time to time on FreeBSD 9.0-RELEASE and only a reboot will get it working again. The mouse still works and I can ssh to the PC (Dell Optiplex 760, running PC-BSD version 9.0). Removing the keyboard and putting it back does not cure the problem, but it is visible in dmesg with no errors. Adding a second keyboard gives the same symptons. Any pointers to what I can try the next time that it happens ? See attachments for some more detail outputs (with frozen keyboard) Johann --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="UTF-8"; name="uname.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="uname.out" FreeBSD jeep 9.0-RELEASE FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 root@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="UTF-8"; name="usbconfig.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="usbconfig.out" ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen6.1: at usbus6, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen7.1: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen4.3: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.4: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="UTF-8"; name="sysctl.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sysctl.out" kern.ostype: FreeBSD kern.osrelease: 9.0-RELEASE kern.osrevision: 199506 kern.version: FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 root@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC kern.maxvnodes: 144608 kern.maxproc: 10000 kern.maxfiles: 49312 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: jeep kern.hostid: 3290749680 kern.clockrate: { hz = 1000, tick = 1000, profhz = 8126, stathz = 127 } kern.posix1version: 200112 kern.ngroups: 1023 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1328272486, usec = 912442 } Fri Feb 3 14:34:46 2012 kern.domainname: kern.osreldate: 900044 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 18000 kern.maxprocperuid: 9000 kern.ipc.maxsockbuf: 2097152 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 92 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 25600 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 5095424 kern.ipc.maxpipekva: 64622592 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 632 kern.ipc.semume: 50 kern.ipc.semopm: 100 kern.ipc.semmsl: 340 kern.ipc.semmnu: 150 kern.ipc.semmns: 340 kern.ipc.semmni: 50 kern.ipc.shm_allow_removed: 1 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 131072 kern.ipc.shmseg: 1024 kern.ipc.shmmni: 1024 kern.ipc.shmmin: 1 kern.ipc.shmmax: 536870912 kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 529 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 kern.dummy: 0 kern.ps_strings: 140737488351200 kern.usrstack: 140737488351232 kern.logsigexit: 1 kern.iov_max: 1024 kern.hostuuid: 44454c4c-4200-1047-8036-b8c04f47344a kern.cam.boot_delay: 0 kern.cam.pmp.default_timeout: 30 kern.cam.pmp.retry_count: 1 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.cd.retry_count: 4 kern.cam.cd.changer.max_busy_seconds: 15 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.cd.0.minimum_cmd_size: 6 kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.spindown_suspend: 1 kern.cam.ada.spindown_shutdown: 1 kern.cam.ada.ada_send_ordered: 1 kern.cam.ada.default_timeout: 30 kern.cam.ada.retry_count: 4 kern.cam.ada.legacy_aliases: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 kern.cam.ada.1.read_ahead: -1 kern.cam.ada.1.write_cache: -1 kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.dcons.poll_hz: 25 kern.tty_pty_warningcnt: 1 kern.disks: cd0 ada1 ada0 kern.geom.disk.ada0.led: kern.geom.disk.ada1.led: kern.geom.disk.cd0.led: kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 0 DISK ada1 320072933376 512 hd 16 sc 63 1 PART ada1p3 9932111872 512 i 3 o 310135309312 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/76a4da4d-a465-11df-8d13-0023aea7a3c2 9932111872 512 i 0 o 0 1 PART ada1p2 310135226368 512 i 2 o 82944 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 2 LABEL gptid/4a753dd5-a465-11df-8d13-0023aea7a3c2 310135226368 512 i 0 o 0 1 PART ada1p1 65536 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/06bb1cb5-a463-11df-8d13-0023aea7a3c2 65536 512 i 0 o 0 0 DISK ada0 320072933376 512 hd 16 sc 63 1 PART ada0p4 309066030592 512 i 4 o 11006885888 ty freebsd-zfs xs GPT xt 516e7cba-6ecf-11d6-8ff8-00022d09712b 1 PART ada0p3 9932111872 512 i 3 o 1074774016 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b 2 LABEL label/swap0 9932111360 512 i 0 o 0 1 PART ada0p2 1073741824 512 i 2 o 1032192 ty freebsd-ufs xs GPT xt 516e7cb6-6ecf-11d6-8ff8-00022d09712b 2 LABEL label/boot0 1073741312 512 i 0 o 0 1 PART ada0p1 65536 512 i 1 o 17408 ty freebsd-boot xs GPT xt 83bd6b9d-7f41-11dc-be0b-001560b84f0f 2 LABEL gptid/3471741d-4693-11e1-aaa5-0023aea7a3c2 65536 512 i 0 o 0 kern.geom.confdot: digraph geom { z0xfffffe0006ced200 [shape=box,label="SWAP\nswap\nr#4"]; z0xfffffe0006898100 [label="r1w1e0"]; z0xfffffe0006898100 -> z0xfffffe000675d900; z0xfffffe0006ced200 -> z0xfffffe0006898100; z0xfffffe000674bc00 [shape=box,label="PART\nada1\nr#2"]; z0xfffffe000670e500 [label="r0w0e0"]; z0xfffffe000670e500 -> z0xfffffe000674b000; z0xfffffe000674bc00 -> z0xfffffe000670e500; z0xfffffe000674bd00 [shape=hexagon,label="ada1p3\nr0w0e0\nerr#0"]; z0xfffffe000674bd00 -> z0xfffffe000674bc00; z0xfffffe000674b600 [shape=hexagon,label="ada1p2\nr0w0e0\nerr#0"]; z0xfffffe000674b600 -> z0xfffffe000674bc00; z0xfffffe000674b800 [shape=hexagon,label="ada1p1\nr0w0e0\nerr#0"]; z0xfffffe000674b800 -> z0xfffffe000674bc00; z0xfffffe00066a3800 [shape=box,label="PART\nada0\nr#2"]; z0xfffffe000670ea00 [label="r3w3e7"]; z0xfffffe000670ea00 -> z0xfffffe000674b300; z0xfffffe00066a3800 -> z0xfffffe000670ea00; z0xfffffe000675d400 [shape=hexagon,label="ada0p4\nr1w1e1\nerr#0"]; z0xfffffe000675d400 -> z0xfffffe00066a3800; z0xfffffe000674aa00 [shape=hexagon,label="ada0p3\nr1w1e1\nerr#0"]; z0xfffffe000674aa00 -> z0xfffffe00066a3800; z0xfffffe00066a3100 [shape=hexagon,label="ada0p2\nr1w1e2\nerr#0"]; z0xfffffe00066a3100 -> z0xfffffe00066a3800; z0xfffffe00066a3300 [shape=hexagon,label="ada0p1\nr0w0e0\nerr#0"]; z0xfffffe00066a3300 -> z0xfffffe00066a3800; z0xfffffe0006716400 [shape=box,label="LABEL\nada1p3\nr#3"]; z0xfffffe0006747380 [label="r0w0e0"]; z0xfffffe0006747380 -> z0xfffffe000674bd00; z0xfffffe0006716400 -> z0xfffffe0006747380; z0xfffffe0006716300 [shape=hexagon,label="gptid/76a4da4d-a465-11df-8d13-0023aea7a3c2\nr0w0e0\nerr#0"]; z0xfffffe0006716300 -> z0xfffffe0006716400; z0xfffffe0006795c00 [shape=box,label="LABEL\nada1p2\nr#3"]; z0xfffffe000670e580 [label="r0w0e0"]; z0xfffffe000670e580 -> z0xfffffe000674b600; z0xfffffe0006795c00 -> z0xfffffe000670e580; z0xfffffe0006795b00 [shape=hexagon,label="gptid/4a753dd5-a465-11df-8d13-0023aea7a3c2\nr0w0e0\nerr#0"]; z0xfffffe0006795b00 -> z0xfffffe0006795c00; z0xfffffe0006716800 [shape=box,label="LABEL\nada1p1\nr#3"]; z0xfffffe0006747400 [label="r0w0e0"]; z0xfffffe0006747400 -> z0xfffffe000674b800; z0xfffffe0006716800 -> z0xfffffe0006747400; z0xfffffe0006716700 [shape=hexagon,label="gptid/06bb1cb5-a463-11df-8d13-0023aea7a3c2\nr0w0e0\nerr#0"]; z0xfffffe0006716700 -> z0xfffffe0006716800; z0xfffffe000675d700 [shape=box,label="LABEL\nada0p3\nr#3"]; z0xfffffe0006747800 [label="r1w1e1"]; z0xfffffe0006747800 -> z0xfffffe000674aa00; z0xfffffe000675d700 -> z0xfffffe0006747800; z0xfffffe000675d900 [shape=hexagon,label="label/swap0\nr1w1e0\nerr#0"]; z0xfffffe000675d900 -> z0xfffffe000675d700; z0xfffffe000674a300 [shape=box,label="LABEL\nada0p2\nr#3"]; z0xfffffe0006703700 [label="r1w1e2"]; z0xfffffe0006703700 -> z0xfffffe00066a3100; z0xfffffe000674a300 -> z0xfffffe0006703700; z0xfffffe0006795600 [shape=hexagon,label="label/boot0\nr1w1e1\nerr#0"]; z0xfffffe0006795600 -> z0xfffffe000674a300; z0xfffffe000674a100 [shape=box,label="LABEL\nada0p1\nr#3"]; z0xfffffe0006747600 [label="r0w0e0"]; z0xfffffe0006747600 -> z0xfffffe00066a3300; z0xfffffe000674a100 -> z0xfffffe0006747600; z0xfffffe000674a000 [shape=hexagon,label="gptid/3471741d-4693-11e1-aaa5-0023aea7a3c2\nr0w0e0\nerr#0"]; z0xfffffe000674a000 -> z0xfffffe000674a100; z0xfffffe000686db00 [shape=box,label="VFS\nffs.label/boot0\nr#4"]; z0xfffffe0006ce9480 [label="r1w1e1"]; z0xfffffe0006ce9480 -> z0xfffffe0006795600; z0xfffffe000686db00 -> z0xfffffe0006ce9480; z0xfffffe000674ad00 [shape=box,label="DISK\ncd0\nr#1"]; z0xfffffe000674ac00 [shape=hexagon,label="cd0\nr0w0e0\nerr#0"]; z0xfffffe000674ac00 -> z0xfffffe000674ad00; z0xfffffe000674b100 [shape=box,label="DISK\nada1\nr#1"]; z0xfffffe000674b000 [shape=hexagon,label="ada1\nr0w0e0\nerr#0"]; z0xfffffe000674b000 -> z0xfffffe000674b100; z0xfffffe000674b400 [shape=box,label="DISK\nada0\nr#1"]; z0xfffffe000674b300 [shape=hexagon,label="ada0\nr3w3e7\nerr#0"]; z0xfffffe000674b300 -> z0xfffffe000674b400; z0xfffffe0006871300 [shape=box,label="ZFS::VDEV\nzfs::vdev\nr#3"]; z0xfffffe00068cb700 [label="r1w1e1"]; z0xfffffe00068cb700 -> z0xfffffe000675d400; z0xfffffe0006871300 -> z0xfffffe00068cb700; z0xfffffe0006795a00 [shape=box,label="DEV\ngptid/76a4da4d-a465-11df-8d13-0023aea7a3c2\nr#4"]; z0xfffffe0006748400 [label="r0w0e0"]; z0xfffffe0006748400 -> z0xfffffe0006716300; z0xfffffe0006795a00 -> z0xfffffe0006748400; z0xfffffe00066a3200 [shape=box,label="DEV\ngptid/4a753dd5-a465-11df-8d13-0023aea7a3c2\nr#4"]; z0xfffffe0006748300 [label="r0w0e0"]; z0xfffffe0006748300 -> z0xfffffe0006795b00; z0xfffffe00066a3200 -> z0xfffffe0006748300; z0xfffffe0006795d00 [shape=box,label="DEV\ngptid/06bb1cb5-a463-11df-8d13-0023aea7a3c2\nr#4"]; z0xfffffe0006748700 [label="r0w0e0"]; z0xfffffe0006748700 -> z0xfffffe0006716700; z0xfffffe0006795d00 -> z0xfffffe0006748700; z0xfffffe0006795200 [shape=box,label="DEV\nlabel/swap0\nr#4"]; z0xfffffe0006747100 [label="r0w0e0"]; z0xfffffe0006747100 -> z0xfffffe000675d900; z0xfffffe0006795200 -> z0xfffffe0006747100; z0xfffffe000674be00 [shape=box,label="DEV\nlabel/boot0\nr#4"]; z0xfffffe000670f800 [label="r0w0e0"]; z0xfffffe000670f800 -> z0xfffffe0006795600; z0xfffffe000674be00 -> z0xfffffe000670f800; z0xfffffe0006798700 [shape=box,label="DEV\ngptid/3471741d-4693-11e1-aaa5-0023aea7a3c2\nr#4"]; z0xfffffe000670e200 [label="r0w0e0"]; z0xfffffe000670e200 -> z0xfffffe000674a000; z0xfffffe0006798700 -> z0xfffffe000670e200; z0xfffffe0006798000 [shape=box,label="DEV\nada1p3\nr#3"]; z0xfffffe0006703900 [label="r0w0e0"]; z0xfffffe0006703900 -> z0xfffffe000674bd00; z0xfffffe0006798000 -> z0xfffffe0006703900; z0xfffffe0006795800 [shape=box,label="DEV\nada1p2\nr#3"]; z0xfffffe000670e300 [label="r0w0e0"]; z0xfffffe000670e300 -> z0xfffffe000674b600; z0xfffffe0006795800 -> z0xfffffe000670e300; z0xfffffe0006798400 [shape=box,label="DEV\nada1p1\nr#3"]; z0xfffffe000670f880 [label="r0w0e0"]; z0xfffffe000670f880 -> z0xfffffe000674b800; z0xfffffe0006798400 -> z0xfffffe000670f880; z0xfffffe000675d500 [shape=box,label="DEV\nada0p4\nr#3"]; z0xfffffe0006747a00 [label="r0w0e0"]; z0xfffffe0006747a00 -> z0xfffffe000675d400; z0xfffffe000675d500 -> z0xfffffe0006747a00; z0xfffffe000675dc00 [shape=box,label="DEV\nada0p3\nr#3"]; z0xfffffe000670e280 [label="r0w0e0"]; z0xfffffe000670e280 -> z0xfffffe000674aa00; z0xfffffe000675dc00 -> z0xfffffe000670e280; z0xfffffe000675db00 [shape=box,label="DEV\nada0p2\nr#3"]; z0xfffffe0006703a00 [label="r0w0e0"]; z0xfffffe0006703a00 -> z0xfffffe00066a3100; z0xfffffe000675db00 -> z0xfffffe0006703a00; z0xfffffe000674a500 [shape=box,label="DEV\nada0p1\nr#3"]; z0xfffffe0006703b00 [label="r0w0e0"]; z0xfffffe0006703b00 -> z0xfffffe00066a3300; z0xfffffe000674a500 -> z0xfffffe0006703b00; z0xfffffe000674a400 [shape=box,label="DEV\ncd0\nr#2"]; z0xfffffe0006747780 [label="r0w0e0"]; z0xfffffe0006747780 -> z0xfffffe000674ac00; z0xfffffe000674a400 -> z0xfffffe0006747780; z0xfffffe000675d200 [shape=box,label="DEV\nada1\nr#2"]; z0xfffffe000670e180 [label="r0w0e0"]; z0xfffffe000670e180 -> z0xfffffe000674b000; z0xfffffe000675d200 -> z0xfffffe000670e180; z0xfffffe000675d000 [shape=box,label="DEV\nada0\nr#2"]; z0xfffffe000670e680 [label="r0w0e0"]; z0xfffffe000670e680 -> z0xfffffe000674b300; z0xfffffe000675d000 -> z0xfffffe000670e680; }; kern.geom.confxml: FD ZFS::ZVOL SWAP swap 4 r1w1e0 MD UZIP MIRROR PART ada1 2 GPT 128 34 625142414 63 16 OK false r0w0e0 r0w0e0 ada1p3 9932111872 512 0 897664000 605733026 625131681 3 freebsd-swap 310135309312 9932111872 516e7cb5-6ecf-11d6-8ff8-00022d09712b 76a4da4d-a465-11df-8d13-0023aea7a3c2 r0w0e0 ada1p2 310135226368 512 0 82944 162 605733025 2 freebsd-zfs 82944 310135226368 516e7cba-6ecf-11d6-8ff8-00022d09712b 4a753dd5-a465-11df-8d13-0023aea7a3c2 r0w0e0 ada1p1 65536 512 0 17408 34 161 1 freebsd-boot 17408 65536 83bd6b9d-7f41-11dc-be0b-001560b84f0f 06bb1cb5-a463-11df-8d13-0023aea7a3c2 ada0 2 GPT 128 34 625142414 63 16 OK false r3w3e7 r1w1e1 ada0p4 309066030592 512 0 2416951296 21497824 625142414 4 freebsd-zfs 11006885888 309066030592 516e7cba-6ecf-11d6-8ff8-00022d09712b 3b1d8b1a-4693-11e1-aaa5-0023aea7a3c2 r1w1e1 ada0p3 9932111872 512 0 1074774016 2099168 21497823 3 freebsd-swap 1074774016 9932111872 516e7cb5-6ecf-11d6-8ff8-00022d09712b 3892e244-4693-11e1-aaa5-0023aea7a3c2 r1w1e2 ada0p2 1073741824 512 0 1032192 2016 2099167 2 freebsd-ufs 1032192 1073741824 516e7cb6-6ecf-11d6-8ff8-00022d09712b 3609c27e-4693-11e1-aaa5-0023aea7a3c2 r0w0e0 ada0p1 65536 512 0 17408 34 161 1 freebsd-boot 17408 65536 83bd6b9d-7f41-11dc-be0b-001560b84f0f 3471741d-4693-11e1-aaa5-0023aea7a3c2 JOURNAL LABEL ada1p3 3 r0w0e0 r0w0e0 gptid/76a4da4d-a465-11df-8d13-0023aea7a3c2 9932111872 512 0 897664000 0 9932111872 19398656 0 0 ada1p2 3 r0w0e0 r0w0e0 gptid/4a753dd5-a465-11df-8d13-0023aea7a3c2 310135226368 512 0 82944 0 310135226368 605732864 0 0 ada1p1 3 r0w0e0 r0w0e0 gptid/06bb1cb5-a463-11df-8d13-0023aea7a3c2 65536 512 0 17408 0 65536 128 0 0 ada0p3 3 r1w1e1 r1w1e0 label/swap0 9932111360 512 0 1074774016 0 9932111360 19398655 0 0 ada0p2 3 r1w1e2 r1w1e1 label/boot0 1073741312 512 0 1032192 0 1073741312 2097151 0 0 ada0p1 3 r0w0e0 r0w0e0 gptid/3471741d-4693-11e1-aaa5-0023aea7a3c2 65536 512 0 17408 0 65536 128 0 0 VFS ffs.label/boot0 4 r1w1e1 ELI DISK cd0 1 r0w0e0 cd0 0 2048 0 0 0 0 PLDS DVD+-RW DH-16AAS ada1 1 r0w0e0 ada1 320072933376 512 0 0 16 63 ST3320418AS ada0 1 r3w3e7 ada0 320072933376 512 0 0 16 63 ST3320418AS ZFS::VDEV zfs::vdev 3 r1w1e1 DEV gptid/76a4da4d-a465-11df-8d13-0023aea7a3c2 4 r0w0e0 gptid/4a753dd5-a465-11df-8d13-0023aea7a3c2 4 r0w0e0 gptid/06bb1cb5-a463-11df-8d13-0023aea7a3c2 4 r0w0e0 label/swap0 4 r0w0e0 label/boot0 4 r0w0e0 gptid/3471741d-4693-11e1-aaa5-0023aea7a3c2 4 r0w0e0 ada1p3 3 r0w0e0 ada1p2 3 r0w0e0 ada1p1 3 r0w0e0 ada0p4 3 r0w0e0 ada0p3 3 r0w0e0 ada0p2 3 r0w0e0 ada0p1 3 r0w0e0 cd0 2 r0w0e0 ada1 2 r0w0e0 ada0 2 r0w0e0 kern.geom.label.debug: 0 kern.geom.label.ext2fs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.gptid.enable: 1 kern.geom.label.gpt.enable: 1 kern.geom.part.check_integrity: 1 kern.geom.eli.batch: 0 kern.geom.eli.threads: 0 kern.geom.eli.overwrites: 5 kern.geom.eli.visible_passphrase: 2 kern.geom.eli.tries: 3 kern.geom.eli.debug: 0 kern.geom.eli.version: 6 kern.geom.eli.key_cache_misses: 0 kern.geom.eli.key_cache_hits: 0 kern.geom.eli.key_cache_limit: 8192 kern.geom.journal.stats.low_mem: 226 kern.geom.journal.stats.journal_full: 0 kern.geom.journal.stats.wait_for_copy: 0 kern.geom.journal.stats.switches: 0 kern.geom.journal.stats.combined_ios: 0 kern.geom.journal.stats.skipped_bytes: 0 kern.geom.journal.cache.alloc_failures: 0 kern.geom.journal.cache.misses: 0 kern.geom.journal.cache.switch: 90 kern.geom.journal.cache.divisor: 2 kern.geom.journal.cache.limit: 1994932224 kern.geom.journal.cache.used: 0 kern.geom.journal.optimize: 1 kern.geom.journal.record_entries: 20 kern.geom.journal.parallel_copies: 16 kern.geom.journal.accept_immediately: 64 kern.geom.journal.parallel_flushes: 16 kern.geom.journal.force_switch: 70 kern.geom.journal.switch_time: 10 kern.geom.journal.debug: 0 kern.geom.mirror.sync_requests: 2 kern.geom.mirror.disconnect_on_failure: 1 kern.geom.mirror.idletime: 5 kern.geom.mirror.timeout: 4 kern.geom.mirror.debug: 0 kern.elf64.nxstack: 0 kern.elf64.fallback_brand: -1 kern.init_shutdown_timeout: 120 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_suspended: 0 kern.acct_configured: 0 kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_times: 2097783 4591023 925663 67078 57390082 3588112 4868039 1088130 6359 55520659 kern.cp_time: 5685895 9459062 2013793 73437 112910741 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: ttyv0,dcons,/dcons,ttyv0,uart,ucom, kern.openfiles: 7175 kern.eventtimer.choice: HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) HPET5(440) HPET6(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.HPET.flags: 7 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 550 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.HPET4.flags: 3 kern.eventtimer.et.HPET4.frequency: 14318180 kern.eventtimer.et.HPET4.quality: 440 kern.eventtimer.et.HPET5.flags: 3 kern.eventtimer.et.HPET5.frequency: 14318180 kern.eventtimer.et.HPET5.quality: 440 kern.eventtimer.et.HPET6.flags: 3 kern.eventtimer.et.HPET6.frequency: 14318180 kern.eventtimer.et.HPET6.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.periodic: 0 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 75474 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules kern.malloc_count: 377 kern.fallback_elf_brand: -1 kern.features.scbus: 1 kern.features.ata_cam: 1 kern.features.nfscl: 1 kern.features.nfsd: 1 kern.features.geom_label: 1 kern.features.geom_part_bsd: 1 kern.features.geom_part_ebr_compat: 1 kern.features.geom_part_ebr: 1 kern.features.geom_part_gpt: 1 kern.features.geom_part_mbr: 1 kern.features.kposix_priority_scheduling: 1 kern.features.ktrace: 1 kern.features.compat_freebsd7: 1 kern.features.compat_freebsd6: 1 kern.features.compat_freebsd5: 1 kern.features.compat_freebsd4: 1 kern.features.hwpmc_hooks: 1 kern.features.stack: 1 kern.features.sysv_msg: 1 kern.features.sysv_sem: 1 kern.features.sysv_shm: 1 kern.features.posix_shm: 1 kern.features.inet: 1 kern.features.inet6: 1 kern.features.audit: 1 kern.features.security_mac: 1 kern.features.ffs_snapshot: 1 kern.features.softupdates: 1 kern.features.ufs_acl: 1 kern.features.ufs_gjournal: 1 kern.features.geom_eli: 1 kern.features.geom_journal: 1 kern.features.geom_mirror: 1 kern.features.geom_uzip: 1 kern.features.libmchain: 1 kern.features.linuxulator_v4l2: 1 kern.features.linuxulator_v4l: 1 kern.features.cuse4bsd: 1 kern.features.posix_sem: 1 kern.features.p1003_1b_semaphores: 1 kern.conftxt: options CONFIG_AUTOGENERATED ident GENERIC machine amd64 cpu HAMMER makeoptions DEBUG=-g options USB_DEBUG options AH_SUPPORT_AR5416 options IEEE80211_SUPPORT_MESH options IEEE80211_AMPDU_AGE options IEEE80211_DEBUG options SC_PIXEL_MODE options AHD_REG_PRETTY_PRINT options AHC_REG_PRETTY_PRINT options ATA_STATIC_ID options ATA_CAM options SMP options KDB_TRACE options KDB options INCLUDE_CONFIG_FILE options MAC options AUDIT options HWPMC_HOOKS options KBD_INSTALL_CDEV options PRINTF_BUFR_SIZE=128 options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options STACK options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD7 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_FREEBSD32 options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MSDOSFS options NFS_ROOT options NFSLOCKD options NFSD options NFSCL options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options SCTP options INET6 options INET options PREEMPTION options SCHED_ULE options NEW_PCIB options GEOM_PART_MBR options GEOM_PART_EBR_COMPAT options GEOM_PART_EBR options GEOM_PART_BSD device isa device mem device io device uart_ns8250 device cpufreq device acpi device pci device fdc device ahci device ata device mvs device siis device ahc device ahd device esp device hptiop device isp device mpt device mps device sym device trm device adv device adw device aic device bt device scbus device ch device da device sa device cd device pass device ses device amr device arcmsr device ciss device dpt device hptmv device hptrr device iir device ips device mly device twa device aac device aacp device ida device mfi device mlx device twe device tws device atkbdc device atkbd device psm device kbdmux device vga device splash device sc device agp device cbb device pccard device cardbus device uart device ppc device ppbus device lpt device plip device ppi device puc device bxe device de device em device igb device ixgbe device le device ti device txp device vx device miibus device ae device age device alc device ale device bce device bfe device bge device dc device et device fxp device jme device lge device msk device nfe device nge device pcn device re device rl device sf device sge device sis device sk device ste device stge device tl device tx device vge device vr device wb device xl device cs device ed device ex device ep device fe device sn device xe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_amrr device an device ath device ath_pci device ath_hal device ath_rate_sample device ipw device iwi device iwn device malo device mwl device ral device wi device wpi device loop device random device ether device vlan device tun device pty device md device gif device faith device firmware device bpf device uhci device ohci device ehci device xhci device usb device uhid device ukbd device ulpt device umass device ums device urio device u3g device uark device ubsa device uftdi device uipaq device uplcom device uslcom device uvisor device uvscom device aue device axe device cdce device cue device kue device rue device udav device rum device run device uath device upgt device ural device urtw device zyd device firewire device fwe device fwip device dcons device dcons_crom device sound device snd_es137x device snd_hda device snd_ich device snd_uaudio device snd_via8233 kern.maxusers: 384 kern.ident: GENERIC kern.kstack_pages: 4 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.shutdown.show_busybufs: 0 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 0 kern.sugid_coredump: 0 kern.sigqueue.alloc_fail: 0 kern.sigqueue.overflow: 0 kern.sigqueue.preallocate: 1024 kern.sigqueue.max_pending_per_proc: 128 kern.forcesigexit: 1 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-1000000) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 6289118 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 528079846 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 54412 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 2763858518 kern.timecounter.tc.TSC-low.frequency: 11689707 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.threads.max_threads_hits: 0 kern.threads.max_threads_per_proc: 1500 kern.ccpu: 0 kern.sched.cpusetsize: 8 kern.sched.preemption: 1 kern.sched.topology_spec: 0, 1 0, 1 kern.sched.steal_thresh: 1 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 127 kern.sched.balance: 1 kern.sched.affinity: 1 kern.sched.idlespinthresh: 16 kern.sched.idlespins: 10000 kern.sched.static_boost: 152 kern.sched.preempt_thresh: 224 kern.sched.interact: 30 kern.sched.slice: 12 kern.sched.name: ULE kern.devstat.version: 6 kern.devstat.generation: 308 kern.devstat.numdevs: 6 kern.kobj_methodcount: 202 kern.log_wakeups_per_second: 5 kern.vm_guest: none kern.sgrowsiz: 131072 kern.maxssiz: 536870912 kern.dflssiz: 8388608 kern.maxdsiz: 34359738368 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 kern.maxbcache: 0 kern.maxswzone: 33554432 kern.msgbufsize: 65536 kern.nswbuf: 256 kern.nbuf: 25908 kern.ncallout: 30016 kern.hz: 1000 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_add_linefeed: 0 kern.log_console_output: 1 kern.smp.forward_signal_enabled: 1 kern.smp.topology: 0 kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 64 kern.smp.maxid: 1 kern.tty_inq_flush_secure: 1 kern.tty_nout: 12404186 kern.tty_nin: 4269755 kern.minvnodes: 36152 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.elf32.nxstack: 0 kern.elf32.fallback_brand: -1 kern.cryptodevallowsoft: 0 kern.userasymcrypto: 1 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 278) Virtual Memory: (Total: 1090962792K Active: 17032180K) Real Memory: (Total: 2485672K Active: 1591276K) Shared Virtual Memory: (Total: 284960K Active: 219008K) Shared Real Memory: (Total: 106924K Active: 95744K) Free Memory Pages: 390112K vm.loadavg: { 0.08 0.09 0.08 } vm.v_free_min: 6187 vm.v_free_target: 26066 vm.v_free_reserved: 1318 vm.v_inactive_target: 39099 vm.v_cache_min: 26066 vm.v_cache_max: 52132 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.md_malloc_wait: 0 vm.kmem_map_free: 2932174848 vm.kmem_map_size: 802058240 vm.kmem_size_scale: 1 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 3989864448 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.overcommit: 0 vm.swap_reserved: 972223930368 vm.swap_total: 9932107776 vm.zone_count: 208 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.kstacks: 836 vm.kstack_cache_size: 128 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 3864 vm.stats.misc.cnt_prezero: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 48911 vm.stats.vm.v_vforkpages: 112625415 vm.stats.vm.v_forkpages: 341264502 vm.stats.vm.v_kthreads: 23 vm.stats.vm.v_rforks: 76 vm.stats.vm.v_vforks: 207845 vm.stats.vm.v_forks: 665562 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 52132 vm.stats.vm.v_cache_min: 26066 vm.stats.vm.v_cache_count: 8267 vm.stats.vm.v_inactive_count: 114479 vm.stats.vm.v_inactive_target: 39099 vm.stats.vm.v_active_count: 340772 vm.stats.vm.v_wire_count: 420851 vm.stats.vm.v_free_count: 89261 vm.stats.vm.v_free_min: 6187 vm.stats.vm.v_free_target: 26066 vm.stats.vm.v_free_reserved: 1318 vm.stats.vm.v_page_count: 974088 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 1094599017 vm.stats.vm.v_pfree: 254811108 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 651353 vm.stats.vm.v_pdpages: 21918820 vm.stats.vm.v_pdwakeups: 226 vm.stats.vm.v_reactivated: 291743 vm.stats.vm.v_intrans: 13268 vm.stats.vm.v_vnodepgsout: 111282 vm.stats.vm.v_vnodepgsin: 533389 vm.stats.vm.v_vnodeout: 18431 vm.stats.vm.v_vnodein: 533389 vm.stats.vm.v_swappgsout: 31881 vm.stats.vm.v_swappgsin: 8916 vm.stats.vm.v_swapout: 5721 vm.stats.vm.v_swapin: 2043 vm.stats.vm.v_ozfod: 59549 vm.stats.vm.v_zfod: 766506364 vm.stats.vm.v_cow_optim: 7243 vm.stats.vm.v_cow_faults: 29399737 vm.stats.vm.v_vm_faults: 824944413 vm.stats.sys.v_soft: 127171895 vm.stats.sys.v_intr: 334676828 vm.stats.sys.v_syscall: 1846379939 vm.stats.sys.v_trap: 1082843661 vm.stats.sys.v_swtch: 1384188546 vm.stats.object.bypasses: 89814 vm.stats.object.collapses: 3143274 vm.v_free_severe: 3752 vm.old_msync: 0 vm.tryrelock_restart: 1 vm.boot_pages: 64 vm.max_wired: 316689 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 26066 vm.max_launder: 32 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9b000 domain: 0 free list: 0xffffffff811648c8 SEGMENT 1: start: 0x100000 end: 0x200000 domain: 0 free list: 0xffffffff811648c8 SEGMENT 2: start: 0x1737000 end: 0xc72b5000 domain: 0 free list: 0xffffffff81164520 SEGMENT 3: start: 0x100000000 end: 0x127ff0000 domain: 0 free list: 0xffffffff81164520 vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 0 | 0 | 0 5 ( 128K) | 0 | 11 | 0 4 ( 64K) | 19 | 16 | 0 3 ( 32K) | 283 | 34 | 1 2 ( 16K) | 4180 | 26 | 12 1 ( 8K) | 17946 | 118 | 399 0 ( 4K) | 11230 | 3590 | 14836 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 | POOL 2 -- -- -- -- -- -- -- -- 12 ( 16384K) | 0 | 0 | 0 11 ( 8192K) | 0 | 0 | 0 10 ( 4096K) | 0 | 0 | 0 9 ( 2048K) | 0 | 0 | 0 8 ( 1024K) | 0 | 0 | 0 7 ( 512K) | 0 | 0 | 0 6 ( 256K) | 0 | 0 | 0 5 ( 128K) | 0 | 1 | 0 4 ( 64K) | 6 | 0 | 0 3 ( 32K) | 9 | 0 | 0 2 ( 16K) | 8 | 0 | 0 1 ( 8K) | 10 | 1 | 0 0 ( 4K) | 12 | 7 | 0 vm.reserv.reclaimed: 1364 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 41380K, 186 vm.reserv.freed: 255337 vm.reserv.broken: 49 vm.idlezero_enable: 0 vm.kvm_free: 545077063680 vm.kvm_size: 549755809792 vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 144763 vm.pmap.pv_entry_allocs: 1239256707 vm.pmap.pv_entry_frees: 1238620774 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 3631952 vm.pmap.pc_chunk_allocs: 3636599 vm.pmap.pc_chunk_count: 4647 vm.pmap.pv_entry_count: 635933 vm.pmap.pdpe.demotions: 0 vm.pmap.pde.promotions: 226113 vm.pmap.pde.p_failures: 4797272 vm.pmap.pde.mappings: 128 vm.pmap.pde.demotions: 193591 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 2974088 vm.pmap.pg_ps_enabled: 1 vm.pmap.pat_works: 1 vfs.ufs.dirhash_reclaimage: 5 vfs.ufs.dirhash_lowmemcount: 226 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 7655 vfs.ufs.dirhash_maxmem: 6623232 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.rename_restarts: 0 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.keytab_enctype: 1 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.callback_addr: vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 0 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.commit_on_close: 0 vfs.nfs.prime_access_cache: 0 vfs.nfs.access_cache_timeout: 60 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 327 vfs.zfs.l2c_only_size: 0 vfs.zfs.mfu_ghost_data_lsize: 302800896 vfs.zfs.mfu_ghost_metadata_lsize: 325668352 vfs.zfs.mfu_ghost_size: 628469248 vfs.zfs.mfu_data_lsize: 92038144 vfs.zfs.mfu_metadata_lsize: 3072 vfs.zfs.mfu_size: 109752320 vfs.zfs.mru_ghost_data_lsize: 135004160 vfs.zfs.mru_ghost_metadata_lsize: 194714624 vfs.zfs.mru_ghost_size: 329718784 vfs.zfs.mru_data_lsize: 172342784 vfs.zfs.mru_metadata_lsize: 455249408 vfs.zfs.mru_size: 674343936 vfs.zfs.anon_data_lsize: 0 vfs.zfs.anon_metadata_lsize: 0 vfs.zfs.anon_size: 71168 vfs.zfs.l2arc_norw: 1 vfs.zfs.l2arc_feed_again: 1 vfs.zfs.l2arc_noprefetch: 1 vfs.zfs.l2arc_feed_min_ms: 200 vfs.zfs.l2arc_feed_secs: 1 vfs.zfs.l2arc_headroom: 2 vfs.zfs.l2arc_write_boost: 8388608 vfs.zfs.l2arc_write_max: 8388608 vfs.zfs.arc_meta_limit: 729030656 vfs.zfs.arc_meta_used: 729007288 vfs.zfs.arc_min: 364515328 vfs.zfs.arc_max: 2916122624 vfs.zfs.dedup.prefetch: 1 vfs.zfs.mdcomp_disable: 0 vfs.zfs.write_limit_override: 0 vfs.zfs.write_limit_inflated: 12407955456 vfs.zfs.write_limit_max: 516998144 vfs.zfs.write_limit_min: 33554432 vfs.zfs.write_limit_shift: 3 vfs.zfs.no_write_throttle: 0 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.mg_alloc_failures: 8 vfs.zfs.check_hostid: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime_ms: 1000 vfs.zfs.txg.timeout: 5 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 0 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.write_gap_limit: 4096 vfs.zfs.vdev.read_gap_limit: 32768 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: 10 vfs.zfs.vdev.bio_flush_disable: 0 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_replay_disable: 0 vfs.zfs.zio.use_uma: 0 vfs.zfs.version.zpl: 5 vfs.zfs.version.spa: 28 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 vfs.nfsd.server_max_nfsvers: 4 vfs.nfsd.server_min_nfsvers: 2 vfs.nfsd.nfs_privport: 0 vfs.nfsd.enable_locallocks: 0 vfs.nfsd.issue_delegations: 0 vfs.nfsd.commit_miss: 0 vfs.nfsd.commit_blks: 0 vfs.nfsd.mirrormnt: 1 vfs.nfsd.minthreads: 1 vfs.nfsd.maxthreads: 1 vfs.nfsd.threads: 0 vfs.nfsd.request_space_used: 0 vfs.nfsd.request_space_used_highest: 0 vfs.nfsd.request_space_high: 13107200 vfs.nfsd.request_space_low: 8738133 vfs.nfsd.request_space_throttled: 0 vfs.nfsd.request_space_throttle_count: 0 vfs.pfs.trace: 0 vfs.pfs.vncache.misses: 7070 vfs.pfs.vncache.hits: 10320 vfs.pfs.vncache.maxentries: 124 vfs.pfs.vncache.entries: 53 vfs.acl_nfs4_old_semantics: 0 vfs.flushwithdeps: 0 vfs.notbufdflashes: 0 vfs.flushbufqtarget: 100 vfs.getnewbufrestarts: 0 vfs.getnewbufcalls: 130 vfs.hifreebuffers: 2888 vfs.lofreebuffers: 1444 vfs.numfreebuffers: 25908 vfs.dirtybufthresh: 5847 vfs.hidirtybuffers: 6497 vfs.lodirtybuffers: 3248 vfs.numdirtybuffers: 0 vfs.recursiveflushes: 0 vfs.altbufferflushes: 0 vfs.bdwriteskip: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 6684672 vfs.lorunningspace: 4456448 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 129 vfs.hibufspace: 423821312 vfs.lobufspace: 423755776 vfs.maxmallocbufspace: 21191065 vfs.bufmallocspace: 0 vfs.maxbufspace: 424476672 vfs.bufspace: 4194304 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 377472 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 12 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathcalls: 377485 vfs.cache.numupgrades: 3187 vfs.cache.numneghits: 5238609 vfs.cache.numnegzaps: 39942 vfs.cache.numposhits: 73310368 vfs.cache.numposzaps: 141194 vfs.cache.nummisszap: 53980 vfs.cache.nummiss: 3037300 vfs.cache.numchecks: 82210776 vfs.cache.dotdothits: 597911 vfs.cache.dothits: 247798 vfs.cache.numcalls: 82667840 vfs.cache.numcache: 22386 vfs.cache.numneg: 1398 vfs.ncsizefactor: 2 vfs.ncnegfactor: 16 vfs.read_max: 64 vfs.write_behind: 1 vfs.typenumhash: 1 vfs.lookup_shared: 1 vfs.usermount: 1 vfs.worklist_len: 0 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 0 vfs.vlru_allow_cache_src: 0 vfs.freevnodes: 36151 vfs.wantfreevnodes: 36152 vfs.numvnodes: 49571 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 vfs.e2fs.dircheck: 0 vfs.fuse.kernelabi_minor: 8 vfs.fuse.kernelabi_major: 7 vfs.fuse.maxtickets: 0 vfs.fuse.iov_credit: 16 vfs.fuse.iov_permanent_bufsize: 524288 vfs.fuse.maxfreetickets: 1024 vfs.fuse.fuse4bsd_version: 0.3.9-pre1 vfs.fuse.sync_unmount: 1 vfs.fuse.enforce_dev_perms: 0 vfs.fuse.init_backgrounded: 1 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.seqpacket.recvspace: 8192 net.local.seqpacket.maxseqpacket: 8192 net.local.taskcount: 1 net.local.recycled: 0 net.local.deferred: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 256 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.random_id_total: 0 net.inet.ip.random_id_collisions: 0 net.inet.ip.random_id_period: 8192 net.inet.ip.mcast.loop: 1 net.inet.ip.mcast.maxsocksrc: 128 net.inet.ip.mcast.maxgrpsrc: 512 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.icmp.icmplim_output: 1 net.inet.igmp.gsrdelay: 10 net.inet.igmp.default_version: 3 net.inet.igmp.legacysupp: 0 net.inet.igmp.v2enable: 1 net.inet.igmp.v1enable: 1 net.inet.igmp.sendlocal: 1 net.inet.igmp.sendra: 1 net.inet.igmp.recvifkludge: 1 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 536 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.cc.available: newreno net.inet.tcp.cc.algorithm: newreno net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 8 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 2097152 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 36 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1680 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.soreceive_stream: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 31 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.sctp.use_dcccecn: 1 net.inet.sctp.rttvar_steady_step: 20 net.inet.sctp.rttvar_eqret: 0 net.inet.sctp.rttvar_rtt: 5 net.inet.sctp.rttvar_bw: 4 net.inet.sctp.initial_cwnd: 3 net.inet.sctp.buffer_splitting: 0 net.inet.sctp.vtag_time_wait: 60 net.inet.sctp.nat_friendly_init: 0 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_ss_module: 0 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_pf_threshold: 65535 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 3200 net.inet.sctp.fr_maxburst: 4 net.inet.sctp.maxburst: 0 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 1864135 net.inet.sctp.sendspace: 1864135 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 11 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.maxhold: 1 net.link.ether.inet.wait: 20 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.vlan.soft_pad: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.link.ifqmaxlen: 50 net.link.tun.devfs_cloning: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 0 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.ip6.no_radr: 0 net.inet6.ip6.norbit_raif: 0 net.inet6.ip6.rfc6204w3: 0 net.inet6.ip6.mcast.loop: 1 net.inet6.ip6.mcast.maxsocksrc: 128 net.inet6.ip6.mcast.maxgrpsrc: 512 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.inet6.mld.use_allow: 1 net.inet6.mld.v1enable: 1 net.inet6.mld.gsrdelay: 10 net.bpf.zerocopy_enable: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.ifdescr_maxlen: 1024 net.isr.numthreads: 1 net.isr.maxprot: 16 net.isr.defaultqlimit: 256 net.isr.maxqlimit: 10240 net.isr.bindthreads: 0 net.isr.maxthreads: 1 net.isr.direct: 0 net.isr.direct_force: 0 net.isr.dispatch: direct net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.route.netisr_maxqlen: 256 net.wlan.cac_timeout: 60 net.wlan.nol_timeout: 1800 net.wlan.debug: 0 net.wlan.addba_maxtries: 3 net.wlan.addba_backoff: 10000 net.wlan.addba_timeout: 250 net.wlan.recv_bar: 1 net.wlan.ampdu_age: 500 net.wlan.hwmp.inact: 5000 net.wlan.hwmp.rannint: 1000 net.wlan.hwmp.rootint: 2000 net.wlan.hwmp.roottimeout: 5000 net.wlan.hwmp.pathlifetime: 5000 net.wlan.hwmp.replyforward: 1 net.wlan.hwmp.targetonly: 0 net.wlan.mesh.maxretries: 2 net.wlan.mesh.confirmtimeout: 40 net.wlan.mesh.holdingtimeout: 40 net.wlan.mesh.retrytimeout: 40 net.bluetooth.sco.rtx_timeout: 60 net.bluetooth.sco.sockets.seq.queue_drops: 0 net.bluetooth.sco.sockets.seq.queue_maxlen: 300 net.bluetooth.sco.sockets.seq.queue_len: 0 net.bluetooth.sco.sockets.seq.debug_level: 3 net.bluetooth.rfcomm.sockets.stream.timeout: 60 net.bluetooth.rfcomm.sockets.stream.debug_level: 3 net.bluetooth.l2cap.ertx_timeout: 300 net.bluetooth.l2cap.rtx_timeout: 60 net.bluetooth.l2cap.sockets.raw.queue_drops: 0 net.bluetooth.l2cap.sockets.raw.queue_maxlen: 50 net.bluetooth.l2cap.sockets.raw.queue_len: 0 net.bluetooth.l2cap.sockets.raw.ioctl_timeout: 5 net.bluetooth.l2cap.sockets.raw.debug_level: 3 net.bluetooth.l2cap.sockets.seq.queue_drops: 0 net.bluetooth.l2cap.sockets.seq.queue_maxlen: 50 net.bluetooth.l2cap.sockets.seq.queue_len: 0 net.bluetooth.l2cap.sockets.seq.debug_level: 3 net.bluetooth.hci.max_neighbor_age: 600 net.bluetooth.hci.connection_timeout: 60 net.bluetooth.hci.command_timeout: 5 net.bluetooth.hci.sockets.raw.queue_drops: 0 net.bluetooth.hci.sockets.raw.queue_maxlen: 300 net.bluetooth.hci.sockets.raw.queue_len: 0 net.bluetooth.hci.sockets.raw.ioctl_timeout: 5 net.bluetooth.hci.sockets.raw.debug_level: 3 net.bluetooth.version: 1 net.graph.msg_version: 8 net.graph.abi_version: 12 net.graph.maxdata: 512 net.graph.maxalloc: 4096 net.graph.threads: 2 debug.acpi.suspend_bounce: 0 debug.acpi.reset_clock: 1 debug.acpi.interpreter_slack: 1 debug.acpi.enable_debug_objects: 0 debug.acpi.acpi_ca_version: 20110527 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.resume_beep: 0 debug.firewire_debug: 0 debug.fwmem_debug: 0 debug.if_fwe_debug: 0 debug.if_fwip_debug: 0 debug.ipw: 0 debug.iwi: 0 debug.mddebug: 0 debug.wpi: 0 debug.elf64_legacy_coredump: 0 debug.bootverbose: 0 debug.boothowto: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.fail_point.sysctl_running: off debug.fail_point.buf_pressure: off debug.fail_point.nlm_deny_grant: off debug.adaptive_machine_arch: 1 debug.sizeof.cdev_priv: 376 debug.sizeof.cdev: 288 debug.sizeof.g_bioq: 56 debug.sizeof.g_consumer: 96 debug.sizeof.g_provider: 136 debug.sizeof.g_geom: 160 debug.sizeof.g_class: 160 debug.sizeof.kinfo_proc: 1088 debug.sizeof.buf: 608 debug.sizeof.bio: 232 debug.sizeof.proc: 1160 debug.sizeof.vnode: 480 debug.sizeof.devstat: 288 debug.sizeof.namecache: 72 debug.sizeof.znode: 400 debug.osd: 0 debug.trace_on_panic: 1 debug.debugger_on_panic: 1 debug.ncores: 5 debug.to_avg_mpcalls: 992 debug.to_avg_lockcalls: 0 debug.to_avg_gcalls: 1 debug.to_avg_depth: 1230 debug.umtx.umtx_pi_allocated: 0 debug.clocktime: 0 debug.kdb.alt_break_to_debugger: 0 debug.kdb.break_to_debugger: 0 debug.kdb.trap_code: 0 debug.kdb.trap: 0 debug.kdb.panic: 0 debug.kdb.enter: 0 debug.kdb.current: debug.rman_debug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.vfscache: 1 debug.numcachehv: 2532 debug.numcache: 22386 debug.numneg: 1398 debug.nchash: 262143 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.if_tun_debug: 0 debug.nlm_debug: 0 debug.fsckcmds: 0 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.softdep.cleanup_failures: 0 debug.softdep.cleanup_retries: 0 debug.softdep.cleanup_high_delay: 0 debug.softdep.cleanup_inorequests: 0 debug.softdep.cleanup_blkrequests: 0 debug.softdep.jwait_newblk: 0 debug.softdep.jwait_inode: 0 debug.softdep.jwait_freeblks: 0 debug.softdep.jwait_filepage: 0 debug.softdep.journal_wait: 0 debug.softdep.journal_min: 0 debug.softdep.journal_low: 0 debug.softdep.jnewblk_rollback: 0 debug.softdep.jaddref_rollback: 0 debug.softdep.dir_entry: 0 debug.softdep.direct_blk_ptrs: 0 debug.softdep.inode_bitmap: 0 debug.softdep.indir_blk_ptrs: 0 debug.softdep.sync_limit_hit: 0 debug.softdep.ino_limit_hit: 0 debug.softdep.blk_limit_hit: 0 debug.softdep.ino_limit_push: 0 debug.softdep.blk_limit_push: 0 debug.softdep.worklist_push: 0 debug.softdep.maxindirdeps: 50 debug.softdep.tickdelay: 2 debug.softdep.max_softdeps: 578432 debug.softdep.write.jfsync: 0 debug.softdep.write.jtrunc: 0 debug.softdep.write.sbdep: 0 debug.softdep.write.jsegdep: 0 debug.softdep.write.jseg: 0 debug.softdep.write.jfreefrag: 0 debug.softdep.write.jfreeblk: 0 debug.softdep.write.jnewblk: 0 debug.softdep.write.jmvref: 0 debug.softdep.write.jremref: 0 debug.softdep.write.jaddref: 0 debug.softdep.write.freedep: 0 debug.softdep.write.freework: 0 debug.softdep.write.newdirblk: 0 debug.softdep.write.dirrem: 0 debug.softdep.write.mkdir: 0 debug.softdep.write.diradd: 0 debug.softdep.write.freefile: 0 debug.softdep.write.freeblks: 0 debug.softdep.write.freefrag: 0 debug.softdep.write.allocindir: 0 debug.softdep.write.indirdep: 0 debug.softdep.write.allocdirect: 0 debug.softdep.write.newblk: 0 debug.softdep.write.bmsafemap: 0 debug.softdep.write.inodedep: 0 debug.softdep.write.pagedep: 0 debug.softdep.current.jfsync: 0 debug.softdep.current.jtrunc: 0 debug.softdep.current.sbdep: 0 debug.softdep.current.jsegdep: 0 debug.softdep.current.jseg: 0 debug.softdep.current.jfreefrag: 0 debug.softdep.current.jfreeblk: 0 debug.softdep.current.jnewblk: 0 debug.softdep.current.jmvref: 0 debug.softdep.current.jremref: 0 debug.softdep.current.jaddref: 0 debug.softdep.current.freedep: 0 debug.softdep.current.freework: 0 debug.softdep.current.newdirblk: 0 debug.softdep.current.dirrem: 0 debug.softdep.current.mkdir: 0 debug.softdep.current.diradd: 0 debug.softdep.current.freefile: 0 debug.softdep.current.freeblks: 0 debug.softdep.current.freefrag: 0 debug.softdep.current.allocindir: 0 debug.softdep.current.indirdep: 0 debug.softdep.current.allocdirect: 0 debug.softdep.current.newblk: 0 debug.softdep.current.bmsafemap: 0 debug.softdep.current.inodedep: 0 debug.softdep.current.pagedep: 0 debug.softdep.total.jfsync: 0 debug.softdep.total.jtrunc: 0 debug.softdep.total.sbdep: 0 debug.softdep.total.jsegdep: 0 debug.softdep.total.jseg: 0 debug.softdep.total.jfreefrag: 0 debug.softdep.total.jfreeblk: 0 debug.softdep.total.jnewblk: 0 debug.softdep.total.jmvref: 0 debug.softdep.total.jremref: 0 debug.softdep.total.jaddref: 0 debug.softdep.total.freedep: 0 debug.softdep.total.freework: 0 debug.softdep.total.newdirblk: 0 debug.softdep.total.dirrem: 0 debug.softdep.total.mkdir: 0 debug.softdep.total.diradd: 0 debug.softdep.total.freefile: 0 debug.softdep.total.freeblks: 0 debug.softdep.total.freefrag: 0 debug.softdep.total.allocindir: 0 debug.softdep.total.indirdep: 0 debug.softdep.total.allocdirect: 0 debug.softdep.total.newblk: 0 debug.softdep.total.bmsafemap: 0 debug.softdep.total.inodedep: 0 debug.softdep.total.pagedep: 0 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.psm.pkterrthresh: 2 debug.psm.usecs: 500000 debug.psm.secs: 0 debug.psm.errusecs: 0 debug.psm.errsecs: 2 debug.psm.hz: 20 debug.psm.loglevel: 0 debug.fdc.settle: 0 debug.fdc.spec2: 16 debug.fdc.spec1: 175 debug.fdc.retries: 10 debug.fdc.debugflags: 0 debug.fdc.fifo: 8 debug.elf32_legacy_coredump: 0 debug.x86bios.int: 0 debug.x86bios.call: 0 debug.hwpstate_verbose: 0 debug.minidump: 1 debug.crypto_timing: 0 debug.pfugidhack: 0 hw.machine: amd64 hw.model: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 4135985152 hw.usermem: 2412150784 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 4966055936 hw.amr.force_sg32: 0 hw.an.an_cache_iponly: 1 hw.an.an_cache_mcastonly: 0 hw.an.an_cache_mode: dbm hw.an.an_dump: off hw.ata.setmax: 0 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 hw.ath.bstuck: 4 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.anical: 100 hw.ath.resetcal: 1200 hw.ath.shortcal: 100 hw.ath.longcal: 30 hw.bce.rx_ticks: 18 hw.bce.rx_ticks_int: 18 hw.bce.rx_quick_cons_trip: 6 hw.bce.rx_quick_cons_trip_int: 6 hw.bce.tx_ticks: 80 hw.bce.tx_ticks_int: 80 hw.bce.tx_quick_cons_trip: 20 hw.bce.tx_quick_cons_trip_int: 20 hw.bce.loose_rx_mtu: 0 hw.bce.hdr_split: 1 hw.bce.tx_pages: 2 hw.bce.rx_pages: 2 hw.bce.msi_enable: 1 hw.bce.tso_enable: 1 hw.bce.verbose: 1 hw.bge.allow_asf: 1 hw.bxe.mrrs: 4294967295 hw.bxe.tx_ticks: 50 hw.bxe.rx_ticks: 25 hw.bxe.multi_mode: 1 hw.bxe.queue_count: 0 hw.bxe.int_mode: 2 hw.bxe.tso_enable: 1 hw.bxe.dcc_enable: 0 hw.cardbus.cis_debug: 0 hw.cardbus.debug: 0 hw.cs.recv_delay: 570 hw.cs.ignore_checksum_failure: 0 hw.em.eee_setting: 0 hw.em.fc_setting: 3 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 hw.igb.rx_process_limit: 100 hw.igb.num_queues: 0 hw.igb.header_split: 0 hw.igb.max_interrupt_rate: 8000 hw.igb.enable_msix: 1 hw.igb.enable_aim: 1 hw.igb.txd: 1024 hw.igb.rxd: 1024 hw.firewire.hold_count: 0 hw.firewire.try_bmr: 1 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.firewire.phydma_enable: 1 hw.firewire.nocyclemaster: 0 hw.firewire.fwe.rx_queue_len: 128 hw.firewire.fwe.tx_speed: 2 hw.firewire.fwe.stream_ch: 1 hw.firewire.fwip.rx_queue_len: 128 hw.malo.txbuf: 256 hw.malo.rxquota: 256 hw.malo.rxbuf: 256 hw.malo.txcoalesce: 8 hw.malo.pci.msi_disable: 0 hw.mfi.max_cmds: 128 hw.mfi.event_class: 0 hw.mfi.event_locale: 65535 hw.mps.disable_msi: 0 hw.mps.disable_msix: 0 hw.mwl.rxdmalow: 3 hw.mwl.rxquota: 640 hw.mwl.txcoalesce: 8 hw.mwl.txbuf: 256 hw.mwl.rxbuf: 640 hw.mwl.rxdesc: 256 hw.pccard.cis_debug: 0 hw.pccard.debug: 0 hw.cbb.debug: 0 hw.cbb.start_32_io: 4096 hw.cbb.start_16_io: 256 hw.cbb.start_memory: 2281701376 hw.pcic.pd6722_vsense: 1 hw.pcic.intr_mask: 57016 hw.pci.usb_early_takeover: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_suspend: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.default_vgapci_unit: 0 hw.pci.mcfg: 1 hw.pci.host_mem_start: 2147483648 hw.snd.vpc_reset: 0 hw.snd.vpc_0db: 45 hw.snd.vpc_autoreset: 1 hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_matrix: 1 hw.snd.report_soft_formats: 1 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_eq_exact_rate: 0 hw.snd.feeder_eq_presets: PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000 hw.snd.feeder_rate_quality: 1 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.feeder_rate_polyphase_max: 183040 hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97 hw.snd.vpc_mixer_bypass: 1 hw.snd.verbose: 0 hw.snd.maxautovchans: 16 hw.snd.default_unit: 0 hw.snd.version: 2009061500/amd64 hw.snd.default_auto: 1 hw.midi.instroff: 0 hw.midi.dumpraw: 0 hw.midi.debug: 0 hw.midi.stat.verbose: 0 hw.midi.seq.debug: 0 hw.syscons.sc_no_suspend_vtswitch: 0 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.syscons.bell: 0 hw.syscons.saver.keybonly: 1 hw.usb.uaudio.default_channels: 0 hw.usb.uaudio.default_bits: 32 hw.usb.uaudio.default_rate: 0 hw.usb.uaudio.debug: 0 hw.usb.ehci.lostintrbug: 0 hw.usb.ehci.iaadbug: 0 hw.usb.ehci.no_hs: 0 hw.usb.ehci.debug: 0 hw.usb.ohci.debug: 0 hw.usb.uhci.loop: 0 hw.usb.uhci.debug: 0 hw.usb.xhci.debug: 0 hw.usb.no_boot_wait: 0 hw.usb.ctrl.debug: 0 hw.usb.umass.debug: 0 hw.usb.urio.debug: 0 hw.usb.debug: 0 hw.usb.dev.debug: 0 hw.usb.usb_lang_mask: 255 hw.usb.usb_lang_id: 9 hw.usb.template: 0 hw.usb.ugen.debug: 0 hw.usb.power_timeout: 30 hw.usb.uhub.debug: 0 hw.usb.no_pf: 0 hw.usb.proc.debug: 0 hw.usb.pr_recovery_delay: 250 hw.usb.pr_poll_delay: 50 hw.usb.no_cs_fail: 0 hw.usb.aue.debug: 0 hw.usb.axe.debug: 0 hw.usb.cdce.interval: 0 hw.usb.cdce.debug: 0 hw.usb.cue.debug: 0 hw.usb.kue.debug: 0 hw.usb.rue.debug: 0 hw.usb.udav.debug: 0 hw.usb.rum.debug: 0 hw.usb.run.debug: 0 hw.usb.uath.regdomain: 0 hw.usb.uath.countrycode: 0 hw.usb.ural.debug: 0 hw.usb.urtw.preamble_mode: 2 hw.usb.zyd.debug: 0 hw.usb.u3g.debug: 0 hw.usb.ubsa.debug: 0 hw.usb.uftdi.debug: 0 hw.usb.ulpt.debug: 0 hw.usb.uplcom.debug: 0 hw.usb.uslcom.debug: 0 hw.usb.uvisor.debug: 0 hw.usb.uvscom.debug: 0 hw.usb.ucom.cons_baud: 9600 hw.usb.ucom.cons_subunit: 0 hw.usb.ucom.cons_unit: -1 hw.usb.ucom.debug: 0 hw.usb.uhid.debug: 0 hw.usb.ukbd.no_leds: 0 hw.usb.ukbd.debug: 0 hw.usb.ums.debug: 0 hw.wi.debug: 0 hw.wi.txerate: 0 hw.xe.debug: 0 hw.intr_storm_threshold: 1000 hw.pagesizes: 4096 2097152 0 hw.availpages: 1009762 hw.bus.devctl_queue: 1000 hw.bus.devctl_disable: 0 hw.clockrate: 2992 hw.via_feature_xcrypt: 0 hw.via_feature_rng: 0 hw.instruction_sse: 1 hw.psm.tap_timeout: 125000 hw.psm.tap_threshold: 25 hw.psm.tap_enabled: -1 hw.kbd.keymap_restrict_change: 0 hw.busdma.total_bpages: 8323 hw.busdma.zone0.total_bpages: 8323 hw.busdma.zone0.free_bpages: 8319 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 4 hw.busdma.zone0.total_bounced: 4837 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 4096 hw.apic.enable_extint: 0 hw.mca.erratum383: 0 hw.mca.amd10h_L1TP: 1 hw.mca.enabled: 1 hw.mca.count: 0 hw.mca.interval: 3600 hw.mca.force_scan: 0 hw.mmc.debug: 0 hw.sdhci.debug: 0 hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.bwn.wme: 1 hw.bwn.usedma: 1 hw.bwn.hwpctl: 0 hw.bwn.bluetooth: 1 hw.bwn.bfp: 0 hw.drm.msi: 1 hw.dri.0.name: radeon 0x9f pci:0000:01:00.0 hw.dri.0.vm: slot offset size type flags address handle mtrr 0 0x00000000fe9f0000 0x00010000 REG 0x82 0xfffffe00fe9f0000 1 no 1 0xffffff8004f3a000 0x00002000 SHM 0x20 0xffffff8004f3a000 2 no 2 0x00000000d0000000 0x0fff0000 FB 0x10 0x0000000000000000 3 no 3 0xffffff81151b9000 0x00201000 SG 0x0e 0xffffff81151b9000 4 no 4 0xffffff81153ba000 0x00001000 SG 0x0e 0xffffff81153ba000 5 no 5 0xffffff81153bb000 0x00200000 SG 0x00 0xffffff81153bb000 6 no 6 0xffffff81155bb000 0x00bc0000 SG 0x00 0xffffff81155bb000 7 no hw.dri.0.clients: a dev pid uid magic ioctls y dri/card0 2416 0 0 166768260 hw.dri.0.bufs: o size count free segs pages kB 16 65536 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 hw.dri.0.vblank: crtc ref count last enabled inmodeset 00 00 00000000 00000000 01 00 01 00 00000000 00000000 01 00 hw.dri.0.debug: 0 machdep.acpi_timer_freq: 3579545 machdep.enable_panic_key: 0 machdep.rtc_save_period: 1800 machdep.wall_cmos_clock: 1 machdep.adjkerntz: -7200 machdep.disable_rtc_set: 0 machdep.disable_mtrrs: 1 machdep.idle: acpi machdep.idle_available: spin, mwait, hlt, acpi machdep.idle_mwait: 1 machdep.max_ldt_segment: 1024 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.kdb_on_nmi: 1 machdep.acpi_root: 1043456 machdep.i8254_freq: 1193182 machdep.tsc_freq: 2992565106 machdep.disable_tsc_calibration: 0 machdep.disable_tsc: 0 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 200112 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 200112 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 200112 p1003_1b.fsync: 200112 p1003_1b.shared_memory_objects: 200112 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 30 p1003_1b.sem_value_max: 2147483647 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 p1003_1b.nsems: 0 security.jail.param.allow.socket_af: 0 security.jail.param.allow.quotas: 0 security.jail.param.allow.mount: 0 security.jail.param.allow.chflags: 0 security.jail.param.allow.raw_sockets: 0 security.jail.param.allow.sysvipc: 0 security.jail.param.allow.set_hostname: 0 security.jail.param.ip6.saddrsel: 0 security.jail.param.ip6.: 0 security.jail.param.ip4.saddrsel: 0 security.jail.param.ip4.: 0 security.jail.param.cpuset.id: 0 security.jail.param.host.hostid: 0 security.jail.param.host.hostuuid: 64 security.jail.param.host.domainname: 256 security.jail.param.host.hostname: 256 security.jail.param.host.: 0 security.jail.param.children.max: 0 security.jail.param.children.cur: 0 security.jail.param.dying: 0 security.jail.param.persist: 0 security.jail.param.enforce_statfs: 0 security.jail.param.securelevel: 0 security.jail.param.path: 1024 security.jail.param.name: 256 security.jail.param.parent: 0 security.jail.param.jid: 0 security.jail.param.linux.oss_version: 0 security.jail.param.linux.osrelease: 65 security.jail.param.linux.osname: 65 security.jail.param.linux.: 0 security.jail.enforce_statfs: 2 security.jail.mount_allowed: 1 security.jail.chflags_allowed: 1 security.jail.allow_raw_sockets: 1 security.jail.sysvipc_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.jail.jail_max_af_ips: 255 security.jail.jailed: 0 security.bsd.map_at_zero: 0 security.bsd.suser_enabled: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 security.bsd.stack_guard_page: 0 security.mac.labeled: 0 security.mac.max_slots: 4 security.mac.version: 4 security.mac.mmap_revocation_via_cow: 0 security.mac.mmap_revocation: 1 compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.ram.0.%desc: System RAM dev.ram.0.%driver: ram dev.ram.0.%parent: nexus0 dev.cryptosoft.0.%desc: software crypto dev.cryptosoft.0.%driver: cryptosoft dev.cryptosoft.0.%parent: nexus0 dev.acpi.0.%desc: DELL B10K dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.ISA_.MBIO dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=11 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2992 dev.cpu.0.freq_levels: 2992/-1 2618/-1 2244/-1 1870/-1 1496/-1 1122/-1 748/-1 374/-1 dev.cpu.0.cx_supported: C1/1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 439us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 354us dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=12 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=13 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=14 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=15 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=16 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=17 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=18 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=19 dev.pci_link.7.%parent: acpi0 dev.acpi_button.0.%desc: Power Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.VBTN dev.acpi_button.0.%pnpinfo: _HID=PNP0C0C _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=4 dev.pcib.0.%parent: acpi0 dev.pcib.0.wake: 0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=1 function=0 handle=\_SB_.PCI0.PCI1 dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x2e11 subvendor=0x1028 subdevice=0x027f class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.domain: 0 dev.pcib.1.pribus: 0 dev.pcib.1.secbus: 1 dev.pcib.1.subbus: 1 dev.pcib.1.wake: 0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=28 function=0 handle=\_SB_.PCI0.PCI2 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x3a70 subvendor=0x1028 subdevice=0x027f class=0x060400 dev.pcib.2.%parent: pci0 dev.pcib.2.domain: 0 dev.pcib.2.pribus: 0 dev.pcib.2.secbus: 2 dev.pcib.2.subbus: 2 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=28 function=1 handle=\_SB_.PCI0.PCI3 dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x3a72 subvendor=0x1028 subdevice=0x027f class=0x060400 dev.pcib.3.%parent: pci0 dev.pcib.3.domain: 0 dev.pcib.3.pribus: 0 dev.pcib.3.secbus: 3 dev.pcib.3.subbus: 3 dev.pcib.3.wake: 0 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=30 function=0 handle=\_SB_.PCI0.PCI4 dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x1028 subdevice=0x027f class=0x060401 dev.pcib.4.%parent: pci0 dev.pcib.4.domain: 0 dev.pcib.4.pribus: 0 dev.pcib.4.secbus: 4 dev.pcib.4.subbus: 4 dev.pcib.4.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.0.wake: 0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.1.wake: 0 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.3.wake: 0 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%parent: pcib4 dev.pci.4.wake: 0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x2e10 subvendor=0x1028 subdevice=0x027f class=0x060000 dev.hostb.0.%parent: pci0 dev.vgapci.0.%desc: VGA-compatible display dev.vgapci.0.%driver: vgapci dev.vgapci.0.%location: slot=0 function=0 dev.vgapci.0.%pnpinfo: vendor=0x1002 device=0x95c5 subvendor=0x1028 subdevice=0x0342 class=0x030000 dev.vgapci.0.%parent: pci1 dev.vgapm.0.%desc: VGA suspend/resume dev.vgapm.0.%driver: vgapm dev.vgapm.0.%parent: vgapci0 dev.atapci.0.%desc: Intel ATA controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=3 function=2 dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x2e16 subvendor=0x1028 subdevice=0x027f class=0x010185 dev.atapci.0.%parent: pci0 dev.ata.2.%desc: ATA channel 0 dev.ata.2.%driver: ata dev.ata.2.%location: channel=0 dev.ata.2.%parent: atapci0 dev.ata.3.%desc: ATA channel 1 dev.ata.3.%driver: ata dev.ata.3.%location: channel=1 dev.ata.3.%parent: atapci0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 7.2.3 dev.em.0.%driver: em dev.em.0.%location: slot=25 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x10de subvendor=0x1028 subdevice=0x027f class=0x020000 dev.em.0.%parent: pci0 dev.em.0.nvm: -1 dev.em.0.debug: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.eee_control: 0 dev.em.0.link_irq: 0 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1477444160 dev.em.0.rx_control: 67141634 dev.em.0.fc_high_water: 8192 dev.em.0.fc_low_water: 6692 dev.em.0.queue0.txd_head: 366 dev.em.0.queue0.txd_tail: 366 dev.em.0.queue0.tx_irq: 0 dev.em.0.queue0.no_desc_avail: 0 dev.em.0.queue0.rxd_head: 27 dev.em.0.queue0.rxd_tail: 26 dev.em.0.queue0.rx_irq: 0 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 9943058 dev.em.0.mac_stats.good_pkts_recvd: 9943058 dev.em.0.mac_stats.bcast_pkts_recvd: 4798660 dev.em.0.mac_stats.mcast_pkts_recvd: 918765 dev.em.0.mac_stats.rx_frames_64: 0 dev.em.0.mac_stats.rx_frames_65_127: 0 dev.em.0.mac_stats.rx_frames_128_255: 0 dev.em.0.mac_stats.rx_frames_256_511: 0 dev.em.0.mac_stats.rx_frames_512_1023: 0 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 2093029416 dev.em.0.mac_stats.good_octets_txd: 3080911519 dev.em.0.mac_stats.total_pkts_txd: 4879960 dev.em.0.mac_stats.good_pkts_txd: 4879960 dev.em.0.mac_stats.bcast_pkts_txd: 551 dev.em.0.mac_stats.mcast_pkts_txd: 600 dev.em.0.mac_stats.tx_frames_64: 0 dev.em.0.mac_stats.tx_frames_65_127: 0 dev.em.0.mac_stats.tx_frames_128_255: 0 dev.em.0.mac_stats.tx_frames_256_511: 0 dev.em.0.mac_stats.tx_frames_512_1023: 0 dev.em.0.mac_stats.tx_frames_1024_1522: 0 dev.em.0.mac_stats.tso_txd: 7171 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.interrupts.asserts: 12899097 dev.em.0.interrupts.rx_pkt_timer: 0 dev.em.0.interrupts.rx_abs_timer: 0 dev.em.0.interrupts.tx_pkt_timer: 0 dev.em.0.interrupts.tx_abs_timer: 0 dev.em.0.interrupts.tx_queue_empty: 0 dev.em.0.interrupts.tx_queue_min_thresh: 0 dev.em.0.interrupts.rx_desc_min_thresh: 0 dev.em.0.interrupts.rx_overrun: 0 dev.uhci.0.%desc: UHCI (generic) USB controller dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=26 function=0 handle=\_SB_.PCI0.USB3 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x3a67 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.0.wake: 0 dev.uhci.1.%desc: UHCI (generic) USB controller dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=26 function=1 handle=\_SB_.PCI0.USB4 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x3a68 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.1.wake: 0 dev.uhci.2.%desc: UHCI (generic) USB controller dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=26 function=2 handle=\_SB_.PCI0.USB5 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x3a69 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.2.%parent: pci0 dev.uhci.2.wake: 0 dev.uhci.3.%desc: UHCI (generic) USB controller dev.uhci.3.%driver: uhci dev.uhci.3.%location: slot=29 function=0 handle=\_SB_.PCI0.USB0 dev.uhci.3.%pnpinfo: vendor=0x8086 device=0x3a64 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.3.%parent: pci0 dev.uhci.3.wake: 0 dev.uhci.4.%desc: UHCI (generic) USB controller dev.uhci.4.%driver: uhci dev.uhci.4.%location: slot=29 function=1 handle=\_SB_.PCI0.USB1 dev.uhci.4.%pnpinfo: vendor=0x8086 device=0x3a65 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.4.%parent: pci0 dev.uhci.4.wake: 0 dev.uhci.5.%desc: UHCI (generic) USB controller dev.uhci.5.%driver: uhci dev.uhci.5.%location: slot=29 function=2 handle=\_SB_.PCI0.USB2 dev.uhci.5.%pnpinfo: vendor=0x8086 device=0x3a66 subvendor=0x1028 subdevice=0x027f class=0x0c0300 dev.uhci.5.%parent: pci0 dev.uhci.5.wake: 0 dev.usbus.0.%desc: UHCI (generic) USB controller dev.usbus.0.%driver: usbus dev.usbus.0.%parent: uhci0 dev.usbus.1.%desc: UHCI (generic) USB controller dev.usbus.1.%driver: usbus dev.usbus.1.%parent: uhci1 dev.usbus.2.%desc: UHCI (generic) USB controller dev.usbus.2.%driver: usbus dev.usbus.2.%parent: uhci2 dev.usbus.3.%desc: EHCI (generic) USB 2.0 controller dev.usbus.3.%driver: usbus dev.usbus.3.%parent: ehci0 dev.usbus.4.%desc: UHCI (generic) USB controller dev.usbus.4.%driver: usbus dev.usbus.4.%parent: uhci3 dev.usbus.5.%desc: UHCI (generic) USB controller dev.usbus.5.%driver: usbus dev.usbus.5.%parent: uhci4 dev.usbus.6.%desc: UHCI (generic) USB controller dev.usbus.6.%driver: usbus dev.usbus.6.%parent: uhci5 dev.usbus.7.%desc: EHCI (generic) USB 2.0 controller dev.usbus.7.%driver: usbus dev.usbus.7.%parent: ehci1 dev.ehci.0.%desc: EHCI (generic) USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=26 function=7 dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x3a6c subvendor=0x1028 subdevice=0x027f class=0x0c0320 dev.ehci.0.%parent: pci0 dev.ehci.1.%desc: EHCI (generic) USB 2.0 controller dev.ehci.1.%driver: ehci dev.ehci.1.%location: slot=29 function=7 dev.ehci.1.%pnpinfo: vendor=0x8086 device=0x3a6a subvendor=0x1028 subdevice=0x027f class=0x0c0320 dev.ehci.1.%parent: pci0 dev.hdac.0.%desc: Intel 82801JD High Definition Audio Controller dev.hdac.0.%driver: hdac dev.hdac.0.%location: slot=27 function=0 dev.hdac.0.%pnpinfo: vendor=0x8086 device=0x3a6e subvendor=0x1028 subdevice=0x027f class=0x040300 dev.hdac.0.%parent: pci0 dev.hdac.0.polling: 0 dev.hdac.0.polling_interval: 250 dev.hdac.0.pindump: 0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.ISA_ dev.isab.0.%pnpinfo: vendor=0x8086 device=0x3a1a subvendor=0x1028 subdevice=0x027f class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.ahci.0.%desc: AHCI SATA controller dev.ahci.0.%driver: ahci dev.ahci.0.%location: slot=31 function=2 handle=\_SB_.PCI0.IDE1 dev.ahci.0.%pnpinfo: vendor=0x8086 device=0x3a02 subvendor=0x1028 subdevice=0x027f class=0x010601 dev.ahci.0.%parent: pci0 dev.ahcich.0.%desc: AHCI channel dev.ahcich.0.%driver: ahcich dev.ahcich.0.%location: channel=0 dev.ahcich.0.%parent: ahci0 dev.ahcich.1.%desc: AHCI channel dev.ahcich.1.%driver: ahcich dev.ahcich.1.%location: channel=1 dev.ahcich.1.%parent: ahci0 dev.ahcich.2.%desc: AHCI channel dev.ahcich.2.%driver: ahcich dev.ahcich.2.%location: channel=2 dev.ahcich.2.%parent: ahci0 dev.ahcich.3.%desc: AHCI channel dev.ahcich.3.%driver: ahcich dev.ahcich.3.%location: channel=3 dev.ahcich.3.%parent: ahci0 dev.ahcich.4.%desc: AHCI channel dev.ahcich.4.%driver: ahcich dev.ahcich.4.%location: channel=5 dev.ahcich.4.%parent: ahci0 dev.hpet.0.%desc: High Precision Event Timer dev.hpet.0.%driver: hpet dev.hpet.0.%location: handle=\_SB_.HPET dev.hpet.0.%pnpinfo: _HID=PNP0103 _UID=0 dev.hpet.0.%parent: acpi0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.ISA_.DMA_ dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.fpupnp.0.%desc: Legacy ISA coprocessor support dev.fpupnp.0.%driver: fpupnp dev.fpupnp.0.%location: handle=\_SB_.PCI0.ISA_.FPU_ dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.fpupnp.0.%parent: acpi0 dev.atrtc.0.%desc: AT realtime clock dev.atrtc.0.%driver: atrtc dev.atrtc.0.%location: handle=\_SB_.PCI0.ISA_.RTC_ dev.atrtc.0.%pnpinfo: _HID=PNP0B00 _UID=0 dev.atrtc.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.ISA_.TMR_ dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.ppc.0.%desc: Parallel port dev.ppc.0.%driver: ppc dev.ppc.0.%location: handle=\_SB_.PCI0.ISA_.PRT_ dev.ppc.0.%pnpinfo: _HID=PNP0401 _UID=0 dev.ppc.0.%parent: acpi0 dev.ppbus.0.%desc: Parallel port bus dev.ppbus.0.%driver: ppbus dev.ppbus.0.%parent: ppc0 dev.plip.0.%desc: PLIP network interface dev.plip.0.%driver: plip dev.plip.0.%parent: ppbus0 dev.lpt.0.%desc: Printer dev.lpt.0.%driver: lpt dev.lpt.0.%parent: ppbus0 dev.ppi.0.%desc: Parallel I/O dev.ppi.0.%driver: ppi dev.ppi.0.%parent: ppbus0 dev.uart.0.%desc: 16550 or compatible dev.uart.0.%driver: uart dev.uart.0.%location: handle=\_SB_.PCI0.ISA_.COMA dev.uart.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.uart.0.%parent: acpi0 dev.apic.0.%desc: APIC resources dev.apic.0.%driver: apic dev.apic.0.%parent: nexus0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%parent: isa0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.pcm.0.%desc: HDA Analog Devices AD1984A PCM #0 Analog dev.pcm.0.%driver: pcm dev.pcm.0.%parent: hdac0 dev.pcm.0.play.vchans: 4 dev.pcm.0.play.vchanmode: fixed dev.pcm.0.play.vchanrate: 48000 dev.pcm.0.play.vchanformat: s16le:2.0 dev.pcm.0.rec.vchans: 4 dev.pcm.0.rec.vchanmode: fixed dev.pcm.0.rec.vchanrate: 48000 dev.pcm.0.rec.vchanformat: s16le:2.0 dev.pcm.0.buffersize: 16384 dev.pcm.0.bitperfect: 0 dev.pcm.1.%desc: HDA Analog Devices AD1984A PCM #1 Analog dev.pcm.1.%driver: pcm dev.pcm.1.%parent: hdac0 dev.pcm.1.play.vchans: 1 dev.pcm.1.play.vchanmode: fixed dev.pcm.1.play.vchanrate: 48000 dev.pcm.1.play.vchanformat: s16le:2.0 dev.pcm.1.rec.vchans: 1 dev.pcm.1.rec.vchanmode: fixed dev.pcm.1.rec.vchanrate: 48000 dev.pcm.1.rec.vchanformat: s16le:2.0 dev.pcm.1.buffersize: 16384 dev.pcm.1.bitperfect: 0 dev.uhub.0.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usbus0 dev.uhub.1.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usbus1 dev.uhub.2.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usbus2 dev.uhub.3.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%parent: usbus3 dev.uhub.4.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.4.%driver: uhub dev.uhub.4.%parent: usbus4 dev.uhub.5.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.5.%driver: uhub dev.uhub.5.%parent: usbus5 dev.uhub.6.%desc: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.6.%driver: uhub dev.uhub.6.%parent: usbus6 dev.uhub.7.%desc: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.7.%driver: uhub dev.uhub.7.%parent: usbus7 dev.uhub.9.%desc: Dell USB Keyboard Hub dev.uhub.9.%driver: uhub dev.uhub.9.%location: bus=1 hubaddr=1 port=4 devaddr=3 interface=0 dev.uhub.9.%pnpinfo: vendor=0x413c product=0x1002 devclass=0x09 devsubclass=0x00 sernum="" release=0x0200 mode=host intclass=0x09 intsubclass=0x00 intprotocol=0x00 dev.uhub.9.%parent: uhub4 dev.uhub.8.%desc: vendor 0x0424 product 0x2504, class 9/0, rev 2.00/0.01, addr 2 dev.uhub.8.%driver: uhub dev.uhub.8.%location: bus=1 hubaddr=5 port=7 devaddr=2 interface=0 dev.uhub.8.%pnpinfo: vendor=0x0424 product=0x2504 devclass=0x09 devsubclass=0x00 sernum="" release=0x0001 mode=host intclass=0x09 intsubclass=0x00 intprotocol=0x01 dev.uhub.8.%parent: uhub7 dev.ums.0.%desc: vendor 0x0461 DELL Laser Mouse, class 0/0, rev 2.00/7.17, addr 2 dev.ums.0.%driver: ums dev.ums.0.%location: bus=1 hubaddr=1 port=0 devaddr=2 interface=0 dev.ums.0.%pnpinfo: vendor=0x0461 product=0x4d51 devclass=0x00 devsubclass=0x00 sernum="" release=0x0717 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x02 dev.ums.0.%parent: uhub0 dev.ums.0.parseinfo: i1: X:r0, p8, s12; Y:r0, p20, s12; Z:r0, p32, s8; B1:r0, p0, s1; B2:r0, p1, s1; B3:r0, p2, s1; B4:r0, p3, s1; B5:r0, p4, s1; dev.ukbd.0.%desc: DELL Dell QuietKey Keyboard, class 0/0, rev 1.10/1.01, addr 2 dev.ukbd.0.%driver: ukbd dev.ukbd.0.%location: bus=1 hubaddr=2 port=4 devaddr=2 interface=0 dev.ukbd.0.%pnpinfo: vendor=0x413c product=0x2106 devclass=0x00 devsubclass=0x00 sernum="" release=0x0101 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 dev.ukbd.0.%parent: uhub4 dev.ukbd.1.%desc: Dell USB Keyboard Hub dev.ukbd.1.%driver: ukbd dev.ukbd.1.%location: bus=3 hubaddr=1 port=4 devaddr=4 interface=0 dev.ukbd.1.%pnpinfo: vendor=0x413c product=0x2002 devclass=0x00 devsubclass=0x00 sernum="" release=0x0200 mode=host intclass=0x03 intsubclass=0x01 intprotocol=0x01 dev.ukbd.1.%parent: uhub9 dev.drm.0.%desc: ATI Radeon HD 3450 dev.drm.0.%driver: drm dev.drm.0.%parent: vgapci0 dev.uhid.0.%desc: Dell USB Keyboard Hub dev.uhid.0.%driver: uhid dev.uhid.0.%location: bus=3 hubaddr=1 port=4 devaddr=4 interface=1 dev.uhid.0.%pnpinfo: vendor=0x413c product=0x2002 devclass=0x00 devsubclass=0x00 sernum="" release=0x0200 mode=host intclass=0x03 intsubclass=0x00 intprotocol=0x00 dev.uhid.0.%parent: uhub9 hptmv.status: RocketRAID 18xx SATA Controller driver Version v1.16 kstat.zfs.misc.xuio_stats.onloan_read_buf: 0 kstat.zfs.misc.xuio_stats.onloan_write_buf: 0 kstat.zfs.misc.xuio_stats.read_buf_copied: 0 kstat.zfs.misc.xuio_stats.read_buf_nocopy: 0 kstat.zfs.misc.xuio_stats.write_buf_copied: 0 kstat.zfs.misc.xuio_stats.write_buf_nocopy: 26748 kstat.zfs.misc.zfetchstats.hits: 0 kstat.zfs.misc.zfetchstats.misses: 0 kstat.zfs.misc.zfetchstats.colinear_hits: 0 kstat.zfs.misc.zfetchstats.colinear_misses: 0 kstat.zfs.misc.zfetchstats.stride_hits: 0 kstat.zfs.misc.zfetchstats.stride_misses: 0 kstat.zfs.misc.zfetchstats.reclaim_successes: 0 kstat.zfs.misc.zfetchstats.reclaim_failures: 0 kstat.zfs.misc.zfetchstats.streams_resets: 0 kstat.zfs.misc.zfetchstats.streams_noresets: 0 kstat.zfs.misc.zfetchstats.bogus_streams: 0 kstat.zfs.misc.arcstats.hits: 71718531 kstat.zfs.misc.arcstats.misses: 425676 kstat.zfs.misc.arcstats.demand_data_hits: 66692016 kstat.zfs.misc.arcstats.demand_data_misses: 128441 kstat.zfs.misc.arcstats.demand_metadata_hits: 5026508 kstat.zfs.misc.arcstats.demand_metadata_misses: 297122 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 73 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 7 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 40 kstat.zfs.misc.arcstats.mru_hits: 9729303 kstat.zfs.misc.arcstats.mru_ghost_hits: 124152 kstat.zfs.misc.arcstats.mfu_hits: 61989221 kstat.zfs.misc.arcstats.mfu_ghost_hits: 35142 kstat.zfs.misc.arcstats.allocated: 5611652 kstat.zfs.misc.arcstats.deleted: 2596745 kstat.zfs.misc.arcstats.stolen: 141841 kstat.zfs.misc.arcstats.recycle_miss: 53387 kstat.zfs.misc.arcstats.mutex_miss: 17 kstat.zfs.misc.arcstats.evict_skip: 1041 kstat.zfs.misc.arcstats.evict_l2_cached: 0 kstat.zfs.misc.arcstats.evict_l2_eligible: 17147533824 kstat.zfs.misc.arcstats.evict_l2_ineligible: 1558528 kstat.zfs.misc.arcstats.hash_elements: 139187 kstat.zfs.misc.arcstats.hash_elements_max: 160731 kstat.zfs.misc.arcstats.hash_collisions: 5083034 kstat.zfs.misc.arcstats.hash_chains: 40062 kstat.zfs.misc.arcstats.hash_chain_max: 15 kstat.zfs.misc.arcstats.p: 796857848 kstat.zfs.misc.arcstats.c: 1004182626 kstat.zfs.misc.arcstats.c_min: 364515328 kstat.zfs.misc.arcstats.c_max: 2916122624 kstat.zfs.misc.arcstats.size: 993492152 kstat.zfs.misc.arcstats.hdr_size: 34078192 kstat.zfs.misc.arcstats.data_size: 784222208 kstat.zfs.misc.arcstats.other_size: 175191752 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_read_bytes: 0 kstat.zfs.misc.arcstats.l2_write_bytes: 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.arcstats.l2_write_trylock_fail: 0 kstat.zfs.misc.arcstats.l2_write_passed_headroom: 0 kstat.zfs.misc.arcstats.l2_write_spa_mismatch: 0 kstat.zfs.misc.arcstats.l2_write_in_l2: 0 kstat.zfs.misc.arcstats.l2_write_io_in_progress: 0 kstat.zfs.misc.arcstats.l2_write_not_cacheable: 18 kstat.zfs.misc.arcstats.l2_write_full: 0 kstat.zfs.misc.arcstats.l2_write_buffer_iter: 0 kstat.zfs.misc.arcstats.l2_write_pios: 0 kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_iter: 0 kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 0 kstat.zfs.misc.vdev_cache_stats.hits: 0 kstat.zfs.misc.vdev_cache_stats.misses: 0 --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="UTF-8"; name="messages.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages.out" Feb 8 10:50:33 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 10:50:33 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 11:57:00 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 11:57:01 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 11:58:06 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 11:58:06 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:14:05 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:14:05 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:16:35 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:16:35 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:19:05 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:19:17 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:22:25 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:22:25 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:33:13 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:33:14 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 12:34:17 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 12:34:18 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 13:08:22 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 13:08:22 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 13:10:52 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 13:10:52 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 13:13:22 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 13:13:22 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 14:04:10 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 14:04:10 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 14:33:42 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 14:33:42 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 14:36:12 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 14:36:12 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 14:37:20 jeep sudo: jhugo : TTY=unknown ; PWD=/usr/home/jhugo ; USER=root ; COMMAND=/usr/local/bin/pc-fbsdupdatecheck Feb 8 16:49:15 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 16:49:16 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 16:51:45 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 16:51:45 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 16:54:15 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 16:54:15 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 21:08:40 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 21:08:40 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 21:13:40 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 21:13:40 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 21:16:10 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 21:16:10 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 21:18:40 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 8 21:18:40 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 8 23:07:17 jeep sshd[8884]: error: PAM: authentication error for jhugo from 2001:4200:7000:100:21c:bfff:fe73:34f6 Feb 9 10:51:17 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 10:51:17 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 11:05:45 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 11:05:45 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 11:08:15 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 11:08:15 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 11:10:45 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 11:10:45 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 11:29:22 jeep su: jhugo to root on /dev/pts/28 Feb 9 11:55:21 jeep su: jhugo to root on /dev/pts/29 Feb 9 11:56:22 jeep kernel: ugen4.3: at usbus4 Feb 9 11:56:22 jeep kernel: uhub9: on usbus4 Feb 9 11:56:22 jeep kernel: uhub9: 3 ports with 2 removable, bus powered Feb 9 11:56:23 jeep kernel: ugen4.4: at usbus4 Feb 9 11:56:23 jeep kernel: ukbd1: on usbus4 Feb 9 11:56:23 jeep kernel: kbd3 at ukbd1 Feb 9 11:56:23 jeep kernel: uhid0: on usbus4 Feb 9 11:56:56 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 11:56:56 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 12:02:02 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 12:02:03 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 12:04:32 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 12:04:33 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 12:07:02 jeep dbus[2077]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Feb 9 12:07:03 jeep dbus[2077]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Feb 9 12:16:01 jeep kernel: ugen4.3: at usbus4 (disconnected) Feb 9 12:16:01 jeep kernel: uhub9: at uhub4, port 1, addr 3 (disconnected) Feb 9 12:16:01 jeep kernel: ugen4.4: at usbus4 (disconnected) Feb 9 12:16:01 jeep kernel: ukbd1: at uhub9, port 1, addr 4 (disconnected) Feb 9 12:16:01 jeep kernel: uhid0: at uhub9, port 1, addr 4 (disconnected) Feb 9 12:16:36 jeep kernel: ugen4.3: at usbus4 Feb 9 12:16:36 jeep kernel: uhub9: on usbus4 Feb 9 12:16:36 jeep kernel: uhub9: 3 ports with 2 removable, bus powered Feb 9 12:16:37 jeep kernel: ugen4.4: at usbus4 Feb 9 12:16:37 jeep kernel: ukbd1: on usbus4 Feb 9 12:16:37 jeep kernel: kbd3 at ukbd1 Feb 9 12:16:37 jeep kernel: uhid0: on usbus4 Feb 9 12:17:32 jeep kernel: ugen4.3: at usbus4 (disconnected) Feb 9 12:17:32 jeep kernel: uhub9: at uhub4, port 1, addr 3 (disconnected) Feb 9 12:17:32 jeep kernel: ugen4.4: at usbus4 (disconnected) Feb 9 12:17:32 jeep kernel: ukbd1: at uhub9, port 1, addr 4 (disconnected) Feb 9 12:17:32 jeep kernel: uhid0: at uhub9, port 1, addr 4 (disconnected) Feb 9 12:19:20 jeep kernel: ugen4.3: at usbus4 Feb 9 12:19:20 jeep kernel: uhub9: on usbus4 Feb 9 12:19:20 jeep kernel: uhub9: 3 ports with 2 removable, bus powered Feb 9 12:19:21 jeep kernel: ugen4.4: at usbus4 Feb 9 12:19:21 jeep kernel: ukbd1: on usbus4 Feb 9 12:19:21 jeep kernel: kbd3 at ukbd1 Feb 9 12:19:21 jeep kernel: uhid0: on usbus4 Feb 9 12:27:49 jeep kernel: ugen3.2: at usbus3 (disconnected) Feb 9 12:27:49 jeep kernel: uhub8: at uhub3, port 2, addr 2 (disconnected) Feb 9 12:27:52 jeep kernel: ugen7.2: at usbus7 Feb 9 12:27:52 jeep kernel: uhub8: on usbus7 Feb 9 12:27:53 jeep kernel: uhub8: 4 ports with 4 removable, self powered --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: text/plain; charset="UTF-8"; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 root@build9x64.pcbsd.org:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.57-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3959779328 (3776 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Length mismatch for 3 range: ec00001 vs ec00000 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc00-0xdcff mem 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff irq 16 at device 0.0 on pci1 pci0: at device 3.0 (no driver attached) atapci0: port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 ata2: on atapci0 ata3: on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0xecc0-0xecdf mem 0xfebe0000-0xfebfffff,0xfebd9000-0xfebd9fff irq 21 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:23:ae:a7:a3:c2 uhci0: port 0xff20-0xff3f irq 16 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0xff00-0xff1f irq 17 at device 26.1 on pci0 usbus1: on uhci1 uhci2: port 0xfc00-0xfc1f irq 22 at device 26.2 on pci0 usbus2: on uhci2 ehci0: mem 0xfebda000-0xfebda3ff irq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xfebdc000-0xfebdffff irq 16 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 ACPI Warning: For \\_SB_.PCI0.PCI2._PRT: Return Package has no elements (empty) (20110527/nspredef-500) pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 uhci3: port 0xff80-0xff9f irq 23 at device 29.0 on pci0 usbus4: on uhci3 uhci4: port 0xff60-0xff7f irq 17 at device 29.1 on pci0 usbus5: on uhci4 uhci5: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 usbus6: on uhci5 ehci1: mem 0xff980000-0xff9803ff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20-0xfe27,0xfe30-0xfe33,0xfec0-0xfedf irq 18 at device 31.2 on pci0 ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Event timer "HPET5" frequency 14318180 Hz quality 440 Event timer "HPET6" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x7f irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x5f irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd1fff,0xd2000-0xd47ff,0xd4800-0xd7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092006000920 device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616092006000920 device_attach: est1 attach returned 6 p4tcc1: on cpu1 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x168 offMax=0x288 hdac0: HDA Codec #2: Analog Devices AD1984A pcm0: at cad 2 nid 1 on hdac0 pcm1: at cad 2 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ada0 at ahcich0 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad8 ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad10 lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 11689707 Hz quality 1000 cd0 at ahcich2 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 usbus3 ugen3.2: at usbus3 uhub8: on usbus3 ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=0 Root mount waiting for: usbus3 uhub8: 4 ports with 4 removable, self powered ugen4.2: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 Root mount waiting for: usbus3 usb_alloc_device: set address 3 failed (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED Root mount waiting for: usbus3 usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED ugen3.3: at usbus3 (disconnected) uhub_reattach_port: could not allocate new device Trying to mount root from zfs:tank0 []... Cuse4BSD v0.1.21 @ /dev/cuse WARNING: attempt to domain_add(bluetooth) after domainfinalize() fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Initialized radeon 1.31.0 20080613 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV620 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs usb_alloc_device: set address 3 failed (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED ugen3.3: at usbus3 (disconnected) uhub_reattach_port: could not allocate new device ugen3.3: at usbus3 uftdi0: on usbus3 ugen3.3: at usbus3 (disconnected) uftdi0: at uhub8, port 3, addr 3 (disconnected) ugen4.3: at usbus4 uhub9: on usbus4 uhub9: 3 ports with 2 removable, bus powered ugen4.4: at usbus4 ukbd1: on usbus4 kbd3 at ukbd1 uhid0: on usbus4 ugen4.3: at usbus4 (disconnected) uhub9: at uhub4, port 1, addr 3 (disconnected) ugen4.4: at usbus4 (disconnected) ukbd1: at uhub9, port 1, addr 4 (disconnected) uhid0: at uhub9, port 1, addr 4 (disconnected) ugen4.3: at usbus4 uhub9: on usbus4 uhub9: 3 ports with 2 removable, bus powered ugen4.4: at usbus4 ukbd1: on usbus4 kbd3 at ukbd1 uhid0: on usbus4 ugen4.3: at usbus4 (disconnected) uhub9: at uhub4, port 1, addr 3 (disconnected) ugen4.4: at usbus4 (disconnected) ukbd1: at uhub9, port 1, addr 4 (disconnected) uhid0: at uhub9, port 1, addr 4 (disconnected) ugen4.3: at usbus4 uhub9: on usbus4 uhub9: 3 ports with 2 removable, bus powered ugen4.4: at usbus4 ukbd1: on usbus4 kbd3 at ukbd1 uhid0: on usbus4 ugen3.2: at usbus3 (disconnected) uhub8: at uhub3, port 2, addr 2 (disconnected) ugen7.2: at usbus7 uhub8: on usbus7 uhub8: 4 ports with 4 removable, self powered --Boundary-00=_dMjOPi/dzL7RXJ5 Content-Type: application/octet-stream; name="ukbd0.dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ukbd0.dump" DgCQmgACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8BQAAgqMzTwAAAAACbgkAAAAAAJgAAACY AAAAIAAAAAAAAACYAAAABwAAAAIAAAAQAAAAo6EMAAAAAAAAAAAAAgAAAEAAAAABAAAAgAAAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAACAAAAowAAAAEABAAEAAAAAQAAAIKjM08AAAAA im4JAAAAAACUAAAAlAAAACAAAAAAAAAAlAAAAAcAAAACAAEAEAAAAKGhDgAAAAAAAAAAAAIAAABA AAAAAQAAAIAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQAAAADAAAAAAEA ACcsJyeCozNPAAAAAJFuCQAAAAAAmAAAAJgAAAAgAAAAAAAAAJgAAAAHAAAAAgAAABAAAACjoQ4A AAAAAAAAAAACAAAAQAAAAAEAAACAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAIA AACjAAAAAgAEAAQAAAABAAAAgqMzTwAAAAAEbwkAAAAAAJQAAACUAAAAIAAAAAAAAACUAAAABwAA AAIAAQAQAAAAoaEMAAAAAAAAAAAAAgAAAEAAAAABAAAAgAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAgAAAAAAAAABAAAAAMAAAAAAQAAXCJodIKjM08AAAAAC28JAAAAAACYAAAAmAAAACAA AAAAAAAAmAAAAAcAAAACAAAAEAAAAKOhDAAAAAAAAAAAAAIAAABAAAAAAQAAAIAAAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAgAAAKMAAAADAAQABAAAAAEAAACCozNPAAAAAIBvCQAA AAAAlAAAAJQAAAAgAAAAAAAAAJQAAAAHAAAAAgABABAAAAChoQ4AAAAAAAAAAAACAAAAQAAAAAEA AACAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAEAAAAAwAAAAABAABcIi9z gqMzTwAAAACGbwkAAAAAAJgAAACYAAAAIAAAAAAAAACYAAAABwAAAAIAAAAQAAAAo6EOAAAAAAAA AAAAAgAAAEAAAAABAAAAgAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAACAAAAowAA AAQABAAEAAAAAQAAAIKjM08AAAAA/W8JAAAAAACUAAAAlAAAACAAAAAAAAAAlAAAAAcAAAACAAEA EAAAAKGhDAAAAAAAAAAAAAIAAABAAAAAAQAAAIAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAIAAAAAAAAAAQAAAADAAAAAAEAALwFAACGozNPAAAAAAZuCQAAAAAAmAAAAJgAAAAgAAAAAAAA AJgAAAAHAAAAAgAAABAAAACjoQwAAAAAAAAAAAACAAAAQAAAAAEAAACAAAAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACAAAAAIAAACjAAAAAQAEAAQAAAABAAAAhqMzTwAAAACBbgkAAAAAAJQA AACUAAAAIAAAAAAAAACUAAAABwAAAAIAAQAQAAAAoaEOAAAAAAAAAAAAAgAAAEAAAAABAAAAgAAA AAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAMAAAAAAQAAbWR2YoajM08A AAAAiG4JAAAAAACYAAAAmAAAACAAAAAAAAAAmAAAAAcAAAACAAAAEAAAAKOhDgAAAAAAAAAAAAIA AABAAAAAAQAAAIAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAgAAAKMAAAACAAQA BAAAAAEAAACGozNPAAAAAPBuCQAAAAAAlAAAAJQAAAAgAAAAAAAAAJQAAAAHAAAAAgABABAAAACh oQwAAAAAAAAAAAACAAAAQAAAAAEAAACAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAA AAAAAAAEAAAAAwAAAAABAABmNzEzhqMzTwAAAAD3bgkAAAAAAJgAAACYAAAAIAAAAAAAAACYAAAA BwAAAAIAAAAQAAAAo6EMAAAAAAAAAAAAAgAAAEAAAAABAAAAgAAAAAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAgAAAACAAAAowAAAAMABAAEAAAAAQAAAIajM08AAAAAcm8JAAAAAACUAAAAlAAA ACAAAAAAAAAAlAAAAAcAAAACAAEAEAAAAKGhDgAAAAAAAAAAAAIAAABAAAAAAQAAAIAAAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQAAAADAAAAAAEAADJkc1qGozNPAAAAAHlv CQAAAAAAmAAAAJgAAAAgAAAAAAAAAJgAAAAHAAAAAgAAABAAAACjoQ4AAAAAAAAAAAACAAAAQAAA AAEAAACAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAIAAACjAAAABAAEAAQAAAAB AAAAhqMzTwAAAADsbwkAAAAAAJQAAACUAAAAIAAAAAAAAACUAAAABwAAAAIAAQAQAAAAoaEMAAAA AAAAAAAAAgAAAEAAAAABAAAAgAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAA BAAAAAMAAAAAAQAA --Boundary-00=_dMjOPi/dzL7RXJ5-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 10:31:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C0D1065673 for ; Tue, 14 Feb 2012 10:31:56 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ED2248FC19 for ; Tue, 14 Feb 2012 10:31:55 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4218C.dip.t-dialin.net [79.196.33.140]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 69BAD8448D4; Tue, 14 Feb 2012 11:31:24 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 91FAA2FEC; Tue, 14 Feb 2012 11:31:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329215481; bh=e08cBNm+RfGuajNpPAR2wfspbPscxLrupBRSXS36H30=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version:Content-Transfer-Encoding; b=K+1PyvxtvI5k8NeiPueTRI3xC9JyklI0SS2Gg7nAlhGSOfM+o01jYfQBqs68FkdGR yNa27sCjLTob4O9TPNlmt/6Y2kcLQWMq6+a+v4nEye9VWYOYlBUwI7uqFrFzYEufBX eAK811w67SXQhcuiv8I40HicRCByaEE/xDaLZGIA7ItyoR0eLDQS1+MlAVMh17twui 7xowgXB9yBavPP1VLLppxSFb5OxaQqym/lulLKf0OaTlHQfZqY00J8EkD4HmSjugPl 70kuVWBDGYyi4aEb7SAakslTzJLDgYUvzby58RAR1/A9jEhpSmX9O68RMhexlFeC2C w0zttw2u6J1nA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1EAVKdq015062; Tue, 14 Feb 2012 11:31:20 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 14 Feb 2012 11:31:20 +0100 Date: Tue, 14 Feb 2012 11:31:20 +0100 Message-ID: <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> From: Alexander Leidinger To: Paul Schenkeveld References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210144449.GA2358@psconsult.nl> In-Reply-To: <20120210144449.GA2358@psconsult.nl> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 69BAD8448D4.A239F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.766, required 6, autolearn=disabled, AWL -0.66, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329820286.18387@X9ykEV6ydnI4XUNyVGUkSQ X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 14 Feb 2012 10:31:56 -0000 Quoting Paul Schenkeveld (from Fri, 10 Feb 2012 15:44:50 +0100): > On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: >> Hi, >> >> during some big discussions in the last monts on various lists, one of >> the problems was that some people would like to use freebsd-update but >> can't as they are using a custom kernel. With all the kernel modules >> we provide, the need for a custom kernel should be small, but on the >> other hand, we do not provide a small kernel-skeleton where you can >> load just the modules you need. >> >> This should be easy to change. As a first step I took the generic >> kernel and removed all devices which are available as modules, e.g. >> the USB section consists now only of the USB_DEBUG option (so that the >> module is build like with the current generic kernel). I also removed >> some storage drivers which are not available as a module. The >> rationale is, that I can not remove CAM from the kernel config if I >> let those drivers inside (if those drivers are important enough, >> someone will probably fix the problem and add the missing pieces to >> generate a module). >> >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >> >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options zhich are not enabled in GENERIC)? Are there options >> which you add which you can not add as a module (SW_WATCHDOG comes to >> my mind)? If yes, which ones and how important are they for you? > > - INET without INET6 > - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) > - Bj=F6rn may add INET6 without INET > - SCHED_ULE vs. SCHED_4BSD > - No vga console/atkbd/psm for embedded devices > - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices Embedded devices are out of the scope of this, normally you do a lot of other modifictions to such systems anyway, so a custom kernel should be not a big problem. I will also not touch the dual-stack part of the kernel config (it shall still allow the generic purpose computing like the GERNERIC config). > - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls Request noted. > I also always specify exactly one CPU type (on i386), know it made a > difference in the 386/486/586 era but am not sure how much difference > it makes nowadays. The 386 part (which we do not have anymore in GENERIC) made a difference, the rest doesn't hurt in the kernel. Bye, Alexander. -- Smuggling... It's not just a job, it's an adventure! -- paid for by your local Colombian recruiting office http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 10:36:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 315FA1065673; Tue, 14 Feb 2012 10:36:37 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id DBFD08FC12; Tue, 14 Feb 2012 10:36:36 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id DD8CE6DE1; Tue, 14 Feb 2012 10:36:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AE7B98419; Tue, 14 Feb 2012 11:36:35 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Jason Hellenthal References: <20120211065857.GA66606@DataIX.net> Date: Tue, 14 Feb 2012 11:36:35 +0100 In-Reply-To: <20120211065857.GA66606@DataIX.net> (Jason Hellenthal's message of "Sat, 11 Feb 2012 01:58:57 -0500") Message-ID: <86zkclem6k.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, dougb@freebsd.org, bapt@freebsd.org Subject: Re: dhclient script adjustments 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, 14 Feb 2012 10:36:37 -0000 Jason Hellenthal writes: > After recent merges to stable/8 I am now seeing errors on bootup of > the following for three interfaces that will never see the light of > DHCP. ? > > /etc/rc.d/dhclient: ERROR: 'dc1' is not a DHCP-enabled interface This is perfectly harmless. Just ignore these messages. They will go away as soon as r230388 is MFCed. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 11:38:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC8B106564A for ; Tue, 14 Feb 2012 11:38:16 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 222FD8FC12 for ; Tue, 14 Feb 2012 11:38:16 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4218C.dip.t-dialin.net [79.196.33.140]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 5A4C18448CE for ; Tue, 14 Feb 2012 12:38:00 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 8EAA02FF4 for ; Tue, 14 Feb 2012 12:37:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329219477; bh=fQD5VNqaNNaKwsca5gAKltex1tdGrFqt9pW4OBP1IGU=; h=Date:Message-ID:From:To:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=pvYkISj4ss6y3w1kWpxEnSkVT5wPBKNbWAGqBZdTJolaDc6Fue+kGH6fzpfNZP3uC 2Z/BvIPPILJ/imaUWocATpJRgMJiUsdnKeJkfTSwIrCa8n0gkuhWFlxAXu6hTiE1nR sgSat2zwdMD0V2U5hNr3MWJgN62ByTVcpRHMFCJ8Tu/6/NMdH7j6t0nBtfavYFBwZQ lUHYaP89yjJ5aFl8E+z/o9TEHALifEgy5a5Da+LRDwwh1iSc2QZ+gdF2abyN6YEOOq nsMgaJgz+GMAioHZijFnaDnZ8fCxg3GZ0GS9GeXh7NrvKNcvejvAg6BZSUVgW/WNd8 seH72MeJUIfKQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1EBbv3A019535 for freebsd-stable@freebsd.org; Tue, 14 Feb 2012 12:37:57 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 14 Feb 2012 12:37:57 +0100 Date: Tue, 14 Feb 2012 12:37:55 +0100 Message-ID: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-stable@freebsd.org References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 5A4C18448CE.A27DD X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.456, required 6, autolearn=disabled, AWL -1.02, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_42 0.60, TW_PF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329824282.15957@YOEvr+9CaW5CFEaeQe4+gg X-EBL-Spam-Status: No Subject: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 14 Feb 2012 11:38:16 -0000 Quoting Alexander Leidinger (from Fri, 10 Feb 2012 14:56:04 +0100): > Such a kernel would cover situations where people compile their own > kernel because they want to get rid of some unused kernel code (and > maybe even need the memory this frees up). > > The question is, is this enough? Or asked differently, why are you > compiling a custom kernel in a production environment (so I rule out > debug options zhich are not enabled in GENERIC)? Are there options > which you add which you can not add as a module (SW_WATCHDOG comes > to my mind)? If yes, which ones and how important are they for you? Here is what I got, the first column is the number of requests, the second what is requested, and the 3rd my comments (basically it means, if there is a comment, it is not needed/possible to include in a modular kernel): ---snip--- 5 IPSEC 4 ALTQ 2 VIMAGE -> not production ready (bz) 2 SW_WATCHDOG 2 IPSEC_FILTERTUNNEL -> obsolete according to bz 2 IPFIREWALL_DEFAULT_TO_ACCEPT -> loader.conf: net.inet.ip.fw.default_to_accept 2 IPFIREWALL -> loader.conf: ipfw_load='YES' 2 HZ=1000 -> loader.conf: kern.hz 2 DEVICE_POLLING -> ifconfig in 9.0 handles this at runtime? 1 enc 1 ZERO_COPY_SOCKETS -> has known problems? can't find the reference, but I removed it from my kernels 1 SC_* options -> not a generic setting, will not include 1 ROUTETABLES=n -> bz is working on this 1 QUOTA 1 PF -> loader.conf: pf_load='YES' 1 MROUTING -> loader.conf: ip_mroute='YES'? 1 KTR -> rare use case, kernel recompile is OK 1 KDTRACE_HOOKS -> legal review needed 1 KDB_UNATTENDED -> re@ wants this, but has reservations 1 KDB_TRACE -> re@ wants this, but has reservations 1 KDB -> re@ wants this, but has reservations 1 IPSTEALTH 1 IPSEC_NAT_T 1 IPFIREWALL_VERBOSE_LIMIT=5 1 IPFIREWALL_VERBOSE 1 IPFIREWALL_FORWARD -> performance impact too big if unused (julian) 1 IPFILTER -> 2/3 firewalls can be loaded... and this one is not really maintained anymore 1 IPDIVERT -> loader.conf: ipdivert_load='YES' 1 GDB 1 FLOWTABLE 1 DUMMYNET -> loader.conf: dummynet_load='YES' 1 DIRECTIO 1 DDB_NUMSYM 1 DDB 1 BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.break_to_debugger 1 BPF_JITTER 1 ALT_BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.alt_break_to_debugger ---snip--- Yes, this poll is not representative... So... what's the impact of including the following options into a kernel which is intended to be modular, respectively are there reasons to _not_ include one of the following? ---snip--- 5 IPSEC -> we do not have a separate cryto dist, so it should be possible to include in a kernel now... legal advise needed 4 ALTQ* -> does add code to the pf module other impact? 2 SW_WATCHDOG -> should not hurt if not enabled in rc.conf 1 enc -> together with IPSEC 1 IPSTEALTH -> changes ipfw module only? 1 IPSEC_NAT_T 1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only? loader tunable? 1 IPFIREWALL_VERBOSE -> changes ipfw module only? loader tunable? 1 FLOWTABLE 1 DIRECTIO 1 BPF_JITTER ---snip--- Bye, Alexander. -- Q: What is purple and concord the world? A: Alexander the Grape. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 12:07:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02CA6106564A; Tue, 14 Feb 2012 12:07:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id B64EF8FC18; Tue, 14 Feb 2012 12:07:31 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q1EC7UAe051702; Tue, 14 Feb 2012 12:07:30 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q1EC7UYj051693; Tue, 14 Feb 2012 12:07:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 14 Feb 2012 12:07:30 GMT Message-Id: <201202141207.q1EC7UYj051693@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on 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: Tue, 14 Feb 2012 12:07:32 -0000 TB --- 2012-02-14 10:58:05 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-02-14 10:58:05 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-02-14 10:58:05 - cleaning the object tree TB --- 2012-02-14 10:58:05 - cvsupping the source tree TB --- 2012-02-14 10:58:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/sparc64/sparc64/supfile TB --- 2012-02-14 10:58:44 - building world TB --- 2012-02-14 10:58:44 - CROSS_BUILD_TESTING=YES TB --- 2012-02-14 10:58:44 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-14 10:58:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-14 10:58:44 - SRCCONF=/dev/null TB --- 2012-02-14 10:58:44 - TARGET=sparc64 TB --- 2012-02-14 10:58:44 - TARGET_ARCH=sparc64 TB --- 2012-02-14 10:58:44 - TZ=UTC TB --- 2012-02-14 10:58:44 - __MAKE_CONF=/dev/null TB --- 2012-02-14 10:58:44 - cd /src TB --- 2012-02-14 10:58:44 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 14 10:58:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Feb 14 12:05:49 UTC 2012 TB --- 2012-02-14 12:05:49 - generating LINT kernel config TB --- 2012-02-14 12:05:49 - cd /src/sys/sparc64/conf TB --- 2012-02-14 12:05:49 - /usr/bin/make -B LINT TB --- 2012-02-14 12:05:49 - cd /src/sys/sparc64/conf TB --- 2012-02-14 12:05:49 - /usr/sbin/config -m LINT TB --- 2012-02-14 12:05:49 - building LINT kernel TB --- 2012-02-14 12:05:49 - CROSS_BUILD_TESTING=YES TB --- 2012-02-14 12:05:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-14 12:05:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-14 12:05:49 - SRCCONF=/dev/null TB --- 2012-02-14 12:05:49 - TARGET=sparc64 TB --- 2012-02-14 12:05:49 - TARGET_ARCH=sparc64 TB --- 2012-02-14 12:05:49 - TZ=UTC TB --- 2012-02-14 12:05:49 - __MAKE_CONF=/dev/null TB --- 2012-02-14 12:05:49 - cd /src TB --- 2012-02-14 12:05:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 14 12:05:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/dev/cxgb -I/src/sys/dev/cxgbe -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector cc: /src/sys/dev/oce/oce_hw.c: No such file or directory cc: /src/sys/dev/oce/oce_if.c: No such file or directory cc: /src/sys/dev/oce/oce_mbox.c: No such file or directory cc: /src/sys/dev/oce/oce_queue.c: No such file or directory cc: /src/sys/dev/oce/oce_sysctl.c: No such file or directory cc: /src/sys/dev/oce/oce_util.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/sparc64.sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-14 12:07:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-14 12:07:30 - ERROR: failed to build LINT kernel TB --- 2012-02-14 12:07:30 - 2961.26 user 499.21 system 4165.45 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 13:08:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AACC1065674 for ; Tue, 14 Feb 2012 13:08:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 11B248FC17 for ; Tue, 14 Feb 2012 13:08:12 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so5934798wgb.31 for ; Tue, 14 Feb 2012 05:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=itlUERmMgGT50fDQ0tbvNHVcNc7cOlPPiBD0J/kaO3Q=; b=edGfSN4iH1Au4R7XUo0BI9xIcFdaNVLHRf9yU9z7SWhmGlOnXxOkds9yyFVUZ2NrBx kv93BJX9y8wmotMLiGspCXp/zifhmEzv8EtTOCGM1KYa34GfqrbuVGCFnzb/hLhdmiJo zpxLaSN8+m+2e+A9a8K78d/DL2N2ZJYU1NO48= MIME-Version: 1.0 Received: by 10.180.101.165 with SMTP id fh5mr30220204wib.10.1329223097378; Tue, 14 Feb 2012 04:38:17 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Tue, 14 Feb 2012 04:38:17 -0800 (PST) In-Reply-To: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> Date: Tue, 14 Feb 2012 12:38:17 +0000 X-Google-Sender-Auth: wmCitf6k2-ZUyTlIP_Ve55a7LyE Message-ID: From: Attilio Rao To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 14 Feb 2012 13:08:13 -0000 2012/2/14, Alexander Leidinger : > Quoting Alexander Leidinger (from Fri, 10 > Feb 2012 14:56:04 +0100): > >> Such a kernel would cover situations where people compile their own >> kernel because they want to get rid of some unused kernel code (and >> maybe even need the memory this frees up). >> >> The question is, is this enough? Or asked differently, why are you >> compiling a custom kernel in a production environment (so I rule out >> debug options zhich are not enabled in GENERIC)? Are there options >> which you add which you can not add as a module (SW_WATCHDOG comes >> to my mind)? If yes, which ones and how important are they for you? > > Here is what I got, the first column is the number of requests, the > second what is requested, and the 3rd my comments (basically it means, > if there is a comment, it is not needed/possible to include in a > modular kernel): ... > 2 SW_WATCHDOG This can become a module with very little effort I guess. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 13:09:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B770D1065673 for ; Tue, 14 Feb 2012 13:09:45 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5DDFD8FC27 for ; Tue, 14 Feb 2012 13:09:45 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 640911CC6F; Tue, 14 Feb 2012 09:49:56 -0300 (BRT) Received: from 187.114.198.119 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Tue, 14 Feb 2012 10:49:56 -0200 Message-ID: <57e2e07a4c574f537aab522ea9fa33aa.squirrel@eternamente.info> In-Reply-To: <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210144449.GA2358@psconsult.nl> <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> Date: Tue, 14 Feb 2012 10:49:56 -0200 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Reducing the need to compile a custom kernel 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, 14 Feb 2012 13:09:45 -0000 On Tue, February 14, 2012 08:31, Alexander Leidinger wrote: > Quoting Paul Schenkeveld (from Fri, 10 Feb 2012 > 15:44:50 +0100): > >> On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: >>> Hi, >>> >>> during some big discussions in the last monts on various lists, one of >>> the problems was that some people would like to use freebsd-update but >>> can't as they are using a custom kernel. With all the kernel modules >>> we provide, the need for a custom kernel should be small, but on the >>> other hand, we do not provide a small kernel-skeleton where you can >>> load just the modules you need. >>> >>> This should be easy to change. As a first step I took the generic >>> kernel and removed all devices which are available as modules, e.g. >>> the USB section consists now only of the USB_DEBUG option (so that the >>> module is build like with the current generic kernel). I also removed >>> some storage drivers which are not available as a module. The >>> rationale is, that I can not remove CAM from the kernel config if I >>> let those drivers inside (if those drivers are important enough, >>> someone will probably fix the problem and add the missing pieces to >>> generate a module). >>> >>> Such a kernel would cover situations where people compile their own >>> kernel because they want to get rid of some unused kernel code (and >>> maybe even need the memory this frees up). >>> >>> The question is, is this enough? Or asked differently, why are you >>> compiling a custom kernel in a production environment (so I rule out >>> debug options zhich are not enabled in GENERIC)? Are there options >>> which you add which you can not add as a module (SW_WATCHDOG comes to >>> my mind)? If yes, which ones and how important are they for you? >> >> - INET without INET6 >> - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) >> - Björn may add INET6 without INET >> - SCHED_ULE vs. SCHED_4BSD >> - No vga console/atkbd/psm for embedded devices >> - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices > > Embedded devices are out of the scope of this, normally you do a lot > of other modifictions to such systems anyway, so a custom kernel > should be not a big problem. > > I will also not touch the dual-stack part of the kernel config (it > shall still allow the generic purpose computing like the GERNERIC > config). I'm really curious why, if they are the piece of hardware that usually are worse to compile things on, for access issues to poor hardware (great to compile kernel+world on i7, pain to do so in my net5501-70). its a bummer to hear this :( matheus >> - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls > > Request noted. > >> I also always specify exactly one CPU type (on i386), know it made a >> difference in the 386/486/586 era but am not sure how much difference >> it makes nowadays. > > The 386 part (which we do not have anymore in GENERIC) made a > difference, the rest doesn't hurt in the kernel. > > Bye, > Alexander. > > -- > Smuggling... It's not just a job, it's an adventure! > -- paid for by your local Colombian recruiting office > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > > _______________________________________________ > 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" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 13:10:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2500C10656D1 for ; Tue, 14 Feb 2012 13:10:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A520F8FC23 for ; Tue, 14 Feb 2012 13:09:59 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC4218C.dip.t-dialin.net [79.196.33.140]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 126EE8448CD; Tue, 14 Feb 2012 14:09:42 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 533262FFE; Tue, 14 Feb 2012 14:09:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329224979; bh=5AbrjjPsE3pGq+dkC6puEw++ltlPDoZVTsPefPKyWBk=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=jjLnxsndIU38VsQhmKK9vzAjDRw+IF4Wkfj7QdKmOwyTN4DZo1ghN1IYIhKa/thT0 pkEGafdiC5PcrJ/oJJf/JcWENaCMwO9vDBIFx+3rYotI8QqHrL1cdxkS95r8OJjZJm DTjx3yuB5s67RoRf+gSGxey6FM4nm02a67JsbMn3TibLADjiMXTu3IveZ9uya4hh/y fsGZqAQfHoUXhxuFogWDCsoQUTcbNaLsfW5qnCG5JZQVyXp9CEUwX5ParOgqKOYvzh 53JxyCbjFFfH2B76H0BUm9NJAeYn0UsneXtd2nNHW1mkJ0MaXWRKn34gQdAdS4K+vF zYLXP5cEY7k7w== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1ED9d9w030636; Tue, 14 Feb 2012 14:09:39 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 14 Feb 2012 14:09:39 +0100 Date: Tue, 14 Feb 2012 14:09:38 +0100 Message-ID: <20120214140938.Horde.qntTTZjmRSRPOl0Sb7u3dhA@webmail.leidinger.net> From: Alexander Leidinger To: Attilio Rao References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 126EE8448CD.A5E90 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.804, required 6, autolearn=disabled, AWL -0.69, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1329829782.90081@38wccEj0MLTmn4Iw/FKTKQ X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 14 Feb 2012 13:10:00 -0000 Quoting Attilio Rao (from Tue, 14 Feb 2012 12:38:17 +0000): > 2012/2/14, Alexander Leidinger : >> 2 SW_WATCHDOG > > This can become a module with very little effort I guess. What's the TODO list for this? Bye, Alexander. -- No man is lonely while eating spaghetti. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 13:54:37 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21C21065673 for ; Tue, 14 Feb 2012 13:54:37 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id DF9E18FC14 for ; Tue, 14 Feb 2012 13:54:36 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 5CA9C39844; Tue, 14 Feb 2012 14:54:35 +0100 (CET) Date: Tue, 14 Feb 2012 14:54:35 +0100 From: Victor Balada Diaz To: Jeremy Chadwick Message-ID: <20120214135435.GQ2010@equilibrium.bsdes.net> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120214100513.GA94501@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 13:54:38 -0000 On Tue, Feb 14, 2012 at 02:05:13AM -0800, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 10:19:09AM +0100, Victor Balada Diaz wrote: > > We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: > > > > ahcich0: Timeout on slot 8 > > ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 > > ahcich0: AHCI reset... > > ahcich0: SATA connect time=0ms status=00000123 > > ahcich0: ready wait time=18ms > > ahcich0: AHCI reset done: device found > > (ada0:ahcich0:0:0:0): Request requeued > > (ada0:ahcich0:0:0:0): Retrying command > > (ada0:ahcich0:0:0:0): Command timed out > > (ada0:ahcich0:0:0:0): Retrying command > > ahcich0: Timeout on slot 8 > > ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 > > ahcich0: AHCI reset... > > ahcich0: SATA connect time=0ms status=00000123 > > ahcich0: ready wait time=84ms > > ahcich0: AHCI reset done: device found > > (ada0:ahcich0:0:0:0): Request requeued > > (ada0:ahcich0:0:0:0): Retrying command > > (ada0:ahcich0:0:0:0): Command timed out > > (ada0:ahcich0:0:0:0): Retrying command > > (ada0:ahcich0:0:0:0): Request requeued > > [...] > > > > If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, > > no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we > > got the above error. If we use both disks in gmirror with old ata driver, no problems. > > Please provide SMART statistics for both disks by installing > ports/sysutils/smartmontools (5.42 or newer please) and running > "smartctl -a" against both disks (ada0/ada1, or ad4/ad10 -- doesn't > matter which driver you're using). I will review the output. Just forgot to say that from time to time, after system hangs and i need to reboot, one of the disks is lost. It doesn't even show after a few reboots, nor on Linux live system. You can see smartctl output here: ada0: # smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F2 EG Device Model: SAMSUNG HD154UI Serial Number: S24EJ9BB200080 LU WWN Device Id: 5 0024e9 2047cb78f Firmware Version: 1AG01118 User Capacity: 1,500,301,910,016 bytes [1.50 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Tue Feb 14 13:51:18 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (18863) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 33) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 072 072 011 Pre-fail Always - 9330 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 13677 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4688 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 22 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 069 067 000 Old_age Always - 31 (Min/Max 31/31) 194 Temperature_Celsius 0x0022 068 067 000 Old_age Always - 32 (Min/Max 31/32) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 113154 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 28 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4430 - # 2 Extended offline Completed without error 10% 4410 - # 3 Extended offline Completed without error 00% 27 - # 4 Short offline Completed without error 00% 14 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Ada1: # smartctl -a /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F2 EG Device Model: SAMSUNG HD154UI Serial Number: S24EJ9BB200082 LU WWN Device Id: 5 0024e9 2047cb7a5 Firmware Version: 1AG01118 User Capacity: 1,500,301,910,016 bytes [1.50 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Tue Feb 14 13:52:09 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (19064) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 33) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 071 071 011 Pre-fail Always - 9360 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12804 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4583 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 071 069 000 Old_age Always - 29 (Min/Max 29/29) 194 Temperature_Celsius 0x0022 070 068 000 Old_age Always - 30 (Min/Max 29/30) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1870564 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4430 - # 2 Extended offline Completed without error 10% 4409 - # 3 Extended offline Completed without error 00% 28 - # 4 Short offline Completed without error 00% 14 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 14:03:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9F54106566B; Tue, 14 Feb 2012 14:03:41 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [94.23.254.147]) by mx1.freebsd.org (Postfix) with ESMTP id 816B78FC15; Tue, 14 Feb 2012 14:03:41 +0000 (UTC) Received: from roxette.lamaiziere.net (136.9.74.86.rev.sfr.net [86.74.9.136]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 011A4FAA2D08; Tue, 14 Feb 2012 14:47:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by roxette.lamaiziere.net (Postfix) with ESMTP id 5D696C30D; Tue, 14 Feb 2012 14:47:20 +0100 (CET) Date: Tue, 14 Feb 2012 14:47:19 +0100 From: Patrick Lamaiziere To: Greg Rivers Message-ID: <20120214144719.11d6ce08@davenulle.org> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: mlaier@freebsd.org, freebsd-stable@freebsd.org Subject: Re: sysutils/pftop on 9.x+ 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, 14 Feb 2012 14:03:41 -0000 Le Mon, 13 Feb 2012 14:09:25 -0600 (CST), Greg Rivers a écrit : > sysutils/pftop was marked broken on 9.x and above last March[1]. Are > there any plans to fix it soon? It's a really handy utility. > > [1] > http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 Looks like there are some patches to make it works with DragonFlyBSD/NetBSD in pkgsrc. Don't have the time to try... http://pkgsrc.se/sysutils/pftop HTH Regards. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 14:16:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED9AB106566B for ; Tue, 14 Feb 2012 14:16:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id D379C8FC08 for ; Tue, 14 Feb 2012 14:16:03 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id ZqEC1i0031HpZEsACqG3zY; Tue, 14 Feb 2012 14:16:03 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id ZqG11i00m1t3BNj8aqG2Hz; Tue, 14 Feb 2012 14:16:02 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AC9EA102C1E; Tue, 14 Feb 2012 06:16:01 -0800 (PST) Date: Tue, 14 Feb 2012 06:16:01 -0800 From: Jeremy Chadwick To: Victor Balada Diaz Message-ID: <20120214141601.GA98986@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120214135435.GQ2010@equilibrium.bsdes.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 14:16:04 -0000 On Tue, Feb 14, 2012 at 02:54:35PM +0100, Victor Balada Diaz wrote: > On Tue, Feb 14, 2012 at 02:05:13AM -0800, Jeremy Chadwick wrote: > > On Tue, Feb 14, 2012 at 10:19:09AM +0100, Victor Balada Diaz wrote: > > > We're having some troubles with AHCI under FreeBSD 8.2 and 8-STABLE. The error is: > > > > > > ahcich0: Timeout on slot 8 > > > ahcich0: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr 00000000 > > > ahcich0: AHCI reset... > > > ahcich0: SATA connect time=0ms status=00000123 > > > ahcich0: ready wait time=18ms > > > ahcich0: AHCI reset done: device found > > > (ada0:ahcich0:0:0:0): Request requeued > > > (ada0:ahcich0:0:0:0): Retrying command > > > (ada0:ahcich0:0:0:0): Command timed out > > > (ada0:ahcich0:0:0:0): Retrying command > > > ahcich0: Timeout on slot 8 > > > ahcich0: is 00000000 cs 007ff000 ss 007fff00 rs 007fff00 tfd c0 serr 00000000 > > > ahcich0: AHCI reset... > > > ahcich0: SATA connect time=0ms status=00000123 > > > ahcich0: ready wait time=84ms > > > ahcich0: AHCI reset done: device found > > > (ada0:ahcich0:0:0:0): Request requeued > > > (ada0:ahcich0:0:0:0): Retrying command > > > (ada0:ahcich0:0:0:0): Command timed out > > > (ada0:ahcich0:0:0:0): Retrying command > > > (ada0:ahcich0:0:0:0): Request requeued > > > [...] > > > > > > If we use old ATA driver we have no problems. If we just use the first disk (ada0) with ahci, > > > no problems either. If we use both disks (ada0 and ada1) in gmirror setup with ahci, we > > > got the above error. If we use both disks in gmirror with old ata driver, no problems. > > > > Please provide SMART statistics for both disks by installing > > ports/sysutils/smartmontools (5.42 or newer please) and running > > "smartctl -a" against both disks (ada0/ada1, or ad4/ad10 -- doesn't > > matter which driver you're using). I will review the output. > > Just forgot to say that from time to time, after system hangs and i need > to reboot, one of the disks is lost. It doesn't even show after a few reboots, > nor on Linux live system. > > You can see smartctl output here: > > ada0: > > # smartctl -a /dev/ada0 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Model Family: SAMSUNG SpinPoint F2 EG > Device Model: SAMSUNG HD154UI > Serial Number: S24EJ9BB200080 > LU WWN Device Id: 5 0024e9 2047cb78f > Firmware Version: 1AG01118 > User Capacity: 1,500,301,910,016 bytes [1.50 TB] > Sector Size: 512 bytes logical/physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b > Local Time is: Tue Feb 14 13:51:18 2012 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x00) Offline data collection activity > was never started. > Auto Offline Data Collection: Disabled. > Self-test execution status: ( 0) The previous self-test routine completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (18863) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 255) minutes. > Conveyance self-test routine > recommended polling time: ( 33) minutes. > SCT capabilities: (0x003f) SCT Status supported. > SCT Error Recovery Control supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 > 3 Spin_Up_Time 0x0007 072 072 011 Pre-fail Always - 9330 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22 > 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 > 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 13677 > 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4688 > 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 > 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 22 > 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 > 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 > 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 > 190 Airflow_Temperature_Cel 0x0022 069 067 000 Old_age Always - 31 (Min/Max 31/31) > 194 Temperature_Celsius 0x0022 068 067 000 Old_age Always - 32 (Min/Max 31/32) > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 113154 > 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 28 > 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 > 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error > # 1 Extended offline Completed without error 00% 4430 - > # 2 Extended offline Completed without error 10% 4410 - > # 3 Extended offline Completed without error 00% 27 - > # 4 Short offline Completed without error 00% 14 - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. > > Ada1: > > # smartctl -a /dev/ada1 > smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Model Family: SAMSUNG SpinPoint F2 EG > Device Model: SAMSUNG HD154UI > Serial Number: S24EJ9BB200082 > LU WWN Device Id: 5 0024e9 2047cb7a5 > Firmware Version: 1AG01118 > User Capacity: 1,500,301,910,016 bytes [1.50 TB] > Sector Size: 512 bytes logical/physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 3b > Local Time is: Tue Feb 14 13:52:09 2012 CET > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x00) Offline data collection activity > was never started. > Auto Offline Data Collection: Disabled. > Self-test execution status: ( 0) The previous self-test routine completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (19064) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 255) minutes. > Conveyance self-test routine > recommended polling time: ( 33) minutes. > SCT capabilities: (0x003f) SCT Status supported. > SCT Error Recovery Control supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 > 3 Spin_Up_Time 0x0007 071 071 011 Pre-fail Always - 9360 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 > 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 > 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12804 > 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4583 > 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 > 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 > 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 > 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 > 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 > 190 Airflow_Temperature_Cel 0x0022 071 069 000 Old_age Always - 29 (Min/Max 29/29) > 194 Temperature_Celsius 0x0022 070 068 000 Old_age Always - 30 (Min/Max 29/30) > 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1870564 > 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 2 > 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 > 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error > # 1 Extended offline Completed without error 00% 4430 - > # 2 Extended offline Completed without error 10% 4409 - > # 3 Extended offline Completed without error 00% 28 - > # 4 Short offline Completed without error 00% 14 - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. Thanks. Both your drives look overall fine, sort-of. I'll outline my concern points, and ask for some more info: * ada0 has 28 CRC errors, while ada1 has 2. These drives have been in use for 4688 hours and 4583 hours (respectively), which is roughly 6 months for each drive. CRC errors usually result in transparent retransmits, but this can sometimes cause I/O delays (especially if the CRC errors are repeated). If the timeout messages recur in the future, please run the commands I gave you above once more and provide the output. I can then compare the old to the new and see if there is anything of interest. * Both drives had 2 long tests run on them a few days ago ("Extended offline" tests). Did you induce these manually? If so, were these tests running at the time you witnessed AHCI timeout errors on ada0? Short, long, and selective surface scan tests are supposed to be non-intrusive, but given the nature of the tests sometimes they can stall the I/O subsystem. If you do tests of this nature, you should write down the exact dates/times when you ran them (at least from now on). If you didn't induce these, something must have, or possibly the drive itself did it (and if that's the case, convenient that it induces an entry in the self-test log!). I do have some familiarity with drives doing internal tests -- the best example are old IBM Deskstar drives executing ADM on their own, resulting in the drives spinning down and performing internal tests, which would subsequently be interrupted by ATA I/O, drive spins back up, etc. -- but took too long resulting in ATA timeouts on FreeBSD and Linux. I mailed IBM about this back in 2000 and got confirmation of the feature (which was also on their SCSI drives but defaulted to off); the feature was mysteriously removed in future drive models and still remains gone today: http://jdc.parodius.com/freebsd/ibm_email_aware_of_adm.txt I'm not saying your drives do this. I'm simply saying that if there is some form of automated test that runs on these drives which is transparent to the underlying ATA layer, then there is really nothing you can do about it, and timeouts are possible. The IBM ADM issue was only discovered after reviewing technical specifications/documentation and compared to their SCSI drives. * Samsung has a notoriously bad reputation for firmware reliability on their SpinPoint drives, but I haven't read of anything bad about the F2 series, just the F1, F3, and F4 models. I have very little (almost none) experience with these drives. I'm not boycotting their products, but I wouldn't be surprised if the timeout errors you saw were caused by something internal the drive was doing. There is absolutely zero visibility into this kind of problem on any layer (even if you had an ATA protocol analyser hooked up); you're completely at the mercy of the firmware. Just something to keep in mind when working with ANY kind of disk (MHDD, SSD, etc.). All that said, could you please provide output from the following commands as well? These may return "not supported" errors, which is acceptable, but we have to check. * smartctl -l devstat /dev/ada0 * smartctl -l sataphy /dev/ada0 * smartctl -l devstat /dev/ada1 * smartctl -l sataphy /dev/ada1 Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 14:30:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 828AE106568C; Tue, 14 Feb 2012 14:30:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 3D0D38FC1E; Tue, 14 Feb 2012 14:30:46 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q1EEUfJw045442; Tue, 14 Feb 2012 09:30:41 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F3A7005.7000909@sentex.net> Date: Tue, 14 Feb 2012 09:30:29 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F32F5B0.2060203@FreeBSD.org> <20120208223819.GA27488@icarus.home.lan> <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> <4F358DB6.4030203@sentex.net> <20120211012753.GA29375@icarus.home.lan> <4F35C7D8.5050707@sentex.net> In-Reply-To: <4F35C7D8.5050707@sentex.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT 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, 14 Feb 2012 14:30:46 -0000 On 2/10/2012 8:43 PM, Mike Tancsa wrote: > On 2/10/2012 8:27 PM, Jeremy Chadwick wrote: >> Mike, >> >> I wanted to make you aware of this commit that just came through: >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c > > Thanks, I did see that. I was going to wait until Monday to csup up > once all the weekend level zeros are done. The prior kernels from Nov > 28th never saw these READ LOG EXT errors on either of these 2 big zfs boxes So far so good. Unfortunately, I had to make 2 changes to the box showing the problem the most. I changed the cable (the new one does seem to fit more snug) as well as updated the code. I havent done many level 0 dumps to it (the real test will be the weekend), but so far so good. On the other box that did show the same READ LOG EXT error, I also updated the kernel, but made no hardware changes. It too has not yet shown any errors since the upgrade. I changed the cable at 8am local time yesterday, and I take snapshots of smartctl at 5am I did see this error increase in 24hrs, but that was on a disk that was off the motherboard. Perhaps a new cable for it too. < 0x000a 2 12 Device-to-host register FISes sent due to a COMRESET --- > 0x000a 2 6 Device-to-host register FISes sent due to a COMRESET ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 14:37:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 349331065670 for ; Tue, 14 Feb 2012 14:37:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 16F288FC12 for ; Tue, 14 Feb 2012 14:37:11 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta14.emeryville.ca.mail.comcast.net with comcast id ZpmE1i0071smiN4AEqdBHS; Tue, 14 Feb 2012 14:37:11 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id ZqdA1i00g1t3BNj8gqdBuz; Tue, 14 Feb 2012 14:37:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A8853102C1E; Tue, 14 Feb 2012 06:37:10 -0800 (PST) Date: Tue, 14 Feb 2012 06:37:10 -0800 From: Jeremy Chadwick To: Mike Tancsa Message-ID: <20120214143710.GA99700@icarus.home.lan> References: <4F32FB5E.7050102@FreeBSD.org> <4F33DB75.1080202@sentex.net> <20120209152240.GA95470@icarus.home.lan> <4F33F056.6070300@sentex.net> <20120209163415.GA96451@icarus.home.lan> <4F34124F.9090808@sentex.net> <4F358DB6.4030203@sentex.net> <20120211012753.GA29375@icarus.home.lan> <4F35C7D8.5050707@sentex.net> <4F3A7005.7000909@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3A7005.7000909@sentex.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: siisch1: Error while READ LOG EXT 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, 14 Feb 2012 14:37:12 -0000 On Tue, Feb 14, 2012 at 09:30:29AM -0500, Mike Tancsa wrote: > On 2/10/2012 8:43 PM, Mike Tancsa wrote: > > On 2/10/2012 8:27 PM, Jeremy Chadwick wrote: > >> Mike, > >> > >> I wanted to make you aware of this commit that just came through: > >> > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ata/ata_da.c > > > > Thanks, I did see that. I was going to wait until Monday to csup up > > once all the weekend level zeros are done. The prior kernels from Nov > > 28th never saw these READ LOG EXT errors on either of these 2 big zfs boxes > > > So far so good. Unfortunately, I had to make 2 changes to the box > showing the problem the most. I changed the cable (the new one does seem > to fit more snug) as well as updated the code. I havent done many level > 0 dumps to it (the real test will be the weekend), but so far so good. > On the other box that did show the same READ LOG EXT error, I also > updated the kernel, but made no hardware changes. It too has not yet > shown any errors since the upgrade. > > I changed the cable at 8am local time yesterday, and I take snapshots of > smartctl at 5am Cool. > I did see this error increase in 24hrs, but that was on a disk that was > off the motherboard. Perhaps a new cable for it too. > > < 0x000a 2 12 Device-to-host register FISes sent due to a > COMRESET > --- > > 0x000a 2 6 Device-to-host register FISes sent due to a > COMRESET This ID tracks the number of times an actual communication reset command was sent from the drive to the controller via a FIS packet. This is at the SATA layer, not the ATA command layer. It's completely normal/okay for a drive to have this number increase, especially if the machine is shut off, force-reset (via reset button), or in some cases simply soft rebooted. Nothing to worry about here; no need to adjust cables or otherwise. Values 6, 12, etc. are all perfectly reasonable and will vary from system to system based on use. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 15:02:48 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4089B106566B for ; Tue, 14 Feb 2012 15:02:48 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 13A4D8FC12 for ; Tue, 14 Feb 2012 15:02:46 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id A06A639846; Tue, 14 Feb 2012 16:02:45 +0100 (CET) Date: Tue, 14 Feb 2012 16:02:45 +0100 From: Victor Balada Diaz To: Jeremy Chadwick Message-ID: <20120214150245.GR2010@equilibrium.bsdes.net> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120214141601.GA98986@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 15:02:48 -0000 On Tue, Feb 14, 2012 at 06:16:01AM -0800, Jeremy Chadwick wrote: [..] > > Thanks. Both your drives look overall fine, sort-of. I'll outline my > concern points, and ask for some more info: > > * ada0 has 28 CRC errors, while ada1 has 2. These drives have been in > use for 4688 hours and 4583 hours (respectively), which is roughly 6 > months for each drive. CRC errors usually result in transparent > retransmits, but this can sometimes cause I/O delays (especially if the > CRC errors are repeated). > > If the timeout messages recur in the future, please run the commands I > gave you above once more and provide the output. I can then compare the > old to the new and see if there is anything of interest. I can force the error each time i want. Its 100% reproducible on my environment so i'll do the tests and send you smartctl -a output again. > > * Both drives had 2 long tests run on them a few days ago ("Extended > offline" tests). Did you induce these manually? If so, were these > tests running at the time you witnessed AHCI timeout errors on ada0? > Short, long, and selective surface scan tests are supposed to be > non-intrusive, but given the nature of the tests sometimes they can > stall the I/O subsystem. I've ran the tests, but they were not running during timeout problems. The only thing running on the disks was a newfs -J under a gjournal partiton. For the rest, they're mostly idle. > > If you do tests of this nature, you should write down the exact > dates/times when you ran them (at least from now on). > > If you didn't induce these, something must have, or possibly the drive > itself did it (and if that's the case, convenient that it induces an > entry in the self-test log!). > > I do have some familiarity with drives doing internal tests -- the best > example are old IBM Deskstar drives executing ADM on their own, > resulting in the drives spinning down and performing internal tests, > which would subsequently be interrupted by ATA I/O, drive spins back up, > etc. -- but took too long resulting in ATA timeouts on FreeBSD and > Linux. I mailed IBM about this back in 2000 and got confirmation of the > feature (which was also on their SCSI drives but defaulted to off); the > feature was mysteriously removed in future drive models and still > remains gone today: > > http://jdc.parodius.com/freebsd/ibm_email_aware_of_adm.txt > > I'm not saying your drives do this. I'm simply saying that if there is > some form of automated test that runs on these drives which is > transparent to the underlying ATA layer, then there is really nothing > you can do about it, and timeouts are possible. The IBM ADM issue was > only discovered after reviewing technical specifications/documentation > and compared to their SCSI drives. That's of course possible, but as the problem is 100% reproducible with AHCI driver and is not with ata driver, i guess this time is not drive's fault. We've also tested replacement disks and cables during the previous days. I guess the problem is in some bad interaction with AHCI driver. > > * Samsung has a notoriously bad reputation for firmware reliability on > their SpinPoint drives, but I haven't read of anything bad about the F2 > series, just the F1, F3, and F4 models. I have very little (almost > none) experience with these drives. I'm not boycotting their products, > but I wouldn't be surprised if the timeout errors you saw were caused by > something internal the drive was doing. There is absolutely zero > visibility into this kind of problem on any layer (even if you had an > ATA protocol analyser hooked up); you're completely at the mercy of the > firmware. Just something to keep in mind when working with ANY kind of > disk (MHDD, SSD, etc.). I've seen reports on freebsd lists and smartmontools wiki about firmware problems with F4 drives manufactured before december of 2010, but checking samsung's web page, seems this drives are not affected. I hope we're not hitting a new bug. More info: http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks > > All that said, could you please provide output from the following > commands as well? These may return "not supported" errors, which is > acceptable, but we have to check. > > * smartctl -l devstat /dev/ada0 > * smartctl -l sataphy /dev/ada0 > * smartctl -l devstat /dev/ada1 > * smartctl -l sataphy /dev/ada1 > Thanks a lot for you help Jeremy. Attached is the output of the commands: fe09# smartctl -l devstat /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net (pass0:ahcich0:0:0:0): READ_LOG_EXT. ACB: 2f 00 04 00 00 40 00 00 00 00 01 00 (pass0:ahcich0:0:0:0): CAM status: ATA Status Error (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ahcich0:0:0:0): RES: 51 04 04 00 00 40 00 00 00 01 00 ATA_READ_LOG_EXT (addr=0x04:0x00, page=0, n=1) failed: Unknown error: 0 fe09# smartctl -l sataphy /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 16 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 16 Transition from drive PhyRdy to drive PhyNRdy 0x000b 2 0 CRC errors within host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0010 2 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 2 0 R_ERR response for host-to-device non-data FIS, non-CRC fe09# smartctl -l devstat /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net (pass1:ahcich1:0:0:0): READ_LOG_EXT. ACB: 2f 00 04 00 00 40 00 00 00 00 01 00 (pass1:ahcich1:0:0:0): CAM status: ATA Status Error (pass1:ahcich1:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass1:ahcich1:0:0:0): RES: 51 04 04 00 00 40 00 00 00 01 00 ATA_READ_LOG_EXT (addr=0x04:0x00, page=0, n=1) failed: Unknown error: 0 fe09# smartctl -l sataphy /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 16 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 16 Transition from drive PhyRdy to drive PhyNRdy 0x000b 2 0 CRC errors within host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0010 2 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 2 0 R_ERR response for host-to-device non-data FIS, non-CRC -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 15:43:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1672106566B for ; Tue, 14 Feb 2012 15:43:53 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2E48FC08 for ; Tue, 14 Feb 2012 15:43:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1EFhnTw014509; Wed, 15 Feb 2012 02:43:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 15 Feb 2012 02:43:49 +1100 (EST) From: Ian Smith To: Alexander Leidinger In-Reply-To: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> Message-ID: <20120215014738.O95093@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: julian@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 14 Feb 2012 15:43:54 -0000 On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote: > Here is what I got, the first column is the number of requests, the second > what is requested, and the 3rd my comments (basically it means, if there is a > comment, it is not needed/possible to include in a modular kernel): > ---snip--- [..] > 1 IPFIREWALL_FORWARD -> performance impact too big if unused (julian) I expect Julian will object if I've mis-paraphrased or over-simplified something I recall him saying at least a couple of years ago :) [..] > 4 ALTQ* -> does add code to the pf module > other impact? ipfw(8) can also apply ALTQ tags, but relies on pfctl(8) to setup the queues - or so I read; I've not used it here. From altq(4): ALTQ Enable ALTQ. ALTQ_CBQ Build the ``Class Based Queuing'' discipline. ALTQ_RED Build the ``Random Early Detection'' extension. ALTQ_RIO Build ``Random Early Drop'' for input and output. ALTQ_HFSC Build the ``Hierarchical Packet Scheduler'' discipline. ALTQ_CDNR Build the traffic conditioner. This option is meaningless at the moment as the conditioner is not used by any of the available disciplines or consumers. ALTQ_PRIQ Build the ``Priority Queuing'' discipline. ALTQ_NOPCC Required if the TSC is unusable. ALTQ_DEBUG Enable additional debugging facilities. Note that ALTQ-disciplines cannot be loaded as kernel modules. In order to use a certain discipline you have to build it into a custom kernel. The pf(4) interface, that is required for the configuration process of ALTQ can be loaded as a module. So which disciplines would one choose? Seeming an unlikely candidate? > 1 IPSTEALTH -> changes ipfw module only? I don't think this is specific to ipfw. From /sys/conf/NOTES: # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the TTL). This can be useful to hide firewalls # from traceroute and similar tools. But can it be disabled once added to kernel? It's no good as a default. > 1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only? > loader tunable? > 1 IPFIREWALL_VERBOSE -> changes ipfw module only? > loader tunable? sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 15:55:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73B7A106566B for ; Tue, 14 Feb 2012 15:55:18 +0000 (UTC) (envelope-from claudius@ambtec.de) Received: from server.ambtec.de (server.ambtec.de [IPv6:2a01:4f8:131:1381::2]) by mx1.freebsd.org (Postfix) with ESMTP id 820888FC18 for ; Tue, 14 Feb 2012 15:55:17 +0000 (UTC) Received: from server.ambtec.de (localhost [127.0.0.1]) by server.ambtec.de (Postfix) with ESMTP id 5E7ADE21D for ; Tue, 14 Feb 2012 16:55:15 +0100 (CET) X-Virus-Scanned: by amavisd-new using ClamAV at ambtec.de Received: from server.ambtec.de ([127.0.0.1]) by server.ambtec.de (server.ambtec.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2ZVWKQ03FqA2 for ; Tue, 14 Feb 2012 16:55:04 +0100 (CET) Received: from [192.168.0.101] (e176012183.adsl.alicedsl.de [85.176.12.183]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.ambtec.de (Postfix) with ESMTPSA id 7BF76E20B for ; Tue, 14 Feb 2012 16:55:04 +0100 (CET) Message-ID: <4F3A83DE.3000200@ambtec.de> Date: Tue, 14 Feb 2012 16:55:10 +0100 From: Claudius Herder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> In-Reply-To: <20120214141601.GA98986@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 15:55:18 -0000 Hello, I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still persists on FreeBSD 9.0 release. Switching from ahci to ataahci resolved the problem for me too. I'm using gmirror for swap, system is on a zpool and the problem first occurred during a zpool scrub, but it is easily reproducible with dd. The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} of=/dev/null is not an issue. Sometimes I need to power off the server because after a reboot one disk is still missing. I really would like to help in this issue, so let me know if you need any more information. -- Claudius dmesg: --cut-- Jan 14 01:33:57 server kernel: ahcich0: Timeout on slot 7 port 0 Jan 14 01:33:57 server kernel: ahcich0: is 00000000 cs 00000080 ss 00000000 rs 00000080 tfd c0 serr 00000000 cmd 0004c717 Jan 14 01:33:57 server kernel: ahcich1: Timeout on slot 31 port 0 Jan 14 01:33:57 server kernel: ahcich1: is 00000000 cs 80000000 ss 00000000 rs 80000000 tfd c0 serr 00000000 cmd 0004df17 Jan 14 01:33:57 server kernel: ahcich0: Timeout on slot 7 port 0 Jan 14 01:33:57 server kernel: ahcich0: is 00000000 cs 0000f800 ss 0000ff80 rs 0000ff80 tfd c0 serr 00000000 cmd 0004cb17 Jan 14 01:33:57 server kernel: ahcich1: Timeout on slot 31 port 0 Jan 14 01:33:57 server kernel: ahcich1: is 00000000 cs 000000f8 ss 800000ff rs 800000ff tfd c0 serr 00000000 cmd 0004c317 Jan 14 01:33:57 server kernel: ahcich0: Timeout on slot 23 port 0 Jan 14 01:33:57 server kernel: ahcich0: is 00000000 cs 01800000 ss 00000000 rs 01800000 tfd c0 serr 00000000 cmd 0004d717 Jan 14 01:33:57 server kernel: ahcich1: Timeout on slot 15 port 0 Jan 14 01:33:57 server kernel: ahcich1: is 00000000 cs 00018000 ss 00000000 rs 00018000 tfd c0 serr 00000000 cmd 0004cf17 Jan 14 01:33:57 server kernel: ahcich1: Timeout on slot 17 port 0 Jan 14 01:33:57 server kernel: ahcich1: is 00000000 cs 01f80000 ss 01fe0000 rs 01fe0000 tfd c0 serr 00000000 cmd 0004d317 Jan 14 01:33:57 server kernel: ahcich0: AHCI reset: device not ready after 31000ms (tfd = 00000080) Jan 14 01:33:57 server kernel: ahcich1: Timeout on slot 31 port 0 Jan 14 01:33:57 server kernel: ahcich1: is 00000000 cs 80000000 ss 00000000 rs 80000000 tfd c0 serr 00000000 cmd 0004df17 Jan 14 01:33:57 server kernel: ahcich0: Timeout on slot 24 port 0 --cut-- smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F1 DT Device Model: SAMSUNG HD753LJ Serial Number: S13UJDWS900110 LU WWN Device Id: 5 0024e9 0020d1bfa Firmware Version: 1AA01118 User Capacity: 750,156,374,016 bytes [750 GB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Tue Feb 14 16:32:58 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 9429) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 158) minutes. Conveyance self-test routine recommended polling time: ( 17) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 082 082 011 Pre-fail Always - 6340 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 8 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 0 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 19820 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 067 050 000 Old_age Always - 33 (Min/Max 30/35) 194 Temperature_Celsius 0x0022 067 048 000 Old_age Always - 33 (Min/Max 29/38) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 614819290 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 14 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl -a /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F1 DT Device Model: SAMSUNG HD753LJ Serial Number: S13UJDWS900108 LU WWN Device Id: 5 0024e9 0020d1be9 Firmware Version: 1AA01118 User Capacity: 750,156,374,016 bytes [750 GB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Tue Feb 14 16:33:09 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 8891) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 149) minutes. Conveyance self-test routine recommended polling time: ( 16) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 082 082 011 Pre-fail Always - 6330 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 8 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 13610 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 19821 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 8 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 052 000 Old_age Always - 32 (Min/Max 29/35) 194 Temperature_Celsius 0x0022 068 050 000 Old_age Always - 32 (Min/Max 29/37) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 561160707 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 46 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 18167 - # 2 Short offline Completed without error 00% 14879 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. smartctl -l sataphy /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 150 Device-to-host register FISes sent due to a COMRESET 0x0001 2 3 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 173 Transition from drive PhyRdy to drive PhyNRdy 0x000b 2 0 CRC errors within host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0010 2 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 2 0 R_ERR response for host-to-device non-data FIS, non-CRC smartctl -l sataphy /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 155 Device-to-host register FISes sent due to a COMRESET 0x0001 2 65535+ Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 178 Transition from drive PhyRdy to drive PhyNRdy 0x000b 2 0 CRC errors within host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0010 2 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 2 0 R_ERR response for host-to-device non-data FIS, non-CRC smartctl -l devstat /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net (pass0:ata2:0:0:0): READ_LOG_EXT. ACB: 2f 00 04 00 00 40 00 00 00 00 01 00 (pass0:ata2:0:0:0): CAM status: ATA Status Error (pass0:ata2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ata2:0:0:0): RES: 51 04 04 00 00 00 00 00 00 01 00 ATA_READ_LOG_EXT (addr=0x04:0x00, page=0, n=1) failed: No error: 0 smartctl -l devstat /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net (pass1:ata3:0:0:0): READ_LOG_EXT. ACB: 2f 00 04 00 00 40 00 00 00 00 01 00 (pass1:ata3:0:0:0): CAM status: ATA Status Error (pass1:ata3:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass1:ata3:0:0:0): RES: 51 04 04 00 00 00 00 00 00 01 00 ATA_READ_LOG_EXT (addr=0x04:0x00, page=0, n=1) failed: No error: 0 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:26:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D2B8106564A for ; Tue, 14 Feb 2012 16:26:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 525A28FC15 for ; Tue, 14 Feb 2012 16:26:54 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so146215vbb.13 for ; Tue, 14 Feb 2012 08:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=lt2kykFR4a2teq+PxBSsOTGgfUjfS6DF8v+3nsMfYYM=; b=HiSkj9F1Sw0GnmF0o1LfiQ889u00QTiAOMUxLyzrYBeUu6Bz65gi32Fv74AXOftGcK 3gGf4ZI//rT6cibQYVHg6kb/4G4w2B5v2baRwS5dxd5aOz91/EQDOrgT6khvjQp818wf lseoEPDPicAhgCh6DkFPN5KDvSrVWAsjG5PKQ= MIME-Version: 1.0 Received: by 10.52.72.83 with SMTP id b19mr9407465vdv.24.1329236814362; Tue, 14 Feb 2012 08:26:54 -0800 (PST) Received: by 10.220.192.135 with HTTP; Tue, 14 Feb 2012 08:26:54 -0800 (PST) In-Reply-To: <20120215014738.O95093@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> <20120215014738.O95093@sola.nimnet.asn.au> Date: Tue, 14 Feb 2012 08:26:54 -0800 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 14 Feb 2012 16:26:55 -0000 On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith wrote: > On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote: > =C2=A0> 1 IPSTEALTH =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> changes ipfw module only? > > I don't think this is specific to ipfw. =C2=A0From /sys/conf/NOTES: > > # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding > # packets without touching the TTL). =C2=A0This can be useful to hide fir= ewalls > # from traceroute and similar tools. > > But can it be disabled once added to kernel? =C2=A0It's no good as a defa= ult. It's controllable via sysctl once it's compiled into the kernel. If it's not compiled into the kernel, then the sysctl doesn't exist. > =C2=A0> 1 IPFIREWALL_VERBOSE_LIMIT=3D5 =C2=A0 =C2=A0 -> changes ipfw modu= le only? > =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loader tunabl= e? This is controllable via sysctl. Not sure if it needs to be compiled into the kernel before it's controllable via sysctl, though. We have compiled into all our firewall kernels (with a default of 1000), then change it via sysctl when needed. > =C2=A0> 1 IPFIREWALL_VERBOSE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->= changes ipfw module only? > =C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loader tunabl= e? > > sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit Ah, you list the sysctls that control the last two. :) --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:28:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E62031065675 for ; Tue, 14 Feb 2012 16:28:05 +0000 (UTC) (envelope-from fk@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by mx1.freebsd.org (Postfix) with ESMTP id A52C18FC13 for ; Tue, 14 Feb 2012 16:28:05 +0000 (UTC) Received: from [109.41.118.72] (helo=fabiankeil.de) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1RxL2m-000127-Rt; Tue, 14 Feb 2012 17:15:53 +0100 Date: Tue, 14 Feb 2012 17:14:46 +0100 From: Fabian Keil To: Greg Rivers Message-ID: <20120214171446.2a5e5eb1.fk@fabiankeil.de> In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/3M_wcT7J_Bsnw0sFDVQinzW"; protocol="application/pgp-signature" X-Df-Sender: MTgwOTA5 Cc: mlaier@freebsd.org, freebsd-stable@freebsd.org Subject: Re: sysutils/pftop on 9.x+ 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, 14 Feb 2012 16:28:06 -0000 --Sig_/3M_wcT7J_Bsnw0sFDVQinzW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Greg Rivers wrote: > sysutils/pftop was marked broken on 9.x and above last March[1]. Are=20 > there any plans to fix it soon? It's a really handy utility. >=20 > [1]=20 > http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev= =3D1.17 Please have a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155938 Note that the currently working fix is in the audit trail, the original fix stopped working after the PF update. Fabian --Sig_/3M_wcT7J_Bsnw0sFDVQinzW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86iHoACgkQSMVSH78upWOm+gCcDr+RSR+6oYJoI/wnWDeEH8z4 TjgAoIsCCmyuphbRaw1GUY0elArQgJ1o =rlmH -----END PGP SIGNATURE----- --Sig_/3M_wcT7J_Bsnw0sFDVQinzW-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:39:28 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAECA1065674; Tue, 14 Feb 2012 16:39:28 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B268D8FC14; Tue, 14 Feb 2012 16:39:28 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1EGdQjL084487; Tue, 14 Feb 2012 16:39:27 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F3A8E3E.9020901@FreeBSD.org> Date: Tue, 14 Feb 2012 17:39:26 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Fabian Keil References: <20120214171446.2a5e5eb1.fk@fabiankeil.de> In-Reply-To: <20120214171446.2a5e5eb1.fk@fabiankeil.de> X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9D14F69AFCF2EE4A2EFAD934" Cc: Greg Rivers , mlaier@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: sysutils/pftop on 9.x+ 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, 14 Feb 2012 16:39:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9D14F69AFCF2EE4A2EFAD934 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14.02.12 17:14, Fabian Keil wrote: > Greg Rivers wrote: >=20 >> sysutils/pftop was marked broken on 9.x and above last March[1]. Are = >> there any plans to fix it soon? It's a really handy utility. >> >> [1]=20 >> http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?re= v=3D1.17 >=20 > Please have a look at: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D155938 >=20 > Note that the currently working fix is in the audit trail, > the original fix stopped working after the PF update. The PR was closed by mistake, I'll take care of it. Florian --------------enig9D14F69AFCF2EE4A2EFAD934 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEUEARECAAYFAk86jj4ACgkQapo8P8lCvwnRhQCXSivVM2pI86yy/YpXqYY+RIpj DACg0NL8yFcM6USzsmtbhceHu6mZ7yY= =rrGG -----END PGP SIGNATURE----- --------------enig9D14F69AFCF2EE4A2EFAD934-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:40:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3145106566B; Tue, 14 Feb 2012 16:40:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3BE8FC16; Tue, 14 Feb 2012 16:40:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAD6OOk+DaFvO/2dsb2JhbABDhRCsGYFyAQEEASNWGxgCAg0ZAlkGiA+naZIIgS+KKCQZDQECAggDDgQGAwUMDwMBAgKDO4MjgRYEiEqMaJMC X-IronPort-AV: E=Sophos;i="4.73,417,1325480400"; d="scan'208";a="159505570" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 14 Feb 2012 11:39:51 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 43FF1B4040; Tue, 14 Feb 2012 11:39:51 -0500 (EST) Date: Tue, 14 Feb 2012 11:39:51 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F39D382.50209@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 16:40:04 -0000 Doug Barton wrote: > On 02/13/2012 19:13, Rick Macklem wrote: > > I just looked and at least some of the fixes were MFC'd to stable/8 > > about > > 8months ago. So, they aren't in 8.2, but will be in 8.3. > > Well 8.3 is about to enter code freeze, any way we can check to be > sure > all of the relevant fixes can be mfc'ed? > I took a look and they seem to have been MFC'd. rick > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:41:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F181065674 for ; Tue, 14 Feb 2012 16:41:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 214238FC16 for ; Tue, 14 Feb 2012 16:41:48 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1EGfeMX098115 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 08:41:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3A8F1E.8010402@freebsd.org> Date: Tue, 14 Feb 2012 08:43:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Ian Smith References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> <20120215014738.O95093@sola.nimnet.asn.au> In-Reply-To: <20120215014738.O95093@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary 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, 14 Feb 2012 16:41:49 -0000 On 2/14/12 7:43 AM, Ian Smith wrote: > On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote: > > Here is what I got, the first column is the number of requests, the second > > what is requested, and the 3rd my comments (basically it means, if there is a > > comment, it is not needed/possible to include in a modular kernel): > > ---snip--- > > [..] > > > 1 IPFIREWALL_FORWARD -> performance impact too big if unused (julian) well it's not that big but you will be running extra code for every packet unless you want it. when I made it an option but I was mainly trying to placate the "just say no" crowd. I perswonally wouldn't mind having it on by default in GENERIC, as long as we still make it an option so people who want every last drop of cpu can remove it. > I expect Julian will object if I've mis-paraphrased or over-simplified > something I recall him saying at least a couple of years ago :) > > [..] > > > 4 ALTQ* -> does add code to the pf module > > other impact? > > ipfw(8) can also apply ALTQ tags, but relies on pfctl(8) to setup the > queues - or so I read; I've not used it here. From altq(4): > > ALTQ Enable ALTQ. > ALTQ_CBQ Build the ``Class Based Queuing'' discipline. > ALTQ_RED Build the ``Random Early Detection'' extension. > ALTQ_RIO Build ``Random Early Drop'' for input and output. > ALTQ_HFSC Build the ``Hierarchical Packet Scheduler'' discipline. > ALTQ_CDNR Build the traffic conditioner. This option is meaningless at > the moment as the conditioner is not used by any of the > available disciplines or consumers. > ALTQ_PRIQ Build the ``Priority Queuing'' discipline. > ALTQ_NOPCC Required if the TSC is unusable. > ALTQ_DEBUG Enable additional debugging facilities. > > Note that ALTQ-disciplines cannot be loaded as kernel modules. In order > to use a certain discipline you have to build it into a custom kernel. > The pf(4) interface, that is required for the configuration process of > ALTQ can be loaded as a module. > > So which disciplines would one choose? Seeming an unlikely candidate? > > > 1 IPSTEALTH -> changes ipfw module only? > > I don't think this is specific to ipfw. From /sys/conf/NOTES: > > # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding > # packets without touching the TTL). This can be useful to hide firewalls > # from traceroute and similar tools. > > But can it be disabled once added to kernel? It's no good as a default. > > > 1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only? > > loader tunable? > > 1 IPFIREWALL_VERBOSE -> changes ipfw module only? > > loader tunable? > > sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit > > cheers, Ian > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 16:50:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B64C106566C for ; Tue, 14 Feb 2012 16:50:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id F0D498FC1F for ; Tue, 14 Feb 2012 16:50:30 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta10.emeryville.ca.mail.comcast.net with comcast id ZsTl1i0050FhH24AAsqWn9; Tue, 14 Feb 2012 16:50:30 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.emeryville.ca.mail.comcast.net with comcast id ZsqV1i00A1t3BNj8UsqVJe; Tue, 14 Feb 2012 16:50:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 30B5D102C1E; Tue, 14 Feb 2012 08:50:29 -0800 (PST) Date: Tue, 14 Feb 2012 08:50:29 -0800 From: Jeremy Chadwick To: Claudius Herder Message-ID: <20120214165029.GA1852@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3A83DE.3000200@ambtec.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 16:50:31 -0000 On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: > > Hello, > > I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still > persists on FreeBSD 9.0 release. > > Switching from ahci to ataahci resolved the problem for me too. > > I'm using gmirror for swap, system is on a zpool and the problem first > occurred during a zpool scrub, but it is easily reproducible with dd. > > The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} > of=/dev/null is not an issue. > Sometimes I need to power off the server because after a reboot one disk > is still missing. > > I really would like to help in this issue, so let me know if you need > any more information. I find it interesting that, at least so far, the only people reporting problems of this type with the ahci.ko driver are people using Samsung disks. The only difference is that your models are F1s while the OPs are F2s. The only difference I can think of is that the ahci.ko driver may have more strict timeouts than the ata driver (ata driver includes ataahci; ataahci.ko != ahci.ko, as you know). You may be able to adjust these using loader.conf variables: kern.cam.ada.default_timeout kern.cam.ada.retry_count I also imagine that hint.ahci.X.ccc might have some involvement here, but it's something I am not familiar with. mav@ would need to comment on this -- it's outside of my familiarity scope. Furthermore, in your case, your ada1 disk has serious CRC-related problems, and your ada0 disk has seen similar just at a much lower rate. ada1 should probably be replaced (along with cables, dusting out SATA ports, etc.), but keeping ada0 is probably fine. The statistics for these are shown in the "smartctl -l sataphy" output, field labelled ID 0x0001, "Command failed due to ICRC error". These are SATA-level problems or physical problems which will manifest themselves as anomalies during any kind of I/O. The counters shown in ID 0x000a and 0x0009 are completely fine; these don't indicate any problems. Your drives don't support GP log region 0x04, which is why "smartctl -l devstat" returns the errors it does. The errors you see coming from the kernel in this situation are 100% okay/acceptable; the drive itself is literally returning ABRT status to the inquiry submit to it. Different drives from different vendors behave differently in this regard. So, what I'm trying to say is, your problem looks different than the OPs. Let's not start a big "I have this problem too" thread; that has happened so many times over the years that when it happens I immediately bow out + stop participating in the thread. > smartctl -l sataphy /dev/ada0 > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x000a 2 150 Device-to-host register FISes sent due to a COMRESET > 0x0001 2 3 Command failed due to ICRC error > 0x0009 2 173 Transition from drive PhyRdy to drive PhyNRdy > > smartctl -l sataphy /dev/ada1 > > SATA Phy Event Counters (GP Log 0x11) > ID Size Value Description > 0x000a 2 155 Device-to-host register FISes sent due to a COMRESET > 0x0001 2 65535+ Command failed due to ICRC error > 0x0009 2 178 Transition from drive PhyRdy to drive PhyNRdy -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:08:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E829E1065677 for ; Tue, 14 Feb 2012 17:08:10 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62AF08FC16 for ; Tue, 14 Feb 2012 17:08:09 +0000 (UTC) Received: by werm13 with SMTP id m13so159780wer.13 for ; Tue, 14 Feb 2012 09:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=G0yadIgUDDmueBbogKEEHXRBP8XKxkGyq1SiPUxojP8=; b=R3ChNBCi60+RfxjpczZ8Lg/BNpGpU6xBzM9LxKAEC9o1fxSvG0bVQftRy91FTntkLD owtNHCziWyfO31ZO2hEGA/F7a+D0FFnx6lR5bkrT/HW1LLqZAjIDikepdY415/DoXzro uuX90RwVOI1rlzgl/9gQ/4vcChfZLc/E/mFhw= MIME-Version: 1.0 Received: by 10.216.134.160 with SMTP id s32mr8246893wei.36.1329237713158; Tue, 14 Feb 2012 08:41:53 -0800 (PST) Received: by 10.216.73.82 with HTTP; Tue, 14 Feb 2012 08:41:53 -0800 (PST) Date: Tue, 14 Feb 2012 11:41:53 -0500 Message-ID: From: Arnaud Lacombe To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: Complete hang on 9.0-RELEASE 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, 14 Feb 2012 17:08:11 -0000 Hi folks, For the records, I was running some tests yesterday on top of a 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the hang, the box was running a process with about 2800 threads with heavy IPC between 1400 writers and 1400 readers. The box was in single user mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning of the dmesg: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Atom(TM) CPU D510 @ 1.66GHz (1666.70-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106ca Family = 6 Model = 1c Stepping = 10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x20000800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2137587712 (2038 MB) avail memory = 2037841920 (1943 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <070611 APIC1125> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 I will restart the test and see if this happens again. regards, - Arnaud From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:09:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E73106576C for ; Tue, 14 Feb 2012 17:09:28 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7D88FC08 for ; Tue, 14 Feb 2012 17:09:27 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 08DFA2EF1 for ; Tue, 14 Feb 2012 16:57:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id UzvmxFwRlzrF for ; Tue, 14 Feb 2012 16:56:28 +0000 (UTC) Received: from [192.168.1.1] (a89-152-168-54.cpe.netcabo.pt [89.152.168.54]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id 109742ED7 for ; Tue, 14 Feb 2012 16:56:27 +0000 (UTC) Message-ID: <4F3A9237.5080901@barafranca.com> Date: Tue, 14 Feb 2012 16:56:23 +0000 From: Hugo Silva User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: CARP carpdev 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, 14 Feb 2012 17:09:28 -0000 Looks like there's been conversations about porting this to FreeBSD since at least 2007. Are there any plans to have ifconfig carpdev available in 9.0-STABLE? From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:15:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD568106564A for ; Tue, 14 Feb 2012 17:15:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 385388FC17 for ; Tue, 14 Feb 2012 17:15:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1EHFH7W019289; Wed, 15 Feb 2012 04:15:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 15 Feb 2012 04:15:17 +1100 (EST) From: Ian Smith To: Bruce Cran In-Reply-To: <4F37DBA3.7030304@cran.org.uk> Message-ID: <20120213195554.O46120@sola.nimnet.asn.au> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Stable Mailing List , Joe Holden , Alex Samorukov Subject: Re: New BSD Installer 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, 14 Feb 2012 17:15:27 -0000 On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote: > On 2/10/2012 7:47 PM, Alex Samorukov wrote: > > I am highly against reverting. Old installer is not GPT aware and in fact > > is unmaintained for a very long time. > > That's not really correct: quite a lot of work was done on it last year. Indeed. Was it you working on the updated sade(8) adding GPT and ZFS? I don't see it in terms of reverting. Much other useful functionality of sysinstall has yet to be reimplemented. Sure, I know, send code .. but it's not only the functionality lost, but the ability for new users to accomplish a good deal of initial server setup before they're skilled enough to do it all from the command line, which is where I was in '98. I also think much of the sometimes gratuitous deprecation of sysinstall is unwarranted. I've used sysinstall post-installation regularly since '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2. Since one small disaster on 3.3 about 12 years ago (installing to the wrong slice) I've had no major issues with it, mostly partitioning all sorts of disks but also browsing and adding useful packages at installation. Strangely, the big push to GPT partitions was oft said to be because MBR slices provided too few partitions. I never found 4 * 6 much of a limit myself, and now the default install makes a Linux-like single partition, rendering dump & restore more or less unusable or at least impractical, while booting multiple systems on GPT also seems to require Linux tools. I don't know whether this move away from BSD traditional filesystem partitioning (/, /var, /usr etc) to Linux-style came down from Core On High or is just the prerogative of installer-writers? Jordan was both the latter and a big part of the former for many years, but I guess that's something that can be reverted if people feel to do so. I expect most developers run mostly the latest gear, and nowadays tend to use vbox images a good deal, but there will be many laptops and other systems using MBR slices and bsdlabel partitions for years to come, and I'd hate to see FreeBSD's longterm support for _slightly_ older hardware disappear, just because of having added better support for latest kit. I for one will be screwed if sade, fdisk and bsdlabel disappear, as the release notes for 9 seem to indicate may be imminently on the cards. cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:16:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6E68106567E for ; Tue, 14 Feb 2012 17:16:31 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 82D5A8FC20 for ; Tue, 14 Feb 2012 17:16:31 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q1EGn51I065829; Tue, 14 Feb 2012 09:49:05 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q1EGn4LF065828; Tue, 14 Feb 2012 09:49:04 -0700 (MST) (envelope-from ken) Date: Tue, 14 Feb 2012 09:49:04 -0700 From: "Kenneth D. Merry" To: Ollivier Robert Message-ID: <20120214164903.GA63724@nargothrond.kdm.org> References: <20120202191105.GA55719@nargothrond.kdm.org> <20120213140844.GA61050@roberto-aw.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213140844.GA61050@roberto-aw.eurocontrol.fr> User-Agent: Mutt/1.4.2i Cc: freebsd-stable@freebsd.org Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 14 Feb 2012 17:16:31 -0000 On Mon, Feb 13, 2012 at 15:08:45 +0100, Ollivier Robert wrote: > According to Kenneth D. Merry: > > The LSI-supported version of the mps(4) driver that supports their 6Gb SAS > > HBAs as well as WarpDrive controllers, is now in stable/9 and stable/8. > > Thanks. > > > Note that the CAM infrastructure changes that went into FreeBSD/head along > > with this driver have not gone into either stable/9 or stable/8. Only the > > driver itself has been merged. > > > > The CAM infrastructure changes depend on some other da(4) driver changes > > that will need to get merged before they can go back. If that merge > > happens, it will probably only be into stable/9. > > Got an ETA for this? Saying differently, is it reasonable to run stable/9 with the new driver but w/o the CAM changes? What do these changes bring BTW? Sorry, been out-of-touch these days :( > No ETA for the CAM changes. I need to talk with Alexander Motin about it, and I haven't gotten around to that. Too busy with other things. The changes just allow the driver to get notification from CAM about read capacity data instead of having the driver probe by itself. The probe in the driver for stable is kludgy, but does work. So it is perfectly fine to run the driver in stable/9 or stable/8 without the CAM changes. The latest mps(4) driver changes have been merged into stable/9 and stable/8, so this would be a good time to try it out. Ken -- Kenneth Merry ken@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:17:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03FC9106566C for ; Tue, 14 Feb 2012 17:17:41 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 661F28FC14 for ; Tue, 14 Feb 2012 17:17:39 +0000 (UTC) Received: from titan.wdn.omnilan.net (titan.lo4.wdn.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q1EHHRnL005218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 18:17:27 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.wdn.omnilan.net [172.21.1.150] claimed to be titan.wdn.omnilan.net Message-ID: <4F3A971F.9040407@omnilan.de> Date: Tue, 14 Feb 2012 18:17:19 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> In-Reply-To: <20120214165029.GA1852@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5467461311D5A8AAB5A9CABE" Cc: freebsd-stable@freebsd.org, Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 17:17:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5467461311D5A8AAB5A9CABE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): > On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: >> Hello, >> >> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it sti= ll >> persists on FreeBSD 9.0 release. >> >> Switching from ahci to ataahci resolved the problem for me too. >> >> I'm using gmirror for swap, system is on a zpool and the problem first= >> occurred during a zpool scrub, but it is easily reproducible with dd. >> >> The timeouts only occur when writing to disks, dd if=3D/dev/ada{0|1} >> of=3D/dev/null is not an issue. >> Sometimes I need to power off the server because after a reboot one di= sk >> is still missing. >> >> I really would like to help in this issue, so let me know if you need >> any more information. > I find it interesting that, at least so far, the only people reporting > problems of this type with the ahci.ko driver are people using Samsung > disks. The only difference is that your models are F1s while the OPs > are F2s. I saw such timeouts long ago and mav@ had a look at my postings and he mentioned it could be a NCQ problem. I suspected the disks firmware. I never tracked it down further, because after replacing the Samsung (F3 in that case) disks with hitachi ones solved all my problems and gave a big performance kick as well (with zfs). You can find the discussion here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.ht= ml JFI -Harry --------------enig5467461311D5A8AAB5A9CABE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86lycACgkQLDqVQ9VXb8jppgCeIimntlGuAZmneF8SUrZ74yVS 9isAnixsNUzhGIEmwfqrIteeFbo39Mru =VO7E -----END PGP SIGNATURE----- --------------enig5467461311D5A8AAB5A9CABE-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:28:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF3E1065676 for ; Tue, 14 Feb 2012 17:28:05 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id CC5C18FC13 for ; Tue, 14 Feb 2012 17:28:04 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id C1EAB6A6647; Tue, 14 Feb 2012 18:28:03 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id bm-tAWuBJakE; Tue, 14 Feb 2012 18:28:03 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 80CBD6A6245; Tue, 14 Feb 2012 18:28:03 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id q1EHS32c004500; Tue, 14 Feb 2012 18:28:03 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id q1EHS1GM003900; Tue, 14 Feb 2012 18:28:01 +0100 (CET) (envelope-from lars) Date: Tue, 14 Feb 2012 18:28:01 +0100 From: Lars Engels To: Ian Smith Message-ID: <20120214172801.GA93151@e-new.0x20.net> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DaTEgnRu5pEC8TLg" Content-Disposition: inline In-Reply-To: <20120213195554.O46120@sola.nimnet.asn.au> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Bruce Cran , Alex Samorukov , Joe Holden , FreeBSD Stable Mailing List Subject: Re: New BSD Installer 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, 14 Feb 2012 17:28:05 -0000 --DaTEgnRu5pEC8TLg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 04:15:17AM +1100, Ian Smith wrote: > On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote: > > On 2/10/2012 7:47 PM, Alex Samorukov wrote: > > > I am highly against reverting. Old installer is not GPT aware and in= fact > > > is unmaintained for a very long time. > >=20 > > That's not really correct: quite a lot of work was done on it last yea= r. >=20 > Indeed. Was it you working on the updated sade(8) adding GPT and ZFS? >=20 > >=20 > I don't see it in terms of reverting. Much other useful functionality=20 > of sysinstall has yet to be reimplemented.=20 What exactly are you missing? There's sysutils/host-setup to configure your system like sysinstall did. There's sade and I am working on a tool to browse and add packages from the installation media and / or the ftp mirrors. --DaTEgnRu5pEC8TLg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86maEACgkQKc512sD3afiQtACeOstCNR5OXkxcT5HSwvY4kKj/ it0An2WIGvc1TVimGJpEU7VhZ6uOuAyi =9bEM -----END PGP SIGNATURE----- --DaTEgnRu5pEC8TLg-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:33:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80ED3106564A for ; Tue, 14 Feb 2012 17:33:24 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF658FC0C for ; Tue, 14 Feb 2012 17:33:23 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so224307vbb.13 for ; Tue, 14 Feb 2012 09:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r82MJmcWqsBu5upX5yRJ29yOxxjpZcdhVtxB40HeFXQ=; b=S5eFfm0xVaUMCxhXjh+e0eJ5fmT1okUZdKH0MCp503gFfMb4suJf0XbOdltw8aCQ0N bvLlsAx2Az9rDc/L2ZCYhDdaYWA9/Yd76hC4ewZSvbhJzPj7B+WXqTLUDwuMqduTsewe UBlPyVQLdwK+tzBRoWP7Vm9bXGT8D2bQuxaK8= MIME-Version: 1.0 Received: by 10.52.27.70 with SMTP id r6mr9579179vdg.41.1329240803480; Tue, 14 Feb 2012 09:33:23 -0800 (PST) Received: by 10.220.192.135 with HTTP; Tue, 14 Feb 2012 09:33:23 -0800 (PST) In-Reply-To: <4F3A9237.5080901@barafranca.com> References: <4F3A9237.5080901@barafranca.com> Date: Tue, 14 Feb 2012 09:33:23 -0800 Message-ID: From: Freddie Cash To: Hugo Silva Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: CARP carpdev 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, 14 Feb 2012 17:33:24 -0000 On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote: > Looks like there's been conversations about porting this to FreeBSD since at > least 2007. > > Are there any plans to have ifconfig carpdev available in 9.0-STABLE? CARP support has been redone in 10-CURRENT, removing the whole "carp0" pseudo-interface support, and just enabling the CARP protocol on the existing network interfaces. This includes the equivalent of "carpdev" support. Search the -current archives for more information, CFT, and so on. I don't recall seeing anything about specific plans to MFC to stable/9, but could be mis-remembering things. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:44:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A680B1065672 for ; Tue, 14 Feb 2012 17:44:16 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDDC8FC16 for ; Tue, 14 Feb 2012 17:44:16 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa04 [127.0.0.1]) by ltcfislmsgpa04.fnfis.com (8.14.4/8.14.4) with SMTP id q1EHVZQH001208; Tue, 14 Feb 2012 11:44:11 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa04.fnfis.com with ESMTP id 12yv31r1r6-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 11:44:11 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 11:43:30 -0600 From: Devin Teske To: "'Ian Smith'" , "'Bruce Cran'" References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> In-Reply-To: <20120213195554.O46120@sola.nimnet.asn.au> Date: Tue, 14 Feb 2012 09:43:35 -0800 Message-ID: <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHpLgw2N43SAX2EkCOmVhPWC2ZpSwJNZ8ORAfwXlJcCVCvdvZXPMgRQ Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_04:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: 'Alex Samorukov' , 'Joe Holden' , 'FreeBSD Stable Mailing List' Subject: RE: New BSD Installer 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, 14 Feb 2012 17:44:16 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Ian Smith > Sent: Tuesday, February 14, 2012 9:15 AM > To: Bruce Cran > Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov > Subject: Re: New BSD Installer > > On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote: > > On 2/10/2012 7:47 PM, Alex Samorukov wrote: > > > I am highly against reverting. Old installer is not GPT aware and in fact > > > is unmaintained for a very long time. > > > > That's not really correct: quite a lot of work was done on it last year. > > Indeed. Was it you working on the updated sade(8) adding GPT and ZFS? > > > > I don't see it in terms of reverting. Much other useful functionality > of sysinstall has yet to be reimplemented. Ron McDowell and I are working feverishly on bsdconfig(8) set to arrive in 10.0-CURRENT Highlights: - It's modular - It's easily estendable/maintained (written in sh(1)) - It's goal is to completely reimplement all missing functionality from sysinstall(8) However, it's still in the preliminary stages. Discussions on bsdconfig are being held on -sysinstall@ Development work is being performed off the reservation (using SourceForge CVS server) until we can agree on the structure prior to import to the base of HEAD SVN tree. Despite being preliminary code, there is currently 8529 lines of code so far. I won't be posting links to the preliminary code (it's still preliminary) for fear of getting too much feedback too early in the game (but if you're interested, you can crawl the recent posts to -sysinstall@ and gleen the links both from Ron and myself). > Sure, I know, send code .. > but it's not only the functionality lost, but the ability for new users > to accomplish a good deal of initial server setup before they're skilled > enough to do it all from the command line, which is where I was in '98. > bsdconfig(8) will fill this gap as sysinstall(8) did in the past. The current plan moving forward is: 1. RELENG_9 will continue to offer both sysinstall and bsdinstall in the installed base 2. RELENG_10 will drop sysinstall(8) but bring in bsdconfig(8) This much has been agreed upon in the discussions involving many. > I also think much of the sometimes gratuitous deprecation of sysinstall > is unwarranted. Yes, it has been acknowledged by many that the scheduled deprecation is aggressive. > I've used sysinstall post-installation regularly since > '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2. Since one > small disaster on 3.3 about 12 years ago (installing to the wrong slice) > I've had no major issues with it, mostly partitioning all sorts of disks > but also browsing and adding useful packages at installation. > When bsdconfig(8) reaches a usable state (is entered into HEAD), we encourage you to be an avid tester in the early stages to make sure we "get it right" with respect to replication of sysinstall(8) features. bsdconfig(8) should work fine on RELENG_9 just as 10.0-CURRENT > Strangely, the big push to GPT partitions was oft said to be because MBR > slices provided too few partitions. That's part of it (no pun intended). The other big deal is that you can't exceed 2TB on a single primary partition. > I never found 4 * 6 much of a limit > myself, and now the default install makes a Linux-like single partition, > rendering dump & restore more or less unusable or at least impractical, I'm with you on this one. I really don't like the single-"/" setup. > while booting multiple systems on GPT also seems to require Linux tools. > > I don't know whether this move away from BSD traditional filesystem > partitioning (/, /var, /usr etc) to Linux-style came down from Core On > High or is just the prerogative of installer-writers? Jordan was both > the latter and a big part of the former for many years, but I guess > that's something that can be reverted if people feel to do so. > Maybe a vote should be taken. There's about 12 votes in this office here alone for putting the partition scheme back the way it was (Colin Percival had a great formula for determining partition sizes). > I expect most developers run mostly the latest gear, and nowadays tend > to use vbox images a good deal, but there will be many laptops and other > systems using MBR slices and bsdlabel partitions for years to come, and > I'd hate to see FreeBSD's longterm support for _slightly_ older hardware > disappear, just because of having added better support for latest kit. > Others will point out that if you try hard enough, you can create the old-style MBR partitions with RELENG_9 (note: some minor bugs were documented in 9.0-RELEASE; the next release will not suffer these fallbacks). > I for one will be screwed if sade, fdisk and bsdlabel disappear, as the > release notes for 9 seem to indicate may be imminently on the cards. > I too would be sad if those disappear. However, I do think sysinstall(8) needs to be deprecated (given that we're developing bsdconfig(8) to replace it). -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:49:07 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6B96106566B; Tue, 14 Feb 2012 17:49:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 742D28FC13; Tue, 14 Feb 2012 17:49:07 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q1EHn6KI031145; Tue, 14 Feb 2012 17:49:06 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q1EHn6B2031125; Tue, 14 Feb 2012 17:49:06 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 14 Feb 2012 17:49:06 GMT Message-Id: <201202141749.q1EHn6B2031125@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:49:07 -0000 TB --- 2012-02-14 15:28:02 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-02-14 15:28:02 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2012-02-14 15:28:02 - cleaning the object tree TB --- 2012-02-14 15:28:02 - cvsupping the source tree TB --- 2012-02-14 15:28:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/ia64/ia64/supfile TB --- 2012-02-14 15:29:05 - building world TB --- 2012-02-14 15:29:05 - CROSS_BUILD_TESTING=YES TB --- 2012-02-14 15:29:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-14 15:29:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-14 15:29:05 - SRCCONF=/dev/null TB --- 2012-02-14 15:29:05 - TARGET=ia64 TB --- 2012-02-14 15:29:05 - TARGET_ARCH=ia64 TB --- 2012-02-14 15:29:05 - TZ=UTC TB --- 2012-02-14 15:29:05 - __MAKE_CONF=/dev/null TB --- 2012-02-14 15:29:05 - cd /src TB --- 2012-02-14 15:29:05 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 14 15:29:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Feb 14 17:15:08 UTC 2012 TB --- 2012-02-14 17:15:08 - generating LINT kernel config TB --- 2012-02-14 17:15:08 - cd /src/sys/ia64/conf TB --- 2012-02-14 17:15:08 - /usr/bin/make -B LINT TB --- 2012-02-14 17:15:08 - cd /src/sys/ia64/conf TB --- 2012-02-14 17:15:08 - /usr/sbin/config -m LINT TB --- 2012-02-14 17:15:08 - building LINT kernel TB --- 2012-02-14 17:15:08 - CROSS_BUILD_TESTING=YES TB --- 2012-02-14 17:15:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-14 17:15:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-14 17:15:08 - SRCCONF=/dev/null TB --- 2012-02-14 17:15:08 - TARGET=ia64 TB --- 2012-02-14 17:15:08 - TARGET_ARCH=ia64 TB --- 2012-02-14 17:15:08 - TZ=UTC TB --- 2012-02-14 17:15:08 - __MAKE_CONF=/dev/null TB --- 2012-02-14 17:15:08 - cd /src TB --- 2012-02-14 17:15:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Feb 14 17:15:09 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:329: warning: implicit declaration of function 'mpssas_find_target_by_handle' /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:329: warning: nested extern declaration of 'mpssas_find_target_by_handle' [-Wnested-externs] /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:329: warning: assignment makes pointer from integer without a cast /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:396: warning: implicit declaration of function 'mpssas_prepare_volume_remove' /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:396: warning: nested extern declaration of 'mpssas_prepare_volume_remove' [-Wnested-externs] /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:403: warning: assignment makes pointer from integer without a cast /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:469: warning: assignment makes pointer from integer without a cast /src/sys/modules/mps/../../dev/mps/mps_sas_lsi.c:481: warning: assignment makes pointer from integer without a cast *** Error code 1 Stop in /src/sys/modules/mps. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-14 17:49:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-14 17:49:05 - ERROR: failed to build LINT kernel TB --- 2012-02-14 17:49:05 - 5814.42 user 834.07 system 8463.93 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:04:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE27106566C for ; Tue, 14 Feb 2012 18:04:04 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3A08FC0A for ; Tue, 14 Feb 2012 18:04:04 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa05 [127.0.0.1]) by ltcfislmsgpa05.fnfis.com (8.14.4/8.14.4) with SMTP id q1EHYMK6003007; Tue, 14 Feb 2012 12:03:56 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa05.fnfis.com with ESMTP id 12yv4ag48v-5 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 12:03:56 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 12:03:53 -0600 From: Devin Teske To: "'Lars Engels'" , "'Ian Smith'" References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <20120214172801.GA93151@e-new.0x20.net> In-Reply-To: <20120214172801.GA93151@e-new.0x20.net> Date: Tue, 14 Feb 2012 10:03:58 -0800 Message-ID: <092e01cceb43$06b25b30$14171190$@fisglobal.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHpLgw2N43SAX2EkCOmVhPWC2ZpSwJNZ8ORAfwXlJcCVCvdvQD7dkbUlcdbOPA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_04:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Content-Type: text/plain; charset="utf-8" Cc: 'Bruce Cran' , 'FreeBSD Stable Mailing List' , 'Joe Holden' , 'Alex Samorukov' Subject: RE: New BSD Installer 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, 14 Feb 2012 18:04:04 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Lars Engels > Sent: Tuesday, February 14, 2012 9:28 AM > To: Ian Smith > Cc: Bruce Cran; Alex Samorukov; Joe Holden; FreeBSD Stable Mailing List > Subject: Re: New BSD Installer >=20 > On Wed, Feb 15, 2012 at 04:15:17AM +1100, Ian Smith wrote: > > On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote: > > > On 2/10/2012 7:47 PM, Alex Samorukov wrote: > > > > I am highly against reverting. Old installer is not GPT aware and = in fact > > > > is unmaintained for a very long time. > > > > > > That's not really correct: quite a lot of work was done on it last y= ear. > > > > Indeed. Was it you working on the updated sade(8) adding GPT and ZFS? > > > > > > > > I don't see it in terms of reverting. Much other useful functionality > > of sysinstall has yet to be reimplemented. >=20 > What exactly are you missing? > There's sysutils/host-setup to configure your system like sysinstall > did. sysutils/host-setup (written/maintained by me) is only good for the followi= ng bits right now: 1. Time zone 2. Hostname/Domain 3. Network Interfaces 4. Default Router/Gateway 5. DNS nameservers There's still quite a bit more that sysinstall(8) offered which isn't provi= ded by anything yet (sysutils/host-setup included). > There's sade and I am working on a tool to browse and add packages from > the installation media and / or the ftp mirrors. Ron McDowell and I are working on a new tool named "bsdconfig(8)" which is = very modular and written in sh(1). bsdconfig(8) is designed squarely at reimplementing all of the sysinstall(8= ) post-install bits so that we can cleanly whack sysinstall(8) without the = prior complaints. The portion of bsdconfig(8) that will handle browsing and adding of package= s from either the installation media or ftp mirrors is incomplete at the mo= ment, and we'd love it if you were willing to either: (a) download the preliminary framework for bsdconfig(8) and start working o= n the packages module, or (b) join the SourceForge CVS project and start working on bsdconfig(8) in r= ealtime with Ron and I NOTE: Choice of either option will result in further information being disb= ursed for your digestive pleasure. So far, bsdconfig(8) has the 8529 lines of code (counting all modules, inte= rnationalization files, and Makefiles) with the following modules/component= s (status listed for each): 1. Distributions Description: Install additional distribution sets Status: pending development 2. Documentation installation Description: Install FreeBSD Documentation set Status: Done. Links to "bsdinstall docsinstall" 3. Packages Description: Install Pre-packaged Software Status: pending development 4. Password Description: Set Root Password Status: pending development 5. Fdisk Description: Fdisk Partition Editor Status: pending development Note: Could be linked directly to sade(8) 6. Disklabel Description: Disk Label Editor Status: pending development Note: Could be linked directly to sade(8) 7. Login/Group Management Description: Add user's login and group information Status: Done (by Ron McDowell) 8. Console Description: Console Settings Status: pending development 9. Timezone Description: Set up Time Zone Status: Done (by Devin Teske; me) NOTE: Functionality shamelessly ripped from my ports addition: sysutils/tzd= ialog 10. Media Selection Description: Select Media to Install From Status: pending development 11. Mouse Description: Configure the Mouse Status: pending development 12. Networking Management Description: Setup Networking interfaces, services, etc. Status: Done (by Devin Teske; me) NOTE: Functionality shamelessly ripped from my ports addition: sysutils/hos= t-setup 13. Security Description: Set Security Parameters Status: pending development 14. Startup Description: Set Startup Parameters Status: pending development 15. Ttys Description: Configure Ttys Status: pending development I am currently working on the framework some more and then I'm going to jum= p over to working on #14 "Startup". As you can see from the above-list, we have quite a bit of functionality to= migrate from sysinstall(8) over to bsdconfig(8) -- however the most diffic= ult bits (user management, network management, and timezone have all been d= one so the rest should fall like a house of cards -- especially since we ha= ve really nice modular includes making the modules nice and light-weight). --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:08:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752771065679 for ; Tue, 14 Feb 2012 18:08:38 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFB98FC1B for ; Tue, 14 Feb 2012 18:08:37 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1EI8Aec005270 ; Tue, 14 Feb 2012 19:08:23 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1EI87U1084432; Tue, 14 Feb 2012 19:08:07 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1EI87aV084429; Tue, 14 Feb 2012 19:08:07 +0100 (CET) (envelope-from arno) To: Lystopad Aleksandr From: "Arno J. Klaassen" References: <20120214044234.GT98031@laa.zp.ua> Date: Tue, 14 Feb 2012 19:08:07 +0100 In-Reply-To: <20120214044234.GT98031@laa.zp.ua> (Lystopad Aleksandr's message of "Tue\, 14 Feb 2012 08\:42\:34 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3AA30A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3AA30A.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 18:08:38 -0000 Hallo Aleksandr, > Hello, Arno J. Klaassen! > > On Sat, Feb 11, 2012 at 04:53:10PM +0100 > arno@heho.snv.jussieu.fr wrote about "9-stable : geli + one-disk ZFS fails": >> >> Hello, >> >> >> I finally decided to 'play' a bit with ZFS on a notebook, some years >> old, but I installed a brand new disk and memtest passes OK. >> >> I installed base+ports on partition 2, using 'classical' UFS. >> >> I crypted partition 3 and created a single zpool on it containing >> 4 Z-"file-systems" : >> >> [root@cc ~]# zfs list >> NAME USED AVAIL REFER MOUNTPOINT >> zfiles 10.7G 377G 152K /zfiles >> zfiles/home 10.6G 377G 119M /zfiles/home >> zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> >> >> I export the ZFS's via nfs and rsynced on the other machine some backup >> of my current note-book (geli + UFS, (almost) same 9-stable version, no >> problem) to the ZFS's. >> >> >> Quite fast, I see on the notebook : >> >> >> [root@cc /usr/temp]# zpool status -v >> pool: zfiles >> state: ONLINE >> status: One or more devices has experienced an error resulting in data >> corruption. Applications may be affected. >> action: Restore the file in question if possible. Otherwise restore the >> entire pool from backup. >> see: http://www.sun.com/msg/ZFS-8000-8A >> scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> 2012 >> config: >> >> NAME STATE READ WRITE CKSUM >> zfiles ONLINE 0 0 11 >> ada0s3.eli ONLINE 0 0 23 >> >> errors: Permanent errors have been detected in the following files: >> >> /zfiles/home/arno/.scito/contrib/XNAT.tar >> [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> [root@cc /usr/temp]# >> >> >> As said, memtest is OK, nothing is logged to the console, UFS on the >> same disk works OK (I did some tests copying and comparing random data) >> and smartctl as well seems to trust the disk : >> >> SMART Self-test log structure revision number 1 >> Num Test_Description Status Remaining LifeTime(hours) >> # 1 Extended offline Completed without error 00% 388 >> # 2 Short offline Completed without error 00% 387 >> >> >> Am I doing something wrong and/or let me know what I could provide as >> extra info to try to solve this (dmesg.boot at the end of this mail). >> >> Thanx a lot in advance, >> >> best, Arno > > Arno, you forgot to say how are you create geli partiotion. > It is important. geli init /dev/ada0s3 (should I have used ' -s 4096 ' ???) I added later : geli attach -k /tmp/ifmemoryfails.key1 -p /dev/ada0s3 In fact, on my regular laptop on which I now use UFS on top of GELI I use /dev/ada0s3f, not the whole partition .... Hope this helps ;-) thanx, best, Arno From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:10:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C83711065675 for ; Tue, 14 Feb 2012 18:10:18 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id AB4FF8FC08 for ; Tue, 14 Feb 2012 18:10:18 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta14.emeryville.ca.mail.comcast.net with comcast id Zu9m1i0020vp7WLAEuAJYk; Tue, 14 Feb 2012 18:10:18 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id ZuAG1i01J4NgCEG8RuAHso; Tue, 14 Feb 2012 18:10:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q1EIAFOn039775; Tue, 14 Feb 2012 11:10:15 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Jason Hellenthal In-Reply-To: <20120214051255.GA82468@DataIX.net> References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> <20120214051255.GA82468@DataIX.net> Content-Type: text/plain Date: Tue, 14 Feb 2012 11:10:15 -0700 Message-Id: <1329243015.37092.185.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: john fleming , "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? 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, 14 Feb 2012 18:10:18 -0000 On Tue, 2012-02-14 at 00:12 -0500, Jason Hellenthal wrote: > > On Mon, Feb 13, 2012 at 08:43:08PM -0800, john fleming wrote: > > Just thought i would post over here as i'm not getting a warm fuzzy from checkpoint about being able to find the root cause of an issue. I have a large install base of IPSO checkpoint firewalls, which are based on FreeBSD 6.2. I've had 3 firewalls hang basically the same way, with something that looks like a filesystem issue or an issue with a CF card. > > > > Does anyone happen to know of any bugs (i've been looking around) that could cause something like that? Granted, it could be a batch of bad CF cards, but its odd that i'm seeing the same thing on 3 different boxes and once rebooted they seem ok. > > > > Also is it possible to get useful info form the atacontroller when things go south like this from the ddb prompt? > > > > This is what shows in show msgbuf > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > ad0: timeout waiting to issue command > > ad0: error issuing WRITE command > > g_vfs_done():ad0s4h[WRITE(offset=33849344, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=33980416, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34111488, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34242560, length=131072)]error = 5 > > g_vfs_done():ad0s4h[WRITE(offset=34373632, length=131072)]error = 5 > > > > ad0: 1882MB at ata0-master PIO4 > > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f mem 0x80301000-0x803013ff at device 31.1 on pci0 > > ata0: on atapci0 > > ata1: on atapci0 > > atapci1: port 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0x50a3,0x5060-0x506f irq 15 at device 31.2 on pci0 > > ata2: on atapci1 > > ata3: on atapci1ad0s4h is basically a r/w ufs partition on the box where almost anything that needs to be written goes. > > trace > > Tracing pid 1101 tid 100043 td 0x656d8460 > > kdb_enter(608cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b > > siointr1(64ba1400) at siointr1+0xf0 > > siointr(64ba1400) at siointr+0x38 > > intr_execute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at intr_execute_handler+0x61 > > intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at intr_execute_handlers+0x40 > > atpic_handle_intr(4) at atpic_handle_intr+0x96 > > Xatpic_intr4() at Xatpic_intr4+0x20 > > --- interrupt, eip = 0x606044af, esp = 0xf0a4ab48, ebp = 0xf0a4ab5c --- > > lockmgr(e1456a04,6,0,656d8460) at lockmgr+0x58f > > getdirtybuf(e14569a4,60a405e4,1) at getdirtybuf+0x2e2 > > flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30 > > flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf > > softdep_sync_metadata(65964618) at softdep_sync_metadata+0x61 > > ffs_syncvnode(65964618,1) at ffs_syncvnode+0x3a2 > > ffs_fsync(f0a4ac74) at ffs_fsync+0x12 > > VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38 > > fsync(656d8460,f0a4acb4) at fsync+0x170 > > syscall(805003b,806003b,5fbf003b,8050000,288be450,...) at syscall+0x2ee > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > This looks to be a problem with softupdates and CF cards. Can you get > this to repeat on a brand new (good) card ? > EIO errors on a write that lead to a panic nearly always backtrace into the softupdates code, because that code pretty much has to panic if it can't write things in the proper order. That doesn't imply that the softupdates code is at fault in any way, or that the errors would go away if softupdates were turned off. In fact, I consider it important to have softupdates enabled on CF and SDCard media. The number of writes (and especially of repeated re-writes of the same filesystem metadata sectors) goes way way up without SU enabled, and that's bad for media with a limited number of write cycles in its lifetime. We've been using 6.2 with SU enabled on CF cards for many years at Symmetricom; we're still shipping systems with that config. Depending on the motherboard or SBC, we often have to disable ata DMA, or limit it to a max of WDMA2 mode. The indication that you need to do so is typically a lockup either trying to load the kernel and modules, or sometimes that works but it locks up while initializing the ata driver. [1] If your systems have been running fine with DMA enabled, it's not the sort of problem that suddenly appears out of the blue. You find out when you need to disable it pretty quickly on new hardware because it doesn't boot reliably. I tend to agree with Jeremy's assesment that you may have some CF cards that have neared the end of their life, and especially if they're full the automatic wear leveling can't find any un-worn cells to use. If the cards are old they may have primitive wear-leveling code in the controllers. [2] Having 3 cards fail at about the same time on similar systems could be a sign of this if they were bought at the same time. We had the unhappy experience of having a large batch of cards bought around the same time all fail around the same time in the field. [1] If it locks up in the mbr or btx loader you have to disable DMA in the bios settings as well as with the loader tunable that's used by the ata driver. [2] I've read white papers about new algorithms in CF controllers that do things like notice when a sector has been occupied with data that was written once and has been read many times without re-writing. These controllers will actually relocate such data to a cell that doesn't have many write cycles left but can still be read reliably, freeing up a cell that has only one write in its life history. Older cards are not nearly as smart as that. -- Ian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:23:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08011065670 for ; Tue, 14 Feb 2012 18:23:24 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id 197168FC0C for ; Tue, 14 Feb 2012 18:23:23 +0000 (UTC) Received: (qmail 31183 invoked from network); 14 Feb 2012 18:22:23 -0000 Received: from pd9ec0d44.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.13.68]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 14 Feb 2012 18:22:23 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id B72EF1BAC55; Tue, 14 Feb 2012 19:23:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1329243800; bh=+8npegbf7VCl5hV80CQtJvOOsiBy7B6djDegiAfhB9M=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=jVoZgwDR9OnSPm8jp6oHKP1veVfeYneYQCLq6bBZ0NZl5BQGLAZ9xVyGVrhhrNYq/ 0OQ1yYA53zkSzbg+DCL+6Q96YG1Y36nIn0CjHbFB+KYO3Gdq9cxdJHzSOwkT9ZaS4r Og6Eg48mZCimEHVSkLE+675jIh59/BbGHBz2oMoY= Date: Tue, 14 Feb 2012 19:23:19 +0100 From: Martin Sugioarto To: Harald Schmalzbauer Message-ID: <20120214192319.44ff7aff@zelda.sugioarto.com> In-Reply-To: <4F3A971F.9040407@omnilan.de> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 18:23:24 -0000 Am Tue, 14 Feb 2012 18:17:19 +0100 schrieb Harald Schmalzbauer : > > I find it interesting that, at least so far, the only people > > reporting problems of this type with the ahci.ko driver are people > > using Samsung disks. The only difference is that your models are > > F1s while the OPs are F2s. > > I saw such timeouts long ago and mav@ had a look at my postings and he > mentioned it could be a NCQ problem. > I suspected the disks firmware. > I never tracked it down further, because after replacing the Samsung > (F3 in that case) disks with hitachi ones solved all my problems and > gave a big performance kick as well (with zfs). > You can find the discussion here: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html Hi, I just want to add here that I am using 2 drives of type "Samsung HD103SJ" (SpinPoint F3). And I did not have problems with ZFS and with UFS either (for several years now). Everything has been deployed ontop ada(4) since FreeBSD-8. Actually the speed is very good (sequential read at 140 MB/s and more). -- Martin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:30:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB691065691; Tue, 14 Feb 2012 18:30:54 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1DF8FC29; Tue, 14 Feb 2012 18:30:53 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q1EIK1Sb023178; Tue, 14 Feb 2012 18:20:01 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q1EIK1pa032530; Tue, 14 Feb 2012 18:20:01 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q1EIK1MP032526; Tue, 14 Feb 2012 18:20:01 GMT Date: Tue, 14 Feb 2012 18:20:01 GMT Message-Id: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> From: Martin Simmons To: "Arno J. Klaassen" In-reply-to: (arno@heho.snv.jussieu.fr) References: Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 18:30:54 -0000 Some random ideas: 1) Can you dd the whole of ada0s3.eli without errors? 2) If you scrub a few more times, does it find the same number of errors each time and are they always in that XNAT.tar file? 3) Can you try zfs without geli? 4) Is the slice/partition layout definitely correct? __Martin >>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: > > hello, > > to eventually gain interest in this issue : > > I updated to today's -stable, tested with vfs.zfs.debug=1 > and vfs.zfs.prefetch_disable=0, no difference. > > I also tested to read the raw partition : > > [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror > 103746636+0 records in > 103746636+0 records out > 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) > [root@cc /usr/ports]# > > Disk is brand new, looks ok, either my setup is not good or there is > a bug somewhere; I can play around with this box for some more time, > please feel free to provide me with some hints what to do to be useful > for you. > > Best, > > Arno > > > "Arno J. Klaassen" writes: > > > Hello, > > > > > > I finally decided to 'play' a bit with ZFS on a notebook, some years > > old, but I installed a brand new disk and memtest passes OK. > > > > I installed base+ports on partition 2, using 'classical' UFS. > > > > I crypted partition 3 and created a single zpool on it containing > > 4 Z-"file-systems" : > > > > [root@cc ~]# zfs list > > NAME USED AVAIL REFER MOUNTPOINT > > zfiles 10.7G 377G 152K /zfiles > > zfiles/home 10.6G 377G 119M /zfiles/home > > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno > > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv > > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito > > > > > > I export the ZFS's via nfs and rsynced on the other machine some backup > > of my current note-book (geli + UFS, (almost) same 9-stable version, no > > problem) to the ZFS's. > > > > > > Quite fast, I see on the notebook : > > > > > > [root@cc /usr/temp]# zpool status -v > > pool: zfiles > > state: ONLINE > > status: One or more devices has experienced an error resulting in data > > corruption. Applications may be affected. > > action: Restore the file in question if possible. Otherwise restore the > > entire pool from backup. > > see: http://www.sun.com/msg/ZFS-8000-8A > > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 > > 2012 > > config: > > > > NAME STATE READ WRITE CKSUM > > zfiles ONLINE 0 0 11 > > ada0s3.eli ONLINE 0 0 23 > > > > errors: Permanent errors have been detected in the following files: > > > > /zfiles/home/arno/.scito/contrib/XNAT.tar > > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar > > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error > > [root@cc /usr/temp]# > > > > > > As said, memtest is OK, nothing is logged to the console, UFS on the > > same disk works OK (I did some tests copying and comparing random data) > > and smartctl as well seems to trust the disk : > > > > SMART Self-test log structure revision number 1 > > Num Test_Description Status Remaining LifeTime(hours) > > # 1 Extended offline Completed without error 00% 388 > > # 2 Short offline Completed without error 00% 387 > > > > > > Am I doing something wrong and/or let me know what I could provide as > > extra info to try to solve this (dmesg.boot at the end of this mail). > > > > Thanx a lot in advance, > > > > best, Arno > > > > > > > > ################### demsg.boot ####### > > > > Table 'FACP' at 0xbdd90200 > > Table 'APIC' at 0xbdd90390 > > APIC: Found table at 0xbdd90390 > > APIC: Using the MADT enumerator. > > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > > SMP: Added CPU 0 (AP) > > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > > SMP: Added CPU 1 (AP) > > MADT: Found CPU APIC ID 130 ACPI ID 3: disabled > > MADT: Found CPU APIC ID 131 ACPI ID 4: disabled > > Copyright (c) 1992-2012 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 9.0-STABLE #0: Fri Feb 3 22:48:57 CET 2012 > > toor@cc:/usr/obj/raid1/bsd/9/src/sys/VR603 amd64 > > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80bba000. > > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80bba200. > > Calibrating TSC clock ... TSC clock: 2161296371 Hz > > CPU: Intel(R) Pentium(R) Dual CPU T3400 @ 2.16GHz (2161.30-MHz K8-class CPU) > > Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 > > Features=0xbfebfbff > > Features2=0xe39d > > AMD Features=0x20100800 > > AMD Features2=0x1 > > TSC: P-state invariant, performance statistics > > real memory = 3221225472 (3072 MB) > > Physical memory chunk(s): > > 0x0000000000001000 - 0x0000000000095fff, 610304 bytes (149 pages) > > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > > 0x0000000000be9000 - 0x00000000b8402fff, 3078725632 bytes (751642 pages) > > avail memory = 3057152000 (2915 MB) > > Event timer "LAPIC" quality 400 > > ACPI APIC Table: > > INTR: Adding local APIC 1 as a target > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 > > x86bios: SSEG 0x001000-0x001fff at 0xffffff8000210000 > > x86bios: EBDA 0x099000-0x09ffff at 0xfffffe0000099000 > > x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > > APIC: CPU 0 has ACPI ID 1 > > APIC: CPU 1 has ACPI ID 2 > > ULE: setup cpu 0 > > ULE: setup cpu 1 > > ACPI: RSDP 0xf9420 00014 (v00 ACPIAM) > > ACPI: RSDT 0xbdd90000 00048 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: FACP 0xbdd90200 00084 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: DSDT 0xbdd905c0 072D3 (v01 1ADTS 1ADTS012 00000012 INTL 20051117) > > ACPI: FACS 0xbdd9e000 00040 > > ACPI: APIC 0xbdd90390 0006C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: MCFG 0xbdd90400 0003C (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: SLIC 0xbdd90440 00176 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: OEMB 0xbdd9e040 00072 (v01 MSI_NB MEGABOOK 20091013 MSFT 00000097) > > ACPI: HPET 0xbdd9a5c0 00038 (v01 MSI_NB OEMHPET 20091013 MSFT 00000097) > > ACPI: ASF! 0xbdd9a600 00099 (v32 LEGEND I865PASF 00000001 INTL 20051117) > > ACPI: GSCI 0xbdd9e0c0 02024 (v01 MSI_NB GMCHSCI 20091013 MSFT 00000097) > > ACPI: SSDT 0xbdda0a50 004F0 (v01 PmRef CpuPm 00003000 INTL 20051117) > > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > > ioapic0: Routing external 8259A's -> intpin 0 > > MADT: Interrupt override: source 0, irq 2 > > ioapic0: Routing IRQ 0 -> intpin 2 > > MADT: Interrupt override: source 9, irq 9 > > ioapic0: intpin 9 trigger: level > > ioapic0 irqs 0-23 on motherboard > > cpu0 BSP: > > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > > wlan: <802.11 Link Layer> > > random: > > kbd: new array size 4 > > kbd1 at kbdmux0 > > mem: > > nfslock: pseudo-device > > io: > > null: > > acpi0: on motherboard > > PCIe: Memory Mapped configuration base @ 0xe0000000 > > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > > ACPI: Executed 1 blocks of module-level executable AML code > > acpi0: Power Button (fixed) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > acpi0: reservation of fee00000, 1000 (3) failed > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, bdd00000 (3) failed > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI Error: No handler for Region [EC__] (0xfffffe000178c700) [EmbeddedControl] (20110527/evregion-421) > > ACPI Error: Region EmbeddedControl (ID=3) has no handler (20110527/exfldio-310) > > ACPI Error: Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/psparse-560) > > ACPI Error: Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xfffffe0001792980), AE_NOT_EXIST (20110527/uteval-113) > > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > > cpu0: on acpi0 > > ACPI: SSDT 0xbdda04b0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00594 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > cpu1: on acpi0 > > ACPI: SSDT 0xbdda0420 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00085 (v01 PmRef Cpu1Cst 00003000 INTL 20051117) > > acpi_ec0: port 0x62,0x66 on acpi0 > > pci_link0: Index IRQ Rtd Ref IRQs > > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link1: Index IRQ Rtd Ref IRQs > > Initial Probe 0 5 N 0 5 > > Validation 0 5 N 0 5 > > After Disable 0 255 N 0 5 > > pci_link2: Index IRQ Rtd Ref IRQs > > Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link3: Index IRQ Rtd Ref IRQs > > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link4: Index IRQ Rtd Ref IRQs > > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link5: Index IRQ Rtd Ref IRQs > > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link6: Index IRQ Rtd Ref IRQs > > Initial Probe 0 3 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 3 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pci_link7: Index IRQ Rtd Ref IRQs > > Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 > > Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 > > pcib0: port 0xcf8-0xcff on acpi0 > > pcib0: decoding 4 range 0-0xcf7 > > pcib0: decoding 4 range 0xd00-0xffff > > pcib0: decoding 3 range 0xa0000-0xbffff > > pcib0: decoding 3 range 0xd0000-0xdffff > > pcib0: decoding 3 range 0xbde00000-0xdfffffff > > pcib0: decoding 3 range 0xf0000000-0xfed8ffff > > pci0: on pcib0 > > pci0: domain=0, physical bus=0 > > found-> vendor=0x8086, dev=0x2a40, revid=0x07 > > domain=0, bus=0, slot=0, func=0 > > class=06-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2a42, revid=0x07 > > domain=0, bus=0, slot=2, func=0 > > class=03-00-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 1 message > > map[10]: type Memory, range 64, base 0xfd800000, size 22, enabled > > pcib0: allocated type 3 (0xfd800000-0xfdbfffff) for rid 10 of pci0:0:2:0 > > map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled > > pcib0: allocated type 3 (0xd0000000-0xdfffffff) for rid 18 of pci0:0:2:0 > > map[20]: type I/O Port, range 32, base 0xb400, size 3, enabled > > pcib0: allocated type 4 (0xb400-0xb407) for rid 20 of pci0:0:2:0 > > pcib0: matched entry for 0.2.INTA > > pcib0: slot 2 INTA hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2a43, revid=0x07 > > domain=0, bus=0, slot=2, func=1 > > class=03-80-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > powerspec 3 supports D0 D3 current D0 > > map[10]: type Memory, range 64, base 0xfdd00000, size 20, enabled > > pcib0: allocated type 3 (0xfdd00000-0xfddfffff) for rid 10 of pci0:0:2:1 > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled > > pcib0: allocated type 4 (0xb800-0xb81f) for rid 20 of pci0:0:26:0 > > pcib0: matched entry for 0.26.INTA > > pcib0: slot 26 INTA hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=7 > > map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled > > pcib0: allocated type 4 (0xb480-0xb49f) for rid 20 of pci0:0:26:1 > > pcib0: matched entry for 0.26.INTB > > pcib0: slot 26 INTB hardwired to IRQ 21 > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > powerspec 2 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xfdefec00, size 10, enabled > > pcib0: allocated type 3 (0xfdefec00-0xfdefefff) for rid 10 of pci0:0:26:7 > > pcib0: matched entry for 0.26.INTC > > pcib0: slot 26 INTC hardwired to IRQ 18 > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=3 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > map[10]: type Memory, range 64, base 0xfdef8000, size 14, enabled > > pcib0: allocated type 3 (0xfdef8000-0xfdefbfff) for rid 10 of pci0:0:27:0 > > pcib0: matched entry for 0.27.INTA > > pcib0: slot 27 INTA hardwired to IRQ 22 > > found-> vendor=0x8086, dev=0x2940, revid=0x03 > > domain=0, bus=0, slot=28, func=0 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=5 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTA > > pcib0: slot 28 INTA hardwired to IRQ 17 > > found-> vendor=0x8086, dev=0x2942, revid=0x03 > > domain=0, bus=0, slot=28, func=1 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=10 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTB > > pcib0: slot 28 INTB hardwired to IRQ 16 > > found-> vendor=0x8086, dev=0x2946, revid=0x03 > > domain=0, bus=0, slot=28, func=3 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > intpin=d, irq=11 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > pcib0: matched entry for 0.28.INTD > > pcib0: slot 28 INTD hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=14 > > map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled > > pcib0: allocated type 4 (0xc000-0xc01f) for rid 20 of pci0:0:29:0 > > pcib0: matched entry for 0.29.INTA > > pcib0: slot 29 INTA hardwired to IRQ 23 > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=11 > > map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled > > pcib0: allocated type 4 (0xbc00-0xbc1f) for rid 20 of pci0:0:29:1 > > pcib0: matched entry for 0.29.INTB > > pcib0: slot 29 INTB hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled > > pcib0: allocated type 4 (0xb880-0xb89f) for rid 20 of pci0:0:29:2 > > pcib0: matched entry for 0.29.INTC > > pcib0: slot 29 INTC hardwired to IRQ 18 > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=14 > > powerspec 2 supports D0 D3 current D0 > > map[10]: type Memory, range 32, base 0xfdeff000, size 10, enabled > > pcib0: allocated type 3 (0xfdeff000-0xfdeff3ff) for rid 10 of pci0:0:29:7 > > pcib0: matched entry for 0.29.INTA > > pcib0: slot 29 INTA hardwired to IRQ 23 > > found-> vendor=0x8086, dev=0x2448, revid=0x93 > > domain=0, bus=0, slot=30, func=0 > > class=06-04-01, hdrtype=0x01, mfdev=0 > > cmdreg=0x0104, statreg=0x0010, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2919, revid=0x03 > > domain=0, bus=0, slot=31, func=0 > > class=06-01-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > found-> vendor=0x8086, dev=0x2929, revid=0x03 > > domain=0, bus=0, slot=31, func=2 > > class=01-06-01, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=11 > > powerspec 3 supports D0 D3 current D0 > > MSI supports 16 messages > > map[10]: type I/O Port, range 32, base 0xcc00, size 3, enabled > > pcib0: allocated type 4 (0xcc00-0xcc07) for rid 10 of pci0:0:31:2 > > map[14]: type I/O Port, range 32, base 0xc880, size 2, enabled > > pcib0: allocated type 4 (0xc880-0xc883) for rid 14 of pci0:0:31:2 > > map[18]: type I/O Port, range 32, base 0xc800, size 3, enabled > > pcib0: allocated type 4 (0xc800-0xc807) for rid 18 of pci0:0:31:2 > > map[1c]: type I/O Port, range 32, base 0xc480, size 2, enabled > > pcib0: allocated type 4 (0xc480-0xc483) for rid 1c of pci0:0:31:2 > > map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled > > pcib0: allocated type 4 (0xc400-0xc41f) for rid 20 of pci0:0:31:2 > > map[24]: type Memory, range 32, base 0xfdeff800, size 11, enabled > > pcib0: allocated type 3 (0xfdeff800-0xfdefffff) for rid 24 of pci0:0:31:2 > > pcib0: matched entry for 0.31.INTB > > pcib0: slot 31 INTB hardwired to IRQ 19 > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=15 > > map[10]: type Memory, range 64, base 0xfdeff400, size 8, enabled > > pcib0: allocated type 3 (0xfdeff400-0xfdeff4ff) for rid 10 of pci0:0:31:3 > > map[20]: type I/O Port, range 32, base 0x400, size 5, enabled > > pcib0: allocated type 4 (0x400-0x41f) for rid 20 of pci0:0:31:3 > > pcib0: matched entry for 0.31.INTC > > pcib0: slot 31 INTC hardwired to IRQ 18 > > vgapci0: port 0xb400-0xb407 mem 0xfd800000-0xfdbfffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > > agp0: on vgapci0 > > agp0: aperture size is 256M, detected 32764k stolen memory > > vgapci1: mem 0xfdd00000-0xfddfffff at device 2.1 on pci0 > > pci0: at device 26.0 (no driver attached) > > pci0: at device 26.1 (no driver attached) > > pci0: at device 26.7 (no driver attached) > > pci0: at device 27.0 (no driver attached) > > pcib1: irq 17 at device 28.0 on pci0 > > pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib1 > > pcib0: allocated type 3 (0xfdf00000-0xfdffffff) for rid 20 of pcib1 > > pcib0: allocated type 3 (0xf9f00000-0xf9ffffff) for rid 24 of pcib1 > > pcib1: domain 0 > > pcib1: secondary bus 2 > > pcib1: subordinate bus 2 > > pcib1: I/O decode 0xd000-0xdfff > > pcib1: memory decode 0xfdf00000-0xfdffffff > > pcib1: prefetched decode 0xf9f00000-0xf9ffffff > > pci2: on pcib1 > > pci2: domain=0, physical bus=2 > > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > > domain=0, bus=2, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=10 > > powerspec 3 supports D0 D1 D2 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 2 messages in map 0x20 > > map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled > > pcib1: allocated I/O port range (0xd800-0xd8ff) for rid 10 of pci0:2:0:0 > > map[18]: type Memory, range 64, base 0xfdfff000, size 12, enabled > > pcib1: allocated memory range (0xfdfff000-0xfdffffff) for rid 18 of pci0:2:0:0 > > map[20]: type Prefetchable Memory, range 64, base 0xf9ff0000, size 16, enabled > > pcib1: allocated prefetch range (0xf9ff0000-0xf9ffffff) for rid 20 of pci0:2:0:0 > > pcib1: matched entry for 2.0.INTA > > pcib1: slot 0 INTA hardwired to IRQ 16 > > pci2: at device 0.0 (no driver attached) > > pcib2: irq 16 at device 28.1 on pci0 > > pcib0: allocated type 4 (0xe000-0xefff) for rid 1c of pcib2 > > pcib0: allocated type 3 (0xfe000000-0xfeafffff) for rid 20 of pcib2 > > pcib0: allocated type 3 (0xfa000000-0xfcffffff) for rid 24 of pcib2 > > pcib2: domain 0 > > pcib2: secondary bus 3 > > pcib2: subordinate bus 4 > > pcib2: I/O decode 0xe000-0xefff > > pcib2: memory decode 0xfe000000-0xfeafffff > > pcib2: prefetched decode 0xfa000000-0xfcffffff > > pci3: on pcib2 > > pci3: domain=0, physical bus=3 > > pcib3: irq 19 at device 28.3 on pci0 > > pcib0: allocated type 3 (0xfeb00000-0xfebfffff) for rid 20 of pcib3 > > pcib3: domain 0 > > pcib3: secondary bus 5 > > pcib3: subordinate bus 5 > > pcib3: memory decode 0xfeb00000-0xfebfffff > > pcib3: no prefetched decode > > pci5: on pcib3 > > pci5: domain=0, physical bus=5 > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=11 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > map[10]: type Memory, range 64, base 0xfebf0000, size 16, enabled > > pcib3: allocated memory range (0xfebf0000-0xfebfffff) for rid 10 of pci0:5:0:0 > > pcib3: matched entry for 5.0.INTA > > pcib3: slot 0 INTA hardwired to IRQ 19 > > pci5: at device 0.0 (no driver attached) > > pci0: at device 29.0 (no driver attached) > > pci0: at device 29.1 (no driver attached) > > pci0: at device 29.2 (no driver attached) > > pci0: at device 29.7 (no driver attached) > > pcib4: at device 30.0 on pci0 > > pcib4: domain 0 > > pcib4: secondary bus 1 > > pcib4: subordinate bus 1 > > pcib4: no prefetched decode > > pcib4: Subtractively decoded bridge. > > pcib4: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND > > pci1: on pcib4 > > pci1: domain=0, physical bus=1 > > isab0: at device 31.0 on pci0 > > isa0: on isab0 > > ahci0: port 0xcc00-0xcc07,0xc880-0xc883,0xc800-0xc807,0xc480-0xc483,0xc400-0xc41f mem 0xfdeff800-0xfdefffff irq 19 at device 31.2 on pci0 > > ahci0: attempting to allocate 1 MSI vectors (16 supported) > > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > > ahci0: using IRQ 256 for MSI > > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported > > ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 4ports > > ahci0: Caps2: > > ahci0: EM Caps: ALHD XMT SMB LED > > ahcich0: at channel 0 on ahci0 > > ahcich0: Caps: > > ahcich1: at channel 1 on ahci0 > > ahcich1: Caps: > > ahcich2: not probed (disabled) > > ahcich3: not probed (disabled) > > ahcich4: at channel 4 on ahci0 > > ahcich4: Caps: > > ahcich5: at channel 5 on ahci0 > > ahcich5: Caps: > > pci0: at device 31.3 (no driver attached) > > acpi_button0: on acpi0 > > acpi_tz0: on acpi0 > > attimer0: port 0x40-0x43 irq 0 on acpi0 > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 50 > > Event timer "i8254" frequency 1193182 Hz quality 100 > > atrtc0: port 0x70-0x71 irq 8 on acpi0 > > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) > > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 51 > > Event timer "RTC" frequency 32768 Hz quality 0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > atkbd: the current kbd controller command byte 0065 > > atkbd: keyboard ID 0x41ab (2) > > kbd0 at atkbd0 > > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 52 > > atkbd0: [GIANT-LOCKED] > > psm0: unable to allocate IRQ > > psmcpnp0: irq 12 on acpi0 > > psm0: current command byte:0065 > > psm0: irq 12 on atkbdc0 > > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 53 > > psm0: [GIANT-LOCKED] > > psm0: model IntelliMouse, device ID 3-00, 3 buttons > > psm0: config:00000000, flags:00000008, packet size:4 > > psm0: syncmask:08, syncbits:00 > > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route > > hpet0: t0: irqs 0x00f00000 (0), 64bit, periodic > > hpet0: t1: irqs 0x00f00000 (0) > > hpet0: t2: irqs 0x00f00800 (0) > > hpet0: t3: irqs 0x00f01000 (0) > > Timecounter "HPET" frequency 14318180 Hz quality 950 > > ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 54 > > Event timer "HPET" frequency 14318180 Hz quality 450 > > Event timer "HPET1" frequency 14318180 Hz quality 440 > > Event timer "HPET2" frequency 14318180 Hz quality 440 > > Event timer "HPET3" frequency 14318180 Hz quality 440 > > acpi_acad0: on acpi0 > > battery0: on acpi0 > > acpi_lid0: on acpi0 > > acpi_button1: on acpi0 > > acpi0: wakeup code va 0xffffff80d4544000 pa 0x4000 > > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > > pcib0: allocated type 3 (0xd0000-0xd07ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd0800-0xd0fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd1000-0xd17ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd1800-0xd1fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd2000-0xd27ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd2800-0xd2fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd3000-0xd37ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd3800-0xd3fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xda000-0xda7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xda800-0xdafff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdc000-0xdc7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdc800-0xdcfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdd000-0xdd7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdd800-0xddfff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xde000-0xde7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xde800-0xdefff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdf000-0xdf7ff) for rid 1 of orm0 > > pcib0: allocated type 3 (0xdf800-0xdffff) for rid 1 of orm0 > > isa_probe_children: disabling PnP devices > > atkbdc: atkbdc0 already exists; skipping it > > atrtc: atrtc0 already exists; skipping it > > attimer: attimer0 already exists; skipping it > > sc: sc0 already exists; skipping it > > isa_probe_children: probing non-PnP devices > > orm0: at iomem 0xc0000-0xcf7ff on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA <16 virtual consoles, flags=0x300> > > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > > ppc0 failed to probe at irq 7 on isa0 > > pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 > > uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 > > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > > isa_probe_children: probing PnP devices > > Device configuration finished. > > procfs registered > > Timecounters tick every 1.000 msec > > vlan: initialized, using hash tables with chaining > > lo0: bpf attached > > ahcich0: AHCI reset... > > ahcich0: SATA connect time=100us status=00000123 > > ahcich0: AHCI reset: device found > > ahcich1: AHCI reset... > > ahcich1: SATA offline status=00000004 > > ahcich1: AHCI reset: device not found > > ahcich4: AHCI reset... > > ahcich4: SATA offline status=00000004 > > ahcich4: AHCI reset: device not found > > ahcich5: AHCI reset... > > ahcich5: SATA connect time=900us status=00000113 > > ahcich5: AHCI reset: device found > > ahcich5: AHCI reset: device ready after 0ms > > (aprobe1:ahcich5:0:0:0): SIGNATURE: eb14 > > acpi_acad0: acline initialization start > > battery0: battery initialization start > > acpi_acad0: On Line > > acpi_acad0: acline initialization done, tried 1 times > > ahcich5: SNTF 0x0001 > > ahcich0: AHCI reset: device ready after 100ms > > (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 > > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > pass0: ATA-8 SATA 2.x device > > GEOM: new disk cd0 > > pass0: Serial Number 5YX0J5YD > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > cd0 at ahcich5 bus 0 scbus3 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: Serial Number 30651780 1165921Q111 > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray open > > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > pass0: Command Queueing enabled > > pass1 at ahcich5 bus 0 scbus3 target 0 lun 0 > > pass1: Removable CD-ROM SCSI-0 device > > pass1: Serial Number 30651780 1165921Q111 > > pass1: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > ada0: ATA-8 SATA 2.x device > > ada0: Serial Number 5YX0J5YD > > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > ada0: Command Queueing enabled > > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad4 > > SMP: AP CPU #1 Launched! > > cpu1 AP: > > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > > TSC timecounter disabled: C3 enabled. > > Timecounter "TSC" frequency 2161296371 Hz quality -1000 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:battery0: battery initialization done, tried 1 times > > 0:0): Error 6, Unretryable error > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > GEOM: new disk ada0 > > GEOM: ada0s3: media size does not match label. > > Trying to mount root from ufs:/dev/ada0s2a [rw,noatime]... > > start_init: trying /sbin/init > > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; > > to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > > ZFS filesystem version 5 > > ZFS storage pool version 28 > > (cd0:ahcich5:0:0:0): SCSI status error > > (cd0:ahcich5:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (cd0:ahcich5:0:0:0): CAM status: SCSI Status Error > > (cd0:ahcich5:0:0:0): SCSI status: Check Condition > > (cd0:ahcich5:0:0:0): SCSI sense: NOT READY asc:3a,2 (Medium not present - tray open) > > (cd0:ahcich5:0:0:0): Error 6, Unretryable error > > tap0: bpf attached > > tap0: Ethernet address: 00:bd:0b:07:00:00 > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > > domain=0, bus=2, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > powerspec 3 supports D0 D1 D2 D3 current D0 > > MSI supports 1 message, 64 bit > > MSI-X supports 2 messages in map 0x20 > > pci0:2:0:0: reprobing on driver added > > re0: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xf9ff0000-0xf9ffffff irq 16 at device 0.0 on pci2 > > re0: MSI count : 1 > > re0: MSI-X count : 2 > > re0: attempting to allocate 1 MSI-X vectors (2 supported) > > msi: routing MSI-X IRQ 257 to local APIC 0 vector 55 > > re0: using IRQ 257 for MSI-X > > re0: Using 1 MSI-X message > > re0: ASPM disabled > > re0: Chip rev. 0x3c000000 > > re0: MAC rev. 0x00400000 > > miibus0: on re0 > > rgephy0: PHY 1 on miibus0 > > rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > > re0: bpf attached > > re0: Ethernet address: 00:24:21:61:e0:20 > > pci3: driver added > > pci5: driver added > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=19 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > pci0:5:0:0: reprobing on driver added > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci3: driver added > > pci5: driver added > > found-> vendor=0x168c, dev=0x001c, revid=0x01 > > domain=0, bus=5, slot=0, func=0 > > class=02-00-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=19 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message > > MSI-X supports 1 message in map 0x10 > > pci0:5:0:0: reprobing on driver added > > ath0: mem 0xfebf0000-0xfebfffff irq 19 at device 0.0 on pci5 > > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 56 > > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > ath0: Use hw queue 1 for WME_AC_BE traffic > > ath0: Use hw queue 0 for WME_AC_BK traffic > > ath0: Use hw queue 2 for WME_AC_VI traffic > > ath0: Use hw queue 3 for WME_AC_VO traffic > > ath0: Use hw queue 8 for CAB traffic > > ath0: Use hw queue 9 for beacons > > ath0: using multicast key search > > crypto: > > cryptosoft0: on motherboard > > crypto: assign cryptosoft0 driver id 0, flags 100663296 > > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 22 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > > crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > > GEOM_ELI: Device ada0s3.eli created. > > GEOM_ELI: Encryption: AES-XTS 128 > > GEOM_ELI: Crypto: software > > pci0: driver added > > found-> vendor=0x8086, dev=0x2937, revid=0x03 > > domain=0, bus=0, slot=26, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=16 > > pci0:0:26:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2938, revid=0x03 > > domain=0, bus=0, slot=26, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=21 > > pci0:0:26:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x293c, revid=0x03 > > domain=0, bus=0, slot=26, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:26:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x293e, revid=0x03 > > domain=0, bus=0, slot=27, func=0 > > class=04-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=22 > > powerspec 2 supports D0 D3 current D0 > > MSI supports 1 message, 64 bit > > pci0:0:27:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2934, revid=0x03 > > domain=0, bus=0, slot=29, func=0 > > class=0c-03-00, hdrtype=0x00, mfdev=1 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > pci0:0:29:0: reprobing on driver added > > found-> vendor=0x8086, dev=0x2935, revid=0x03 > > domain=0, bus=0, slot=29, func=1 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=b, irq=19 > > pci0:0:29:1: reprobing on driver added > > found-> vendor=0x8086, dev=0x2936, revid=0x03 > > domain=0, bus=0, slot=29, func=2 > > class=0c-03-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:29:2: reprobing on driver added > > found-> vendor=0x8086, dev=0x293a, revid=0x03 > > domain=0, bus=0, slot=29, func=7 > > class=0c-03-20, hdrtype=0x00, mfdev=0 > > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=a, irq=23 > > powerspec 2 supports D0 D3 current D0 > > pci0:0:29:7: reprobing on driver added > > found-> vendor=0x8086, dev=0x2930, revid=0x03 > > domain=0, bus=0, slot=31, func=3 > > class=0c-05-00, hdrtype=0x00, mfdev=0 > > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > > intpin=c, irq=18 > > pci0:0:31:3: reprobing on driver added > > pci1: driver added > > pci2: driver added > > pci3: driver added > > pci5: driver added > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > p4tcc0: on cpu0 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > p4tcc1: on cpu1 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > coretemp0: on cpu0 > > coretemp0: Setting TjMax=100 > > est0: on cpu0 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est0 attach returned 6 > > coretemp1: on cpu1 > > coretemp1: Setting TjMax=100 > > est1: on cpu1 > > est: CPU supports Enhanced Speedstep, but is not recognized. > > est: cpu_vendor GenuineIntel, msr 6130d2b06000d2b > > device_attach: est1 attach returned 6 > > > > _______________________________________________ > > 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" > > > > -- > > Arno J. Klaassen > > SCITO S.A. > 8 rue des Haies > F-75020 Paris, France > http://scito.com > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:38:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC85106566B; Tue, 14 Feb 2012 18:38:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 329C68FC15; Tue, 14 Feb 2012 18:38:27 +0000 (UTC) Received: by werm13 with SMTP id m13so240803wer.13 for ; Tue, 14 Feb 2012 10:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YdslPh7L8R9+Tv8mnIW0bpW0IRZGvb+VObZR9PVh7B0=; b=DNO6bkDY0OoF+Jk1vy7NbfJCDHrsNJ9di3YHSJ7QQJBxOpA+CZvvFvi9MbeYIFhzzt ltG1nQe7qBcUzqEyj6ejJNiFM4Pu8viRXC7hQeo2ySeE4xpQY/DbJMIsXN8jXprSKzpK GRfzBWIuGhWhnY8yy6/ewrPtglXl218dTnkes= MIME-Version: 1.0 Received: by 10.216.138.24 with SMTP id z24mr1405271wei.48.1329244707088; Tue, 14 Feb 2012 10:38:27 -0800 (PST) Received: by 10.223.158.143 with HTTP; Tue, 14 Feb 2012 10:38:27 -0800 (PST) In-Reply-To: <4F3A1A19.7010803@freebsd.org> References: <4F3A1A19.7010803@freebsd.org> Date: Tue, 14 Feb 2012 10:38:27 -0800 Message-ID: From: Kevin Oberman To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: freebsd 9-stable TOP problem from around Jan 10 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, 14 Feb 2012 18:38:28 -0000 On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer wrot= e: > Has anyone else seen a =A0problem with top -H -S? > > after a short while the screen gets more and more corrupted.. > > hitting ^L or turning off S & H modes helps .. for a while. > > If this is a known fixed problem, let me know but I need to co-ordinate w= ith > others > to upgrade the machine in question. Not seeing it here on 9-stable. Could it be a display issue? I am using gnome-terminal with TERM defined as 'xterm'. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 18:54:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE4B1065678; Tue, 14 Feb 2012 18:54:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 463378FC1F; Tue, 14 Feb 2012 18:54:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1EIsKiN062109 ; Tue, 14 Feb 2012 19:54:20 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1EIrhgw084894; Tue, 14 Feb 2012 19:53:44 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1EIrhIq084891; Tue, 14 Feb 2012 19:53:43 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Tue, 14 Feb 2012 19:53:43 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3AADDC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3AADDC.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 14 Feb 2012 18:54:26 -0000 Hi, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? I just started it; will take some hours > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? I deleted the XNAT.tar; I also copied files by 'ssh tar -c | tar -xp' to rule out NFS, same type of errors; Looks like multiple scrubs give the same files but not the same number of chksum errors (to be confirmed) > 3) Can you try zfs without geli? sure, I will split the place in one partition with geli and one without > 4) Is the slice/partition layout definitely correct? I (still ???) use sysinstall to do the dirty computations in my place. This is what gpart says (looks OK (to me ...) : [root@cc ~]# gpart list ada0 Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 976773167 first: 63 entries: 4 scheme: MBR Providers: 1. Name: ada0s1 Mediasize: 40802001408 (38G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r0w0e0 rawtype: 7 length: 40802001408 offset: 32256 type: ntfs index: 1 end: 79691471 start: 63 2. Name: ada0s2 Mediasize: 34359607296 (32G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2147328000 Mode: r3w3e5 attrib: active rawtype: 165 length: 34359607296 offset: 40802033664 type: freebsd index: 2 end: 146800079 start: 79691472 3. Name: ada0s3 Mediasize: 424946221056 (395G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 2147196928 Mode: r1w1e1 rawtype: 165 length: 424946221056 offset: 75161640960 type: freebsd index: 3 end: 976773167 start: 146800080 Consumers: 1. Name: ada0 Mediasize: 500107862016 (465G) Sectorsize: 512 Mode: r4w4e10 Merci, Arno > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > >> > [ dmesg.boot deleted ] From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:00:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E83BD106566C for ; Tue, 14 Feb 2012 19:00:38 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6B38FC1A for ; Tue, 14 Feb 2012 19:00:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 4FE55446005; Tue, 14 Feb 2012 14:03:00 -0500 (EST) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBzgxADU9QCh; Tue, 14 Feb 2012 14:02:59 -0500 (EST) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id E82C1446002; Tue, 14 Feb 2012 14:02:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) From: Andrew Boyer In-Reply-To: Date: Tue, 14 Feb 2012 14:00:41 -0500 Message-Id: References: To: FreeBSD Stable Mailing List X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jake Holland Subject: Re: hang during dump (reproducible) 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, 14 Feb 2012 19:00:39 -0000 On Feb 10, 2012, at 9:50 PM, Jake Holland wrote: >=20 > Many thanks to Attilio Rao, Kostik Belousov, and Andriy Gapon. And = anybody else involved. >=20 > However, when I looked at the commit I noticed this: >> $ svn log -r228424 svn://svn.freebsd.org/base > ... >> MFC after: 3 months (or never) >=20 > I'm not sure whether "never" is still considered an option, but it = would be useful for me if 8.3 release, when it comes, does not hang this = way during panic. But thanks for the patch, regardless. >=20 Agreed - if this commit could be MFC'd for 8.3 it would be much = appreciated. -Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:24:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5D0106566C for ; Tue, 14 Feb 2012 19:24:35 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 44D498FC16 for ; Tue, 14 Feb 2012 19:24:34 +0000 (UTC) Received: from titan.wdn.omnilan.net (titan.lo4.wdn.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q1EJOWXv010111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 20:24:33 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.wdn.omnilan.net [172.21.1.150] claimed to be titan.wdn.omnilan.net Message-ID: <4F3AB4F0.9010002@omnilan.de> Date: Tue, 14 Feb 2012 20:24:32 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Martin Sugioarto References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> In-Reply-To: <20120214192319.44ff7aff@zelda.sugioarto.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB6FD41B87E3F0B2C422F57D" Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 19:24:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB6FD41B87E3F0B2C422F57D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Martin Sugioarto am 14.02.2012 19:23 (localtime): > Am Tue, 14 Feb 2012 18:17:19 +0100 > schrieb Harald Schmalzbauer : > >>> I find it interesting that, at least so far, the only people >>> reporting problems of this type with the ahci.ko driver are people >>> using Samsung disks. The only difference is that your models are >>> F1s while the OPs are F2s. >> I saw such timeouts long ago and mav@ had a look at my postings and he= >> mentioned it could be a NCQ problem. >> I suspected the disks firmware. >> I never tracked it down further, because after replacing the Samsung >> (F3 in that case) disks with hitachi ones solved all my problems and >> gave a big performance kick as well (with zfs). >> You can find the discussion here: >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374= =2Ehtml > Hi, > > I just want to add here that I am using 2 drives of type "Samsung > HD103SJ" (SpinPoint F3). And I did not have problems with ZFS and with > UFS either (for several years now). Everything has been deployed ontop > ada(4) since FreeBSD-8. > > Actually the speed is very good (sequential read at 140 MB/s and more).= I guess it's always the firmware of the EcoGreen models which cause these problems. Your drive isn't EG... I don't remember exactly the different model numbers, but I'm sure they were all EcoGreen. The lower power consumption was the reason to choose these specific drives (different capacities and F2/F3 series tried), with acceptable performance loss - I thought. But it turned out that EcoGreen and NCQ as well as RAIDZ demands dont' fit together... -Harry --------------enigFB6FD41B87E3F0B2C422F57D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86tPAACgkQLDqVQ9VXb8iYGwCcCTDHkqyjWW4g8/U0H9xFHFfY Mi8AnibROD/RwWoJWEiWaXBPcJpFCZxF =Ahf8 -----END PGP SIGNATURE----- --------------enigFB6FD41B87E3F0B2C422F57D-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:51:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75BA10657B0 for ; Tue, 14 Feb 2012 19:51:11 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 36F908FC19 for ; Tue, 14 Feb 2012 19:51:10 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so289905wgb.31 for ; Tue, 14 Feb 2012 11:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ny3MLLIdalr6miGqMdzishiqQ6lNVl+Jc5Jbt7mEYD0=; b=Db7EA3X4Qq+tDj2roiaGlZ0qXLQdA90OMZQY48WZAlr+Z7cEt0BNy3/UbyIW2NTdDA 35ShIIZ+358BIweflpQSHUwxITvvASOLkT29QNM+yRopvoJvvynRZtQERBVue9DDou0f i4/92YsOFZe1aK+GYW1BwXQmogYOrZe8lJePM= MIME-Version: 1.0 Received: by 10.180.92.229 with SMTP id cp5mr31145808wib.8.1329249069872; Tue, 14 Feb 2012 11:51:09 -0800 (PST) Received: by 10.223.158.143 with HTTP; Tue, 14 Feb 2012 11:51:09 -0800 (PST) In-Reply-To: <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> Date: Tue, 14 Feb 2012 11:51:09 -0800 Message-ID: From: Kevin Oberman To: Devin Teske Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Bruce Cran , FreeBSD Stable Mailing List , Joe Holden , Alex Samorukov , Ian Smith Subject: Re: New BSD Installer 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, 14 Feb 2012 19:51:11 -0000 On Tue, Feb 14, 2012 at 9:43 AM, Devin Teske wr= ote: > > >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- >> stable@freebsd.org] On Behalf Of Ian Smith >> Sent: Tuesday, February 14, 2012 9:15 AM >> To: Bruce Cran >> Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov >> Subject: Re: New BSD Installer >> >> Strangely, the big push to GPT partitions was oft said to be because MBR >> slices provided too few partitions. > > That's part of it (no pun intended). > > The other big deal is that you can't exceed 2TB on a single primary parti= tion. > > >> I never found 4 * 6 much of a limit >> myself, and now the default install makes a Linux-like single partition, >> rendering dump & restore more or less unusable or at least impractical, > > I'm with you on this one. I really don't like the single-"/" setup. > > >> while booting multiple systems on GPT also seems to require Linux tools. >> >> I don't know whether this move away from BSD traditional filesystem >> partitioning (/, /var, /usr etc) to Linux-style came down from Core On >> High or is just the prerogative of installer-writers? =A0Jordan was both >> the latter and a big part of the former for many years, but I guess >> that's something that can be reverted if people feel to do so. >> > > Maybe a vote should be taken. There's about 12 votes in this office here = alone > for putting the partition scheme back the way it was (Colin Percival had = a great > formula for determining partition sizes). I suggest that both be implemented, which looks to the untrained eye as a straight-forward thing to implement, and then the install ask if a single partition or a traditional multi-partition system should be installed. I prefer multi and use that on all of my systems. I also really prefer GPT for a variety of reasons, but we need better tools to support things. I miss booteasy. Yes, you can get it to boot from a different partition, but it is a pain. I deal with it by putting FreeBSD on one disk and Windows on another when I want a dual-boot system. I put the MBR formatted (Windows) is first in the boot order, so I can just hit F5 to boot the FreeBSD disk. This works for me, but I suspect that lots of people would prefer having multiple OSes on a single disk...especially when it's a single spindle laptop. (I suspect laptops are more commonly dual-boot than most any other platform.) As for fdisk and bsdlabel, I'm happy to see both go. They have a horrid user interface and require a calculator to get right. Yes, I use them, but only because there is no other way to do some things. (sade(8) comes closer all of the time, though.) --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:51:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 628E71065673 for ; Tue, 14 Feb 2012 19:51:48 +0000 (UTC) (envelope-from martin@sugioarto.com) Received: from mailserv.regfish.com (mailserv.regfish.com [79.140.61.33]) by mx1.freebsd.org (Postfix) with ESMTP id B2A3B8FC27 for ; Tue, 14 Feb 2012 19:51:46 +0000 (UTC) Received: (qmail 17766 invoked from network); 14 Feb 2012 19:50:45 -0000 Received: from pd9ec0d44.dip0.t-ipconnect.de (HELO yuni.sugioarto.com) (46959-0001@[217.236.13.68]) (envelope-sender ) by mailserv.regfish.com (qmail-ldap-1.03) with SMTP for ; 14 Feb 2012 19:50:45 -0000 Received: from zelda.sugioarto.com (zelda.sugioarto.com [192.168.0.12]) by yuni.sugioarto.com (Postfix) with ESMTP id 64DED1BAC55; Tue, 14 Feb 2012 20:51:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sugioarto.com; s=mail; t=1329249104; bh=bqDrVQOnDx4PGLGIxaV/iggr+kLoiFFS5hybJZ4FlKk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=a1ZEifaXQW5FgMmyvkKZ0D/1ehuSzVZANGg3t7A3as1mDkQpDNumCaveX3x0c8Sj1 7PI9VkGlLm341X0lSHqN8rYv6E8ywqodNF71MS+w6b9GagiRE2xg7gPe/HtWr6HOT2 mSC7B74k/Pepx9wwXWebvm7D3XngzIksnboduJuI= Date: Tue, 14 Feb 2012 20:51:43 +0100 From: Martin Sugioarto To: Harald Schmalzbauer Message-ID: <20120214205143.2a6b9c87@zelda.sugioarto.com> In-Reply-To: <4F3AB4F0.9010002@omnilan.de> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <4F3AB4F0.9010002@omnilan.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 19:51:48 -0000 Am Tue, 14 Feb 2012 20:24:32 +0100 schrieb Harald Schmalzbauer : > I guess it's always the firmware of the EcoGreen models which cause > these problems. Your drive isn't EG... > I don't remember exactly the different model numbers, but I'm sure > they were all EcoGreen. The lower power consumption was the reason to > choose these specific drives (different capacities and F2/F3 series > tried), with acceptable performance loss - I thought. But it turned > out that EcoGreen and NCQ as well as RAIDZ demands dont' fit > together... Hi, I intentionally did not buy any Eco or Green model because I don't like them (Load_Cycle_Count bugs and so on). I realized, I like to use 1 Watt more power but have the performance doubled. -- Martin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:52:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 986D21065673 for ; Tue, 14 Feb 2012 19:52:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 77C448FC08 for ; Tue, 14 Feb 2012 19:52:57 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id ZuwF1i0071vN32cACvsx51; Tue, 14 Feb 2012 19:52:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id Zvsv1i00S1t3BNj8ivsvST; Tue, 14 Feb 2012 19:52:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DDCA102C1E; Tue, 14 Feb 2012 11:52:55 -0800 (PST) Date: Tue, 14 Feb 2012 11:52:55 -0800 From: Jeremy Chadwick To: Oscar Prieto Message-ID: <20120214195255.GA5064@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Martin Sugioarto , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 19:52:57 -0000 On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote: > I used to had tons of ahci errors in my 4 disk raidz1 worth of > HD154UIs when the rig was built a year ago or so (with 8.0 Release), > but they dissapeared after tuning ZFS. > > Sadly i also got a new timeout days ago followed with smartcl erros i > still keep unchecked but i guess they cold be legit, i still have to > test/swap cables and give it a try. About your ada3 disk: The below SMART errors indicate your disk does in fact have physical media problems -- 1 confirmed bad sector, and 5 which are "suspect". "Suspect" LBAs are unreadable until writes are issued to them. A write will induce the drive to re-analyse the sector at that LBA and determine if it's truly bad or not. A single LBA can actually take quite a long time to analyse (it depends on what the problem is), and may result in 30+ seconds of delay. You can either let the drive figure it out over normal usage patterns, or you can do it manually yourself time permitting. Your drive that shows read failures in the SMART self-test log gives you the LBA numbers; try reading from those LBAs first. I can explain this procedure in another thread/offline/whatever. (Does anyone read what I write, re: don't hijack the thread? :-) ) About all of your disks: All of your disks are undergoing regular/periodic SMART short and long tests. Please stop this; it really, truly does no good. You will experience performance hits during these tests. About timeouts: Timeouts seen on the controller and driver level can happen in this situation; this is universal. This is usually what features like Western Digital's TLER and Hitachi + Samsung's CCTL can help alleviate, but not fully solve. I think the ada(4) default timeout of 30 seconds is a decent value, to be quite honest, but I'm not sure what the AHCI driver timeout is. mav@ would need to clue me in, or I'd need to go look at the source. (Right now in my life is not a good time for me to be reviewing source code or looking at commits, sadly. Too much on my mind recently.) I can discuss the TLER/CCTL stuff more at length if needed, but to be blatantly honest, I would rather not and here's why: people begin to rely on these features to try and circumvent actual problems with their drives. Phrased differently: people on the Internet become incredibly focused on all of these timeout durations (TLER/CCTL vs. controller vs. driver vs. storage subsystem timeouts) and try to find some bizarre "perfect harmony" between them all. Instead, just leave them all alone and watch your drives for problems. Further details which pertain to Samsung drives: In your case, you run smartd(8), which periodically hits the drive with SMART requests, pulling attribute data down and parsing it. I believe your model is fine for this, but for similar Samsung models, I must strongly advise against this. There are well-documented problems with Samsung firmwares and SMART behaviour which can result in data loss (yes you read that right). Please see smartmontools' Wiki page on the matter for full details. Just make sure you're running a fixed firmware: http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks Regarding throughput of the drives being slow (30-40MBytes/sec across a gigE link): This sounds more like a Samba tuning problem, but ZFS raidz isn't known for "amazing speed" per se. Please see a post of mine from a while back on how to tune Samba, which many followed up to with appreciation stating their throughput increased dramatically: http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061642.html I should follow up to that post with the following entry, because I've since updated my own smb.conf to tune things a bit better, and include comments as to the justifications: # # The below options increase throughput substantially. Be aware # that AIO support requires the aio.ko kernel module loaded, # and Samba to be built with AIO enabled. Important notes: # # 1) We explicitly disable sendfile(2) because it has known # problems on ZFS, including resulting in 2x the amount of memory # used on the machine (VM cache + ZFS cache). For further details, # see freebsd-fs or freebsd-stable thread, subject "8.1-STABLE: # zfs and sendfile: problem still exists". # # 2) (2011/10/03) socket options SO_SNDBUF and SO_RCVBUF do not # appear to matter on FreeBSD, or our sysctls somehow take care of # this (or maybe AIO?). The performance is the same with or without # these two socket options on 8.2-STABLE. # # 3) (2011/10/03) My previously-mentioned "aio write behind" option # is incorrect; see the officia smb.conf(5) man page for the syntax. # It's not a yes/no toggleable, thus serves no purpose. # socket options = TCP_NODELAY use sendfile = no min receivefile size = 16384 aio read size = 16384 aio write size = 16384 The rest is in the thread I linked. Hope this helps. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 19:59:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4FD21065672 for ; Tue, 14 Feb 2012 19:59:10 +0000 (UTC) (envelope-from oscarmpp@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2704B8FC17 for ; Tue, 14 Feb 2012 19:59:09 +0000 (UTC) Received: by yenl12 with SMTP id l12so330870yen.13 for ; Tue, 14 Feb 2012 11:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=16tuRwODIeK5ed0AptQydrKjBiPsA578uQv8hM7z7Ms=; b=sGCKJNOr6J72pyeuaYt9wkyG8AlBRLX5nrM5mOLk2lCAS9owe8nfhs/OcF5nf/WC9B hxUtWcrUbLd8k7qiMdhFguf0VpNo5MwbpDDFpWfnt2urfaxUxpfl3+olciXTV2Q3Kj2U IX6nRXRyPS1Fk9YvobmL9ZUrELSKMgVsQeaQE= MIME-Version: 1.0 Received: by 10.60.1.230 with SMTP id 6mr1152090oep.42.1329247884466; Tue, 14 Feb 2012 11:31:24 -0800 (PST) Received: by 10.60.78.36 with HTTP; Tue, 14 Feb 2012 11:31:23 -0800 (PST) In-Reply-To: <20120214192319.44ff7aff@zelda.sugioarto.com> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> Date: Tue, 14 Feb 2012 20:31:23 +0100 Message-ID: From: Oscar Prieto To: Martin Sugioarto Content-Type: multipart/mixed; boundary=e89a8fb1ffa4f8daf904b8f1a3b1 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 19:59:10 -0000 --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi I used to had tons of ahci errors in my 4 disk raidz1 worth of HD154UIs when the rig was built a year ago or so (with 8.0 Release), but they dissapeared after tuning ZFS. Sadly i also got a new timeout days ago followed with smartcl erros i still keep unchecked but i guess they cold be legit, i still have to test/swap cables and give it a try. @Alexander: Where did you got the info about those drives being 4K? ----- Feb 9 08:24:55 zaibach kernel: ahcich3: Timeout on slot 2 port 0 Feb 9 08:24:55 zaibach kernel: ahcich3: is 00000000 cs 00000ff8 ss 00000ffc rs 00000ffc tfd c0 serr 00000000 cmd 0004c317 ----- Feb 14 19:26:48 zaibach smartd[63590]: Device: /dev/ada3, 5 Currently unreadable (pending) sectors Feb 14 19:26:48 zaibach smartd[63590]: Device: /dev/ada3, 1 Offline uncorrectable sectors ----- Regarding the drives themselves i really expected more throughput, funnily i tend to get faster writes than sequential reads with samba (40Mb/s vs 30ish Mb/s under a Gb link) and i'm really waiting for the prices to settle to try another ones. On Tue, Feb 14, 2012 at 7:23 PM, Martin Sugioarto wr= ote: > Am Tue, 14 Feb 2012 18:17:19 +0100 > schrieb Harald Schmalzbauer : > >> > I find it interesting that, at least so far, the only people >> > reporting problems of this type with the ahci.ko driver are people >> > using Samsung disks. =A0The only difference is that your models are >> > F1s while the OPs are F2s. >> >> I saw such timeouts long ago and mav@ had a look at my postings and he >> mentioned it could be a NCQ problem. >> I suspected the disks firmware. >> I never tracked it down further, because after replacing the Samsung >> (F3 in that case) disks with hitachi ones solved all my problems and >> gave a big performance kick as well (with zfs). >> You can find the discussion here: >> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.h= tml > > Hi, > > I just want to add here that I am using 2 drives of type "Samsung > HD103SJ" (SpinPoint F3). And I did not have problems with ZFS and with > UFS either (for several years now). Everything has been deployed ontop > ada(4) since FreeBSD-8. > > Actually the speed is very good (sequential read at 140 MB/s and more). > > -- > Martin > _______________________________________________ > 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" --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=US-ASCII; name="kernel.txt" Content-Disposition: attachment; filename="kernel.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbii171 Y3B1ICAgICBIQU1NRVIKaWRlbnQgICBaQUlCQUNICgojbWFrZW9wdGlvbnMgREVCVUc9LWcgICAg ICAgICMgQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMKCm9wdGlvbnMgICAg IFNDSEVEX1VMRSAgICAgICAjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAgICAgUFJFRU1QVElPTiAg ICAgICMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpvcHRpb25zICAgICBJTkVUICAg ICAgICAgICAgIyBJbnRlck5FVHdvcmtpbmcKb3B0aW9ucyAgICAgSU5FVDYgICAgICAgICAgICMg SVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAgICAgU0NUUCAgICAgICAgICAg ICMgU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sCm9wdGlvbnMgICAgIEZGUyAg ICAgICAgICAgICAjIEJlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQpvcHRpb25zICAgICBTT0ZUVVBE QVRFUyAgICAgIyBFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgICAgIFVG U19BQ0wgICAgICAgICAjIFN1cHBvcnQgZm9yIGFjY2VzcyBjb250cm9sIGxpc3RzCm9wdGlvbnMg ICAgIFVGU19ESVJIQVNIICAgICAjIEltcHJvdmUgcGVyZm9ybWFuY2Ugb24gYmlnIGRpcmVjdG9y aWVzCm9wdGlvbnMgICAgIFVGU19HSk9VUk5BTCAgICAjIEVuYWJsZSBnam91cm5hbC1iYXNlZCBV RlMgam91cm5hbGluZwpvcHRpb25zICAgICBNRF9ST09UICAgICAgICAgIyBNRCBpcyBhIHBvdGVu dGlhbCByb290IGRldmljZQpvcHRpb25zICAgICBORlNDTCAgICAgICAgICAgIyBOZXcgTmV0d29y ayBGaWxlc3lzdGVtIENsaWVudApvcHRpb25zICAgICBORlNEICAgICAgICAgICAgIyBOZXcgTmV0 d29yayBGaWxlc3lzdGVtIFNlcnZlcgpvcHRpb25zICAgICBORlNMT0NLRCAgICAgICAgIyBOZXR3 b3JrIExvY2sgTWFuYWdlcgpvcHRpb25zICAgICBORlNfUk9PVCAgICAgICAgIyBORlMgdXNhYmxl IGFzIC8sIHJlcXVpcmVzIE5GU0NMCm9wdGlvbnMgICAgIE1TRE9TRlMgICAgICAgICAjIE1TRE9T IEZpbGVzeXN0ZW0Kb3B0aW9ucyAgICAgQ0Q5NjYwICAgICAgICAgICMgSVNPIDk2NjAgRmlsZXN5 c3RlbQpvcHRpb25zICAgICBQUk9DRlMgICAgICAgICAgIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJl cXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zICAgICBQU0VVRE9GUyAgICAgICAgIyBQc2V1ZG8tZmls ZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAgICAgR0VPTV9QQVJUX0dQVCAgICMgR1VJRCBQYXJ0 aXRpb24gVGFibGVzLgpvcHRpb25zICAgICBHRU9NX0xBQkVMICAgICAgIyBQcm92aWRlcyBsYWJl bGl6YXRpb24Kb3B0aW9ucyAgICAgQ09NUEFUX0ZSRUVCU0QzMiAgICAjIENvbXBhdGlibGUgd2l0 aCBpMzg2IGJpbmFyaWVzCm9wdGlvbnMgICAgIFNDU0lfREVMQVk9NTAwMCAgICAgIyBEZWxheSAo aW4gbXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAgICAgS1RSQUNFICAgICAgICAgICMg a3RyYWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAgICAgU1RBQ0sgICAgICAgICAgICMgc3RhY2soOSkg c3VwcG9ydApvcHRpb25zICAgICBTWVNWU0hNICAgICAgICAgIyBTWVNWLXN0eWxlIHNoYXJlZCBt ZW1vcnkKb3B0aW9ucyAgICAgU1lTVk1TRyAgICAgICAgICMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1 ZXVlcwpvcHRpb25zICAgICBTWVNWU0VNICAgICAgICAgIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMK b3B0aW9ucyAgICAgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIg cmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAgICAgUFJJTlRGX0JVRlJfU0laRT0xMjggICAg IyBQcmV2ZW50IHByaW50ZiBvdXRwdXQgYmVpbmcgaW50ZXJzcGVyc2VkLgpvcHRpb25zICAgICBL QkRfSU5TVEFMTF9DREVWICAgICMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2RldgpvcHRpb25z ICAgICBIV1BNQ19IT09LUyAgICAgIyBOZWNlc3Nhcnkga2VybmVsIGhvb2tzIGZvciBod3BtYyg0 KQpvcHRpb25zICAgICBBVURJVCAgICAgICAgICAgIyBTZWN1cml0eSBldmVudCBhdWRpdGluZwpv cHRpb25zICAgICBNQUMgICAgICAgICAjIFRydXN0ZWRCU0QgTUFDIEZyYW1ld29yawojb3B0aW9u cyAgICBLRFRSQUNFX0ZSQU1FICAgICAgICMgRW5zdXJlIGZyYW1lcyBhcmUgY29tcGlsZWQgaW4K I29wdGlvbnMgICAgS0RUUkFDRV9IT09LUyAgICAgICAjIEtlcm5lbCBEVHJhY2UgaG9va3MKb3B0 aW9ucyAgICAgSU5DTFVERV9DT05GSUdfRklMRSAgICAgIyBJbmNsdWRlIHRoaXMgZmlsZSBpbiBr ZXJuZWwKb3B0aW9ucyAgICAgS0RCICAgICAgICAgIyBLZXJuZWwgZGVidWdnZXIgcmVsYXRlZCBj b2RlCm9wdGlvbnMgICAgIEtEQl9UUkFDRSAgICAgICAjIFByaW50IGEgc3RhY2sgdHJhY2UgZm9y IGEgcGFuaWMKCiMgTWFrZSBhbiBTTVAtY2FwYWJsZSBrZXJuZWwgYnkgZGVmYXVsdApvcHRpb25z ICAgICBTTVAgICAgICAgICAjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKCiMgQ1BV IGZyZXF1ZW5jeSBjb250cm9sCmRldmljZSAgICAgIGNwdWZyZXEKCiMgQnVzIHN1cHBvcnQuCmRl dmljZSAgICAgIGFjcGkKZGV2aWNlICAgICAgcGNpCgojIEFUQSBjb250cm9sbGVycwpkZXZpY2Ug ICAgICBhaGNpICAgICAgICAjIEFIQ0ktY29tcGF0aWJsZSBTQVRBIGNvbnRyb2xsZXJzCmRldmlj ZSAgICAgIGF0YSAgICAgIyBMZWdhY3kgQVRBL1NBVEEgY29udHJvbGxlcnMKb3B0aW9ucyAgICAg QVRBX0NBTSAgICAgIyBIYW5kbGUgbGVnYWN5IGNvbnRyb2xsZXJzIHdpdGggQ0FNCm9wdGlvbnMg ICAgIEFUQV9TVEFUSUNfSUQgICAjIFN0YXRpYyBkZXZpY2UgbnVtYmVyaW5nCgojIEFUQS9TQ1NJ IHBlcmlwaGVyYWxzCmRldmljZSAgICAgIHNjYnVzICAgICAgICMgU0NTSSBidXMgKHJlcXVpcmVk IGZvciBBVEEvU0NTSSkKZGV2aWNlICAgICAgY2ggICAgICAjIFNDU0kgbWVkaWEgY2hhbmdlcnMK ZGV2aWNlICAgICAgZGEgICAgICAjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQpkZXZpY2UgICAgICBz YSAgICAgICMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UgICAgICBjZCAgICAg ICMgQ0QKZGV2aWNlICAgICAgcGFzcyAgICAgICAgIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVj dCBBVEEvU0NTSSBhY2Nlc3MpCmRldmljZSAgICAgIHNlcyAgICAgIyBTQ1NJIEVudmlyb25tZW50 YWwgU2VydmljZXMgKGFuZCBTQUYtVEUpCgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5 Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmljZSAgICAgIGF0a2JkYyAgICAgICMgQVQga2V5 Ym9hcmQgY29udHJvbGxlcgpkZXZpY2UgICAgICBhdGtiZCAgICAgICAjIEFUIGtleWJvYXJkCmRl dmljZSAgICAgIHBzbSAgICAgIyBQUy8yIG1vdXNlCmRldmljZSAgICAgIGtiZG11eCAgICAgICMg a2V5Ym9hcmQgbXVsdGlwbGV4ZXIKZGV2aWNlICAgICAgdmdhICAgICAjIFZHQSB2aWRlbyBjYXJk IGRyaXZlcgpkZXZpY2UgICAgICBzcGxhc2ggICAgICAjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVl biBzYXZlciBzdXBwb3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIs IHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2aWNlICAgICAgc2MKb3B0aW9ucyAgICAgU0Nf UElYRUxfTU9ERSAgICMgYWRkIHN1cHBvcnQgZm9yIHRoZSByYXN0ZXIgdGV4dCBtb2RlCmRldmlj ZSAgICAgIGFncCAgICAgIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIFNlcmlhbCAo Q09NKSBwb3J0cwpkZXZpY2UgICAgICB1YXJ0ICAgICAgICAjIEdlbmVyaWMgVUFSVCBkcml2ZXIK CiMgUENJIEV0aGVybmV0IE5JQ3MuCmRldmljZSAgICAgIGVtICAgICAgIyBJbnRlbCBQUk8vMTAw MCBHaWdhYml0IEV0aGVybmV0IEZhbWlseQoKIyBQc2V1ZG8gZGV2aWNlcy4KZGV2aWNlICAgICAg bG9vcCAgICAgICAgIyBOZXR3b3JrIGxvb3BiYWNrCmRldmljZSAgICAgIHJhbmRvbSAgICAgICMg RW50cm9weSBkZXZpY2UKZGV2aWNlICAgICAgZXRoZXIgICAgICAgIyBFdGhlcm5ldCBzdXBwb3J0 CmRldmljZSAgICAgIHZsYW4gICAgICAgICMgODAyLjFRIFZMQU4gc3VwcG9ydApkZXZpY2UgICAg ICB0dW4gICAgICMgUGFja2V0IHR1bm5lbC4KZGV2aWNlICAgICAgcHR5ICAgICAjIEJTRC1zdHls ZSBjb21wYXRpYmlsaXR5IHBzZXVkbyB0dHlzCmRldmljZSAgICAgIG1kICAgICAgIyBNZW1vcnkg ImRpc2tzIgpkZXZpY2UgICAgICBnaWYgICAgICMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKZGV2 aWNlICAgICAgZmFpdGggICAgICAgIyBJUHY2LXRvLUlQdjQgcmVsYXlpbmcgKHRyYW5zbGF0aW9u KQpkZXZpY2UgICAgICBmaXJtd2FyZSAgICAjIGZpcm13YXJlIGFzc2lzdCBtb2R1bGUKCiMgVGhl IGBicGYnIGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3 YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEK IyBOb3RlIHRoYXQgJ2JwZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRldmljZSAgICAgIGJwZiAg ICAgIyBCZXJrZWxleSBwYWNrZXQgZmlsdGVyCgojIFVTQiBzdXBwb3J0Cm9wdGlvbnMgICAgIFVT Ql9ERUJVRyAgICMgZW5hYmxlIGRlYnVnIG1zZ3MKZGV2aWNlICAgICAgdWhjaSAgICAgICAgIyBV SENJIFBDSS0+VVNCIGludGVyZmFjZQpkZXZpY2UgICAgICBvaGNpICAgICAgICAjIE9IQ0kgUENJ LT5VU0IgaW50ZXJmYWNlCmRldmljZSAgICAgIGVoY2kgICAgICAgICMgRUhDSSBQQ0ktPlVTQiBp bnRlcmZhY2UgKFVTQiAyLjApCmRldmljZSAgICAgIHVzYiAgICAgIyBVU0IgQnVzIChyZXF1aXJl ZCkKI2RldmljZSAgICAgdWRicCAgICAgICAgIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2Vz IChuZWVkcyBuZXRncmFwaCkKZGV2aWNlICAgICAgdWhpZCAgICAgICAgIyAiSHVtYW4gSW50ZXJm YWNlIERldmljZXMiCmRldmljZSAgICAgIHVrYmQgICAgICAgICMgS2V5Ym9hcmQKZGV2aWNlICAg ICAgdW1hc3MgICAgICAgIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQg ZGEKZGV2aWNlICAgICAgdW1zICAgICAjIE1vdXNlCgojIEFMVFEKb3B0aW9ucyAgICAgICAgIEFM VFEKb3B0aW9ucyAgICAgICAgIEFMVFFfQ0JRICAgICAgICAjIENsYXNzIEJhc2VzIFF1ZXVpbmcg KENCUSkKb3B0aW9ucyAgICAgICAgIEFMVFFfUkVEICAgICAgICAjIFJhbmRvbSBFYXJseSBEZXRl Y3Rpb24gKFJFRCkKb3B0aW9ucyAgICAgICAgIEFMVFFfUklPICAgICAgICAjIFJFRCBJbi9PdXQK b3B0aW9ucyAgICAgICAgIEFMVFFfSEZTQyAgICAgICAjIEhpZXJhcmNoaWNhbCBQYWNrZXQgU2No ZWR1bGVyIChIRlNDKQpvcHRpb25zICAgICAgICAgQUxUUV9QUklRICAgICAgICMgUHJpb3JpdHkg UXVldWluZyAoUFJJUSkKb3B0aW9ucyAgICAgICAgIEFMVFFfTk9QQ0MgICAgICAjIFJlcXVpcmVk IGZvciBTTVAgYnVpbGQKCiMgUE9MTElORyAoaHR0cDovL3d3dy5jeWJlcmNpdGkuYml6L2ZhcS9m cmVlYnNkLWRldmljZS1wb2xsaW5nLW5ldHdvcmstcG9sbGluZy10dXRvcmlhbC8pCm9wdGlvbnMg REVWSUNFX1BPTExJTkcKb3B0aW9ucyBIWj0xMDAwCg== --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: application/octet-stream; name=dmesg Content-Disposition: attachment; filename=dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbibzs0 YWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2ljaDI6IDxB SENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNpY2gzOiA8QUhDSSBjaGFubmVs PiBhdCBjaGFubmVsIDMgb24gYWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5l bCA0IG9uIGFoY2kwCmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBvbiBhaGNp MApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2ZXIgYXR0 YWNoZWQpCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXR0aW1lcjA6IDxB VCB0aW1lcj4gcG9ydCAweDQwLTB4NDMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIgImk4MjU0 IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0IiBmcmVx dWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4g cG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJlcXVlbmN5 IDMyNzY4IEh6IHF1YWxpdHkgMAp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgz ZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAp1YXJ0MDogY29uc29sZSAoOTYwMCxu LDgsMSkKdWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZmIGlycSAz IG9uIGFjcGkwCnVhcnQyOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNlOC0weDNlZiBp cnEgNSBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0 IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IDxQUy8y IE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20wOiBtb2Rl bCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24g RXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApUaW1lY291 bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50IHRpbWVy ICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTAKRXZlbnQgdGltZXIgIkhQ RVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQy IiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQRVQzIiBm cmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKb3JtMDogPElTQSBPcHRpb24gUk9NPiBh dCBpb21lbSAweGMwMDAwLTB4YzdmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQg ZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9 MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0g MHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNl bnNvcnM+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9u IGNwdTAKY29yZXRlbXAxOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTEKcDR0 Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY29yZXRlbXAyOiA8 Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTIKcDR0Y2MyOiA8Q1BVIEZyZXF1ZW5j eSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKY29yZXRlbXAzOiA8Q1BVIE9uLURpZSBUaGVybWFs IFNlbnNvcnM+IG9uIGNwdTMKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTMKWkZTIE5PVElDRTogUHJlZmV0Y2ggaXMgZGlzYWJsZWQgYnkgZGVmYXVsdCBpZiBs ZXNzIHRoYW4gNEdCIG9mIFJBTSBpcyBwcmVzZW50OwogICAgICAgICAgICB0byBlbmFibGUsIGFk ZCAidmZzLnpmcy5wcmVmZXRjaF9kaXNhYmxlPTAiIHRvIC9ib290L2xvYWRlci5jb25mLgpaRlMg ZmlsZXN5c3RlbSB2ZXJzaW9uIDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDI4ClRpbWVjb3Vu dGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVlZCBVU0Ig djEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVnZW4wLjE6IDxJbnRlbD4g YXQgdXNidXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQp1aHVi MTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czEKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDQ4 ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1aHVi MjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAx PiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRlbCBFSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzCnVz YnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVsbCBTcGVl ZCBVU0IgdjEuMAp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNAp1aHViNDogPEludGVsIFVIQ0kg cm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czQKdWdl bjUuMTogPEludGVsPiBhdCB1c2J1czUKdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM1CnVodWIwOiAyIHBvcnRzIHdp dGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2J1czY6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW42LjE6IDxJbnRl bD4gYXQgdXNidXM2CnVodWI2OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNgp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWdlbjcuMTogPEludGVsPiBhdCB1c2J1czcKdWh1Yjc6IDxJbnRl bCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXM3CnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViNDog MiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYWRhMCBhdCBhaGNpY2gwIGJ1 cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiB1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCjxTQU1TVU5HIEhEMTU0VUkgMUFHMDExMTg+IEFUQS03IFNBVEEgMi54IGRldmlj ZQphZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElPIDgxOTJi eXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDE0MzA3OTlNQiAoMjkz MDI3NzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGEwOiBQcmV2aW91 c2x5IHdhcyBrbm93biBhcyBhZDQKYWRhMSBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0YXJnZXQg MCBsdW4gMAphZGExOiA8U0FNU1VORyBIRDE1NFVJIDFBRzAxMTE4PiBBVEEtNyBTQVRBIDIueCBk ZXZpY2UKYWRhMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA4 MTkyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExOiAxNDMwNzk5TUIg KDI5MzAyNzcxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRhMTogUHJl dmlvdXNseSB3YXMga25vd24gYXMgYWQ2CmFkYTIgYXQgYWhjaWNoMiBidXMgMCBzY2J1czIgdGFy Z2V0IDAgbHVuIDAKYWRhMjogPFNBTVNVTkcgSEQxNTRVSSAxQUcwMTExOD4gQVRBLTcgU0FUQSAy LnggZGV2aWNlCmFkYTI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVETUE2LCBQ SU8gODE5MmJ5dGVzKQphZGEyOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMjogMTQzMDc5 OU1CICgyOTMwMjc3MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0MpCmFkYTI6 IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkOAphZGEzIGF0IGFoY2ljaDMgYnVzIDAgc2NidXMz IHRhcmdldCAwIGx1biAwCmFkYTM6IDxTQU1TVU5HIEhEMTU0VUkgMUFHMDExMTg+IEFUQS03IFNB VEEgMi54IGRldmljZQphZGEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1B NiwgUElPIDgxOTJieXRlcykKYWRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTM6IDE0 MzA3OTlNQiAoMjkzMDI3NzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQph ZGEzOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDEwCmFkYTQgYXQgYWhjaWNoNCBidXMgMCBz Y2J1czQgdGFyZ2V0IDAgbHVuIDAKYWRhNDogPEtpbmdTcGVjIEtTRC1TQTE4LkgtMDA4U0ogMDkw ODE4PiBBVEEtNyBTQVRBIDIueCBkZXZpY2UKYWRhNDogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChT QVRBIDIueCwgVURNQTYsIFBJTyA1MTJieXRlcykKYWRhNDogNzY4N01CICgxNTc0NDk2MCA1MTIg Ynl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTU2MjBDKQphZGE0OiBQcmV2aW91c2x5IHdhcyBrbm93 biBhcyBhZDEyCmNkMCBhdCBhaGNpY2g1IGJ1cyAwIHNjYnVzNSB0YXJnZXQgMCBsdW4gMApjZDA6 IDxNQVRTSElUQSBDRC1SVyAgQ1ctODEyNCBEWjEzPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0ktMCBk ZXZpY2UgCmNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTIsIEFUQVBJ IDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6 ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50CnVodWIzOiA2IHBvcnRzIHdp dGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEKU01Q OiBBUCBDUFUgIzIgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMzIExhdW5jaGVkIQpUaW1lY291bnRl ciAiVFNDLWxvdyIgZnJlcXVlbmN5IDEzMDIxMTE3IEh6IHF1YWxpdHkgMTAwMApSb290IG1vdW50 IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZAp1Z2VuNy4yOiA8R2VuZXJpYz4gYXQgdXNidXM3CnVtYXNzMDogPEJ1 bGstSW4sIEJ1bGstT3V0LCBJbnRlcmZhY2U+IG9uIHVzYnVzNwp1bWFzczA6ICBTQ1NJIG92ZXIg QnVsay1Pbmx5OyBxdWlya3MgPSAweDQwMDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM3 CnVtYXNzMDo2OjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzNgpUcnlpbmcgdG8gbW91bnQgcm9vdCBm cm9tIHpmczp6cm9vdCBbXS4uLgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNUIFVOSVQg UkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IENBTSBz dGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6IFNDU0kg c3RhdHVzOiBDaGVjayBDb25kaXRpb24KKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTogU0NTSSBz ZW5zZTogTk9UIFJFQURZIGFzYzozYSwwIChNZWRpdW0gbm90IHByZXNlbnQpCmRhMCBhdCB1bWFz cy1zaW0wIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4gMApkYTA6IDxHZW5lcmljLSBTRC9NTUMg MS4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiA0MC4wMDBN Qi9zIHRyYW5zZmVycwpkYTA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBO T1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudAp1Z2VuMi4yOiA8V2luYm9uZCBFbGVjdHJvbmlj cyBDb3JwPiBhdCB1c2J1czIKdW1zMDogPFdpbmJvbmQgRWxlY3Ryb25pY3MgQ29ycCBIZXJtb24g VVNCIGhpZG1vdXNlIERldmljZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8wLjAxLCBhZGRyIDI+IG9u IHVzYnVzMgp1bXMwOiAzIGJ1dHRvbnMgYW5kIFtaXSBjb29yZGluYXRlcyBJRD0wCnVrYmQwOiA8 V2luYm9uZCBFbGVjdHJvbmljcyBDb3JwIEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNlLCBjbGFz cyAwLzAsIHJldiAxLjEwLzAuMDEsIGFkZHIgMj4gb24gdXNidXMyCmtiZDIgYXQgdWtiZDAKKHBy b2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMjAgMCAwIDAg MCAKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0dXMgRXJy b3IKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlv bgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjEpOiBTQ1NJIHNlbnNlOiBOT1QgUkVBRFkgYXNjOjNh LDAgKE1lZGl1bSBub3QgcHJlc2VudCkKZGExIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2NidXM2IHRh cmdldCAwIGx1biAxCmRhMTogPEdlbmVyaWMtIE1TL01TLVBybyAxLjAwPiBSZW1vdmFibGUgRGly ZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTE6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRhMTog QXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5v dCBwcmVzZW50CmVtMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmVtMTogbGluayBzdGF0ZSBj aGFuZ2VkIHRvIFVQCmVtMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KZW0wOiBsaW5rIHN0 YXRlIGNoYW5nZWQgdG8gVVAKZW0wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgplbTA6IGxp bmsgc3RhdGUgY2hhbmdlZCB0byBVUAphcnA6IDE5Mi4xNjguMi4xMzAgbW92ZWQgZnJvbSAwMDox ZDpmZTpkZDoyMzpjZSB0byAwMDoxNDpiZjpjOToxNzo5OSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTMwIG1vdmVkIGZyb20gMDA6MTQ6YmY6Yzk6MTc6OTkgdG8gMDA6MWQ6ZmU6ZGQ6MjM6Y2Ugb24g ZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9tIDAwOjE0OmJmOmQyOjVlOjQyIHRvIDAw OjFkOmZlOmU4OmM2OjAxIG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMjkgbW92ZWQgZnJvbSAwMDox ZDpmZTplODpjNjowMSB0byAwMDoxNDpiZjpkMjo1ZTo0MiBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTI5IG1vdmVkIGZyb20gMDA6MTQ6YmY6ZDI6NWU6NDIgdG8gMDA6MWQ6ZmU6ZTg6YzY6MDEgb24g ZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9tIDAwOjFkOmZlOmU4OmM2OjAxIHRvIDAw OjE0OmJmOmQyOjVlOjQyIG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMjkgbW92ZWQgZnJvbSAwMDox NDpiZjpkMjo1ZTo0MiB0byAwMDoxZDpmZTplODpjNjowMSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTI5IG1vdmVkIGZyb20gMDA6MWQ6ZmU6ZTg6YzY6MDEgdG8gMDA6MTQ6YmY6ZDI6NWU6NDIgb24g ZW0xCmFycDogMTkyLjE2OC4yLjI1MyBtb3ZlZCBmcm9tIDAwOjIyOjE1OjhmOmExOmIzIHRvIDAw OjE0OmJmOmM5OjE3Ojk5IG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMzAgbW92ZWQgZnJvbSAwMDox ZDpmZTpkZDoyMzpjZSB0byAwMDoxNDpiZjpjOToxNzo5OSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTMwIG1vdmVkIGZyb20gMDA6MTQ6YmY6Yzk6MTc6OTkgdG8gMDA6MWQ6ZmU6ZGQ6MjM6Y2Ugb24g ZW0xCmFycDogMTkyLjE2OC4yLjEzMCBtb3ZlZCBmcm9tIDAwOjFkOmZlOmRkOjIzOmNlIHRvIDAw OjE0OmJmOmM5OjE3Ojk5IG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMzAgbW92ZWQgZnJvbSAwMDox NDpiZjpjOToxNzo5OSB0byAwMDoxZDpmZTpkZDoyMzpjZSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTMwIG1vdmVkIGZyb20gMDA6MWQ6ZmU6ZGQ6MjM6Y2UgdG8gMDA6MTQ6YmY6Yzk6MTc6OTkgb24g ZW0xCmFycDogMTkyLjE2OC4yLjEzMCBtb3ZlZCBmcm9tIDAwOjE0OmJmOmM5OjE3Ojk5IHRvIDAw OjFkOmZlOmRkOjIzOmNlIG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMzAgbW92ZWQgZnJvbSAwMDox ZDpmZTpkZDoyMzpjZSB0byAwMDoxNDpiZjpjOToxNzo5OSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTMwIG1vdmVkIGZyb20gMDA6MTQ6YmY6Yzk6MTc6OTkgdG8gMDA6MWQ6ZmU6ZGQ6MjM6Y2Ugb24g ZW0xCmFycDogMTkyLjE2OC4yLjEzMCBtb3ZlZCBmcm9tIDAwOjFkOmZlOmRkOjIzOmNlIHRvIDAw OjE0OmJmOmM5OjE3Ojk5IG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMzAgbW92ZWQgZnJvbSAwMDox NDpiZjpjOToxNzo5OSB0byAwMDoxZDpmZTpkZDoyMzpjZSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTI5IG1vdmVkIGZyb20gMDA6MTQ6YmY6ZDI6NWU6NDIgdG8gMDA6MWQ6ZmU6ZTg6YzY6MDEgb24g ZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9tIDAwOjFkOmZlOmU4OmM2OjAxIHRvIDAw OjE0OmJmOmQyOjVlOjQyIG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMjkgbW92ZWQgZnJvbSAwMDox NDpiZjpkMjo1ZTo0MiB0byAwMDoxZDpmZTplODpjNjowMSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTI5IG1vdmVkIGZyb20gMDA6MWQ6ZmU6ZTg6YzY6MDEgdG8gMDA6MTQ6YmY6ZDI6NWU6NDIgb24g ZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9tIDAwOjE0OmJmOmQyOjVlOjQyIHRvIDAw OjFkOmZlOmU4OmM2OjAxIG9uIGVtMQphcnA6IDE5Mi4xNjguMi4xMjkgbW92ZWQgZnJvbSAwMDox ZDpmZTplODpjNjowMSB0byAwMDoxNDpiZjpkMjo1ZTo0MiBvbiBlbTEKYXJwOiAxOTIuMTY4LjIu MTI5IG1vdmVkIGZyb20gMDA6MTQ6YmY6ZDI6NWU6NDIgdG8gMDA6MWQ6ZmU6ZTg6YzY6MDEgb24g ZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9tIDAwOjFkOmZlOmU4OmM2OjAxIHRvIDAw OjE0OmJmOmQyOjVlOjQyIG9uIGVtMQpMaW1pdGluZyBvcGVuIHBvcnQgUlNUIHJlc3BvbnNlIGZy b20gNTEgdG8gNTAgcGFja2V0cy9zZWMKZW0xOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQKZW0x OiBwcm9taXNjdW91cyBtb2RlIGRpc2FibGVkCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9t IDAwOjE0OmJmOmQyOjVlOjQyIHRvIDAwOjFkOmZlOmU4OmM2OjAxIG9uIGVtMQphcnA6IDE5Mi4x NjguMi4xMjkgbW92ZWQgZnJvbSAwMDoxNDpiZjpkMjo1ZTo0MiB0byAwMDoxZDpmZTplODpjNjow MSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIuMTI5IG1vdmVkIGZyb20gMDA6MWQ6ZmU6ZTg6YzY6MDEg dG8gMDA6MTQ6YmY6ZDI6NWU6NDIgb24gZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9t IDAwOjE0OmJmOmQyOjVlOjQyIHRvIDAwOjFkOmZlOmU4OmM2OjAxIG9uIGVtMQphcnA6IDE5Mi4x NjguMi4xMjkgbW92ZWQgZnJvbSAwMDoxNDpiZjpkMjo1ZTo0MiB0byAwMDoxZDpmZTplODpjNjow MSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIuMTI5IG1vdmVkIGZyb20gMDA6MTQ6YmY6ZDI6NWU6NDIg dG8gMDA6MWQ6ZmU6ZTg6YzY6MDEgb24gZW0xCmFycDogMTkyLjE2OC4yLjEyOSBtb3ZlZCBmcm9t IDAwOjE0OmJmOmQyOjVlOjQyIHRvIDAwOjFkOmZlOmU4OmM2OjAxIG9uIGVtMQphcnA6IDE5Mi4x NjguMi4xMjkgbW92ZWQgZnJvbSAwMDoxNDpiZjpkMjo1ZTo0MiB0byAwMDoxZDpmZTplODpjNjow MSBvbiBlbTEKYXJwOiAxOTIuMTY4LjIuMTI5IG1vdmVkIGZyb20gMDA6MTQ6YmY6ZDI6NWU6NDIg dG8gMDA6MWQ6ZmU6ZTg6YzY6MDEgb24gZW0xCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Ig c3lzdGVtIHByb2Nlc3MgYHZubHJ1JyB0byBzdG9wLi4uZG9uZQpXYWl0aW5nIChtYXggNjAgc2Vj b25kcykgZm9yIHN5c3RlbSBwcm9jZXNzIGBidWZkYWVtb24nIHRvIHN0b3AuLi5kb25lCldhaXRp bmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYHN5bmNlcicgdG8gc3RvcC4u LgpTeW5jaW5nIGRpc2tzLCB2bm9kZXMgcmVtYWluaW5nLi4uMCAwIDAgMCAwIDAgMCBkb25lCkFs bCBidWZmZXJzIHN5bmNlZC4KVXB0aW1lOiAxZDBoNDNtMjNzClJlYm9vdGluZy4uLgpDb3B5cmln aHQgKGMpIDE5OTItMjAxMiBUaGUgRnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5Nzks IDE5ODAsIDE5ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKCVRo ZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCkZyZWVCU0QgaXMgYSByZWdpc3RlcmVkIHRyYWRlbWFyayBvZiBUaGUgRnJlZUJTRCBG b3VuZGF0aW9uLgpGcmVlQlNEIDkuMC1SRUxFQVNFICM1OiBTYXQgRmViICA0IDE2OjQxOjUxIENF VCAyMDEyCiAgICByb290QHphaWJhY2guZHluZG5zLm9yZzovdXNyL29iai91c3Ivc3JjL3N5cy9a QUlCQUNIIGFtZDY0CkNQVTogSW50ZWwoUikgQXRvbShUTSkgQ1BVIEQ1MTAgICBAIDEuNjZHSHog KDE2NjYuNzAtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQg PSAweDEwNmNhICBGYW1pbHkgPSA2ICBNb2RlbCA9IDFjICBTdGVwcGluZyA9IDEwCiAgRmVhdHVy ZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQ LE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNT RSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVhdHVyZXMyPTB4NDBlMzFkPFNTRTMsRFRFUzY0LE1P TixEU19DUEwsVE0yLFNTU0UzLENYMTYseFRQUixQRENNLE1PVkJFPgogIEFNRCBGZWF0dXJlcz0w eDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4KICBUU0M6 IFAtc3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzCnJlYWwgbWVtb3J5ICA9 IDQyOTQ5NjcyOTYgKDQwOTYgTUIpCmF2YWlsIG1lbW9yeSA9IDQwOTM0MzE4MDggKDM5MDMgTUIp CkV2ZW50IHRpbWVyICJMQVBJQyIgcXVhbGl0eSA0MDAKQUNQSSBBUElDIFRhYmxlOiA8MDkxNDEx IEFQSUMxNjMyPgpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0 IENQVXMKRnJlZUJTRC9TTVA6IDEgcGFja2FnZShzKSB4IDIgY29yZShzKSB4IDIgSFRUIHRocmVh ZHMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUC9IVCk6IEFQSUMgSUQ6ICAxCiBj cHUyIChBUCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUC9IVCk6IEFQSUMgSUQ6ICAzCmlvYXBpYzA6 IENoYW5naW5nIEFQSUMgSUQgdG8gNAppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9u IG1vdGhlcmJvYXJkCm5ldGlzcl9pbml0OiBmb3JjaW5nIG1heHRocmVhZHMgdG8gMSBhbmQgYmlu ZHRocmVhZHMgdG8gMCBmb3IgZGV2aWNlIHBvbGxpbmcKa2JkMSBhdCBrYmRtdXgwCmFjcGkwOiA8 U01DSSA+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQphY3BpMDog cmVzZXJ2YXRpb24gb2YgZmVlMDAwMDAsIDEwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRp b24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZAphY3BpMDogcmVzZXJ2YXRpb24gb2YgMTAwMDAwLCBi ZmYwMDAwMCAoMykgZmFpbGVkClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgOTAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1 TUh6PiBwb3J0IDB4ODA4LTB4ODBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6 IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAw eGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMAp1aGNpMDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhjYzAwLTB4Y2MxZiBp cnEgMTYgYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNpMDogTGVnU3VwID0gMHgyZjAwCnVzYnVz MDogPEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kwCnVoY2kxOiA8 SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGM4ODAtMHhjODlmIGly cSAyMSBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVoY2kxOiBMZWdTdXAgPSAweDJmMDAKdXNidXMx OiA8SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTEKdWhjaTI6IDxJ bnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YzgwMC0weGM4MWYgaXJx IDE5IGF0IGRldmljZSAyNi4yIG9uIHBjaTAKdWhjaTI6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czI6 IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMgplaGNpMDogPElu dGVsIDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZWJmYmMwMC0weGZl YmZiZmZmIGlycSAxOCBhdCBkZXZpY2UgMjYuNyBvbiBwY2kwCnVzYnVzMzogRUhDSSB2ZXJzaW9u IDEuMAp1c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24g ZWhjaTAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4LjAg b24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQpwY2liMjogPEFDUEkgUENJLVBD SSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguNCBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIyCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3 LjIuMz4gcG9ydCAweGRjMDAtMHhkYzFmIG1lbSAweGZlOWUwMDAwLTB4ZmU5ZmZmZmYsMHhmZTlk YzAwMC0weGZlOWRmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTIKZW0wOiBVc2luZyBN U0lYIGludGVycnVwdHMgd2l0aCAzIHZlY3RvcnMKZW0wOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoy NTo5MDowMjozMjphNgpwY2liMzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZp Y2UgMjguNSBvbiBwY2kwCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCmVtMTogPEludGVs KFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA3LjIuMz4gcG9ydCAweGVjMDAtMHhlYzFm IG1lbSAweGZlYWUwMDAwLTB4ZmVhZmZmZmYsMHhmZWFkYzAwMC0weGZlYWRmZmZmIGlycSAxNyBh dCBkZXZpY2UgMC4wIG9uIHBjaTMKZW0xOiBVc2luZyBNU0lYIGludGVycnVwdHMgd2l0aCAzIHZl Y3RvcnMKZW0xOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyNTo5MDowMjozMjphNwp1aGNpMzogPElu dGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhjNDgwLTB4YzQ5ZiBpcnEg MjMgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNpMzogTGVnU3VwID0gMHgyZjAwCnVzYnVzNDog PEludGVsIDgyODAxSSAoSUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kzCnVoY2k0OiA8SW50 ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGM0MDAtMHhjNDFmIGlycSAx OSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2k0OiBMZWdTdXAgPSAweDJmMDAKdXNidXM1OiA8 SW50ZWwgODI4MDFJIChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTQKdWhjaTU6IDxJbnRl bCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4YzA4MC0weGMwOWYgaXJxIDE4 IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTU6IExlZ1N1cCA9IDB4MmYwMAp1c2J1czY6IDxJ bnRlbCA4MjgwMUkgKElDSDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpNQplaGNpMTogPEludGVs IDgyODAxSSAoSUNIOSkgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmZWJmYjgwMC0weGZlYmZi YmZmIGlycSAyMyBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwCnVzYnVzNzogRUhDSSB2ZXJzaW9uIDEu MAp1c2J1czc6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhj aTEKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwCnBj aTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNw bGF5PiBtZW0gMHhmYzAwMDAwMC0weGZjZmZmZmZmLDB4ZmRmZmMwMDAtMHhmZGZmZmZmZiwweGZl MDAwMDAwLTB4ZmU3ZmZmZmYgaXJxIDE3IGF0IGRldmljZSA0LjAgb24gcGNpNAppc2FiMDogPFBD SS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBp c2FiMAphaGNpMDogPEludGVsIElDSDkgQUhDSSBTQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhiNDgw LTB4YjQ4NywweGMwMDAtMHhjMDAzLDB4YmMwMC0weGJjMDcsMHhiODgwLTB4Yjg4MywweGI4MDAt MHhiODFmIG1lbSAweGZlYmZiMDAwLTB4ZmViZmI3ZmYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9u IHBjaTAKYWhjaTA6IEFIQ0kgdjEuMjAgd2l0aCA2IDNHYnBzIHBvcnRzLCBQb3J0IE11bHRpcGxp ZXIgbm90IHN1cHBvcnRlZAphaGNpY2gwOiA8QUhDSSBjaGFubmVsPiBhdCBjaGFubmVsIDAgb24g YWhjaTAKYWhjaWNoMTogPEFIQ0kgY2hhbm5lbD4gYXQgY2hhbm5lbCAxIG9uIGFoY2kwCmFoY2lj aDI6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgMiBvbiBhaGNpMAphaGNpY2gzOiA8QUhDSSBj aGFubmVsPiBhdCBjaGFubmVsIDMgb24gYWhjaTAKYWhjaWNoNDogPEFIQ0kgY2hhbm5lbD4gYXQg Y2hhbm5lbCA0IG9uIGFoY2kwCmFoY2ljaDU6IDxBSENJIGNoYW5uZWw+IGF0IGNoYW5uZWwgNSBv biBhaGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAzMS4zIChubyBkcml2 ZXIgYXR0YWNoZWQpCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYXR0aW1l cjA6IDxBVCB0aW1lcj4gcG9ydCAweDQwLTB4NDMgaXJxIDAgb24gYWNwaTAKVGltZWNvdW50ZXIg Imk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDAKRXZlbnQgdGltZXIgImk4MjU0 IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBxdWFsaXR5IDEwMAphdHJ0YzA6IDxBVCByZWFsdGltZSBj bG9jaz4gcG9ydCAweDcwLTB4NzEgaXJxIDggb24gYWNwaTAKRXZlbnQgdGltZXIgIlJUQyIgZnJl cXVlbmN5IDMyNzY4IEh6IHF1YWxpdHkgMAp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBv cnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAp1YXJ0MDogY29uc29sZSAo OTYwMCxuLDgsMSkKdWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGFjcGkwCnVhcnQyOiA8MTY1NTAgb3IgY29tcGF0aWJsZT4gcG9ydCAweDNlOC0w eDNlZiBpcnEgNSBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIp PiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJx IDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCnBzbTA6 IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBbR0lBTlQtTE9DS0VEXQpwc20w OiBtb2RlbCBHZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwCmhwZXQwOiA8SGlnaCBQcmVj aXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMApU aW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTUwCkV2ZW50 IHRpbWVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NTAKRXZlbnQgdGlt ZXIgIkhQRVQxIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIg IkhQRVQyIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKRXZlbnQgdGltZXIgIkhQ RVQzIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA0NDAKb3JtMDogPElTQSBPcHRpb24g Uk9NPiBhdCBpb21lbSAweGMwMDAwLTB4YzdmZmYgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29s ZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywg ZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYg aW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKY29yZXRlbXAwOiA8Q1BVIE9uLURpZSBUaGVy bWFsIFNlbnNvcnM+IG9uIGNwdTAKcDR0Y2MwOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRy b2w+IG9uIGNwdTAKY29yZXRlbXAxOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNw dTEKcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTEKY29yZXRl bXAyOiA8Q1BVIE9uLURpZSBUaGVybWFsIFNlbnNvcnM+IG9uIGNwdTIKcDR0Y2MyOiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTIKY29yZXRlbXAzOiA8Q1BVIE9uLURpZSBU aGVybWFsIFNlbnNvcnM+IG9uIGNwdTMKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENv bnRyb2w+IG9uIGNwdTMKWkZTIE5PVElDRTogUHJlZmV0Y2ggaXMgZGlzYWJsZWQgYnkgZGVmYXVs dCBpZiBsZXNzIHRoYW4gNEdCIG9mIFJBTSBpcyBwcmVzZW50OwogICAgICAgICAgICB0byBlbmFi bGUsIGFkZCAidmZzLnpmcy5wcmVmZXRjaF9kaXNhYmxlPTAiIHRvIC9ib290L2xvYWRlci5jb25m LgpaRlMgZmlsZXN5c3RlbSB2ZXJzaW9uIDUKWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uIDI4ClRp bWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKdXNidXMwOiAxMk1icHMgRnVsbCBTcGVl ZCBVU0IgdjEuMAp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wCnVnZW4wLjE6IDxJ bnRlbD4gYXQgdXNidXMwCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCBy ZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVz MQp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czEKdXNidXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1 czM6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMAp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVz Mgp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJbnRl bCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNi dXMzCnVzYnVzNDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNidXM1OiAxMk1icHMgRnVs bCBTcGVlZCBVU0IgdjEuMAp1Z2VuNC4xOiA8SW50ZWw+IGF0IHVzYnVzNAp1aHViNDogPEludGVs IFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1 czQKdWdlbjUuMTogPEludGVsPiBhdCB1c2J1czUKdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgSFVC LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXM1CnVodWIwOiAyIHBv cnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2J1czY6IDEyTWJwcyBGdWxsIFNw ZWVkIFVTQiB2MS4wCnVzYnVzNzogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wCnVnZW42LjE6 IDxJbnRlbD4gYXQgdXNidXM2CnVodWI2OiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNgp1aHViMTogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjcuMTogPEludGVsPiBhdCB1c2J1czcKdWh1Yjc6 IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXM3CnVodWIyOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYWRhMCBhdCBhaGNp Y2gwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgMCBsdW4gMAphZGEwOiB1aHViNTogMiBwb3J0cyB3aXRo IDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWh1YjY6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCjxTQU1TVU5HIEhEMTU0VUkgMUFHMDExMTg+IEFUQS03IFNBVEEgMi54 IGRldmljZQphZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54LCBVRE1BNiwgUElP IDgxOTJieXRlcykKYWRhMDogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFkYTA6IDE0MzA3OTlN QiAoMjkzMDI3NzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYzODNDKQphZGEwOiBQ cmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDQKYWRhMSBhdCBhaGNpY2gxIGJ1cyAwIHNjYnVzMSB0 YXJnZXQgMCBsdW4gMAphZGExOiA8U0FNU1VORyBIRDE1NFVJIDFBRzAxMTE4PiBBVEEtNyBTQVRB IDIueCBkZXZpY2UKYWRhMTogMzAwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDIueCwgVURNQTYs IFBJTyA4MTkyYnl0ZXMpCmFkYTE6IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZAphZGExOiAxNDMw Nzk5TUIgKDI5MzAyNzcxNjggNTEyIGJ5dGUgc2VjdG9yczogMTZIIDYzUy9UIDE2MzgzQykKYWRh MTogUHJldmlvdXNseSB3YXMga25vd24gYXMgYWQ2CmFkYTIgYXQgYWhjaWNoMiBidXMgMCBzY2J1 czIgdGFyZ2V0IDAgbHVuIDAKYWRhMjogPFNBTVNVTkcgSEQxNTRVSSAxQUcwMTExOD4gQVRBLTcg U0FUQSAyLnggZGV2aWNlCmFkYTI6IDMwMC4wMDBNQi9zIHRyYW5zZmVycyAoU0FUQSAyLngsIFVE TUE2LCBQSU8gODE5MmJ5dGVzKQphZGEyOiBDb21tYW5kIFF1ZXVlaW5nIGVuYWJsZWQKYWRhMjog MTQzMDc5OU1CICgyOTMwMjc3MTY4IDUxMiBieXRlIHNlY3RvcnM6IDE2SCA2M1MvVCAxNjM4M0Mp CmFkYTI6IFByZXZpb3VzbHkgd2FzIGtub3duIGFzIGFkOAphZGEzIGF0IGFoY2ljaDMgYnVzIDAg c2NidXMzIHRhcmdldCAwIGx1biAwCmFkYTM6IDxTQU1TVU5HIEhEMTU0VUkgMUFHMDExMTg+IEFU QS03IFNBVEEgMi54IGRldmljZQphZGEzOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMgKFNBVEEgMi54 LCBVRE1BNiwgUElPIDgxOTJieXRlcykKYWRhMzogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkCmFk YTM6IDE0MzA3OTlNQiAoMjkzMDI3NzE2OCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTYz ODNDKQphZGEzOiBQcmV2aW91c2x5IHdhcyBrbm93biBhcyBhZDEwCmFkYTQgYXQgYWhjaWNoNCBi dXMgMCBzY2J1czQgdGFyZ2V0IDAgbHVuIDAKYWRhNDogPEtpbmdTcGVjIEtTRC1TQTE4LkgtMDA4 U0ogMDkwODE4PiBBVEEtNyBTQVRBIDIueCBkZXZpY2UKYWRhNDogMzAwLjAwME1CL3MgdHJhbnNm ZXJzIChTQVRBIDIueCwgVURNQTYsIFBJTyA1MTJieXRlcykKYWRhNDogNzY4N01CICgxNTc0NDk2 MCA1MTIgYnl0ZSBzZWN0b3JzOiAxNkggNjNTL1QgMTU2MjBDKQphZGE0OiBQcmV2aW91c2x5IHdh cyBrbm93biBhcyBhZDEyCmNkMCBhdCBhaGNpY2g1IGJ1cyAwIHNjYnVzNSB0YXJnZXQgMCBsdW4g MApjZDA6IDxNQVRTSElUQSBDRC1SVyAgQ1ctODEyNCBEWjEzPiBSZW1vdmFibGUgQ0QtUk9NIFND U0ktMCBkZXZpY2UgCmNkMDogMTUwLjAwME1CL3MgdHJhbnNmZXJzIChTQVRBIDEueCwgVURNQTIs IEFUQVBJIDEyYnl0ZXMsIFBJTyA4MTkyYnl0ZXMpCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZp Y2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50CnVodWIzOiA2IHBv cnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hl ZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQpUaW1l Y291bnRlciAiVFNDLWxvdyIgZnJlcXVlbmN5IDEzMDIxMTAzIEh6IHF1YWxpdHkgMTAwMApSb290 IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czcgdXNidXMzCnVodWI3OiA2IHBvcnRzIHdpdGggNiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1Z2VuNy4yOiA8R2VuZXJpYz4gYXQgdXNidXM3CnVtYXNz MDogPEJ1bGstSW4sIEJ1bGstT3V0LCBJbnRlcmZhY2U+IG9uIHVzYnVzNwp1bWFzczA6ICBTQ1NJ IG92ZXIgQnVsay1Pbmx5OyBxdWlya3MgPSAweDQwMDAKUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog dXNidXM3CnVtYXNzMDo2OjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzNgpUcnlpbmcgdG8gbW91bnQg cm9vdCBmcm9tIHpmczp6cm9vdCBbXS4uLgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjApOiBURVNU IFVOSVQgUkVBRFkuIENEQjogMCAwIDAgMCAwIDAgCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6 IENBTSBzdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihwcm9iZTA6dW1hc3Mtc2ltMDowOjA6MCk6 IFNDU0kgc3RhdHVzOiBDaGVjayBDb25kaXRpb24KKHByb2JlMDp1bWFzcy1zaW0wOjA6MDowKTog U0NTSSBzZW5zZTogTk9UIFJFQURZIGFzYzozYSwwIChNZWRpdW0gbm90IHByZXNlbnQpCmRhMCBh dCB1bWFzcy1zaW0wIGJ1cyAwIHNjYnVzNiB0YXJnZXQgMCBsdW4gMApkYTA6IDxHZW5lcmljLSBT RC9NTUMgMS4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEwOiA0 MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFp bGVkOiBOT1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudAp1Z2VuMi4yOiA8V2luYm9uZCBFbGVj dHJvbmljcyBDb3JwPiBhdCB1c2J1czIKdW1zMDogPFdpbmJvbmQgRWxlY3Ryb25pY3MgQ29ycCBI ZXJtb24gVVNCIGhpZG1vdXNlIERldmljZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8wLjAxLCBhZGRy IDI+IG9uIHVzYnVzMgp1bXMwOiAzIGJ1dHRvbnMgYW5kIFtaXSBjb29yZGluYXRlcyBJRD0wCnVr YmQwOiA8V2luYm9uZCBFbGVjdHJvbmljcyBDb3JwIEhlcm1vbiBVU0IgaGlkbW91c2UgRGV2aWNl LCBjbGFzcyAwLzAsIHJldiAxLjEwLzAuMDEsIGFkZHIgMj4gb24gdXNidXMyCmtiZDIgYXQgdWti ZDAKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogVEVTVCBVTklUIFJFQURZLiBDREI6IDAgMjAg MCAwIDAgMCAKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogQ0FNIHN0YXR1czogU0NTSSBTdGF0 dXMgRXJyb3IKKHByb2JlMDp1bWFzcy1zaW0wOjA6MDoxKTogU0NTSSBzdGF0dXM6IENoZWNrIENv bmRpdGlvbgoocHJvYmUwOnVtYXNzLXNpbTA6MDowOjEpOiBTQ1NJIHNlbnNlOiBOT1QgUkVBRFkg YXNjOjNhLDAgKE1lZGl1bSBub3QgcHJlc2VudCkKZGExIGF0IHVtYXNzLXNpbTAgYnVzIDAgc2Ni dXM2IHRhcmdldCAwIGx1biAxCmRhMTogPEdlbmVyaWMtIE1TL01TLVBybyAxLjAwPiBSZW1vdmFi bGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIApkYTE6IDQwLjAwME1CL3MgdHJhbnNmZXJz CmRhMTogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVk aXVtIG5vdCBwcmVzZW50CmVtMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmVtMTogbGluayBz dGF0ZSBjaGFuZ2VkIHRvIFVQCg== --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=US-ASCII; name="smartctl_ada0.txt" Content-Disposition: attachment; filename="smartctl_ada0.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbjb664 c21hcnRjdGwgNS40MiAyMDExLTEwLTIwIHIzNDU4IFtGcmVlQlNEIDkuMC1SRUxFQVNFIGFtZDY0 XSAobG9jYWwgYnVpbGQpCkNvcHlyaWdodCAoQykgMjAwMi0xMSBieSBCcnVjZSBBbGxlbiwgaHR0 cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5GT1JNQVRJ T04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgU0FNU1VORyBTcGluUG9pbnQgRjIgRUcK RGV2aWNlIE1vZGVsOiAgICAgU0FNU1VORyBIRDE1NFVJClNlcmlhbCBOdW1iZXI6ICAgIFMxWFdK MU1TQTAxMjAzCkxVIFdXTiBEZXZpY2UgSWQ6IDUgMDAyNGU5IDAwMjQ1YjI4NApGaXJtd2FyZSBW ZXJzaW9uOiAxQUcwMTExOApVc2VyIENhcGFjaXR5OiAgICAxLDUwMCwzMDEsOTEwLDAxNiBieXRl cyBbMS41MCBUQl0KU2VjdG9yIFNpemU6ICAgICAgNTEyIGJ5dGVzIGxvZ2ljYWwvcGh5c2ljYWwK RGV2aWNlIGlzOiAgICAgICAgSW4gc21hcnRjdGwgZGF0YWJhc2UgW2ZvciBkZXRhaWxzIHVzZTog LVAgc2hvd10KQVRBIFZlcnNpb24gaXM6ICAgOApBVEEgU3RhbmRhcmQgaXM6ICBBVEEtOC1BQ1Mg cmV2aXNpb24gM2IKTG9jYWwgVGltZSBpczogICAgVHVlIEZlYiAxNCAxOTo0OTo1MyAyMDEyIENF VApTTUFSVCBzdXBwb3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxp dHkuClNNQVJUIHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERB VEEgU0VDVElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3Qg cmVzdWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHgwMCkJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkKCQkJ CQl3YXMgbmV2ZXIgc3RhcnRlZC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBE aXNhYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAgIDApCVRoZSBwcmV2 aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKCQkJCQl3aXRob3V0IGVycm9yIG9yIG5v IHNlbGYtdGVzdCBoYXMgZXZlciAKCQkJCQliZWVuIHJ1bi4KVG90YWwgdGltZSB0byBjb21wbGV0 ZSBPZmZsaW5lIApkYXRhIGNvbGxlY3Rpb246IAkJKDE5MjI5KSBzZWNvbmRzLgpPZmZsaW5lIGRh dGEgY29sbGVjdGlvbgpjYXBhYmlsaXRpZXM6IAkJCSAoMHg3YikgU01BUlQgZXhlY3V0ZSBPZmZs aW5lIGltbWVkaWF0ZS4KCQkJCQlBdXRvIE9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uIG9uL29mZiBz dXBwb3J0LgoJCQkJCVN1c3BlbmQgT2ZmbGluZSBjb2xsZWN0aW9uIHVwb24gbmV3CgkJCQkJY29t bWFuZC4KCQkJCQlPZmZsaW5lIHN1cmZhY2Ugc2NhbiBzdXBwb3J0ZWQuCgkJCQkJU2VsZi10ZXN0 IHN1cHBvcnRlZC4KCQkJCQlDb252ZXlhbmNlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuCgkJCQkJU2Vs ZWN0aXZlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuClNNQVJUIGNhcGFiaWxpdGllczogICAgICAgICAg ICAoMHgwMDAzKQlTYXZlcyBTTUFSVCBkYXRhIGJlZm9yZSBlbnRlcmluZwoJCQkJCXBvd2VyLXNh dmluZyBtb2RlLgoJCQkJCVN1cHBvcnRzIFNNQVJUIGF1dG8gc2F2ZSB0aW1lci4KRXJyb3IgbG9n Z2luZyBjYXBhYmlsaXR5OiAgICAgICAgKDB4MDEpCUVycm9yIGxvZ2dpbmcgc3VwcG9ydGVkLgoJ CQkJCUdlbmVyYWwgUHVycG9zZSBMb2dnaW5nIHN1cHBvcnRlZC4KU2hvcnQgc2VsZi10ZXN0IHJv dXRpbmUgCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTogCSAoICAgMikgbWludXRlcy4KRXh0ZW5k ZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggMjU1KSBt aW51dGVzLgpDb252ZXlhbmNlIHNlbGYtdGVzdCByb3V0aW5lCnJlY29tbWVuZGVkIHBvbGxpbmcg dGltZTogCSAoICAzMykgbWludXRlcy4KU0NUIGNhcGFiaWxpdGllczogCSAgICAgICAoMHgwMDNm KQlTQ1QgU3RhdHVzIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRXJyb3IgUmVjb3ZlcnkgQ29udHJvbCBz dXBwb3J0ZWQuCgkJCQkJU0NUIEZlYXR1cmUgQ29udHJvbCBzdXBwb3J0ZWQuCgkJCQkJU0NUIERh dGEgVGFibGUgc3VwcG9ydGVkLgoKU01BUlQgQXR0cmlidXRlcyBEYXRhIFN0cnVjdHVyZSByZXZp c2lvbiBudW1iZXI6IDE2ClZlbmRvciBTcGVjaWZpYyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhy ZXNob2xkczoKSUQjIEFUVFJJQlVURV9OQU1FICAgICAgICAgIEZMQUcgICAgIFZBTFVFIFdPUlNU IFRIUkVTSCBUWVBFICAgICAgVVBEQVRFRCAgV0hFTl9GQUlMRUQgUkFXX1ZBTFVFCiAgMSBSYXdf UmVhZF9FcnJvcl9SYXRlICAgICAweDAwMGYgICAxMDAgICAwOTkgICAwNTEgICAgUHJlLWZhaWwg IEFsd2F5cyAgICAgICAtICAgICAgIDAKICAzIFNwaW5fVXBfVGltZSAgICAgICAgICAgIDB4MDAw NyAgIDA2MiAgIDA2MiAgIDAxMSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTIy MTAKICA0IFN0YXJ0X1N0b3BfQ291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAg ICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMTkxCiAgNSBSZWFsbG9jYXRlZF9TZWN0 b3JfQ3QgICAweDAwMzMgICAxMDAgICAxMDAgICAwMTAgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAg ICAtICAgICAgIDAKICA3IFNlZWtfRXJyb3JfUmF0ZSAgICAgICAgIDB4MDAwZiAgIDEwMCAgIDEw MCAgIDA1MSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMAogIDggU2Vla19UaW1l X1BlcmZvcm1hbmNlICAgMHgwMDI1ICAgMTAwICAgMTAwICAgMDE1ICAgIFByZS1mYWlsICBPZmZs aW5lICAgICAgLSAgICAgICAxMjQxNQogIDkgUG93ZXJfT25fSG91cnMgICAgICAgICAgMHgwMDMy ICAgMDk3ICAgMDk3ICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAxNjQz MAogMTAgU3Bpbl9SZXRyeV9Db3VudCAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDUxICAg IFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAwCiAxMSBDYWxpYnJhdGlvbl9SZXRyeV9D b3VudCAweDAwMTIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAt ICAgICAgIDAKIDEyIFBvd2VyX0N5Y2xlX0NvdW50ICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMTg5CiAxMyBSZWFkX1NvZnRf RXJyb3JfUmF0ZSAgICAweDAwMGUgICAxMDAgICAwOTkgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5 cyAgICAgICAtICAgICAgIDAKMTgzIFJ1bnRpbWVfQmFkX0Jsb2NrICAgICAgIDB4MDAzMiAgIDEw MCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxODQgRW5k LXRvLUVuZF9FcnJvciAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDAwICAgIFByZS1mYWls ICBBbHdheXMgICAgICAgLSAgICAgICAwCjE4NyBSZXBvcnRlZF9VbmNvcnJlY3QgICAgICAweDAw MzIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDg4 CjE4OCBDb21tYW5kX1RpbWVvdXQgICAgICAgICAweDAwMzIgICAxMDAgICAxMDAgICAwMDAgICAg T2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTkwIEFpcmZsb3dfVGVtcGVyYXR1cmVf Q2VsIDB4MDAyMiAgIDA4MSAgIDA1OSAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0g ICAgICAgMTkgKE1pbi9NYXggMTgvMjMpCjE5NCBUZW1wZXJhdHVyZV9DZWxzaXVzICAgICAweDAw MjIgICAwNzkgICAwNTcgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDIx IChNaW4vTWF4IDE3LzI0KQoxOTUgSGFyZHdhcmVfRUNDX1JlY292ZXJlZCAgMHgwMDFhICAgMTAw ICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAyMDc2NTc1MDMK MTk2IFJlYWxsb2NhdGVkX0V2ZW50X0NvdW50IDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBP bGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxOTcgQ3VycmVudF9QZW5kaW5nX1NlY3Rv ciAgMHgwMDEyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAg ICAgICAwCjE5OCBPZmZsaW5lX1VuY29ycmVjdGFibGUgICAweDAwMzAgICAxMDAgICAxMDAgICAw MDAgICAgT2xkX2FnZSAgIE9mZmxpbmUgICAgICAtICAgICAgIDAKMTk5IFVETUFfQ1JDX0Vycm9y X0NvdW50ICAgIDB4MDAzZSAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAg ICAgIC0gICAgICAgOAoyMDAgTXVsdGlfWm9uZV9FcnJvcl9SYXRlICAgMHgwMDBhICAgMTAwICAg MTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjIwMSBTb2Z0X1Jl YWRfRXJyb3JfUmF0ZSAgICAweDAwMGEgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFs d2F5cyAgICAgICAtICAgICAgIDAKClNNQVJUIEVycm9yIExvZyBWZXJzaW9uOiAxCk5vIEVycm9y cyBMb2dnZWQKClNNQVJUIFNlbGYtdGVzdCBsb2cgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAx Ck51bSAgVGVzdF9EZXNjcmlwdGlvbiAgICBTdGF0dXMgICAgICAgICAgICAgICAgICBSZW1haW5p bmcgIExpZmVUaW1lKGhvdXJzKSAgTEJBX29mX2ZpcnN0X2Vycm9yCiMgMSAgRXh0ZW5kZWQgb2Zm bGluZSAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2NDI0ICAgICAg ICAgLQojIDIgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAg ICAgMDAlICAgICAxNjQxNCAgICAgICAgIC0KIyAzICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBs ZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYzOTAgICAgICAgICAtCiMgNCAgU2hv cnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2 MzY1ICAgICAgICAgLQojIDUgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQg ZXJyb3IgICAgICAgMDAlICAgICAxNjM0MSAgICAgICAgIC0KIyA2ICBTaG9ydCBvZmZsaW5lICAg ICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYzMTcgICAgICAgICAt CiMgNyAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAw MCUgICAgIDE2MjkzICAgICAgICAgLQojIDggIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVk IHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjI3MCAgICAgICAgIC0KIyA5ICBFeHRlbmRl ZCBvZmZsaW5lICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYyNTUg ICAgICAgICAtCiMxMCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJv ciAgICAgICAwMCUgICAgIDE2MjQ1ICAgICAgICAgLQojMTEgIFNob3J0IG9mZmxpbmUgICAgICAg Q29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjIyMSAgICAgICAgIC0KIzEy ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAg ICAgMTYxOTggICAgICAgICAtCiMxMyAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0 aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MTc0ICAgICAgICAgLQojMTQgIFNob3J0IG9mZmxp bmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjE1MCAgICAg ICAgIC0KIzE1ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAg ICAgIDAwJSAgICAgMTYxMjYgICAgICAgICAtCiMxNiAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21w bGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MTAyICAgICAgICAgLQojMTcgIEV4 dGVuZGVkIG9mZmxpbmUgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAx NjA4NyAgICAgICAgIC0KIzE4ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0 IGVycm9yICAgICAgIDAwJSAgICAgMTYwNzggICAgICAgICAtCiMxOSAgU2hvcnQgb2ZmbGluZSAg ICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MDU0ICAgICAgICAg LQojMjAgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAg MDAlICAgICAxNjAzMCAgICAgICAgIC0KIzIxICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRl ZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYwMDYgICAgICAgICAtCgpTTUFSVCBTZWxl Y3RpdmUgc2VsZi10ZXN0IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXIgMQogU1BB TiAgTUlOX0xCQSAgTUFYX0xCQSAgQ1VSUkVOVF9URVNUX1NUQVRVUwogICAgMSAgICAgICAgMCAg ICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDIgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5n CiAgICAzICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwogICAgNCAgICAgICAgMCAgICAg ICAgMCAgTm90X3Rlc3RpbmcKICAgIDUgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nClNl bGVjdGl2ZSBzZWxmLXRlc3QgZmxhZ3MgKDB4MCk6CiAgQWZ0ZXIgc2Nhbm5pbmcgc2VsZWN0ZWQg c3BhbnMsIGRvIE5PVCByZWFkLXNjYW4gcmVtYWluZGVyIG9mIGRpc2suCklmIFNlbGVjdGl2ZSBz ZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dlci11cCwgcmVzdW1lIGFmdGVyIDAgbWludXRlIGRl bGF5LgoK --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=US-ASCII; name="smartctl_ada1.txt" Content-Disposition: attachment; filename="smartctl_ada1.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbjb685 c21hcnRjdGwgNS40MiAyMDExLTEwLTIwIHIzNDU4IFtGcmVlQlNEIDkuMC1SRUxFQVNFIGFtZDY0 XSAobG9jYWwgYnVpbGQpCkNvcHlyaWdodCAoQykgMjAwMi0xMSBieSBCcnVjZSBBbGxlbiwgaHR0 cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5GT1JNQVRJ T04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgU0FNU1VORyBTcGluUG9pbnQgRjIgRUcK RGV2aWNlIE1vZGVsOiAgICAgU0FNU1VORyBIRDE1NFVJClNlcmlhbCBOdW1iZXI6ICAgIFMxWFdK MUNaNDEyMDg1CkxVIFdXTiBEZXZpY2UgSWQ6IDUgMDAyNGU5IDAwMzU0NjBkNQpGaXJtd2FyZSBW ZXJzaW9uOiAxQUcwMTExOApVc2VyIENhcGFjaXR5OiAgICAxLDUwMCwzMDEsOTEwLDAxNiBieXRl cyBbMS41MCBUQl0KU2VjdG9yIFNpemU6ICAgICAgNTEyIGJ5dGVzIGxvZ2ljYWwvcGh5c2ljYWwK RGV2aWNlIGlzOiAgICAgICAgSW4gc21hcnRjdGwgZGF0YWJhc2UgW2ZvciBkZXRhaWxzIHVzZTog LVAgc2hvd10KQVRBIFZlcnNpb24gaXM6ICAgOApBVEEgU3RhbmRhcmQgaXM6ICBBVEEtOC1BQ1Mg cmV2aXNpb24gM2IKTG9jYWwgVGltZSBpczogICAgVHVlIEZlYiAxNCAxOTo0OTo1NyAyMDEyIENF VApTTUFSVCBzdXBwb3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxp dHkuClNNQVJUIHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERB VEEgU0VDVElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3Qg cmVzdWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHgwMCkJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkKCQkJ CQl3YXMgbmV2ZXIgc3RhcnRlZC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBE aXNhYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAgIDApCVRoZSBwcmV2 aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKCQkJCQl3aXRob3V0IGVycm9yIG9yIG5v IHNlbGYtdGVzdCBoYXMgZXZlciAKCQkJCQliZWVuIHJ1bi4KVG90YWwgdGltZSB0byBjb21wbGV0 ZSBPZmZsaW5lIApkYXRhIGNvbGxlY3Rpb246IAkJKDE5MjcwKSBzZWNvbmRzLgpPZmZsaW5lIGRh dGEgY29sbGVjdGlvbgpjYXBhYmlsaXRpZXM6IAkJCSAoMHg3YikgU01BUlQgZXhlY3V0ZSBPZmZs aW5lIGltbWVkaWF0ZS4KCQkJCQlBdXRvIE9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uIG9uL29mZiBz dXBwb3J0LgoJCQkJCVN1c3BlbmQgT2ZmbGluZSBjb2xsZWN0aW9uIHVwb24gbmV3CgkJCQkJY29t bWFuZC4KCQkJCQlPZmZsaW5lIHN1cmZhY2Ugc2NhbiBzdXBwb3J0ZWQuCgkJCQkJU2VsZi10ZXN0 IHN1cHBvcnRlZC4KCQkJCQlDb252ZXlhbmNlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuCgkJCQkJU2Vs ZWN0aXZlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuClNNQVJUIGNhcGFiaWxpdGllczogICAgICAgICAg ICAoMHgwMDAzKQlTYXZlcyBTTUFSVCBkYXRhIGJlZm9yZSBlbnRlcmluZwoJCQkJCXBvd2VyLXNh dmluZyBtb2RlLgoJCQkJCVN1cHBvcnRzIFNNQVJUIGF1dG8gc2F2ZSB0aW1lci4KRXJyb3IgbG9n Z2luZyBjYXBhYmlsaXR5OiAgICAgICAgKDB4MDEpCUVycm9yIGxvZ2dpbmcgc3VwcG9ydGVkLgoJ CQkJCUdlbmVyYWwgUHVycG9zZSBMb2dnaW5nIHN1cHBvcnRlZC4KU2hvcnQgc2VsZi10ZXN0IHJv dXRpbmUgCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTogCSAoICAgMikgbWludXRlcy4KRXh0ZW5k ZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggMjU1KSBt aW51dGVzLgpDb252ZXlhbmNlIHNlbGYtdGVzdCByb3V0aW5lCnJlY29tbWVuZGVkIHBvbGxpbmcg dGltZTogCSAoICAzNCkgbWludXRlcy4KU0NUIGNhcGFiaWxpdGllczogCSAgICAgICAoMHgwMDNm KQlTQ1QgU3RhdHVzIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRXJyb3IgUmVjb3ZlcnkgQ29udHJvbCBz dXBwb3J0ZWQuCgkJCQkJU0NUIEZlYXR1cmUgQ29udHJvbCBzdXBwb3J0ZWQuCgkJCQkJU0NUIERh dGEgVGFibGUgc3VwcG9ydGVkLgoKU01BUlQgQXR0cmlidXRlcyBEYXRhIFN0cnVjdHVyZSByZXZp c2lvbiBudW1iZXI6IDE2ClZlbmRvciBTcGVjaWZpYyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhy ZXNob2xkczoKSUQjIEFUVFJJQlVURV9OQU1FICAgICAgICAgIEZMQUcgICAgIFZBTFVFIFdPUlNU IFRIUkVTSCBUWVBFICAgICAgVVBEQVRFRCAgV0hFTl9GQUlMRUQgUkFXX1ZBTFVFCiAgMSBSYXdf UmVhZF9FcnJvcl9SYXRlICAgICAweDAwMGYgICAxMDAgICAxMDAgICAwNTEgICAgUHJlLWZhaWwg IEFsd2F5cyAgICAgICAtICAgICAgIDAKICAzIFNwaW5fVXBfVGltZSAgICAgICAgICAgIDB4MDAw NyAgIDA2MyAgIDA2MyAgIDAxMSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTE5 MzAKICA0IFN0YXJ0X1N0b3BfQ291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAg ICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgNDMKICA1IFJlYWxsb2NhdGVkX1NlY3Rv cl9DdCAgIDB4MDAzMyAgIDEwMCAgIDEwMCAgIDAxMCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAg IC0gICAgICAgMAogIDcgU2Vla19FcnJvcl9SYXRlICAgICAgICAgMHgwMDBmICAgMTAwICAgMTAw ICAgMDUxICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAwCiAgOCBTZWVrX1RpbWVf UGVyZm9ybWFuY2UgICAweDAwMjUgICAxMDAgICAxMDAgICAwMTUgICAgUHJlLWZhaWwgIE9mZmxp bmUgICAgICAtICAgICAgIDExMTkwCiAgOSBQb3dlcl9Pbl9Ib3VycyAgICAgICAgICAweDAwMzIg ICAwOTggICAwOTggICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDk1ODEK IDEwIFNwaW5fUmV0cnlfQ291bnQgICAgICAgIDB4MDAzMyAgIDEwMCAgIDEwMCAgIDA1MSAgICBQ cmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMAogMTEgQ2FsaWJyYXRpb25fUmV0cnlfQ291 bnQgMHgwMDEyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAg ICAgICAwCiAxMiBQb3dlcl9DeWNsZV9Db3VudCAgICAgICAweDAwMzIgICAxMDAgICAxMDAgICAw MDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDQzCiAxMyBSZWFkX1NvZnRfRXJy b3JfUmF0ZSAgICAweDAwMGUgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAg ICAgICAtICAgICAgIDAKMTgzIFJ1bnRpbWVfQmFkX0Jsb2NrICAgICAgIDB4MDAzMiAgIDEwMCAg IDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxODQgRW5kLXRv LUVuZF9FcnJvciAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDAwICAgIFByZS1mYWlsICBB bHdheXMgICAgICAgLSAgICAgICAwCjE4NyBSZXBvcnRlZF9VbmNvcnJlY3QgICAgICAweDAwMzIg ICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTg4 IENvbW1hbmRfVGltZW91dCAgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRf YWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxOTAgQWlyZmxvd19UZW1wZXJhdHVyZV9DZWwg MHgwMDIyICAgMDgxICAgMDY2ICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAg ICAxOSAoTWluL01heCAxOC8yMykKMTk0IFRlbXBlcmF0dXJlX0NlbHNpdXMgICAgIDB4MDAyMiAg IDA3OSAgIDA2NSAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMjEgKE1p bi9NYXggMTgvMjUpCjE5NSBIYXJkd2FyZV9FQ0NfUmVjb3ZlcmVkICAweDAwMWEgICAxMDAgICAx MDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDIyOTcyMDU3NwoxOTYg UmVhbGxvY2F0ZWRfRXZlbnRfQ291bnQgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9h Z2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjE5NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9yICAw eDAwMTIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAg IDAKMTk4IE9mZmxpbmVfVW5jb3JyZWN0YWJsZSAgIDB4MDAzMCAgIDEwMCAgIDEwMCAgIDAwMCAg ICBPbGRfYWdlICAgT2ZmbGluZSAgICAgIC0gICAgICAgMAoxOTkgVURNQV9DUkNfRXJyb3JfQ291 bnQgICAgMHgwMDNlICAgMTAwICAgMDk5ICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAg LSAgICAgICA0CjIwMCBNdWx0aV9ab25lX0Vycm9yX1JhdGUgICAweDAwMGEgICAxMDAgICAxMDAg ICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMjAxIFNvZnRfUmVhZF9F cnJvcl9SYXRlICAgIDB4MDAwYSAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlz ICAgICAgIC0gICAgICAgMAoKU01BUlQgRXJyb3IgTG9nIFZlcnNpb246IDEKTm8gRXJyb3JzIExv Z2dlZAoKU01BUlQgU2VsZi10ZXN0IGxvZyBzdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVyIDEKTnVt ICBUZXN0X0Rlc2NyaXB0aW9uICAgIFN0YXR1cyAgICAgICAgICAgICAgICAgIFJlbWFpbmluZyAg TGlmZVRpbWUoaG91cnMpICBMQkFfb2ZfZmlyc3RfZXJyb3IKIyAxICBTaG9ydCBvZmZsaW5lICAg ICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgIDk1NjUgICAgICAgICAt CiMgMiAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAw MCUgICAgICA5NTQxICAgICAgICAgLQojIDMgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVk IHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAgOTUxNyAgICAgICAgIC0KIyA0ICBTaG9ydCBv ZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgIDk0OTMg ICAgICAgICAtCiMgNSAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJv ciAgICAgICAwMCUgICAgICA5NDY5ICAgICAgICAgLQojIDYgIFNob3J0IG9mZmxpbmUgICAgICAg Q29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAgOTQ0NSAgICAgICAgIC0KIyA3 ICBFeHRlbmRlZCBvZmZsaW5lICAgIEludGVycnVwdGVkIChob3N0IHJlc2V0KSAgICAgIDMwJSAg ICAgIDk0MjggICAgICAgICAtCiMgOCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0 aG91dCBlcnJvciAgICAgICAwMCUgICAgICA5NDIyICAgICAgICAgLQojIDkgIFNob3J0IG9mZmxp bmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAgOTM5NyAgICAg ICAgIC0KIzEwICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAg ICAgIDAwJSAgICAgIDkzNzMgICAgICAgICAtCiMxMSAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21w bGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgICA5MzQ5ICAgICAgICAgLQojMTIgIFNo b3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAg OTMyNSAgICAgICAgIC0KIzEzICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0 IGVycm9yICAgICAgIDAwJSAgICAgIDkzMDEgICAgICAgICAtCiMxNCAgU2hvcnQgb2ZmbGluZSAg ICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgICA5Mjc3ICAgICAgICAg LQojMTUgIEV4dGVuZGVkIG9mZmxpbmUgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAg MDAlICAgICAgOTI2MiAgICAgICAgIC0KIzE2ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRl ZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgIDkyNTMgICAgICAgICAtCiMxNyAgU2hvcnQg b2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgICA5MjI5 ICAgICAgICAgLQojMTggIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJy b3IgICAgICAgMDAlICAgICAgOTIwNSAgICAgICAgIC0KIzE5ICBTaG9ydCBvZmZsaW5lICAgICAg IENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgIDkxODEgICAgICAgICAtCiMy MCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUg ICAgICA5MTU3ICAgICAgICAgLQojMjEgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdp dGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAgOTEzMyAgICAgICAgIC0KClNNQVJUIFNlbGVjdGl2 ZSBzZWxmLXRlc3QgbG9nIGRhdGEgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAxCiBTUEFOICBN SU5fTEJBICBNQVhfTEJBICBDVVJSRU5UX1RFU1RfU1RBVFVTCiAgICAxICAgICAgICAwICAgICAg ICAwICBOb3RfdGVzdGluZwogICAgMiAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKICAg IDMgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICA0ICAgICAgICAwICAgICAgICAw ICBOb3RfdGVzdGluZwogICAgNSAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKU2VsZWN0 aXZlIHNlbGYtdGVzdCBmbGFncyAoMHgwKToKICBBZnRlciBzY2FubmluZyBzZWxlY3RlZCBzcGFu cywgZG8gTk9UIHJlYWQtc2NhbiByZW1haW5kZXIgb2YgZGlzay4KSWYgU2VsZWN0aXZlIHNlbGYt dGVzdCBpcyBwZW5kaW5nIG9uIHBvd2VyLXVwLCByZXN1bWUgYWZ0ZXIgMCBtaW51dGUgZGVsYXku Cgo= --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=US-ASCII; name="smartctl_ada2.txt" Content-Disposition: attachment; filename="smartctl_ada2.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbjb6a6 c21hcnRjdGwgNS40MiAyMDExLTEwLTIwIHIzNDU4IFtGcmVlQlNEIDkuMC1SRUxFQVNFIGFtZDY0 XSAobG9jYWwgYnVpbGQpCkNvcHlyaWdodCAoQykgMjAwMi0xMSBieSBCcnVjZSBBbGxlbiwgaHR0 cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5GT1JNQVRJ T04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgU0FNU1VORyBTcGluUG9pbnQgRjIgRUcK RGV2aWNlIE1vZGVsOiAgICAgU0FNU1VORyBIRDE1NFVJClNlcmlhbCBOdW1iZXI6ICAgIFMxWFdK MU1TQTAxMjA2CkxVIFdXTiBEZXZpY2UgSWQ6IDUgMDAyNGU5IDAwMjQ1YjI4YgpGaXJtd2FyZSBW ZXJzaW9uOiAxQUcwMTExOApVc2VyIENhcGFjaXR5OiAgICAxLDUwMCwzMDEsOTEwLDAxNiBieXRl cyBbMS41MCBUQl0KU2VjdG9yIFNpemU6ICAgICAgNTEyIGJ5dGVzIGxvZ2ljYWwvcGh5c2ljYWwK RGV2aWNlIGlzOiAgICAgICAgSW4gc21hcnRjdGwgZGF0YWJhc2UgW2ZvciBkZXRhaWxzIHVzZTog LVAgc2hvd10KQVRBIFZlcnNpb24gaXM6ICAgOApBVEEgU3RhbmRhcmQgaXM6ICBBVEEtOC1BQ1Mg cmV2aXNpb24gM2IKTG9jYWwgVGltZSBpczogICAgVHVlIEZlYiAxNCAxOTo1MDowMSAyMDEyIENF VApTTUFSVCBzdXBwb3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxp dHkuClNNQVJUIHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERB VEEgU0VDVElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3Qg cmVzdWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHgwMCkJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkKCQkJ CQl3YXMgbmV2ZXIgc3RhcnRlZC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBE aXNhYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAgIDApCVRoZSBwcmV2 aW91cyBzZWxmLXRlc3Qgcm91dGluZSBjb21wbGV0ZWQKCQkJCQl3aXRob3V0IGVycm9yIG9yIG5v IHNlbGYtdGVzdCBoYXMgZXZlciAKCQkJCQliZWVuIHJ1bi4KVG90YWwgdGltZSB0byBjb21wbGV0 ZSBPZmZsaW5lIApkYXRhIGNvbGxlY3Rpb246IAkJKDE5NjMyKSBzZWNvbmRzLgpPZmZsaW5lIGRh dGEgY29sbGVjdGlvbgpjYXBhYmlsaXRpZXM6IAkJCSAoMHg3YikgU01BUlQgZXhlY3V0ZSBPZmZs aW5lIGltbWVkaWF0ZS4KCQkJCQlBdXRvIE9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uIG9uL29mZiBz dXBwb3J0LgoJCQkJCVN1c3BlbmQgT2ZmbGluZSBjb2xsZWN0aW9uIHVwb24gbmV3CgkJCQkJY29t bWFuZC4KCQkJCQlPZmZsaW5lIHN1cmZhY2Ugc2NhbiBzdXBwb3J0ZWQuCgkJCQkJU2VsZi10ZXN0 IHN1cHBvcnRlZC4KCQkJCQlDb252ZXlhbmNlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuCgkJCQkJU2Vs ZWN0aXZlIFNlbGYtdGVzdCBzdXBwb3J0ZWQuClNNQVJUIGNhcGFiaWxpdGllczogICAgICAgICAg ICAoMHgwMDAzKQlTYXZlcyBTTUFSVCBkYXRhIGJlZm9yZSBlbnRlcmluZwoJCQkJCXBvd2VyLXNh dmluZyBtb2RlLgoJCQkJCVN1cHBvcnRzIFNNQVJUIGF1dG8gc2F2ZSB0aW1lci4KRXJyb3IgbG9n Z2luZyBjYXBhYmlsaXR5OiAgICAgICAgKDB4MDEpCUVycm9yIGxvZ2dpbmcgc3VwcG9ydGVkLgoJ CQkJCUdlbmVyYWwgUHVycG9zZSBMb2dnaW5nIHN1cHBvcnRlZC4KU2hvcnQgc2VsZi10ZXN0IHJv dXRpbmUgCnJlY29tbWVuZGVkIHBvbGxpbmcgdGltZTogCSAoICAgMikgbWludXRlcy4KRXh0ZW5k ZWQgc2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggMjU1KSBt aW51dGVzLgpDb252ZXlhbmNlIHNlbGYtdGVzdCByb3V0aW5lCnJlY29tbWVuZGVkIHBvbGxpbmcg dGltZTogCSAoICAzNCkgbWludXRlcy4KU0NUIGNhcGFiaWxpdGllczogCSAgICAgICAoMHgwMDNm KQlTQ1QgU3RhdHVzIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRXJyb3IgUmVjb3ZlcnkgQ29udHJvbCBz dXBwb3J0ZWQuCgkJCQkJU0NUIEZlYXR1cmUgQ29udHJvbCBzdXBwb3J0ZWQuCgkJCQkJU0NUIERh dGEgVGFibGUgc3VwcG9ydGVkLgoKU01BUlQgQXR0cmlidXRlcyBEYXRhIFN0cnVjdHVyZSByZXZp c2lvbiBudW1iZXI6IDE2ClZlbmRvciBTcGVjaWZpYyBTTUFSVCBBdHRyaWJ1dGVzIHdpdGggVGhy ZXNob2xkczoKSUQjIEFUVFJJQlVURV9OQU1FICAgICAgICAgIEZMQUcgICAgIFZBTFVFIFdPUlNU IFRIUkVTSCBUWVBFICAgICAgVVBEQVRFRCAgV0hFTl9GQUlMRUQgUkFXX1ZBTFVFCiAgMSBSYXdf UmVhZF9FcnJvcl9SYXRlICAgICAweDAwMGYgICAxMDAgICAxMDAgICAwNTEgICAgUHJlLWZhaWwg IEFsd2F5cyAgICAgICAtICAgICAgIDAKICAzIFNwaW5fVXBfVGltZSAgICAgICAgICAgIDB4MDAw NyAgIDA2MyAgIDA2MyAgIDAxMSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTE5 NzAKICA0IFN0YXJ0X1N0b3BfQ291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAg ICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMTgwCiAgNSBSZWFsbG9jYXRlZF9TZWN0 b3JfQ3QgICAweDAwMzMgICAxMDAgICAxMDAgICAwMTAgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAg ICAtICAgICAgIDAKICA3IFNlZWtfRXJyb3JfUmF0ZSAgICAgICAgIDB4MDAwZiAgIDEwMCAgIDEw MCAgIDA1MSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMAogIDggU2Vla19UaW1l X1BlcmZvcm1hbmNlICAgMHgwMDI1ICAgMTAwICAgMDgzICAgMDE1ICAgIFByZS1mYWlsICBPZmZs aW5lICAgICAgLSAgICAgICAxMjI3MAogIDkgUG93ZXJfT25fSG91cnMgICAgICAgICAgMHgwMDMy ICAgMDk3ICAgMDk3ICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAxNjQz MQogMTAgU3Bpbl9SZXRyeV9Db3VudCAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDUxICAg IFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAwCiAxMSBDYWxpYnJhdGlvbl9SZXRyeV9D b3VudCAweDAwMTIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAt ICAgICAgIDAKIDEyIFBvd2VyX0N5Y2xlX0NvdW50ICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMTgwCiAxMyBSZWFkX1NvZnRf RXJyb3JfUmF0ZSAgICAweDAwMGUgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5 cyAgICAgICAtICAgICAgIDAKMTgzIFJ1bnRpbWVfQmFkX0Jsb2NrICAgICAgIDB4MDAzMiAgIDEw MCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxODQgRW5k LXRvLUVuZF9FcnJvciAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDAwICAgIFByZS1mYWls ICBBbHdheXMgICAgICAgLSAgICAgICAwCjE4NyBSZXBvcnRlZF9VbmNvcnJlY3QgICAgICAweDAw MzIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAK MTg4IENvbW1hbmRfVGltZW91dCAgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBP bGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMAoxOTAgQWlyZmxvd19UZW1wZXJhdHVyZV9D ZWwgMHgwMDIyICAgMDgxICAgMDYzICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAg ICAgICAxOSAoTWluL01heCAxOC8yMykKMTk0IFRlbXBlcmF0dXJlX0NlbHNpdXMgICAgIDB4MDAy MiAgIDA3OCAgIDA2MiAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMjIg KE1pbi9NYXggMTcvMjUpCjE5NSBIYXJkd2FyZV9FQ0NfUmVjb3ZlcmVkICAweDAwMWEgICAxMDAg ICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDI4NDk1Nzc2Mwox OTYgUmVhbGxvY2F0ZWRfRXZlbnRfQ291bnQgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAgIE9s ZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjE5NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9y ICAweDAwMTIgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAg ICAgIDAKMTk4IE9mZmxpbmVfVW5jb3JyZWN0YWJsZSAgIDB4MDAzMCAgIDEwMCAgIDEwMCAgIDAw MCAgICBPbGRfYWdlICAgT2ZmbGluZSAgICAgIC0gICAgICAgMAoxOTkgVURNQV9DUkNfRXJyb3Jf Q291bnQgICAgMHgwMDNlICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAg ICAgLSAgICAgICAyMAoyMDAgTXVsdGlfWm9uZV9FcnJvcl9SYXRlICAgMHgwMDBhICAgMTAwICAg MTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAwCjIwMSBTb2Z0X1Jl YWRfRXJyb3JfUmF0ZSAgICAweDAwMGEgICAxMDAgICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFs d2F5cyAgICAgICAtICAgICAgIDAKClNNQVJUIEVycm9yIExvZyBWZXJzaW9uOiAxCk5vIEVycm9y cyBMb2dnZWQKClNNQVJUIFNlbGYtdGVzdCBsb2cgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAx Ck51bSAgVGVzdF9EZXNjcmlwdGlvbiAgICBTdGF0dXMgICAgICAgICAgICAgICAgICBSZW1haW5p bmcgIExpZmVUaW1lKGhvdXJzKSAgTEJBX29mX2ZpcnN0X2Vycm9yCiMgMSAgU2hvcnQgb2ZmbGlu ZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2NDE2ICAgICAg ICAgLQojIDIgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAg ICAgMDAlICAgICAxNjM5MiAgICAgICAgIC0KIyAzICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBs ZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYzNjggICAgICAgICAtCiMgNCAgU2hv cnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2 MzQ0ICAgICAgICAgLQojIDUgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQg ZXJyb3IgICAgICAgMDAlICAgICAxNjMyMCAgICAgICAgIC0KIyA2ICBFeHRlbmRlZCBvZmZsaW5l ICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYzMTMgICAgICAgICAt CiMgNyAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAw MCUgICAgIDE2Mjk2ICAgICAgICAgLQojIDggIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVk IHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjI3MiAgICAgICAgIC0KIyA5ICBTaG9ydCBv ZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYyNDgg ICAgICAgICAtCiMxMCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJv ciAgICAgICAwMCUgICAgIDE2MjI0ICAgICAgICAgLQojMTEgIFNob3J0IG9mZmxpbmUgICAgICAg Q29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjIwMCAgICAgICAgIC0KIzEy ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAg ICAgMTYxNzYgICAgICAgICAtCiMxMyAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0 aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MTUyICAgICAgICAgLQojMTQgIEV4dGVuZGVkIG9m ZmxpbmUgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjEzNiAgICAg ICAgIC0KIzE1ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAg ICAgIDAwJSAgICAgMTYxMjggICAgICAgICAtCiMxNiAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21w bGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MTA0ICAgICAgICAgLQojMTcgIFNo b3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAx NjA4MCAgICAgICAgIC0KIzE4ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0 IGVycm9yICAgICAgIDAwJSAgICAgMTYwNTYgICAgICAgICAtCiMxOSAgU2hvcnQgb2ZmbGluZSAg ICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MDMyICAgICAgICAg LQojMjAgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAg MDAlICAgICAxNjAwOCAgICAgICAgIC0KIzIxICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRl ZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTU5ODQgICAgICAgICAtCgpTTUFSVCBTZWxl Y3RpdmUgc2VsZi10ZXN0IGxvZyBkYXRhIHN0cnVjdHVyZSByZXZpc2lvbiBudW1iZXIgMQogU1BB TiAgTUlOX0xCQSAgTUFYX0xCQSAgQ1VSUkVOVF9URVNUX1NUQVRVUwogICAgMSAgICAgICAgMCAg ICAgICAgMCAgTm90X3Rlc3RpbmcKICAgIDIgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5n CiAgICAzICAgICAgICAwICAgICAgICAwICBOb3RfdGVzdGluZwogICAgNCAgICAgICAgMCAgICAg ICAgMCAgTm90X3Rlc3RpbmcKICAgIDUgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nClNl bGVjdGl2ZSBzZWxmLXRlc3QgZmxhZ3MgKDB4MCk6CiAgQWZ0ZXIgc2Nhbm5pbmcgc2VsZWN0ZWQg c3BhbnMsIGRvIE5PVCByZWFkLXNjYW4gcmVtYWluZGVyIG9mIGRpc2suCklmIFNlbGVjdGl2ZSBz ZWxmLXRlc3QgaXMgcGVuZGluZyBvbiBwb3dlci11cCwgcmVzdW1lIGFmdGVyIDAgbWludXRlIGRl bGF5LgoK --e89a8fb1ffa4f8daf904b8f1a3b1 Content-Type: text/plain; charset=US-ASCII; name="smartctl_ada3.txt" Content-Disposition: attachment; filename="smartctl_ada3.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gynbjb6c7 c21hcnRjdGwgNS40MiAyMDExLTEwLTIwIHIzNDU4IFtGcmVlQlNEIDkuMC1SRUxFQVNFIGFtZDY0 XSAobG9jYWwgYnVpbGQpCkNvcHlyaWdodCAoQykgMjAwMi0xMSBieSBCcnVjZSBBbGxlbiwgaHR0 cDovL3NtYXJ0bW9udG9vbHMuc291cmNlZm9yZ2UubmV0Cgo9PT0gU1RBUlQgT0YgSU5GT1JNQVRJ T04gU0VDVElPTiA9PT0KTW9kZWwgRmFtaWx5OiAgICAgU0FNU1VORyBTcGluUG9pbnQgRjIgRUcK RGV2aWNlIE1vZGVsOiAgICAgU0FNU1VORyBIRDE1NFVJClNlcmlhbCBOdW1iZXI6ICAgIFMxWFdK MU1TQTAxMjAxCkxVIFdXTiBEZXZpY2UgSWQ6IDUgMDAyNGU5IDAwMjQ1YjI3YQpGaXJtd2FyZSBW ZXJzaW9uOiAxQUcwMTExOApVc2VyIENhcGFjaXR5OiAgICAxLDUwMCwzMDEsOTEwLDAxNiBieXRl cyBbMS41MCBUQl0KU2VjdG9yIFNpemU6ICAgICAgNTEyIGJ5dGVzIGxvZ2ljYWwvcGh5c2ljYWwK RGV2aWNlIGlzOiAgICAgICAgSW4gc21hcnRjdGwgZGF0YWJhc2UgW2ZvciBkZXRhaWxzIHVzZTog LVAgc2hvd10KQVRBIFZlcnNpb24gaXM6ICAgOApBVEEgU3RhbmRhcmQgaXM6ICBBVEEtOC1BQ1Mg cmV2aXNpb24gM2IKTG9jYWwgVGltZSBpczogICAgVHVlIEZlYiAxNCAxOTo1MDowNSAyMDEyIENF VApTTUFSVCBzdXBwb3J0IGlzOiBBdmFpbGFibGUgLSBkZXZpY2UgaGFzIFNNQVJUIGNhcGFiaWxp dHkuClNNQVJUIHN1cHBvcnQgaXM6IEVuYWJsZWQKCj09PSBTVEFSVCBPRiBSRUFEIFNNQVJUIERB VEEgU0VDVElPTiA9PT0KU01BUlQgb3ZlcmFsbC1oZWFsdGggc2VsZi1hc3Nlc3NtZW50IHRlc3Qg cmVzdWx0OiBQQVNTRUQKCkdlbmVyYWwgU01BUlQgVmFsdWVzOgpPZmZsaW5lIGRhdGEgY29sbGVj dGlvbiBzdGF0dXM6ICAoMHgwMCkJT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gYWN0aXZpdHkKCQkJ CQl3YXMgbmV2ZXIgc3RhcnRlZC4KCQkJCQlBdXRvIE9mZmxpbmUgRGF0YSBDb2xsZWN0aW9uOiBE aXNhYmxlZC4KU2VsZi10ZXN0IGV4ZWN1dGlvbiBzdGF0dXM6ICAgICAgKCAxMTQpCVRoZSBwcmV2 aW91cyBzZWxmLXRlc3QgY29tcGxldGVkIGhhdmluZwoJCQkJCXRoZSByZWFkIGVsZW1lbnQgb2Yg dGhlIHRlc3QgZmFpbGVkLgpUb3RhbCB0aW1lIHRvIGNvbXBsZXRlIE9mZmxpbmUgCmRhdGEgY29s bGVjdGlvbjogCQkoMTkzNjgpIHNlY29uZHMuCk9mZmxpbmUgZGF0YSBjb2xsZWN0aW9uCmNhcGFi aWxpdGllczogCQkJICgweDdiKSBTTUFSVCBleGVjdXRlIE9mZmxpbmUgaW1tZWRpYXRlLgoJCQkJ CUF1dG8gT2ZmbGluZSBkYXRhIGNvbGxlY3Rpb24gb24vb2ZmIHN1cHBvcnQuCgkJCQkJU3VzcGVu ZCBPZmZsaW5lIGNvbGxlY3Rpb24gdXBvbiBuZXcKCQkJCQljb21tYW5kLgoJCQkJCU9mZmxpbmUg c3VyZmFjZSBzY2FuIHN1cHBvcnRlZC4KCQkJCQlTZWxmLXRlc3Qgc3VwcG9ydGVkLgoJCQkJCUNv bnZleWFuY2UgU2VsZi10ZXN0IHN1cHBvcnRlZC4KCQkJCQlTZWxlY3RpdmUgU2VsZi10ZXN0IHN1 cHBvcnRlZC4KU01BUlQgY2FwYWJpbGl0aWVzOiAgICAgICAgICAgICgweDAwMDMpCVNhdmVzIFNN QVJUIGRhdGEgYmVmb3JlIGVudGVyaW5nCgkJCQkJcG93ZXItc2F2aW5nIG1vZGUuCgkJCQkJU3Vw cG9ydHMgU01BUlQgYXV0byBzYXZlIHRpbWVyLgpFcnJvciBsb2dnaW5nIGNhcGFiaWxpdHk6ICAg ICAgICAoMHgwMSkJRXJyb3IgbG9nZ2luZyBzdXBwb3J0ZWQuCgkJCQkJR2VuZXJhbCBQdXJwb3Nl IExvZ2dpbmcgc3VwcG9ydGVkLgpTaG9ydCBzZWxmLXRlc3Qgcm91dGluZSAKcmVjb21tZW5kZWQg cG9sbGluZyB0aW1lOiAJICggICAyKSBtaW51dGVzLgpFeHRlbmRlZCBzZWxmLXRlc3Qgcm91dGlu ZQpyZWNvbW1lbmRlZCBwb2xsaW5nIHRpbWU6IAkgKCAyNTUpIG1pbnV0ZXMuCkNvbnZleWFuY2Ug c2VsZi10ZXN0IHJvdXRpbmUKcmVjb21tZW5kZWQgcG9sbGluZyB0aW1lOiAJICggIDM0KSBtaW51 dGVzLgpTQ1QgY2FwYWJpbGl0aWVzOiAJICAgICAgICgweDAwM2YpCVNDVCBTdGF0dXMgc3VwcG9y dGVkLgoJCQkJCVNDVCBFcnJvciBSZWNvdmVyeSBDb250cm9sIHN1cHBvcnRlZC4KCQkJCQlTQ1Qg RmVhdHVyZSBDb250cm9sIHN1cHBvcnRlZC4KCQkJCQlTQ1QgRGF0YSBUYWJsZSBzdXBwb3J0ZWQu CgpTTUFSVCBBdHRyaWJ1dGVzIERhdGEgU3RydWN0dXJlIHJldmlzaW9uIG51bWJlcjogMTYKVmVu ZG9yIFNwZWNpZmljIFNNQVJUIEF0dHJpYnV0ZXMgd2l0aCBUaHJlc2hvbGRzOgpJRCMgQVRUUklC VVRFX05BTUUgICAgICAgICAgRkxBRyAgICAgVkFMVUUgV09SU1QgVEhSRVNIIFRZUEUgICAgICBV UERBVEVEICBXSEVOX0ZBSUxFRCBSQVdfVkFMVUUKICAxIFJhd19SZWFkX0Vycm9yX1JhdGUgICAg IDB4MDAwZiAgIDEwMCAgIDA5OSAgIDA1MSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAg ICAgNDIKICAzIFNwaW5fVXBfVGltZSAgICAgICAgICAgIDB4MDAwNyAgIDA2MiAgIDA2MiAgIDAx MSAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTIxMjAKICA0IFN0YXJ0X1N0b3Bf Q291bnQgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlz ICAgICAgIC0gICAgICAgMTgzCiAgNSBSZWFsbG9jYXRlZF9TZWN0b3JfQ3QgICAweDAwMzMgICAx MDAgICAxMDAgICAwMTAgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAgICAtICAgICAgIDAKICA3IFNl ZWtfRXJyb3JfUmF0ZSAgICAgICAgIDB4MDAwZiAgIDEwMCAgIDEwMCAgIDA1MSAgICBQcmUtZmFp bCAgQWx3YXlzICAgICAgIC0gICAgICAgMAogIDggU2Vla19UaW1lX1BlcmZvcm1hbmNlICAgMHgw MDI1ICAgMTAwICAgMTAwICAgMDE1ICAgIFByZS1mYWlsICBPZmZsaW5lICAgICAgLSAgICAgICAx MjU1NwogIDkgUG93ZXJfT25fSG91cnMgICAgICAgICAgMHgwMDMyICAgMDk3ICAgMDk3ICAgMDAw ICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAxNjQzMAogMTAgU3Bpbl9SZXRyeV9D b3VudCAgICAgICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDUxICAgIFByZS1mYWlsICBBbHdheXMg ICAgICAgLSAgICAgICAwCiAxMSBDYWxpYnJhdGlvbl9SZXRyeV9Db3VudCAweDAwMTIgICAxMDAg ICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKIDEyIFBvd2Vy X0N5Y2xlX0NvdW50ICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAg QWx3YXlzICAgICAgIC0gICAgICAgMTgyCiAxMyBSZWFkX1NvZnRfRXJyb3JfUmF0ZSAgICAweDAw MGUgICAxMDAgICAwOTkgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDQy CjE4MyBSdW50aW1lX0JhZF9CbG9jayAgICAgICAweDAwMzIgICAxMDAgICAxMDAgICAwMDAgICAg T2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMTg0IEVuZC10by1FbmRfRXJyb3IgICAg ICAgIDB4MDAzMyAgIDEwMCAgIDEwMCAgIDAwMCAgICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0g ICAgICAgMAoxODcgUmVwb3J0ZWRfVW5jb3JyZWN0ICAgICAgMHgwMDMyICAgMTAwICAgMTAwICAg MDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAxODAKMTg4IENvbW1hbmRfVGlt ZW91dCAgICAgICAgIDB4MDAzMiAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlz ICAgICAgIC0gICAgICAgMAoxOTAgQWlyZmxvd19UZW1wZXJhdHVyZV9DZWwgMHgwMDIyICAgMDgw ICAgMDYxICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAyMCAoTWluL01h eCAxOC8yMykKMTk0IFRlbXBlcmF0dXJlX0NlbHNpdXMgICAgIDB4MDAyMiAgIDA3OCAgIDA1OSAg IDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAgICAgMjIgKE1pbi9NYXggMTgvMjUp CjE5NSBIYXJkd2FyZV9FQ0NfUmVjb3ZlcmVkICAweDAwMWEgICAxMDAgICAxMDAgICAwMDAgICAg T2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDI4MjgwNzM0NQoxOTYgUmVhbGxvY2F0ZWRf RXZlbnRfQ291bnQgMHgwMDMyICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMg ICAgICAgLSAgICAgICAwCjE5NyBDdXJyZW50X1BlbmRpbmdfU2VjdG9yICAweDAwMTIgICAxMDAg ICAxMDAgICAwMDAgICAgT2xkX2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDUKMTk4IE9mZmxp bmVfVW5jb3JyZWN0YWJsZSAgIDB4MDAzMCAgIDEwMCAgIDEwMCAgIDAwMCAgICBPbGRfYWdlICAg T2ZmbGluZSAgICAgIC0gICAgICAgMQoxOTkgVURNQV9DUkNfRXJyb3JfQ291bnQgICAgMHgwMDNl ICAgMTAwICAgMTAwICAgMDAwICAgIE9sZF9hZ2UgICBBbHdheXMgICAgICAgLSAgICAgICAxCjIw MCBNdWx0aV9ab25lX0Vycm9yX1JhdGUgICAweDAwMGEgICAxMDAgICAxMDAgICAwMDAgICAgT2xk X2FnZSAgIEFsd2F5cyAgICAgICAtICAgICAgIDAKMjAxIFNvZnRfUmVhZF9FcnJvcl9SYXRlICAg IDB4MDAwYSAgIDEwMCAgIDA5OSAgIDAwMCAgICBPbGRfYWdlICAgQWx3YXlzICAgICAgIC0gICAg ICAgMAoKU01BUlQgRXJyb3IgTG9nIFZlcnNpb246IDEKTm8gRXJyb3JzIExvZ2dlZAoKU01BUlQg U2VsZi10ZXN0IGxvZyBzdHJ1Y3R1cmUgcmV2aXNpb24gbnVtYmVyIDEKTnVtICBUZXN0X0Rlc2Ny aXB0aW9uICAgIFN0YXR1cyAgICAgICAgICAgICAgICAgIFJlbWFpbmluZyAgTGlmZVRpbWUoaG91 cnMpICBMQkFfb2ZfZmlyc3RfZXJyb3IKIyAxICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRl ZDogcmVhZCBmYWlsdXJlICAgICAgIDIwJSAgICAgMTY0MTcgICAgICAgICAyMDE0MTAxMTc4CiMg MiAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQ6IHJlYWQgZmFpbHVyZSAgICAgICAyMCUg ICAgIDE2Mzk5ICAgICAgICAgMjAxNDA5OTM5NQojIDMgIFNob3J0IG9mZmxpbmUgICAgICAgQ29t cGxldGVkOiByZWFkIGZhaWx1cmUgICAgICAgMjAlICAgICAxNjM5MyAgICAgICAgIDIwMTQwOTkz OTUKIyA0ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZDogcmVhZCBmYWlsdXJlICAgICAg IDIwJSAgICAgMTYzNjkgICAgICAgICAyMDE0MDk5Mzk1CiMgNSAgU2hvcnQgb2ZmbGluZSAgICAg ICBDb21wbGV0ZWQ6IHJlYWQgZmFpbHVyZSAgICAgICAyMCUgICAgIDE2MzUyICAgICAgICAgMjAx NDA5OTM5NQojIDYgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkOiByZWFkIGZhaWx1cmUg ICAgICAgMjAlICAgICAxNjM0NCAgICAgICAgIDIwMTQwOTkzOTUKIyA3ICBFeHRlbmRlZCBvZmZs aW5lICAgIENvbXBsZXRlZDogcmVhZCBmYWlsdXJlICAgICAgIDkwJSAgICAgMTYzMjEgICAgICAg ICAyMDE0MDk5Mzk1CiMgOCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQ6IHJlYWQgZmFp bHVyZSAgICAgICAyMCUgICAgIDE2MzIwICAgICAgICAgMjAxNDA5OTM5NQojIDkgIFNob3J0IG9m ZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjI5NiAg ICAgICAgIC0KIzEwICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9y ICAgICAgIDAwJSAgICAgMTYyNzMgICAgICAgICAtCiMxMSAgU2hvcnQgb2ZmbGluZSAgICAgICBD b21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MjQ5ICAgICAgICAgLQojMTIg IFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAg ICAxNjIyNCAgICAgICAgIC0KIzEzICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBsZXRlZCB3aXRo b3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYyMDEgICAgICAgICAtCiMxNCAgU2hvcnQgb2ZmbGlu ZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2MTc3ICAgICAg ICAgLQojMTUgIEV4dGVuZGVkIG9mZmxpbmUgICAgQ29tcGxldGVkIHdpdGhvdXQgZXJyb3IgICAg ICAgMDAlICAgICAxNjE1OSAgICAgICAgIC0KIzE2ICBTaG9ydCBvZmZsaW5lICAgICAgIENvbXBs ZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYxNTMgICAgICAgICAtCiMxNyAgU2hv cnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAwMCUgICAgIDE2 MTI5ICAgICAgICAgLQojMTggIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVkIHdpdGhvdXQg ZXJyb3IgICAgICAgMDAlICAgICAxNjEwNSAgICAgICAgIC0KIzE5ICBTaG9ydCBvZmZsaW5lICAg ICAgIENvbXBsZXRlZCB3aXRob3V0IGVycm9yICAgICAgIDAwJSAgICAgMTYwODEgICAgICAgICAt CiMyMCAgU2hvcnQgb2ZmbGluZSAgICAgICBDb21wbGV0ZWQgd2l0aG91dCBlcnJvciAgICAgICAw MCUgICAgIDE2MDU3ICAgICAgICAgLQojMjEgIFNob3J0IG9mZmxpbmUgICAgICAgQ29tcGxldGVk IHdpdGhvdXQgZXJyb3IgICAgICAgMDAlICAgICAxNjAzMyAgICAgICAgIC0KClNNQVJUIFNlbGVj dGl2ZSBzZWxmLXRlc3QgbG9nIGRhdGEgc3RydWN0dXJlIHJldmlzaW9uIG51bWJlciAxCiBTUEFO ICBNSU5fTEJBICBNQVhfTEJBICBDVVJSRU5UX1RFU1RfU1RBVFVTCiAgICAxICAgICAgICAwICAg ICAgICAwICBOb3RfdGVzdGluZwogICAgMiAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcK ICAgIDMgICAgICAgIDAgICAgICAgIDAgIE5vdF90ZXN0aW5nCiAgICA0ICAgICAgICAwICAgICAg ICAwICBOb3RfdGVzdGluZwogICAgNSAgICAgICAgMCAgICAgICAgMCAgTm90X3Rlc3RpbmcKU2Vs ZWN0aXZlIHNlbGYtdGVzdCBmbGFncyAoMHgwKToKICBBZnRlciBzY2FubmluZyBzZWxlY3RlZCBz cGFucywgZG8gTk9UIHJlYWQtc2NhbiByZW1haW5kZXIgb2YgZGlzay4KSWYgU2VsZWN0aXZlIHNl bGYtdGVzdCBpcyBwZW5kaW5nIG9uIHBvd2VyLXVwLCByZXN1bWUgYWZ0ZXIgMCBtaW51dGUgZGVs YXkuCgo= --e89a8fb1ffa4f8daf904b8f1a3b1-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:03:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98DFA106566C for ; Tue, 14 Feb 2012 20:03:02 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 27F248FC18 for ; Tue, 14 Feb 2012 20:03:01 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1EK2x1r020541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 07:03:00 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q1EK2xt5029887; Wed, 15 Feb 2012 07:02:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q1EK2xa6029886; Wed, 15 Feb 2012 07:02:59 +1100 (EST) (envelope-from peter) Date: Wed, 15 Feb 2012 07:02:58 +1100 From: Peter Jeremy To: Gary Palmer Message-ID: <20120214200258.GA29641@server.vk2pj.dyndns.org> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <20120213132821.GA78733@in-addr.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 14 Feb 2012 20:03:02 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Feb-13 08:28:21 -0500, Gary Palmer wrote: >The filesystem is the *BEST* place to do caching. It knows what metadata >is most effective to cache and what other data (e.g. file contents) doesn't >need to be cached. Agreed. > Any attempt to do this in layers between the FS and >the disk won't achieve the same gains as a properly written filesystem.=20 Agreed - but traditionally, Unix uses this approach via block devices. For various reasons, FreeBSD moved caching into UFS and removed block devices. Unfortunately, this means that any FS that wants caching has to implement its own - and currently only UFS & ZFS do. What would be nice is a generic caching subsystem that any FS can use - similar to the old block devices but with hooks to allow the FS to request read-ahead, advise of unwanted blocks and ability to flush dirty blocks in a requested order with the equivalent of barriers (request Y will not occur until preceeding request X has been committed to stable media). This would allow filesystems to regain the benefits of block devices with minimal effort and then improve performance & cache efficiency with additional work. One downside of the "each FS does its own caching" in that the caches are all separate and need careful integration into the VM subsystem to prevent starvation (eg past problems with UFS starving ZFS L2ARC). --=20 Peter Jeremy --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk86vfIACgkQ/opHv/APuIdhKwCfaIq3Q2Xfl2l+4Qknp1n4f2yW WHgAn1pewFdOWd0/XLeEDKT27rVux2Ab =yehn -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:06:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B6F31065673 for ; Tue, 14 Feb 2012 20:06:45 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4CE8FC13 for ; Tue, 14 Feb 2012 20:06:44 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa03 [127.0.0.1]) by ltcfislmsgpa03.fnfis.com (8.14.4/8.14.4) with SMTP id q1EJpsH4026724; Tue, 14 Feb 2012 14:06:40 -0600 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com with ESMTP id 12yx4wg1t6-16 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 14:06:38 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 14:05:30 -0600 From: Devin Teske To: "'Kevin Oberman'" References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> In-Reply-To: Date: Tue, 14 Feb 2012 12:05:31 -0800 Message-ID: <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHpLgw2N43SAX2EkCOmVhPWC2ZpSwJNZ8ORAfwXlJcCVCvdvQKmrcmqAYxp73mVrcSM0A== Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_04:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Content-Type: text/plain; charset="iso-8859-1" Cc: 'Bruce Cran' , 'FreeBSD Stable Mailing List' , 'Joe Holden' , 'Alex Samorukov' , 'Ian Smith' Subject: RE: New BSD Installer 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, 14 Feb 2012 20:06:45 -0000 > -----Original Message----- > From: Kevin Oberman [mailto:kob6558@gmail.com] > Sent: Tuesday, February 14, 2012 11:51 AM > To: Devin Teske > Cc: Ian Smith; Bruce Cran; Alex Samorukov; Joe Holden; FreeBSD Stable Mai= ling > List > Subject: Re: New BSD Installer >=20 > On Tue, Feb 14, 2012 at 9:43 AM, Devin Teske > wrote: > > > > > >> -----Original Message----- > >> From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > >> stable@freebsd.org] On Behalf Of Ian Smith > >> Sent: Tuesday, February 14, 2012 9:15 AM > >> To: Bruce Cran > >> Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov > >> Subject: Re: New BSD Installer > >> > >> Strangely, the big push to GPT partitions was oft said to be because M= BR > >> slices provided too few partitions. > > > > That's part of it (no pun intended). > > > > The other big deal is that you can't exceed 2TB on a single primary partition. > > > > > >> I never found 4 * 6 much of a limit > >> myself, and now the default install makes a Linux-like single partitio= n, > >> rendering dump & restore more or less unusable or at least impractical, > > > > I'm with you on this one. I really don't like the single-"/" setup. > > > > > >> while booting multiple systems on GPT also seems to require Linux tool= s. > >> > >> I don't know whether this move away from BSD traditional filesystem > >> partitioning (/, /var, /usr etc) to Linux-style came down from Core On > >> High or is just the prerogative of installer-writers? =A0Jordan was bo= th > >> the latter and a big part of the former for many years, but I guess > >> that's something that can be reverted if people feel to do so. > >> > > > > Maybe a vote should be taken. There's about 12 votes in this office here alone > > for putting the partition scheme back the way it was (Colin Percival ha= d a great > > formula for determining partition sizes). >=20 > I suggest that both be implemented, which looks to the untrained eye > as a straight-forward thing to implement, and then the install ask if > a single partition or a traditional multi-partition system should be > installed. I prefer multi and use that on all of my systems. >=20 > I also really prefer GPT for a variety of reasons, but we need better > tools to support things. I miss booteasy. Yes, you can get it to boot > from a different partition, but it is a pain. I deal with it by > putting FreeBSD on one disk and Windows on another when I want a > dual-boot system. I put the MBR formatted (Windows) is first in the > boot order, so I can just hit F5 to boot the FreeBSD disk. >=20 > This works for me, but I suspect that lots of people would prefer > having multiple OSes on a single disk...especially when it's a single > spindle laptop. (I suspect laptops are more commonly dual-boot than > most any other platform.) >=20 > As for fdisk and bsdlabel, I'm happy to see both go. They have a > horrid user interface and require a calculator to get right. Yes, I > use them, but only because there is no other way to do some things. > (sade(8) comes closer all of the time, though.) Please don't get rid of fdisk or bsdlabel as they are (and forever will be) required to do things like: 1. scripted formatting of a thumb drive 2. automated probing of disk information (fdisk -p) 3. Other tasks that are not suitably handled by curses-based utilities For example, the following command will create a second Windows partition o= n a thumb drive without user interaction: echo "p 2 0x0c * *" | fdisk -f - /dev/da0 If you take away fdisk, how am I supposed to achieve the above? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:15:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58F69106567B for ; Tue, 14 Feb 2012 20:15:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 3913A8FC0A for ; Tue, 14 Feb 2012 20:15:33 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta15.emeryville.ca.mail.comcast.net with comcast id Zvo51i0031eYJf8AFwFZpB; Tue, 14 Feb 2012 20:15:33 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta19.emeryville.ca.mail.comcast.net with comcast id ZwFX1i01J1t3BNj01wFYdX; Tue, 14 Feb 2012 20:15:33 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9D6AC102C1E; Tue, 14 Feb 2012 12:15:31 -0800 (PST) Date: Tue, 14 Feb 2012 12:15:31 -0800 From: Jeremy Chadwick To: Devin Teske Message-ID: <20120214201531.GA5698@icarus.home.lan> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Bruce Cran' , 'Joe Holden' , 'FreeBSD Stable Mailing List' , 'Ian Smith' , 'Alex Samorukov' Subject: Re: New BSD Installer 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, 14 Feb 2012 20:15:34 -0000 On Tue, Feb 14, 2012 at 12:05:31PM -0800, Devin Teske wrote: > Please don't get rid of fdisk or bsdlabel as they are (and forever will be) > required to do things like: > > 1. scripted formatting of a thumb drive Can't this be done with gpart(8)? There are scripts all over the web and on the lists here showing people using it for that purpose. It doesn't require use of GPT either. > 2. automated probing of disk information (fdisk -p) Can't this be accomplished with "gpart list"? Yes I know the man page doesn't appear to have it documented, but it's there. Furthermore, fdisk -p shows silly things like C/H/S nomenclature; do you really use this? Do you have boards which don't support even the most basic 28-bit LBA addressing? > 3. Other tasks that are not suitably handled by curses-based utilities > > ... > > For example, the following command will create a second Windows partition on a > thumb drive without user interaction: > > echo "p 2 0x0c * *" | fdisk -f - /dev/da0 > > If you take away fdisk, how am I supposed to achieve the above? Again: gpart(8). And before you complain: yes, I am in full agreement that introduction of gpart into the fray should have probably been "more public". The syntax of the gpart commands takes some getting used to as well (some things are hardly intuitive, but eventually make sense once you see them in use). I'm happy to use gpart for scripting, while fdisk/bsdlabel are like pulling teeth. That said, like others, I would be thrilled to see fdisk and bsdlabel/disklabel disappear. However, for that to happen, I really expect gpart to be better documented. Hell, all of the GEOM-based g* utilities should be implemented slightly... differently. It's hard to explain what I mean by this. Play with the geom(8) command sometime to see what I mean. "geom list" says to use "geom list list", etc.. Once you delve into the code to see how it all works it then starts making more sense why the utilities behave this way, but it's completely and entirely non-intuitive to anyone not already familiar with it. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:19:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 703451065678 for ; Tue, 14 Feb 2012 20:19:03 +0000 (UTC) (envelope-from oscarmpp@googlemail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3638A8FC14 for ; Tue, 14 Feb 2012 20:19:02 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so515253obc.13 for ; Tue, 14 Feb 2012 12:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pK+bLFUPb3Ld2+U9lxz2uWeYGLawSh+QLOKzCx5Bvuc=; b=Gd9bG5r9hCSu5bi4osj/uqT6HC6hr6bX/ZLSiL1nPTMABuIkgwt5vHdvurt1DpyFd3 3Gfd5gSs7SIbFnmpnzX8pOS52j9TYnNDYnDJOghSmTjb6oGYm4BvXlkC059yb95u+a33 R3kyb2ExPwQvIxXe+hOKiXvF9PbKAq5kBDN6Y= MIME-Version: 1.0 Received: by 10.60.26.133 with SMTP id l5mr1323641oeg.22.1329250742670; Tue, 14 Feb 2012 12:19:02 -0800 (PST) Received: by 10.60.78.36 with HTTP; Tue, 14 Feb 2012 12:19:02 -0800 (PST) In-Reply-To: <20120214205143.2a6b9c87@zelda.sugioarto.com> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <4F3AB4F0.9010002@omnilan.de> <20120214205143.2a6b9c87@zelda.sugioarto.com> Date: Tue, 14 Feb 2012 21:19:02 +0100 Message-ID: From: Oscar Prieto To: Martin Sugioarto Content-Type: text/plain; charset=ISO-8859-1 Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 20:19:03 -0000 Thank you Jeremy, i'm already checking your links. When i installed smartd i configured a daily short test and a weekly long one for all the drives while the machine remains mostly unused, never thought it could be a problem reading the documentation and info around. # /usr/local/etc/smartd.conf /dev/ada0 -a -o on -S on -s (S/../.././03|L/../../2/07) /dev/ada1 -a -o on -S on -s (S/../.././04|L/../../3/07) /dev/ada2 -a -o on -S on -s (S/../.././05|L/../../4/07) /dev/ada3 -a -o on -S on -s (S/../.././06|L/../../5/07) I'll remove the checks, do you advice for removing the daemon altogether? On Tue, Feb 14, 2012 at 8:51 PM, Martin Sugioarto wrote: > Am Tue, 14 Feb 2012 20:24:32 +0100 > schrieb Harald Schmalzbauer : > >> I guess it's always the firmware of the EcoGreen models which cause >> these problems. Your drive isn't EG... >> I don't remember exactly the different model numbers, but I'm sure >> they were all EcoGreen. The lower power consumption was the reason to >> choose these specific drives (different capacities and F2/F3 series >> tried), with acceptable performance loss - I thought. But it turned >> out that EcoGreen and NCQ as well as RAIDZ demands dont' fit >> together... > > Hi, > > I intentionally did not buy any Eco or Green model because I don't like > them (Load_Cycle_Count bugs and so on). I realized, I like to use 1 Watt > more power but have the performance doubled. > > -- > Martin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:31:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A507106566C for ; Tue, 14 Feb 2012 20:31:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by mx1.freebsd.org (Postfix) with ESMTP id 303E88FC0A for ; Tue, 14 Feb 2012 20:31:25 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id Zo0Y1i0061ei1Bg5AwXSfp; Tue, 14 Feb 2012 20:31:26 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.westchester.pa.mail.comcast.net with comcast id ZwXQ1i00f1t3BNj3kwXQuN; Tue, 14 Feb 2012 20:31:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1DA03102C1E; Tue, 14 Feb 2012 12:31:23 -0800 (PST) Date: Tue, 14 Feb 2012 12:31:23 -0800 From: Jeremy Chadwick To: Oscar Prieto Message-ID: <20120214203123.GA5959@icarus.home.lan> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <4F3AB4F0.9010002@omnilan.de> <20120214205143.2a6b9c87@zelda.sugioarto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Martin Sugioarto , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 20:31:26 -0000 On Tue, Feb 14, 2012 at 09:19:02PM +0100, Oscar Prieto wrote: > Thank you Jeremy, i'm already checking your links. > > When i installed smartd i configured a daily short test and a weekly > long one for all the drives while the machine remains mostly unused, > never thought it could be a problem reading the documentation and info > around. > > # /usr/local/etc/smartd.conf > /dev/ada0 -a -o on -S on -s (S/../.././03|L/../../2/07) > /dev/ada1 -a -o on -S on -s (S/../.././04|L/../../3/07) > /dev/ada2 -a -o on -S on -s (S/../.././05|L/../../4/07) > /dev/ada3 -a -o on -S on -s (S/../.././06|L/../../5/07) The problem is that, quite honestly, these do you zero good. All it does is make a mess (per se) of the SMART self-test log. Take for example your situation with ada3: smartd(8) told you that the number of pending sectors increased to 5, and uncorrected increased to 1. That's really all you need to know at that point. If you want to know the LBA numbers which are problematic, you can manually intervene. The point is: the drive itself is going to notice problematic or bad sectors quicker than periodic short or long or surface scan tests will. Let the drive do its thing normally and only use SMART tests when there's indication something is wrong. > I'll remove the checks, do you advice for removing the daemon altogether? smartd(8) is useful because it keeps track of attributes which change in value and logs data to syslog (if I remember right), thus you have an exact time/date when an attribute changed. This is especially useful for things pertaining to sector/physical media problems. As such, I tend to recommend folks using smartd(8) properly tune their smartd.conf to only monitor specific attributes. This varies from drive to drive, but the key ones are things like attributes 5, 10, 11, 192, 193, 194 (if you want temperature logging), 196, 197, 198, 199, and 200. I'm speaking strictly for Western Digital disks here. The stock defaults, if I remember right, are to "monitor everything", which really doesn't work well given that so many vendors encode their RAW_VALUE fields in proprietary/vendor-specific formats. People will often monitor things like the Hardware_ECC_Recovered attribute and start "freaking out" once day when the value goes from 0 to 838938239 or something larger. Attribute data formats are not part of the ATA standard, so vendors choose to encode them. Plus, not many admins that I've run into (honest) know what that attribute actually means disk-wise (hint: it's 100% normal for sector ECC to happen at all times; magnetic media is not perfect, that's what the per-sector ECC section is for!) However: people don't understand what SMART attribute acquisition actually does behind the scenes -- it results in the disk having to read from the HPA area (not user accessible or within LBA regions), which means seeking + moving the arms to an area, reading, then reporting all of this back. Thus, it impacts I/O performance. This is why I don't use smartd(8) on any of our systems. But if I was to use it? I would have it poll maybe every 120 minutes, rather than every 30. It all depends on the system/load/etc.. I've seen people poll every 5 minutes (I think they're absolutely crazy/paranoid). Their systems, their problem. :-) Hope this helps. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 21:05:53 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 8ECE6106567A; Tue, 14 Feb 2012 21:05:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-150-251.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 268E7151DDE; Tue, 14 Feb 2012 21:05:24 +0000 (UTC) Message-ID: <4F3ACC91.7030104@FreeBSD.org> Date: Tue, 14 Feb 2012 13:05:21 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.1) Gecko/20120213 Thunderbird/10.0.1 MIME-Version: 1.0 To: Rick Macklem References: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Why won't 8.2 umount -f? 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, 14 Feb 2012 21:05:53 -0000 On 02/14/2012 08:39, Rick Macklem wrote: > I took a look and they seem to have been MFC'd. That's awesome! Thanks for your time on this. I guess we've got some upgrading to do. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 21:11:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 183CB106566B for ; Tue, 14 Feb 2012 21:11:38 +0000 (UTC) (envelope-from mandrews@bit0.com) Received: from magnum.bit0.com (magnum.bit0.com [IPv6:2604:e700:b0:1::200]) by mx1.freebsd.org (Postfix) with ESMTP id BE1788FC0A for ; Tue, 14 Feb 2012 21:11:37 +0000 (UTC) Received: from magnum.bit0.com (localhost [127.0.0.1]) by magnum.bit0.com (Postfix) with ESMTP id 07E49EBAF for ; Tue, 14 Feb 2012 16:11:37 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=bit0.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=boogity; bh=AZHd+fXiv NRdaxMSCvtuz4Gz7XZ1dmfRpfQXMiLuJ5M=; b=YQX050HTmwULALnzc30aGlX6C tmhxasKJITGw42FrM92lBZPLuhNDv7/zighT1LRMa1/q3Xo+yrqPLlbg00gpO4Fp tHNrfZPjfFPCdzQbCf/94djqzbZycvNlIsX73C3imiXhyVbuuCv7m7CoRQogNSfr 2xVrXtNkOBmwy93whY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bit0.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=boogity; b=qii FiwgGR0NQEnBzL/SN5oBcZ5UdERk7gbUBUw5ox3f5vofbIXAGm2d4YPukmOE8D+n esAfjri2jwGQpXnlTVZqjZByaY9tMad5Qv0xdMO4NeTWSlARQDddNOZ2rztHG2lg c06bJAKAnn/R6pv+V8wI6Lph/Tbtd6N/yBr4Z1Ig= Received: from [IPv6:2001:470:1f11:c3c:230:1bff:febc:8604] (unknown [IPv6:2001:470:1f11:c3c:230:1bff:febc:8604]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by magnum.bit0.com (Postfix) with ESMTPSA id C9985EBAE for ; Tue, 14 Feb 2012 16:11:36 -0500 (EST) Message-ID: <4F3ACDE7.8060003@bit0.com> Date: Tue, 14 Feb 2012 16:11:03 -0500 From: Mike Andrews User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> In-Reply-To: <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: New BSD Installer 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, 14 Feb 2012 21:11:38 -0000 On 2/14/2012 3:05 PM, Devin Teske wrote: > Please don't get rid of fdisk or bsdlabel as they are (and forever will be) > required to do things like: > > 1. scripted formatting of a thumb drive > > 2. automated probing of disk information (fdisk -p) > > 3. Other tasks that are not suitably handled by curses-based utilities > > For example, the following command will create a second Windows partition on a > thumb drive without user interaction: > > echo "p 2 0x0c * *" | fdisk -f - /dev/da0 > > If you take away fdisk, how am I supposed to achieve the above? /sbin/gpart add -t 12 -i 2 da0 (Untested, but that should work...) gpart is very scriptable, and still handles MBR and bsdlabel partitions if you need to work with removable media or volumes that will never be larger than 2 TB. "gpart list" and "gpart show" would get you all the machine-parsable stuff you'd ever need. The 2 TB limit is *the* reason to move from MBR+bsdlabel to GPT though. Even without RAID, 3 TB disks exist already. :) With FreeBSD's boot code, you don't even need an EFI-capable machine to boot from a GPT-partitioned device. For non-removable media, it's time to move on. Really. :) Even on smaller 250 GB disks, I'm using GPT just because there's no reason not to... it's just cleaner and it was easier to write gpart scripts than it was to script fdisk/bsdlabel scripts anyway. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 22:01:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D28D1065689; Tue, 14 Feb 2012 22:01:31 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (centre.keltia.net [IPv6:2a01:240:fe5c::41]) by mx1.freebsd.org (Postfix) with ESMTP id 533878FC15; Tue, 14 Feb 2012 22:01:31 +0000 (UTC) Received: from lonrach-2.local (unknown [IPv6:2a01:e34:ee87:4a00:d69a:20ff:fed0:3a83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix/TLS) with ESMTPSA id 4761912FF3; Tue, 14 Feb 2012 23:01:27 +0100 (CET) Date: Tue, 14 Feb 2012 23:01:55 +0100 From: Ollivier Robert To: "Kenneth D. Merry" Message-ID: <20120214220155.GB35565@lonrach-2.local> References: <20120202191105.GA55719@nargothrond.kdm.org> <20120213140844.GA61050@roberto-aw.eurocontrol.fr> <20120214164903.GA63724@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120214164903.GA63724@nargothrond.kdm.org> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: LSI supported mps(4) driver in stable/9 and stable/8 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, 14 Feb 2012 22:01:31 -0000 According to Kenneth D. Merry: > So it is perfectly fine to run the driver in stable/9 or stable/8 without > the CAM changes. Excellent, thank you Ken. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 22:04:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53675106566C for ; Tue, 14 Feb 2012 22:04:59 +0000 (UTC) (envelope-from hugo@barafranca.com) Received: from mail.barafranca.com (mail.barafranca.com [67.213.67.47]) by mx1.freebsd.org (Postfix) with ESMTP id 210058FC0A for ; Tue, 14 Feb 2012 22:04:58 +0000 (UTC) Received: from localhost (unknown [172.16.100.24]) by mail.barafranca.com (Postfix) with ESMTP id 80D542027; Tue, 14 Feb 2012 22:04:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at barafranca.com Received: from mail.barafranca.com ([172.16.100.24]) by localhost (mail.barafranca.com [172.16.100.24]) (amavisd-new, port 10024) with ESMTP id wqEvM1aMt-cK; Tue, 14 Feb 2012 22:04:19 +0000 (UTC) Received: from [192.168.1.1] (a89-152-168-54.cpe.netcabo.pt [89.152.168.54]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.barafranca.com (Postfix) with ESMTPSA id 20CEF201F; Tue, 14 Feb 2012 22:04:18 +0000 (UTC) Message-ID: <4F3ADA5E.4060800@barafranca.com> Date: Tue, 14 Feb 2012 22:04:14 +0000 From: Hugo Silva User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Freddie Cash References: <4F3A9237.5080901@barafranca.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: glebius@freebsd.org, freebsd-stable@freebsd.org Subject: Re: CARP carpdev 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, 14 Feb 2012 22:04:59 -0000 On 02/14/12 17:33, Freddie Cash wrote: > On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote: >> Looks like there's been conversations about porting this to FreeBSD since at >> least 2007. >> >> Are there any plans to have ifconfig carpdev available in 9.0-STABLE? > > CARP support has been redone in 10-CURRENT, removing the whole "carp0" > pseudo-interface support, and just enabling the CARP protocol on the > existing network interfaces. This includes the equivalent of "carpdev" > support. > > Search the -current archives for more information, CFT, and so on. > > I don't recall seeing anything about specific plans to MFC to > stable/9, but could be mis-remembering things. > http://svnweb.freebsd.org/base?view=revision&revision=228571 The single IP limitation may be a problem in some locations.. Did not find anything about a possible MFC either. glebius@ is cc'd, perhaps he can add something, but based on http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been MFCd (there's a primer for the new carp in current's UPDATING)\ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 22:34:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98527106566B for ; Tue, 14 Feb 2012 22:34:19 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 37B6C8FC17 for ; Tue, 14 Feb 2012 22:34:19 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 9FF2339844; Tue, 14 Feb 2012 23:15:27 +0100 (CET) Date: Tue, 14 Feb 2012 23:15:27 +0100 From: Victor Balada Diaz To: Harald Schmalzbauer Message-ID: <20120214221527.GT2010@equilibrium.bsdes.net> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3A971F.9040407@omnilan.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 22:34:19 -0000 On Tue, Feb 14, 2012 at 06:17:19PM +0100, Harald Schmalzbauer wrote: > schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): > > On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: > >> Hello, > >> > >> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still > >> persists on FreeBSD 9.0 release. > >> > >> Switching from ahci to ataahci resolved the problem for me too. > >> > >> I'm using gmirror for swap, system is on a zpool and the problem first > >> occurred during a zpool scrub, but it is easily reproducible with dd. > >> > >> The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} > >> of=/dev/null is not an issue. > >> Sometimes I need to power off the server because after a reboot one disk > >> is still missing. > >> > >> I really would like to help in this issue, so let me know if you need > >> any more information. > > I find it interesting that, at least so far, the only people reporting > > problems of this type with the ahci.ko driver are people using Samsung > > disks. The only difference is that your models are F1s while the OPs > > are F2s. > > I saw such timeouts long ago and mav@ had a look at my postings and he > mentioned it could be a NCQ problem. > I suspected the disks firmware. > I never tracked it down further, because after replacing the Samsung (F3 > in that case) disks with hitachi ones solved all my problems and gave a > big performance kick as well (with zfs). > You can find the discussion here: > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html > You gave me a good idea: try to disable NCQ and see if that's the fault. So i went and applied the attached patch. After it, i can no longer reproduce the issue with ahci driver. I know this is not a solution because it disables NCQ at controller level instead of disk level, but at least we know for sure where the problem is. I think the solution would be to add a new quirk ADA_Q_NONCQ in sys/cam/ata/ata_da.c. Quirks infraestructure is already built, so adding a new quirk for this seems easy. Is someone interested? Do you think there is a better solution? If someone is interested i can build a patch to add ADA_Q_NONCQ quirk and add my drives to it. Regards. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 22:39:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55B22106566B for ; Tue, 14 Feb 2012 22:39:29 +0000 (UTC) (envelope-from oscarmpp@googlemail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E1DBD8FC1C for ; Tue, 14 Feb 2012 22:39:28 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so699956obc.13 for ; Tue, 14 Feb 2012 14:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ss7OtR6TlBdvcXwvDbB+U/oDpivClUUsoZWWNVVt4PE=; b=aYWfqv7Tk74LcIeKIlOHNhnDDAm+uT1V2NnrRzK+iVZt//rTqD5vGNypSe78ZI/KQL vK6qArH4RW3eY7j0Ear0nI4NFM/t2NRNIWe9PAdzv1ISs/xVwO8U0jhzIrPetEhwCPtz aY+GZpGmnmueRrd8vU+f3Fl916PEq5dkOuprE= MIME-Version: 1.0 Received: by 10.182.231.97 with SMTP id tf1mr16697775obc.32.1329259168311; Tue, 14 Feb 2012 14:39:28 -0800 (PST) Received: by 10.60.78.36 with HTTP; Tue, 14 Feb 2012 14:39:28 -0800 (PST) In-Reply-To: <20120214203123.GA5959@icarus.home.lan> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <4F3AB4F0.9010002@omnilan.de> <20120214205143.2a6b9c87@zelda.sugioarto.com> <20120214203123.GA5959@icarus.home.lan> Date: Tue, 14 Feb 2012 23:39:28 +0100 Message-ID: From: Oscar Prieto To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org, Martin Sugioarto , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 22:39:29 -0000 Thank you again Jeremy, sure it helps! On Tue, Feb 14, 2012 at 9:31 PM, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 09:19:02PM +0100, Oscar Prieto wrote: >> Thank you Jeremy, i'm already checking your links. >> >> When i installed smartd i configured a daily short test and a weekly >> long one for all the drives while the machine remains mostly unused, >> never thought it could be a problem reading the documentation and info >> around. >> >> # /usr/local/etc/smartd.conf >> /dev/ada0 -a -o on -S on -s (S/../.././03|L/../../2/07) >> /dev/ada1 -a -o on -S on -s (S/../.././04|L/../../3/07) >> /dev/ada2 -a -o on -S on -s (S/../.././05|L/../../4/07) >> /dev/ada3 -a -o on -S on -s (S/../.././06|L/../../5/07) > > The problem is that, quite honestly, these do you zero good. =A0All it do= es > is make a mess (per se) of the SMART self-test log. > > Take for example your situation with ada3: smartd(8) told you that the > number of pending sectors increased to 5, and uncorrected increased to > 1. =A0That's really all you need to know at that point. =A0If you want to > know the LBA numbers which are problematic, you can manually intervene. > > The point is: the drive itself is going to notice problematic or bad > sectors quicker than periodic short or long or surface scan tests will. > Let the drive do its thing normally and only use SMART tests when > there's indication something is wrong. > >> I'll remove the checks, do you advice for removing the daemon altogether= ? > > smartd(8) is useful because it keeps track of attributes which change in > value and logs data to syslog (if I remember right), thus you have an > exact time/date when an attribute changed. =A0This is especially useful > for things pertaining to sector/physical media problems. > > As such, I tend to recommend folks using smartd(8) properly tune their > smartd.conf to only monitor specific attributes. =A0This varies from driv= e > to drive, but the key ones are things like attributes 5, 10, 11, 192, > 193, 194 (if you want temperature logging), 196, 197, 198, 199, and 200. > I'm speaking strictly for Western Digital disks here. > > The stock defaults, if I remember right, are to "monitor everything", > which really doesn't work well given that so many vendors encode their > RAW_VALUE fields in proprietary/vendor-specific formats. =A0People will > often monitor things like the Hardware_ECC_Recovered attribute and start > "freaking out" once day when the value goes from 0 to 838938239 or > something larger. =A0Attribute data formats are not part of the ATA > standard, so vendors choose to encode them. =A0Plus, not many admins that > I've run into (honest) know what that attribute actually means > disk-wise (hint: it's 100% normal for sector ECC to happen at all times; > magnetic media is not perfect, that's what the per-sector ECC section is > for!) > > However: people don't understand what SMART attribute acquisition > actually does behind the scenes -- it results in the disk having to read > from the HPA area (not user accessible or within LBA regions), which > means seeking + moving the arms to an area, reading, then reporting all > of this back. =A0Thus, it impacts I/O performance. =A0This is why I don't > use smartd(8) on any of our systems. =A0But if I was to use it? =A0I woul= d > have it poll maybe every 120 minutes, rather than every 30. =A0It all > depends on the system/load/etc.. =A0I've seen people poll every 5 minutes > (I think they're absolutely crazy/paranoid). =A0Their systems, their > problem. =A0:-) > > Hope this helps. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 jdc@parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.= parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mountain Vie= w, CA, US | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 PGP 4BD= 6C0CB | > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:10:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B59C1065670 for ; Tue, 14 Feb 2012 23:10:03 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 47D078FC08 for ; Tue, 14 Feb 2012 23:10:02 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta13.emeryville.ca.mail.comcast.net with comcast id ZyCx1i0061ZMdJ4ADzA1UT; Tue, 14 Feb 2012 23:10:01 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id Zz9z1i0071t3BNj8cz9zTr; Tue, 14 Feb 2012 23:10:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CB2C5102C1E; Tue, 14 Feb 2012 15:09:58 -0800 (PST) Date: Tue, 14 Feb 2012 15:09:58 -0800 From: Jeremy Chadwick To: Victor Balada Diaz Message-ID: <20120214230958.GA8434@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120214221527.GT2010@equilibrium.bsdes.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 23:10:03 -0000 On Tue, Feb 14, 2012 at 11:15:27PM +0100, Victor Balada Diaz wrote: > On Tue, Feb 14, 2012 at 06:17:19PM +0100, Harald Schmalzbauer wrote: > > schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): > > > On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: > > >> Hello, > > >> > > >> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still > > >> persists on FreeBSD 9.0 release. > > >> > > >> Switching from ahci to ataahci resolved the problem for me too. > > >> > > >> I'm using gmirror for swap, system is on a zpool and the problem first > > >> occurred during a zpool scrub, but it is easily reproducible with dd. > > >> > > >> The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} > > >> of=/dev/null is not an issue. > > >> Sometimes I need to power off the server because after a reboot one disk > > >> is still missing. > > >> > > >> I really would like to help in this issue, so let me know if you need > > >> any more information. > > > I find it interesting that, at least so far, the only people reporting > > > problems of this type with the ahci.ko driver are people using Samsung > > > disks. The only difference is that your models are F1s while the OPs > > > are F2s. > > > > I saw such timeouts long ago and mav@ had a look at my postings and he > > mentioned it could be a NCQ problem. > > I suspected the disks firmware. > > I never tracked it down further, because after replacing the Samsung (F3 > > in that case) disks with hitachi ones solved all my problems and gave a > > big performance kick as well (with zfs). > > You can find the discussion here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html > > > > You gave me a good idea: try to disable NCQ and see if that's the fault. So > i went and applied the attached patch. After it, i can no longer reproduce > the issue with ahci driver. > > I know this is not a solution because it disables NCQ at controller level > instead of disk level, but at least we know for sure where the problem is. > > I think the solution would be to add a new quirk ADA_Q_NONCQ in sys/cam/ata/ata_da.c. > Quirks infraestructure is already built, so adding a new quirk for this seems > easy. > > Is someone interested? Do you think there is a better solution? > > If someone is interested i can build a patch to add ADA_Q_NONCQ quirk and add my drives > to it. I took a stab at this, but I don't feel confident this is the proper solution/method. I worry there's some sort of chicken-or-the-egg condition here (quirk setup/matching comes *after* SATA capabilities detection), or that it makes the code messier. Need mav@'s recommendations on this. Below is for RELENG_8. I should note I haven't tested if this works, or even compiles -- normally I don't provide such patches without testing so I apologise in advance / user beware. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | diff -ruN /usr/src/sys/cam/ata/ata_da.c src/sys/cam/ata/ata_da.c --- /usr/src/sys/cam/ata/ata_da.c 2012-02-10 17:22:25.000000000 -0800 +++ src/sys/cam/ata/ata_da.c 2012-02-14 15:07:07.988814133 -0800 @@ -90,7 +90,8 @@ typedef enum { ADA_Q_NONE = 0x00, - ADA_Q_4K = 0x01, + ADA_Q_4K = 0x01, /* 4k sectors */ + ADA_Q_NONCQ = 0x02, /* device has flaky NCQ support */ } ada_quirks; typedef enum { @@ -162,6 +163,11 @@ /*quirks*/ADA_Q_4K }, { + /* Samsung Spinpoint F2 EG (EcoGreen) drives */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "SAMSUNG HD154UI*", "*" }, + /*quirks*/ADA_Q_NONCQ, + }, + { /* Samsung Advanced Format (4k) drives */ { T_DIRECT, SIP_MEDIA_FIXED, "*", "SAMSUNG HD155UI*", "*" }, /*quirks*/ADA_Q_4K @@ -887,9 +893,6 @@ softc->flags |= ADA_FLAG_CAN_FLUSHCACHE; if (cgd->ident_data.support.command1 & ATA_SUPPORT_POWERMGT) softc->flags |= ADA_FLAG_CAN_POWERMGT; - if (cgd->ident_data.satacapabilities & ATA_SUPPORT_NCQ && - (cgd->inq_flags & SID_DMA) && (cgd->inq_flags & SID_CmdQue)) - softc->flags |= ADA_FLAG_CAN_NCQ; if (cgd->ident_data.support_dsm & ATA_SUPPORT_DSM_TRIM) { softc->flags |= ADA_FLAG_CAN_TRIM; softc->trim_max_ranges = TRIM_MAX_RANGES; @@ -916,6 +919,15 @@ else softc->quirks = ADA_Q_NONE; + /* + * Do not enable NCQ for devices which have the ADA_Q_NONCQ quirk. + */ + if (!(softc->quirks & ADA_Q_NONCQ)) { + if (cgd->ident_data.satacapabilities & ATA_SUPPORT_NCQ && + (cgd->inq_flags & SID_DMA) && (cgd->inq_flags & SID_CmdQue)) + softc->flags |= ADA_FLAG_CAN_NCQ; + } + bzero(&cpi, sizeof(cpi)); xpt_setup_ccb(&cpi.ccb_h, periph->path, CAM_PRIORITY_NONE); cpi.ccb_h.func_code = XPT_PATH_INQ; From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:33:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62A5C106564A for ; Tue, 14 Feb 2012 23:33:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 347DE8FC16 for ; Tue, 14 Feb 2012 23:33:33 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1ENXUlI099936 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 15:33:33 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3AEFA5.1020906@freebsd.org> Date: Tue, 14 Feb 2012 15:35:01 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Kevin Oberman References: <4F3A1A19.7010803@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: freebsd 9-stable TOP problem from around Jan 10 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, 14 Feb 2012 23:33:34 -0000 On 2/14/12 10:38 AM, Kevin Oberman wrote: > On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer wrote: >> Has anyone else seen a problem with top -H -S? >> >> after a short while the screen gets more and more corrupted.. >> >> hitting ^L or turning off S& H modes helps .. for a while. >> >> If this is a known fixed problem, let me know but I need to co-ordinate with >> others >> to upgrade the machine in question. > Not seeing it here on 9-stable. Could it be a display issue? I am > using gnome-terminal with TERM defined as 'xterm'. yeah I'm on a mac with iterm, but running through 'screen' . it's never been a problem before.. just since we upgraded to 9-stable. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:33:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558F91065700; Tue, 14 Feb 2012 23:33:55 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1C81E8FC12; Tue, 14 Feb 2012 23:33:54 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id q1ENQO1m005548; Tue, 14 Feb 2012 17:33:53 -0600 Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa02.fnfis.com with ESMTP id 1300fgg60x-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 17:33:53 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 17:33:52 -0600 From: Devin Teske To: "'Doug Barton'" , "'Rick Macklem'" References: <511955909.1353483.1329237591261.JavaMail.root@erie.cs.uoguelph.ca> <4F3ACC91.7030104@FreeBSD.org> In-Reply-To: <4F3ACC91.7030104@FreeBSD.org> Date: Tue, 14 Feb 2012 15:33:58 -0800 Message-ID: <09bf01cceb71$207a2790$616e76b0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSc4LeLj7QlldhfqGzt105NKM1bAJFPsjSlx/QMhA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_06:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: freebsd-fs@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: RE: Why won't 8.2 umount -f? 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, 14 Feb 2012 23:33:55 -0000 > -----Original Message----- > From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] > On Behalf Of Doug Barton > Sent: Tuesday, February 14, 2012 1:05 PM > To: Rick Macklem > Cc: freebsd-fs@FreeBSD.org; freebsd-stable@FreeBSD.org > Subject: Re: Why won't 8.2 umount -f? > > On 02/14/2012 08:39, Rick Macklem wrote: > > I took a look and they seem to have been MFC'd. > > That's awesome! Thanks for your time on this. I guess we've got some > upgrading to do. > +1 Awaiting 8.3 with bated breath! -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:34:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 817E31065849; Tue, 14 Feb 2012 23:34:29 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id CE6138FC12; Tue, 14 Feb 2012 23:34:28 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id C641439844; Wed, 15 Feb 2012 00:34:20 +0100 (CET) Date: Wed, 15 Feb 2012 00:34:20 +0100 From: Victor Balada Diaz To: Jeremy Chadwick Message-ID: <20120214233420.GU2010@equilibrium.bsdes.net> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ZInfyf7laFu/Kiw7" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120214230958.GA8434@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 14 Feb 2012 23:34:29 -0000 --ZInfyf7laFu/Kiw7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Feb 14, 2012 at 03:09:58PM -0800, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 11:15:27PM +0100, Victor Balada Diaz wrote: > > On Tue, Feb 14, 2012 at 06:17:19PM +0100, Harald Schmalzbauer wrote: > > > schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): > > > > On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: > > > >> Hello, > > > >> > > > >> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still > > > >> persists on FreeBSD 9.0 release. > > > >> > > > >> Switching from ahci to ataahci resolved the problem for me too. > > > >> > > > >> I'm using gmirror for swap, system is on a zpool and the problem first > > > >> occurred during a zpool scrub, but it is easily reproducible with dd. > > > >> > > > >> The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} > > > >> of=/dev/null is not an issue. > > > >> Sometimes I need to power off the server because after a reboot one disk > > > >> is still missing. > > > >> > > > >> I really would like to help in this issue, so let me know if you need > > > >> any more information. > > > > I find it interesting that, at least so far, the only people reporting > > > > problems of this type with the ahci.ko driver are people using Samsung > > > > disks. The only difference is that your models are F1s while the OPs > > > > are F2s. > > > > > > I saw such timeouts long ago and mav@ had a look at my postings and he > > > mentioned it could be a NCQ problem. > > > I suspected the disks firmware. > > > I never tracked it down further, because after replacing the Samsung (F3 > > > in that case) disks with hitachi ones solved all my problems and gave a > > > big performance kick as well (with zfs). > > > You can find the discussion here: > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html > > > > > > > You gave me a good idea: try to disable NCQ and see if that's the fault. So > > i went and applied the attached patch. After it, i can no longer reproduce > > the issue with ahci driver. > > > > I know this is not a solution because it disables NCQ at controller level > > instead of disk level, but at least we know for sure where the problem is. > > > > I think the solution would be to add a new quirk ADA_Q_NONCQ in sys/cam/ata/ata_da.c. > > Quirks infraestructure is already built, so adding a new quirk for this seems > > easy. > > > > Is someone interested? Do you think there is a better solution? > > > > If someone is interested i can build a patch to add ADA_Q_NONCQ quirk and add my drives > > to it. > > I took a stab at this, but I don't feel confident this is the proper > solution/method. I worry there's some sort of chicken-or-the-egg > condition here (quirk setup/matching comes *after* SATA capabilities > detection), or that it makes the code messier. Need mav@'s > recommendations on this. > > Below is for RELENG_8. I should note I haven't tested if this works, or > even compiles -- normally I don't provide such patches without testing > so I apologise in advance / user beware. You're amazingly fast. Thanks for all your help :) You start applying the quirks before snprintf(announce_buf, sizeof(announce_buf), "kern.cam.ada.%d.quirks", periph->unit_number); quirks = softc->quirks; TUNABLE_INT_FETCH(announce_buf, &quirks); So you're breaking quirk setting at boot time. See my attached patch. I can confirm it works for me. Regards. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. --ZInfyf7laFu/Kiw7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ata_da.patch" --- ata_da.c 2012-02-14 22:17:54.000000000 +0100 +++ ata_da.c 2012-02-14 22:58:05.000000000 +0100 @@ -91,6 +91,7 @@ typedef enum { ADA_Q_NONE = 0x00, ADA_Q_4K = 0x01, + ADA_Q_NONCQ = 0x02, } ada_quirks; typedef enum { @@ -162,6 +163,14 @@ /*quirks*/ADA_Q_4K }, { + /* + * Samsung have NCQ broken: + * http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/066168.html + */ + { T_DIRECT, SIP_MEDIA_FIXED, "*", "SAMSUNG HD154UI*", "*" }, + /*quirks*/ADA_Q_NONCQ + }, + { /* Samsung Advanced Format (4k) drives */ { T_DIRECT, SIP_MEDIA_FIXED, "*", "SAMSUNG HD155UI*", "*" }, /*quirks*/ADA_Q_4K @@ -967,6 +976,10 @@ softc->disk->d_maxsize = maxio; softc->disk->d_unit = periph->unit_number; softc->disk->d_flags = 0; + /* Disable NCQ if needed */ + if (softc->flags & ADA_FLAG_CAN_NCQ && + softc->quirks & ADA_Q_NONCQ) + softc->flags ^= ADA_FLAG_CAN_NCQ; if (softc->flags & ADA_FLAG_CAN_FLUSHCACHE) softc->disk->d_flags |= DISKFLAG_CANFLUSHCACHE; if ((softc->flags & ADA_FLAG_CAN_TRIM) || --ZInfyf7laFu/Kiw7-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:36:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1A31065670 for ; Tue, 14 Feb 2012 23:36:44 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) by mx1.freebsd.org (Postfix) with ESMTP id 72DFD8FC17 for ; Tue, 14 Feb 2012 23:36:44 +0000 (UTC) Received: from pps.filterd (ltcfislmsgpa02 [127.0.0.1]) by ltcfislmsgpa02.fnfis.com (8.14.4/8.14.4) with SMTP id q1ENQO20005548; Tue, 14 Feb 2012 17:36:42 -0600 Received: from smtp.fisglobal.com ([10.132.206.15]) by ltcfislmsgpa02.fnfis.com with ESMTP id 1300fgg684-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 17:36:42 -0600 Received: from dtwin (10.14.152.15) by smtp.fisglobal.com (10.132.206.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 14 Feb 2012 17:36:41 -0600 From: Devin Teske To: "'Mike Andrews'" , References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> In-Reply-To: <4F3ACDE7.8060003@bit0.com> Date: Tue, 14 Feb 2012 15:36:47 -0800 Message-ID: <09c701cceb71$85388f50$8fa9adf0$@fisglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHpLgw2N43SAX2EkCOmVhPWC2ZpSwJNZ8ORAfwXlJcCVCvdvQKmrcmqAYxp73kBraTlqwFzCD1XlZT6zQA= Content-Language: en-us X-Originating-IP: [10.14.152.15] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7361, 1.0.260, 0.0.0000 definitions=2012-02-14_06:2012-02-14, 2012-02-14, 1970-01-01 signatures=0 Cc: Subject: RE: New BSD Installer 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, 14 Feb 2012 23:36:44 -0000 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Mike Andrews > Sent: Tuesday, February 14, 2012 1:11 PM > To: freebsd-stable@freebsd.org > Subject: Re: New BSD Installer > > On 2/14/2012 3:05 PM, Devin Teske wrote: > > Please don't get rid of fdisk or bsdlabel as they are (and forever will be) > > required to do things like: > > > > 1. scripted formatting of a thumb drive > > > > 2. automated probing of disk information (fdisk -p) > > > > 3. Other tasks that are not suitably handled by curses-based utilities > > > > For example, the following command will create a second Windows partition on > a > > thumb drive without user interaction: > > > > echo "p 2 0x0c * *" | fdisk -f - /dev/da0 > > > > If you take away fdisk, how am I supposed to achieve the above? > > /sbin/gpart add -t 12 -i 2 da0 > I stand corrected. Ok, remove at-will but not before 10.0 please. Looking for 9.x to be the transitional phase. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 23:49:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBF3A1065677 for ; Tue, 14 Feb 2012 23:49:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 72F808FC18 for ; Tue, 14 Feb 2012 23:49:31 +0000 (UTC) Received: from vivi.cc.vt.edu (vivi.cc.vt.edu [198.82.163.43]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q1EEaCT3007779 for ; Tue, 14 Feb 2012 09:38:18 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by vivi.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id UGJ13122; Tue, 14 Feb 2012 09:38:18 -0500 (EST) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q1EEcIHS016242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 14 Feb 2012 09:38:18 -0500 From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 09:38:18 -0500 Message-Id: To: stable@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=vivi.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020205.4F3A71DA.0112,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: Subject: ZFS + nullfs + Linuxulator = 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: Tue, 14 Feb 2012 23:49:31 -0000 I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, = last built 2012-02-08). It will panic during the daily periodic scripts = that run at 3am. Here is the most recent panic message: Fatal trap 9: general protection fault while in kernel mode cpuid =3D 0; apic id =3D 00 instruction pointer =3D 0x20:0xffffffff8069d266 stack pointer =3D 0x28:0xffffff8094b90390 frame pointer =3D 0x28:0xffffff8094b903a0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 72566 (ps) trap number =3D 9 panic: general protection fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff8062cf8e at kdb_backtrace+0x5e #1 0xffffffff805facd3 at panic+0x183 #2 0xffffffff808e6c20 at trap_fatal+0x290 #3 0xffffffff808e715a at trap+0x10a #4 0xffffffff808cec64 at calltrap+0x8 #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 #9 0xffffffff8060473f at sysctl_root+0x14f #10 0xffffffff80604a2a at userland_sysctl+0x14a #11 0xffffffff80604f1a at __sysctl+0xaa #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 #13 0xffffffff808cef5c at Xfast_syscall+0xfc Uptime: 3d19h6m0s Dumping 1308 out of 2028 = MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... The reason for the subject line is that I have another RELENG_8 system = that uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS = + nullfs is not the problem. I am wondering if it is the combination of = the three that is deadly, here. Both RELENG_8 systems are root-on-ZFS installs. Each night there is a = separate backup script that runs and completes before the regular = "periodic daily" run. This script takes a recursive snapshot of the ZFS = pool and then mounts these snapshots via mount_nullfs to provide a = coherent view of the filesystem under /backup. The only difference = between the two RELENG_8 systems is that one uses rsync to back up = /backup to another machine and the other uses the Linux Tivoli TSM = client to back up /backup to a TSM server. After the backup is = completed, a script runs that unmounts the nullfs file systems and then = destroys the ZFS snapshot. The first (rsync backup) RELENG_8 system does not panic. It has been = running the ZFS + nullfs rsync backup job without incident for weeks = now. The second (Tivoli TSM) RELENG_8 will reliably panic when the = subsequent "periodic daily" job runs. (It is using the 32-bit TSM 6.2.4 = Linux client running "dsmc schedule" via the linux_base-f10-10_4 = package.) The actual ZFS + nullfs Tivoli TSM backup job appears to run = successfully, making me wonder if perhaps it has some memory leak or = other subtle corruption that sets up the ensuing panic when the = "periodic daily" job later gives the system a workout. If I can provide more information about the panic, please let me know. = Despite the message about dumping in the panic output above, when the = system reboots I get a "No core dumps found" message during boot. (I = have dumpdev=3D"AUTO" set in /etc/rc.conf.) My swap device is on = separate partitions but is mirrored using geom_mirror as = /dev/mirror/swap. Do crash dumps to gmirror devices work on RELENG_8? Does anyone have any idea what is to blame for the panic, or how I can = fix or work around it? Cheers, Paul. PS: The uptime of three days in the panic message is because I disabled = the Tivoli TSM backup job on Friday so it would not run over the = weekend. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:10:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC61E106567C for ; Wed, 15 Feb 2012 00:10:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id CC0568FC1C for ; Wed, 15 Feb 2012 00:10:22 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ZyzN1i0091afHeLA30AN9c; Wed, 15 Feb 2012 00:10:22 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.emeryville.ca.mail.comcast.net with comcast id a0AM1i00i1t3BNj8d0AM6X; Wed, 15 Feb 2012 00:10:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DEB2B102C1E; Tue, 14 Feb 2012 16:10:20 -0800 (PST) Date: Tue, 14 Feb 2012 16:10:20 -0800 From: Jeremy Chadwick To: Victor Balada Diaz Message-ID: <20120215001020.GA9386@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> <20120214233420.GU2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120214233420.GU2010@equilibrium.bsdes.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 00:10:23 -0000 On Wed, Feb 15, 2012 at 12:34:20AM +0100, Victor Balada Diaz wrote: > On Tue, Feb 14, 2012 at 03:09:58PM -0800, Jeremy Chadwick wrote: > > On Tue, Feb 14, 2012 at 11:15:27PM +0100, Victor Balada Diaz wrote: > > > On Tue, Feb 14, 2012 at 06:17:19PM +0100, Harald Schmalzbauer wrote: > > > > schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): > > > > > On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: > > > > >> Hello, > > > > >> > > > > >> I have got a quite similar problem with AHCI on FreeBSD 8.2 and it still > > > > >> persists on FreeBSD 9.0 release. > > > > >> > > > > >> Switching from ahci to ataahci resolved the problem for me too. > > > > >> > > > > >> I'm using gmirror for swap, system is on a zpool and the problem first > > > > >> occurred during a zpool scrub, but it is easily reproducible with dd. > > > > >> > > > > >> The timeouts only occur when writing to disks, dd if=/dev/ada{0|1} > > > > >> of=/dev/null is not an issue. > > > > >> Sometimes I need to power off the server because after a reboot one disk > > > > >> is still missing. > > > > >> > > > > >> I really would like to help in this issue, so let me know if you need > > > > >> any more information. > > > > > I find it interesting that, at least so far, the only people reporting > > > > > problems of this type with the ahci.ko driver are people using Samsung > > > > > disks. The only difference is that your models are F1s while the OPs > > > > > are F2s. > > > > > > > > I saw such timeouts long ago and mav@ had a look at my postings and he > > > > mentioned it could be a NCQ problem. > > > > I suspected the disks firmware. > > > > I never tracked it down further, because after replacing the Samsung (F3 > > > > in that case) disks with hitachi ones solved all my problems and gave a > > > > big performance kick as well (with zfs). > > > > You can find the discussion here: > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.html > > > > > > > > > > You gave me a good idea: try to disable NCQ and see if that's the fault. So > > > i went and applied the attached patch. After it, i can no longer reproduce > > > the issue with ahci driver. > > > > > > I know this is not a solution because it disables NCQ at controller level > > > instead of disk level, but at least we know for sure where the problem is. > > > > > > I think the solution would be to add a new quirk ADA_Q_NONCQ in sys/cam/ata/ata_da.c. > > > Quirks infraestructure is already built, so adding a new quirk for this seems > > > easy. > > > > > > Is someone interested? Do you think there is a better solution? > > > > > > If someone is interested i can build a patch to add ADA_Q_NONCQ quirk and add my drives > > > to it. > > > > I took a stab at this, but I don't feel confident this is the proper > > solution/method. I worry there's some sort of chicken-or-the-egg > > condition here (quirk setup/matching comes *after* SATA capabilities > > detection), or that it makes the code messier. Need mav@'s > > recommendations on this. > > > > Below is for RELENG_8. I should note I haven't tested if this works, or > > even compiles -- normally I don't provide such patches without testing > > so I apologise in advance / user beware. > > You're amazingly fast. Thanks for all your help :) > > You start applying the quirks before > > snprintf(announce_buf, sizeof(announce_buf), > "kern.cam.ada.%d.quirks", periph->unit_number); > quirks = softc->quirks; > TUNABLE_INT_FETCH(announce_buf, &quirks); > > So you're breaking quirk setting at boot time. I'm too tired to quite understand (in full) what's wrong with my patch, but I think you're referring to situations where someone would have kern.cam.ada.X.quirks set in loader.conf? If so, I believe that same situation would happen presently if someone set kern.cam.ada.X.quirks in their loader.conf to a value that did not contain bit #0 set to 1, and used one of the 4K sector disks listed in ada_quirk_table -- what's in loader.conf looks like it would overwrite whatever the kernel code bits chose automatically: 910 match = cam_quirkmatch((caddr_t)&cgd->ident_data, 911 (caddr_t)ada_quirk_table, 912 sizeof(ada_quirk_table)/sizeof(*ada_quirk_table), 913 sizeof(*ada_quirk_table), ata_identify_match); 914 if (match != NULL) 915 softc->quirks = ((struct ada_quirk_entry *)match)->quirks; 916 else 917 softc->quirks = ADA_Q_NONE; ... 931 snprintf(announce_buf, sizeof(announce_buf), 932 "kern.cam.ada.%d.quirks", periph->unit_number); 933 quirks = softc->quirks; 934 TUNABLE_INT_FETCH(announce_buf, &quirks); 935 softc->quirks = quirks; I read this to mean: Lines 910-917 -- if there's a device ID string match in ada_quirk_table, set softc->quirks to the content of that struct entry. So, for example, 4K sector disks would set softc->quirks to 0x01. Lines 931-933 -- assign the "quirks" variable to what softc->quirks currently contains. Thus, for 4K sector disks, quirks = 0x01. Line 934 -- load into "quirks" variable the contents of loader.conf entries pertaining to kern.cam.ada.N.quirks, if set. If someone had an entry in loader.conf saying kern.cam.ada.N.quirks=0 then yes, this would overwrite what the kernel "auto-chose". Line 935 -- assign softc->quirks = quirks, thus softc->quirks = 0x00, assuming someone set it to such in loader.conf. > See my attached patch. I can confirm it works for me. I thought of taking that approach, but for me it's "dirty". Here's what I mean by that: ADA_FLAG_CAN_NCQ gets set in softc->flags around line 892, but then roughly a hundred lines later, you clear the exact same flag you just set (based on quirk conditionals). I dunno how people feel about that, but my impression is that it's dirty/confusing. My opinion is to only set the bit once and not mess about with repeated if() statements that set it, then clear it, etc... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:15:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C45C106574D for ; Wed, 15 Feb 2012 00:15:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 102B98FC0C for ; Wed, 15 Feb 2012 00:15:12 +0000 (UTC) Received: from localhost.samsco.home (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q1ENgmt6064363; Tue, 14 Feb 2012 16:42:48 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Scott Long In-Reply-To: <20120214233420.GU2010@equilibrium.bsdes.net> Date: Tue, 14 Feb 2012 16:42:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6D5E973B-6D98-41D7-B5E9-64A497F0F9F5@samsco.org> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> <20120214233420.GU2010@equilibrium.bsdes.net> To: Victor Balada Diaz X-Mailer: Apple Mail (2.1251.1) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 00:15:14 -0000 On Feb 14, 2012, at 4:34 PM, Victor Balada Diaz wrote: > On Tue, Feb 14, 2012 at 03:09:58PM -0800, Jeremy Chadwick wrote: >> On Tue, Feb 14, 2012 at 11:15:27PM +0100, Victor Balada Diaz wrote: >>> On Tue, Feb 14, 2012 at 06:17:19PM +0100, Harald Schmalzbauer wrote: >>>> schrieb Jeremy Chadwick am 14.02.2012 17:50 (localtime): >>>>> On Tue, Feb 14, 2012 at 04:55:10PM +0100, Claudius Herder wrote: >>>>>> Hello, >>>>>>=20 >>>>>> I have got a quite similar problem with AHCI on FreeBSD 8.2 and = it still >>>>>> persists on FreeBSD 9.0 release. >>>>>>=20 >>>>>> Switching from ahci to ataahci resolved the problem for me too. >>>>>>=20 >>>>>> I'm using gmirror for swap, system is on a zpool and the problem = first >>>>>> occurred during a zpool scrub, but it is easily reproducible with = dd. >>>>>>=20 >>>>>> The timeouts only occur when writing to disks, dd = if=3D/dev/ada{0|1} >>>>>> of=3D/dev/null is not an issue. >>>>>> Sometimes I need to power off the server because after a reboot = one disk >>>>>> is still missing. >>>>>>=20 >>>>>> I really would like to help in this issue, so let me know if you = need >>>>>> any more information. >>>>> I find it interesting that, at least so far, the only people = reporting >>>>> problems of this type with the ahci.ko driver are people using = Samsung >>>>> disks. The only difference is that your models are F1s while the = OPs >>>>> are F2s. >>>>=20 >>>> I saw such timeouts long ago and mav@ had a look at my postings and = he >>>> mentioned it could be a NCQ problem. >>>> I suspected the disks firmware. >>>> I never tracked it down further, because after replacing the = Samsung (F3 >>>> in that case) disks with hitachi ones solved all my problems and = gave a >>>> big performance kick as well (with zfs). >>>> You can find the discussion here: >>>> = http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055374.htm= l >>>>=20 >>>=20 >>> You gave me a good idea: try to disable NCQ and see if that's the = fault. So >>> i went and applied the attached patch. After it, i can no longer = reproduce >>> the issue with ahci driver. >>>=20 >>> I know this is not a solution because it disables NCQ at controller = level >>> instead of disk level, but at least we know for sure where the = problem is. >>>=20 >>> I think the solution would be to add a new quirk ADA_Q_NONCQ in = sys/cam/ata/ata_da.c. >>> Quirks infraestructure is already built, so adding a new quirk for = this seems >>> easy. >>>=20 >>> Is someone interested? Do you think there is a better solution? >>>=20 >>> If someone is interested i can build a patch to add ADA_Q_NONCQ = quirk and add my drives >>> to it. >>=20 >> I took a stab at this, but I don't feel confident this is the proper >> solution/method. I worry there's some sort of chicken-or-the-egg >> condition here (quirk setup/matching comes *after* SATA capabilities >> detection), or that it makes the code messier. Need mav@'s >> recommendations on this. >>=20 >> Below is for RELENG_8. I should note I haven't tested if this works, = or >> even compiles -- normally I don't provide such patches without = testing >> so I apologise in advance / user beware. >=20 > You're amazingly fast. Thanks for all your help :) >=20 > You start applying the quirks before=20 >=20 > snprintf(announce_buf, sizeof(announce_buf), > "kern.cam.ada.%d.quirks", periph->unit_number); > quirks =3D softc->quirks; > TUNABLE_INT_FETCH(announce_buf, &quirks); >=20 > So you're breaking quirk setting at boot time. >=20 > See my attached patch. I can confirm it works for me. >=20 > Regards. >=20 I don't think that disabling NCQ entirely is the right solution. It's a = tag starvation issue in the firmware, not a complete failure, and it can = be dealt with in the CAM XPT scheduler fairly efficiently. Alexander = and I talked about this recently, and though we differ on the details, a = tag hack is not in order, IMHO. In the short term, try just using "cam = control tags ada0 -N 1" to limit the concurrent commands to 1. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:18:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D191065670 for ; Wed, 15 Feb 2012 00:18:01 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9948FC0A for ; Wed, 15 Feb 2012 00:18:00 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q1F0I0Lt013608 for ; Tue, 14 Feb 2012 17:18:00 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q1F0I0i2013607 for freebsd-stable@freebsd.org; Tue, 14 Feb 2012 17:18:00 -0700 (MST) (envelope-from ken) Date: Tue, 14 Feb 2012 17:18:00 -0700 From: "Kenneth D. Merry" To: freebsd-stable@freebsd.org Message-ID: <20120215001759.GA76269@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: HEADS UP: Xen merge coming to stable/8 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, 15 Feb 2012 00:18:01 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I'm planning to merge almost all of the Xen changes from FreeBSD/head into stable/8 soon. This should bring more features, stability, etc. I've attached what will be the commit message. If there are any objections, speak now. Ken -- Kenneth Merry ken@FreeBSD.ORG --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xen_stable_8.20120214.txt" MFC r215818, r216405, r216437, r216448, r216956, r221827, r222975, r223059, r225343, r225704, r225705, r225706, r225707, r225709, r226029, r220647, r230183, r230587, r230916, r228526, r230879: Bring Xen support in stable/8 up to parity with head. r215818 | cperciva | 2010-11-25 08:05:21 -0700 (Thu, 25 Nov 2010) | 5 lines Rename HYPERVISOR_multicall (which performs the multicall hypercall) to _HYPERVISOR_multicall, and create a new HYPERVISOR_multicall function which invokes _HYPERVISOR_multicall and checks that the individual hypercalls all succeeded. r216405 | rwatson | 2010-12-13 05:15:46 -0700 (Mon, 13 Dec 2010) | 7 lines Add options NO_ADAPTIVE_SX to the XENHVM kernel configuration, matching its similar disabling of adaptive mutexes and rwlocks. The existing comment on why this is the case also applies to sx locks. MFC after: 3 days Discussed with: attilio r216437 | gibbs | 2010-12-14 10:23:49 -0700 (Tue, 14 Dec 2010) | 2 lines Remove spurious printf left over from debugging our XenStore support. r216448 | gibbs | 2010-12-14 13:57:40 -0700 (Tue, 14 Dec 2010) | 4 lines Fix a typo in a comment. Noticed by: Attila Nagy r216956 | rwatson | 2011-01-04 07:49:54 -0700 (Tue, 04 Jan 2011) | 8 lines Make "options XENHVM" compile for i386, not just amd64 -- a largely mechanical change. This opens the door for using PV device drivers under Xen HVM on i386, as well as more general harmonisation of i386 and amd64 Xen support in FreeBSD. Reviewed by: cperciva MFC after: 3 weeks r221827 | mav | 2011-05-12 21:40:16 -0600 (Thu, 12 May 2011) | 2 lines Fix msleep() usage in Xen balloon driver to not wake up on every HZ tick. r222975 | gibbs | 2011-06-10 22:59:01 -0600 (Fri, 10 Jun 2011) | 63 lines Monitor and emit events for XenStore changes to XenBus trees of the devices we manage. These changes can be due to writes we make ourselves or due to changes made by the control domain. The goal of these changes is to insure that all state transitions can be detected regardless of their source and to allow common device policies (e.g. "onlined" backend devices) to be centralized in the XenBus bus code. sys/xen/xenbus/xenbusvar.h: sys/xen/xenbus/xenbus.c: sys/xen/xenbus/xenbus_if.m: Add a new method for XenBus drivers "localend_changed". This method is invoked whenever a write is detected to a device's XenBus tree. The default implementation of this method is a no-op. sys/xen/xenbus/xenbus_if.m: sys/dev/xen/netfront/netfront.c: sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/blkback/blkback.c: Change the signature of the "otherend_changed" method. This notification cannot fail, so it should return void. sys/xen/xenbus/xenbusb_back.c: Add "online" device handling to the XenBus Back Bus support code. An online backend device remains active after a front-end detaches as a reconnect is expected to occur in the near future. sys/xen/interface/io/xenbus.h: Add comment block further explaining the meaning and driver responsibilities associated with the XenBus Closed state. sys/xen/xenbus/xenbusb.c: sys/xen/xenbus/xenbusb.h: sys/xen/xenbus/xenbusb_back.c: sys/xen/xenbus/xenbusb_front.c: sys/xen/xenbus/xenbusb_if.m: o Register a XenStore watch against the local XenBus tree for all devices. o Cache the string length of the path to our local tree. o Allow the xenbus front and back drivers to hook/filter both local and otherend watch processing. o Update the device ivar version of "state" when we detect a XenStore update of that node. sys/dev/xen/control/control.c: sys/xen/xenbus/xenbus.c: sys/xen/xenbus/xenbusb.c: sys/xen/xenbus/xenbusb.h: sys/xen/xenbus/xenbusvar.h: sys/xen/xenstore/xenstorevar.h: Allow clients of the XenStore watch mechanism to attach a single uintptr_t worth of client data to the watch. This removes the need to carefully place client watch data within enclosing objects so that a cast or offsetof calculation can be used to convert from watch to enclosing object. Sponsored by: Spectra Logic Corporation MFC after: 1 week r223059 | gibbs | 2011-06-13 14:36:29 -0600 (Mon, 13 Jun 2011) | 36 lines Several enhancements to the Xen block back driver. sys/dev/xen/blkback/blkback.c: o Implement front-end request coalescing. This greatly improves the performance of front-end clients that are unaware of the dynamic request-size/number of requests negotiation available in the FreeBSD backend driver. This required a large restructuring in how this driver records in-flight transactions and how those transactions are mapped into kernel KVA. For example, the driver now includes a mini "KVA manager" that allocates ranges of contiguous KVA to patches of requests that are physically contiguous in the backing store so that a single bio or UIO segment can be used to represent the I/O. o Refuse to open any backend files or devices if the system has yet to mount root. This avoids a panic. o Properly handle "onlined" devices. An "onlined" backend device stays attached to its backing store across front-end disconnections. This feature is intended to reduce latency when a front-end does a hand-off to another driver (e.g. PV aware bootloader to OS kernel) or during a VM reboot. o Harden the driver against a pathological/buggy front-end by carefully vetting front-end XenStore data such as the front-end state. o Add sysctls that report the negotiated number of segments per-request and the number of requests that can be concurrently in flight. Submitted by: kdm Reviewed by: gibbs Sponsored by: Spectra Logic Corporation MFC after: 1 week r225343 | rwatson | 2011-09-02 11:36:01 -0600 (Fri, 02 Sep 2011) | 7 lines Add support for alternative break-to-debugger support on the Xen console. This should help debug boot-time hangs experienced in 9.0-BETA. MFC after: 3 weeks Tested by: sbruno Approved by: re (kib) r225704 | gibbs | 2011-09-20 17:44:34 -0600 (Tue, 20 Sep 2011) | 29 lines Properly handle suspend/resume events in the Xen device framework. Sponsored by: BQ Internet sys/xen/xenbus/xenbusb.c: o In xenbusb_resume(), publish the state transition of the resuming device into XenbusStateIntiailising so that the remote peer can see it. Recording the state locally is not sufficient to trigger a re-connect sequence. o In xenbusb_resume(), defer new-bus resume processing until after the remote peer's XenStore address has been updated. The drivers may need to refer to this information during resume processing. sys/xen/xenbus/xenbusb_back.c: sys/xen/xenbus/xenbusb_front.c: Register xenbusb_resume() rather than bus_generic_resume() as the handler for device_resume events. sys/xen/xenstore/xenstore.c: o Fix grammer in a comment. o In xs_suspend(), pass suspend events on to the child devices (e.g. xenbusb_front/back, that are attached to the XenStore. Approved by: re MFC after: 1 week r225705 | gibbs | 2011-09-20 18:02:44 -0600 (Tue, 20 Sep 2011) | 35 lines Add suspend/resume support to the Xen blkfront driver. Sponsored by: BQ Internet sys/dev/xen/blkfront/block.h: sys/dev/xen/blkfront/blkfront.c: Remove now unused blkif_vdev_t from the blkfront soft. sys/dev/xen/blkfront/blkfront.c: o In blkfront_suspend(), indicate the desire to suspend by changing the softc connected state to SUSPENDED, and then wait for any I/O pending on the remote peer to drain. Cancel suspend processing if I/O does not drain within 30 seconds. o Enable and update blkfront_resume(). Since I/O is drained prior to the suspension of the VM, the complicated recovery process performed by other Xen blkfront implementations is avoided. We simply tear down the connection to our old peer, and then re-connect. o In blkif_initialize(), fix a resource leak and botched return if we cannot allocate shadow memory for our requests. o In blkfront_backend_changed(), correct our response to the XenbusStateInitialised state. This state indicates that our backend peer has published sufficient data for blkfront to publish ring information and other XenStore data, not that a connection can occur. Blkfront now will only perform connection processing in response to the XenbusStateConnected state. This corrects an issue where blkfront connected before the backend was ready during resume processing. Approved by: re MFC after: 1 week r225706 | gibbs | 2011-09-20 18:06:02 -0600 (Tue, 20 Sep 2011) | 11 lines [ Forced commit. Actual changes accidentally included in r225704 ] sys/dev/xen/control/control.c: Fix locking violations in Xen HVM suspend processing and have it perform similar actions to those performed during an ACPI triggered suspend. Sponsored by: BQ Internet Approved by: re MFC after: 1 week r225707 | gibbs | 2011-09-20 18:08:25 -0600 (Tue, 20 Sep 2011) | 21 lines Correct suspend/resume support in the Netfront driver. Sponsored by: BQ Internet sys/dev/xen/netfront/netfront.c: o Implement netfront_suspend(), a specialized suspend handler for the netfront driver. This routine simply disables the carrier so the driver is idle during system suspend processing. o Fix a leak when re-initializing LRO during a link reset. o In netif_release_tx_bufs(), when cleaning up the grant references for our TX ring, use gnttab_end_foreign_access_ref instead of attempting to grant the page again. o In netif_release_tx_bufs(), we do not track mbufs associated with mbuf chains, but instead just free each mbuf directly. Use m_free(), not m_freem(), to avoid double frees of mbufs. o Refactor some code to enhance clarity. Approved by: re MFC after: 1 week r225709 | gibbs | 2011-09-20 18:15:29 -0600 (Tue, 20 Sep 2011) | 19 lines Update netfront so that it queries and honors published back-end features. sys/dev/xen/netfront/netfront.c: o Add xn_query_features() which reads the XenStore and records the TSO, LRO, and chained ring-request support of the backend. o Rename xn_configure_lro() to xn_configure_features() and use this routine to manage the setup of TSO, LRO, and checksum offload. o In create_netdev(), initialize if_capabilities and if_hwassist to the capabilities found on all backends. Delegate configuration of if_capenable and the TSO flag if if_hwassist to xn_configure_features(). Reported by: Hugo Silva (fix inspired by patch provided) Approved by: re MFC after: 1 week r226029 | jkim | 2011-10-04 17:53:47 -0600 (Tue, 04 Oct 2011) | 2 lines Add strnlen() to libkern. r220647 | jkim | 2011-04-14 16:17:39 -0600 (Thu, 14 Apr 2011) | 4 lines Add event handlers for (ACPI) suspend/resume events. Suspend event handlers are invoked right before device drivers go into sleep state and resume event handlers are invoked right after all device drivers are waken up. r230183 | cperciva | 2012-01-15 19:38:45 -0700 (Sun, 15 Jan 2012) | 3 lines Make XENHVM work on i386. The __ffs() function counts bits starting from zero, unlike ffs(3), which starts counting from 1. r230587 | ken | 2012-01-26 09:35:09 -0700 (Thu, 26 Jan 2012) | 38 lines Xen netback driver rewrite. share/man/man4/Makefile, share/man/man4/xnb.4, sys/dev/xen/netback/netback.c, sys/dev/xen/netback/netback_unit_tests.c: Rewrote the netback driver for xen to attach properly via newbus and work properly in both HVM and PVM mode (only HVM is tested). Works with the in-tree FreeBSD netfront driver or the Windows netfront driver from SuSE. Has not been extensively tested with a Linux netfront driver. Does not implement LRO, TSO, or polling. Includes unit tests that may be run through sysctl after compiling with XNB_DEBUG defined. sys/dev/xen/blkback/blkback.c, sys/xen/interface/io/netif.h: Comment elaboration. sys/kern/uipc_mbuf.c: Fix page fault in kernel mode when calling m_print() on a null mbuf. Since m_print() is only used for debugging, there are no performance concerns for extra error checking code. sys/kern/subr_scanf.c: Add the "hh" and "ll" width specifiers from C99 to scanf(). A few callers were already using "ll" even though scanf() was handling it as "l". Submitted by: Alan Somers Submitted by: John Suykerbuyk Sponsored by: Spectra Logic MFC after: 1 week Reviewed by: ken r230916 | ken | 2012-02-02 10:54:35 -0700 (Thu, 02 Feb 2012) | 13 lines Fix the netback driver build for i386. netback.c: Add missing VM includes. xen/xenvar.h, xen/xenpmap.h: Move some XENHVM macros from to on i386 to match the amd64 headers. conf/files: Add netback to the build. Submitted by: jhb MFC after: 3 days r228526 | kevlo | 2011-12-14 23:29:13 -0700 (Wed, 14 Dec 2011) | 2 lines s/timout/timeout r230879 | ken | 2012-02-01 13:19:33 -0700 (Wed, 01 Feb 2012) | 4 lines Add the GSO prefix descriptor define. MFC after: 3 days --jRHKVT23PllUwdXP-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:20:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92615106566C for ; Wed, 15 Feb 2012 00:20:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 7786A8FC13 for ; Wed, 15 Feb 2012 00:20:38 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta07.emeryville.ca.mail.comcast.net with comcast id a0D11i0051GXsucA70LeLU; Wed, 15 Feb 2012 00:20:38 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id a0Ld1i00E1t3BNj8U0Ld98; Wed, 15 Feb 2012 00:20:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0A83E102C1E; Tue, 14 Feb 2012 16:20:37 -0800 (PST) Date: Tue, 14 Feb 2012 16:20:37 -0800 From: Jeremy Chadwick To: Julian Elischer Message-ID: <20120215002036.GA9938@icarus.home.lan> References: <4F3A1A19.7010803@freebsd.org> <4F3AEFA5.1020906@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3AEFA5.1020906@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: freebsd 9-stable TOP problem from around Jan 10 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, 15 Feb 2012 00:20:38 -0000 On Tue, Feb 14, 2012 at 03:35:01PM -0800, Julian Elischer wrote: > On 2/14/12 10:38 AM, Kevin Oberman wrote: > >On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer wrote: > >>Has anyone else seen a problem with top -H -S? > >> > >>after a short while the screen gets more and more corrupted.. > >> > >>hitting ^L or turning off S& H modes helps .. for a while. > >> > >>If this is a known fixed problem, let me know but I need to co-ordinate with > >>others > >>to upgrade the machine in question. > >Not seeing it here on 9-stable. Could it be a display issue? I am > >using gnome-terminal with TERM defined as 'xterm'. > > yeah I'm on a mac with iterm, but running through 'screen' . > > it's never been a problem before.. just since we upgraded to 9-stable. If you remove GNU screen from the picture does the problem go away? If so, I'm not surprised. :-) Make sure that when you're using GNU screen, that all shells launched "under/within" screen have TERM=screen. If they don't, then this is almost certainly the problem -- GNU screen "translates" between terminal types, meaning it translates its own terminal type ("screen") into whatever TERM is currently attached ("xterm", "iterm", whatever). See the last 4 paragraphs of my post here to understand what exactly GNU screen is doing: http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html So, in general, make sure your dotfiles and so on don't mess about with the $TERM environment variable and you should generally be okay. If within GNU screen TERM=screen and you see the problem, but outside of screen you use TERM=xterm (or something else) but don't see the problem, then I would almost certainly blame GNU screen. If you're looking for something that simply keeps a terminal running in the background, try nohup or tmux. Alternately, possibly someone added a "screen" entry to /etc/termcap on RELENG_9? I don't use 9 so I have no way to confirm this, but on 8 there is no such entry. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:23:54 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606B8106566B for ; Wed, 15 Feb 2012 00:23:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id 2198A8FC1F for ; Wed, 15 Feb 2012 00:23:53 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id a0PZ1i0041uE5Es560PufZ; Wed, 15 Feb 2012 00:23:54 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.westchester.pa.mail.comcast.net with comcast id a0Ps1i02r1t3BNj3c0Ptts; Wed, 15 Feb 2012 00:23:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C0661102C1E; Tue, 14 Feb 2012 16:23:51 -0800 (PST) Date: Tue, 14 Feb 2012 16:23:51 -0800 From: Jeremy Chadwick To: Paul Mather Message-ID: <20120215002351.GB9938@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org Subject: Re: ZFS + nullfs + Linuxulator = 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: Wed, 15 Feb 2012 00:23:54 -0000 On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: > I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, last built 2012-02-08). It will panic during the daily periodic scripts that run at 3am. Here is the most recent panic message: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff8069d266 > stack pointer = 0x28:0xffffff8094b90390 > frame pointer = 0x28:0xffffff8094b903a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 72566 (ps) > trap number = 9 > panic: general protection fault > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff8062cf8e at kdb_backtrace+0x5e > #1 0xffffffff805facd3 at panic+0x183 > #2 0xffffffff808e6c20 at trap_fatal+0x290 > #3 0xffffffff808e715a at trap+0x10a > #4 0xffffffff808cec64 at calltrap+0x8 > #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 > #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 > #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 > #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 > #9 0xffffffff8060473f at sysctl_root+0x14f > #10 0xffffffff80604a2a at userland_sysctl+0x14a > #11 0xffffffff80604f1a at __sysctl+0xaa > #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 > #13 0xffffffff808cef5c at Xfast_syscall+0xfc > Uptime: 3d19h6m0s > Dumping 1308 out of 2028 MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91% > Dump complete > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > > > The reason for the subject line is that I have another RELENG_8 system that uses ZFS + nullfs but doesn't panic, leading me to believe that ZFS + nullfs is not the problem. I am wondering if it is the combination of the three that is deadly, here. > > Both RELENG_8 systems are root-on-ZFS installs. Each night there is a separate backup script that runs and completes before the regular "periodic daily" run. This script takes a recursive snapshot of the ZFS pool and then mounts these snapshots via mount_nullfs to provide a coherent view of the filesystem under /backup. The only difference between the two RELENG_8 systems is that one uses rsync to back up /backup to another machine and the other uses the Linux Tivoli TSM client to back up /backup to a TSM server. After the backup is completed, a script runs that unmounts the nullfs file systems and then destroys the ZFS snapshot. > > The first (rsync backup) RELENG_8 system does not panic. It has been running the ZFS + nullfs rsync backup job without incident for weeks now. The second (Tivoli TSM) RELENG_8 will reliably panic when the subsequent "periodic daily" job runs. (It is using the 32-bit TSM 6.2.4 Linux client running "dsmc schedule" via the linux_base-f10-10_4 package.) The actual ZFS + nullfs Tivoli TSM backup job appears to run successfully, making me wonder if perhaps it has some memory leak or other subtle corruption that sets up the ensuing panic when the "periodic daily" job later gives the system a workout. > > If I can provide more information about the panic, please let me know. Despite the message about dumping in the panic output above, when the system reboots I get a "No core dumps found" message during boot. (I have dumpdev="AUTO" set in /etc/rc.conf.) My swap device is on separate partitions but is mirrored using geom_mirror as /dev/mirror/swap. Do crash dumps to gmirror devices work on RELENG_8? See gmirror(8) man page, section NOTES. Read the full thing. > Does anyone have any idea what is to blame for the panic, or how I can fix or work around it? Does the panic always happen when "ps" is run? That's what's shown in the above panic message. Quoting: > current process = 72566 (ps) And I'm inclined to think it does, based on the backtrace: > #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 > #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 > #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 > #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 But if you can go through the previous panics and confirm that, it would be helpful to developers in tracking down the problem. Sorry I can't be of any more assistance than this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 00:41:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C910106566C for ; Wed, 15 Feb 2012 00:41:06 +0000 (UTC) (envelope-from brian.scott4@det.nsw.edu.au) Received: from up-mx3.det.nsw.edu.au (up-mx3.det.nsw.edu.au [153.107.41.21]) by mx1.freebsd.org (Postfix) with ESMTP id F2BA48FC19 for ; Wed, 15 Feb 2012 00:41:05 +0000 (UTC) Received: from itfsmtp7.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx3.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id q1ENqRJ6028648 for ; Wed, 15 Feb 2012 10:52:27 +1100 Received: from itfexhub4.central.det.win (Not Verified[153.107.9.31]) by itfsmtp7.central.det.win with MailMarshal (v6, 7, 2, 0) id ; Wed, 15 Feb 2012 10:52:27 +1100 Received: from ALF2.riverina.det.win ([172.18.8.18]) by itfexhub4.central.det.win with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 10:52:26 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Feb 2012 10:52:25 +1100 Message-ID: <208875941252614284029FECC54B9ED8D76374@ALF2.riverina.det.win> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reducing the need to compile a custom kernel Thread-Index: AczrBA959KMPlCEIROiTDk/IeLhhkwAax8yA References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net><20120210144449.GA2358@psconsult.nl> <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> From: "Scott, Brian" To: X-OriginalArrivalTime: 14 Feb 2012 23:52:26.0152 (UTC) FILETIME=[B40E8A80:01CCEB73] Subject: RE: Reducing the need to compile a custom kernel 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, 15 Feb 2012 00:41:06 -0000 >> - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices > >Embedded devices are out of the scope of this, normally you do a lot of other modifictions to such systems anyway, so a custom kernel should be not a >big problem. Just as a quick data point here, I have just installed FreeBSD onto an ALIX system and was hoping to keep everything very standard. Turns out that I needed to rebuild the kernel to add CPU_GEODE to get a few simple features added. Everything else is standard GENERIC because I'm too lazy to fine tune. The geode code is very small and I would expect completely harmless if left enabled in GENERIC. The overhead of including it for other systems would be a few extra compares during startup and a k or so extra size in the kernel. I would suggest that avoiding custom kernels to make trivial changes is exactly what you should be looking at. Make features like this removable for the people who want to fine tune their kernels but include for people who are happy to have a little overhead as a trade of for ease of management. The only other thing that regularly has me running custom kernels is IPFIREWALL_FORWARD. As others have said, I'd be very happy if that was the default but removable. Brian Scott ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 01:03:56 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99EB51065672 for ; Wed, 15 Feb 2012 01:03:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E2E4D8FC08 for ; Wed, 15 Feb 2012 01:03:55 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1F0lsuw047518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 02:47:54 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1F0lrvH099916; Wed, 15 Feb 2012 02:47:53 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1F0lrpY099915; Wed, 15 Feb 2012 02:47:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Feb 2012 02:47:53 +0200 From: Konstantin Belousov To: Paul Mather Message-ID: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3KcXvujU0fwzTBcC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: ZFS + nullfs + Linuxulator = 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: Wed, 15 Feb 2012 01:03:56 -0000 --3KcXvujU0fwzTBcC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: > I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel, l= ast built 2012-02-08). It will panic during the daily periodic scripts tha= t run at 3am. Here is the most recent panic message: >=20 > Fatal trap 9: general protection fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > instruction pointer =3D 0x20:0xffffffff8069d266 > stack pointer =3D 0x28:0xffffff8094b90390 > frame pointer =3D 0x28:0xffffff8094b903a0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D resume, IOPL =3D 0 > current process =3D 72566 (ps) > trap number =3D 9 > panic: general protection fault > cpuid =3D 0 > KDB: stack backtrace: > #0 0xffffffff8062cf8e at kdb_backtrace+0x5e > #1 0xffffffff805facd3 at panic+0x183 > #2 0xffffffff808e6c20 at trap_fatal+0x290 > #3 0xffffffff808e715a at trap+0x10a > #4 0xffffffff808cec64 at calltrap+0x8 > #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 > #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 > #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 > #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 > #9 0xffffffff8060473f at sysctl_root+0x14f > #10 0xffffffff80604a2a at userland_sysctl+0x14a > #11 0xffffffff80604f1a at __sysctl+0xaa > #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 > #13 0xffffffff808cef5c at Xfast_syscall+0xfc Please look up the line number for the fill_kinfo_thread+0x54. --3KcXvujU0fwzTBcC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk87ALkACgkQC3+MBN1Mb4ht2gCgzhm4+1PseCx69fYZSwEp1utu YeUAoOtDJ65CyrvsepT/6EHKpuf953sP =kXTk -----END PGP SIGNATURE----- --3KcXvujU0fwzTBcC-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 01:04:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6338F10657CC for ; Wed, 15 Feb 2012 01:04:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E89918FC14 for ; Wed, 15 Feb 2012 01:04:17 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1F14AAx049128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1F14AgC000279; Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1F14AmY000278; Wed, 15 Feb 2012 03:04:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Feb 2012 03:04:10 +0200 From: Konstantin Belousov To: Peter Jeremy Message-ID: <20120215010410.GS3283@deviant.kiev.zoral.com.ua> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ien3FGZY55BN3Fs2" Content-Disposition: inline In-Reply-To: <20120214200258.GA29641@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 15 Feb 2012 01:04:18 -0000 --ien3FGZY55BN3Fs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 07:02:58AM +1100, Peter Jeremy wrote: > On 2012-Feb-13 08:28:21 -0500, Gary Palmer wrote: > >The filesystem is the *BEST* place to do caching. It knows what metadata > >is most effective to cache and what other data (e.g. file contents) does= n't > >need to be cached. >=20 > Agreed. >=20 > > Any attempt to do this in layers between the FS and > >the disk won't achieve the same gains as a properly written filesystem.= =20 >=20 > Agreed - but traditionally, Unix uses this approach via block devices. > For various reasons, FreeBSD moved caching into UFS and removed block > devices. Unfortunately, this means that any FS that wants caching has > to implement its own - and currently only UFS & ZFS do. Block caching is still there, only user-accessible interface was removed. UFS utilizes the buffer cache for the device which carries the volume, for metadata caching. There are some memory areas in UFS which can be classified as caches on its own, but their existence is mostly to support operation, and not caching (e.g. the inodeblock copy accompaniying each inode). >=20 > What would be nice is a generic caching subsystem that any FS can use > - similar to the old block devices but with hooks to allow the FS to > request read-ahead, advise of unwanted blocks and ability to flush > dirty blocks in a requested order with the equivalent of barriers > (request Y will not occur until preceeding request X has been > committed to stable media). This would allow filesystems to regain > the benefits of block devices with minimal effort and then improve > performance & cache efficiency with additional work. >=20 > One downside of the "each FS does its own caching" in that the caches > are all separate and need careful integration into the VM subsystem to > prevent starvation (eg past problems with UFS starving ZFS L2ARC). Other filesystems which use vfs_bio, like cd9660 or ufs, use the same disk cache layer as UFS. --ien3FGZY55BN3Fs2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk87BIgACgkQC3+MBN1Mb4jbGwCgrTTJjedaASuWu5YV1z9ASwxu OJMAoKUq+gnre+3bhN3ehFdwEsbjLjN5 =dSnK -----END PGP SIGNATURE----- --ien3FGZY55BN3Fs2-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 01:43:04 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2256C106564A; Wed, 15 Feb 2012 01:43:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id BE26C8FC13; Wed, 15 Feb 2012 01:43:03 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1F1h2Tj047833; Wed, 15 Feb 2012 01:43:02 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1F1h2fq047770; Wed, 15 Feb 2012 01:43:02 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Feb 2012 01:43:02 GMT Message-Id: <201202150143.q1F1h2fq047770@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:43:04 -0000 TB --- 2012-02-15 00:31:23 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-15 00:31:23 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-02-15 00:31:23 - cleaning the object tree TB --- 2012-02-15 00:31:23 - cvsupping the source tree TB --- 2012-02-15 00:31:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2012-02-15 00:36:50 - building world TB --- 2012-02-15 00:36:50 - CROSS_BUILD_TESTING=YES TB --- 2012-02-15 00:36:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-15 00:36:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-15 00:36:50 - SRCCONF=/dev/null TB --- 2012-02-15 00:36:50 - TARGET=ia64 TB --- 2012-02-15 00:36:50 - TARGET_ARCH=ia64 TB --- 2012-02-15 00:36:50 - TZ=UTC TB --- 2012-02-15 00:36:50 - __MAKE_CONF=/dev/null TB --- 2012-02-15 00:36:50 - cd /src TB --- 2012-02-15 00:36:50 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 15 00:36:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 15 01:37:12 UTC 2012 TB --- 2012-02-15 01:37:12 - generating LINT kernel config TB --- 2012-02-15 01:37:12 - cd /src/sys/ia64/conf TB --- 2012-02-15 01:37:12 - /usr/bin/make -B LINT TB --- 2012-02-15 01:37:12 - cd /src/sys/ia64/conf TB --- 2012-02-15 01:37:12 - /usr/sbin/config -m LINT TB --- 2012-02-15 01:37:12 - building LINT kernel TB --- 2012-02-15 01:37:12 - CROSS_BUILD_TESTING=YES TB --- 2012-02-15 01:37:12 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-15 01:37:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-15 01:37:12 - SRCCONF=/dev/null TB --- 2012-02-15 01:37:12 - TARGET=ia64 TB --- 2012-02-15 01:37:12 - TARGET_ARCH=ia64 TB --- 2012-02-15 01:37:12 - TZ=UTC TB --- 2012-02-15 01:37:12 - __MAKE_CONF=/dev/null TB --- 2012-02-15 01:37:12 - cd /src TB --- 2012-02-15 01:37:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 15 01:37:12 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_init': /src/sys/dev/netmap/netmap.c:522: warning: integer overflow in expression *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-15 01:43:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-15 01:43:02 - ERROR: failed to build LINT kernel TB --- 2012-02-15 01:43:02 - 3247.56 user 494.73 system 4298.93 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 02:33:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A0B106564A; Wed, 15 Feb 2012 02:33:49 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 07FC48FC14; Wed, 15 Feb 2012 02:33:49 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 9F9A625D3870; Wed, 15 Feb 2012 02:33:47 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A0205BDB607; Wed, 15 Feb 2012 02:33:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Eaeywt0xWfNi; Wed, 15 Feb 2012 02:33:45 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1CE68BDB602; Wed, 15 Feb 2012 02:33:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F3ADA5E.4060800@barafranca.com> Date: Wed, 15 Feb 2012 02:33:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1A41718A-076E-4EA8-9417-AF19FA8911E3@lists.zabbadoz.net> References: <4F3A9237.5080901@barafranca.com> <4F3ADA5E.4060800@barafranca.com> To: Hugo Silva X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org, glebius@freebsd.org Subject: Re: CARP carpdev 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, 15 Feb 2012 02:33:49 -0000 On 14. Feb 2012, at 22:04 , Hugo Silva wrote: > On 02/14/12 17:33, Freddie Cash wrote: >> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva = wrote: >>> Looks like there's been conversations about porting this to FreeBSD = since at >>> least 2007. >>>=20 >>> Are there any plans to have ifconfig carpdev available in = 9.0-STABLE? >>=20 >> CARP support has been redone in 10-CURRENT, removing the whole = "carp0" >> pseudo-interface support, and just enabling the CARP protocol on the >> existing network interfaces. This includes the equivalent of = "carpdev" >> support. >>=20 >> Search the -current archives for more information, CFT, and so on. >>=20 >> I don't recall seeing anything about specific plans to MFC to >> stable/9, but could be mis-remembering things. >>=20 >=20 >=20 > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D228571 >=20 > The single IP limitation may be a problem in some locations.. >=20 > Did not find anything about a possible MFC either. glebius@ is cc'd, = perhaps he can add something, but based on = http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been = MFCd (there's a primer for the new carp in current's UPDATING)\ There's no plans to MFC given it changes things significantly. I however wonder if someone wants to provide a user branch in SVN to provide regular patchsets for stable/9 and maybe even stable/8 (8.3R) to help people not going to HEAD? --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 02:37:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73220106566B; Wed, 15 Feb 2012 02:37:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 395D18FC08; Wed, 15 Feb 2012 02:37:50 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so1148060pbc.13 for ; Tue, 14 Feb 2012 18:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=kdzLiep3umfgXSgCt0YzUoJhznlHVNJ1akd3KXWDibo=; b=siagVRd9n64QvjOo/eJB6Xecuuhg42Fj7ZDh8sWqtFTl8YQjoLOFUs+wOeaRsIA6dk 82URKDKrr7nlrG3CSK404r4X4GpUw1F/IxjCNwI/7IZMNT6B60PYYR7Eghs6MioA92ob g9E2FjmuiNYxnVZP3Fc3R7f4HBckYXm65TBYY= Received: by 10.68.225.73 with SMTP id ri9mr64605648pbc.70.1329273469831; Tue, 14 Feb 2012 18:37:49 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id q8sm7519453pbi.1.2012.02.14.18.37.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Feb 2012 18:37:48 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 15 Feb 2012 11:37:46 -0800 From: YongHyeon PYUN Date: Wed, 15 Feb 2012 11:37:46 -0800 To: Randy Bush Message-ID: <20120215193746.GC4131@michelle.cdnetworks.com> References: <20120128121830.GA38513@alchemy.franken.de> <20120128131830.GZ44286@alchemy.franken.de> <20120128213857.GB39861@alchemy.franken.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: FreeBSD Net , FreeBSD Stable , Marius Strobl Subject: Re: 9-stable - ifmedia_set: no match for 0x0/0xfffffff X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:37:50 -0000 On Sun, Jan 29, 2012 at 01:19:40PM +0900, Randy Bush wrote: > > What happens if you set hw.bge.allow_asf to 0 and use auto-negotiation > > on both sides? > > it works! the switch was already auto-neg, and i forced auto-neg on the > server side. > Apart from suspend/resume issue, bge(4) still needs more code to handle controllers with ASF/IPMI firmware. This part is mostly undocumented and hard to experiment due to lack of hardware access. Current IPMI/ASF handling code shows mixed results and setting hw.bge.allow_asf to 0 will break IPMI support. > thanks. this was not pleasant. did i remember to whine that i am in > tokyo and the server is on the beast coast of the states? :) > > i think a bit of a warning about hw.bge.allow_asf in UPDATING might help > folk. > > thank you *very* much for your help. > > randy From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 04:50:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE86D1065672 for ; Wed, 15 Feb 2012 04:50:14 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A43BB8FC13 for ; Wed, 15 Feb 2012 04:50:14 +0000 (UTC) Received: from localhost.samsco.home (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id q1F4o4EE067266; Tue, 14 Feb 2012 21:50:04 -0700 (MST) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <20120214200258.GA29641@server.vk2pj.dyndns.org> Date: Tue, 14 Feb 2012 21:50:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> To: Peter Jeremy X-Mailer: Apple Mail (2.1251.1) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly 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, 15 Feb 2012 04:50:15 -0000 On Feb 14, 2012, at 1:02 PM, Peter Jeremy wrote: > On 2012-Feb-13 08:28:21 -0500, Gary Palmer = wrote: >> The filesystem is the *BEST* place to do caching. It knows what = metadata >> is most effective to cache and what other data (e.g. file contents) = doesn't >> need to be cached. >=20 > Agreed. >=20 >> Any attempt to do this in layers between the FS and >> the disk won't achieve the same gains as a properly written = filesystem.=20 >=20 > Agreed - but traditionally, Unix uses this approach via block devices. > For various reasons, FreeBSD moved caching into UFS and removed block > devices. Unfortunately, this means that any FS that wants caching has > to implement its own - and currently only UFS & ZFS do. >=20 > What would be nice is a generic caching subsystem that any FS can use > - similar to the old block devices but with hooks to allow the FS to > request read-ahead, advise of unwanted blocks and ability to flush > dirty blocks in a requested order with the equivalent of barriers > (request Y will not occur until preceeding request X has been > committed to stable media). This would allow filesystems to regain > the benefits of block devices with minimal effort and then improve > performance & cache efficiency with additional work. >=20 Any filesystem that uses bread/bwrite/cluster_read are already using the = "generic caching subsystem" that you propose. This includes UDF, = CD9660, MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local = storage filesystem in the tree except for ZFS. Not all of them = implement VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations = for the vnode pager, not requirements for using buffer-cache services on = block devices. As Kostik pointed out in a parallel email, the only = thing that was removed from FreeBSD was the userland interface to cached = devices via /dev nodes. This has nothing to do with filesystems, though = I suppose that could maybe sorta kinda be an issue for FUSE?. ZFS isn't in this list because it implements its own private = buffer/cache (the ARC) that understands the special requirements of ZFS. = There are good and bad aspects to this, noted below. > One downside of the "each FS does its own caching" in that the caches > are all separate and need careful integration into the VM subsystem to > prevent starvation (eg past problems with UFS starving ZFS L2ARC). >=20 I'm not sure what you mean here. The ARC is limited by available wired = memory; attempts to allocate such memory will evict pages from the = buffer cache as necessary, until all available RAM is consumed. If = anything, ZFS starves the rest of the system, not the other way around, = and that's simply because the ARC isn't integrated with the normal VM. = Such integration is extremely hard and has nothing to do with having a = generic caching subsystem. Scott From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 02:10:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6FB31065674 for ; Wed, 15 Feb 2012 02:10:56 +0000 (UTC) (envelope-from jflemingeds@yahoo.com) Received: from nm22.bullet.mail.ne1.yahoo.com (nm22.bullet.mail.ne1.yahoo.com [98.138.90.85]) by mx1.freebsd.org (Postfix) with SMTP id 8150B8FC1B for ; Wed, 15 Feb 2012 02:10:56 +0000 (UTC) Received: from [98.138.90.48] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2012 01:57:19 -0000 Received: from [98.138.89.164] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2012 01:57:19 -0000 Received: from [127.0.0.1] by omp1020.mail.ne1.yahoo.com with NNFMP; 15 Feb 2012 01:57:19 -0000 X-Yahoo-Newman-Id: 291307.19079.bm@omp1020.mail.ne1.yahoo.com Received: (qmail 99948 invoked from network); 15 Feb 2012 01:57:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=s6NqLA0zAwekmBpCatxFdhARGKADkf3ponvRzDRGP0Bn630HbW9KQ+OkHRiW7Ur5PXmhov9z9tg6XdYp4YZZf49wmTsFbBDCyzy0hS0eVl9V3Te8rUjiKeEZKyiIYQkAs8XhMYsBIumcSzUVKTS/e6Q+JKNuybGjxAEbEN8Zd4k= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1329271039; bh=DzQUbYiDbX5w2581Nxx+9tGgVWxabLy1eS8bs45uxDM=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:X-rim-org-msg-ref-id:Message-ID:Content-Transfer-Encoding:Reply-To:X-Priority:References:In-Reply-To:Sensitivity:Importance:Subject:To:Cc:From:Date:Content-Type:MIME-Version; b=J0B6lij6gc18pt+ksoOkRDtpAmE0PACQF12GOPKenojZMYZ8VFKnA0/g5sUmrSdwp5XMoSX+hLGXIaeXec0PRRhQWDH0Sq8jZ87X7/+DxcoX+1ibqpXsCXcIf9RejeCN/tBvhJIsbOlXIk1DH65LAWM5zLUXg6muPEjBDCL1irc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tC.QmckVM1n4IUFdPY3ccPzp4HgXfJrb8LqMP9sdtk7LVZU KrpXgGm7rdptGOCKmqUVkkbL6iccYOpEXwqVclAvrI4tva9gEU6LK2G.opMm KuR2ROpW0kei3aNiuk.sjrAAJB9lhOZjuTWXpR8AXUJAu4BA7mWW9OEL00_S VY.30Jx547eV8ykbguWapgp7K7RaUeTwJ2wQz4VzOH1anlle_EF7K9DNwoDQ I_pt87cqleA0Eyjm7oUfecR18vkdfpJVKmlfVI9ODPiSawZAjuTgamRCHi_a Y1lpSzzpnJhI99BudlDucfE0EbGwGNEk_TbF3ZikkGMtzdnewuRMV_tYCW4_ 773k5qECkAlVZTLVLPOjO7Al4.EW0kCyrYfNEh_.gz7ZaGfDmmFSUavrvQ9u lX.b76ckIOJEZBrMaqS3AqPdAJmyR X-Yahoo-SMTP: q2FSJ8mswBAC_rVZ2SKqQrZBUHBGa1B7 Received: from b5.c31.bise6.blackberry (jflemingeds@74.82.87.203 with xymcookie) by smtp113-mob.biz.mail.ne1.yahoo.com with SMTP; 14 Feb 2012 17:57:18 -0800 PST X-rim-org-msg-ref-id: 1056033736 Message-ID: <1056033736-1329271037-cardhu_decombobulator_blackberry.rim.net-225645010-@b15.c31.bise6.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> <20120214051828.GA89777@icarus.home.lan> In-Reply-To: <20120214051828.GA89777@icarus.home.lan> Sensitivity: Normal Importance: Normal To: "Jeremy Chadwick" From: jflemingeds@yahoo.com Date: Wed, 15 Feb 2012 01:57:17 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 15 Feb 2012 05:36:31 +0000 Cc: "freebsd-stable@freebsd.org" Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jflemingeds@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:10:56 -0000 MiBvZiB0aGUgMyBjZiBjYXJkcyBhcmUgdmVyeSBuZXcsIGxpa2UgbGVzcyB0aGVuIDYgbW9udGhz IG9sZC4gDQoNCkkgdGhpbmsgYXJvdW5kIDY1LTcwIHBlcmNlbnQgaXMgaW4gdXNlLiBUaGlzIG51 bWJlciBkb2Vzbid0IGNoYW5nZSB1bmxlc3MgdGhlIHVzZXIgZHVtcHMgZGF0YSBpbiBhIGhvbWUg ZGlyLCB3aGljaCBpc24ndCB0aGUgY2FzZSBzbyBmYXIuIA0KDQpZb3UgYXJlIGNvcnJlY3QgdGhh dCBvbmx5IHdyaXRlcyBhcmUgZmFpbGluZy4gTXNnYnVmIGhhcyBtb3JlIHRoZW4gd2hhdCBJIHBh c3RlZCBidXQgSSdtIHByZXR0eSBzdXJlIGl0cyBqdXN0IG1vcmUgb2YgdGhlIHNhbWUgZXJyb3Jz LiBJbGwgcmVkb3VibGUgbXkgY2hlY2suIA0KDQpUaGUgb3RoZXIgc2xpY2VzIGFyZSB2ZXJ5IHNt YWxsLiBPbmUgaXMgMzUgbWVnIHRoZSBvdGhlciBpcyAxMDAgc29tZSBvZGQgbWVnLiBIIGlzIDEu MiBnaWcuICANCg0KSSBkb24ndCBrbm93IGlmIGlsbCBiZSBhYmxlIHRvIHRyeSB0aGUgZGQgdGVz dCBmb3IgYSBmZXcgcmVhc29ucyBidXQgaWxsIGNoZWNrIGl0IG91dC4gTGV0IG1lIGFzayB5b3Ug dGhpcy4gU2F5IHplcm9pbmcgb3V0IHRoZSBkcml2ZSB3b3JrcyB3aXRob3V0IGVycm9yLiBEb2Vz IHRoYXQgdGVsbCBtZSBhbnl0aGluZz8gIA0KDQpJIGFsc28gZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8g c21hcnQgdG9vbHMgYXMgdGhpcyBpcyBiYXNpY2FsbHkgYSBjbG9zZWQgc3lzdGVtIGFuZCB0aGUg dmVuZG9yIHdvdWxkIG5ldmVyIGdpdmUgdXMgYWNjZXNzIHRvIGEgY29tcGxpZXIuIEdyYW50ZWQg SSBoYXZlbid0IHRyaWVkIGp1c3QgdGhyb3dpbmcgb24gZ2NjIGZyb20gNi4yLiBJIGNvdWxkIHBs YXkgd2l0aCB0aGF0IG9yIG1heWJlIHNpbmNlIHNhaWQgdmVuZG9yJ3MgZGV2IHRlYW0gaXMga2Vl cGluZyB0cmFjayBvZiB0aGlzIHRocmVhZCB0aGV5IGNvdWxkIHByb3ZpZGUgc2FpZCBiaW5hcnkg OikuIA0KDQpJIHJlYWxseSBkb24ndCBsaWtlIHRoZSBpZGVhIG9mIHJlcGxhY2luZyBoYXJkd2Fy ZSBhcyBJJ20gbG9va2luZyBhdCBhcm91bmQgMjAwIGJveGVzLiBJIHJlYWxseSBob3BlIGl0IGRv ZXNuJ3QgY29tZSB0byB0aGF0LiANCg0KVGhhbmtzIGZvciB0aGUgcmVwbHkhDQoNClNlbnQgdmlh IEJsYWNrQmVycnkgZnJvbSBULU1vYmlsZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogSmVyZW15IENoYWR3aWNrIDxmcmVlYnNkQGpkYy5wYXJvZGl1cy5jb20+DQpEYXRlOiBN b24sIDEzIEZlYiAyMDEyIDIxOjE4OjI4IA0KVG86IGpvaG4gZmxlbWluZzxqZmxlbWluZ2Vkc0B5 YWhvby5jb20+DQpDYzogZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc8ZnJlZWJzZC1zdGFibGVA ZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiBSZTogNi4yLVJlbGVhc2UgLi5pc2guLiBDRiArIGF0YSA9 PSBmcmVlemU/DQoNCk9uIE1vbiwgRmViIDEzLCAyMDEyIGF0IDA4OjQzOjA4UE0gLTA4MDAsIGpv aG4gZmxlbWluZyB3cm90ZToNCj4gSnVzdCB0aG91Z2h0IGkgd291bGQgcG9zdCBvdmVyIGhlcmUg YXMgaSdtIG5vdCBnZXR0aW5nIGEgd2FybSBmdXp6eSBmcm9tIGNoZWNrcG9pbnQgYWJvdXQgYmVp bmcgYWJsZSB0byBmaW5kIHRoZSByb290IGNhdXNlIG9mIGFuIGlzc3VlLiBJIGhhdmUgYSBsYXJn ZSBpbnN0YWxsIGJhc2Ugb2YgSVBTTyBjaGVja3BvaW50IGZpcmV3YWxscywgd2hpY2ggYXJlIGJh c2VkIG9uIEZyZWVCU0QgNi4yLiBJJ3ZlIGhhZCAzIGZpcmV3YWxscyBoYW5nIGJhc2ljYWxseSB0 aGUgc2FtZSB3YXksIHdpdGggc29tZXRoaW5nIHRoYXQgbG9va3MgbGlrZSBhIGZpbGVzeXN0ZW0g aXNzdWUgb3IgYW4/aXNzdWUgd2l0aCBhIENGIGNhcmQuIA0KDQpGcmVlQlNEIDYuMiB3YXMgRU9M J2QgaW4gZWFybHktdG8tbWlkLTIwMDguICBUaGUgQVRBIGRyaXZlciBoYXMgY2hhbmdlZA0Kc2ln bmlmaWNhbnRseSBzaW5jZSB0aGVuIChwcmVzZW50LWRheSB1c2VzIENBTSkuDQoNCj4gRG9lcyBh bnlvbmUgaGFwcGVuIHRvIGtub3cgb2YgYW55IGJ1Z3MgKGkndmUgYmVlbiBsb29raW5nIGFyb3Vu ZCkgdGhhdCBjb3VsZCBjYXVzZSBzb21ldGhpbmcgbGlrZSB0aGF0PyBHcmFudGVkLCBpdCBjb3Vs ZCBiZSBhIGJhdGNoIG9mIGJhZCBDRiBjYXJkcywgYnV0IGl0cyBvZGQgdGhhdCBpJ20gc2VlaW5n IHRoZSBzYW1lIHRoaW5nIG9uIDMgZGlmZmVyZW50IGJveGVzIGFuZCBvbmNlIHJlYm9vdGVkIHRo ZXkgc2VlbSBvay4NCj4gPw0KPiBBbHNvIGlzIGl0IHBvc3NpYmxlIHRvIGdldCB1c2VmdWwgaW5m byBmb3JtIHRoZSBhdGFjb250cm9sbGVyIHdoZW4gdGhpbmdzIGdvIHNvdXRoIGxpa2UgdGhpcyBm cm9tIHRoZSBkZGIgcHJvbXB0Pw0KDQpOb3QgcGFydGljdWxhcmx5LiAgV2hhdCdzIHNob3duIGJl bG93IGluZGljYXRlcyB0aGF0IHRoZSBkcml2ZXIgaGFkDQppc3N1ZWQgc29tZSBmb3JtIG9mIEFU QSB3cml0ZSBjb21tYW5kICh0aGVyZSBhcmUgbXVsdGlwbGUga2luZHMgcGVyIEFUQQ0Kc3BlY2lm aWNhdGlvbiksIGFuZCBlaXRoZXIgdGhlIHVuZGVybHlpbmcgbWVkaWEgKENGL2Rpc2spIG9yIGNv bnRyb2xsZXINCnN0YWxsZWQvbG9ja2VkIHVwL3Rvb2sgdG9vIGxvbmcuICBJIGZvcmdldCB3aGF0 IHRoZSB0aW1lb3V0IHZhbHVlIGlzIGluDQo2LjI7IEkgY2FuJ3QgYmUgYm90aGVyZWQgdG8gcmVt ZW1iZXIgc3VjaCBmcm9tIDYgeWVhcnMgYWdvLiAgOi0pDQoNCj4gVGhpcyBpcyB3aGF0IHNob3dz IGluIHNob3cgbXNnYnVmDQo+IGFkMDogdGltZW91dCB3YWl0aW5nIHRvIGlzc3VlIGNvbW1hbmQN Cj4gYWQwOiBlcnJvciBpc3N1aW5nIFdSSVRFIGNvbW1hbmQNCj4gYWQwOiB0aW1lb3V0IHdhaXRp bmcgdG8gaXNzdWUgY29tbWFuZA0KPiBhZDA6IGVycm9yIGlzc3VpbmcgV1JJVEUgY29tbWFuZA0K PiBhZDA6IHRpbWVvdXQgd2FpdGluZyB0byBpc3N1ZSBjb21tYW5kDQo+IGFkMDogZXJyb3IgaXNz dWluZyBXUklURSBjb21tYW5kDQo+IGFkMDogdGltZW91dCB3YWl0aW5nIHRvIGlzc3VlIGNvbW1h bmQNCj4gYWQwOiBlcnJvciBpc3N1aW5nIFdSSVRFIGNvbW1hbmQNCj4gZ192ZnNfZG9uZSgpOmFk MHM0aFtXUklURShvZmZzZXQ9MzM4NDkzNDQsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNSANCj4g Z192ZnNfZG9uZSgpOmFkMHM0aFtXUklURShvZmZzZXQ9MzM5ODA0MTYsIGxlbmd0aD0xMzEwNzIp XWVycm9yID0gNSANCj4gZ192ZnNfZG9uZSgpOmFkMHM0aFtXUklURShvZmZzZXQ9MzQxMTE0ODgs IGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNQ0KPiA/Z192ZnNfZG9uZSgpOmFkMHM0aFtXUklURShv ZmZzZXQ9MzQyNDI1NjAsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNSANCj4gZ192ZnNfZG9uZSgp OmFkMHM0aFtXUklURShvZmZzZXQ9MzQzNzM2MzIsIGxlbmd0aD0xMzEwNzIpXWVycm9yID0gNSAN Cg0KZXJyb3IgNSA9IEVJTyA9IElucHV0L291dHB1dCBlcnJvci4gIEJ1dCB0aGlzIGlzbid0IHRv byBiaWcgb2YgYQ0Kc3VycHJpc2UgZ2l2ZW4gdGhlIHRpbWVvdXRzIHlvdSBzZWUgcHJpb3IuDQoN CkFyZSB0aGVzZSBDRiBjYXJkcyBicmFuZCBuZXcgLS0gbWVhbmluZywgYXJlIHRoZXkgY29tcGxl dGVseSB1bnVzZWQNCihoYXZpbmcgbmV2ZXIgaGFkIGFueSB3cml0ZXMgZG9uZSB0byB0aGVtKSwg b3IgaGF2ZSB0aGV5IGJlZW4gaW4gdXNlIGENCndoaWxlPyAgSSdtIGJldHRpbmcgdGhleSd2ZSBi ZWVuIGluIHVzZSBhIHdoaWxlLCBhbmQgaGF2ZSBwcm9iYWJseSBiZWVuDQpkb2luZyBtYW55IHdy aXRlcyBvdmVyIHRoZSB5ZWFycy4NCg0KVHdvIHRoaW5ncyB0byBub3RlIGhlcmU6DQoNCjEpIFRo ZSBlcnJvcnMgeW91J3ZlIHNob3duIGFyZSBvbmx5IGhhcHBlbmluZyBvbiB3cml0ZXMsIG5vdCBy ZWFkcy4gIE9mDQpjb3Vyc2UgaWYgeW91IG9taXR0ZWQgaW5mb3JtYXRpb24gdGhlbiB0aGlzIGlz bid0IGFuIGFjY3VyYXRlIHN0YXRlbWVudC4NCjIpIFRpbWVvdXRzIGFyZSBzZWVuIHdoZW4gaXNz dWluZyB3cml0ZXMgdG8gc29tZSBMQkEgcmVnaW9ucy4NCg0KSG93IGZ1bGwgaXMgdGhlIENGIGNh cmQsIGRpc2stc3BhY2Utd2lzZT8gIE5vdCBqdXN0IGFkMHM0aCwgSSdtIHRhbGtpbmcNCmFib3V0 IHRoZSBlbnRpcmUgY2FyZC4gIEhvdyBtdWNoIHNwYWNlIGlzIHJvdWdobHkgYXZhaWxhYmxlPyAg VGhleSdyZQ0KdmVyeSBzbWFsbCBDRiBjYXJkcyAoMS44R0J5dGUgcm91Z2hseSksIGFuZCB0aGUg bGVzcyBzcGFjZSBhdmFpbGFibGUsDQp0aGUgbGVzcyBlZmZlY3RpdmVuZXNzIG9mIHdlYXIgbGV2 ZWxsaW5nIChhbmQgaW4gc29tZSBjYXNlcyB0aGUgc2xvd2VyDQp0aGUgd3JpdGVzIGFyZSkuDQoN ClJlYXNvbiBJIGFzazogZ2l2ZW4gdGhhdCB0aGVzZSBhcmUgQ0YgY2FyZHMsIHRoaXMgc21lbGxz IG9mIGNhcmRzIHdoaWNoDQphcmUgc2ltcGx5ICJ3b3JuIGRvd24iLiAgQ0YgY2FyZHMgaGF2ZSBs aW1pdGVkIG51bWJlcnMgb2Ygd3JpdGVzLCBhbmQNCnRoZSBjYXJkIG1heSBiZSAiZnJlYWtpbmcg b3V0IiBpbnRlcm5hbGx5IHdoZW4gYXR0ZW1wdGluZyB0byB3cml0ZSB0bw0Kc29tZSBMQkFzIHdo aWNoIG1hcCB0byBDRiBzZWN0b3JzIHRoYXQgYXJlLCBpbiBlZmZlY3QsICJiYWQiLiAgVGhlIENG DQpjYXJkcycgRUNDIGltcGxlbWVudGF0aW9uIG1heSBiZSBidWdneSwgb3IgbWF5IHNpbXBseSBi ZSAic3Bpbm5pbmcgaGFyZCINCmZvciB0b28gbG9uZy4gIFlvdSBjYW4gcmVhZCBhYm91dCB0aGlz IHNvcnQgb2YgYmVoYXZpb3VyIG9uIFdpa2lwZWRpYSdzDQpDb21wYWN0Rmxhc2ggYXJ0aWNsZS4N Cg0KWW91IHdvdWxkbid0IGJlIGFibGUgdG8gdmVyaWZ5IHRoaXMgd2l0aCBkZCBpZj0vZGV2L2Fk MCwgYmVjYXVzZSB0aG9zZQ0KYXJlIHJlYWQgb3BlcmF0aW9ucy4gIFlvdSBjb3VsZCB6ZXJvIHRo ZSBtZWRpYSAoZGQgaWY9L2Rldi96ZXJvDQpvZj0vZGV2L2FkMCkgYXMgYSBmb3JtIG9mIHZlcmlm aWNhdGlvbiBpZiB5b3Ugd2FudGVkLg0KDQpEbyB5b3UgaGFwcGVuIHRvIGtub3cgaWYgdGhlc2Ug Q0YgY2FyZHMgc3VwcG9ydCBTTUFSVD8gIElmIHNvLA0KaW5zdGFsbGluZyBzbWFydG1vbnRvb2xz ICh2ZXJzaW9uIDUuNDIgb3IgbmV3ZXIgcGxlYXNlKSBhbmQgcHJvdmlkaW5nDQpvdXRwdXQgZnJv bSAic21hcnRjdGwgLWEgL2Rldi9hZDAiIG1heSBiZSBoZWxwZnVsIHRvIG1lLCBidXQgSSBtYWtl IG5vDQpndWFyYW50ZWVzIGFueXRoaW5nIG9mIHVzZSB3aWxsIGJlIHNob3duIHRoZXJlLg0KDQpP dmVyYWxsIG15IGFkdmljZSB3b3VsZCBiZSB0byByZXBsYWNlIHRoZSBDRiBjYXJkcywgZXNwZWNp YWxseSBpZiB0aGV5DQpoYXZlIGJlZW4gaW4gdXNlIGZvciBhIGxvbmcgd2hpbGUuICBJdCByZWFs bHkgZG9lc24ndCBtYXR0ZXIgdG8gbWUgdGhhdA0KaXQncyBoYXBwZW5pbmcgb24gMyBtYWNoaW5l cyAoaG9uZXN0KSwgZXNwZWNpYWxseSBpZiB0aGVzZSBhcmUgNi4yDQptYWNoaW5lcyB3aXRoIENG IGNhcmRzIHRoYXQgaGF2ZSBiZWVuIGluIHVzZSBmb3IgeWVhcnMuICBXZSdyZSBsdWNreSB0bw0K Z2V0IDIgeWVhcnMgb3V0IG9mIG91ciBDRiBjYXJkcyBvbiBvdXIgSnVuaXBlciBNMTIwLzMyMHMg YmVmb3JlIHRoZXkNCnN0YXJ0IHNwaXR0aW5nIEkvTyBlcnJvcnMuICBQaWNrIGxhcmdlciBDRiBj YXJkcyBhcyB3ZWxsOyBtb3JlIHNwYWNlID0NCm1vcmUgcm9vbSBmb3IgZWZmZWN0aXZlIHdlYXIg bGV2ZWxsaW5nLg0KDQo+ID8NCj4gYWQwOiAxODgyTUIgPFNURUMgTTIrIENGIDkuMC4yIEsxMTg2 LTI+IGF0IGF0YTAtbWFzdGVyIFBJTzQNCj4gYXRhcGNpMDogPEludGVsIDYzMDBFU0IgVURNQTEw MCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4MTc3LDB4Mzc2LDB4 NTA3MC0weDUwN2YgbWVtIDB4ODAzMDEwMDAtMHg4MDMwMTNmZiBhdCBkZXZpY2UgMzEuMSBvbiBw Y2kwDQo+IGF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQo+IGF0YTE6IDxBVEEgY2hh bm5lbCAxPiBvbiBhdGFwY2kwDQo+IGF0YXBjaTE6IDxJbnRlbCA2MzAwRVNCIFNBVEExNTAgY29u dHJvbGxlcj4gcG9ydCAweDUwODgtMHg1MDhmLDB4NTBhNC0weDUwYTcsMHg1MDgwLTB4NTA4Nyww eDUwYTAtMHg1MGEzLDB4NTA2MC0weDUwNmYgaXJxIDE1IGF0IGRldmljZSAzMS4yIG9uIHBjaTAN Cj4gYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTENCj4gYXRhMzogPEFUQSBjaGFubmVs IDE+IG9uIGF0YXBjaTFhZDBzNGggaXMgYmFzaWNhbGx5IGEgci93IHVmcyBwYXJ0aXRpb24gb24g dGhlIGJveCB3aGVyZSBhbG1vc3QgYW55dGhpbmcgdGhhdCBuZWVkcyB0byBiZSB3cml0dGVuIGdv ZXMuDQo+IHRyYWNlDQo+IFRyYWNpbmcgcGlkIDExMDEgdGlkIDEwMDA0MyB0ZCAweDY1NmQ4NDYw DQo+IGtkYl9lbnRlcig2MDhjYzM4OCw2MjQ2LDY1NmQ4NDYwLDY0YmExNDAwLDYwOTVkNTgwLC4u LikgYXQga2RiX2VudGVyKzB4MmINCj4gc2lvaW50cjEoNjRiYTE0MDApIGF0IHNpb2ludHIxKzB4 ZjANCj4gc2lvaW50cig2NGJhMTQwMCkgYXQgc2lvaW50cisweDM4DQo+IGludHJfZXhlY3V0ZV9o YW5kbGVyKDYwOTVkNTgwLGYwYTRhYjA0LDYsNjA5NWQ1ODAsZjBhNGFhZmMsLi4uKSBhdCBpbnRy X2V4ZWN1dGVfaGFuZGxlcisweDYxDQo+IGludHJfZXhlY3V0ZV9oYW5kbGVycyg2MDk1ZDU4MCxm MGE0YWIwNCw2LDAsNjU2ZDg0NjAsLi4uKSBhdCBpbnRyX2V4ZWN1dGVfaGFuZGxlcnMrMHg0MA0K PiBhdHBpY19oYW5kbGVfaW50cig0KSBhdCBhdHBpY19oYW5kbGVfaW50cisweDk2DQo+IFhhdHBp Y19pbnRyNCgpIGF0IFhhdHBpY19pbnRyNCsweDIwDQo+IC0tLSBpbnRlcnJ1cHQsIGVpcCA9IDB4 NjA2MDQ0YWYsIGVzcCA9IDB4ZjBhNGFiNDgsIGVicCA9IDB4ZjBhNGFiNWMgLS0tDQo+IGxvY2tt Z3IoZTE0NTZhMDQsNiwwLDY1NmQ4NDYwKSBhdCBsb2NrbWdyKzB4NThmDQo+IGdldGRpcnR5YnVm KGUxNDU2OWE0LDYwYTQwNWU0LDEpIGF0IGdldGRpcnR5YnVmKzB4MmUyDQo+IGZsdXNoX2RlcGxp c3QoNjhiMzA4NTAsMSxmMGE0YWJiOCkgYXQgZmx1c2hfZGVwbGlzdCsweDMwDQo+IGZsdXNoX2lu b2RlZGVwX2RlcHMoNjU2ZmEyOGMsMWYyMzUpIGF0IGZsdXNoX2lub2RlZGVwX2RlcHMrMHhjZg0K PiBzb2Z0ZGVwX3N5bmNfbWV0YWRhdGEoNjU5NjQ2MTgpIGF0IHNvZnRkZXBfc3luY19tZXRhZGF0 YSsweDYxDQo+IGZmc19zeW5jdm5vZGUoNjU5NjQ2MTgsMSkgYXQgZmZzX3N5bmN2bm9kZSsweDNh Mg0KPiBmZnNfZnN5bmMoZjBhNGFjNzQpIGF0IGZmc19mc3luYysweDEyDQo+IFZPUF9GU1lOQ19B UFYoNjA5NDkyNjAsZjBhNGFjNzQpIGF0IFZPUF9GU1lOQ19BUFYrMHgzOA0KPiBmc3luYyg2NTZk ODQ2MCxmMGE0YWNiNCkgYXQgZnN5bmMrMHgxNzANCj4gc3lzY2FsbCg4MDUwMDNiLDgwNjAwM2Is NWZiZjAwM2IsODA1MDAwMCwyODhiZTQ1MCwuLi4pIGF0IHN5c2NhbGwrMHgyZWUNCj4gWGludDB4 ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgxZg0KDQotLSANCnwgSmVyZW15IENo YWR3aWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgamRjQHBhcm9kaXVzLmNvbSB8 DQp8IFBhcm9kaXVzIE5ldHdvcmtpbmcgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnBh cm9kaXVzLmNvbS8gfA0KfCBVTklYIFN5c3RlbXMgQWRtaW5pc3RyYXRvciAgICAgICAgICAgICAg ICAgTW91bnRhaW4gVmlldywgQ0EsIFVTIHwNCnwgTWFraW5nIGxpZmUgaGFyZCBmb3Igb3RoZXJz IHNpbmNlIDE5NzcuICAgICAgICAgICAgIFBHUCA0QkQ2QzBDQiB8DQoNCg== From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 05:38:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1D51065679; Wed, 15 Feb 2012 05:38:37 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 1F33F8FC13; Wed, 15 Feb 2012 05:38:37 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1F5caOU047173; Wed, 15 Feb 2012 05:38:36 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1F5ca9C047148; Wed, 15 Feb 2012 05:38:36 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Feb 2012 05:38:36 GMT Message-Id: <201202150538.q1F5ca9C047148@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:38:37 -0000 TB --- 2012-02-15 04:26:47 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-15 04:26:47 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-02-15 04:26:47 - cleaning the object tree TB --- 2012-02-15 04:27:08 - cvsupping the source tree TB --- 2012-02-15 04:27:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2012-02-15 04:32:32 - building world TB --- 2012-02-15 04:32:32 - CROSS_BUILD_TESTING=YES TB --- 2012-02-15 04:32:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-15 04:32:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-15 04:32:32 - SRCCONF=/dev/null TB --- 2012-02-15 04:32:32 - TARGET=ia64 TB --- 2012-02-15 04:32:32 - TARGET_ARCH=ia64 TB --- 2012-02-15 04:32:32 - TZ=UTC TB --- 2012-02-15 04:32:32 - __MAKE_CONF=/dev/null TB --- 2012-02-15 04:32:32 - cd /src TB --- 2012-02-15 04:32:32 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 15 04:32:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Feb 15 05:32:53 UTC 2012 TB --- 2012-02-15 05:32:53 - generating LINT kernel config TB --- 2012-02-15 05:32:53 - cd /src/sys/ia64/conf TB --- 2012-02-15 05:32:53 - /usr/bin/make -B LINT TB --- 2012-02-15 05:32:53 - cd /src/sys/ia64/conf TB --- 2012-02-15 05:32:53 - /usr/sbin/config -m LINT TB --- 2012-02-15 05:32:53 - building LINT kernel TB --- 2012-02-15 05:32:53 - CROSS_BUILD_TESTING=YES TB --- 2012-02-15 05:32:53 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-15 05:32:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-15 05:32:53 - SRCCONF=/dev/null TB --- 2012-02-15 05:32:53 - TARGET=ia64 TB --- 2012-02-15 05:32:53 - TARGET_ARCH=ia64 TB --- 2012-02-15 05:32:53 - TZ=UTC TB --- 2012-02-15 05:32:53 - __MAKE_CONF=/dev/null TB --- 2012-02-15 05:32:53 - cd /src TB --- 2012-02-15 05:32:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Feb 15 05:32:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_eth_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/mxge/mxge_rss_ethp_z8e.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/my/if_my.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/netmap/netmap.c cc1: warnings being treated as errors /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_init': /src/sys/dev/netmap/netmap.c:522: warning: integer overflow in expression *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-15 05:38:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-15 05:38:36 - ERROR: failed to build LINT kernel TB --- 2012-02-15 05:38:36 - 3244.71 user 487.03 system 4308.70 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 06:27:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2484106564A for ; Wed, 15 Feb 2012 06:27:20 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6C3A98FC0C for ; Wed, 15 Feb 2012 06:27:20 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so3862993wgb.1 for ; Tue, 14 Feb 2012 22:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xlaz9rT9RtG/b9KzW3Ch2IhEBSE76nSgsqnumWByBkM=; b=cb0b264s6GAlqglQP2pz6tXzWxw9RZqV2uZ+GFNsE/7aEIVAfr0DbHQ+xb2uRdqyGT 9Pz6YiLpWJpxjR6zrF6S6f2bSQzka2PDzAdZqPRP54VKty4mINAr0siQ0kfVoH+aYZ5f cdQIU81f8TAwtR86BKWIVTmTrMPfpsbufoW14= MIME-Version: 1.0 Received: by 10.180.24.166 with SMTP id v6mr6451191wif.10.1329287239337; Tue, 14 Feb 2012 22:27:19 -0800 (PST) Received: by 10.223.62.70 with HTTP; Tue, 14 Feb 2012 22:27:19 -0800 (PST) In-Reply-To: References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> Date: Wed, 15 Feb 2012 00:27:19 -0600 Message-ID: From: Adam Vande More To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: disk devices speed is ugly 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, 15 Feb 2012 06:27:21 -0000 On Tue, Feb 14, 2012 at 10:50 PM, Scott Long wrote: > > Any filesystem that uses bread/bwrite/cluster_read are already using the > "generic caching subsystem" that you propose. This includes UDF, CD9660, > MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage > filesystem in the tree except for ZFS. Not all of them implement > VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vnode > pager, not requirements for using buffer-cache services on block devices. > As Kostik pointed out in a parallel email, the only thing that was removed > from FreeBSD was the userland interface to cached devices via /dev nodes. > Does this mean the Architecture Handbook page is wrong?: http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 06:43:32 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E27106566C; Wed, 15 Feb 2012 06:43:32 +0000 (UTC) (envelope-from gcr+freebsd-stable@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 3D38B8FC08; Wed, 15 Feb 2012 06:43:31 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.5/8.14.5) with ESMTP id q1F6hQdK053482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 00:43:26 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2012; t=1329288207; bh=kbLBgJhdShYY2FeHZhyBwnrAxI78J0p9grMYv3onsmI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=M9puzY6OEqO1ymdrG2HP1i+jdUcp8GQ1uKu3eIXJaxypChIBJiDqJOTgC+5QRpMg0 g77ru9RbbLtHu82qheFTmWEOrGjBVQnmRdzIGLx5X+pgaYAOaYRH3sekuMDSNSs4sU L88Lue4YcRXXgIqOFlZnZ/9YayRykpet8SQuyYMA= Date: Wed, 15 Feb 2012 00:43:21 -0600 (CST) From: Greg Rivers To: Florian Smeets In-Reply-To: <4F3A8E3E.9020901@FreeBSD.org> Message-ID: References: <20120214171446.2a5e5eb1.fk@fabiankeil.de> <4F3A8E3E.9020901@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (roadkill.tharned.org [75.145.12.185]); Wed, 15 Feb 2012 00:43:27 -0600 (CST) Cc: Fabian Keil , mlaier@FreeBSD.org, freebsd-stable@FreeBSD.org, Patrick Lamaiziere Subject: Re: sysutils/pftop on 9.x+ 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, 15 Feb 2012 06:43:32 -0000 On Tue, 14 Feb 2012, Florian Smeets wrote: > On 14.02.12 17:14, Fabian Keil wrote: >> Greg Rivers wrote: >> >>> sysutils/pftop was marked broken on 9.x and above last March[1]. Are >>> there any plans to fix it soon? It's a really handy utility. >>> >>> [1] >>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 >> >> Please have a look at: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=155938 >> >> Note that the currently working fix is in the audit trail, >> the original fix stopped working after the PF update. > > The PR was closed by mistake, I'll take care of it. > Thanks for committing the fix, Florian. pftop now builds and runs fine; tested on recent 9.0-STABLE amd64. Thanks also to Patrick for his input and especially to Fabian for creating the patches and filing the PR. -- Greg Rivers From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 07:07:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E2D106566B for ; Wed, 15 Feb 2012 07:07:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D20638FC08 for ; Wed, 15 Feb 2012 07:07:21 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1F77J2v001628 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Feb 2012 23:07:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3B5A01.4090109@freebsd.org> Date: Tue, 14 Feb 2012 23:08:49 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Jeremy Chadwick References: <4F3A1A19.7010803@freebsd.org> <4F3AEFA5.1020906@freebsd.org> <20120215002036.GA9938@icarus.home.lan> In-Reply-To: <20120215002036.GA9938@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: freebsd 9-stable TOP problem from around Jan 10 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, 15 Feb 2012 07:07:22 -0000 On 2/14/12 4:20 PM, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 03:35:01PM -0800, Julian Elischer wrote: >> On 2/14/12 10:38 AM, Kevin Oberman wrote: >>> On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer wrote: >>>> Has anyone else seen a problem with top -H -S? >>>> >>>> after a short while the screen gets more and more corrupted.. >>>> >>>> hitting ^L or turning off S& H modes helps .. for a while. >>>> >>>> If this is a known fixed problem, let me know but I need to co-ordinate with >>>> others >>>> to upgrade the machine in question. >>> Not seeing it here on 9-stable. Could it be a display issue? I am >>> using gnome-terminal with TERM defined as 'xterm'. >> yeah I'm on a mac with iterm, but running through 'screen' . >> >> it's never been a problem before.. just since we upgraded to 9-stable. > If you remove GNU screen from the picture does the problem go away? If > so, I'm not surprised. :-) > > Make sure that when you're using GNU screen, that all shells launched > "under/within" screen have TERM=screen. If they don't, then this is > almost certainly the problem -- GNU screen "translates" between terminal > types, meaning it translates its own terminal type ("screen") into > whatever TERM is currently attached ("xterm", "iterm", whatever). See > the last 4 paragraphs of my post here to understand what exactly GNU > screen is doing: > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html > > So, in general, make sure your dotfiles and so on don't mess about with > the $TERM environment variable and you should generally be okay. it seems to have stopped doing it for no apparent reason will keep an eye on it. and save this email away for when it does it again. > If within GNU screen TERM=screen and you see the problem, but outside of > screen you use TERM=xterm (or something else) but don't see the problem, > then I would almost certainly blame GNU screen. If you're looking for > something that simply keeps a terminal running in the background, try > nohup or tmux. > > Alternately, possibly someone added a "screen" entry to /etc/termcap on > RELENG_9? I don't use 9 so I have no way to confirm this, but on 8 > there is no such entry. SC|screen|VT 100/ANSI X3.64 virtual terminal:\ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 08:26:58 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090B9106564A for ; Wed, 15 Feb 2012 08:26:58 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 669D28FC0C for ; Wed, 15 Feb 2012 08:26:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q1F8Qpn7045667; Wed, 15 Feb 2012 12:26:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q1F8QpL4045666; Wed, 15 Feb 2012 12:26:51 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Feb 2012 12:26:51 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20120215082651.GO20404@glebius.int.ru> References: <4F3A9237.5080901@barafranca.com> <4F3ADA5E.4060800@barafranca.com> <1A41718A-076E-4EA8-9417-AF19FA8911E3@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1A41718A-076E-4EA8-9417-AF19FA8911E3@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, Hugo Silva Subject: Re: CARP carpdev 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, 15 Feb 2012 08:26:58 -0000 On Wed, Feb 15, 2012 at 02:33:43AM +0000, Bjoern A. Zeeb wrote: B> > On 02/14/12 17:33, Freddie Cash wrote: B> >> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote: B> >>> Looks like there's been conversations about porting this to FreeBSD since at B> >>> least 2007. B> >>> B> >>> Are there any plans to have ifconfig carpdev available in 9.0-STABLE? B> >> B> >> CARP support has been redone in 10-CURRENT, removing the whole "carp0" B> >> pseudo-interface support, and just enabling the CARP protocol on the B> >> existing network interfaces. This includes the equivalent of "carpdev" B> >> support. B> >> B> >> Search the -current archives for more information, CFT, and so on. B> >> B> >> I don't recall seeing anything about specific plans to MFC to B> >> stable/9, but could be mis-remembering things. B> >> B> > B> > B> > http://svnweb.freebsd.org/base?view=revision&revision=228571 B> > B> > The single IP limitation may be a problem in some locations.. B> > B> > Did not find anything about a possible MFC either. glebius@ is cc'd, perhaps he can add something, but based on http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been MFCd (there's a primer for the new carp in current's UPDATING)\ B> B> B> There's no plans to MFC given it changes things significantly. B> B> I however wonder if someone wants to provide a user branch in SVN to B> provide regular patchsets for stable/9 and maybe even stable/8 (8.3R) B> to help people not going to HEAD? If you are hinting at me, I would not :P To get benefits of new carp(4) and updated pf(4) I'm running head in production. What I can do is providing information about exact revisions that I am running. Usually I update a single router, and wait for some time to prove its stability, then roll out a release from that revision and update other routers. -- Totus tuus, Glebius. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 08:29:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3FCF106566C; Wed, 15 Feb 2012 08:29:10 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 23E2D8FC17; Wed, 15 Feb 2012 08:29:09 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 86AFC39844; Wed, 15 Feb 2012 09:29:05 +0100 (CET) Date: Wed, 15 Feb 2012 09:29:05 +0100 From: Victor Balada Diaz To: Jeremy Chadwick Message-ID: <20120215082905.GV2010@equilibrium.bsdes.net> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> <20120214233420.GU2010@equilibrium.bsdes.net> <20120215001020.GA9386@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120215001020.GA9386@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 08:29:11 -0000 On Tue, Feb 14, 2012 at 04:10:20PM -0800, Jeremy Chadwick wrote: > I'm too tired to quite understand (in full) what's wrong with my patch, > but I think you're referring to situations where someone would have > kern.cam.ada.X.quirks set in loader.conf? > > If so, I believe that same situation would happen presently if someone > set kern.cam.ada.X.quirks in their loader.conf to a value that did not > contain bit #0 set to 1, and used one of the 4K sector disks listed in > ada_quirk_table -- what's in loader.conf looks like it would overwrite > whatever the kernel code bits chose automatically: > > 910 match = cam_quirkmatch((caddr_t)&cgd->ident_data, > 911 (caddr_t)ada_quirk_table, > 912 sizeof(ada_quirk_table)/sizeof(*ada_quirk_table), > 913 sizeof(*ada_quirk_table), ata_identify_match); > 914 if (match != NULL) > 915 softc->quirks = ((struct ada_quirk_entry *)match)->quirks; > 916 else > 917 softc->quirks = ADA_Q_NONE; > ... > 931 snprintf(announce_buf, sizeof(announce_buf), > 932 "kern.cam.ada.%d.quirks", periph->unit_number); > 933 quirks = softc->quirks; > 934 TUNABLE_INT_FETCH(announce_buf, &quirks); > 935 softc->quirks = quirks; > > I read this to mean: > > Lines 910-917 -- if there's a device ID string match in ada_quirk_table, > set softc->quirks to the content of that struct entry. So, for example, > 4K sector disks would set softc->quirks to 0x01. > > Lines 931-933 -- assign the "quirks" variable to what softc->quirks > currently contains. Thus, for 4K sector disks, quirks = 0x01. > > Line 934 -- load into "quirks" variable the contents of loader.conf > entries pertaining to kern.cam.ada.N.quirks, if set. If someone had an > entry in loader.conf saying kern.cam.ada.N.quirks=0 then yes, this would > overwrite what the kernel "auto-chose". > > Line 935 -- assign softc->quirks = quirks, thus softc->quirks = 0x00, > assuming someone set it to such in loader.conf. That's exactly what i meant. > > See my attached patch. I can confirm it works for me. > > I thought of taking that approach, but for me it's "dirty". Here's what > I mean by that: > > ADA_FLAG_CAN_NCQ gets set in softc->flags around line 892, but then > roughly a hundred lines later, you clear the exact same flag you just > set (based on quirk conditionals). > > I dunno how people feel about that, but my impression is that it's > dirty/confusing. My opinion is to only set the bit once and not mess > about with repeated if() statements that set it, then clear it, etc... Indeed you're right. It's a hack. Would be better to move quirk evaluation before checking capabilities. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 08:53:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73F91065672 for ; Wed, 15 Feb 2012 08:53:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0D7A48FC0C for ; Wed, 15 Feb 2012 08:53:42 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1F8rVRx096567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 10:53:31 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1F8rVhY003251; Wed, 15 Feb 2012 10:53:31 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1F8rVwE003250; Wed, 15 Feb 2012 10:53:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Feb 2012 10:53:31 +0200 From: Konstantin Belousov To: Adam Vande More Message-ID: <20120215085331.GV3283@deviant.kiev.zoral.com.ua> References: <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dRLJIiDvVt9dROG4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: disk devices speed is ugly 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, 15 Feb 2012 08:53:43 -0000 --dRLJIiDvVt9dROG4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 12:27:19AM -0600, Adam Vande More wrote: > On Tue, Feb 14, 2012 at 10:50 PM, Scott Long wrote: >=20 > > > > Any filesystem that uses bread/bwrite/cluster_read are already using the > > "generic caching subsystem" that you propose. This includes UDF, CD966= 0, > > MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage > > filesystem in the tree except for ZFS. Not all of them implement > > VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vno= de > > pager, not requirements for using buffer-cache services on block device= s. > > As Kostik pointed out in a parallel email, the only thing that was rem= oved > > from FreeBSD was the userland interface to cached devices via /dev node= s. > > >=20 > Does this mean the Architecture Handbook page is wrong?: >=20 > http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html No, why did you decided that it is wrong ? --dRLJIiDvVt9dROG4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk87cooACgkQC3+MBN1Mb4j3aACgreebK3nd5t1pmZmmyny5tthF 0PwAmwSPjkEevUZ+9Nlou65oinigP44s =6i3v -----END PGP SIGNATURE----- --dRLJIiDvVt9dROG4-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:08:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D891065670; Wed, 15 Feb 2012 09:08:35 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id ADF908FC13; Wed, 15 Feb 2012 09:08:34 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so905536bkc.13 for ; Wed, 15 Feb 2012 01:08:33 -0800 (PST) Received: by 10.205.119.140 with SMTP id fu12mr10747934bkc.139.1329296913319; Wed, 15 Feb 2012 01:08:33 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id t17sm5120665bke.6.2012.02.15.01.08.32 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 01:08:32 -0800 (PST) Message-ID: <4F3B760A.1060205@my.gd> Date: Wed, 15 Feb 2012 10:08:26 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F3A9237.5080901@barafranca.com> <4F3ADA5E.4060800@barafranca.com> In-Reply-To: <4F3ADA5E.4060800@barafranca.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnYHrFgFWXhzW6c8Gr7dJ1I8mHT9uA4h6FCZUKsa8dfMpy0I96O6z/IG4mjk5rpEZNM2gX4 Cc: Gleb Smirnoff Subject: Re: CARP carpdev 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, 15 Feb 2012 09:08:35 -0000 On 2/14/12 11:04 PM, Hugo Silva wrote: > On 02/14/12 17:33, Freddie Cash wrote: >> On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silva wrote: >>> Looks like there's been conversations about porting this to FreeBSD >>> since at >>> least 2007. >>> >>> Are there any plans to have ifconfig carpdev available in 9.0-STABLE? >> >> CARP support has been redone in 10-CURRENT, removing the whole "carp0" >> pseudo-interface support, and just enabling the CARP protocol on the >> existing network interfaces. This includes the equivalent of "carpdev" >> support. >> >> Search the -current archives for more information, CFT, and so on. >> >> I don't recall seeing anything about specific plans to MFC to >> stable/9, but could be mis-remembering things. >> > > > http://svnweb.freebsd.org/base?view=revision&revision=228571 > > The single IP limitation may be a problem in some locations.. > > Did not find anything about a possible MFC either. glebius@ is cc'd, > perhaps he can add something, but based on > http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been > MFCd (there's a primer for the new carp in current's UPDATING)\ > I think what Gleb meant by "It also allows to run a single redundant IP per interface" is that, like in OpenBSD, you won't need to assign a physical IP address in the same subnet as the CARP IP you want to use, on your system. LEGACY: - 1 physical IP in subnet XY on a physical interface - 1 virtual IP in subnet XY on a carp interface HEAD: - 1 virtual IP in subnet XY on a physical interface Although, you're still allowed to assign a physical IP to suit your needs. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:25:17 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D368010657C1 for ; Wed, 15 Feb 2012 09:25:17 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4ABF58FC12 for ; Wed, 15 Feb 2012 09:25:17 +0000 (UTC) Received: by eaan10 with SMTP id n10so301958eaa.13 for ; Wed, 15 Feb 2012 01:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=v4D76ruc5cj+Oe8KtpIjtFuGWUF46U7YcxLDgR/fBso=; b=aQXlV0P8qEi3yFfVBsn3qOZUTZTZB4EuSvw8PdExbd28K69HqB/Y1UyxrvMFuO1Ezj cnUo2Oo5oZWBD3E6g0r3kpPYvEqPVeUZ6ABXJ4DRlL+jM5KqInsAH+b4ggTlySKs/23+ ARXyYRWgqcqLt0uHHEjRexdEnNDHnJSxWCLxo= Received: by 10.213.112.139 with SMTP id w11mr1150274ebp.94.1329296369056; Wed, 15 Feb 2012 00:59:29 -0800 (PST) Received: from mkushnir.zapto.org (182-65-95-178.pool.ukrtel.net. [178.95.65.182]) by mx.google.com with ESMTPS id n17sm8953828eei.3.2012.02.15.00.59.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 00:59:28 -0800 (PST) Message-ID: <4F3B745A.4010509@gmail.com> Date: Wed, 15 Feb 2012 11:01:14 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120212 Thunderbird/10.0 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 09:25:17 -0000 Hello, [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both csup'ed around Feb. 10. Now worked around by turning the RTL8187L off in the BIOS. %uname -a FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11 19:39:29 EET 2012 root@mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK amd64 Below are the panic info and the full dmesg preceding the panic. Please let me know if there is anything more I could provide. [From my quick source code analysis, it looks like the driver fails to recognize the device in if_urtw.c, urtw_get_rfchip(), although later proceeds with the attach, which seems not quite logical... Correct behavior would probably be to not attach at all.] crash info: ----------- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803eff25 stack pointer = 0x28:0xffffff807df08950 frame pointer = 0x28:0xffffff807df08980 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (usbus3) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap_pfault() at trap_pfault+0x201 trap() at trap+0x3df calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff803eff25, rsp = 0xffffff807df08950, rbp = 0xffffff807df08980 --- ifindex_alloc_locked() at ifindex_alloc_locked+0x25 if_alloc() at if_alloc+0x71 urtw_attach() at urtw_attach+0x63e device_attach() at device_attach+0x69 usb_probe_and_attach() at usb_probe_and_attach+0x1f9 uhub_explore() at uhub_explore+0x4a1 usb_bus_explore() at usb_bus_explore+0xdc usb_process() at usb_process+0xd5 fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807df08d00, rbp = 0 --- Uptime: 9s Dumping 441 out of 8179 MB:..4%..11%..22%..33%..44%..51%..62%..73%..84%..91% dmesg: ------ Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #0: Fri Feb 10 21:45:38 EET 2012 root@:/usr/obj/usr/src/sys/MAREK amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2940.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8261365760 (7878 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. ioapic0 irqs 0-23 on motherboard ichwd module loaded kbd1 at kbdmux0 smbios0: at iomem 0xfc360-0xfc37e on motherboard smbios0: Version: 2.4, BCD Revision: 2.4 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 0x7E, should be 0x75 (20101013/tbutils-354) cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xcc00-0xcc7f mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfa000000-0xfbffffff irq 16 at device 0.0 on pci1 uhci0: port 0xb800-0xb81f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xbc00-0xbc1f irq 18 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xf9fffc00-0xf9ffffff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xf9ff8000-0xf9ffbfff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib2: irq 17 at device 28.0 on pci0 pci3: on pcib2 pcib3: irq 16 at device 28.5 on pci0 pci2: on pcib3 mskc0: port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1b:fc:6a:d1:42 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow mskc0: [ITHREAD] uhci3: port 0xb080-0xb09f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb480-0xb49f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xf9fff800-0xf9fffbff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 fwohci0: port 0xec00-0xec7f mem 0xfebff800-0xfebfffff irq 18 at device 2.0 on pci4 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:06:66:45:55:7c:a3 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x155c000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode fwohci1: mem 0xfebfe000-0xfebfefff irq 19 at device 3.0 on pci4 fwohci1: [ITHREAD] fwohci1: OHCI version 1.0 (ROM=1) fwohci1: No. of Isochronous channels is 8. fwohci1: EUI64 00:11:d8:00:01:4f:cd:f6 fwohci1: Phy 1394a available S400, 2 ports. fwohci1: Link S400, max_rec 2048 bytes. firewire1: on fwohci1 dcons_crom1: on firewire1 dcons_crom1: bus_addr 0x155c000 dcons_crom1: dcons_paddr is already set fwohci1: Initiate bus reset fwohci1: fwohci_intr_core: BUS reset fwohci1: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode re0: port 0xe800-0xe8ff mem 0xfebff400-0xfebff4ff irq 16 at device 4.0 on pci4 re0: Chip rev. 0x18000000 re0: MAC rev. 0x00000000 miibus1: on re0 rgephy0: PHY 1 on miibus1 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:1b:fc:6a:c5:84 re0: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41f mem 0xf9ffe800-0xf9ffefff irq 22 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ichsmb0: port 0x400-0x41f mem 0xf9fff400-0xf9fff4ff irq 18 at device 31.3 on pci0 ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ichwd0: on isa0 ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding disabled, default to deny, logging firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 firewire1: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire1: bus manager 0 disabled hdac0: HDA Codec #0: Analog Devices AD1988B pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 1.x device ada0: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) cd0 at ahcich4 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closedSMP: AP CPU #1 Launched! GEOM: ada0s3: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 usbus3 ugen3.2: at usbus3 Trying to mount root from ufs:/dev/ada1s1a Setting hostuuid: a0900011-d800-014f-cdf6-001bfc6ac584. Setting hostid: 0x86be90f6. Entropy harvesting: interrupts ethernet point_to_point kickstart . Starting file system checks: /dev/ada1s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada1s1a: clean, 221185 free (1137 frags, 27506 blocks, 0.2% fragmentation) /dev/ada1s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada1s1e: clean, 491565 free (53 frags, 61439 blocks, 0.0% fragmentation) /dev/ada1s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada1s1d: clean, 2305691 free (931 frags, 288095 blocks, 0.0% fragmentation) /dev/ada1s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada1s1f: clean, 306575787 free (215947 frags, 38294980 blocks, 0.0% fragmentation) /dev/ada0s3a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s3a: clean, 11006 free (502 frags, 1313 blocks, 0.2% fragmentation) /dev/ada0s3f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s3f: clean, 56793648 free (256080 frags, 7067196 blocks, 0.3% fragmentation) Mounting local file systems: . ugen6.2: at usbus6 ums0: on usbus6 ums0: 3 buttons and [XYZ] coordinates ID=0 Setting hostname: mkushnir.zapto.org . Starting Network: lo0 re0. lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xc inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 nd6 options=3 re0: flags=8843 metric 0 mtu 1500 options=209b ether 00:1b:fc:6a:c5:84 inet 10.1.1.10 netmask 0xffffff00 broadcast 10.1.1.255 media: Ethernet autoselect (none) status: no carrier Starting PPP profile: ukrtelecom . Additional routing options: IP gateway=YES . Starting devd. WARNING: attempt to domain_add(netgraph) after domainfinalize() urtw0: on usbus3 urtw0: unknown RTL8187L type: 0x8000000 Starting ums0 moused . Generating host.conf. Warning: kernel has firewall functionality, but firewall rules are not enabled. All ip services are disabled. Creating and/or trimming log files . Starting syslogd. savecore: reboot after panic: page fault Feb 10 22:33:21 mkushnir savecore: reboot after panic: page fault savecore: writing core to vmcore.7 urtw0: rtl8187l rf rtl8225u hwrev none re0: link state changed to UP Thanks, -- Markiyan From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:44:54 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 697CB1065702; Wed, 15 Feb 2012 09:44:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 758A28FC13; Wed, 15 Feb 2012 09:44:52 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA25004; Wed, 15 Feb 2012 11:44:42 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RxbPk-0000Jm-CB; Wed, 15 Feb 2012 11:44:40 +0200 Message-ID: <4F3B7E69.2030802@FreeBSD.org> Date: Wed, 15 Feb 2012 11:44:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Victor Balada Diaz , Jeremy Chadwick References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> <20120214233420.GU2010@equilibrium.bsdes.net> <20120215001020.GA9386@icarus.home.lan> <20120215082905.GV2010@equilibrium.bsdes.net> In-Reply-To: <20120215082905.GV2010@equilibrium.bsdes.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 09:44:54 -0000 [cc list somewhat trimmed] on 15/02/2012 10:29 Victor Balada Diaz said the following: > Indeed you're right. It's a hack. Sorry for intruding and under-quoting... perhaps the following commit could be a model solution for your problem here? http://svnweb.freebsd.org/base?view=revision&revision=231745 (with scsi -> ata , of course) -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:50:31 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3240910656FC for ; Wed, 15 Feb 2012 09:50:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC888FC21 for ; Wed, 15 Feb 2012 09:50:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA25585; Wed, 15 Feb 2012 11:50:14 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RxbV8-0000Ju-4n; Wed, 15 Feb 2012 11:50:14 +0200 Message-ID: <4F3B7FBC.7080708@FreeBSD.org> Date: Wed, 15 Feb 2012 11:49:48 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Scott Long References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, Peter Jeremy Subject: Re: disk devices speed is ugly 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, 15 Feb 2012 09:50:31 -0000 on 15/02/2012 06:50 Scott Long said the following: > The ARC is limited by available wired memory; attempts to allocate such > memory will evict pages from the buffer cache as necessary, until all > available RAM is consumed. If anything, ZFS starves the rest of the system, > not the other way around, and that's simply because the ARC isn't integrated > with the normal VM. I just would like to add for completeness that this is an oversimplified view of ARC's behavior. ARC tries to monitor overall memory usage and tries to throttle itself when necessary. It also reacts to lowmem signal from pagedaemon. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:53:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD92E106564A; Wed, 15 Feb 2012 09:53:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 103368FC21; Wed, 15 Feb 2012 09:53:32 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so604844wib.13 for ; Wed, 15 Feb 2012 01:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h/KvYmiuqWSxxgzTGIPh+XLkMAogI3Mzqc+tVhIGj6c=; b=F4QLPfaQC+AHZaS+9ZItddLgCKAdtA38O8YeuQf0zfy0FUl5JKOeKqXNrzlR1N/ijN GwAIRW1wJQ788TGzXhkW1jtGsI1s6HNip9cSXw9LTO7d/3aiXrXQPfs4kUQRTLl9UG5t iplhBv6q6GNItOLV6pRQKDPZndmwfzBZEtjtg= MIME-Version: 1.0 Received: by 10.180.106.67 with SMTP id gs3mr7138866wib.7.1329298000086; Wed, 15 Feb 2012 01:26:40 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.177.73 with HTTP; Wed, 15 Feb 2012 01:26:40 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Feb 2012 09:26:40 +0000 X-Google-Sender-Auth: VcyPMcb-QEYeyOLCSmue1ed6mzU Message-ID: From: Attilio Rao To: Pavel Polyakov Content-Type: text/plain; charset=UTF-8 Cc: stable@freebsd.org, daichi@freebsd.org Subject: Re: lock violation in unionfs (9.0-STABLE r230270) 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, 15 Feb 2012 09:53:33 -0000 2012/2/13, Pavel Polyakov : > http://www.freebsd.org/cgi/query-pr.cgi?pr=165087 > > Occurs simply trying to use unionfs: > mount -t unionfs -o noatime /usr /mnt > > insmntque: mp-safe fs and non-locked vp: 0xfffffe01d96704f0 is not > exclusive locked but should be > KDB: enter: lock violation Pavel, can you give a spin to this patch?: http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch I think that the unlocking is due at that point as the vnode lock can be switch later on. Let me know what you think about it and what the test does. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 09:58:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7640106566C for ; Wed, 15 Feb 2012 09:58:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 97F918FC17 for ; Wed, 15 Feb 2012 09:58:57 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta06.emeryville.ca.mail.comcast.net with comcast id a9yW1i0070cQ2SLA69yxca; Wed, 15 Feb 2012 09:58:57 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id a9yw1i0061t3BNj8W9ywWG; Wed, 15 Feb 2012 09:58:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3DDF0102C1E; Wed, 15 Feb 2012 01:58:56 -0800 (PST) Date: Wed, 15 Feb 2012 01:58:56 -0800 From: Jeremy Chadwick To: Julian Elischer Message-ID: <20120215095856.GA19213@icarus.home.lan> References: <4F3A1A19.7010803@freebsd.org> <4F3AEFA5.1020906@freebsd.org> <20120215002036.GA9938@icarus.home.lan> <4F3B5A01.4090109@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3B5A01.4090109@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Subject: Re: freebsd 9-stable TOP problem from around Jan 10 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, 15 Feb 2012 09:58:57 -0000 On Tue, Feb 14, 2012 at 11:08:49PM -0800, Julian Elischer wrote: > On 2/14/12 4:20 PM, Jeremy Chadwick wrote: > >On Tue, Feb 14, 2012 at 03:35:01PM -0800, Julian Elischer wrote: > >>On 2/14/12 10:38 AM, Kevin Oberman wrote: > >>>On Tue, Feb 14, 2012 at 12:23 AM, Julian Elischer wrote: > >>>>Has anyone else seen a problem with top -H -S? > >>>> > >>>>after a short while the screen gets more and more corrupted.. > >>>> > >>>>hitting ^L or turning off S& H modes helps .. for a while. > >>>> > >>>>If this is a known fixed problem, let me know but I need to co-ordinate with > >>>>others > >>>>to upgrade the machine in question. > >>>Not seeing it here on 9-stable. Could it be a display issue? I am > >>>using gnome-terminal with TERM defined as 'xterm'. > >>yeah I'm on a mac with iterm, but running through 'screen' . > >> > >>it's never been a problem before.. just since we upgraded to 9-stable. > >If you remove GNU screen from the picture does the problem go away? If > >so, I'm not surprised. :-) > > > >Make sure that when you're using GNU screen, that all shells launched > >"under/within" screen have TERM=screen. If they don't, then this is > >almost certainly the problem -- GNU screen "translates" between terminal > >types, meaning it translates its own terminal type ("screen") into > >whatever TERM is currently attached ("xterm", "iterm", whatever). See > >the last 4 paragraphs of my post here to understand what exactly GNU > >screen is doing: > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063052.html > > > >So, in general, make sure your dotfiles and so on don't mess about with > >the $TERM environment variable and you should generally be okay. > it seems to have stopped doing it for no apparent reason > > will keep an eye on it. and save this email away for when it does it > again. > > >If within GNU screen TERM=screen and you see the problem, but outside of > >screen you use TERM=xterm (or something else) but don't see the problem, > >then I would almost certainly blame GNU screen. If you're looking for > >something that simply keeps a terminal running in the background, try > >nohup or tmux. > > > >Alternately, possibly someone added a "screen" entry to /etc/termcap on > >RELENG_9? I don't use 9 so I have no way to confirm this, but on 8 > >there is no such entry. > > SC|screen|VT 100/ANSI X3.64 virtual terminal:\ Sorry, I'm quite wrong here on the last point. Somehow my manual search in vi did not come up with anything in /etc/termcap for screen, yet there is absolutely a definition for it in RELENG_8. PEBKAC. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:02:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5894C106568E; Wed, 15 Feb 2012 10:02:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id C3A438FC08; Wed, 15 Feb 2012 10:02:01 +0000 (UTC) Received: from titan.wdn.omnilan.net (titan.lo4.wdn.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q1FA20ho045857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 11:02:01 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.wdn.omnilan.net [172.21.1.150] claimed to be titan.wdn.omnilan.net Message-ID: <4F3B8298.3000701@omnilan.de> Date: Wed, 15 Feb 2012 11:02:00 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig177FB0098509D26C4B4735BD" Cc: Alexander Motin Subject: Lost ata_xpt.c fix for -stable: svn commit: r217444 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, 15 Feb 2012 10:02:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig177FB0098509D26C4B4735BD Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, I just applied my local patches against RELENG_8_2 src tree and found that http://svn.freebsd.org/changeset/base/217444 was still missing, and if I read svnweb right (sorry, lack of svn knowledge here), it's also missing in -stable. Any plans to commit? Thanks, -Harry --------------enig177FB0098509D26C4B4735BD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk87gpgACgkQLDqVQ9VXb8gd3gCfUamzRbl9z/4nknJ3NVWFbtps JggAnRG0ailDQ5Wm/ShKSL4duUe5+pLS =4ZWg -----END PGP SIGNATURE----- --------------enig177FB0098509D26C4B4735BD-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:19:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C269106564A for ; Wed, 15 Feb 2012 10:19:38 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 41C798FC0C for ; Wed, 15 Feb 2012 10:19:38 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so889766vbb.13 for ; Wed, 15 Feb 2012 02:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HSWzjGsQgdnHkeFN3inTgHNyYMvnOCcGQXLEUSpE92o=; b=Dz2r3B4ZSEsFAt6I+0zXA9IBwKZxR2h2E7pK8fftJsh7sxwUXYXSPI0L+mbusly6bI HgIEh4Mkzuar91GP8asyf3CuVFPUMlcAfepNlIpfmFtMfUr3R4gkVizdx4Ki/hLmZBCD w6Q+adp9B6yLPkC9OgHpDe2XfWPn9z3Cign+k= MIME-Version: 1.0 Received: by 10.52.94.33 with SMTP id cz1mr10785786vdb.132.1329301177727; Wed, 15 Feb 2012 02:19:37 -0800 (PST) Received: by 10.52.91.210 with HTTP; Wed, 15 Feb 2012 02:19:37 -0800 (PST) In-Reply-To: <20120214195255.GA5064@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <20120214195255.GA5064@icarus.home.lan> Date: Wed, 15 Feb 2012 10:19:37 +0000 Message-ID: From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Harald Schmalzbauer , Claudius Herder , freebsd-stable@freebsd.org, Oscar Prieto , Martin Sugioarto Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 10:19:38 -0000 On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote: >> I used to had tons of ahci errors in my 4 disk raidz1 worth of >> HD154UIs when the rig was built a year ago or so (with 8.0 Release), >> but they dissapeared after tuning ZFS. >> >> Sadly i also got a new timeout days ago followed with smartcl erros i >> still keep unchecked but i guess they cold be legit, i still have to >> test/swap cables and give it a try. Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, haven't had a problem with any of them yet (touch wood). > Further details which pertain to Samsung drives: > > In your case, you run smartd(8), which periodically hits the drive with > SMART requests, pulling attribute data down and parsing it. =C2=A0I belie= ve > your model is fine for this, but for similar Samsung models, I must > strongly advise against this. =C2=A0There are well-documented problems wi= th > Samsung firmwares and SMART behaviour which can result in data loss (yes > you read that right). =C2=A0Please see smartmontools' Wiki page on the ma= tter > for full details. =C2=A0Just make sure you're running a fixed firmware: > > http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks > Yikes, I have just this week installed a HD204UI. From that page, drives manufactured after December 2010 should not be affected, which is fortunate as the linked firmware page doesn't seem to exist anymore, Samsung no longer seem to offer support for their drives and point you at Seagate, whose site (of course!) only has downloads for current Seagate drives. Hmm reading later on in the thread there is a patch to mark certain drives as having flaky NCQ - in the patch it is for the SAMSUNG HD154UI. As I mentioned before, I have 9 SAMSUNG HD154UI, all of which use ahci(4) and NCQ, and all work perfectly, no timeouts. This is using 9-STABLE. I suspect that there may be more going on than 'flaky NCQ', and that perhaps disabling NCQ masks the real issue. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:27:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7175E1065670 for ; Wed, 15 Feb 2012 10:27:29 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E5D058FC16 for ; Wed, 15 Feb 2012 10:27:28 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so977987bkc.13 for ; Wed, 15 Feb 2012 02:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OXC9BiITldJqYOSZPWjAGVkY5z1Xw9EbHExN6M/xU10=; b=NRreQ7tLoPuiNDFaKY9bU7iq3XCUkXESjO6wwASHHZKp4TZ66cm55jl+7DzWPu6XKX Osb2gOMhmCUhZeOZPtS1dohv7z0XetBhH+6dTUWLiETY4MDjVAheicqzwBS8H3dyDmBo 0MXa5sdKPWffMISu017OJsLbLhk/F1hDdEglY= Received: by 10.204.128.202 with SMTP id l10mr11103867bks.116.1329301647912; Wed, 15 Feb 2012 02:27:27 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id o7sm5465232bkw.16.2012.02.15.02.27.25 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 02:27:26 -0800 (PST) Sender: Alexander Motin Message-ID: <4F3B888C.3090602@FreeBSD.org> Date: Wed, 15 Feb 2012 12:27:24 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111227 Thunderbird/9.0 MIME-Version: 1.0 To: Harald Schmalzbauer References: <4F3B8298.3000701@omnilan.de> In-Reply-To: <4F3B8298.3000701@omnilan.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Lost ata_xpt.c fix for -stable: svn commit: r217444 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, 15 Feb 2012 10:27:29 -0000 Hi. On 02/15/12 12:02, Harald Schmalzbauer wrote: > I just applied my local patches against RELENG_8_2 src tree and found > that http://svn.freebsd.org/changeset/base/217444 was still missing, and > if I read svnweb right (sorry, lack of svn knowledge here), it's also > missing in -stable. > Any plans to commit? As I can see, it was merged to 8-STABLE a year ago at r218340: http://svnweb.freebsd.org/base?view=revision&revision=218340 -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:29:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B455106564A for ; Wed, 15 Feb 2012 10:29:33 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B6B858FC1E for ; Wed, 15 Feb 2012 10:29:32 +0000 (UTC) Received: by lagz14 with SMTP id z14so1140562lag.13 for ; Wed, 15 Feb 2012 02:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I2NkDZpX8rbAaxhm1E244Nm/C+6AjClW15gshtQ7VN8=; b=DI7PVWMCf379+XpVYnKJsteHFzntMxjqFMGXL0zJqN7WH/ZJZuERH6IbZktqaDxp/P a+OK5qrW11ooAxNWvqKYoY6cvh25yeDk1ofO9Gg0BCDM+mvj+3SblpF19M+PZvHW95KE YYBiUy2NEbeyzrFWHwWN4TSAeMB4tU1Vz8WPA= MIME-Version: 1.0 Received: by 10.112.87.225 with SMTP id bb1mr8474630lbb.59.1329300263815; Wed, 15 Feb 2012 02:04:23 -0800 (PST) Received: by 10.152.18.4 with HTTP; Wed, 15 Feb 2012 02:04:23 -0800 (PST) In-Reply-To: <4F3B745A.4010509@gmail.com> References: <4F3B745A.4010509@gmail.com> Date: Wed, 15 Feb 2012 13:04:23 +0300 Message-ID: From: Sergey Kandaurov To: Markiyan Kushnir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 10:29:33 -0000 On 15 February 2012 13:01, Markiyan Kushnir wr= ote: > Hello, > > [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, bot= h > csup'ed around Feb. 10. > > Now worked around by turning the RTL8187L off in the BIOS. > > %uname -a > FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11 > 19:39:29 EET 2012 > root@mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK =A0amd64 > > > Below are the panic info and the full dmesg preceding the panic. Please l= et > me know if there is anything more I could provide. > > [From my quick source code analysis, it looks like the driver fails to > recognize the device in if_urtw.c, urtw_get_rfchip(), although later > proceeds with the attach, which seems not quite logical... Correct behavi= or > would probably be to not attach at all.] > > > crash info: > ----------- > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =A0 =3D 0x28 > fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not = present > instruction pointer =A0 =A0 =3D 0x20:0xffffffff803eff25 > stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08950 > frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08980 > code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x1= b > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1,= def32 0, gran 1 > processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D 0 > current process =A0 =A0 =A0 =A0 =3D 14 (usbus3) > trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 > panic: page fault > cpuid =3D 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > trap_fatal() at trap_fatal+0x290 > trap_pfault() at trap_pfault+0x201 > trap() at trap+0x3df > calltrap() at calltrap+0x8 > --- trap 0xc, rip =3D 0xffffffff803eff25, rsp =3D 0xffffff807df08950, rbp= =3D > 0xffffff807df08980 --- > ifindex_alloc_locked() at ifindex_alloc_locked+0x25 > if_alloc() at if_alloc+0x71 > urtw_attach() at urtw_attach+0x63e > device_attach() at device_attach+0x69 > usb_probe_and_attach() at usb_probe_and_attach+0x1f9 > uhub_explore() at uhub_explore+0x4a1 > usb_bus_explore() at usb_bus_explore+0xdc > usb_process() at usb_process+0xd5 > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip =3D 0, rsp =3D 0xffffff807df08d00, rbp =3D 0 --- > Uptime: 9s > Dumping 441 out of 8179 MB:..4%..11%..22%..33%..44%..51%..62%..73%..84%..= 91% > [..] > WARNING: VIMAGE (virtualized network stack) is a highly experimental [..] > savecore: reboot after panic: page fault > Feb 10 22:33:21 mkushnir savecore: reboot after panic: page fault > savecore: writing core to vmcore.7 Something tells me that the problem may lie in VIMAGE. Can you issue the following command: kgdb -n 7 then in gdb menu run this command: bt to resolve source lines. [ anticipating hte response, I will try to lookup if_alloc+0x71 for my system built around the same date (w/o vimage though): 0xffffffff80698211 is in if_alloc (/usr/src/sys/net/if.c:283). 278 retry: 279 /* 280 * Try to find an empty slot below V_if_index. If we fail, take the 281 * next slot. 282 */ 283 for (idx =3D 1; idx <=3D V_if_index; idx++) { 284 if (V_ifindex_table[idx].ife_ifnet =3D=3D NULL) 285 break; 286 } 287 ] --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:34:10 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0A1E1065677 for ; Wed, 15 Feb 2012 10:34:10 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4FC8FC17 for ; Wed, 15 Feb 2012 10:34:10 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so774961wgb.31 for ; Wed, 15 Feb 2012 02:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z3CFK4jqT92HV81eFR8qIN6m19QiBeTlGgbyW2mllGQ=; b=URWgjVHe/YVJOdzp7R+vpJnHZ7JWTng44AJUY6p9gxV6z3wxlsdgUHcAykaaD24wzM mqj9GNW6KDng+uDMpE7Dmw6PF3W4i6H6UqcpTP2XKvf6VchmETdNj5kVyyZVlUavcASN ACsGCAxnkGpWo30XM8WyViCVw4SEiFBmqypQ0= MIME-Version: 1.0 Received: by 10.180.95.1 with SMTP id dg1mr34514902wib.21.1329302049318; Wed, 15 Feb 2012 02:34:09 -0800 (PST) Received: by 10.227.177.143 with HTTP; Wed, 15 Feb 2012 02:34:09 -0800 (PST) In-Reply-To: References: <4F3B745A.4010509@gmail.com> Date: Wed, 15 Feb 2012 12:34:09 +0200 Message-ID: From: Markiyan Kushnir To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 10:34:11 -0000 Here it is: (kgdb) bt #0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263 #1 0xffffffff8036da50 in boot (howto=3D260) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:441 #2 0xffffffff8036def1 in panic (fmt=3DVariable "fmt" is not available. ) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:614 #3 0xffffffff80567240 in trap_fatal (frame=3D0xc, eva=3DVariable "eva" is not available. ) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:825 #4 0xffffffff80567591 in trap_pfault (frame=3D0xffffff807dd4b8a0, usermode=3D0) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:741 #5 0xffffffff80567a4f in trap (frame=3D0xffffff807dd4b8a0) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:478 #6 0xffffffff8054e584 in calltrap () at /usr/RELENG_8/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff804237f5 in ifindex_alloc_locked (idxp=3D0xffffff807dd4b99e) at /usr/RELENG_8/src/sys/net/if.c:285 #8 0xffffffff804286e1 in if_alloc (type=3D71 'G') at /usr/RELENG_8/src/sys/net/if.c:453 #9 0xffffffff81e2f07e in urtw_attach (dev=3DVariable "dev" is not availabl= e. ) at /usr/RELENG_8/src/sys/modules/usb/urtw/../../../dev/usb/wlan/if_urtw.c= :856 #10 0xffffffff8039aef9 in device_attach (dev=3D0xffffff0016fca600) at device_if.h:178 #11 0xffffffff80272649 in usb_probe_and_attach (udev=3D0xffffff0016e3c800, iface_index=3DVariable "iface_index" is not available. ) at /usr/RELENG_8/src/sys/dev/usb/usb_device.c:1195 #12 0xffffffff8027aaa1 in uhub_explore (udev=3D0xffffff0016d98000) at /usr/RELENG_8/src/sys/dev/usb/usb_hub.c:269 #13 0xffffffff802653ec in usb_bus_explore (pm=3DVariable "pm" is not availa= ble. ) at /usr/RELENG_8/src/sys/dev/usb/controller/usb_controller.c:349 #14 0xffffffff8027ead5 in usb_process (arg=3DVariable "arg" is not availabl= e. ) at /usr/RELENG_8/src/sys/dev/usb/usb_process.c:174 #15 0xffffffff803413af in fork_exit (callout=3D0xffffffff8027ea00 , arg=3D0xffffff80003f7db0, frame=3D0xffffff807dd4bc50) at /usr/RELENG_8/src/sys/kern/kern_fork.c:876 #16 0xffffffff8054eace in fork_trampoline () at /usr/RELENG_8/src/sys/amd64/amd64/exception.S:602 #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000001 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0xffffffff808287e8 in sleepq_chains () #42 0xffffff0002904cf0 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffff00029048c0 in ?? () #45 0xffffff807dd4b730 in ?? () #46 0xffffff807dd4b6d8 in ?? () #47 0xffffff000252e000 in ?? () #48 0xffffffff80394462 in sched_switch (td=3D0xffffffff8027ea00, newtd=3D0xffffff80003f7db0, flags=3Ddwarf2_read_address: Corrupted DWARF expression. ) at /usr/RELENG_8/src/sys/kern/sched_ule.c:1861 Previous frame inner to this frame (corrupt stack?) (kgdb) 2012/2/15 Sergey Kandaurov : > On 15 February 2012 13:01, Markiyan Kushnir = wrote: >> Hello, >> >> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, bo= th >> csup'ed around Feb. 10. >> >> Now worked around by turning the RTL8187L off in the BIOS. >> >> %uname -a >> FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11 >> 19:39:29 EET 2012 >> root@mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK =A0amd64 >> >> >> Below are the panic info and the full dmesg preceding the panic. Please = let >> me know if there is anything more I could provide. >> >> [From my quick source code analysis, it looks like the driver fails to >> recognize the device in if_urtw.c, urtw_get_rfchip(), although later >> proceeds with the attach, which seems not quite logical... Correct behav= ior >> would probably be to not attach at all.] >> >> >> crash info: >> ----------- >> >> Fatal trap 12: page fault while in kernel mode >> cpuid =3D 0; apic id =3D 00 >> fault virtual address =A0 =3D 0x28 >> fault code =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D supervisor read data, page not= present >> instruction pointer =A0 =A0 =3D 0x20:0xffffffff803eff25 >> stack pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08950 >> frame pointer =A0 =A0 =A0 =A0 =A0 =3D 0x28:0xffffff807df08980 >> code segment =A0 =A0 =A0 =A0 =A0 =A0=3D base 0x0, limit 0xfffff, type 0x= 1b >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D DPL 0, pres 1, long 1= , def32 0, gran 1 >> processor eflags =A0 =A0 =A0 =A0=3D interrupt enabled, resume, IOPL =3D = 0 >> current process =A0 =A0 =A0 =A0 =3D 14 (usbus3) >> trap number =A0 =A0 =A0 =A0 =A0 =A0 =3D 12 >> panic: page fault >> cpuid =3D 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> kdb_backtrace() at kdb_backtrace+0x37 >> panic() at panic+0x187 >> trap_fatal() at trap_fatal+0x290 >> trap_pfault() at trap_pfault+0x201 >> trap() at trap+0x3df >> calltrap() at calltrap+0x8 >> --- trap 0xc, rip =3D 0xffffffff803eff25, rsp =3D 0xffffff807df08950, rb= p =3D >> 0xffffff807df08980 --- >> ifindex_alloc_locked() at ifindex_alloc_locked+0x25 >> if_alloc() at if_alloc+0x71 >> urtw_attach() at urtw_attach+0x63e >> device_attach() at device_attach+0x69 >> usb_probe_and_attach() at usb_probe_and_attach+0x1f9 >> uhub_explore() at uhub_explore+0x4a1 >> usb_bus_explore() at usb_bus_explore+0xdc >> usb_process() at usb_process+0xd5 >> fork_exit() at fork_exit+0x11f >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip =3D 0, rsp =3D 0xffffff807df08d00, rbp =3D 0 --- >> Uptime: 9s >> Dumping 441 out of 8179 MB:..4%..11%..22%..33%..44%..51%..62%..73%..84%.= .91% >> > [..] >> WARNING: VIMAGE (virtualized network stack) is a highly experimental > [..] >> savecore: reboot after panic: page fault >> Feb 10 22:33:21 mkushnir savecore: reboot after panic: page fault >> savecore: writing core to vmcore.7 > > Something tells me that the problem may lie in VIMAGE. > > Can you issue the following command: kgdb -n 7 > then in gdb menu run this command: bt > to resolve source lines. > > [ anticipating hte response, I will try to lookup if_alloc+0x71 > for my system built around the same date (w/o vimage though): > 0xffffffff80698211 is in if_alloc (/usr/src/sys/net/if.c:283). > 278 =A0 =A0 retry: > 279 =A0 =A0 =A0 =A0 =A0 =A0 /* > 280 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Try to find an empty slot below V_if_ind= ex. =A0If we > fail, take the > 281 =A0 =A0 =A0 =A0 =A0 =A0 =A0* next slot. > 282 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/ > 283 =A0 =A0 =A0 =A0 =A0 =A0 for (idx =3D 1; idx <=3D V_if_index; idx++) { > 284 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (V_ifindex_table[idx].ife_= ifnet =3D=3D NULL) > 285 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; > 286 =A0 =A0 =A0 =A0 =A0 =A0 } > 287 > ] > > -- > wbr, > pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:37:01 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 666F31065686 for ; Wed, 15 Feb 2012 10:37:01 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id EDFA28FC1B for ; Wed, 15 Feb 2012 10:37:00 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so4026613wgb.1 for ; Wed, 15 Feb 2012 02:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YYqiNtk7plvkynOAqZHSLCEJM+1+PbgPkC1MlNOeyfk=; b=o/IVZ0WaT7mxE0u1DHRc5Hl9z88/Izzf8yWGdjVvAPUUFLeqHd18vG0Q6c4rYW2JxE Vub56NP1ZMKcHIXvBJgXu92ZrIhzpQC7bFJ1msRqifkrjLRLpTZbD3b/z6NNW6OM/nAH uuQsd84TmUfFMu2x8zQQAC/ZOeqOKfbT1p61c= MIME-Version: 1.0 Received: by 10.180.95.1 with SMTP id dg1mr34529140wib.21.1329302220119; Wed, 15 Feb 2012 02:37:00 -0800 (PST) Received: by 10.227.177.143 with HTTP; Wed, 15 Feb 2012 02:37:00 -0800 (PST) In-Reply-To: References: <4F3B745A.4010509@gmail.com> Date: Wed, 15 Feb 2012 12:37:00 +0200 Message-ID: From: Markiyan Kushnir To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 10:37:01 -0000 looks like that's it ... -- Markiyan. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:40:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0FB106567A; Wed, 15 Feb 2012 10:40:09 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 5469E8FC14; Wed, 15 Feb 2012 10:40:09 +0000 (UTC) Received: from titan.wdn.omnilan.net (titan.lo4.wdn.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q1FAe8sQ047151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 11:40:08 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.wdn.omnilan.net [172.21.1.150] claimed to be titan.wdn.omnilan.net Message-ID: <4F3B8B88.2020004@omnilan.de> Date: Wed, 15 Feb 2012 11:40:08 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4F3B8298.3000701@omnilan.de> <4F3B888C.3090602@FreeBSD.org> In-Reply-To: <4F3B888C.3090602@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2635EA68B31FEFFF4E79DA4D" Cc: freebsd-stable@freebsd.org Subject: Re: Lost ata_xpt.c fix for -stable: svn commit: r217444 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, 15 Feb 2012 10:40:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2635EA68B31FEFFF4E79DA4D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Alexander Motin am 15.02.2012 11:27 (localtime): > Hi. > > On 02/15/12 12:02, Harald Schmalzbauer wrote: >> I just applied my local patches against RELENG_8_2 src tree and found >> that http://svn.freebsd.org/changeset/base/217444 was still missing, a= nd >> if I read svnweb right (sorry, lack of svn knowledge here), it's also >> missing in -stable. >> Any plans to commit? > > As I can see, it was merged to 8-STABLE a year ago at r218340: > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D218340 > Sorry for the noise. Haven't checked carefully enough and couldn't imagine RELENG_8_2 wa created 13 months ago... Thanks, -Harry --------------enig2635EA68B31FEFFF4E79DA4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk87i4gACgkQLDqVQ9VXb8gErACgvbjqae26rCvgzY2pNv7dAEGl 9IIAniCA0BriJ31Nr35RWnLGYvlRfwvb =s14/ -----END PGP SIGNATURE----- --------------enig2635EA68B31FEFFF4E79DA4D-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:40:10 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D690B1065672 for ; Wed, 15 Feb 2012 10:40:10 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 69EED8FC15 for ; Wed, 15 Feb 2012 10:40:10 +0000 (UTC) Received: by werm13 with SMTP id m13so840006wer.13 for ; Wed, 15 Feb 2012 02:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mbkSx4Z4Gv7eVNZc3yU83jskUyGUM80UhEgffMade8=; b=l8/4Skg6oYN8O74k3UetIICFWSM3D5FDZsPBpM40DEjC8flAr174BfaGW8Y+sV22Y6 G6DkbwRaCRSVnz/kJf6vGKGcWyZBtc5U5vnSzYrLCLVvcdnzFu2O/vu/6sCmQZ0phj5T 1FhrOnQ53HtHooXQ3oRhP7aHxVo+liqOSMQ3k= MIME-Version: 1.0 Received: by 10.181.11.227 with SMTP id el3mr34435041wid.18.1329302409474; Wed, 15 Feb 2012 02:40:09 -0800 (PST) Received: by 10.227.177.143 with HTTP; Wed, 15 Feb 2012 02:40:09 -0800 (PST) In-Reply-To: References: <4F3B745A.4010509@gmail.com> Date: Wed, 15 Feb 2012 12:40:09 +0200 Message-ID: From: Markiyan Kushnir To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org Subject: Re: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 10:40:10 -0000 Any way, I'm still unsure if the urtw's logic of "ignore device identification failure, and attach" is correct. -- Markiyan. 2012/2/15 Markiyan Kushnir : > looks like that's it ... > > -- > Markiyan. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:42:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039961065676 for ; Wed, 15 Feb 2012 10:42:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id ACF678FC14 for ; Wed, 15 Feb 2012 10:42:08 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta07.westchester.pa.mail.comcast.net with comcast id aAfs1i0010Fqzac57Ai99u; Wed, 15 Feb 2012 10:42:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.westchester.pa.mail.comcast.net with comcast id aAi71i00P1t3BNj3UAi7tH; Wed, 15 Feb 2012 10:42:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E0E12102C1F; Wed, 15 Feb 2012 02:42:05 -0800 (PST) Date: Wed, 15 Feb 2012 02:42:05 -0800 From: Jeremy Chadwick To: Tom Evans Message-ID: <20120215104205.GA19734@icarus.home.lan> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <20120214195255.GA5064@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Claudius Herder , freebsd-stable@freebsd.org, Oscar Prieto , Martin Sugioarto Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 10:42:09 -0000 On Wed, Feb 15, 2012 at 10:19:37AM +0000, Tom Evans wrote: > On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick > wrote: > > On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote: > >> I used to had tons of ahci errors in my 4 disk raidz1 worth of > >> HD154UIs when the rig was built a year ago or so (with 8.0 Release), > >> but they dissapeared after tuning ZFS. > >> > >> Sadly i also got a new timeout days ago followed with smartcl erros i > >> still keep unchecked but i guess they cold be legit, i still have to > >> test/swap cables and give it a try. > > Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, > haven't had a problem with any of them yet (touch wood). > > > Further details which pertain to Samsung drives: > > > > In your case, you run smartd(8), which periodically hits the drive with > > SMART requests, pulling attribute data down and parsing it. ??I believe > > your model is fine for this, but for similar Samsung models, I must > > strongly advise against this. ??There are well-documented problems with > > Samsung firmwares and SMART behaviour which can result in data loss (yes > > you read that right). ??Please see smartmontools' Wiki page on the matter > > for full details. ??Just make sure you're running a fixed firmware: > > > > http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks > > > > Yikes, I have just this week installed a HD204UI. From that page, > drives manufactured after December 2010 should not be affected, which > is fortunate as the linked firmware page doesn't seem to exist > anymore, Samsung no longer seem to offer support for their drives and > point you at Seagate, whose site (of course!) only has downloads for > current Seagate drives. > > > Hmm reading later on in the thread there is a patch to mark certain > drives as having flaky NCQ - in the patch it is for the SAMSUNG > HD154UI. As I mentioned before, I have 9 SAMSUNG HD154UI, all of which > use ahci(4) and NCQ, and all work perfectly, no timeouts. This is > using 9-STABLE. > > I suspect that there may be more going on than 'flaky NCQ', and that > perhaps disabling NCQ masks the real issue. It could simply be a firmware bug in the drive, which is what some others have eluded to (and I'm in agreement with). I would love to say "compare firmware versions on your drives", except there is real in-the-field proof that firmware version strings often do not get updated/changed between firmwares (at least in the case of some Seagate and Western Digital disks). Furthermore, NCQ can "play differently" with different AHCI controllers. That said, the disks / firmware versions mentioned by people involved in this thread / referenced threads are: * Victor Balada Diaz -- SAMSUNG HD154UI, firmware 1AG01118 * Claudius Herder -- SAMSUNG HD753LJ, firmware 1AA01118 * Oscar Prieto -- SAMSUNG HD154UI, firmware 1AG01118 - NOTE: In Oscar's case, his drives exhibit other problems. I would provide a link but the web archive for freebsd-stable does not show my mail which contains analysis of the situation * Harald Schmalzbauer -- not provided, but hints at Samsung EG drives For this to be thorough, one would need to check what all AHCI controllers are being used and compare those as well. I think Scott's theory is probably on-the-ball here, as it pertains to tag exhaustion, which would manifest itself in the described fashion: http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/066177.html I'd urge people experiencing this problem to issue the command Scott provided on all their Samsung disks and see if the problem goes away after that. If it does, great, and I acknowledge there is no loader.conf tunable for doing this, etc. etc. etc. so either make an rc.d script that does it after boot-up or something. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:52:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F223106566B for ; Wed, 15 Feb 2012 10:52:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4308C8FC08 for ; Wed, 15 Feb 2012 10:52:05 +0000 (UTC) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id aArB1i0081swQuc58As6Ap; Wed, 15 Feb 2012 10:52:06 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta15.westchester.pa.mail.comcast.net with comcast id aAs51i00A1t3BNj3bAs5R8; Wed, 15 Feb 2012 10:52:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D0A8D102C1E; Wed, 15 Feb 2012 02:52:03 -0800 (PST) Date: Wed, 15 Feb 2012 02:52:03 -0800 From: Jeremy Chadwick To: Tom Evans Message-ID: <20120215105203.GA20072@icarus.home.lan> References: <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <20120214195255.GA5064@icarus.home.lan> <20120215104205.GA19734@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120215104205.GA19734@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Claudius Herder , freebsd-stable@freebsd.org, Oscar Prieto , Martin Sugioarto Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 10:52:06 -0000 On Wed, Feb 15, 2012 at 02:42:05AM -0800, Jeremy Chadwick wrote: > On Wed, Feb 15, 2012 at 10:19:37AM +0000, Tom Evans wrote: > > On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick > > wrote: > > > On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote: > > >> I used to had tons of ahci errors in my 4 disk raidz1 worth of > > >> HD154UIs when the rig was built a year ago or so (with 8.0 Release), > > >> but they dissapeared after tuning ZFS. > > >> > > >> Sadly i also got a new timeout days ago followed with smartcl erros i > > >> still keep unchecked but i guess they cold be legit, i still have to > > >> test/swap cables and give it a try. > > > > Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, > > haven't had a problem with any of them yet (touch wood). > > > > > Further details which pertain to Samsung drives: > > > > > > In your case, you run smartd(8), which periodically hits the drive with > > > SMART requests, pulling attribute data down and parsing it. ??I believe > > > your model is fine for this, but for similar Samsung models, I must > > > strongly advise against this. ??There are well-documented problems with > > > Samsung firmwares and SMART behaviour which can result in data loss (yes > > > you read that right). ??Please see smartmontools' Wiki page on the matter > > > for full details. ??Just make sure you're running a fixed firmware: > > > > > > http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks > > > > > > > Yikes, I have just this week installed a HD204UI. From that page, > > drives manufactured after December 2010 should not be affected, which > > is fortunate as the linked firmware page doesn't seem to exist > > anymore, Samsung no longer seem to offer support for their drives and > > point you at Seagate, whose site (of course!) only has downloads for > > current Seagate drives. > > > > > > Hmm reading later on in the thread there is a patch to mark certain > > drives as having flaky NCQ - in the patch it is for the SAMSUNG > > HD154UI. As I mentioned before, I have 9 SAMSUNG HD154UI, all of which > > use ahci(4) and NCQ, and all work perfectly, no timeouts. This is > > using 9-STABLE. > > > > I suspect that there may be more going on than 'flaky NCQ', and that > > perhaps disabling NCQ masks the real issue. > > It could simply be a firmware bug in the drive, which is what some > others have eluded to (and I'm in agreement with). I would love to say > "compare firmware versions on your drives", except there is real > in-the-field proof that firmware version strings often do not get > updated/changed between firmwares (at least in the case of some Seagate > and Western Digital disks). Furthermore, NCQ can "play differently" with > different AHCI controllers. > > That said, the disks / firmware versions mentioned by people involved in > this thread / referenced threads are: > > * Victor Balada Diaz -- SAMSUNG HD154UI, firmware 1AG01118 > * Claudius Herder -- SAMSUNG HD753LJ, firmware 1AA01118 > * Oscar Prieto -- SAMSUNG HD154UI, firmware 1AG01118 > - NOTE: In Oscar's case, his drives exhibit other problems. I > would provide a link but the web archive for freebsd-stable does > not show my mail which contains analysis of the situation > * Harald Schmalzbauer -- not provided, but hints at Samsung EG drives > > For this to be thorough, one would need to check what all AHCI > controllers are being used and compare those as well. > > I think Scott's theory is probably on-the-ball here, as it pertains to > tag exhaustion, which would manifest itself in the described fashion: > > http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/066177.html > > I'd urge people experiencing this problem to issue the command Scott > provided on all their Samsung disks and see if the problem goes away > after that. If it does, great, and I acknowledge there is no > loader.conf tunable for doing this, etc. etc. etc. so either make an > rc.d script that does it after boot-up or something. Sorry, I missed the in-line part of your post at the top where you said: > > Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, > > haven't had a problem with any of them yet (touch wood). So that would be you using the same firmware (or so I'd like to believe, but see my previous explanations) as others. It could be some AHCI<->NCQ drive implementation quirk. There was an example of this back in the day with Maxtor drives' NCQ implementation not behaving correctly on nVidia controllers, which Maxtor insisted was an nVidia problem yet released a drive firmware fix for. I'm one of the people this affected (on my desktop system), which is why I remember it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 10:57:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 062941065670 for ; Wed, 15 Feb 2012 10:57:37 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 75FC88FC08 for ; Wed, 15 Feb 2012 10:57:36 +0000 (UTC) Received: from titan.wdn.omnilan.net (titan.lo4.wdn.omnilan.net [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q1FAvXCa047859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 11:57:34 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnisec.de: Host titan.lo4.wdn.omnilan.net [172.21.1.150] claimed to be titan.wdn.omnilan.net Message-ID: <4F3B8F9D.6070907@omnilan.de> Date: Wed, 15 Feb 2012 11:57:33 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jeremy Chadwick References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <20120214195255.GA5064@icarus.home.lan> <20120215104205.GA19734@icarus.home.lan> In-Reply-To: <20120215104205.GA19734@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1576C785B7FE08F3CAF7759E" Cc: Tom Evans , freebsd-stable@freebsd.org, Oscar Prieto , Martin Sugioarto , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 10:57:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1576C785B7FE08F3CAF7759E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable schrieb Jeremy Chadwick am 15.02.2012 11:42 (localtime): > On Wed, Feb 15, 2012 at 10:19:37AM +0000, Tom Evans wrote: >> On Tue, Feb 14, 2012 at 7:52 PM, Jeremy Chadwick >> wrote: >>> On Tue, Feb 14, 2012 at 08:31:23PM +0100, Oscar Prieto wrote: >>>> I used to had tons of ahci errors in my 4 disk raidz1 worth of >>>> HD154UIs when the rig was built a year ago or so (with 8.0 Release),= >>>> but they dissapeared after tuning ZFS. >>>> >>>> Sadly i also got a new timeout days ago followed with smartcl erros = i >>>> still keep unchecked but i guess they cold be legit, i still have to= >>>> test/swap cables and give it a try. >> Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, >> haven't had a problem with any of them yet (touch wood). >> >>> Further details which pertain to Samsung drives: >>> >>> In your case, you run smartd(8), which periodically hits the drive wi= th >>> SMART requests, pulling attribute data down and parsing it. ??I belie= ve >>> your model is fine for this, but for similar Samsung models, I must >>> strongly advise against this. ??There are well-documented problems wi= th >>> Samsung firmwares and SMART behaviour which can result in data loss (= yes >>> you read that right). ??Please see smartmontools' Wiki page on the ma= tter >>> for full details. ??Just make sure you're running a fixed firmware: >>> >>> http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlo= cks >>> >> Yikes, I have just this week installed a HD204UI. From that page, >> drives manufactured after December 2010 should not be affected, which >> is fortunate as the linked firmware page doesn't seem to exist >> anymore, Samsung no longer seem to offer support for their drives and >> point you at Seagate, whose site (of course!) only has downloads for >> current Seagate drives. >> >> >> Hmm reading later on in the thread there is a patch to mark certain >> drives as having flaky NCQ - in the patch it is for the SAMSUNG >> HD154UI. As I mentioned before, I have 9 SAMSUNG HD154UI, all of which= >> use ahci(4) and NCQ, and all work perfectly, no timeouts. This is >> using 9-STABLE. >> >> I suspect that there may be more going on than 'flaky NCQ', and that >> perhaps disabling NCQ masks the real issue. > It could simply be a firmware bug in the drive, which is what some > others have eluded to (and I'm in agreement with). I would love to say= > "compare firmware versions on your drives", except there is real > in-the-field proof that firmware version strings often do not get > updated/changed between firmwares (at least in the case of some Seagate= > and Western Digital disks). Furthermore, NCQ can "play differently" wi= th > different AHCI controllers. > > That said, the disks / firmware versions mentioned by people involved i= n > this thread / referenced threads are: > > * Victor Balada Diaz -- SAMSUNG HD154UI, firmware 1AG01118 > * Claudius Herder -- SAMSUNG HD753LJ, firmware 1AA01118 > * Oscar Prieto -- SAMSUNG HD154UI, firmware 1AG01118 > - NOTE: In Oscar's case, his drives exhibit other problems. I > would provide a link but the web archive for freebsd-stable does > not show my mail which contains analysis of the situation > * Harald Schmalzbauer -- not provided, but hints at Samsung EG drives -- SAMSUNG HD154UI, firmware 1AG01118 I still have them for "outsourcing" in one server, where they idle all the time. Thanks, -Harry --------------enig1576C785B7FE08F3CAF7759E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk87j50ACgkQLDqVQ9VXb8jfvACfevOKSoyJ+X6zfC1O4P9O9w0k 9QYAn246EXO3a01NlbZvhhKzIemcG612 =g2ZR -----END PGP SIGNATURE----- --------------enig1576C785B7FE08F3CAF7759E-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 11:11:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 428431065670 for ; Wed, 15 Feb 2012 11:11:23 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB5AD8FC18 for ; Wed, 15 Feb 2012 11:11:22 +0000 (UTC) Received: by vcmm1 with SMTP id m1so937109vcm.13 for ; Wed, 15 Feb 2012 03:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F8Gv+tXi+bmm/AyU68RbLud9J1ulQEc93mDzJc9b9NI=; b=JHIO3lcofwHgJAA+cH9TbbM0bJ5GOnF7RlxDlkC2uwS4Zlhyue4i2r4p/NMM52OZ6x ex4WHvBc44F3DOTgozyo6e74rdRn4YHJOYXLOkdGGKXJRp/IY0Z98LdO5M7G9M7QoYb+ uNK8raA7KVSMpHjG81Nt6F3aqC4ocuD0plcP8= MIME-Version: 1.0 Received: by 10.52.68.209 with SMTP id y17mr10861983vdt.98.1329304282178; Wed, 15 Feb 2012 03:11:22 -0800 (PST) Received: by 10.52.91.210 with HTTP; Wed, 15 Feb 2012 03:11:22 -0800 (PST) In-Reply-To: <20120215105203.GA20072@icarus.home.lan> References: <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214192319.44ff7aff@zelda.sugioarto.com> <20120214195255.GA5064@icarus.home.lan> <20120215104205.GA19734@icarus.home.lan> <20120215105203.GA20072@icarus.home.lan> Date: Wed, 15 Feb 2012 11:11:22 +0000 Message-ID: From: Tom Evans To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 11:11:23 -0000 On Wed, Feb 15, 2012 at 10:52 AM, Jeremy Chadwick wrote: > Sorry, I missed the in-line part of your post at the top where you said: > >> > Interesting. I have 9 SAMSUNG HD154UI 1AG01118 in my raidz setup, >> > haven't had a problem with any of them yet (touch wood). > > So that would be you using the same firmware (or so I'd like to believe, > but see my previous explanations) as others. > Yes, that draws my ire too - how can you update the firmware and not change the firmware revision, it is crazy. It's possible that even amongst my drives there are different revisions, as not all drives were bought at the same time. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 12:57:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF287106566C for ; Wed, 15 Feb 2012 12:57:47 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 40A718FC1C for ; Wed, 15 Feb 2012 12:57:45 +0000 (UTC) Received: by eekb47 with SMTP id b47so395865eek.13 for ; Wed, 15 Feb 2012 04:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7uJLlVyNPt2I882Gd0IWrPJYWbw3814cNh4ig2wvTJs=; b=udGNYUy3sQhN7v+nY8K2ju79HwLKZ9hl8JuL66/GuyQrHy+XctAxgtFwubhZfd8HR1 nNbKJu+1BQ0dKcEVHAQ/mLXMMCVLXgczJTQSm1g0cLw4tBSQrDiWQ5D1qq9WqpEyhIsi KCu5emwKpI2pp7yECtglkwZZAbzXp7IXZ+ojA= Received: by 10.213.33.145 with SMTP id h17mr244740ebd.89.1329310665101; Wed, 15 Feb 2012 04:57:45 -0800 (PST) Received: from mkushnir.zapto.org (151-201-124-91.pool.ukrtel.net. [91.124.201.151]) by mx.google.com with ESMTPS id c16sm10982995eei.1.2012.02.15.04.57.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 04:57:44 -0800 (PST) Message-ID: <4F3BAC32.2020406@gmail.com> Date: Wed, 15 Feb 2012 14:59:30 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120212 Thunderbird/10.0 MIME-Version: 1.0 To: stable@freebsd.org References: <4F3B745A.4010509@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: RELENG_8 panic caused by urtw? 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, 15 Feb 2012 12:57:47 -0000 Tried the case w/o VIMAGE in the kernel (RTL8187L is on in the BIOS) -- no panic. Also, with the VNET_DEBUG on, got a couple of CURVNET_SET() recursion in the logs: Feb 15 14:08:03 mkushnir kernel: CURVNET_SET() recursion in unp_connect() line 1237, prev in soconnect() Feb 15 14:08:03 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:03 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:03 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:03 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:03 mkushnir kernel: unp_connect() at unp_connect+0x8f2 Feb 15 14:08:03 mkushnir kernel: uipc_connect() at uipc_connect+0x55 Feb 15 14:08:03 mkushnir kernel: soconnect() at soconnect+0x179 Feb 15 14:08:03 mkushnir kernel: kern_connect() at kern_connect+0x12e Feb 15 14:08:03 mkushnir kernel: connect() at connect+0x41 Feb 15 14:08:03 mkushnir kernel: amd64_syscall() at amd64_syscall+0x1f4 Feb 15 14:08:03 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:08:03 mkushnir kernel: --- syscall (98, FreeBSD ELF64, connect), rip = 0x80083bcbc, rsp = 0x7fffffffe888, rbp = 0x39bd --- Feb 15 14:08:04 mkushnir kernel: CURVNET_SET() recursion in soreceive() line 2296, prev in netisr_process_workstream_proto() Feb 15 14:08:04 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:04 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:04 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:04 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:04 mkushnir kernel: soreceive() at soreceive+0xbd Feb 15 14:08:04 mkushnir kernel: clnt_dg_soupcall() at clnt_dg_soupcall+0xa8 Feb 15 14:08:04 mkushnir kernel: sowakeup() at sowakeup+0x69 Feb 15 14:08:04 mkushnir kernel: udp6_append() at udp6_append+0x17b Feb 15 14:08:04 mkushnir kernel: udp6_input() at udp6_input+0x7c5 Feb 15 14:08:04 mkushnir kernel: ip6_input() at ip6_input+0xd0a Feb 15 14:08:04 mkushnir kernel: swi_net() at swi_net+0x1dd Feb 15 14:08:04 mkushnir kernel: intr_event_execute_handlers() at intr_event_execute_handlers+0x104 Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: ithread_loop() at ithread_loop+0x95 Feb 15 14:08:04 mkushnir kernel: fork_exit() at fork_exit+0x11f Feb 15 14:08:04 mkushnir kernel: fork_trampoline() at fork_trampoline+0xe Feb 15 14:08:04 mkushnir kernel: --- trap 0, rip = 0, rsp = 0xffffff800004bd00, rbp = 0 --- Feb 15 14:08:04 mkushnir kernel: CURVNET_SET() recursion in soreceive() line 2296, prev in sosend() Feb 15 14:08:04 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:08:04 mkushnir kernel: KDB: stack backtrace: Feb 15 14:08:04 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:08:04 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:08:04 mkushnir kernel: soreceive() at soreceive+0xbd Feb 15 14:08:04 mkushnir kernel: clnt_vc_soupcall() at clnt_vc_soupcall+0xc6 Feb 15 14:08:04 mkushnir kernel: sowakeup() at sowakeup+0x69 Feb 15 14:08:04 mkushnir kernel: uipc_send() at Feb 15 14:08:04 mkushnir kernel: uipc_send+0xca0 Feb 15 14:08:04 mkushnir kernel: sosend_generic() at sosend_generic+0x46c Feb 15 14:08:04 mkushnir kernel: sosend() at sosend+0xe8 Feb 15 14:08:04 mkushnir kernel: soo_write() at soo_write+0x62 Feb 15 14:08:04 mkushnir kernel: dofilewrite() at dofilewrite+0x8b Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: kern_writev() at kern_writev+0x60 Feb 15 14:08:04 mkushnir kernel: write() at write+0x55 Feb 15 14:08:04 mkushnir kernel: amd64_syscall() at fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8a Feb 15 14:08:04 mkushnir kernel: md64_syscall+0x1f4 Feb 15 14:08:04 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:08:04 mkushnir kernel: Feb 15 14:08:04 mkushnir kernel: --- syscall (4, FreeBSD ELF64, write), rip = 0x80095faac, rsp = 0x7fffffffc338, rbp = 0x800c63000 --- [...] Feb 15 14:10:00 mkushnir kernel: CURVNET_SET() recursion in tun_destroy() line 256, prev in if_clone_destroyif() Feb 15 14:10:00 mkushnir kernel: 0xffffff00023164c0 -> 0xffffff00023164c0 Feb 15 14:10:00 mkushnir kernel: Feb 15 14:10:00 mkushnir kernel: KDB: stack backtrace: Feb 15 14:10:01 mkushnir kernel: Feb 15 14:10:01 mkushnir kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Feb 15 14:10:01 mkushnir kernel: kdb_backtrace() at kdb_backtrace+0x37 Feb 15 14:10:01 mkushnir kernel: tun_destroy() at tun_destroy+0x132 Feb 15 14:10:01 mkushnir kernel: ifc_simple_destroy() at ifc_simple_destroy+0x2a Feb 15 14:10:01 mkushnir kernel: if_clone_destroyif() at if_clone_destroyif+0x147 Feb 15 14:10:01 mkushnir kernel: if_clone_destroy() at if_clone_destroy+0x15a Feb 15 14:10:01 mkushnir kernel: ifioctl() at ifioctl+0x935 Feb 15 14:10:01 mkushnir kernel: Feb 15 14:10:01 mkushnir kernel: kern_ioctl() at kern_ioctl+0x102 Feb 15 14:10:01 mkushnir kernel: ioctl() at ioctl+0xfd Feb 15 14:10:01 mkushnir kernel: amd64_syscall() at amd64_syscall+0x1f4 Feb 15 14:10:01 mkushnir kernel: Xfast_syscall() at Xfast_syscall+0xfc Feb 15 14:10:01 mkushnir kernel: --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800b86a6c, rsp = 0x7fffffffe4a8, rbp = 0x7fffffffef44 --- -- Marikyan. On 15.02.2012 12:40, Markiyan Kushnir wrote: > Any way, I'm still unsure if the urtw's logic of "ignore device > identification failure, and attach" is correct. > > > -- > Markiyan. > > 2012/2/15 Markiyan Kushnir: >> looks like that's it ... >> >> -- >> Markiyan. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 14:12:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60396106566B for ; Wed, 15 Feb 2012 14:12:48 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id C2F528FC28 for ; Wed, 15 Feb 2012 14:12:47 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id q1FECbHp006782; Wed, 15 Feb 2012 15:12:37 +0100 (MET) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 8C9C32E05C; Wed, 15 Feb 2012 15:12:37 +0100 (CET) Date: Wed, 15 Feb 2012 15:12:37 +0100 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20120215141237.GA40349@twoquid.cs.ru.nl> References: <20120213155902.GE867@twoquid.cs.ru.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120213155902.GE867@twoquid.cs.ru.nl> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Subject: Re: ZFS faulted pool problem 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, 15 Feb 2012 14:12:48 -0000 I'm still (or again) in more or less the same situation as before. I have tried things like exporting the pool and re-importing it. However the import didn't even want to work. Only once I found an undocumented "zpool import -V" option by UTSLing, the pool got imported again, but still without an attempt at resilvering. There also exist (undocumented) -F (rewind) and -X (extreme rewind) options for zpool import and zpool clear. However, the effect of -X seems to be that some extremely lengthy operation is attempted, that never finishes. In some cases, a reboot was necessary to terminate the process. I have also tried to remove an extra disk, on the theory that with raidz2 you can miss 2 disks, and that the problem might be restricted to a single disk. I haven't done each disk yet, but so far there was no success. (I "removed" each disk by unconfiguring the pass-through on the Areca web interface). $ zpool status pool: tank state: FAULTED status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scan: scrub repaired 0 in 49h3m with 2 errors on Fri Jan 20 15:10:35 2012 config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 2 raidz2-0 DEGRADED 0 0 8 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 3758301462980058947 UNAVAIL 0 0 0 was /dev/da4 da5 ONLINE 0 0 0 fourquid.1:~$ sudo zpool online tank da4 cannot open 'tank': pool is unavailable fourquid.1:~$ sudo zpool clear -nF tank fourquid.1:~$ sudo zpool clear -F tank cannot clear errors for tank: I/O error fourquid.1:~$ sudo zpool clear -nFX tank (no output, uses some cpu, some I/O) zdb -v ok zdb -v -c tank zdb: can't open 'tank': input/output error zdb -v -l /dev/da[01235] ok zdb -v -u tank zdb: can't open 'tank': Input/output error zdb -v -l -u /dev/da[01235] ok zdb -v -m tank zdb: can't open 'tank': Input/output error zdb -v -m -X tank no output, uses cpu and I/O$ zdb -v -i tank zdb: can't open 'tank': Input/output error zdb -v -i -F tank zdb: can't open 'tank': Input/output error zdb -v -i -X tank no output, uses cpu and I/O Any ideas? -Olaf. -- Pipe rene = new PipePicture(); assert(Not rene.GetType().Equals(Pipe)); From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 14:54:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EAFE1065670; Wed, 15 Feb 2012 14:54:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 9D38E8FC14; Wed, 15 Feb 2012 14:54:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1FEsBCu051002 ; Wed, 15 Feb 2012 15:54:11 +0100 (CET) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1FErcnH094628; Wed, 15 Feb 2012 15:53:38 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1FErbN5094625; Wed, 15 Feb 2012 15:53:37 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Wed, 15 Feb 2012 15:53:37 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3BC713.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3BC713.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 15 Feb 2012 14:54:25 -0000 Hello, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? [root@cc ~]# dd if=/dev/ada0s3.eli of=/dev/null bs=4096 conv=noerror 103746635+0 records in 103746635+0 records out 424946216960 bytes transferred in 18773.796016 secs (22635072 bytes/sec) [root@cc ~]# > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? Looks like each scrub worsens the situation : [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 148K in 0h14m with 26 errors on Mon Feb 13 18:54:33 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 26 ada0s3.eli ONLINE 0 0 87 errors: Permanent errors have been detected in the following files: [ 11 files ] [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub in progress since Wed Feb 15 14:36:52 2012 17.7G scanned out of 28.7G at 72.1M/s, 0h2m to go 0 repaired, 61.56% done config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 54 ada0s3.eli ONLINE 0 0 143 errors: Permanent errors have been detected in the following files: [ 11 files ] # [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 4K in 0h7m with 70 errors on Wed Feb 15 14:43:57 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 96 ada0s3.eli ONLINE 0 0 228 errors: Permanent errors have been detected in the following files: [ 25 files (cannot quickly see iff it contains all old 11 files) ] [root@cc ~]# [root@cc ~]# zpool status -v pool: zfiles state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 0h6m with 70 errors on Wed Feb 15 15:19:28 2012 config: NAME STATE READ WRITE CKSUM zfiles ONLINE 0 0 166 ada0s3.eli ONLINE 0 0 368 errors: Permanent errors have been detected in the following files: [ 25 files ] [root@cc ~]# > 3) Can you try zfs without geli? > > 4) Is the slice/partition layout definitely correct? > > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 16:50:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E523106564A; Wed, 15 Feb 2012 16:50:52 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id 127F98FC14; Wed, 15 Feb 2012 16:50:51 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id E77B039844; Wed, 15 Feb 2012 17:50:49 +0100 (CET) Date: Wed, 15 Feb 2012 17:50:49 +0100 From: Victor Balada Diaz To: Scott Long Message-ID: <20120215165049.GW2010@equilibrium.bsdes.net> References: <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <4F3A83DE.3000200@ambtec.de> <20120214165029.GA1852@icarus.home.lan> <4F3A971F.9040407@omnilan.de> <20120214221527.GT2010@equilibrium.bsdes.net> <20120214230958.GA8434@icarus.home.lan> <20120214233420.GU2010@equilibrium.bsdes.net> <6D5E973B-6D98-41D7-B5E9-64A497F0F9F5@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6D5E973B-6D98-41D7-B5E9-64A497F0F9F5@samsco.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Harald Schmalzbauer , Alexander Motin , freebsd-stable@freebsd.org, Jeremy Chadwick , Claudius Herder Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 16:50:52 -0000 On Tue, Feb 14, 2012 at 04:42:47PM -0700, Scott Long wrote: > On Feb 14, 2012, at 4:34 PM, Victor Balada Diaz wrote: > > On Tue, Feb 14, 2012 at 03:09:58PM -0800, Jeremy Chadwick wrote: > >> I took a stab at this, but I don't feel confident this is the proper > >> solution/method. I worry there's some sort of chicken-or-the-egg > >> condition here (quirk setup/matching comes *after* SATA capabilities > >> detection), or that it makes the code messier. Need mav@'s > >> recommendations on this. > >> > >> Below is for RELENG_8. I should note I haven't tested if this works, or > >> even compiles -- normally I don't provide such patches without testing > >> so I apologise in advance / user beware. > > > > You're amazingly fast. Thanks for all your help :) > > > > You start applying the quirks before > > > > snprintf(announce_buf, sizeof(announce_buf), > > "kern.cam.ada.%d.quirks", periph->unit_number); > > quirks = softc->quirks; > > TUNABLE_INT_FETCH(announce_buf, &quirks); > > > > So you're breaking quirk setting at boot time. > > > > See my attached patch. I can confirm it works for me. > > > > Regards. > > > > I don't think that disabling NCQ entirely is the right solution. It's a tag starvation issue in the firmware, not a complete failure, and it can be dealt with in the CAM XPT scheduler fairly efficiently. Alexander and I talked about this recently, and though we differ on the details, a tag hack is not in order, IMHO. In the short term, try just using "cam control tags ada0 -N 1" to limit the concurrent commands to 1. > > Scott Seems changing tags on both disks doesn't fix the issue: (ada0:ahcich0:0:0:0): Request requeued (ada0:ahcich0:0:0:0): Retrying command ahcich1: Timeout on slot 0 ahcich1: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr 00000000 ahcich1: AHCI reset... ahcich1: SATA connect time=0ms status=00000123 ahcich1: ready wait time=18ms ahcich1: AHCI reset done: device found (ada1:ahcich1:0:0:0): Request requeued (ada1:ahcich1:0:0:0): Retrying command (ada1:ahcich1:0:0:0): Command timed out (ada1:ahcich1:0:0:0): Retrying command ahcich0: Timeout on slot 30 ahcich0: is 00000000 cs c0000000 ss 00000000 rs c0000000 tfd c0 serr 00000000 ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=18ms ahcich0: AHCI reset done: device found The only difference is that now i get "Request requeued" message. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 18:17:59 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2DD4106564A for ; Wed, 15 Feb 2012 18:17:59 +0000 (UTC) (envelope-from victor@bsdes.net) Received: from equilibrium.bsdes.net (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.freebsd.org (Postfix) with ESMTP id DB4488FC08 for ; Wed, 15 Feb 2012 18:17:58 +0000 (UTC) Received: by equilibrium.bsdes.net (Postfix, from userid 1001) id 9669139846; Wed, 15 Feb 2012 19:17:57 +0100 (CET) Date: Wed, 15 Feb 2012 19:17:57 +0100 From: Victor Balada Diaz To: Jeremy Chadwick Message-ID: <20120215181757.GX2010@equilibrium.bsdes.net> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20120214141601.GA98986@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 18:18:00 -0000 On Tue, Feb 14, 2012 at 06:16:01AM -0800, Jeremy Chadwick wrote: > Thanks. Both your drives look overall fine, sort-of. I'll outline my > concern points, and ask for some more info: > > * ada0 has 28 CRC errors, while ada1 has 2. These drives have been in > use for 4688 hours and 4583 hours (respectively), which is roughly 6 > months for each drive. CRC errors usually result in transparent > retransmits, but this can sometimes cause I/O delays (especially if the > CRC errors are repeated). > > If the timeout messages recur in the future, please run the commands I > gave you above once more and provide the output. I can then compare the > old to the new and see if there is anything of interest. I've made it fail again. You can see smartctl -a output. CRC errors are increasing. But i'm not sure what does it really mean. Is HD broken? both? at the same time? # smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.1-RELEASE-p5 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F2 EG Device Model: SAMSUNG HD154UI Serial Number: S24EJ9BB200080 LU WWN Device Id: 5 0024e9 2047cb78f Firmware Version: 1AG01118 User Capacity: 1,500,301,910,016 bytes [1.50 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Wed Feb 15 18:11:31 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (18863) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 33) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 072 072 011 Pre-fail Always - 9330 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 13677 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4716 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 22 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 067 065 000 Old_age Always - 33 (Min/Max 31/35) 194 Temperature_Celsius 0x0022 066 061 000 Old_age Always - 34 (Min/Max 31/39) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 5063520 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 41 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4430 - # 2 Extended offline Completed without error 10% 4410 - # 3 Extended offline Completed without error 00% 27 - # 4 Short offline Completed without error 00% 14 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. fe09# smartctl -a /dev/ada1 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.1-RELEASE-p5 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: SAMSUNG SpinPoint F2 EG Device Model: SAMSUNG HD154UI Serial Number: S24EJ9BB200082 LU WWN Device Id: 5 0024e9 2047cb7a5 Firmware Version: 1AG01118 User Capacity: 1,500,301,910,016 bytes [1.50 TB] Sector Size: 512 bytes logical/physical Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 3b Local Time is: Wed Feb 15 18:11:40 2012 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (19064) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 33) minutes. SCT capabilities: (0x003f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 071 071 011 Pre-fail Always - 9360 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 21 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0 8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12804 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 4612 10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21 13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age Always - 0 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 069 067 000 Old_age Always - 31 (Min/Max 29/33) 194 Temperature_Celsius 0x0022 067 067 000 Old_age Always - 33 (Min/Max 29/36) 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 412845960 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 11 200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4430 - # 2 Extended offline Completed without error 10% 4409 - # 3 Extended offline Completed without error 00% 28 - # 4 Short offline Completed without error 00% 14 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. -- La prueba más fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 19:19:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D177106564A for ; Wed, 15 Feb 2012 19:19:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 18C038FC0C for ; Wed, 15 Feb 2012 19:19:33 +0000 (UTC) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id aJy71i0010Fqzac51KKaQk; Wed, 15 Feb 2012 19:19:34 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta08.westchester.pa.mail.comcast.net with comcast id aKKZ1i00R1t3BNj3UKKZju; Wed, 15 Feb 2012 19:19:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B570E102C1E; Wed, 15 Feb 2012 11:19:31 -0800 (PST) Date: Wed, 15 Feb 2012 11:19:31 -0800 From: Jeremy Chadwick To: Victor Balada Diaz Message-ID: <20120215191931.GA30747@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <20120215181757.GX2010@equilibrium.bsdes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120215181757.GX2010@equilibrium.bsdes.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 15 Feb 2012 19:19:34 -0000 On Wed, Feb 15, 2012 at 07:17:57PM +0100, Victor Balada Diaz wrote: > On Tue, Feb 14, 2012 at 06:16:01AM -0800, Jeremy Chadwick wrote: > > Thanks. Both your drives look overall fine, sort-of. I'll outline my > > concern points, and ask for some more info: > > > > * ada0 has 28 CRC errors, while ada1 has 2. These drives have been in > > use for 4688 hours and 4583 hours (respectively), which is roughly 6 > > months for each drive. CRC errors usually result in transparent > > retransmits, but this can sometimes cause I/O delays (especially if the > > CRC errors are repeated). > > > > If the timeout messages recur in the future, please run the commands I > > gave you above once more and provide the output. I can then compare the > > old to the new and see if there is anything of interest. > > I've made it fail again. You can see smartctl -a output. CRC errors are increasing. > But i'm not sure what does it really mean. Is HD broken? both? at the same time? CRC errors indicate one of the following, in no particular order: * Physical cabling problems (number of reasons/possibilities here are too many to list) * Dirty/dusty SATA connectors (cables/drive/host controller) * Electrical interference (badly shielded cables, etc.) * Physical electronic/electrical problems (disk PCB, host controller PCB, etc.) The important thing to remember about CRCs is that they indicate a hardware-level problem between the host controller and the controller chip on the drive. They do not indicate problems with the drive's cache (those are tracked in attribute 184), and they do not indicate software-level problems (e.g. driver bugs, etc.). I have no real advice for tracking this kind of problem down. The most common response is "replace cables", which isn't necessarily the root cause. I have no advice or tips on how to track down interference issues, or how to truly examine a disk PCB or controller PCB for the latter item. "Flaky traces" on a PCB could cause this sort of thing. Folks in the EE field would know more about these issues; I am not an EE person. Since the attribute increased on both drives simultaneously (I have to assume simultaneously?), it's more likely that the problem is not with SATA cables or the drives but the controller on the motherboard. I'd recommend replacing the motherboard. I make no guarantees this will fix anything however, but it is the "common point" for both of your drives. There really isn't anything else I can do going forward. This is pretty much where the buck stops for me, and is validation as to why each and every problem/issue has to be handled individually. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 19:22:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039CC1065673 for ; Wed, 15 Feb 2012 19:22:21 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id B1A958FC0C for ; Wed, 15 Feb 2012 19:22:20 +0000 (UTC) Received: from vivi.cc.vt.edu (vivi.cc.vt.edu [198.82.163.43]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q1FJLoIu007702; Wed, 15 Feb 2012 14:21:50 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by vivi.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id UGV07389; Wed, 15 Feb 2012 14:21:50 -0500 (EST) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q1FJLnll022885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Feb 2012 14:21:50 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120215002351.GB9938@icarus.home.lan> Date: Wed, 15 Feb 2012 14:21:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <274B6964-3CFF-4706-845C-61FA4F8D0617@gromit.dlib.vt.edu> References: <20120215002351.GB9938@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=vivi.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020206.4F3C05CE.0027,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: stable@freebsd.org Subject: Re: ZFS + nullfs + Linuxulator = 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: Wed, 15 Feb 2012 19:22:21 -0000 On Feb 14, 2012, at 7:23 PM, Jeremy Chadwick wrote: > On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: >> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC = kernel, last built 2012-02-08). It will panic during the daily periodic = scripts that run at 3am. Here is the most recent panic message: >>=20 >> Fatal trap 9: general protection fault while in kernel mode >> cpuid =3D 0; apic id =3D 00 >> instruction pointer =3D 0x20:0xffffffff8069d266 >> stack pointer =3D 0x28:0xffffff8094b90390 >> frame pointer =3D 0x28:0xffffff8094b903a0 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags =3D resume, IOPL =3D 0 >> current process =3D 72566 (ps) >> trap number =3D 9 >> panic: general protection fault >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e >> #1 0xffffffff805facd3 at panic+0x183 >> #2 0xffffffff808e6c20 at trap_fatal+0x290 >> #3 0xffffffff808e715a at trap+0x10a >> #4 0xffffffff808cec64 at calltrap+0x8 >> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 >> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 >> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 >> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 >> #9 0xffffffff8060473f at sysctl_root+0x14f >> #10 0xffffffff80604a2a at userland_sysctl+0x14a >> #11 0xffffffff80604f1a at __sysctl+0xaa >> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 >> #13 0xffffffff808cef5c at Xfast_syscall+0xfc >> Uptime: 3d19h6m0s >> Dumping 1308 out of 2028 = MB:..2%..12%..21%..31%..41%..51%..62%..71%..81%..91% >> Dump complete >> Automatic reboot in 15 seconds - press a key on the console to abort >> Rebooting... >>=20 >>=20 >> The reason for the subject line is that I have another RELENG_8 = system that uses ZFS + nullfs but doesn't panic, leading me to believe = that ZFS + nullfs is not the problem. I am wondering if it is the = combination of the three that is deadly, here. >>=20 >> Both RELENG_8 systems are root-on-ZFS installs. Each night there is = a separate backup script that runs and completes before the regular = "periodic daily" run. This script takes a recursive snapshot of the ZFS = pool and then mounts these snapshots via mount_nullfs to provide a = coherent view of the filesystem under /backup. The only difference = between the two RELENG_8 systems is that one uses rsync to back up = /backup to another machine and the other uses the Linux Tivoli TSM = client to back up /backup to a TSM server. After the backup is = completed, a script runs that unmounts the nullfs file systems and then = destroys the ZFS snapshot. >>=20 >> The first (rsync backup) RELENG_8 system does not panic. It has been = running the ZFS + nullfs rsync backup job without incident for weeks = now. The second (Tivoli TSM) RELENG_8 will reliably panic when the = subsequent "periodic daily" job runs. (It is using the 32-bit TSM 6.2.4 = Linux client running "dsmc schedule" via the linux_base-f10-10_4 = package.) The actual ZFS + nullfs Tivoli TSM backup job appears to run = successfully, making me wonder if perhaps it has some memory leak or = other subtle corruption that sets up the ensuing panic when the = "periodic daily" job later gives the system a workout. >>=20 >> If I can provide more information about the panic, please let me = know. Despite the message about dumping in the panic output above, when = the system reboots I get a "No core dumps found" message during boot. = (I have dumpdev=3D"AUTO" set in /etc/rc.conf.) My swap device is on = separate partitions but is mirrored using geom_mirror as = /dev/mirror/swap. Do crash dumps to gmirror devices work on RELENG_8? >=20 > See gmirror(8) man page, section NOTES. Read the full thing. Thanks! I've changed the balance algorithm to "prefer", so hopefully = I'll get saved crash dumps to examine from now on. >> Does anyone have any idea what is to blame for the panic, or how I = can fix or work around it? >=20 > Does the panic always happen when "ps" is run? That's what's shown in > the above panic message. Quoting: >=20 >> current process =3D 72566 (ps) >=20 > And I'm inclined to think it does, based on the backtrace: >=20 >> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 >> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 >> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 >> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 >=20 > But if you can go through the previous panics and confirm that, it = would > be helpful to developers in tracking down the problem. Just going by memory, at least one other time it did a panic during = "df". But, most of the time I remember the panic occurring during "ps". Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 21:39:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E26E01065673 for ; Wed, 15 Feb 2012 21:39:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B699F8FC17 for ; Wed, 15 Feb 2012 21:39:41 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1FLdZcI009369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 13:39:40 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3C2671.3090808@freebsd.org> Date: Wed, 15 Feb 2012 13:41:05 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: threads@freebsd.org, FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jens Axboe Subject: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 15 Feb 2012 21:39:42 -0000 The program fio (an IO test in ports) uses pthreads the following code (from fio-2.0.3, but its in earlier code too) has suddenly started misbehaving. clock_gettime(CLOCK_REALTIME, &t); t.tv_sec += seconds + 10; pthread_mutex_lock(&mutex->lock); while (!mutex->value && !ret) { mutex->waiters++; ret = pthread_cond_timedwait(&mutex->cond, &mutex->lock, &t); mutex->waiters--; } if (!ret) { mutex->value--; pthread_mutex_unlock(&mutex->lock); } It turns out that 'ret' sometimes comes back instantly (on my machine) with a value of 60 (ETIMEDOUT) despite the fact that we set the timeout 10 seconds into the future. Has anyone else seen anything like this? (and yes the condition variable attribute have been set to use the REALTIME clock). From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 23:47:50 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 621FA1065679 for ; Wed, 15 Feb 2012 23:47:50 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0B43B8FC16 for ; Wed, 15 Feb 2012 23:47:49 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q1FNlnjn058313 for ; Wed, 15 Feb 2012 16:47:49 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q1FNlngt058312 for stable@freebsd.org; Wed, 15 Feb 2012 16:47:49 -0700 (MST) (envelope-from ken) Date: Wed, 15 Feb 2012 16:47:49 -0700 From: "Kenneth D. Merry" To: stable@freebsd.org Message-ID: <20120215234749.GA57231@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: CAM Target Layer now in stable/9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 23:47:50 -0000 The CAM Target Layer (CTL) is now in stable/9. I am not currently planning to merge it into stable/8, because CTL is now dependent on the sense routines introduced in the CAM descriptor sense changes. The descriptor sense changes required a CAM CCB ABI change, and thus can't be merged back into stable/8. If there is enough demand, I may look into backporting it to stable/8, but otherwise, just use stable/9 or head if you'd like to use CTL. CTL is a disk and processor device emulation subsystem originally written for Copan Systems under Linux starting in 2003. It has been shipping in Copan (now SGI) products since 2005. It was ported to FreeBSD in 2008, and thanks to an agreement between SGI (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is available under a BSD-style license. The intent behind the agreement was that Spectra would work to get CTL into the FreeBSD tree. CTL Features: ============ - Disk and processor device emulation. - Tagged queueing - SCSI task attribute support (ordered, head of queue, simple tags) - SCSI implicit command ordering support. (e.g. if a read follows a mode select, the read will be blocked until the mode select completes.) - Full task management support (abort, LUN reset, target reset, etc.) - Support for multiple ports - Support for multiple simultaneous initiators - Support for multiple simultaneous backing stores - Persistent reservation support - Mode sense/select support - Error injection support - High Availability support (1) - All I/O handled in-kernel, no userland context switch overhead. (1) HA Support is just an API stub, and needs much more to be fully functional. See the to-do list below. Configuring and Running CTL: =========================== - After applying the CTL patchset to your tree, build world and install it on your target system. - Add 'device ctl' to your kernel configuration file. - If you're running with a 8Gb or 4Gb Qlogic FC board, add 'options ISP_TARGET_MODE' to your kernel config file. 'device ispfw' or loading the ispfw module is also recommended. - Rebuild and install a new kernel. - Reboot with the new kernel. - To add a LUN with the RAM disk backend: ctladm create -b ramdisk -s 10485760000000000000 ctladm port -o on - You should now see the CTL disk LUN through camcontrol devlist: scbus6 on ctl2cam0 bus 0: at scbus6 target 1 lun 0 (da24,pass32) <> at scbus6 target -1 lun -1 () This is visible through the CTL CAM SIM. This allows using CTL without any physical hardware. You should be able to issue any normal SCSI commands to the device via the pass(4)/da(4) devices. If any target-capable HBAs are in the system (e.g. isp(4)), and have target mode enabled, you should now also be able to see the CTL LUNs via that target interface. Note that all CTL LUNs are presented to all frontends. There is no LUN masking, or separate, per-port configuration. - Note that the ramdisk backend is a "fake" ramdisk. That is, it is backed by a small amount of RAM that is used for all I/O requests. This is useful for performance testing, but not for any data integrity tests. - To add a LUN with the block/file backend: truncate -s +1T myfile ctladm create -b block -o file=myfile ctladm port -o on Note that if you use a block device as a backend, you should also disable sending synchronize cache commands to the backend, because GEOM can't handle the BIO_FLUSH request. To do that, type: ctladm realsync off You'll want to do that before turning the frontend ports on. - You can also see a list of LUNs and their backends like this: # ctladm devlist LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 10 block 2147483648 512 MYSERIAL 10 MYDEVID 10 11 block 2147483648 512 MYSERIAL 11 MYDEVID 11 - You can see the LUN type and backing store for block/file backend LUNs like this: # ctladm devlist -v LUN Backend Size (Blocks) BS Serial Number Device ID 0 block 2147483648 512 MYSERIAL 0 MYDEVID 0 lun_type=0 num_threads=14 file=testdisk0 1 block 2147483648 512 MYSERIAL 1 MYDEVID 1 lun_type=0 num_threads=14 file=testdisk1 2 block 2147483648 512 MYSERIAL 2 MYDEVID 2 lun_type=0 num_threads=14 file=testdisk2 3 block 2147483648 512 MYSERIAL 3 MYDEVID 3 lun_type=0 num_threads=14 file=testdisk3 4 block 2147483648 512 MYSERIAL 4 MYDEVID 4 lun_type=0 num_threads=14 file=testdisk4 5 block 2147483648 512 MYSERIAL 5 MYDEVID 5 lun_type=0 num_threads=14 file=testdisk5 6 block 2147483648 512 MYSERIAL 6 MYDEVID 6 lun_type=0 num_threads=14 file=testdisk6 7 block 2147483648 512 MYSERIAL 7 MYDEVID 7 lun_type=0 num_threads=14 file=testdisk7 8 block 2147483648 512 MYSERIAL 8 MYDEVID 8 lun_type=0 num_threads=14 file=testdisk8 9 block 2147483648 512 MYSERIAL 9 MYDEVID 9 lun_type=0 num_threads=14 file=testdisk9 10 ramdisk 0 0 MYSERIAL 0 MYDEVID 0 lun_type=3 11 ramdisk 204800000000000 512 MYSERIAL 1 MYDEVID 1 lun_type=0 - To see system throughput, use ctlstat(8): # ctlstat -t System Read System Write System Total ms KB/t tps MB/s ms KB/t tps MB/s ms KB/t tps MB/s 1.71 50.64 0 0.00 1.24 512.00 0 0.03 2.05 245.20 0 0.03 1.0% 0.00 0.00 0 0.00 1.12 512.00 564 282.00 1.12 512.00 564 282.00 8.4% 0.00 0.00 0 0.00 1.27 512.00 536 268.00 1.27 512.00 536 268.00 10.0% 0.00 0.00 0 0.00 1.27 512.00 535 267.50 1.27 512.00 535 267.50 7.6% 0.00 0.00 0 0.00 1.12 512.00 520 260.00 1.12 512.00 520 260.00 10.9% 0.00 0.00 0 0.00 1.02 512.00 538 269.00 1.02 512.00 538 269.00 10.9% 0.00 0.00 0 0.00 1.10 512.00 557 278.50 1.10 512.00 557 278.50 9.6% 0.00 0.00 0 0.00 1.12 512.00 561 280.50 1.12 512.00 561 280.50 10.4% 0.00 0.00 0 0.00 1.14 512.00 502 251.00 1.14 512.00 502 251.00 6.5% 0.00 0.00 0 0.00 1.31 512.00 527 263.50 1.31 512.00 527 263.50 10.5% 0.00 0.00 0 0.00 1.07 512.00 560 280.00 1.07 512.00 560 280.00 10.3% CTL To Do List: ============== - Use devstat(9) for CTL's statistics collection. CTL uses a home-grown statistics collection system that is similar to devstat(9). ctlstat should be retired in favor of iostat, etc., once aggregation modes are available in iostat to match the behavior of ctlstat -t and dump modes are available to match the behavior of ctlstat -d/ctlstat -J. - ZFS ARC backend for CTL. Since ZFS copies all I/O into the ARC (Adaptive Replacement Cache), running the block/file backend on top of a ZFS-backed zdev or file will involve an extra set of copies. The optimal solution for backing targets served by CTL with ZFS would be to allocate buffers out of the ARC directly, and DMA to/from them directly. That would eliminate an extra data buffer allocation and copy. - Switch CTL over to using CAM CCBs instead of its own union ctl_io. This will likely require a significant amount of work, but will eliminate another data structure in the stack, more memory allocations, etc. This will also require changes to the CAM CCB structure to support CTL. - Full-featured High Availability support. The HA API that is in ctl_ha.h is essentially a renamed version of Copan's HA API. There is no substance to it, but it remains in CTL to show what needs to be done to implement active/active HA from a CTL standpoint. The things that would need to be done include: - A kernel level software API for message passing as well as DMA between at least two nodes. - Hardware support and drivers for inter-node communication. This could be as simples as ethernet hardware and drivers. - A "supervisor", or startup framework to control and coordinate HA startup, failover (going from active/active to single mode), and failback (going from single mode to active/active). - HA support in other components of the stack. The goal behind HA is that one node can fail and another node can seamlessly take over handling I/O requests. This requires support from pretty much every component in the storage stack, from top to bottom. CTL is one piece of it, but you also need support in the RAID stack/filesystem/backing store. You also need full configuration mirroring, and all peer nodes need to be able to talk to the underlying storage hardware. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 02:38:44 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40AB7106564A; Thu, 16 Feb 2012 02:38:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 028018FC13; Thu, 16 Feb 2012 02:38:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G2chNn049382; Thu, 16 Feb 2012 02:38:43 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G2chI6049378; Thu, 16 Feb 2012 02:38:43 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 02:38:43 GMT Message-Id: <201202160238.q1G2chI6049378@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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: Thu, 16 Feb 2012 02:38:44 -0000 TB --- 2012-02-16 01:56:44 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 01:56:44 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-02-16 01:56:44 - cleaning the object tree TB --- 2012-02-16 01:56:44 - cvsupping the source tree TB --- 2012-02-16 01:56:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2012-02-16 01:56:55 - building world TB --- 2012-02-16 01:56:55 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 01:56:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 01:56:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 01:56:55 - SRCCONF=/dev/null TB --- 2012-02-16 01:56:55 - TARGET=sparc64 TB --- 2012-02-16 01:56:55 - TARGET_ARCH=sparc64 TB --- 2012-02-16 01:56:55 - TZ=UTC TB --- 2012-02-16 01:56:55 - __MAKE_CONF=/dev/null TB --- 2012-02-16 01:56:55 - cd /src TB --- 2012-02-16 01:56:55 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 01:56:56 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 02:38:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 02:38:43 - ERROR: failed to build world TB --- 2012-02-16 02:38:43 - 2013.02 user 357.14 system 2518.32 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 02:40:22 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27553106567F; Thu, 16 Feb 2012 02:40:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id AB5198FC26; Thu, 16 Feb 2012 02:40:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G2eL5S058684; Thu, 16 Feb 2012 02:40:21 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G2eLQt058682; Thu, 16 Feb 2012 02:40:21 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 02:40:21 GMT Message-Id: <201202160240.q1G2eLQt058682@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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: Thu, 16 Feb 2012 02:40:22 -0000 TB --- 2012-02-16 01:55:48 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 01:55:48 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-02-16 01:55:48 - cleaning the object tree TB --- 2012-02-16 01:55:48 - cvsupping the source tree TB --- 2012-02-16 01:55:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2012-02-16 01:56:36 - building world TB --- 2012-02-16 01:56:36 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 01:56:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 01:56:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 01:56:36 - SRCCONF=/dev/null TB --- 2012-02-16 01:56:36 - TARGET=powerpc TB --- 2012-02-16 01:56:36 - TARGET_ARCH=powerpc TB --- 2012-02-16 01:56:36 - TZ=UTC TB --- 2012-02-16 01:56:36 - __MAKE_CONF=/dev/null TB --- 2012-02-16 01:56:36 - cd /src TB --- 2012-02-16 01:56:36 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 01:56:37 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 02:40:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 02:40:21 - ERROR: failed to build world TB --- 2012-02-16 02:40:21 - 2138.60 user 366.73 system 2673.19 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 03:23:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D9F6106564A; Thu, 16 Feb 2012 03:23:51 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailB.acsu.buffalo.edu (localmailb.acsu.buffalo.edu [128.205.5.200]) by mx1.freebsd.org (Postfix) with ESMTP id E2F178FC08; Thu, 16 Feb 2012 03:23:50 +0000 (UTC) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E8EDE5032; Wed, 15 Feb 2012 22:23:49 -0500 (EST) Received: from localmailB.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailB.acsu.buffalo.edu (Postfix) with ESMTP id 5453D555B; Wed, 15 Feb 2012 22:23:49 -0500 (EST) Received: from smtp1.acsu.buffalo.edu (smtp1.acsu.buffalo.edu [128.205.5.253]) by localmailB.acsu.buffalo.edu (Prefixe) with ESMTP id 23A845032; Wed, 15 Feb 2012 22:23:49 -0500 (EST) Received: from [192.168.1.101] (cpe-72-231-248-9.buffalo.res.rr.com [72.231.248.9]) (Authenticated sender: kensmith@buffalo.edu) by smtp1.acsu.buffalo.edu (Postfix) with ESMTPSA id BD3624AE98; Wed, 15 Feb 2012 22:23:48 -0500 (EST) From: Ken Smith To: freebsd-stable Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ZwEhZcEe0F1tQk7Cs6kX" Organization: U. Buffalo Date: Wed, 15 Feb 2012 22:23:43 -0500 Message-ID: <1329362623.8568.3.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: XX: 28% Cc: re Subject: stable/8 -> 8.3-PRERELEASE... 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, 16 Feb 2012 03:23:51 -0000 --=-ZwEhZcEe0F1tQk7Cs6kX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a quick note to say we have entered code freeze for the 8.3-RELEASE release cycle. As of a few minutes ago stable/8 will identify itself as 8.3-PRERELEASE. The target schedule for the release is available here: http://www.freebsd.org/releases/8.3R/schedule.html Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-ZwEhZcEe0F1tQk7Cs6kX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk88drUACgkQ/G14VSmup/YuJwCcCJkqHXdckIgfwZwR1qTxxt63 DnwAnA+qlcLO81+WDcq8s4YHQz4h4ztn =jBfY -----END PGP SIGNATURE----- --=-ZwEhZcEe0F1tQk7Cs6kX-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:05:58 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEFA61065675 for ; Thu, 16 Feb 2012 05:05:58 +0000 (UTC) (envelope-from john@theusgroup.com) Received: from theusgroup.com (theusgroup.com [64.122.243.222]) by mx1.freebsd.org (Postfix) with ESMTP id B4B498FC16 for ; Thu, 16 Feb 2012 05:05:58 +0000 (UTC) To: Jeremy Chadwick In-reply-to: <20120215191931.GA30747@icarus.home.lan> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <20120215181757.GX2010@equilibrium.bsdes.net> <20120215191931.GA30747@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Wed, 15 Feb 2012 11:19:31 -0800." Date: Wed, 15 Feb 2012 20:48:42 -0800 From: John Message-Id: <20120216044842.282B16B9@server.theusgroup.com> Cc: Victor Balada Diaz , stable@FreeBSD.org Subject: Re: problems with AHCI on FreeBSD 8.2 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, 16 Feb 2012 05:05:58 -0000 Jeremy Chadwick wrote: > > CRC errors ... > >I have no real advice for tracking this kind of problem down. The most >common response is "replace cables", which isn't necessarily the root >cause. I have no advice or tips on how to track down interference >issues, or how to truly examine a disk PCB or controller PCB for the >latter item. "Flaky traces" on a PCB could cause this sort of thing. >Folks in the EE field would know more about these issues; I am not an EE >person. > >Since the attribute increased on both drives simultaneously (I have to >assume simultaneously?), it's more likely that the problem is not with >SATA cables or the drives but the controller on the motherboard. I'd >recommend replacing the motherboard. I make no guarantees this will fix >anything however, but it is the "common point" for both of your drives. This EE agrees with your advise. I would add if replacing the motherboard fails to fix the problem, then replace the power supply. Even with extremely high end test equipment, you likely would never be able to see the failure occur for at least two reasons; the most likely failure mode is inside a single IC, and adding probes would alter the environment enough to change the failure mode. John Theus TheUs Group TheUsGroup.com From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:06:20 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF6C31065701; Thu, 16 Feb 2012 05:06:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 918F18FC08; Thu, 16 Feb 2012 05:06:20 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G56Jvt082402; Thu, 16 Feb 2012 05:06:19 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G56Jtn082395; Thu, 16 Feb 2012 05:06:19 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:06:19 GMT Message-Id: <201202160506.q1G56Jtn082395@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 arm/arm 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: Thu, 16 Feb 2012 05:06:20 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for arm/arm TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2012-02-16 04:30:47 - building world TB --- 2012-02-16 04:30:47 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:30:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:30:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:30:47 - SRCCONF=/dev/null TB --- 2012-02-16 04:30:47 - TARGET=arm TB --- 2012-02-16 04:30:47 - TARGET_ARCH=arm TB --- 2012-02-16 04:30:47 - TZ=UTC TB --- 2012-02-16 04:30:47 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:30:47 - cd /src TB --- 2012-02-16 04:30:47 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:30:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:06:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:06:19 - ERROR: failed to build world TB --- 2012-02-16 05:06:19 - 1642.95 user 386.05 system 2164.02 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:11:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3B891065792; Thu, 16 Feb 2012 05:11:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 441FB8FC1B; Thu, 16 Feb 2012 05:11:43 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5Bg61052431; Thu, 16 Feb 2012 05:11:42 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5BgEp052405; Thu, 16 Feb 2012 05:11:42 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:11:42 GMT Message-Id: <201202160511.q1G5BgEp052405@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 mips/mips 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: Thu, 16 Feb 2012 05:11:43 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for mips/mips TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/mips/mips/supfile TB --- 2012-02-16 04:35:46 - building world TB --- 2012-02-16 04:35:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:35:46 - SRCCONF=/dev/null TB --- 2012-02-16 04:35:46 - TARGET=mips TB --- 2012-02-16 04:35:46 - TARGET_ARCH=mips TB --- 2012-02-16 04:35:46 - TZ=UTC TB --- 2012-02-16 04:35:46 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:35:46 - cd /src TB --- 2012-02-16 04:35:46 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:35:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:11:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:11:42 - ERROR: failed to build world TB --- 2012-02-16 05:11:42 - 1623.78 user 362.94 system 2487.00 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:15:27 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF11E106564A; Thu, 16 Feb 2012 05:15:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 93ECC8FC13; Thu, 16 Feb 2012 05:15:27 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5FRPJ005515; Thu, 16 Feb 2012 05:15:27 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5FRiV005514; Thu, 16 Feb 2012 05:15:27 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:15:27 GMT Message-Id: <201202160515.q1G5FRiV005514@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 i386/i386 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: Thu, 16 Feb 2012 05:15:28 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2012-02-16 04:30:47 - building world TB --- 2012-02-16 04:30:47 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:30:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:30:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:30:47 - SRCCONF=/dev/null TB --- 2012-02-16 04:30:47 - TARGET=i386 TB --- 2012-02-16 04:30:47 - TARGET_ARCH=i386 TB --- 2012-02-16 04:30:47 - TZ=UTC TB --- 2012-02-16 04:30:47 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:30:47 - cd /src TB --- 2012-02-16 04:30:47 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:30:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:15:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:15:27 - ERROR: failed to build world TB --- 2012-02-16 05:15:27 - 2116.91 user 391.07 system 2711.36 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:15:53 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF7A1065686; Thu, 16 Feb 2012 05:15:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 23F328FC1F; Thu, 16 Feb 2012 05:15:53 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5FqM9010228; Thu, 16 Feb 2012 05:15:52 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5Fq3U010224; Thu, 16 Feb 2012 05:15:52 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:15:52 GMT Message-Id: <201202160515.q1G5Fq3U010224@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 amd64/amd64 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: Thu, 16 Feb 2012 05:15:53 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2012-02-16 04:30:47 - building world TB --- 2012-02-16 04:30:47 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:30:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:30:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:30:47 - SRCCONF=/dev/null TB --- 2012-02-16 04:30:47 - TARGET=amd64 TB --- 2012-02-16 04:30:47 - TARGET_ARCH=amd64 TB --- 2012-02-16 04:30:47 - TZ=UTC TB --- 2012-02-16 04:30:47 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:30:47 - cd /src TB --- 2012-02-16 04:30:47 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:30:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:15:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:15:52 - ERROR: failed to build world TB --- 2012-02-16 05:15:52 - 2135.52 user 404.34 system 2736.89 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:20:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBDE5106564A; Thu, 16 Feb 2012 05:20:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 904508FC18; Thu, 16 Feb 2012 05:20:31 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5KV2I064911; Thu, 16 Feb 2012 05:20:31 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5KVxD064907; Thu, 16 Feb 2012 05:20:31 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:20:31 GMT Message-Id: <201202160520.q1G5KVxD064907@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 i386/pc98 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: Thu, 16 Feb 2012 05:20:32 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2012-02-16 04:35:46 - building world TB --- 2012-02-16 04:35:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:35:46 - SRCCONF=/dev/null TB --- 2012-02-16 04:35:46 - TARGET=pc98 TB --- 2012-02-16 04:35:46 - TARGET_ARCH=i386 TB --- 2012-02-16 04:35:46 - TZ=UTC TB --- 2012-02-16 04:35:46 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:35:46 - cd /src TB --- 2012-02-16 04:35:46 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:35:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:20:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:20:31 - ERROR: failed to build world TB --- 2012-02-16 05:20:31 - 2110.75 user 401.74 system 3015.34 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:31:21 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFCD1106566B; Thu, 16 Feb 2012 05:31:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 655618FC08; Thu, 16 Feb 2012 05:31:21 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5VKf5060598; Thu, 16 Feb 2012 05:31:20 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5VK0j060584; Thu, 16 Feb 2012 05:31:20 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:31:20 GMT Message-Id: <201202160531.q1G5VK0j060584@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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 ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 05:31:21 -0000 TB --- 2012-02-16 04:30:15 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 04:30:15 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-02-16 04:30:15 - cleaning the object tree TB --- 2012-02-16 04:30:15 - cvsupping the source tree TB --- 2012-02-16 04:30:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2012-02-16 04:35:46 - building world TB --- 2012-02-16 04:35:46 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 04:35:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 04:35:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 04:35:46 - SRCCONF=/dev/null TB --- 2012-02-16 04:35:46 - TARGET=ia64 TB --- 2012-02-16 04:35:46 - TARGET_ARCH=ia64 TB --- 2012-02-16 04:35:46 - TZ=UTC TB --- 2012-02-16 04:35:46 - __MAKE_CONF=/dev/null TB --- 2012-02-16 04:35:46 - cd /src TB --- 2012-02-16 04:35:46 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 04:35:46 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:31:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:31:20 - ERROR: failed to build world TB --- 2012-02-16 05:31:20 - 2791.66 user 423.30 system 3665.11 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:46:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D353106564A; Thu, 16 Feb 2012 05:46:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 020158FC14; Thu, 16 Feb 2012 05:46:04 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5k4Sm032906; Thu, 16 Feb 2012 05:46:04 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5k4oi032905; Thu, 16 Feb 2012 05:46:04 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:46:04 GMT Message-Id: <201202160546.q1G5k4oi032905@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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: Thu, 16 Feb 2012 05:46:05 -0000 TB --- 2012-02-16 05:06:20 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 05:06:20 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-02-16 05:06:20 - cleaning the object tree TB --- 2012-02-16 05:06:27 - cvsupping the source tree TB --- 2012-02-16 05:06:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2012-02-16 05:07:21 - building world TB --- 2012-02-16 05:07:21 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 05:07:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 05:07:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 05:07:21 - SRCCONF=/dev/null TB --- 2012-02-16 05:07:21 - TARGET=powerpc TB --- 2012-02-16 05:07:21 - TARGET_ARCH=powerpc TB --- 2012-02-16 05:07:21 - TZ=UTC TB --- 2012-02-16 05:07:21 - __MAKE_CONF=/dev/null TB --- 2012-02-16 05:07:21 - cd /src TB --- 2012-02-16 05:07:21 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 05:07:21 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:46:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:46:04 - ERROR: failed to build world TB --- 2012-02-16 05:46:04 - 1977.68 user 329.65 system 2384.45 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 05:47:45 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EB84106567E; Thu, 16 Feb 2012 05:47:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id A73688FC2A; Thu, 16 Feb 2012 05:47:44 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q1G5liLn037015; Thu, 16 Feb 2012 05:47:44 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q1G5liFV037014; Thu, 16 Feb 2012 05:47:44 GMT (envelope-from tinderbox@freebsd.org) Date: Thu, 16 Feb 2012 05:47:44 GMT Message-Id: <201202160547.q1G5liFV037014@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.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: Thu, 16 Feb 2012 05:47:45 -0000 TB --- 2012-02-16 05:11:42 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-02-16 05:11:42 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-02-16 05:11:42 - cleaning the object tree TB --- 2012-02-16 05:11:51 - cvsupping the source tree TB --- 2012-02-16 05:11:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2012-02-16 05:12:11 - building world TB --- 2012-02-16 05:12:11 - CROSS_BUILD_TESTING=YES TB --- 2012-02-16 05:12:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-02-16 05:12:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-02-16 05:12:11 - SRCCONF=/dev/null TB --- 2012-02-16 05:12:11 - TARGET=sparc64 TB --- 2012-02-16 05:12:11 - TARGET_ARCH=sparc64 TB --- 2012-02-16 05:12:11 - TZ=UTC TB --- 2012-02-16 05:12:11 - __MAKE_CONF=/dev/null TB --- 2012-02-16 05:12:11 - cd /src TB --- 2012-02-16 05:12:11 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 16 05:12:12 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.sbin/rtadvd/rtadvd.c:148: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:148: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c:149: error: 'ND_OPT_DNSSL' undeclared here (not in a function) /src/usr.sbin/rtadvd/rtadvd.c:149: error: array index in initializer not of integer type /src/usr.sbin/rtadvd/rtadvd.c:149: error: (near initialization for 'ndopt_flags') /src/usr.sbin/rtadvd/rtadvd.c: In function 'nd6_options': /src/usr.sbin/rtadvd/rtadvd.c:1456: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_rdnss' /src/usr.sbin/rtadvd/rtadvd.c:1461: error: invalid application of 'sizeof' to incomplete type 'struct nd_opt_dnssl' *** Error code 1 Stop in /src/usr.sbin/rtadvd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-02-16 05:47:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-02-16 05:47:44 - ERROR: failed to build world TB --- 2012-02-16 05:47:44 - 1828.16 user 308.36 system 2161.22 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 08:57:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308311065675 for ; Thu, 16 Feb 2012 08:57:22 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id DD1F08FC18 for ; Thu, 16 Feb 2012 08:57:21 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1G8vKoh011379 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 16 Feb 2012 00:57:21 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3CC54B.7080402@freebsd.org> Date: Thu, 16 Feb 2012 00:58:51 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: something wrong with dmesg? 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, 16 Feb 2012 08:57:22 -0000 I just noticed that lately in 9.x and maybe 8-Stable, dmesg seems to return nothing if there is active logging going on. I saw someone else refer to this as well. Has this been reported? From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 09:27:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18476106564A for ; Thu, 16 Feb 2012 09:27:07 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1E98FC0A for ; Thu, 16 Feb 2012 09:27:05 +0000 (UTC) Received: by lagz14 with SMTP id z14so3155578lag.13 for ; Thu, 16 Feb 2012 01:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zM1hhhHOo1kNMcgmxswbvFNut92rat2mWnjdBTkClWk=; b=WgLlEIfLCRd7r7JYn4bEqvY8voUf3Q94Y/gOgDax94hZmGSzYouF/pE3jXezoSC57G h5o9tq037clOsLRk4fhE3N/U3zLJr/eKsM8958ueCGhWejLlL4FBiyU5veVnsKJCe0Hv e5azzbVN49H0LGUokv9C4Upk+FT1Fi00QC6/0= MIME-Version: 1.0 Received: by 10.152.110.102 with SMTP id hz6mr1316235lab.21.1329384425082; Thu, 16 Feb 2012 01:27:05 -0800 (PST) Received: by 10.152.18.4 with HTTP; Thu, 16 Feb 2012 01:27:05 -0800 (PST) In-Reply-To: <4F3CC54B.7080402@freebsd.org> References: <4F3CC54B.7080402@freebsd.org> Date: Thu, 16 Feb 2012 12:27:05 +0300 Message-ID: From: Sergey Kandaurov To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable Subject: Re: something wrong with dmesg? 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, 16 Feb 2012 09:27:07 -0000 On 16 February 2012 12:58, Julian Elischer wrote: > I just noticed that lately in 9.x and maybe 8-Stable, dmesg seems to return > nothing if > there is active logging going on. I saw someone else refer to this as well. > > Has this been reported? Didn't we have this for years? I cannot recall there was a difference to the current behavior since 8.x or 7.x (or even 6.x). kern.msgbuf includes messages sent with syslog, and if they dominate then you might get empty dmesg output. By default it skips non-kernel (or rather those messages which doesn't use BSD syslog format) messages, and you can include them using dmesg -a. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 11:59:07 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D041065672 for ; Thu, 16 Feb 2012 11:59:07 +0000 (UTC) (envelope-from oscarmpp@googlemail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A5298FC18 for ; Thu, 16 Feb 2012 11:59:07 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so3784817obc.13 for ; Thu, 16 Feb 2012 03:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hM2oNe+LPprLeIPZWKnWpwh1DhFUPOWMZkGbkEVgGvY=; b=A3fqM2g9Lobze1+x/iRhKlyWEkulAxHYqIGi8PFKYlFp8xKJ056nqEWC0EHaJ1fods 47z/26PEbETSOxsPhbTCQc8fJsQOmnmHZWIj7hSBS3n+e9ABs6Pvim3pBv01hzAIeG+4 NtCU5xu/iyLjUB6WZmQ0TWSp2nWUELF+Ywo5I= MIME-Version: 1.0 Received: by 10.60.26.133 with SMTP id l5mr802242oeg.22.1329391783542; Thu, 16 Feb 2012 03:29:43 -0800 (PST) Received: by 10.60.78.36 with HTTP; Thu, 16 Feb 2012 03:29:43 -0800 (PST) In-Reply-To: <20120216044842.282B16B9@server.theusgroup.com> References: <20120214091909.GP2010@equilibrium.bsdes.net> <20120214100513.GA94501@icarus.home.lan> <20120214135435.GQ2010@equilibrium.bsdes.net> <20120214141601.GA98986@icarus.home.lan> <20120215181757.GX2010@equilibrium.bsdes.net> <20120215191931.GA30747@icarus.home.lan> <20120216044842.282B16B9@server.theusgroup.com> Date: Thu, 16 Feb 2012 12:29:43 +0100 Message-ID: From: Oscar Prieto To: John Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Victor Balada Diaz , stable@freebsd.org, Jeremy Chadwick Subject: Re: problems with AHCI on FreeBSD 8.2 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, 16 Feb 2012 11:59:07 -0000 Yesterday I did a backup of the sensible stuff of the pool and decided to just break stuff on purpose ;) I writed with dd over the sector marked as faulty by smartctl and runned a smartctl short test. I repeated the process several times until smartctl gave no errors at all on ada3. After that i left the pool doing a scrub and it seemed to repair the integrity of the pool: ------ [root@zaibach ~]# zpool status pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scan: scrub repaired 398K in 10h39m with 0 errors on Thu Feb 16 09:15:59 2= 012 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada2p1 ONLINE 0 0 0 ada1p1 ONLINE 0 0 0 ada3p1 ONLINE 0 0 11 ada0p1 ONLINE 0 0 0 ----- But funnily i got an ahci timeout on other drive, /dev/ada2. ----- Feb 16 04:08:23 zaibach kernel: ahcich2: Timeout on slot 15 port 0 Feb 16 04:08:23 zaibach kernel: ahcich2: is 00000000 cs 00040000 ss 00078000 rs 00078000 tfd c0 serr 00000000 cmd 0004d217 ------- At least a short smartctl test on /dev/ada2 doesn't seem to complain this t= ime. On Thu, Feb 16, 2012 at 5:48 AM, John wrote: > Jeremy Chadwick wrote: >> >> CRC errors ... >> >>I have no real advice for tracking this kind of problem down. =A0The most >>common response is "replace cables", which isn't necessarily the root >>cause. =A0I have no advice or tips on how to track down interference >>issues, or how to truly examine a disk PCB or controller PCB for the >>latter item. =A0"Flaky traces" on a PCB could cause this sort of thing. >>Folks in the EE field would know more about these issues; I am not an EE >>person. >> >>Since the attribute increased on both drives simultaneously (I have to >>assume simultaneously?), it's more likely that the problem is not with >>SATA cables or the drives but the controller on the motherboard. =A0I'd >>recommend replacing the motherboard. =A0I make no guarantees this will fi= x >>anything however, but it is the "common point" for both of your drives. > > This EE agrees with your advise. I would add if replacing the motherboard= fails > to fix the problem, then replace the power supply. Even with extremely hi= gh > end test equipment, you likely would never be able to see the failure occ= ur > for at least two reasons; the most likely failure mode is inside a single= IC, > and adding probes would alter the environment enough to change the failur= e > mode. > > John Theus > TheUs Group > TheUsGroup.com > _______________________________________________ > 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 Thu Feb 16 15:09:59 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C0F81065673 for ; Thu, 16 Feb 2012 15:09:59 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id B30FF8FC25 for ; Thu, 16 Feb 2012 15:09:58 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q1GF9RpI005261; Thu, 16 Feb 2012 10:09:27 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id TWW87928; Thu, 16 Feb 2012 10:09:27 -0500 (EST) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q1GF9RxM010223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 10:09:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> Date: Thu, 16 Feb 2012 10:09:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020203.4F3D1C27.014B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: stable@freebsd.org Subject: Re: ZFS + nullfs + Linuxulator = 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, 16 Feb 2012 15:09:59 -0000 On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote: > On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: >> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC = kernel, last built 2012-02-08). It will panic during the daily periodic = scripts that run at 3am. Here is the most recent panic message: >>=20 >> Fatal trap 9: general protection fault while in kernel mode >> cpuid =3D 0; apic id =3D 00 >> instruction pointer =3D 0x20:0xffffffff8069d266 >> stack pointer =3D 0x28:0xffffff8094b90390 >> frame pointer =3D 0x28:0xffffff8094b903a0 >> code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags =3D resume, IOPL =3D 0 >> current process =3D 72566 (ps) >> trap number =3D 9 >> panic: general protection fault >> cpuid =3D 0 >> KDB: stack backtrace: >> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e >> #1 0xffffffff805facd3 at panic+0x183 >> #2 0xffffffff808e6c20 at trap_fatal+0x290 >> #3 0xffffffff808e715a at trap+0x10a >> #4 0xffffffff808cec64 at calltrap+0x8 >> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 >> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 >> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 >> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 >> #9 0xffffffff8060473f at sysctl_root+0x14f >> #10 0xffffffff80604a2a at userland_sysctl+0x14a >> #11 0xffffffff80604f1a at __sysctl+0xaa >> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 >> #13 0xffffffff808cef5c at Xfast_syscall+0xfc >=20 > Please look up the line number for the fill_kinfo_thread+0x54. Is there a way for me to do this from the above information? As I said = in the original message, I failed to get a crash dump after reboot = (because, it turns out, I hadn't set up my gmirror swap device = properly). Alas, with the latest panic, it appears to have hung[1] = during the "Dumping" phase, so it looks like I won't get a saved crash = dump this time, either. :-( Speaking of the latest panic, here it is: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x308 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff806026ef stack pointer =3D 0x28:0xffffff8094acd2d0 frame pointer =3D 0x28:0xffffff8094acd350 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 20992 (df) trap number =3D 12 panic: page fault cpuid =3D 0 KDB: stack backtrace: #0 0xffffffff8062cf8e at kdb_backtrace+0x5e #1 0xffffffff805facd3 at panic+0x183 #2 0xffffffff808e6c20 at trap_fatal+0x290 #3 0xffffffff808e6f71 at trap_pfault+0x201 #4 0xffffffff808e742f at trap+0x3df #5 0xffffffff808cec64 at calltrap+0x8 #6 0xffffffff80602e1e at _sx_xlock+0x4e #7 0xffffffff80f9ca35 at rrw_enter+0xa5 #8 0xffffffff80f9ce86 at zfs_statfs+0x46 #9 0xffffffff80681258 at __vfs_statfs+0x28 #10 0xffffffff81476521 at nullfs_statfs+0x51 #11 0xffffffff80681258 at __vfs_statfs+0x28 #12 0xffffffff80690b22 at kern_statfs+0x1b2 #13 0xffffffff80690c77 at statfs+0x37 #14 0xffffffff808e62d4 at amd64_syscall+0x1f4 #15 0xffffffff808cef5c at Xfast_syscall+0xfc Cheers, Paul. [1] Not quite hung solid: when I press the power button I get this = appearing on the console: acpi0: suspend request ignored (not ready yet) acpi0: request to enter state S5 failed (err 6) From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 15:49:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4A3106566B for ; Thu, 16 Feb 2012 15:49:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id D012F8FC08 for ; Thu, 16 Feb 2012 15:49:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1GFnWgF095162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 17:49:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1GFnWWT014102; Thu, 16 Feb 2012 17:49:32 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1GFnWJc014101; Thu, 16 Feb 2012 17:49:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 16 Feb 2012 17:49:32 +0200 From: Konstantin Belousov To: Paul Mather Message-ID: <20120216154932.GM3283@deviant.kiev.zoral.com.ua> References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uOOcqLQ8l/YzXNYx" Content-Disposition: inline In-Reply-To: <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: ZFS + nullfs + Linuxulator = 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, 16 Feb 2012 15:49:37 -0000 --uOOcqLQ8l/YzXNYx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote: > On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote: >=20 > > On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: > >> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kernel= , last built 2012-02-08). It will panic during the daily periodic scripts = that run at 3am. Here is the most recent panic message: > >>=20 > >> Fatal trap 9: general protection fault while in kernel mode > >> cpuid =3D 0; apic id =3D 00 > >> instruction pointer =3D 0x20:0xffffffff8069d266 > >> stack pointer =3D 0x28:0xffffff8094b90390 > >> frame pointer =3D 0x28:0xffffff8094b903a0 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags =3D resume, IOPL =3D 0 > >> current process =3D 72566 (ps) > >> trap number =3D 9 > >> panic: general protection fault > >> cpuid =3D 0 > >> KDB: stack backtrace: > >> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e > >> #1 0xffffffff805facd3 at panic+0x183 > >> #2 0xffffffff808e6c20 at trap_fatal+0x290 > >> #3 0xffffffff808e715a at trap+0x10a > >> #4 0xffffffff808cec64 at calltrap+0x8 > >> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 > >> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 > >> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 > >> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 > >> #9 0xffffffff8060473f at sysctl_root+0x14f > >> #10 0xffffffff80604a2a at userland_sysctl+0x14a > >> #11 0xffffffff80604f1a at __sysctl+0xaa > >> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 > >> #13 0xffffffff808cef5c at Xfast_syscall+0xfc > >=20 > > Please look up the line number for the fill_kinfo_thread+0x54. >=20 >=20 > Is there a way for me to do this from the above information? As > I said in the original message, I failed to get a crash dump after > reboot (because, it turns out, I hadn't set up my gmirror swap device > properly). Alas, with the latest panic, it appears to have hung[1] > during the "Dumping" phase, so it looks like I won't get a saved crash > dump this time, either. :-( Load the kernel.debug into kgdb, and from there do "list *fill_kinfo_thread+0x54". --uOOcqLQ8l/YzXNYx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk89JYsACgkQC3+MBN1Mb4jTHQCgqgF5VyownHPJywbHEphRblMH NFoAoNpHWh5b61G9IcxuNpaDzxI7dqQr =7Vbm -----END PGP SIGNATURE----- --uOOcqLQ8l/YzXNYx-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 17:03:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15309106564A for ; Thu, 16 Feb 2012 17:03:18 +0000 (UTC) (envelope-from jflemingeds@yahoo.com) Received: from nm5.bullet.mail.sp2.yahoo.com (nm5.bullet.mail.sp2.yahoo.com [98.139.91.75]) by mx1.freebsd.org (Postfix) with SMTP id D08D88FC13 for ; Thu, 16 Feb 2012 17:03:17 +0000 (UTC) Received: from [98.139.91.64] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 16 Feb 2012 17:03:17 -0000 Received: from [98.139.91.9] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 16 Feb 2012 17:03:17 -0000 Received: from [127.0.0.1] by omp1009.mail.sp2.yahoo.com with NNFMP; 16 Feb 2012 17:03:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 500172.62074.bm@omp1009.mail.sp2.yahoo.com Received: (qmail 24265 invoked by uid 60001); 16 Feb 2012 17:03:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1329411796; bh=P/ZE41+rHhfBoVeEdHMwL7DB3x1IbkmRMpxbFRpLHEA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=epKquST2JUaKB0bPcujjVpjy41CeA/fSJGKqO3IESI+FYLLW/RMBvE8dSQgV7oWzI3YhpkFStduScdlfN1kCPnLri+9GNAF22c65ynUmAku82tRmgZ8PrbgmCw9Sny3OoA8HPDU7mrp96Ay+qqP5OZcUoK9dpxGflXxpMk61kp4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dVupSw9dsAFmKE1ScIewMK2NwbmgiF2bVXUWyCAAobZIF5RK4MssOOSyCzaC4qI2cp2J8n5uziBtvLrxlvIHF3ziwIdU+tADWkzrawkteEeWBvljLRBtk2JCN2jE6x+MC7sNiicjcEjJB+4A7In5QouEA4RxV7T4FFHiH406euQ=; X-YMail-OSG: 15zOE8YVM1lfKEmMrGVOlq3CfIDy7aIcw3jX2UzbLQW85x6 vJb68mzGpvhIROxxqyiOly4BBED.Q9SxRJteK08uT01sjaN9zKjcOqmj03SD USgiLSwjFQdIdrAg33Iwc9FFYannbFNWtlyxEJwv5tdKhRUmbPJfYr.XeqzV 9.bbqGNp78RWbbEhiMuCkWRD4AsD2twDNqSJ.Vh8xfc_B4qjVHskBHuavAnk bPnGLzy0xZQys6h9r5VBY0of1NrEOAi9fxcVAZfjQZy2KJ63vRxmb7DLWj8X 0x4jqq9DAj0rSxPlVO8orP3YwA_vsDoHytYdDu_IzwXZF_nK0WQVT.F.S6kR XgkV8_MHM3GxmuDRWLsUmLwJozZofsUOJxma12aj0KjYI10QdLhCQgBYCOQs CsvZV9sNM61GJii5L1rpeM6QPoSxZftC7aqKvlBk4Dfx6YA1FYdJjqDt4SzR e0lDe Received: from [99.8.58.116] by web111719.mail.gq1.yahoo.com via HTTP; Thu, 16 Feb 2012 09:03:16 PST X-Mailer: YahooMailWebService/0.8.116.338427 References: <1329194588.14324.YahooMailNeo@web111720.mail.gq1.yahoo.com> <20120214051828.GA89777@icarus.home.lan> <1056033736-1329271037-cardhu_decombobulator_blackberry.rim.net-225645010-@b15.c31.bise6.blackberry> Message-ID: <1329411796.23457.YahooMailNeo@web111719.mail.gq1.yahoo.com> Date: Thu, 16 Feb 2012 09:03:16 -0800 (PST) From: john fleming To: "freebsd-stable@freebsd.org" In-Reply-To: <1056033736-1329271037-cardhu_decombobulator_blackberry.rim.net-225645010-@b15.c31.bise6.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 6.2-Release ..ish.. CF + ata == freeze? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john fleming List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:03:18 -0000 The plot is starting to thicken. I've noticed all the systems that have don= e this (so far) have this flash card on them.=0A=0ASTEC M2+ CF 9.0.2 K1186-= 2=0A=0A=0AFrom talking to checkpoint this is a newer flash they have starte= d using. I just had a 4th machine do the same thing yesterday. Basic instal= l, about %70 disk space free, very new install, like 1-2 month and the up t= ime on the machine in question was only 16 days. After rebooting i did a fe= w dd if=3D/dev/zero of=3D~/file bs=3D1m count=3D350 and didn't get any erro= rs.=0A=0AThe latest machine is a 1 gig version of the flash listed above, s= o this ate almost all the free disk space. Checkpoint is asking that we RAM= one of the flash cards so they can play with it.=0A=0A=0A_________________= _______________=0A From: "jflemingeds@yahoo.com" =0A= To: Jeremy Chadwick =0ACc: "freebsd-stable@freeb= sd.org" =0ASent: Tuesday, February 14, 2012 7:= 57 PM=0ASubject: Re: 6.2-Release ..ish.. CF + ata =3D=3D freeze?=0A =0A2 of= the 3 cf cards are very new, like less then 6 months old. =0A=0AI think ar= ound 65-70 percent is in use. This number doesn't change unless the user du= mps data in a home dir, which isn't the case so far. =0A=0AYou are correct = that only writes are failing. Msgbuf has more then what I pasted but I'm pr= etty sure its just more of the same errors. Ill redouble my check. =0A=0ATh= e other slices are very small. One is 35 meg the other is 100 some odd meg.= H is 1.2 gig.=A0 =0A=0AI don't know if ill be able to try the dd test for = a few reasons but ill check it out. Let me ask you this. Say zeroing out th= e drive works without error. Does that tell me anything?=A0 =0A=0AI also do= n't have access to smart tools as this is basically a closed system and the= vendor would never give us access to a complier. Granted I haven't tried j= ust throwing on gcc from 6.2. I could play with that or maybe since said ve= ndor's dev team is keeping track of this thread they could provide said bin= ary :). =0A=0AI really don't like the idea of replacing hardware as I'm loo= king at around 200 boxes. I really hope it doesn't come to that. =0A=0AThan= ks for the reply!=0A=0ASent via BlackBerry from T-Mobile=0A=0A-----Original= Message-----=0AFrom: Jeremy Chadwick =0ADate: Mo= n, 13 Feb 2012 21:18:28 =0ATo: john fleming=0ACc: fr= eebsd-stable@freebsd.org=0ASubject: Re: 6.2-Rel= ease ..ish.. CF + ata =3D=3D freeze?=0A=0AOn Mon, Feb 13, 2012 at 08:43:08P= M -0800, john fleming wrote:=0A> Just thought i would post over here as i'm= not getting a warm fuzzy from checkpoint about being able to find the root= cause of an issue. I have a large install base of IPSO checkpoint firewall= s, which are based on FreeBSD 6.2. I've had 3 firewalls hang basically the = same way, with something that looks like a filesystem issue or an?issue wit= h a CF card. =0A=0AFreeBSD 6.2 was EOL'd in early-to-mid-2008.=A0 The ATA d= river has changed=0Asignificantly since then (present-day uses CAM).=0A=0A>= Does anyone happen to know of any bugs (i've been looking around) that cou= ld cause something like that? Granted, it could be a batch of bad CF cards,= but its odd that i'm seeing the same thing on 3 different boxes and once r= ebooted they seem ok.=0A> ?=0A> Also is it possible to get useful info form= the atacontroller when things go south like this from the ddb prompt?=0A= =0ANot particularly.=A0 What's shown below indicates that the driver had=0A= issued some form of ATA write command (there are multiple kinds per ATA=0As= pecification), and either the underlying media (CF/disk) or controller=0Ast= alled/locked up/took too long.=A0 I forget what the timeout value is in=0A6= .2; I can't be bothered to remember such from 6 years ago.=A0 :-)=0A=0A> Th= is is what shows in show msgbuf=0A> ad0: timeout waiting to issue command= =0A> ad0: error issuing WRITE command=0A> ad0: timeout waiting to issue com= mand=0A> ad0: error issuing WRITE command=0A> ad0: timeout waiting to issue= command=0A> ad0: error issuing WRITE command=0A> ad0: timeout waiting to i= ssue command=0A> ad0: error issuing WRITE command=0A> g_vfs_done():ad0s4h[W= RITE(offset=3D33849344, length=3D131072)]error =3D 5 =0A> g_vfs_done():ad0s= 4h[WRITE(offset=3D33980416, length=3D131072)]error =3D 5 =0A> g_vfs_done():= ad0s4h[WRITE(offset=3D34111488, length=3D131072)]error =3D 5=0A> ?g_vfs_don= e():ad0s4h[WRITE(offset=3D34242560, length=3D131072)]error =3D 5 =0A> g_vfs= _done():ad0s4h[WRITE(offset=3D34373632, length=3D131072)]error =3D 5 =0A=0A= error 5 =3D EIO =3D Input/output error.=A0 But this isn't too big of a=0Asu= rprise given the timeouts you see prior.=0A=0AAre these CF cards brand new = -- meaning, are they completely unused=0A(having never had any writes done = to them), or have they been in use a=0Awhile?=A0 I'm betting they've been i= n use a while, and have probably been=0Adoing many writes over the years.= =0A=0ATwo things to note here:=0A=0A1) The errors you've shown are only hap= pening on writes, not reads.=A0 Of=0Acourse if you omitted information then= this isn't an accurate statement.=0A2) Timeouts are seen when issuing writ= es to some LBA regions.=0A=0AHow full is the CF card, disk-space-wise?=A0 N= ot just ad0s4h, I'm talking=0Aabout the entire card.=A0 How much space is r= oughly available?=A0 They're=0Avery small CF cards (1.8GByte roughly), and = the less space available,=0Athe less effectiveness of wear levelling (and i= n some cases the slower=0Athe writes are).=0A=0AReason I ask: given that th= ese are CF cards, this smells of cards which=0Aare simply "worn down".=A0 C= F cards have limited numbers of writes, and=0Athe card may be "freaking out= " internally when attempting to write to=0Asome LBAs which map to CF sector= s that are, in effect, "bad".=A0 The CF=0Acards' ECC implementation may be = buggy, or may simply be "spinning hard"=0Afor too long.=A0 You can read abo= ut this sort of behaviour on Wikipedia's=0ACompactFlash article.=0A=0AYou w= ouldn't be able to verify this with dd if=3D/dev/ad0, because those=0Aare r= ead operations.=A0 You could zero the media (dd if=3D/dev/zero=0Aof=3D/dev/= ad0) as a form of verification if you wanted.=0A=0ADo you happen to know if= these CF cards support SMART?=A0 If so,=0Ainstalling smartmontools (versio= n 5.42 or newer please) and providing=0Aoutput from "smartctl -a /dev/ad0" = may be helpful to me, but I make no=0Aguarantees anything of use will be sh= own there.=0A=0AOverall my advice would be to replace the CF cards, especia= lly if they=0Ahave been in use for a long while.=A0 It really doesn't matte= r to me that=0Ait's happening on 3 machines (honest), especially if these a= re 6.2=0Amachines with CF cards that have been in use for years.=A0 We're l= ucky to=0Aget 2 years out of our CF cards on our Juniper M120/320s before t= hey=0Astart spitting I/O errors.=A0 Pick larger CF cards as well; more spac= e =3D=0Amore room for effective wear levelling.=0A=0A> ?=0A> ad0: 1882MB at ata0-master PIO4=0A> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5070-0x507f m= em 0x80301000-0x803013ff at device 31.1 on pci0=0A> ata0: o= n atapci0=0A> ata1: on atapci0=0A> atapci1: port 0x5088-0x508f,0x50a4-0x50a7,0x5080-0x5087,0x50a0-0= x50a3,0x5060-0x506f irq 15 at device 31.2 on pci0=0A> ata2: = on atapci1=0A> ata3: on atapci1ad0s4h is basically a r/w u= fs partition on the box where almost anything that needs to be written goes= .=0A> trace=0A> Tracing pid 1101 tid 100043 td 0x656d8460=0A> kdb_enter(608= cc388,6246,656d8460,64ba1400,6095d580,...) at kdb_enter+0x2b=0A> siointr1(6= 4ba1400) at siointr1+0xf0=0A> siointr(64ba1400) at siointr+0x38=0A> intr_ex= ecute_handler(6095d580,f0a4ab04,6,6095d580,f0a4aafc,...) at intr_execute_ha= ndler+0x61=0A> intr_execute_handlers(6095d580,f0a4ab04,6,0,656d8460,...) at= intr_execute_handlers+0x40=0A> atpic_handle_intr(4) at atpic_handle_intr+0= x96=0A> Xatpic_intr4() at Xatpic_intr4+0x20=0A> --- interrupt, eip =3D 0x60= 6044af, esp =3D 0xf0a4ab48, ebp =3D 0xf0a4ab5c ---=0A> lockmgr(e1456a04,6,0= ,656d8460) at lockmgr+0x58f=0A> getdirtybuf(e14569a4,60a405e4,1) at getdirt= ybuf+0x2e2=0A> flush_deplist(68b30850,1,f0a4abb8) at flush_deplist+0x30=0A>= flush_inodedep_deps(656fa28c,1f235) at flush_inodedep_deps+0xcf=0A> softde= p_sync_metadata(65964618) at softdep_sync_metadata+0x61=0A> ffs_syncvnode(6= 5964618,1) at ffs_syncvnode+0x3a2=0A> ffs_fsync(f0a4ac74) at ffs_fsync+0x12= =0A> VOP_FSYNC_APV(60949260,f0a4ac74) at VOP_FSYNC_APV+0x38=0A> fsync(656d8= 460,f0a4acb4) at fsync+0x170=0A> syscall(805003b,806003b,5fbf003b,8050000,2= 88be450,...) at syscall+0x2ee=0A> Xint0x80_syscall() at Xint0x80_syscall+0x= 1f=0A=0A-- =0A| Jeremy Chadwick=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 jdc@parodius.com |=0A| Parodius Networking=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.parodius.com/ |=0A| UNIX Systems Adm= inistrator=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mountain View, CA, US |=0A| Maki= ng life hard for others since 1977.=A0 =A0 =A0 =A0 =A0 =A0 PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 17:19:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C18106564A for ; Thu, 16 Feb 2012 17:19:32 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 35F1B8FC1B for ; Thu, 16 Feb 2012 17:19:31 +0000 (UTC) Received: from vivi.cc.vt.edu (vivi.cc.vt.edu [198.82.163.43]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q1GHJ1gL006439; Thu, 16 Feb 2012 12:19:01 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by vivi.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id UHI24539; Thu, 16 Feb 2012 12:19:01 -0500 (EST) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q1GHJ1mt010759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Feb 2012 12:19:01 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <20120216154932.GM3283@deviant.kiev.zoral.com.ua> Date: Thu, 16 Feb 2012 12:07:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> <20120216154932.GM3283@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=vivi.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020201.4F3D3A85.007B,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: stable@freebsd.org Subject: Re: ZFS + nullfs + Linuxulator = 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, 16 Feb 2012 17:19:32 -0000 On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote: > On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote: >> On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote: >>=20 >>> On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: >>>> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC = kernel, last built 2012-02-08). It will panic during the daily periodic = scripts that run at 3am. Here is the most recent panic message: >>>>=20 >>>> Fatal trap 9: general protection fault while in kernel mode >>>> cpuid =3D 0; apic id =3D 00 >>>> instruction pointer =3D 0x20:0xffffffff8069d266 >>>> stack pointer =3D 0x28:0xffffff8094b90390 >>>> frame pointer =3D 0x28:0xffffff8094b903a0 >>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b >>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags =3D resume, IOPL =3D 0 >>>> current process =3D 72566 (ps) >>>> trap number =3D 9 >>>> panic: general protection fault >>>> cpuid =3D 0 >>>> KDB: stack backtrace: >>>> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e >>>> #1 0xffffffff805facd3 at panic+0x183 >>>> #2 0xffffffff808e6c20 at trap_fatal+0x290 >>>> #3 0xffffffff808e715a at trap+0x10a >>>> #4 0xffffffff808cec64 at calltrap+0x8 >>>> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 >>>> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 >>>> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 >>>> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 >>>> #9 0xffffffff8060473f at sysctl_root+0x14f >>>> #10 0xffffffff80604a2a at userland_sysctl+0x14a >>>> #11 0xffffffff80604f1a at __sysctl+0xaa >>>> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 >>>> #13 0xffffffff808cef5c at Xfast_syscall+0xfc >>>=20 >>> Please look up the line number for the fill_kinfo_thread+0x54. >>=20 >>=20 >> Is there a way for me to do this from the above information? As >> I said in the original message, I failed to get a crash dump after >> reboot (because, it turns out, I hadn't set up my gmirror swap device >> properly). Alas, with the latest panic, it appears to have hung[1] >> during the "Dumping" phase, so it looks like I won't get a saved = crash >> dump this time, either. :-( >=20 > Load the kernel.debug into kgdb, and from there do > "list *fill_kinfo_thread+0x54". gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you = are welcome to change it and/or distribute copies of it under certain = conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for = details. This GDB was configured as "amd64-marcel-freebsd"... (kgdb) list *fill_kinfo_thread+0x54 0xffffffff805ee034 is in fill_kinfo_thread = (/usr/src/sys/kern/kern_proc.c:854). 849 thread_lock(td); 850 if (td->td_wmesg !=3D NULL) 851 strlcpy(kp->ki_wmesg, td->td_wmesg, = sizeof(kp->ki_wmesg)); 852 else 853 bzero(kp->ki_wmesg, sizeof(kp->ki_wmesg)); 854 strlcpy(kp->ki_ocomm, td->td_name, = sizeof(kp->ki_ocomm)); 855 if (TD_ON_LOCK(td)) { 856 kp->ki_kiflag |=3D KI_LOCKBLOCK; 857 strlcpy(kp->ki_lockname, td->td_lockname, 858 sizeof(kp->ki_lockname)); (kgdb)=20 Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 17:34:44 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C217F1065674; Thu, 16 Feb 2012 17:34:44 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2518FC1C; Thu, 16 Feb 2012 17:34:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23892; Thu, 16 Feb 2012 19:34:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3D3E2D.9090100@FreeBSD.org> Date: Thu, 16 Feb 2012 19:34:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> In-Reply-To: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: threads@FreeBSD.org, FreeBSD Stable , Jens Axboe Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 16 Feb 2012 17:34:44 -0000 on 15/02/2012 23:41 Julian Elischer said the following: > The program fio (an IO test in ports) uses pthreads > > the following code (from fio-2.0.3, but its in earlier code too) > has suddenly started misbehaving. > > clock_gettime(CLOCK_REALTIME, &t); > t.tv_sec += seconds + 10; > > pthread_mutex_lock(&mutex->lock); > > while (!mutex->value && !ret) { > mutex->waiters++; > ret = pthread_cond_timedwait(&mutex->cond, &mutex->lock, &t); > mutex->waiters--; > } > > if (!ret) { > mutex->value--; > pthread_mutex_unlock(&mutex->lock); > } > > > It turns out that 'ret' sometimes comes back instantly (on my machine) with a > value of 60 (ETIMEDOUT) > despite the fact that we set the timeout 10 seconds into the future. > > Has anyone else seen anything like this? > (and yes the condition variable attribute have been set to use the REALTIME clock). But why? Just a hypothesis that maybe there is some issue with time keeping on that system. How would that code work out for you with MONOTONIC? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 21:01:07 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C3EC106566B; Thu, 16 Feb 2012 21:01:07 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D1138FC08; Thu, 16 Feb 2012 21:01:07 +0000 (UTC) Received: by ggnk5 with SMTP id k5so1799516ggn.13 for ; Thu, 16 Feb 2012 13:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cZLGWtyu9fEJA2zc3zkdNdd7yGj2BpCigRGE7Iiiq1k=; b=JAed+uVrt24eeoS+CKLeG/ta8zA8MnW4uyK716RwC1Cs00P57yRjDa4ZjlOpJeOBgQ /RK05KWQqz9UYhQFL3pWNMHgJthyKnsJm4E4jhB87fiurcwkR4dVtIqpySCCwlT+Nlup TpNnUR6edC8KtjKrDimun+TdKJjcwD/OEgT3s= MIME-Version: 1.0 Received: by 10.101.152.1 with SMTP id e1mr1686205ano.83.1329424203978; Thu, 16 Feb 2012 12:30:03 -0800 (PST) Received: by 10.236.22.138 with HTTP; Thu, 16 Feb 2012 12:30:03 -0800 (PST) Date: Thu, 16 Feb 2012 21:30:03 +0100 Message-ID: From: Oliver Pinter To: mm@freebsd.org Content-Type: multipart/mixed; boundary=001636c5a46f6f16e904b91ab11b Cc: stable@freebsd.org Subject: ffmpeg patch to fix build with libvpx 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, 16 Feb 2012 21:01:07 -0000 --001636c5a46f6f16e904b91ab11b Content-Type: text/plain; charset=ISO-8859-1 --001636c5a46f6f16e904b91ab11b Content-Type: text/x-diff; charset=US-ASCII; name="multimedia-ffmpeg-Makefile.diff" Content-Disposition: attachment; filename="multimedia-ffmpeg-Makefile.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 LS0tIC90bXAvTWFrZWZpbGUub3JpZwkyMDEyLTAyLTE2IDIxOjI3OjE5LjAwMDAwMDAwMCArMDEw MAorKysgTWFrZWZpbGUJMjAxMi0wMi0xNiAyMToyNzozMC4wMDAwMDAwMDAgKzAxMDAKQEAgLTM1 Nyw3ICszNTcsNyBAQAogCiAjIHZwOAogLmlmICFkZWZpbmVkKFdJVEhPVVRfVlA4KQotTElCX0RF UEVORFMrPQl2cHguMDoke1BPUlRTRElSfS9tdWx0aW1lZGlhL2xpYnZweAorTElCX0RFUEVORFMr PQl2cHguMToke1BPUlRTRElSfS9tdWx0aW1lZGlhL2xpYnZweAogQ09ORklHVVJFX0FSR1MrPQkt LWVuYWJsZS1saWJ2cHgKIC5lbHNlCiBDT05GSUdVUkVfQVJHUys9CS0tZGlzYWJsZS1saWJ2cHgK --001636c5a46f6f16e904b91ab11b-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 21:05:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EC7E106564A; Thu, 16 Feb 2012 21:05:09 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECC08FC0A; Thu, 16 Feb 2012 21:05:09 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1GL554j015543 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 13:05:08 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3D6FDD.9050808@freebsd.org> Date: Thu, 16 Feb 2012 13:06:37 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> In-Reply-To: <4F3D3E2D.9090100@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , Jens Axboe Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 16 Feb 2012 21:05:09 -0000 On 2/16/12 9:34 AM, Andriy Gapon wrote: > on 15/02/2012 23:41 Julian Elischer said the following: >> The program fio (an IO test in ports) uses pthreads >> >> the following code (from fio-2.0.3, but its in earlier code too) >> has suddenly started misbehaving. >> >> clock_gettime(CLOCK_REALTIME,&t); >> t.tv_sec += seconds + 10; >> >> pthread_mutex_lock(&mutex->lock); >> >> while (!mutex->value&& !ret) { >> mutex->waiters++; >> ret = pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >> mutex->waiters--; >> } >> >> if (!ret) { >> mutex->value--; >> pthread_mutex_unlock(&mutex->lock); >> } >> >> >> It turns out that 'ret' sometimes comes back instantly (on my machine) with a >> value of 60 (ETIMEDOUT) >> despite the fact that we set the timeout 10 seconds into the future. >> >> Has anyone else seen anything like this? >> (and yes the condition variable attribute have been set to use the REALTIME clock). > But why? > > Just a hypothesis that maybe there is some issue with time keeping on that system. > How would that code work out for you with MONOTONIC? Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, and they both had the same problem.. i.e. random early returns with ETIMEDOUT. I think we will try move out machine forward to a newer -stable to see if it resolves. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 21:33:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B631106566C for ; Thu, 16 Feb 2012 21:33:06 +0000 (UTC) (envelope-from JAxboe@fusionio.com) Received: from mx1.fusionio.com (mx1.fusionio.com [66.114.96.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4F6378FC12 for ; Thu, 16 Feb 2012 21:33:06 +0000 (UTC) X-ASG-Debug-ID: 1329426816-03d6a50ee0138200001-BIHDGU Received: from mail1.int.fusionio.com (mail1.int.fusionio.com [10.101.1.21]) by mx1.fusionio.com with ESMTP id 6Wqqh7uHIwmH680t; Thu, 16 Feb 2012 14:13:36 -0700 (MST) X-Barracuda-Envelope-From: JAxboe@fusionio.com Received: from [192.168.0.212] (188.20.58.220) by mail.fusionio.com (10.101.1.19) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 16 Feb 2012 14:13:35 -0700 Message-ID: <4F3D717C.9040309@fusionio.com> Date: Thu, 16 Feb 2012 22:13:32 +0100 From: Jens Axboe MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> X-ASG-Orig-Subj: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) In-Reply-To: <4F3D6FDD.9050808@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail1.int.fusionio.com[10.101.1.21] X-Barracuda-Start-Time: 1329426816 X-Barracuda-URL: http://10.101.1.180:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at fusionio.com X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88735 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Kabaev , "threads@freebsd.org" , FreeBSD Stable , Andriy Gapon , Alexander Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 16 Feb 2012 21:33:06 -0000 On 2012-02-16 22:06, Julian Elischer wrote: > On 2/16/12 9:34 AM, Andriy Gapon wrote: >> on 15/02/2012 23:41 Julian Elischer said the following: >>> The program fio (an IO test in ports) uses pthreads >>> >>> the following code (from fio-2.0.3, but its in earlier code too) >>> has suddenly started misbehaving. >>> >>> clock_gettime(CLOCK_REALTIME,&t); >>> t.tv_sec += seconds + 10; >>> >>> pthread_mutex_lock(&mutex->lock); >>> >>> while (!mutex->value&& !ret) { >>> mutex->waiters++; >>> ret = pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>> mutex->waiters--; >>> } >>> >>> if (!ret) { >>> mutex->value--; >>> pthread_mutex_unlock(&mutex->lock); >>> } >>> >>> >>> It turns out that 'ret' sometimes comes back instantly (on my machine) with a >>> value of 60 (ETIMEDOUT) >>> despite the fact that we set the timeout 10 seconds into the future. >>> >>> Has anyone else seen anything like this? >>> (and yes the condition variable attribute have been set to use the REALTIME clock). >> But why? >> >> Just a hypothesis that maybe there is some issue with time keeping on that system. >> How would that code work out for you with MONOTONIC? > > Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, and > they both had the same problem.. > i.e. random early returns with ETIMEDOUT. Yep indeed, using either MONOTONIC or REALTIME (and having set both with pthread_condattr_setclock()), no change in behaviour. -- Jens Axboe From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 22:15:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C821065670 for ; Thu, 16 Feb 2012 22:15:13 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 442B68FC14 for ; Thu, 16 Feb 2012 22:15:13 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1GMFBUX015765 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 14:15:12 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3D804B.8000008@freebsd.org> Date: Thu, 16 Feb 2012 14:16:43 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Sergey Kandaurov References: <4F3CC54B.7080402@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: something wrong with dmesg? 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, 16 Feb 2012 22:15:13 -0000 On 2/16/12 1:27 AM, Sergey Kandaurov wrote: > On 16 February 2012 12:58, Julian Elischer wrote: >> I just noticed that lately in 9.x and maybe 8-Stable, dmesg seems to return >> nothing if >> there is active logging going on. I saw someone else refer to this as well. >> >> Has this been reported? > Didn't we have this for years? I cannot recall there was a difference to the > current behavior since 8.x or 7.x (or even 6.x). > kern.msgbuf includes messages sent with syslog, and if they dominate > then you might get empty dmesg output. By default it skips non-kernel > (or rather those messages which doesn't use BSD syslog format) > messages, and you can include them using dmesg -a. > I expect to see the output from all kernel 'printf' statements in dmesg. they were definitely not turning up for me last week, but if I tried again, there would be contents, From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 22:48:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85B231065670 for ; Thu, 16 Feb 2012 22:48:19 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [69.77.177.114]) by mx1.freebsd.org (Postfix) with ESMTP id 590668FC0C for ; Thu, 16 Feb 2012 22:48:19 +0000 (UTC) Received: from [172.16.10.157] (unknown [172.16.10.157]) by mail.intertainservices.com (Postfix) with ESMTPSA id D465B5643F for ; Thu, 16 Feb 2012 17:31:08 -0500 (EST) Message-ID: <1329431468.2054.17.camel@localhost> From: Mike Jakubik To: freebsd-stable@freebsd.org Date: Thu, 16 Feb 2012 17:31:08 -0500 In-Reply-To: <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16) Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: D465B5643F.AFA72 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Subject: RE: New BSD Installer 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, 16 Feb 2012 22:48:19 -0000 On Tue, 2012-02-14 at 09:43 -0800, Devin Teske wrote: > I'm with you on this one. I really don't like the single-"/" setup. > > > > while booting multiple systems on GPT also seems to require Linux tools. > > > > I don't know whether this move away from BSD traditional filesystem > > partitioning (/, /var, /usr etc) to Linux-style came down from Core On > > High or is just the prerogative of installer-writers? Jordan was both > > the latter and a big part of the former for many years, but I guess > > that's something that can be reverted if people feel to do so. > > > > Maybe a vote should be taken. There's about 12 votes in this office here alone > for putting the partition scheme back the way it was (Colin Percival had a great > formula for determining partition sizes). > You got my vote for the traditional partitioning scheme. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 22:55:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 892DE1065677; Thu, 16 Feb 2012 22:55:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9498FC14; Thu, 16 Feb 2012 22:55:47 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1GMtj5P015873 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 14:55:46 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3D89CD.9050309@freebsd.org> Date: Thu, 16 Feb 2012 14:57:17 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> In-Reply-To: <4F3D6FDD.9050808@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , Jens Axboe Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 16 Feb 2012 22:55:47 -0000 On 2/16/12 1:06 PM, Julian Elischer wrote: > On 2/16/12 9:34 AM, Andriy Gapon wrote: >> on 15/02/2012 23:41 Julian Elischer said the following: >>> The program fio (an IO test in ports) uses pthreads >>> >>> the following code (from fio-2.0.3, but its in earlier code too) >>> has suddenly started misbehaving. >>> >>> clock_gettime(CLOCK_REALTIME,&t); >>> t.tv_sec += seconds + 10; >>> >>> pthread_mutex_lock(&mutex->lock); >>> >>> while (!mutex->value&& !ret) { >>> mutex->waiters++; >>> ret = >>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>> mutex->waiters--; >>> } >>> >>> if (!ret) { >>> mutex->value--; >>> pthread_mutex_unlock(&mutex->lock); >>> } >>> >>> >>> It turns out that 'ret' sometimes comes back instantly (on my >>> machine) with a >>> value of 60 (ETIMEDOUT) >>> despite the fact that we set the timeout 10 seconds into the future. >>> >>> Has anyone else seen anything like this? >>> (and yes the condition variable attribute have been set to use the >>> REALTIME clock). >> But why? >> >> Just a hypothesis that maybe there is some issue with time keeping >> on that system. >> How would that code work out for you with MONOTONIC? > > Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, > and they both had the same problem.. > i.e. random early returns with ETIMEDOUT. > > I think we will try move out machine forward to a newer -stable to > see if it resolves. Kan upgraded the machine today to today's 9.x branch tip and the problem still occurs. 8.x does not have this problem. I have not got a 9-RELEASE machine to test on.. so I can not tell if this came in with the burst of stuff that came in after the 9.x branch was unfrozen after the release of 9.0. > > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 22:59:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD1F1065680 for ; Thu, 16 Feb 2012 22:59:57 +0000 (UTC) (envelope-from prvs=139337f927=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 73DB58FC08 for ; Thu, 16 Feb 2012 22:59:56 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Thu, 16 Feb 2012 22:49:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018101420.msg for ; Thu, 16 Feb 2012 22:49:01 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=139337f927=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <1F7793659A864776BF0DD68DD3F68444@multiplay.co.uk> From: "Steven Hartland" To: Date: Thu, 16 Feb 2012 22:48:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: ahci / ada hiding disk errors? 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, 16 Feb 2012 22:59:57 -0000 We've got a machine here with a suspected failed disk but the ahci driver seems to be hiding the details of any failure and only displaying "Synchronize cache failed" to the console. Switching to IDE mode in the bios and using the old adX devices show info such as:- ad6: 953869MB at ata3-master UDMA100 SATA 3Gb/s ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525165 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525151 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525164 ad6: FAILURE - READ_DMA status=51 error=4 LBA=128 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 ad6: FAILURE - READ_DMA status=51 error=4 LBA=16 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525105 ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 So should we be getting more info on this from the ahci driver? The machine is currently running a long smart test on the drive as a short test showed no errors. Any ideas if the disk is bad or possibly a controller failure? mfsbsd# smartctl -a /dev/ad6 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ST91000640NS Serial Number: 9XG05QJY Firmware Version: SN01 User Capacity: 1,000,204,886,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Thu Feb 16 18:08:32 2012 UTC SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 246) Self-test routine in progress... 60% of test remaining. Total time to complete Offline data collection: ( 642) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 208) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x10bd) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 082 063 044 Pre-fail Always - 171321356 3 Spin_Up_Time 0x0003 094 094 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 17 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 074 060 030 Pre-fail Always - 29134930 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 6659 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 17 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 078 046 045 Old_age Always - 22 (Min/Max 21/23) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 12 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 17 194 Temperature_Celsius 0x0022 022 054 000 Old_age Always - 22 (0 14 0 0) 195 Hardware_ECC_Recovered 0x001a 118 099 000 Old_age Always - 171321356 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Self-test routine in progress 60% 6659 - # 2 Short offline Completed without error 00% 6657 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 16 23:52:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50CFF106564A for ; Thu, 16 Feb 2012 23:52:54 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 380B88FC0A for ; Thu, 16 Feb 2012 23:52:53 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta11.emeryville.ca.mail.comcast.net with comcast id ange1i0051vN32cABnstoJ; Thu, 16 Feb 2012 23:52:53 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id anss1i00D1t3BNj8inssXu; Thu, 16 Feb 2012 23:52:53 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 58184102C1E; Thu, 16 Feb 2012 15:52:52 -0800 (PST) Date: Thu, 16 Feb 2012 15:52:52 -0800 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20120216235252.GA59094@icarus.home.lan> References: <1F7793659A864776BF0DD68DD3F68444@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F7793659A864776BF0DD68DD3F68444@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: ahci / ada hiding disk errors? 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, 16 Feb 2012 23:52:54 -0000 On Thu, Feb 16, 2012 at 10:48:00PM -0000, Steven Hartland wrote: > We've got a machine here with a suspected failed disk but > the ahci driver seems to be hiding the details of any failure > and only displaying "Synchronize cache failed" to the console. > > Switching to IDE mode in the bios and using the old adX devices > show info such as:- > > ad6: 953869MB at ata3-master UDMA100 SATA 3Gb/s > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525165 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525151 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525164 > ad6: FAILURE - READ_DMA status=51 error=4 LBA=128 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 > ad6: FAILURE - READ_DMA status=51 error=4 LBA=16 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525167 > ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 > ad6: FAILURE - READ_DMA48 status=51 error=4 LBA=1953525105 > ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 > ad6: FAILURE - READ_DMA status=51 error=4 LBA=0 These types of messages can be returned by ahci.ko and related CAM bits. They're formatted quite differently, but the same indications are given. What you need to be aware of is that quite often the ata(4) driver would spit out errors for things which weren't really errors. Likewise, I remember seeing vfs_xxx_x functions often spit out errno=5 for filesystem stuff with LBAs that were negative or totally off the scale (e.g. exceeded the LBA range of the actual disk). Thus, I was left to believe the ata(4) driver had some serious bugs in it. The above logs indicate that the ATA READ requests are failing to almost random LBAs. Note that LBA 0 is listed -- sector 0 is quite special as I'm sure you know -- so I'm quite surprised by that one, especially if other I/O to the disk works. It's worth pointing out that all of the errors shown above are on READ operations, which seems to imply sector problems, except the SMART stats show no such issues. Keep reading. A possibility is power-related problems, where the drive may be being fed improper voltages (it needs 5V, 12V, and 3.3V -- yep all 3) at some times, which can cause all sorts of craziness on a drive. > So should we be getting more info on this from the ahci driver? The driver is quite verbose as-is, IMHO. > The machine is currently running a long smart test on the drive as a > short test showed no errors. Short tests do not do surface scans. Long tests *may* do a surface scan, but it varies from drive to drive (I keep having to have arguments with people off-list about this who insist long tests do surface scans on all drives -- this is not the case). > Any ideas if the disk is bad or possibly a controller failure? A controller failure should appear differently. Communication failures between the disk and controller would also not show up/manifest themselves as what you've shown above. CRC errors between host controller and disk controller would show up in SMART attribute 199. > mfsbsd# smartctl -a /dev/ad6 > smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build) > Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Device Model: ST91000640NS > Serial Number: 9XG05QJY > Firmware Version: SN01 > User Capacity: 1,000,204,886,016 bytes > Device is: Not in smartctl database [for details use: -P showall] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 4 > Local Time is: Thu Feb 16 18:08:32 2012 UTC > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > {snipping} > > Self-test execution status: ( 246) Self-test routine in progress... > 60% of test remaining. It's important to note here that your self-test run is still running. It's very easy to miss this. > {snipping} > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 082 063 044 Pre-fail Always - 171321356 > 3 Spin_Up_Time 0x0003 094 094 000 Pre-fail Always - 0 > 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 17 > 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000f 074 060 030 Pre-fail Always - 29134930 > 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 6659 > 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 17 > 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 > 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 > 190 Airflow_Temperature_Cel 0x0022 078 046 045 Old_age Always - 22 (Min/Max 21/23) > 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 > 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 12 > 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 17 > 194 Temperature_Celsius 0x0022 022 054 000 Old_age Always - 22 (0 14 0 0) > 195 Hardware_ECC_Recovered 0x001a 118 099 000 Old_age Always - 171321356 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 I see absolutely no anomalies here. Literally the disk looks perfectly fine. Given my comments about voltage concerns, I would recommend you watch attribute 12 the next time you see I/O errors. If it increments, then your drive is losing power in the middle of I/O operations. Other attributes such as 1, 7, and 195 are all vendor-encoded and thus are not literal counters. This is normal for Seagate disks. All of these will almost always have non-zero values in them, given that there are always some degree of errors when reading from magnetic media -- this is what the ECC section per-sector is used to address. I will also point out that this is not a problem with your drive's on-board cache. That would show up in attribute 184. > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error > # 1 Extended offline Self-test routine in progress 60% 6659 - > # 2 Short offline Completed without error 00% 6657 - The long test is still running, as I stated above. Also, just as a data point: folks should remember to completely ignore the "remaining" percentage shown -- it is hardly ever accurate, especially on Western Digital drives. I would appreciate if you could provide actual timestamps associated with the above I/O errors from your logs. One of the kernel logs, probably messages (or all.log if you enable it -- I HIGHLY recomment folks do!) -- should have actual datestamps too. I'd like to see how often these occur, or if all at once. Otherwise I see nothing wrong with your drive. As such, I'm inclined to believe what you're seeing is probably a bug in the ata(4) driver. Also, just for amusement value: so far in the past 7 days, this is the *TENTH* disk-related issue I have had to look at from people on the Internet (not just FreeBSD either). I don't know what's going on, but you people are practically requiring me to make this a full-time job. Hell, maybe I should start doing "consulting" on these type of things, haha. I will take this opportunity to give a shout-out to mav@ and related folks (I think avg@ had some involvement, maybe not?) for the AHCI-to-CAM layer bits, as well as the latest ATA-to-CAM bits too. I'm really glad to see us moving away from ata(4). I say that as respectfully as possible towards the original author Soren Schmidt, whose work on ata(4) and "ATAng" over the years shouldn't be forgotten. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 00:08:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276AD106566B for ; Fri, 17 Feb 2012 00:08:34 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D20638FC08 for ; Fri, 17 Feb 2012 00:08:33 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id AEC8C28424; Fri, 17 Feb 2012 01:08:30 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CEFF728423; Fri, 17 Feb 2012 01:08:29 +0100 (CET) Message-ID: <4F3D9A7C.7080900@quip.cz> Date: Fri, 17 Feb 2012 01:08:28 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Mike Andrews References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> In-Reply-To: <4F3ACDE7.8060003@bit0.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: New BSD Installer 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, 17 Feb 2012 00:08:34 -0000 Mike Andrews wrote: > On 2/14/2012 3:05 PM, Devin Teske wrote: >> Please don't get rid of fdisk or bsdlabel as they are (and forever >> will be) >> required to do things like: >> >> 1. scripted formatting of a thumb drive >> >> 2. automated probing of disk information (fdisk -p) >> >> 3. Other tasks that are not suitably handled by curses-based utilities >> >> For example, the following command will create a second Windows >> partition on a >> thumb drive without user interaction: >> >> echo "p 2 0x0c * *" | fdisk -f - /dev/da0 >> >> If you take away fdisk, how am I supposed to achieve the above? > > /sbin/gpart add -t 12 -i 2 da0 > > (Untested, but that should work...) > > gpart is very scriptable, and still handles MBR and bsdlabel partitions > if you need to work with removable media or volumes that will never be > larger than 2 TB. "gpart list" and "gpart show" would get you all the > machine-parsable stuff you'd ever need. > > The 2 TB limit is *the* reason to move from MBR+bsdlabel to GPT though. > Even without RAID, 3 TB disks exist already. :) With FreeBSD's boot > code, you don't even need an EFI-capable machine to boot from a > GPT-partitioned device. For non-removable media, it's time to move on. > Really. :) Even on smaller 250 GB disks, I'm using GPT just because > there's no reason not to... it's just cleaner and it was easier to write > gpart scripts than it was to script fdisk/bsdlabel scripts anyway. Please don't mix two things together. gpart can replace fdisk and bsdlabel, but GPT vs. MBR is a different thing. GPT doesn't play nice with GEOM classes which store their metadata on last sector. For example, you can't use gmirror of a whole drives and use GPT on top of this mirror. (and gmirror is not the only one) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 00:18:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF12F106566B for ; Fri, 17 Feb 2012 00:18:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 68BA18FC0C for ; Fri, 17 Feb 2012 00:18:31 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta12.westchester.pa.mail.comcast.net with comcast id an8b1i0031wpRvQ5CoJXnl; Fri, 17 Feb 2012 00:18:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta18.westchester.pa.mail.comcast.net with comcast id aoJW1i00V1t3BNj3eoJWEv; Fri, 17 Feb 2012 00:18:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 331C6102C1F; Thu, 16 Feb 2012 16:18:29 -0800 (PST) Date: Thu, 16 Feb 2012 16:18:29 -0800 From: Jeremy Chadwick To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20120217001829.GA59869@icarus.home.lan> References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3D9A7C.7080900@quip.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, Mike Andrews Subject: Re: New BSD Installer 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, 17 Feb 2012 00:18:31 -0000 On Fri, Feb 17, 2012 at 01:08:28AM +0100, Miroslav Lachman wrote: > Mike Andrews wrote: > >On 2/14/2012 3:05 PM, Devin Teske wrote: > >>Please don't get rid of fdisk or bsdlabel as they are (and forever > >>will be) > >>required to do things like: > >> > >>1. scripted formatting of a thumb drive > >> > >>2. automated probing of disk information (fdisk -p) > >> > >>3. Other tasks that are not suitably handled by curses-based utilities > >> > >>For example, the following command will create a second Windows > >>partition on a > >>thumb drive without user interaction: > >> > >>echo "p 2 0x0c * *" | fdisk -f - /dev/da0 > >> > >>If you take away fdisk, how am I supposed to achieve the above? > > > >/sbin/gpart add -t 12 -i 2 da0 > > > >(Untested, but that should work...) > > > >gpart is very scriptable, and still handles MBR and bsdlabel partitions > >if you need to work with removable media or volumes that will never be > >larger than 2 TB. "gpart list" and "gpart show" would get you all the > >machine-parsable stuff you'd ever need. > > > >The 2 TB limit is *the* reason to move from MBR+bsdlabel to GPT though. > >Even without RAID, 3 TB disks exist already. :) With FreeBSD's boot > >code, you don't even need an EFI-capable machine to boot from a > >GPT-partitioned device. For non-removable media, it's time to move on. > >Really. :) Even on smaller 250 GB disks, I'm using GPT just because > >there's no reason not to... it's just cleaner and it was easier to write > >gpart scripts than it was to script fdisk/bsdlabel scripts anyway. > > Please don't mix two things together. gpart can replace fdisk and > bsdlabel, but GPT vs. MBR is a different thing. GPT doesn't play > nice with GEOM classes which store their metadata on last sector. > For example, you can't use gmirror of a whole drives and use GPT on > top of this mirror. (and gmirror is not the only one) This is quite possibly the most concise, clearest definition of a major (borderline catastrophic) situation pertaining to GPT + GEOM combinations. I'm going to be more bold than usual: who is fixing this, and when is it going to be MFC'd to 9, 8, and probably 7 would be a good idea? If nobody is fixing this, someone had better light a fire under someone's ass to fix it. I'm absolutely amazed this is still a problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 00:41:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 655FA106564A; Fri, 17 Feb 2012 00:41:06 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9468FC14; Fri, 17 Feb 2012 00:41:05 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H0f2aF016187 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 16:41:04 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3DA27A.3090903@freebsd.org> Date: Thu, 16 Feb 2012 16:42:34 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> In-Reply-To: <4F3D89CD.9050309@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , David Xu Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 00:41:06 -0000 Adding David Xu for his thoughts since he reqrote the code in quesiton in revision 213098 On 2/16/12 2:57 PM, Julian Elischer wrote: > On 2/16/12 1:06 PM, Julian Elischer wrote: >> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>> on 15/02/2012 23:41 Julian Elischer said the following: >>>> The program fio (an IO test in ports) uses pthreads >>>> >>>> the following code (from fio-2.0.3, but its in earlier code too) >>>> has suddenly started misbehaving. >>>> >>>> clock_gettime(CLOCK_REALTIME,&t); >>>> t.tv_sec += seconds + 10; >>>> >>>> pthread_mutex_lock(&mutex->lock); >>>> >>>> while (!mutex->value&& !ret) { >>>> mutex->waiters++; >>>> ret = >>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>> mutex->waiters--; >>>> } >>>> >>>> if (!ret) { >>>> mutex->value--; >>>> pthread_mutex_unlock(&mutex->lock); >>>> } >>>> >>>> >>>> It turns out that 'ret' sometimes comes back instantly (on my >>>> machine) with a >>>> value of 60 (ETIMEDOUT) >>>> despite the fact that we set the timeout 10 seconds into the future. >>>> >>>> Has anyone else seen anything like this? >>>> (and yes the condition variable attribute have been set to use >>>> the REALTIME clock). >>> But why? >>> >>> Just a hypothesis that maybe there is some issue with time keeping >>> on that system. >>> How would that code work out for you with MONOTONIC? >> >> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, >> and they both had the same problem.. >> i.e. random early returns with ETIMEDOUT. >> >> I think we will try move out machine forward to a newer -stable to >> see if it resolves. > Kan upgraded the machine today to today's 9.x branch tip and the > problem still occurs. > 8.x does not have this problem. > > I have not got a 9-RELEASE machine to test on.. so I can not tell if > this came in with the burst of stuff > that came in after the 9.x branch was unfrozen after the release of > 9.0. > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 01:09:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E390106566B for ; Fri, 17 Feb 2012 01:09:57 +0000 (UTC) (envelope-from prvs=1394c8742a=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 E90D08FC08 for ; Fri, 17 Feb 2012 01:09:56 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 17 Feb 2012 00:59:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018103233.msg for ; Fri, 17 Feb 2012 00:59:23 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1394c8742a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: <64A97EF77EAB4FBBA20960732D59761D@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <1F7793659A864776BF0DD68DD3F68444@multiplay.co.uk> <20120216235252.GA59094@icarus.home.lan> Date: Fri, 17 Feb 2012 00:58:27 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org Subject: Re: ahci / ada hiding disk errors? 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, 17 Feb 2012 01:09:57 -0000 ----- Original Message ----- From: "Jeremy Chadwick" ... > The long test is still running, as I stated above. Also, just as a data > point: folks should remember to completely ignore the "remaining" > percentage shown -- it is hardly ever accurate, especially on Western > Digital drives. yep was aware of this just wanted to get it out there to see if anyone had any ideas, thanks for the feedback :) Long test compeleted a few hours latter and still not saying anny errors. SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 6661 - # 2 Short offline Completed without error 00% 6657 - Updated smart attributes:- SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 082 063 044 Pre-fail Always - 171321356 3 Spin_Up_Time 0x0003 094 094 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 17 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 074 060 030 Pre-fail Always - 29135041 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 6663 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 17 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 078 046 045 Old_age Always - 22 (Min/Max 21/23) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 12 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 17 194 Temperature_Celsius 0x0022 022 054 000 Old_age Always - 22 (0 14 0 0) 195 Hardware_ECC_Recovered 0x001a 118 099 000 Old_age Always - 171321356 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 > > I would appreciate if you could provide actual timestamps associated > with the above I/O errors from your logs. One of the kernel logs, > probably messages (or all.log if you enable it -- I HIGHLY recomment > folks do!) -- should have actual datestamps too. I'd like to see how > often these occur, or if all at once. The drive is currently totally inaccessible. Any io attempt to any area results in an error:- ad6: FAILURE - READ_DMA status=51 error=4 LBA="any lba" > Otherwise I see nothing wrong with your drive. As such, I'm inclined to > believe what you're seeing is probably a bug in the ata(4) driver. I don't think this is the case as the drive has been working fine for many months until a reboot today, after which nothing seems to be able to access the data, but sees the drive fine. > Also, just for amusement value: so far in the past 7 days, this is the > *TENTH* disk-related issue I have had to look at from people on the > Internet (not just FreeBSD either). I don't know what's going on, but > you people are practically requiring me to make this a full-time job. > Hell, maybe I should start doing "consulting" on these type of things, > haha. hehe ;-) Think our next move will to have the drive reseated and if that doesn't help moved to another machine to see if that helps. Seems very odd that smart see no sign of an issue yet nothing can be accessed. Any other ideas would be greatfully recieved. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 01:34:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8615106564A for ; Fri, 17 Feb 2012 01:34:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 82F268FC0A for ; Fri, 17 Feb 2012 01:34:56 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1H1YsYv048168; Thu, 16 Feb 2012 18:34:54 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1H1YrZp048165; Thu, 16 Feb 2012 18:34:53 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 16 Feb 2012 18:34:53 -0700 (MST) From: Warren Block To: Jeremy Chadwick In-Reply-To: <20120217001829.GA59869@icarus.home.lan> Message-ID: References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 16 Feb 2012 18:34:54 -0700 (MST) Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 01:34:56 -0000 On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > On Fri, Feb 17, 2012 at 01:08:28AM +0100, Miroslav Lachman wrote: >> >> Please don't mix two things together. gpart can replace fdisk and >> bsdlabel, but GPT vs. MBR is a different thing. GPT doesn't play >> nice with GEOM classes which store their metadata on last sector. >> For example, you can't use gmirror of a whole drives and use GPT on >> top of this mirror. (and gmirror is not the only one) > > This is quite possibly the most concise, clearest definition of a major > (borderline catastrophic) situation pertaining to GPT + GEOM > combinations. > > I'm going to be more bold than usual: who is fixing this, and when is it > going to be MFC'd to 9, 8, and probably 7 would be a good idea? If > nobody is fixing this, someone had better light a fire under someone's > ass to fix it. I'm absolutely amazed this is still a problem. How can it be fixed? GPT only has two points of reference, the start and end of the disk. To do more it would have to be aware of a lot of possible disk formats. On the other hand, GEOM stuff works inside GPT partitions. And if that's not acceptable, MBR partitions will be around for a long time. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 01:54:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE201065672; Fri, 17 Feb 2012 01:54:28 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9B26F8FC08; Fri, 17 Feb 2012 01:54:28 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H1sQtv016431 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 17:54:27 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3DB3AE.5000109@freebsd.org> Date: Thu, 16 Feb 2012 17:55:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> In-Reply-To: <4F3DA27A.3090903@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , David Xu Subject: Re: pthread_cond_timedwait() broken in 9-stable? [possible answer] 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, 17 Feb 2012 01:54:28 -0000 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 switching the machine from TSC_low to ACPI-fast fixes the problem. in 8.x it used to default to ACPI but I used to switch it to "TSC" to get better performance. I wonder why TSC-low is now bad to use.. maybe the TSCs are not as well sychronised as they were in 8.x? maybe the pthreads code didn't get the memo about changing timers? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 01:56:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2835D106567C; Fri, 17 Feb 2012 01:56:48 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EDC238FC12; Fri, 17 Feb 2012 01:56:47 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1H1ujN2056748; Fri, 17 Feb 2012 01:56:46 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3DB3DB.2060603@gmail.com> Date: Fri, 17 Feb 2012 09:56:43 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> In-Reply-To: <4F3DA27A.3090903@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , David Xu , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 01:56:48 -0000 On 2012/2/17 8:42, Julian Elischer wrote: > Adding David Xu for his thoughts since he reqrote the code in quesiton > in revision 213098 > > On 2/16/12 2:57 PM, Julian Elischer wrote: >> On 2/16/12 1:06 PM, Julian Elischer wrote: >>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>> The program fio (an IO test in ports) uses pthreads >>>>> >>>>> the following code (from fio-2.0.3, but its in earlier code too) >>>>> has suddenly started misbehaving. >>>>> >>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>> t.tv_sec += seconds + 10; >>>>> >>>>> pthread_mutex_lock(&mutex->lock); >>>>> >>>>> while (!mutex->value&& !ret) { >>>>> mutex->waiters++; >>>>> ret = >>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>> mutex->waiters--; >>>>> } >>>>> >>>>> if (!ret) { >>>>> mutex->value--; >>>>> pthread_mutex_unlock(&mutex->lock); >>>>> } >>>>> >>>>> >>>>> It turns out that 'ret' sometimes comes back instantly (on my >>>>> machine) with a >>>>> value of 60 (ETIMEDOUT) >>>>> despite the fact that we set the timeout 10 seconds into the future. >>>>> >>>>> Has anyone else seen anything like this? >>>>> (and yes the condition variable attribute have been set to use the >>>>> REALTIME clock). >>>> But why? >>>> >>>> Just a hypothesis that maybe there is some issue with time keeping >>>> on that system. >>>> How would that code work out for you with MONOTONIC? >>> >>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, >>> and they both had the same problem.. >>> i.e. random early returns with ETIMEDOUT. >>> >>> I think we will try move out machine forward to a newer -stable to >>> see if it resolves. >> Kan upgraded the machine today to today's 9.x branch tip and the >> problem still occurs. >> 8.x does not have this problem. >> >> I have not got a 9-RELEASE machine to test on.. so I can not tell if >> this came in with the burst of stuff >> that came in after the 9.x branch was unfrozen after the release of 9.0. >> >> > I am trying to reproduce the problem, do you have complete sample code to test ? Regards, David Xu From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:00:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2792B106566B; Fri, 17 Feb 2012 02:00:05 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 04C7E8FC15; Fri, 17 Feb 2012 02:00:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1H2020l056811; Fri, 17 Feb 2012 02:00:03 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3DB4A0.2080904@gmail.com> Date: Fri, 17 Feb 2012 10:00:00 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3AE.5000109@freebsd.org> In-Reply-To: <4F3DB3AE.5000109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , David Xu , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? [possible answer] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:00:05 -0000 On 2012/2/17 9:55, Julian Elischer wrote: > > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) > ACPI-fast(900) dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > > switching the machine from TSC_low to ACPI-fast fixes the problem. > > in 8.x it used to default to ACPI > but I used to switch it to "TSC" to get better performance. > > I wonder why TSC-low is now bad to use.. > maybe the TSCs are not as well sychronised as they were in 8.x? > maybe the pthreads code didn't get the memo about changing timers? > pthread code does not know timer setting, same as other code in kernel. ;-) From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:10:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B303B106564A for ; Fri, 17 Feb 2012 02:10:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 9234B8FC0C for ; Fri, 17 Feb 2012 02:10:21 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta14.emeryville.ca.mail.comcast.net with comcast id apTH1i00A1smiN4AEqAMy8; Fri, 17 Feb 2012 02:10:21 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id aqAK1i00G1t3BNj8gqALsP; Fri, 17 Feb 2012 02:10:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 75EFD102C1E; Thu, 16 Feb 2012 18:10:19 -0800 (PST) Date: Thu, 16 Feb 2012 18:10:19 -0800 From: Jeremy Chadwick To: Warren Block Message-ID: <20120217021019.GA61420@icarus.home.lan> References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 02:10:21 -0000 On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: > On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > >On Fri, Feb 17, 2012 at 01:08:28AM +0100, Miroslav Lachman wrote: > >> > >>Please don't mix two things together. gpart can replace fdisk and > >>bsdlabel, but GPT vs. MBR is a different thing. GPT doesn't play > >>nice with GEOM classes which store their metadata on last sector. > >>For example, you can't use gmirror of a whole drives and use GPT on > >>top of this mirror. (and gmirror is not the only one) > > > >This is quite possibly the most concise, clearest definition of a major > >(borderline catastrophic) situation pertaining to GPT + GEOM > >combinations. > > > >I'm going to be more bold than usual: who is fixing this, and when is it > >going to be MFC'd to 9, 8, and probably 7 would be a good idea? If > >nobody is fixing this, someone had better light a fire under someone's > >ass to fix it. I'm absolutely amazed this is still a problem. > > How can it be fixed? GPT only has two points of reference, the > start and end of the disk. To do more it would have to be aware of > a lot of possible disk formats. The GPT aspect of it cannot be fixed. The GEOM aspect of it should be fixed. The "let's store the metadata in the last sector" mentality is what needs to be addressed. There has to be a better way of doing this. I'm surprised that given the nature of these two bits (GPT vs. GEOM), that the GEOM layer cannot simply lie about the full capacity of the partition, or something to that effect. Consider this: Linux's md driver has the capability to do, in effect, the same thing GEOM classes (gmirror, etc.) do. They obviously must store metadata somewhere too. How did they do it? http://www.mjmwired.net/kernel/Documentation/md.txt http://linux.die.net/man/4/md http://linux.die.net/man/8/mdadm Quoting mdadm: >> The devicesize option will rarely be of use. It applies to version 1.1 >> and 1.2 metadata only (where the metadata is at the start of the device) >> and is only useful when the component device has changed size (typically >> become larger). The version 1 metadata records the amount of the device >> that can be used to store data, so if a device in a version 1.1 or 1.2 >> array becomes larger, the metadata will still be visible, but the extra >> space will not. In this case it might be useful to assemble the array >> with --update=devicesize. This will cause mdadm to determine the maximum >> usable amount of space on each device and update the relevant field in >> the metadata. Quoting md: >> The common format -- known as version 0.90 -- has a superblock that is >> 4K long and is written into a 64K aligned block that starts at least 64K >> and less than 128K from the end of the device (i.e. to get the address >> of the superblock round the size of the device down to a multiple of 64K >> and then subtract 64K). The available size of each device is the amount >> of space before the super block, so between 64K and 128K is lost when a >> device in incorporated into an MD array. This superblock stores >> multi-byte fields in a processor-dependent manner, so arrays cannot >> easily be moved between computers with different processors. >> >> The new format -- known as version 1 -- has a superblock that is >> normally 1K long, but can be longer. It is normally stored between 8K >> and 12K from the end of the device, on a 4K boundary, though variations >> can be stored at the start of the device (version 1.1) or 4K from the >> start of the device (version 1.2). This metadata format stores multibyte >> data in a processor-independent format and supports up to hundreds of >> component devices (version 0.90 only supports 28). So for version 0.90 of their metadata format, you lose drive capacity by about 64-128KBytes, given that the space is needed for metadata. For version 1.0, I'm not sure. For version 1.1 it looks like the metadata can be stored at the beginning. So overall, this sounds to me like the equivalent of if GEOM was to "lie" about the actual capacities of the devices when using classes that require use of metadata (gmirror, etc.). > On the other hand, GEOM stuff works inside GPT partitions. And if > that's not acceptable, MBR partitions will be around for a long > time. MBR partitions don't scale past 2TB. Arguing that use of MBR is an acceptable workaround is the equivalent to burying one's head in the sand. Let's try to accept the future, not feign ignorance. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:17:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38850106564A; Fri, 17 Feb 2012 02:17:37 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 00FF88FC0C; Fri, 17 Feb 2012 02:17:36 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H2HZGJ016535 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 18:17:36 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3DB91A.2090806@freebsd.org> Date: Thu, 16 Feb 2012 18:19:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: davidxu@freebsd.org References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> In-Reply-To: <4F3DB3DB.2060603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, David Xu , FreeBSD Stable , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 02:17:37 -0000 On 2/16/12 5:56 PM, David Xu wrote: > On 2012/2/17 8:42, Julian Elischer wrote: >> Adding David Xu for his thoughts since he reqrote the code in >> quesiton in revision 213098 >> >> On 2/16/12 2:57 PM, Julian Elischer wrote: >>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>> The program fio (an IO test in ports) uses pthreads >>>>>> >>>>>> the following code (from fio-2.0.3, but its in earlier code too) >>>>>> has suddenly started misbehaving. >>>>>> >>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>> t.tv_sec += seconds + 10; >>>>>> >>>>>> pthread_mutex_lock(&mutex->lock); >>>>>> >>>>>> while (!mutex->value&& !ret) { >>>>>> mutex->waiters++; >>>>>> ret = >>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>> mutex->waiters--; >>>>>> } >>>>>> >>>>>> if (!ret) { >>>>>> mutex->value--; >>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>> } >>>>>> >>>>>> >>>>>> It turns out that 'ret' sometimes comes back instantly (on my >>>>>> machine) with a >>>>>> value of 60 (ETIMEDOUT) >>>>>> despite the fact that we set the timeout 10 seconds into the >>>>>> future. >>>>>> >>>>>> Has anyone else seen anything like this? >>>>>> (and yes the condition variable attribute have been set to use >>>>>> the REALTIME clock). >>>>> But why? >>>>> >>>>> Just a hypothesis that maybe there is some issue with time >>>>> keeping on that system. >>>>> How would that code work out for you with MONOTONIC? >>>> >>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, >>>> and they both had the same problem.. >>>> i.e. random early returns with ETIMEDOUT. >>>> >>>> I think we will try move out machine forward to a newer -stable >>>> to see if it resolves. >>> Kan upgraded the machine today to today's 9.x branch tip and the >>> problem still occurs. >>> 8.x does not have this problem. >>> >>> I have not got a 9-RELEASE machine to test on.. so I can not tell >>> if this came in with the burst of stuff >>> that came in after the 9.x branch was unfrozen after the release >>> of 9.0. >>> >>> >> > I am trying to reproduce the problem, do you have complete sample > code to test ? I'm still looking the exact set but on my machine (4 cpus) the program from ports sysutils/fio exhibits the problem when used with kern.timecounter.hardware=TSC-low and with the following config file: pu05 # cat config.fio [global] #clocksource=cpu direct=1 rw=randread bs=4096 fill_device=1 numjobs=16 iodepth=16 #ioengine=posixaio #ioengine=psync ioengine=psync group_reporting norandommap time_based runtime=60000 randrepeat=0 [file1] filename=/dev/ada0 pu05 # pu05 # fio config.fio fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning. file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 ... file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 fio 2.0.3 Starting 15 threads and 1 process fio: job startup hung? exiting. fio: 5 jobs failed to start Segmentation fault (core dumped) pu05# The reason 5 jobs failed to start is because the parent timed out on them immediately. It didn't time out on 10 of them apparently. if I set the timer to ACPI-fast it works as expected.. > > Regards, > David Xu > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:38:32 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D97751065672 for ; Fri, 17 Feb 2012 02:38:32 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F78E8FC08 for ; Fri, 17 Feb 2012 02:38:32 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q1H2cQ23005805; Thu, 16 Feb 2012 21:38:26 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q1H2cQPs005803; Thu, 16 Feb 2012 21:38:26 -0500 (EST) (envelope-from wollman) Date: Thu, 16 Feb 2012 21:38:26 -0500 (EST) From: Garrett Wollman Message-Id: <201202170238.q1H2cQPs005803@hergotha.csail.mit.edu> To: freebsd@jdc.parodius.com In-Reply-To: <20120217021019.GA61420@icarus.home.lan> References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 16 Feb 2012 21:38:27 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: stable@freebsd.org Subject: Re: New BSD Installer 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, 17 Feb 2012 02:38:32 -0000 In article <20120217021019.GA61420@icarus.home.lan>, Jeremy Chadwick wrote: >So for version 0.90 of their metadata format, you lose drive capacity by >about 64-128KBytes, given that the space is needed for metadata. Which is exactly what geom_mirror does, amazingly enough. (Except, of course, that geom_mirror only needs one sector!) See the function mirror_label() in /usr/src/sbin/geom/class/mirror/geom_mirror.c. So if geom_mirror is not working with GPT, you should look elsewhere for the culprit. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:40:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0075106564A for ; Fri, 17 Feb 2012 02:40:39 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 70D978FC1B for ; Fri, 17 Feb 2012 02:40:39 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1H2eZR7048475; Thu, 16 Feb 2012 19:40:35 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1H2eZmQ048472; Thu, 16 Feb 2012 19:40:35 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 16 Feb 2012 19:40:35 -0700 (MST) From: Warren Block To: Jeremy Chadwick In-Reply-To: <20120217021019.GA61420@icarus.home.lan> Message-ID: References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 16 Feb 2012 19:40:36 -0700 (MST) Cc: freebsd-stable@freebsd.org, Mike Andrews , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 02:40:39 -0000 On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: (...Linux mdadm) > So for version 0.90 of their metadata format, you lose drive capacity by > about 64-128KBytes, given that the space is needed for metadata. For > version 1.0, I'm not sure. For version 1.1 it looks like the metadata > can be stored at the beginning. > > So overall, this sounds to me like the equivalent of if GEOM was to > "lie" about the actual capacities of the devices when using classes that > require use of metadata (gmirror, etc.). Sorry, I may be misunderstanding your point. GEOM classes don't lie, they accurately represent the space. The space provided by a gmirror is one block less than the actual space occupied, to allow for the metadata block at the end. The problem is that GPT puts backup partition tables at the end of the physical (not logical) device. Create a GEOM device on that drive, and the GEOM metadata overwrites the backup GPT partition table. Well, the last block of it, anyway. But create the GEOM device inside a GPT partition that spans the drive, and things are fine. The GPT backup tables are safely outside the GEOM metadata, which is safely outside of the data. Short-form: GPT tables are at the absolute start and end of the physical disk. GEOM metadata is relative, at the end of the logical device, not necessarily the end of the physical device. >> On the other hand, GEOM stuff works inside GPT partitions. And if >> that's not acceptable, MBR partitions will be around for a long >> time. > > MBR partitions don't scale past 2TB. Arguing that use of MBR is an > acceptable workaround is the equivalent to burying one's head in the > sand. Let's try to accept the future, not feign ignorance. I wasn't recommending it. If putting GEOM data inside GPT partitions isn't acceptable (but why not?), there's the alternative of not using any partitioning at all. Create the GEOM device on the bare drive using the full space. Of course it won't boot... From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:42:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C09241065673; Fri, 17 Feb 2012 02:42:29 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A97D28FC12; Fri, 17 Feb 2012 02:42:29 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1H2gQDm002878; Fri, 17 Feb 2012 02:42:27 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3DBE90.5030305@gmail.com> Date: Fri, 17 Feb 2012 10:42:24 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> In-Reply-To: <4F3DB91A.2090806@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, FreeBSD Stable , davidxu@freebsd.org, Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:42:29 -0000 On 2012/2/17 10:19, Julian Elischer wrote: > On 2/16/12 5:56 PM, David Xu wrote: >> On 2012/2/17 8:42, Julian Elischer wrote: >>> Adding David Xu for his thoughts since he reqrote the code in >>> quesiton in revision 213098 >>> >>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>> >>>>>>> the following code (from fio-2.0.3, but its in earlier code too) >>>>>>> has suddenly started misbehaving. >>>>>>> >>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>> t.tv_sec += seconds + 10; >>>>>>> >>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>> >>>>>>> while (!mutex->value&& !ret) { >>>>>>> mutex->waiters++; >>>>>>> ret = >>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>> mutex->waiters--; >>>>>>> } >>>>>>> >>>>>>> if (!ret) { >>>>>>> mutex->value--; >>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> It turns out that 'ret' sometimes comes back instantly (on my >>>>>>> machine) with a >>>>>>> value of 60 (ETIMEDOUT) >>>>>>> despite the fact that we set the timeout 10 seconds into the >>>>>>> future. >>>>>>> >>>>>>> Has anyone else seen anything like this? >>>>>>> (and yes the condition variable attribute have been set to use >>>>>>> the REALTIME clock). >>>>>> But why? >>>>>> >>>>>> Just a hypothesis that maybe there is some issue with time >>>>>> keeping on that system. >>>>>> How would that code work out for you with MONOTONIC? >>>>> >>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, >>>>> and they both had the same problem.. >>>>> i.e. random early returns with ETIMEDOUT. >>>>> >>>>> I think we will try move out machine forward to a newer -stable to >>>>> see if it resolves. >>>> Kan upgraded the machine today to today's 9.x branch tip and the >>>> problem still occurs. >>>> 8.x does not have this problem. >>>> >>>> I have not got a 9-RELEASE machine to test on.. so I can not tell >>>> if this came in with the burst of stuff >>>> that came in after the 9.x branch was unfrozen after the release of >>>> 9.0. >>>> >>>> >>> >> I am trying to reproduce the problem, do you have complete sample >> code to test ? > > I'm still looking the exact set > but on my machine (4 cpus) the program from ports sysutils/fio > exhibits the problem when used with > kern.timecounter.hardware=TSC-low and with the following config file: > > pu05 # cat config.fio > > [global] > #clocksource=cpu > direct=1 > rw=randread > bs=4096 > fill_device=1 > numjobs=16 > iodepth=16 > #ioengine=posixaio > #ioengine=psync > ioengine=psync > group_reporting > norandommap > time_based > runtime=60000 > randrepeat=0 > > [file1] > filename=/dev/ada0 > > pu05 # > pu05 # fio config.fio > fio: this platform does not support process shared mutexes, forcing > use of threads. Use the 'thread' option to get rid of this warning. > file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 > ... > file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 > fio 2.0.3 > Starting 15 threads and 1 process > fio: job startup hung? exiting. > fio: 5 jobs failed to start > Segmentation fault (core dumped) > pu05# > > > The reason 5 jobs failed to start is because the parent timed out on > them immediately. > It didn't time out on 10 of them apparently. > > > if I set the timer to ACPI-fast it works as expected.. maybe following code can check to see if TSC-LOW works by let the thread run on each cpu. gettimeofday(&prev, NULL); int cpu = 0; for (;;) { cpuset_t set; cpu = ++cpu % 4; CPU_ZERO(&set); CPU_SET(cpu, &set); pthread_setaffinity_np(pthread_self(), sizeof(set), &set); gettimeofday(&cur, NULL); if ( timercmp(&prev, &cur, >=)) { abort(); } } From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 02:44:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 713B11065673; Fri, 17 Feb 2012 02:44:59 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4488FC15; Fri, 17 Feb 2012 02:44:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1H2iu4L002945; Fri, 17 Feb 2012 02:44:56 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3DBF26.2000306@gmail.com> Date: Fri, 17 Feb 2012 10:44:54 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: davidxu@freebsd.org References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> <4F3DBE90.5030305@gmail.com> In-Reply-To: <4F3DBE90.5030305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@freebsd.org, Julian Elischer , FreeBSD Stable , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 02:44:59 -0000 On 2012/2/17 10:42, David Xu wrote: > aybe following code can check to see if TSC-LOW works by let the > thread run > on each cpu. > > refresh: gettimeofday(&prev, NULL); int cpu = 0; for (;;) { cpuset_t set; cpu = ++cpu % 4; CPU_ZERO(&set); CPU_SET(cpu, &set); pthread_setaffinity_np(pthread_self(), sizeof(set), &set); gettimeofday(&cur, NULL); if ( timercmp(&prev, &cur, >)) { abort(); } prev = cur; } From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 03:08:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A9D106566C for ; Fri, 17 Feb 2012 03:08:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id DBBFA8FC08 for ; Fri, 17 Feb 2012 03:08:08 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id ar1e1i0051ZXKqc57r89Ph; Fri, 17 Feb 2012 03:08:09 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta21.westchester.pa.mail.comcast.net with comcast id ar871i01p1t3BNj3hr88cq; Fri, 17 Feb 2012 03:08:09 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7708D102C1E; Thu, 16 Feb 2012 19:08:06 -0800 (PST) Date: Thu, 16 Feb 2012 19:08:06 -0800 From: Jeremy Chadwick To: Warren Block Message-ID: <20120217030806.GA62601@icarus.home.lan> References: <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 03:08:09 -0000 On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: > On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > > >On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: > > (...Linux mdadm) > >So for version 0.90 of their metadata format, you lose drive capacity by > >about 64-128KBytes, given that the space is needed for metadata. For > >version 1.0, I'm not sure. For version 1.1 it looks like the metadata > >can be stored at the beginning. > > > >So overall, this sounds to me like the equivalent of if GEOM was to > >"lie" about the actual capacities of the devices when using classes that > >require use of metadata (gmirror, etc.). > > Sorry, I may be misunderstanding your point. GEOM classes don't > lie, they accurately represent the space. The space provided by a > gmirror is one block less than the actual space occupied, to allow > for the metadata block at the end. The problem is that GPT puts > backup partition tables at the end of the physical (not logical) > device. Create a GEOM device on that drive, and the GEOM metadata > overwrites the backup GPT partition table. Well, the last block of > it, anyway. > > But create the GEOM device inside a GPT partition that spans the > drive, and things are fine. The GPT backup tables are safely > outside the GEOM metadata, which is safely outside of the data. I wasn't aware you could do that. I was only aware that it was the other way around. That (my) misconception seems to also be relayed by others such as Miroslav who said: >>GPT doesn't play nice with GEOM classes which store their metadata >>on last sector. For example, you can't use gmirror of a whole drives >>and use GPT on top of this mirror. (and gmirror is not the only one) So if I read this correctly, it means that the erroneous behaviour is the result of someone doing things "in the wrong order" (for lack of better terminology). However, with the methodology you describe (GEOM device inside a GPT partition), are our bootloader bits (BTX, etc.) smart enough to figure this out and thus be able to boot/load kernel/so forth from such a device? (Note that this question is different from your later mention of creating the GEOM device on the bare drive with no partitioning, in which case yep, won't be bootable). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 03:45:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450C5106566C for ; Fri, 17 Feb 2012 03:45:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CABD78FC08 for ; Fri, 17 Feb 2012 03:45:57 +0000 (UTC) Received: by werm13 with SMTP id m13so2522711wer.13 for ; Thu, 16 Feb 2012 19:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jNmMGcRQcz1xctoOs6RRoI0o8xbjfUyCXl6zPx7SkPA=; b=cFJ+VzZoo33zI42M+KN68P7VrDtSxHSIVbo6MGEgVWhOT/Hkp5oGd0qRpZHJcSjrGK jnSAP/TiL0WdnE1ygchLiHt9vItGjLJiIKRiZmOMZVbS8EGJPoVB9ces4w/MqtzUoyz/ Wjc45wBX2rM6NcN/N/pIBUuA44uSCa3YizSqI= MIME-Version: 1.0 Received: by 10.216.139.21 with SMTP id b21mr2503843wej.9.1329450356961; Thu, 16 Feb 2012 19:45:56 -0800 (PST) Received: by 10.223.62.70 with HTTP; Thu, 16 Feb 2012 19:45:56 -0800 (PST) In-Reply-To: <20120217021019.GA61420@icarus.home.lan> References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> Date: Thu, 16 Feb 2012 21:45:56 -0600 Message-ID: From: Adam Vande More To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Warren Block , freebsd-stable@freebsd.org, Mike Andrews , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 03:45:58 -0000 On Thu, Feb 16, 2012 at 8:10 PM, Jeremy Chadwick wrote: > I'm surprised that given the nature of these two bits (GPT vs. GEOM), > that the GEOM layer cannot simply lie about the full capacity of the > partition, or something to that effect. > GEOM can already do this. gvirstor and gnop do something like this, and gnop may be of particular use. You could gmirror some drives, gnop it to a slightly smaller provider, then GPT the resulting device. At least that's how it could work in my understanding, I haven't actually attempted it. -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 04:23:32 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D2C710656EE for ; Fri, 17 Feb 2012 04:23:32 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD65A8FC14 for ; Fri, 17 Feb 2012 04:23:30 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H4LktH099723; Fri, 17 Feb 2012 13:21:57 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H4LfZs034408; Fri, 17 Feb 2012 13:21:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Feb 2012 13:20:21 +0900 (JST) Message-Id: <20120217.132021.880997830536801810.hrs@allbsd.org> To: freebsd@jdc.parodius.com From: Hiroki Sato In-Reply-To: <20120217030806.GA62601@icarus.home.lan> References: <20120217021019.GA61420@icarus.home.lan> <20120217030806.GA62601@icarus.home.lan> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_17_13_20_21_2012_576)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Feb 2012 13:22:01 +0900 (JST) X-Spam-Status: No, score=-103.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_VERTICALLINE, QENCPTR1, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: wblock@wonkity.com, freebsd-stable@FreeBSD.org, mandrews@bit0.com, 000.fbsd@quip.cz Subject: Re: New BSD Installer 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, 17 Feb 2012 04:23:32 -0000 ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeremy Chadwick wrote in <20120217030806.GA62601@icarus.home.lan>: fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: fr> > Sorry, I may be misunderstanding your point. GEOM classes don't fr> > lie, they accurately represent the space. The space provided by a fr> > gmirror is one block less than the actual space occupied, to allow fr> > for the metadata block at the end. The problem is that GPT puts fr> > backup partition tables at the end of the physical (not logical) fr> > device. Create a GEOM device on that drive, and the GEOM metadata fr> > overwrites the backup GPT partition table. Well, the last block of fr> > it, anyway. fr> > fr> > But create the GEOM device inside a GPT partition that spans the fr> > drive, and things are fine. The GPT backup tables are safely fr> > outside the GEOM metadata, which is safely outside of the data. fr> fr> I wasn't aware you could do that. I was only aware that it was the fr> other way around. That (my) misconception seems to also be relayed fr> by others such as Miroslav who said: fr> fr> >>GPT doesn't play nice with GEOM classes which store their metadata fr> >>on last sector. For example, you can't use gmirror of a whole drives fr> >>and use GPT on top of this mirror. (and gmirror is not the only one) fr> fr> So if I read this correctly, it means that the erroneous behaviour is fr> the result of someone doing things "in the wrong order" (for lack of fr> better terminology). Well, does GPT really depend on the absolute last block? The header has fields for both the first and the last LBAs and they do not have to be matched with the physical capacity. Creating a gmirror first, and then creating a GPT on it does not work? I do not think it is true, and I suspect a description on gmirror recommending kern.geom.debugflags=17 in the handbook is the source of the problem. The partition layout in my mind is the following: (0) (last) |PMBR|GPT primary| .... |GPT secondary|gmirror meta| |<------------------------------------------------->| ada0 |<------------------------------------>| | mirror/gm0 | |<----->| | mirror/gm0p{1,2,...} and the following commands will create an example of this configuration: # mdconfig -a -t vnode -s100m md0 # mdconfig -a -t vnode -s100m md1 # gmirror label gm0 /dev/md0 /dev/md1 # gmirror dump /dev/md0 | grep size mediasize: 104857088 sectorsize: 512 provsize: 104857600 # gpart create -s gpt mirror/gm0 # gpart add -t freebsd-ufs mirror/gm0 mirror/gm0p1 added => 34 204732 mirror/gm0 GPT (100M) 34 204732 1 freebsd-ufs (100M) # echo "(34 + 204732) * 512" | bc 104840192 The size of GPT header + partition entries is 33 sectors. So, # echo "(34 + 204732) * 512 + 33 * 512" | bc 104857088 is the size which the GPT recognizes. This matches the size of mirror/gm0, not /dev/md0. This means the gmirror metadata is located just after it. I think this should work in most cases for mirroring the whole disk. Certainly the gpart reports "[CORRUPT]" if the underlying device capacity does not match with the GPT header. For example, deactivating mirror/gm0 above will show the following: # gpart show => 34 204732 mirror/gm0 GPT (100M) 34 204732 1 freebsd-ufs (100M) # gmirror stop gm0 # gpart show => 34 204732 md1 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) => 34 204732 md0 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) # gpart recover md0 md0 recovered # gpart show => 34 204732 md1 GPT (100M) [CORRUPT] 34 204732 1 freebsd-ufs (100M) => 34 204733 md0 GPT (100M) 34 204732 1 freebsd-ufs (100M) 204766 1 - free - (512B) We can see the gpart recover extends the size to the last sector where gmirror metadata was placed and clears the "[CORRUPT]" status as expected. So, some early boot stages which do not recognize mirror/gm0 see the corrupted GPT. However, I think they will simply follow the information in the GPT header. -- Hiroki ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk891YUACgkQTyzT2CeTzy2TWgCfSaDckdcDPNR/+R0nJWA1Eu5r gtoAoNOw0gLhPM/eFwOCiABY7v88ZvmH =TDXP -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_17_13_20_21_2012_576)---- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 04:55:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D86106564A for ; Fri, 17 Feb 2012 04:55:46 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id C84318FC0A for ; Fri, 17 Feb 2012 04:55:45 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1H4tc9G049157; Thu, 16 Feb 2012 21:55:38 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1H4tco9049154; Thu, 16 Feb 2012 21:55:38 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 16 Feb 2012 21:55:38 -0700 (MST) From: Warren Block To: Jeremy Chadwick In-Reply-To: <20120217030806.GA62601@icarus.home.lan> Message-ID: References: <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> <20120217030806.GA62601@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 16 Feb 2012 21:55:38 -0700 (MST) Cc: freebsd-stable@freebsd.org, Mike Andrews , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: New BSD Installer 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, 17 Feb 2012 04:55:46 -0000 On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: >> On Thu, 16 Feb 2012, Jeremy Chadwick wrote: >> >>> On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: >> >> (...Linux mdadm) >>> So for version 0.90 of their metadata format, you lose drive capacity by >>> about 64-128KBytes, given that the space is needed for metadata. For >>> version 1.0, I'm not sure. For version 1.1 it looks like the metadata >>> can be stored at the beginning. >>> >>> So overall, this sounds to me like the equivalent of if GEOM was to >>> "lie" about the actual capacities of the devices when using classes that >>> require use of metadata (gmirror, etc.). >> >> Sorry, I may be misunderstanding your point. GEOM classes don't >> lie, they accurately represent the space. The space provided by a >> gmirror is one block less than the actual space occupied, to allow >> for the metadata block at the end. The problem is that GPT puts >> backup partition tables at the end of the physical (not logical) >> device. Create a GEOM device on that drive, and the GEOM metadata >> overwrites the backup GPT partition table. Well, the last block of >> it, anyway. >> >> But create the GEOM device inside a GPT partition that spans the >> drive, and things are fine. The GPT backup tables are safely >> outside the GEOM metadata, which is safely outside of the data. > > I wasn't aware you could do that. I was only aware that it was the > other way around. That (my) misconception seems to also be relayed > by others such as Miroslav who said: > >>> GPT doesn't play nice with GEOM classes which store their metadata >>> on last sector. For example, you can't use gmirror of a whole drives >>> and use GPT on top of this mirror. (and gmirror is not the only one) > > So if I read this correctly, it means that the erroneous behaviour is > the result of someone doing things "in the wrong order" (for lack of > better terminology). Yes, or the misconception that GPT behaves the same way as GEOM classes. (Which isn't helped by both "GPT" and "gpart" coincidentally starting with a "g".) > However, with the methodology you describe (GEOM device inside a GPT > partition), are our bootloader bits (BTX, etc.) smart enough to figure > this out and thus be able to boot/load kernel/so forth from such a > device? gptboot does not see the mirror, but will boot from one of the mirrored drives. Since the drives are identical, that works. A smart boot loader that could handle other GEOM classes is possible. One disadvantage is that identical partitions have to be created manually on both drives and then mirrored rather than creating a mirror and creating a single set of partitions on it. ae@ has an article on GPT and gmirror: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=auto&tl=en&u=http%3A%2F%2Fbu7cher.blogspot.com%2F2011%2F03%2Ffreebsd-gmirror-gpt-ufs.html&act=url And so do I: http://www.wonkity.com/~wblock/docs/html/gmirror.html From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 05:37:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFFC6106566C for ; Fri, 17 Feb 2012 05:37:49 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7307E8FC19 for ; Fri, 17 Feb 2012 05:37:48 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2984025vcm.13 for ; Thu, 16 Feb 2012 21:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MNYoQm3/54jJEYMTTH2r+WFbsYnlfydDou0SYYkN3Ds=; b=Y834JBLoCkuuBs96F2pWEueRvcbUNiPK6mLNr/XjZYL1zp6soWFhqFF299EniNym8Q G/F3lOHNVceg4OFAyzfiW7fxsMvE0ixqt2XUHqk8yBwMAlOEw1Im8UK/4ysIHjjLpKRg K1g9uUMlGGwk7kqr0hvUoMQwmTGiE78+4YlbA= MIME-Version: 1.0 Received: by 10.52.27.70 with SMTP id r6mr2524459vdg.41.1329457068419; Thu, 16 Feb 2012 21:37:48 -0800 (PST) Received: by 10.220.192.135 with HTTP; Thu, 16 Feb 2012 21:37:48 -0800 (PST) In-Reply-To: References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> Date: Thu, 16 Feb 2012 21:37:48 -0800 Message-ID: From: Freddie Cash To: Warren Block Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Andrews , freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick Subject: Re: New BSD Installer 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, 17 Feb 2012 05:37:49 -0000 On Thu, Feb 16, 2012 at 6:40 PM, Warren Block wrote: > On Thu, 16 Feb 2012, Jeremy Chadwick wrote: > >> On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote: > > > (...Linux mdadm) > >> So for version 0.90 of their metadata format, you lose drive capacity by >> about 64-128KBytes, given that the space is needed for metadata. =C2=A0F= or >> version 1.0, I'm not sure. =C2=A0For version 1.1 it looks like the metad= ata >> can be stored at the beginning. >> >> So overall, this sounds to me like the equivalent of if GEOM was to >> "lie" about the actual capacities of the devices when using classes that >> require use of metadata (gmirror, etc.). > > Sorry, I may be misunderstanding your point. =C2=A0GEOM classes don't lie= , they > accurately represent the space. =C2=A0The space provided by a gmirror is = one > block less than the actual space occupied, to allow for the metadata bloc= k > at the end. =C2=A0The problem is that GPT puts backup partition tables at= the end > of the physical (not logical) device. Create a GEOM device on that drive, > and the GEOM metadata overwrites the backup GPT partition table. =C2=A0We= ll, the > last block of it, anyway. > > But create the GEOM device inside a GPT partition that spans the drive, a= nd > things are fine. =C2=A0The GPT backup tables are safely outside the GEOM > metadata, which is safely outside of the data. > > Short-form: GPT tables are at the absolute start and end of the physical > disk. =C2=A0GEOM metadata is relative, at the end of the logical device, = not > necessarily the end of the physical device. Seems to me that we need a GEOM-aware loader that can "taste" the GEOM metadata on a disk *before* the GPT is read, such that the "first and last physical block of the disk" becomes "the first and last physical block of the GEOM provider". Perhaps by storing the GEOM class metadata in the first and last blocks of the provider. Then you just start reading the start of the disk, notice a gmirror metadata block, setup the gmirror, notice a gstripe metadata block, setup the gstripe, notice a GPT metadata block, load the GPT partitions, etc No idea just how feasible this would be, though. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 05:46:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13B9B106564A for ; Fri, 17 Feb 2012 05:46:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2F538FC16 for ; Fri, 17 Feb 2012 05:46:05 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so2961052vbb.13 for ; Thu, 16 Feb 2012 21:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YgWROjUNcXR0Dv/Xjb8sOWlOyOw65PbmHyrrRSoFKeM=; b=wuT48vSOoiZ583yN99zxqqVb/IVNFA1rEAMi5OjU3XamETMi95QHZlWNyzI5lYoqzz XDvGOmppGOoZ+xTt4KSzNxxfau/lXKo3ZRmCqd38IibSK0QNxIQQulKlSEmh/BpCctmO kYnnJ0xJ21J+bFAnWIIRjly7jXWYvvYUMjIA0= MIME-Version: 1.0 Received: by 10.52.38.10 with SMTP id c10mr2524749vdk.58.1329457564792; Thu, 16 Feb 2012 21:46:04 -0800 (PST) Received: by 10.220.192.135 with HTTP; Thu, 16 Feb 2012 21:46:04 -0800 (PST) In-Reply-To: <20120217.132021.880997830536801810.hrs@allbsd.org> References: <20120217021019.GA61420@icarus.home.lan> <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> Date: Thu, 16 Feb 2012 21:46:04 -0800 Message-ID: From: Freddie Cash To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 05:46:06 -0000 On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato wrote: > Jeremy Chadwick wrote > =C2=A0in <20120217030806.GA62601@icarus.home.lan>: > > fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: > fr> > Sorry, I may be misunderstanding your point. =C2=A0GEOM classes don= 't > fr> > lie, they accurately represent the space. =C2=A0The space provided = by a > fr> > gmirror is one block less than the actual space occupied, to allow > fr> > for the metadata block at the end. =C2=A0The problem is that GPT pu= ts > fr> > backup partition tables at the end of the physical (not logical) > fr> > device. Create a GEOM device on that drive, and the GEOM metadata > fr> > overwrites the backup GPT partition table. =C2=A0Well, the last blo= ck of > fr> > it, anyway. > fr> > > fr> > But create the GEOM device inside a GPT partition that spans the > fr> > drive, and things are fine. =C2=A0The GPT backup tables are safely > fr> > outside the GEOM metadata, which is safely outside of the data. > fr> > fr> I wasn't aware you could do that. =C2=A0I was only aware that it was = the > fr> other way around. =C2=A0That (my) misconception seems to also be rela= yed > fr> by others such as Miroslav who said: > fr> > fr> >>GPT doesn't play nice with GEOM classes which store their metadata > fr> >>on last sector. =C2=A0For example, you can't use gmirror of a whole= drives > fr> >>and use GPT on top of this mirror. (and gmirror is not the only one= ) > fr> > fr> So if I read this correctly, it means that the erroneous behaviour is > fr> the result of someone doing things "in the wrong order" (for lack of > fr> better terminology). > > =C2=A0Well, does GPT really depend on the absolute last block? =C2=A0The = header > =C2=A0has fields for both the first and the last LBAs and they do not hav= e > =C2=A0to be matched with the physical capacity. =C2=A0Creating a gmirror = first, > =C2=A0and then creating a GPT on it does not work? =C2=A0I do not think i= t is > =C2=A0true, and I suspect a description on gmirror recommending > =C2=A0kern.geom.debugflags=3D17 in the handbook is the source of the prob= lem. It's not the partitioning that's the issue. It's the order that GEOM providers and GPT partition tables are "tasted". You can gmirror two disks, then GPT partition the gm0 device without any issues. As you noted, the first/last sectors are 1 less than the physical disk (the size of the gmirror provider). When you boot, though, the gptboot loader only sees the GPT table, it doesn't know that it's part of a gmirror setup. Thus it loads the GPT, notices that the size of the GPT is 1 less sector than the size of the disk, can't find the secondary GPT table as the last sector of the disk is gmirror metadata, and complains about corrupted GPT. Then the kernel loads, gmirror "tastes" the disk, finds the gmirror metadata, configures the gmirror provider, and now all the GPT stuff matches again. And the system carries on correctly. The issue is that we don't have a GEOM-aware loader. Or, at least, that the gpt*boot loaders read the GPT table(s) before configuring the GEOM providers. If we had a gloader that understood all the different GEOM classes, this would be a non-issue. At least, from my limited understanding of things. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 06:37:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA764106566C for ; Fri, 17 Feb 2012 06:37:38 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3173E8FC0A for ; Fri, 17 Feb 2012 06:37:37 +0000 (UTC) Received: from nschwcmgw07p ([61.9.190.167]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20120217063736.YHQD11739.nschwmtas03p.mx.bigpond.com@nschwcmgw07p>; Fri, 17 Feb 2012 06:37:36 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.112.105]) by nschwcmgw07p with BigPond Outbound id audb1i0062GVmci01udbK4; Fri, 17 Feb 2012 06:37:36 +0000 X-Authority-Analysis: v=2.0 cv=OurNOlDt c=1 sm=1 a=0GO/22z+lHYfckWJ4naYnw==:17 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=1mHPyEShj_kq8wcnPlEA:9 a=13oSXlDQSYVwkr55YuMA:7 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=0GO/22z+lHYfckWJ4naYnw==:117 Received: from white (white.hs [10.0.5.2]) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id q1H6bEbY064685 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Feb 2012 17:37:15 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'Bruce Cran'" References: <4F355A5B.9080007@rewt.org.uk> <4F35743B.4020302@os2.kiev.ua><4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> Date: Fri, 17 Feb 2012 17:37:14 +1100 Message-ID: <61AB04813A1041FD8B8E925AADD46D10@white> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20120213195554.O46120@sola.nimnet.asn.au> Thread-Index: AczrPGdEEOwASNj6Qr+hIeQDTxIzwwB/zLUA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: 'FreeBSD Stable Mailing List' Subject: RE: New BSD Installer 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, 17 Feb 2012 06:37:38 -0000 To answer an earlier question by Bruce... > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Ian Smith > Sent: Wednesday, 15 February 2012 4:15 AM > To: Bruce Cran > Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov > Subject: Re: New BSD Installer > > On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote: > > On 2/10/2012 7:47 PM, Alex Samorukov wrote: > > > I am highly against reverting. Old installer is not GPT > aware and in fact > > is unmaintained for a very long time. > > > > That's not really correct: quite a lot of work was done on > it last year. > > Indeed. Was it you working on the updated sade(8) adding GPT and ZFS? > > > > I don't see it in terms of reverting. Much other useful > functionality of sysinstall has yet to be reimplemented. > Sure, I know, send code .. > but it's not only the functionality lost, but the ability for > new users to accomplish a good deal of initial server setup > before they're skilled enough to do it all from the command > line, which is where I was in '98. > > I also think much of the sometimes gratuitous deprecation of > sysinstall is unwarranted. I've used sysinstall > post-installation regularly since > '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2. > Since one small disaster on 3.3 about 12 years ago > (installing to the wrong slice) I've had no major issues with > it, mostly partitioning all sorts of disks but also browsing > and adding useful packages at installation. > > Strangely, the big push to GPT partitions was oft said to be > because MBR slices provided too few partitions. I never > found 4 * 6 much of a limit myself, and now the default > install makes a Linux-like single partition, rendering dump & > restore more or less unusable or at least impractical, while > booting multiple systems on GPT also seems to require Linux tools. > > I don't know whether this move away from BSD traditional > filesystem partitioning (/, /var, /usr etc) to Linux-style > came down from Core On High or is just the prerogative of > installer-writers? Jordan was both the latter and a big part > of the former for many years, but I guess that's something > that can be reverted if people feel to do so. > > I expect most developers run mostly the latest gear, and > nowadays tend to use vbox images a good deal, but there will > be many laptops and other systems using MBR slices and > bsdlabel partitions for years to come, and I'd hate to see > FreeBSD's longterm support for _slightly_ older hardware > disappear, just because of having added better support for latest kit. > > I for one will be screwed if sade, fdisk and bsdlabel > disappear, as the release notes for 9 seem to indicate may be > imminently on the cards. > > > > cheers, Ian > _______________________________________________ > 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" I've included the gpart commands that should allay your concerns about fdisk and bsdlabel. Like you I use MBR for exactly the reasons that Freddie has articulated, and share Jeremy's concerns. GPT doesn't yet suit my operations model for bootable media; so The following will prepare the partitions/slices for a conventional device, for example a small usb drive D=da1 SIZE=1G gpart create -s MBR $D gpart add -b63 -s $SIZE -t freebsd $D # to insert s1 gpart create -s bsd ${D}s1 # create s1 as BSD gpart add -s 300M -t freebsd-ufs ${D}s1 # create partition s1a gpart add -s 16M -t freebsd-swap ${D}s1 # create swap gpart add -t freebsd-ufs ${D}s1 # rest to s1d gpart add -s $SIZE -t freebsd $D # to insert s2 gpart create -s bsd ${D}s2 # create s2 gpart add -s 256M -t freebsd-ufs ${D}s2 # should be s2a gpart add -s 16M -t freebsd-ufs ${D}s2 # should be s2d gpart add -s 32M -t freebsd-ufs ${D}s2 # should be s2e gpart add -s 48M -t freebsd-ufs ${D}s2 # should be s2f gpart add -s 64M -t freebsd-ufs ${D}s2 # should be s2e gpart add -t freebsd-ufs ${D}s2 # should be s2h gpart bootcode -b /boot/boot0 ${D} gpart bootcode -b /boot/boot ${D}s1 gpart set -a active -i 1 ${D} # This is redundent, but emphasises the point :) I like the convenience of this approach as it eliminates the fiddly fdisk and bsdlabel work. Enjoy. Regards, Dewayne. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 07:07:05 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 647FC1065674 for ; Fri, 17 Feb 2012 07:07:05 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id C6F278FC12 for ; Fri, 17 Feb 2012 07:07:04 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H75D7K037408; Fri, 17 Feb 2012 16:05:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1H75AJP035952; Fri, 17 Feb 2012 16:05:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Feb 2012 16:04:30 +0900 (JST) Message-Id: <20120217.160430.406937514120319292.hrs@allbsd.org> To: fjwcash@gmail.com From: Hiroki Sato In-Reply-To: References: <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Feb_17_16_04_30_2012_094)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Feb 2012 16:05:29 +0900 (JST) X-Spam-Status: No, score=-104.0 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, MIMEQENC, QENCPTR1, QENCPTR2, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@FreeBSD.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 07:07:05 -0000 ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)-- Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Freddie Cash wrote in : fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato wrot= e: fj> > Jeremy Chadwick wrote fj> > =A0in <20120217030806.GA62601@icarus.home.lan>: fj> > fj> > fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:= fj> > fr> > Sorry, I may be misunderstanding your point. =A0GEOM classe= s don't fj> > fr> > lie, they accurately represent the space. =A0The space prov= ided by a fj> > fr> > gmirror is one block less than the actual space occupied, t= o allow fj> > fr> > for the metadata block at the end. =A0The problem is that G= PT puts fj> > fr> > backup partition tables at the end of the physical (not log= ical) fj> > fr> > device. Create a GEOM device on that drive, and the GEOM me= tadata fj> > fr> > overwrites the backup GPT partition table. =A0Well, the las= t block of fj> > fr> > it, anyway. fj> > fr> > fj> > fr> > But create the GEOM device inside a GPT partition that span= s the fj> > fr> > drive, and things are fine. =A0The GPT backup tables are sa= fely fj> > fr> > outside the GEOM metadata, which is safely outside of the d= ata. fj> > fr> fj> > fr> I wasn't aware you could do that. =A0I was only aware that it= was the fj> > fr> other way around. =A0That (my) misconception seems to also be= relayed fj> > fr> by others such as Miroslav who said: fj> > fr> fj> > fr> >>GPT doesn't play nice with GEOM classes which store their m= etadata fj> > fr> >>on last sector. =A0For example, you can't use gmirror of a = whole drives fj> > fr> >>and use GPT on top of this mirror. (and gmirror is not the = only one) fj> > fr> fj> > fr> So if I read this correctly, it means that the erroneous beha= viour is fj> > fr> the result of someone doing things "in the wrong order" (for = lack of fj> > fr> better terminology). fj> > fj> > =A0Well, does GPT really depend on the absolute last block? =A0Th= e header fj> > =A0has fields for both the first and the last LBAs and they do no= t have fj> > =A0to be matched with the physical capacity. =A0Creating a gmirro= r first, fj> > =A0and then creating a GPT on it does not work? =A0I do not think= it is fj> > =A0true, and I suspect a description on gmirror recommending fj> > =A0kern.geom.debugflags=3D17 in the handbook is the source of the= problem. fj> = fj> It's not the partitioning that's the issue. It's the order that GE= OM fj> providers and GPT partition tables are "tasted". fj> = fj> You can gmirror two disks, then GPT partition the gm0 device withou= t fj> any issues. As you noted, the first/last sectors are 1 less than t= he fj> physical disk (the size of the gmirror provider). fj> = fj> When you boot, though, the gptboot loader only sees the GPT table, = it fj> doesn't know that it's part of a gmirror setup. Thus it loads the fj> GPT, notices that the size of the GPT is 1 less sector than the siz= e fj> of the disk, can't find the secondary GPT table as the last sector = of fj> the disk is gmirror metadata, and complains about corrupted GPT. fj> = fj> Then the kernel loads, gmirror "tastes" the disk, finds the gmirror= fj> metadata, configures the gmirror provider, and now all the GPT stuf= f fj> matches again. And the system carries on correctly. fj> = fj> The issue is that we don't have a GEOM-aware loader. Or, at least,= fj> that the gpt*boot loaders read the GPT table(s) before configuring = the fj> GEOM providers. No, the issue is our gptloader assumes the backup header is always located at the (physical) last sector while this is not mandatory in the UEFI specification. GEOM-based logical volumes suffer from this assumption at boot time. It is not practical (and not necessary) to taste the volumes before loading a kernel. If the primary header is valid, using a lookup order of the hdr_lba_alt(AlternateLBA), the hdr_lba_end(LastUsableLBA), then drvsize() - 1 looks reasonable to me. The current code uses drvsize() - 1 first and then looks up the AlternateLBA only when drvsize() failed. -- Hiroki ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk89+/4ACgkQTyzT2CeTzy0L9ACgh49WyKoJBOT6c4WX2GycFFA9 NIUAoMDIEYLEkcL0yfQedMIiT/y/OgUX =MiHq -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Feb_17_16_04_30_2012_094)---- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 07:40:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 273DC106564A; Fri, 17 Feb 2012 07:40:02 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3A3E48FC08; Fri, 17 Feb 2012 07:40:01 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H7e0uw017537 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 23:40:00 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3E04AB.2000508@freebsd.org> Date: Thu, 16 Feb 2012 23:41:31 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: davidxu@freebsd.org References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> <4F3DBE90.5030305@gmail.com> In-Reply-To: <4F3DBE90.5030305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , Alexander Kabaev , Andriy Gapon , threads@freebsd.org, FreeBSD Stable , Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 07:40:10 -0000 adding jkim as he seems to be the last person working with TSC. On 2/16/12 6:42 PM, David Xu wrote: > On 2012/2/17 10:19, Julian Elischer wrote: >> On 2/16/12 5:56 PM, David Xu wrote: >>> On 2012/2/17 8:42, Julian Elischer wrote: >>>> Adding David Xu for his thoughts since he reqrote the code in >>>> quesiton in revision 213098 >>>> >>>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>>> >>>>>>>> the following code (from fio-2.0.3, but its in earlier code too) >>>>>>>> has suddenly started misbehaving. >>>>>>>> >>>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>>> t.tv_sec += seconds + 10; >>>>>>>> >>>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>>> >>>>>>>> while (!mutex->value&& !ret) { >>>>>>>> mutex->waiters++; >>>>>>>> ret = >>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>>> mutex->waiters--; >>>>>>>> } >>>>>>>> >>>>>>>> if (!ret) { >>>>>>>> mutex->value--; >>>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> It turns out that 'ret' sometimes comes back instantly (on my >>>>>>>> machine) with a >>>>>>>> value of 60 (ETIMEDOUT) >>>>>>>> despite the fact that we set the timeout 10 seconds into the >>>>>>>> future. >>>>>>>> >>>>>>>> Has anyone else seen anything like this? >>>>>>>> (and yes the condition variable attribute have been set to >>>>>>>> use the REALTIME clock). >>>>>>> But why? >>>>>>> >>>>>>> Just a hypothesis that maybe there is some issue with time >>>>>>> keeping on that system. >>>>>>> How would that code work out for you with MONOTONIC? >>>>>> >>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and >>>>>> CLOCK_MONOTONIC, and they both had the same problem.. >>>>>> i.e. random early returns with ETIMEDOUT. >>>>>> >>>>>> I think we will try move out machine forward to a newer -stable >>>>>> to see if it resolves. >>>>> Kan upgraded the machine today to today's 9.x branch tip and the >>>>> problem still occurs. >>>>> 8.x does not have this problem. >>>>> >>>>> I have not got a 9-RELEASE machine to test on.. so I can not >>>>> tell if this came in with the burst of stuff >>>>> that came in after the 9.x branch was unfrozen after the release >>>>> of 9.0. >>>>> >>>>> >>>> >>> I am trying to reproduce the problem, do you have complete sample >>> code to test ? >> >> I'm still looking the exact set >> but on my machine (4 cpus) the program from ports sysutils/fio >> exhibits the problem when used with >> kern.timecounter.hardware=TSC-low and with the following config file: >> >> pu05 # cat config.fio >> >> [global] >> #clocksource=cpu >> direct=1 >> rw=randread >> bs=4096 >> fill_device=1 >> numjobs=16 >> iodepth=16 >> #ioengine=posixaio >> #ioengine=psync >> ioengine=psync >> group_reporting >> norandommap >> time_based >> runtime=60000 >> randrepeat=0 >> >> [file1] >> filename=/dev/ada0 >> >> pu05 # >> pu05 # fio config.fio >> fio: this platform does not support process shared mutexes, forcing >> use of threads. Use the 'thread' option to get rid of this warning. >> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >> ... >> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >> fio 2.0.3 >> Starting 15 threads and 1 process >> fio: job startup hung? exiting. >> fio: 5 jobs failed to start >> Segmentation fault (core dumped) >> pu05# >> >> >> The reason 5 jobs failed to start is because the parent timed out >> on them immediately. >> It didn't time out on 10 of them apparently. >> >> >> if I set the timer to ACPI-fast it works as expected.. > maybe following code can check to see if TSC-LOW works by let the > thread run > on each cpu. > > gettimeofday(&prev, NULL); > int cpu = 0; > for (;;) { > cpuset_t set; > cpu = ++cpu % 4; > CPU_ZERO(&set); > CPU_SET(cpu, &set); > pthread_setaffinity_np(pthread_self(), sizeof(set), &set); > gettimeofday(&cur, NULL); > if ( timercmp(&prev, &cur, >=)) { > abort(); > } > } > > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 08:05:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C413106566B; Fri, 17 Feb 2012 08:05:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 329F68FC0C; Fri, 17 Feb 2012 08:05:10 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1H858gq017634 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 00:05:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3E0A90.6080400@freebsd.org> Date: Fri, 17 Feb 2012 00:06:40 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: davidxu@freebsd.org References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> <4F3DBE90.5030305@gmail.com> <4F3E04AB.2000508@freebsd.org> In-Reply-To: <4F3E04AB.2000508@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , Alexander Kabaev , Andriy Gapon , threads@freebsd.org, FreeBSD Stable , Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 08:05:11 -0000 On 2/16/12 11:41 PM, Julian Elischer wrote: > adding jkim as he seems to be the last person working with TSC. > > > On 2/16/12 6:42 PM, David Xu wrote: >> On 2012/2/17 10:19, Julian Elischer wrote: >>> On 2/16/12 5:56 PM, David Xu wrote: >>>> On 2012/2/17 8:42, Julian Elischer wrote: >>>>> Adding David Xu for his thoughts since he reqrote the code in >>>>> quesiton in revision 213098 >>>>> >>>>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>>>> >>>>>>>>> the following code (from fio-2.0.3, but its in earlier code >>>>>>>>> too) >>>>>>>>> has suddenly started misbehaving. >>>>>>>>> >>>>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>>>> t.tv_sec += seconds + 10; >>>>>>>>> >>>>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>>>> >>>>>>>>> while (!mutex->value&& !ret) { >>>>>>>>> mutex->waiters++; >>>>>>>>> ret = >>>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>>>> mutex->waiters--; >>>>>>>>> } >>>>>>>>> >>>>>>>>> if (!ret) { >>>>>>>>> mutex->value--; >>>>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> It turns out that 'ret' sometimes comes back instantly (on >>>>>>>>> my machine) with a >>>>>>>>> value of 60 (ETIMEDOUT) >>>>>>>>> despite the fact that we set the timeout 10 seconds into the >>>>>>>>> future. >>>>>>>>> >>>>>>>>> Has anyone else seen anything like this? >>>>>>>>> (and yes the condition variable attribute have been set to >>>>>>>>> use the REALTIME clock). >>>>>>>> But why? >>>>>>>> >>>>>>>> Just a hypothesis that maybe there is some issue with time >>>>>>>> keeping on that system. >>>>>>>> How would that code work out for you with MONOTONIC? >>>>>>> >>>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and >>>>>>> CLOCK_MONOTONIC, and they both had the same problem.. >>>>>>> i.e. random early returns with ETIMEDOUT. >>>>>>> >>>>>>> I think we will try move out machine forward to a newer >>>>>>> -stable to see if it resolves. >>>>>> Kan upgraded the machine today to today's 9.x branch tip and >>>>>> the problem still occurs. >>>>>> 8.x does not have this problem. >>>>>> >>>>>> I have not got a 9-RELEASE machine to test on.. so I can not >>>>>> tell if this came in with the burst of stuff >>>>>> that came in after the 9.x branch was unfrozen after the >>>>>> release of 9.0. >>>>>> >>>>>> >>>>> >>>> I am trying to reproduce the problem, do you have complete >>>> sample code to test ? >>> >>> I'm still looking the exact set >>> but on my machine (4 cpus) the program from ports sysutils/fio >>> exhibits the problem when used with >>> kern.timecounter.hardware=TSC-low and with the following config file: >>> >>> pu05 # cat config.fio >>> >>> [global] >>> #clocksource=cpu >>> direct=1 >>> rw=randread >>> bs=4096 >>> fill_device=1 >>> numjobs=16 >>> iodepth=16 >>> #ioengine=posixaio >>> #ioengine=psync >>> ioengine=psync >>> group_reporting >>> norandommap >>> time_based >>> runtime=60000 >>> randrepeat=0 >>> >>> [file1] >>> filename=/dev/ada0 >>> >>> pu05 # >>> pu05 # fio config.fio >>> fio: this platform does not support process shared mutexes, >>> forcing use of threads. Use the 'thread' option to get rid of this >>> warning. >>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >>> ... >>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >>> fio 2.0.3 >>> Starting 15 threads and 1 process >>> fio: job startup hung? exiting. >>> fio: 5 jobs failed to start >>> Segmentation fault (core dumped) >>> pu05# >>> >>> >>> The reason 5 jobs failed to start is because the parent timed out >>> on them immediately. >>> It didn't time out on 10 of them apparently. >>> >>> >>> if I set the timer to ACPI-fast it works as expected.. >> maybe following code can check to see if TSC-LOW works by let the >> thread run >> on each cpu. >> >> gettimeofday(&prev, NULL); >> int cpu = 0; >> for (;;) { >> cpuset_t set; >> cpu = ++cpu % 4; >> CPU_ZERO(&set); >> CPU_SET(cpu, &set); >> pthread_setaffinity_np(pthread_self(), sizeof(set), &set); >> gettimeofday(&cur, NULL); >> if ( timercmp(&prev, &cur, >=)) { >> abort(); >> } >> } >> >> pu05# sysctl kern.timecounter.hardware=TSC-low kern.timecounter.hardware: ACPI-fast -> TSC-low pu05# ./test ^C pu05# cat test.c #include #include #include #include #include main() { int cpu = 0; struct timeval prev, cur; gettimeofday(&prev, NULL); for (;;) { cpuset_t set; cpu = ++cpu % 4; CPU_ZERO(&set); CPU_SET(cpu, &set); pthread_setaffinity_np(pthread_self(), sizeof(set), &set); gettimeofday(&cur, NULL); if ( timercmp(&prev, &cur, >)) { abort(); } prev = cur; } } pu05# ./test minutes pass....... ^C pu05# so it looks as if the TSC is working ok.. I'm just going to check that the program is actually moving CPU... yes it is moving around but I can't tell at what speed. (according to top). so we are still left with a question of "where is the problem?" kernel TSC driver? generic gettimeofday() code? pthreads cond code? the application? From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 09:37:43 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4AF7106564A; Fri, 17 Feb 2012 09:37:43 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F2D428FC14; Fri, 17 Feb 2012 09:37:41 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA03355; Fri, 17 Feb 2012 11:37:39 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RyKG3-0007Xd-IM; Fri, 17 Feb 2012 11:37:39 +0200 Message-ID: <4F3E1FC5.2020103@FreeBSD.org> Date: Fri, 17 Feb 2012 11:37:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3AE.5000109@freebsd.org> In-Reply-To: <4F3DB3AE.5000109@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , threads@FreeBSD.org, FreeBSD Stable , David Xu , Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? [possible answer] 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, 17 Feb 2012 09:37:43 -0000 on 17/02/2012 03:55 Julian Elischer said the following: > > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > > switching the machine from TSC_low to ACPI-fast fixes the problem. > > in 8.x it used to default to ACPI > but I used to switch it to "TSC" to get better performance. > > I wonder why TSC-low is now bad to use.. > maybe the TSCs are not as well sychronised as they were in 8.x? > maybe the pthreads code didn't get the memo about changing timers? More useful information that you can provide: - C-states configuration - CPU identification I see that you've already contacted jkim, that's useful too. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 10:37:34 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528B51065673 for ; Fri, 17 Feb 2012 10:37:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8F19E8FC14 for ; Fri, 17 Feb 2012 10:37:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA04035; Fri, 17 Feb 2012 12:37:19 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RyLBn-0007aW-20; Fri, 17 Feb 2012 12:37:19 +0200 Message-ID: <4F3E2DBE.2070107@FreeBSD.org> Date: Fri, 17 Feb 2012 12:36:46 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Freddie Cash References: <4F35743B.4020302@os2.kiev.ua> <4F37DBA3.7030304@cran.org.uk> <20120213195554.O46120@sola.nimnet.asn.au> <092c01cceb40$2dc8f240$895ad6c0$@fisglobal.com> <095a01cceb54$04a38fb0$0deaaf10$@fisglobal.com> <4F3ACDE7.8060003@bit0.com> <4F3D9A7C.7080900@quip.cz> <20120217001829.GA59869@icarus.home.lan> <20120217021019.GA61420@icarus.home.lan> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Warren Block , freebsd-stable@FreeBSD.org, Mike Andrews , Miroslav Lachman <000.fbsd@quip.cz>, Jeremy Chadwick Subject: Re: New BSD Installer 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, 17 Feb 2012 10:37:34 -0000 on 17/02/2012 07:37 Freddie Cash said the following: > Seems to me that we need a GEOM-aware loader I am also adding a GEOM-aware BIOS/firmware to the wish-list. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 10:46:53 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 664CD106564A; Fri, 17 Feb 2012 10:46:53 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 584238FC0C; Fri, 17 Feb 2012 10:46:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA04204; Fri, 17 Feb 2012 12:46:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RyLL0-0007bI-2M; Fri, 17 Feb 2012 12:46:50 +0200 Message-ID: <4F3E3000.9000206@FreeBSD.org> Date: Fri, 17 Feb 2012 12:46:24 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> <20120217.160430.406937514120319292.hrs@allbsd.org> In-Reply-To: <20120217.160430.406937514120319292.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 10:46:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 17/02/2012 09:04 Hiroki Sato said the following: > No, the issue is our gptloader assumes the backup header is always located > at the (physical) last sector while this is not mandatory in the UEFI > specification. Are you sure? Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A September 7, 2011 says: [snip] > Two GPT Header structures are stored on the device: the primary and the > backup. The primary GPT Header must be located in LBA 1 (i.e., the second > logical block), and the backup GPT Header must be located in the last LBA > of the device. Within the GPT Header the My LBA field contains the [snip] > If the primary GPT is corrupt, software must check the last LBA of the > device to see if it has a valid GPT Header and point to a valid GPT > Partition Entry Array. If it points to a valid GPT Partition Entry Array, > then software should restore the primary GPT if allowed by platform policy > settings (e.g. a platform may require a user to provide confirmation before > restoring the table, or may allow the table to be restored automatically). > Software must report whenever it restores a GPT. [snip] > Both the primary and backup GPTs must be valid before an attempt is made to > grow the size of a physical volume. This is due to the GPT recovery scheme > depending on locating the backup GPT at the end of the device. A volume may > grow in size when disks are added to a RAID device. As soon as the volume > size is increased the backup GPT must be moved to the end of the volume and > the primary and backup GPT Headers must be updated to reflect the new > volume size. - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPPjAAAAoJEHSlLSemUf4vpjUH/0S2gDBN5gD1o7Aqa8W3BL2F mbz+riZYoCKca1QBRVb6sJ/xaCVHidoivbJMbXDCNLf35tdCvillQiNuaR4YizRD a8McAg4OpQmYlaNJ39/dpnIpPyY0XZ2jZWVV9PGob5tnh0uBDm0TL8/JSxIrsyol l+QmUbuicRXzcKhwHRW4MArLtUD5jiZK2ytxpUvDgv8rJcKQO3dnMSPSFi2V8eFQ 0Yq2Nzb7Dwf9Ie6ldLT/Pw2dtkbCBYQbngPqtt7ynwVDQY0NA5OysPW3gym2OLo+ Vk+SsVTrLe9MVeD8T/4qSVvGIgm0xNqXcyOt7XIpN/yyHkbR20kfuzuq3sooN4o= =/Q6i -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 11:12:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE691065670 for ; Fri, 17 Feb 2012 11:12:17 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id C0FB38FC18 for ; Fri, 17 Feb 2012 11:12:16 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyLjZ-00059g-HB; Fri, 17 Feb 2012 11:12:13 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyLjZ-0009kp-GN; Fri, 17 Feb 2012 11:12:13 +0000 To: freebsd@jdc.parodius.com, wblock@wonkity.com In-Reply-To: <20120217030806.GA62601@icarus.home.lan> Message-Id: From: Pete French Date: Fri, 17 Feb 2012 11:12:13 +0000 Cc: mandrews@bit0.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz Subject: Re: New BSD Installer 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, 17 Feb 2012 11:12:17 -0000 > I wasn't aware you could do that. I was only aware that it was the > other way around. That (my) misconception seems to also be relayed > by others such as Miroslav who said: Should this not be the recommended way of doing things even for MBR disks ? I have a lot of machines booting from gmirror, but we always do it by mirroring MBR partitions (or GPT ones). I cant see why you would want to do it the other way round in fact. It doesnt gain you anything does it ? As someone else pointed out, you do need to partition the two drives to match, and add bootloaders to them. But thats not really a great hardship is it, and everything just works properly. You dont need any different bootloader (as it sees the start of the drive and the gmirror stuff is at the end). An example I have here is a machine setup with a pair of drives, each has 3 partitions on it. ada0s1 ada0s2 and ada0s, plsu the correspoding ones on ada1. The two s1 partititons are gmirrored for boot, and the two s2 partitions are configured for swap, and the two s3 partitions are also mirrored, but using ZFS instead of gmirror. That kind of configuration is only really possible if you put the mirroring inside the external partition table. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 11:28:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C98B1065670; Fri, 17 Feb 2012 11:28:52 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0E56D8FC08; Fri, 17 Feb 2012 11:28:52 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1HBSn4v027239; Fri, 17 Feb 2012 11:28:49 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3E39EF.3030209@gmail.com> Date: Fri, 17 Feb 2012 19:28:47 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> <4F3DBE90.5030305@gmail.com> <4F3E04AB.2000508@freebsd.org> <4F3E0A90.6080400@freebsd.org> In-Reply-To: <4F3E0A90.6080400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Alexander Kabaev , Andriy Gapon , davidxu@freebsd.org, threads@freebsd.org, Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 11:28:52 -0000 On 2012/2/17 16:06, Julian Elischer wrote: > On 2/16/12 11:41 PM, Julian Elischer wrote: >> adding jkim as he seems to be the last person working with TSC. >> >> >> On 2/16/12 6:42 PM, David Xu wrote: >>> On 2012/2/17 10:19, Julian Elischer wrote: >>>> On 2/16/12 5:56 PM, David Xu wrote: >>>>> On 2012/2/17 8:42, Julian Elischer wrote: >>>>>> Adding David Xu for his thoughts since he reqrote the code in >>>>>> quesiton in revision 213098 >>>>>> >>>>>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>>>>> >>>>>>>>>> the following code (from fio-2.0.3, but its in earlier code too) >>>>>>>>>> has suddenly started misbehaving. >>>>>>>>>> >>>>>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>>>>> t.tv_sec += seconds + 10; >>>>>>>>>> >>>>>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>>>>> >>>>>>>>>> while (!mutex->value&& !ret) { >>>>>>>>>> mutex->waiters++; >>>>>>>>>> ret = >>>>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>>>>> mutex->waiters--; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if (!ret) { >>>>>>>>>> mutex->value--; >>>>>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It turns out that 'ret' sometimes comes back instantly (on my >>>>>>>>>> machine) with a >>>>>>>>>> value of 60 (ETIMEDOUT) >>>>>>>>>> despite the fact that we set the timeout 10 seconds into the >>>>>>>>>> future. >>>>>>>>>> >>>>>>>>>> Has anyone else seen anything like this? >>>>>>>>>> (and yes the condition variable attribute have been set to >>>>>>>>>> use the REALTIME clock). >>>>>>>>> But why? >>>>>>>>> >>>>>>>>> Just a hypothesis that maybe there is some issue with time >>>>>>>>> keeping on that system. >>>>>>>>> How would that code work out for you with MONOTONIC? >>>>>>>> >>>>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and >>>>>>>> CLOCK_MONOTONIC, and they both had the same problem.. >>>>>>>> i.e. random early returns with ETIMEDOUT. >>>>>>>> >>>>>>>> I think we will try move out machine forward to a newer -stable >>>>>>>> to see if it resolves. >>>>>>> Kan upgraded the machine today to today's 9.x branch tip and the >>>>>>> problem still occurs. >>>>>>> 8.x does not have this problem. >>>>>>> >>>>>>> I have not got a 9-RELEASE machine to test on.. so I can not >>>>>>> tell if this came in with the burst of stuff >>>>>>> that came in after the 9.x branch was unfrozen after the release >>>>>>> of 9.0. >>>>>>> >>>>>>> >>>>>> >>>>> I am trying to reproduce the problem, do you have complete sample >>>>> code to test ? >>>> >>>> I'm still looking the exact set >>>> but on my machine (4 cpus) the program from ports sysutils/fio >>>> exhibits the problem when used with >>>> kern.timecounter.hardware=TSC-low and with the following config file: >>>> >>>> pu05 # cat config.fio >>>> >>>> [global] >>>> #clocksource=cpu >>>> direct=1 >>>> rw=randread >>>> bs=4096 >>>> fill_device=1 >>>> numjobs=16 >>>> iodepth=16 >>>> #ioengine=posixaio >>>> #ioengine=psync >>>> ioengine=psync >>>> group_reporting >>>> norandommap >>>> time_based >>>> runtime=60000 >>>> randrepeat=0 >>>> >>>> [file1] >>>> filename=/dev/ada0 >>>> >>>> pu05 # >>>> pu05 # fio config.fio >>>> fio: this platform does not support process shared mutexes, forcing >>>> use of threads. Use the 'thread' option to get rid of this warning. >>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >>>> ... >>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, iodepth=16 >>>> fio 2.0.3 >>>> Starting 15 threads and 1 process >>>> fio: job startup hung? exiting. >>>> fio: 5 jobs failed to start >>>> Segmentation fault (core dumped) >>>> pu05# >>>> >>>> >>>> The reason 5 jobs failed to start is because the parent timed out >>>> on them immediately. >>>> It didn't time out on 10 of them apparently. >>>> >>>> >>>> if I set the timer to ACPI-fast it works as expected.. >>> maybe following code can check to see if TSC-LOW works by let the >>> thread run >>> on each cpu. >>> >>> gettimeofday(&prev, NULL); >>> int cpu = 0; >>> for (;;) { >>> cpuset_t set; >>> cpu = ++cpu % 4; >>> CPU_ZERO(&set); >>> CPU_SET(cpu, &set); >>> pthread_setaffinity_np(pthread_self(), sizeof(set), &set); >>> gettimeofday(&cur, NULL); >>> if ( timercmp(&prev, &cur, >=)) { >>> abort(); >>> } >>> } >>> >>> > > pu05# sysctl kern.timecounter.hardware=TSC-low > kern.timecounter.hardware: ACPI-fast -> TSC-low > pu05# ./test > ^C > pu05# cat test.c > > #include > #include > #include > #include > > #include > > main() > { > int cpu = 0; > struct timeval prev, cur; > > gettimeofday(&prev, NULL); > for (;;) { > cpuset_t set; > cpu = ++cpu % 4; > CPU_ZERO(&set); > CPU_SET(cpu, &set); > pthread_setaffinity_np(pthread_self(), sizeof(set), &set); > gettimeofday(&cur, NULL); > if ( timercmp(&prev, &cur, >)) { > abort(); > } > prev = cur; > } > } > > pu05# ./test > > minutes pass....... > > ^C > pu05# > > so it looks as if the TSC is working ok.. > I'm just going to check that the program is actually moving CPU... > yes it is moving around but I can't tell at what speed. (according to > top). > > so we are still left with a question of "where is the problem?" > > kernel TSC driver? > generic gettimeofday() code? > pthreads cond code? > the application? > > I am running the fio test on my notebook which is using TSC-low, it is on 9.0-RC3, I can not reproduce the problem for minutes, then I interrupt it with ctrl-c: http://people.freebsd.org/~davidxu/tsc_pthread/dmesg.txt http://people.freebsd.org/~davidxu/tsc_pthread/tc.txt http://people.freebsd.org/~davidxu/tsc_pthread/fio.txt From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 11:18:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C8B7106564A for ; Fri, 17 Feb 2012 11:18:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C04CC8FC12 for ; Fri, 17 Feb 2012 11:18:43 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CEAE.dip.t-dialin.net [87.150.206.174]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9658F84498E; Fri, 17 Feb 2012 12:18:25 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id E3CA1529C; Fri, 17 Feb 2012 12:18:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329477503; bh=zE/tJKaue4g2IJFCrxN2MqnKH/PleG1F/my7ppI0E1g=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=wSZ/KCc9gB5LgBoJPnwrMn8ml+F7V33heLyaXxmpBkhwK9kID8h3BZBPkbH8185lw st/RCAFXWVo4ng9TYS0JJ0aMtKFzsZN/zJdaTANZI21rUeKb2tgy92upFj2E1qKkfI XiYF8mYCta8sHU4DIAwBRsmABKM+RzFwJzm5AVZQvF0hBVKEpvUuKh3i0uX8WCcfFI a+2DpmTfYmACsYuf8DfzDH1ZiOsMmYZGA5t+2KlT23E+FimBzBiabJKGhD0gGYdi1/ QfALqNRI8bJIYfBRlqQoogUv1tUwQWfWfer50i/Zez7Imv/dEQ1X6Pg2KOAKdMa2xq CaECTI4V2Os3w== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1HBIIv0001303; Fri, 17 Feb 2012 12:18:18 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 17 Feb 2012 12:18:18 +0100 Date: Fri, 17 Feb 2012 12:18:15 +0100 Message-ID: <20120217121815.Horde.87ltTZjmRSRPPjd35caAIAA@webmail.leidinger.net> From: Alexander Leidinger To: Nenhum_de_Nos References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210144449.GA2358@psconsult.nl> <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> <57e2e07a4c574f537aab522ea9fa33aa.squirrel@eternamente.info> In-Reply-To: <57e2e07a4c574f537aab522ea9fa33aa.squirrel@eternamente.info> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9658F84498E.A1E8C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.317, required 6, autolearn=disabled, AWL -1.42, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_65 0.60, RCVD_IN_BL_SPAMCOP_NET 1.25, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330082307.31493@+D1b8qiZ/Aacn2dQ+MY3zw X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 17 Feb 2012 12:23:22 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel 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, 17 Feb 2012 11:18:44 -0000 Quoting Nenhum_de_Nos (from Tue, 14 Feb 2012 10:49:56 -0200): > On Tue, February 14, 2012 08:31, Alexander Leidinger wrote: >> Embedded devices are out of the scope of this, normally you do a lot >> of other modifictions to such systems anyway, so a custom kernel >> should be not a big problem. >> >> I will also not touch the dual-stack part of the kernel config (it >> shall still allow the generic purpose computing like the GERNERIC >> config). > > I'm really curious why, if they are the piece of hardware that > usually are worse to compile things > on, for access issues to poor hardware (great to compile > kernel+world on i7, pain to do so in my > net5501-70). Typically embedded environments have a different goal regarding the kernel, than a normal server/desktop. In an embedded sytem RAM and disc space may be very limited and as such you need to get rid of a lot of things you want to have in a server kernel. A server is also some kind of generic purpose device, whereas an embedded system is a special purpose device. If we do not know the special purpose of the device, we can not provide a suitable kernel for it (a NAS has other requirements than a router, firewall, WLAN access point or multimedia system). Regarding the compile time issue you talked about: cross compiling a world/kernel is supported by FreeBSD. It may be not a bad idea to provide examples of special purpose kernels with FreeBSD, but this is a completely different topic I (as the thread started) want to discuss in this thread about the work _I_ want to do and need input from the community for. You are off course free to open a new thread to discuss the kernel-config of special purpose devices. Bye, Alexander. -- Bender: Bite my shiny, metal ass! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 11:21:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA5151065670 for ; Fri, 17 Feb 2012 11:21:27 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 492328FC0A for ; Fri, 17 Feb 2012 11:21:27 +0000 (UTC) Received: from outgoing.leidinger.net (p5796CEAE.dip.t-dialin.net [87.150.206.174]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 30ADA84498E; Fri, 17 Feb 2012 12:21:13 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6F00B529D; Fri, 17 Feb 2012 12:21:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1329477670; bh=RnZKl+jBmvb4SZ/Mq7AF2jL6d6fSYB6bTGgo5xKR2BI=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version:Content-Transfer-Encoding; b=fDuYAa6QivuvodRsYtZofWuswEoQWCJFNbqHpG9CdgIurzsL1CJcPg8KujENJLJGN mclvvuNOgMEblGNo+YKB13HINEA+lj41fsciMiMQPj+lZSPfx6WCJiFAFXqDT4LySR Op8lt3D0Xv4oz8vjBIBVExFFHEK9MzfRSY6iYkjzbPcqaWh/ebb28GfPDh4hFsYbuw xOUOgML013E7VYg6p/R3WDcRazObR3oLOpIjzTmUmJIJIR4z0lAjx0+nVJ4z4+7pXd bCjRil7D1i5C5LMPqMyyRj7eMbP+MCyk9wMYS4qa45YLdQKJo3PhbAPxYCyW5OXotp Bn4tjXYWN/yBA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1HBLANN001501; Fri, 17 Feb 2012 12:21:10 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 17 Feb 2012 12:21:10 +0100 Date: Fri, 17 Feb 2012 12:21:10 +0100 Message-ID: <20120217122110.Horde.6XSicpjmRSRPPjgmMlJAECA@webmail.leidinger.net> From: Alexander Leidinger To: Freddie Cash References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> <20120215014738.O95093@sola.nimnet.asn.au> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 30ADA84498E.A3A3C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.085, required 6, autolearn=disabled, AWL -1.13, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_BL_SPAMCOP_NET 1.25, TW_PF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1330082474.70694@/obJ0R4qlr60u9qhTzPiag X-EBL-Spam-Status: No X-Mailman-Approved-At: Fri, 17 Feb 2012 12:23:35 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 17 Feb 2012 11:21:27 -0000 Quoting Freddie Cash (from Tue, 14 Feb 2012 08:26:54 -0800): > On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith wrote: >> On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote: >> =C2=A0> 1 IPSTEALTH =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-> changes ipfw module only? >> >> I don't think this is specific to ipfw. =C2=A0From /sys/conf/NOTES: >> >> # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding >> # packets without touching the TTL). =C2=A0This can be useful to hide fi= rewalls >> # from traceroute and similar tools. >> >> But can it be disabled once added to kernel? =C2=A0It's no good as a def= ault. > > It's controllable via sysctl once it's compiled into the kernel. If > it's not compiled into the kernel, then the sysctl doesn't exist. Is it the following? net.inet.ip.stealth=3D0 Bye, Alexander. -- BOFH excuse #152: My pony-tail hit the on/off switch on the power strip http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 14:30:36 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D121065677; Fri, 17 Feb 2012 14:30:36 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6C5438FC1C; Fri, 17 Feb 2012 14:30:35 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1HEUIVF041490; Fri, 17 Feb 2012 23:30:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1HEUEw9038771; Fri, 17 Feb 2012 23:30:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Feb 2012 23:28:43 +0900 (JST) Message-Id: <20120217.232843.2212672671663755444.hrs@allbsd.org> To: avg@FreeBSD.org From: Hiroki Sato In-Reply-To: <4F3E3000.9000206@FreeBSD.org> References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Fri, 17 Feb 2012 23:30:30 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 14:30:36 -0000 ----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Feb_17_23_28_43_2012_801)--" Content-Transfer-Encoding: 7bit ----Next_Part(Fri_Feb_17_23_28_43_2012_801)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andriy Gapon wrote in <4F3E3000.9000206@FreeBSD.org>: av> -----BEGIN PGP SIGNED MESSAGE----- av> Hash: SHA1 av> av> on 17/02/2012 09:04 Hiroki Sato said the following: av> > No, the issue is our gptloader assumes the backup header is always located av> > at the (physical) last sector while this is not mandatory in the UEFI av> > specification. av> av> Are you sure? Yes, sure. In the gm0->md0+md1 case, the last LBA of the "device" is changed (growed in size) but they can still have a valid backup header at "the last LBA - 1" before an attempt to grow the size of the volume as the last paragraph of your excerpts says. If we *choose* to grow the device size permanently, the backup header must be relocated at the new last LBA. However, before the relocation happens, the specification says both the primary and secondary header must be valid in the previous device size. This is my understanding. This means software should assume the device size can grow and should not assume the backup header is always located at the last possible LBA on the device. If AlternateLBA does not match "the device size - 1", the software should recognize the location of the backup header based on the information in the primary header first. The gptboot does not do so currently. I didn't give it a try actually but the attached patch is what I want to say. -- Hiroki ----Next_Part(Fri_Feb_17_23_28_43_2012_801)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gptboot-20120217-1.diff" Index: sys/boot/common/gpt.c =================================================================== --- sys/boot/common/gpt.c (revision 230616) +++ sys/boot/common/gpt.c (working copy) @@ -333,24 +333,26 @@ gptread_table("primary", uuid, dskp, &hdr_primary, table_primary) == 0) { hdr_primary_lba = hdr_primary.hdr_lba_self; + /* Use AlternateLBA if valid. If not, use LastUsableLBA+34. */ + if (hdr_primary_lba < hdr_primary.hdr_lba_alt) + altlba = hdr_primary.hdr_lba_alt; + else if (hdr_primary.hdr_lba_end != 0) + altlba = hdr_primary.hdr_lba_end + 34; gpthdr = &hdr_primary; gpttable = table_primary; } - altlba = drvsize(dskp); - if (altlba > 0) - altlba--; - else if (hdr_primary_lba > 0) { - /* - * If we cannot obtain disk size, but primary header - * is valid, we can get backup header location from - * there. - */ - altlba = hdr_primary.hdr_lba_alt; + /* + * Try to locate the backup header from the media size if no primary + * header found. + */ + if (hdr_primary_lba == 0) { + altlba = drvsize(dskp); + if (altlba > 0) + altlba--; } - if (altlba == 0) - printf("%s: unable to locate backup GPT header\n", BOOTPROG); - else if (gptread_hdr("backup", dskp, &hdr_backup, altlba) == 0 && + if (altlba != 0 && + gptread_hdr("backup", dskp, &hdr_backup, altlba) == 0 && gptread_table("backup", uuid, dskp, &hdr_backup, table_backup) == 0) { hdr_backup_lba = hdr_backup.hdr_lba_self; @@ -359,7 +361,8 @@ gpttable = table_backup; printf("%s: using backup GPT\n", BOOTPROG); } - } + } else + printf("%s: unable to locate backup GPT header\n", BOOTPROG); /* * Convert all BOOTONCE without BOOTME flags into BOOTFAILED. ----Next_Part(Fri_Feb_17_23_28_43_2012_801)---- ----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8+ZBsACgkQTyzT2CeTzy0M3ACg05dETV4WjnlHeiZwEJP/ujqC JC0AoL9uL7LTO2jp47qsVQFoavNaA51A =uxfH -----END PGP SIGNATURE----- ----Security_Multipart0(Fri_Feb_17_23_28_43_2012_262)---- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:14:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDF93106564A for ; Fri, 17 Feb 2012 15:14:22 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9EAC78FC1A for ; Fri, 17 Feb 2012 15:14:22 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so3358870vbb.13 for ; Fri, 17 Feb 2012 07:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nq2K6qUA7YTZ/Kj3oUwi2f8oy+f8yhRZcP7qieWMcVA=; b=Fn6x/gSeUaKGZCCiD4FcmBjeLajG2x0biBbZ1XghTzzhaVg5tfXXghxy5icpyDoE0L 945/7ZxBTVJzxBiFHG5/7bgw5radkxNJ2liNSOn1k3t88CGQrbDuIJdSlPqj9aWhZHqF vjV2Lg04MLyHMwcQG4HT+K2KMe9CiTkizmkck= MIME-Version: 1.0 Received: by 10.52.36.242 with SMTP id t18mr3325905vdj.7.1329491661943; Fri, 17 Feb 2012 07:14:21 -0800 (PST) Received: by 10.220.192.135 with HTTP; Fri, 17 Feb 2012 07:14:21 -0800 (PST) In-Reply-To: <20120217122110.Horde.6XSicpjmRSRPPjgmMlJAECA@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> <20120215014738.O95093@sola.nimnet.asn.au> <20120217122110.Horde.6XSicpjmRSRPPjgmMlJAECA@webmail.leidinger.net> Date: Fri, 17 Feb 2012 07:14:21 -0800 Message-ID: From: Freddie Cash To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 17 Feb 2012 15:14:23 -0000 On Fri, Feb 17, 2012 at 3:21 AM, Alexander Leidinger wrote: > Quoting Freddie Cash (from Tue, 14 Feb 2012 08:26:54 > -0800): > >> On Tue, Feb 14, 2012 at 7:43 AM, Ian Smith wrote: >>> >>> On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote: >>> =C2=A0> 1 IPSTEALTH =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0-> changes ipfw module only? >>> >>> I don't think this is specific to ipfw. =C2=A0From /sys/conf/NOTES: >>> >>> # IPSTEALTH enables code to support stealth forwarding (i.e., forwardin= g >>> # packets without touching the TTL). =C2=A0This can be useful to hide >>> firewalls >>> # from traceroute and similar tools. >>> >>> But can it be disabled once added to kernel? =C2=A0It's no good as a de= fault. >> >> >> It's controllable via sysctl once it's compiled into the kernel. =C2=A0I= f >> it's not compiled into the kernel, then the sysctl doesn't exist. > > > Is it the following? > net.inet.ip.stealth=3D0 Yeah, that's the one. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:21:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A625910656D1 for ; Fri, 17 Feb 2012 15:21:46 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDDC8FC15 for ; Fri, 17 Feb 2012 15:21:46 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3394318vcm.13 for ; Fri, 17 Feb 2012 07:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mZ57Que6JtCGvIiTjUjlqoouZHxk/W0LWvpCheegYvE=; b=IcvzztwsjIeGpoc7u+PDvAfkBNwdwrBuwHdz2v24IdzcopnyBOJr3Q7s26Ybx1cp/R xAAT4V+CJ4uI4foP6NWSDV1cL5YxRHxx/plBlfjxpLAXaouFQuyYunN50SVBpNYDHM4E yx/ubTQ91tWLniQx4FRDRa8Fh0HJ8Y6pj02xE= MIME-Version: 1.0 Received: by 10.52.38.10 with SMTP id c10mr3324547vdk.58.1329492105763; Fri, 17 Feb 2012 07:21:45 -0800 (PST) Received: by 10.220.192.135 with HTTP; Fri, 17 Feb 2012 07:21:45 -0800 (PST) In-Reply-To: References: <20120217030806.GA62601@icarus.home.lan> Date: Fri, 17 Feb 2012 07:21:45 -0800 Message-ID: From: Freddie Cash To: Pete French Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 15:21:46 -0000 On Fri, Feb 17, 2012 at 3:12 AM, Pete French wr= ote: >> I wasn't aware you could do that. =C2=A0I was only aware that it was the >> other way around. =C2=A0That (my) misconception seems to also be relayed >> by others such as Miroslav who said: > > Should this not be the recommended way of doing things even for MBR > disks ? I have a lot of machines booting from gmirror, but we always > do it by mirroring MBR partitions (or GPT ones). I cant see why you would > want to do it the other way round in fact. It doesnt gain you anything > does it ? The problem with mirroring partitions is that you thrash the disk during the rebuild after replacing a failed disk. And the more partitions you have, the worse it gets. If you mirror the device, then the rebuild process only has to rebuild a single "thing". If you mirror 4 partitions on a device, then there will be four simultaneous, parallel rebuild processes running, thrashing the drive heads on both devices, killing you I/O throughput and extending the length of the rebuild. And if you mix your redundancy technologies (like gmirror and zfs mirror) it gets even worse due to competing rebuild schedulers. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:33:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706971065674 for ; Fri, 17 Feb 2012 15:33:02 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0E73E8FC15 for ; Fri, 17 Feb 2012 15:33:02 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyPng-00081m-2t; Fri, 17 Feb 2012 15:32:44 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyPng-00016G-2N; Fri, 17 Feb 2012 15:32:44 +0000 To: fjwcash@gmail.com, petefrench@ingresso.co.uk In-Reply-To: Message-Id: From: Pete French Date: Fri, 17 Feb 2012 15:32:44 +0000 Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 15:33:02 -0000 > The problem with mirroring partitions is that you thrash the disk > during the rebuild after replacing a failed disk. And the more > partitions you have, the worse it gets. yes, this is true - actually I have had this on older machiens, and have had to stop the rebuilds of each bit until the other completes for this reason. had forgotten that.... am about to replace a failed drive in one of my 2 gmirror ++ zfs boxes, so the reminder comes at a good time ;) -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:43:35 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF5C2106564A; Fri, 17 Feb 2012 15:43:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4DF78FC0A; Fri, 17 Feb 2012 15:43:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08997; Fri, 17 Feb 2012 17:43:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3E75A4.3040400@FreeBSD.org> Date: Fri, 17 Feb 2012 17:43:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> In-Reply-To: <20120217.232843.2212672671663755444.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 15:43:35 -0000 on 17/02/2012 16:28 Hiroki Sato said the following: > Andriy Gapon wrote > in <4F3E3000.9000206@FreeBSD.org>: > > av> -----BEGIN PGP SIGNED MESSAGE----- > av> Hash: SHA1 > av> > av> on 17/02/2012 09:04 Hiroki Sato said the following: > av> > No, the issue is our gptloader assumes the backup header is always located > av> > at the (physical) last sector while this is not mandatory in the UEFI > av> > specification. > av> > av> Are you sure? > > Yes, sure. Sorry, I haven't really given a thought to what you wrote below. You said that "this is not mandatory in the UEFI specification" and I gave the quotes which say that it is. Also keep in mind that BIOS and other OSs know nothing about FreeBSD GEOM. > In the gm0->md0+md1 case, the last LBA of the "device" is > changed (growed in size) but they can still have a valid backup > header at "the last LBA - 1" before an attempt to grow the size of > the volume as the last paragraph of your excerpts says. If we > *choose* to grow the device size permanently, the backup header must > be relocated at the new last LBA. However, before the relocation > happens, the specification says both the primary and secondary header > must be valid in the previous device size. This is my understanding. > > This means software should assume the device size can grow and should > not assume the backup header is always located at the last possible > LBA on the device. If AlternateLBA does not match "the device size - > 1", the software should recognize the location of the backup header > based on the information in the primary header first. The gptboot > does not do so currently. I didn't give it a try actually but the > attached patch is what I want to say. > > -- Hiroki -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:49:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3593C1065674 for ; Fri, 17 Feb 2012 15:49:44 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id C74168FC1F for ; Fri, 17 Feb 2012 15:49:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1HFnfpR052762; Fri, 17 Feb 2012 08:49:41 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1HFnfIL052759; Fri, 17 Feb 2012 08:49:41 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 17 Feb 2012 08:49:41 -0700 (MST) From: Warren Block To: Freddie Cash In-Reply-To: Message-ID: References: <20120217030806.GA62601@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-902635197-1653418493-1329493022=:52228" Content-ID: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 17 Feb 2012 08:49:41 -0700 (MST) Cc: freebsd-stable@freebsd.org, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd@jdc.parodius.com, Pete French Subject: Re: New BSD Installer 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, 17 Feb 2012 15:49:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---902635197-1653418493-1329493022=:52228 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 17 Feb 2012, Freddie Cash wrote: > On Fri, Feb 17, 2012 at 3:12 AM, Pete French wrote: >>> I wasn't aware you could do that.  I was only aware that it was the >>> other way around.  That (my) misconception seems to also be relayed >>> by others such as Miroslav who said: >> >> Should this not be the recommended way of doing things even for MBR >> disks ? I have a lot of machines booting from gmirror, but we always >> do it by mirroring MBR partitions (or GPT ones). I cant see why you would >> want to do it the other way round in fact. It doesnt gain you anything >> does it ? > > The problem with mirroring partitions is that you thrash the disk > during the rebuild after replacing a failed disk. Potentially, yes. > And the more partitions you have, the worse it gets. One big mirrored partition avoids it, but then there's only one partition. (ad0p2a? Forget I mentioned that.) > If you mirror the device, then the rebuild process only has to rebuild > a single "thing". > > If you mirror 4 partitions on a device, then there will be four > simultaneous, parallel rebuild processes running, thrashing the drive > heads on both devices, killing you I/O throughput and extending the > length of the rebuild. Some queuing logic in the mirror rebuild could avoid that. I am blissfully unaware of how complicated that might be. ---902635197-1653418493-1329493022=:52228-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 15:54:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D66E106567C for ; Fri, 17 Feb 2012 15:54:42 +0000 (UTC) (envelope-from boland37@xs4all.nl) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id C007A8FC17 for ; Fri, 17 Feb 2012 15:54:41 +0000 (UTC) Received: from charlemagne.boland.org (150-42-215.ftth.xms.internl.net [82.215.42.150]) (authenticated bits=0) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id q1HFbBli031745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 17 Feb 2012 16:37:11 +0100 (CET) (envelope-from boland37@xs4all.nl) Message-ID: <4F3E7426.70408@xs4all.nl> Date: Fri, 17 Feb 2012 16:37:10 +0100 From: Michiel Boland User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.26) Gecko/20120203 Thunderbird/3.1.18 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20120217030806.GA62601@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: New BSD Installer 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, 17 Feb 2012 15:54:42 -0000 On 02/17/2012 16:21, Freddie Cash wrote: [...] > The problem with mirroring partitions is that you thrash the disk > during the rebuild after replacing a failed disk. And the more > partitions you have, the worse it gets. I guess that if you do per-slice mirroring you should turn off autosync, right? Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 16:17:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id ADFB41065674; Fri, 17 Feb 2012 16:17:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "davidxu@freebsd.org" Date: Fri, 17 Feb 2012 11:17:41 -0500 User-Agent: KMail/1.6.2 References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3E0A90.6080400@freebsd.org> <4F3E39EF.3030209@gmail.com> In-Reply-To: <4F3E39EF.3030209@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202171117.46626.jkim@FreeBSD.org> Cc: Alexander Kabaev , "threads@freebsd.org" , Julian Elischer , FreeBSD Stable , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 16:17:55 -0000 On Friday 17 February 2012 06:28 am, David Xu wrote: > On 2012/2/17 16:06, Julian Elischer wrote: > > On 2/16/12 11:41 PM, Julian Elischer wrote: > >> adding jkim as he seems to be the last person working with TSC. > >> > >> On 2/16/12 6:42 PM, David Xu wrote: > >>> On 2012/2/17 10:19, Julian Elischer wrote: > >>>> On 2/16/12 5:56 PM, David Xu wrote: > >>>>> On 2012/2/17 8:42, Julian Elischer wrote: > >>>>>> Adding David Xu for his thoughts since he reqrote the code > >>>>>> in quesiton in revision 213098 > >>>>>> > >>>>>> On 2/16/12 2:57 PM, Julian Elischer wrote: > >>>>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: > >>>>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: > >>>>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: > >>>>>>>>>> The program fio (an IO test in ports) uses pthreads > >>>>>>>>>> > >>>>>>>>>> the following code (from fio-2.0.3, but its in earlier > >>>>>>>>>> code too) has suddenly started misbehaving. > >>>>>>>>>> > >>>>>>>>>> clock_gettime(CLOCK_REALTIME,&t); > >>>>>>>>>> t.tv_sec += seconds + 10; > >>>>>>>>>> > >>>>>>>>>> pthread_mutex_lock(&mutex->lock); > >>>>>>>>>> > >>>>>>>>>> while (!mutex->value&& !ret) { > >>>>>>>>>> mutex->waiters++; > >>>>>>>>>> ret = > >>>>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); > >>>>>>>>>> mutex->waiters--; > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> if (!ret) { > >>>>>>>>>> mutex->value--; > >>>>>>>>>> pthread_mutex_unlock(&mutex->lock); > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> It turns out that 'ret' sometimes comes back instantly > >>>>>>>>>> (on my machine) with a > >>>>>>>>>> value of 60 (ETIMEDOUT) > >>>>>>>>>> despite the fact that we set the timeout 10 seconds into > >>>>>>>>>> the future. > >>>>>>>>>> > >>>>>>>>>> Has anyone else seen anything like this? > >>>>>>>>>> (and yes the condition variable attribute have been set > >>>>>>>>>> to use the REALTIME clock). > >>>>>>>>> > >>>>>>>>> But why? > >>>>>>>>> > >>>>>>>>> Just a hypothesis that maybe there is some issue with > >>>>>>>>> time keeping on that system. > >>>>>>>>> How would that code work out for you with MONOTONIC? > >>>>>>>> > >>>>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and > >>>>>>>> CLOCK_MONOTONIC, and they both had the same problem.. > >>>>>>>> i.e. random early returns with ETIMEDOUT. > >>>>>>>> > >>>>>>>> I think we will try move out machine forward to a newer > >>>>>>>> -stable to see if it resolves. > >>>>>>> > >>>>>>> Kan upgraded the machine today to today's 9.x branch tip > >>>>>>> and the problem still occurs. > >>>>>>> 8.x does not have this problem. > >>>>>>> > >>>>>>> I have not got a 9-RELEASE machine to test on.. so I can > >>>>>>> not tell if this came in with the burst of stuff > >>>>>>> that came in after the 9.x branch was unfrozen after the > >>>>>>> release of 9.0. > >>>>> > >>>>> I am trying to reproduce the problem, do you have complete > >>>>> sample code to test ? > >>>> > >>>> I'm still looking the exact set > >>>> but on my machine (4 cpus) the program from ports sysutils/fio > >>>> exhibits the problem when used with > >>>> kern.timecounter.hardware=TSC-low and with the following > >>>> config file: > >>>> > >>>> pu05 # cat config.fio > >>>> > >>>> [global] > >>>> #clocksource=cpu > >>>> direct=1 > >>>> rw=randread > >>>> bs=4096 > >>>> fill_device=1 > >>>> numjobs=16 > >>>> iodepth=16 > >>>> #ioengine=posixaio > >>>> #ioengine=psync > >>>> ioengine=psync > >>>> group_reporting > >>>> norandommap > >>>> time_based > >>>> runtime=60000 > >>>> randrepeat=0 > >>>> > >>>> [file1] > >>>> filename=/dev/ada0 > >>>> > >>>> pu05 # > >>>> pu05 # fio config.fio > >>>> fio: this platform does not support process shared mutexes, > >>>> forcing use of threads. Use the 'thread' option to get rid of > >>>> this warning. file1: (g=0): rw=randread, bs=4K-4K/4K-4K, > >>>> ioengine=psync, iodepth=16 ... > >>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, > >>>> iodepth=16 fio 2.0.3 > >>>> Starting 15 threads and 1 process > >>>> fio: job startup hung? exiting. > >>>> fio: 5 jobs failed to start > >>>> Segmentation fault (core dumped) > >>>> pu05# > >>>> > >>>> > >>>> The reason 5 jobs failed to start is because the parent timed > >>>> out on them immediately. > >>>> It didn't time out on 10 of them apparently. > >>>> > >>>> > >>>> if I set the timer to ACPI-fast it works as expected.. > >>> > >>> maybe following code can check to see if TSC-LOW works by let > >>> the thread run > >>> on each cpu. > >>> > >>> gettimeofday(&prev, NULL); > >>> int cpu = 0; > >>> for (;;) { > >>> cpuset_t set; > >>> cpu = ++cpu % 4; > >>> CPU_ZERO(&set); > >>> CPU_SET(cpu, &set); > >>> pthread_setaffinity_np(pthread_self(), sizeof(set), &set); > >>> gettimeofday(&cur, NULL); > >>> if ( timercmp(&prev, &cur, >=)) { > >>> abort(); > >>> } > >>> } > > > > pu05# sysctl kern.timecounter.hardware=TSC-low > > kern.timecounter.hardware: ACPI-fast -> TSC-low > > pu05# ./test > > ^C > > pu05# cat test.c > > > > #include > > #include > > #include > > #include > > > > #include > > > > main() > > { > > int cpu = 0; > > struct timeval prev, cur; > > > > gettimeofday(&prev, NULL); > > for (;;) { > > cpuset_t set; > > cpu = ++cpu % 4; > > CPU_ZERO(&set); > > CPU_SET(cpu, &set); > > pthread_setaffinity_np(pthread_self(), sizeof(set), > > &set); gettimeofday(&cur, NULL); > > if ( timercmp(&prev, &cur, >)) { > > abort(); > > } > > prev = cur; > > } > > } > > > > pu05# ./test > > > > minutes pass....... > > > > ^C > > pu05# > > > > so it looks as if the TSC is working ok.. > > I'm just going to check that the program is actually moving > > CPU... yes it is moving around but I can't tell at what speed. > > (according to top). > > > > so we are still left with a question of "where is the problem?" > > > > kernel TSC driver? > > generic gettimeofday() code? > > pthreads cond code? > > the application? > > I am running the fio test on my notebook which is using TSC-low, > it is on 9.0-RC3, I can not reproduce the problem for > minutes, then I interrupt it with ctrl-c: > > http://people.freebsd.org/~davidxu/tsc_pthread/dmesg.txt > http://people.freebsd.org/~davidxu/tsc_pthread/tc.txt > http://people.freebsd.org/~davidxu/tsc_pthread/fio.txt Your CPU is single-package, dual-core, and SMT-enabled. All cores should be in perfect sync. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 16:39:31 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 5457F106566B; Fri, 17 Feb 2012 16:39:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 17 Feb 2012 11:39:21 -0500 User-Agent: KMail/1.6.2 References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3AE.5000109@freebsd.org> In-Reply-To: <4F3DB3AE.5000109@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202171139.23610.jkim@FreeBSD.org> Cc: Alexander Kabaev , "threads@freebsd.org" , Julian Elischer , David Xu , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? [possible answer] 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, 17 Feb 2012 16:39:31 -0000 On Thursday 16 February 2012 08:55 pm, Julian Elischer wrote: > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) > ACPI-fast(900) dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > > switching the machine from TSC_low to ACPI-fast fixes the problem. > > in 8.x it used to default to ACPI > but I used to switch it to "TSC" to get better performance. > > I wonder why TSC-low is now bad to use.. > maybe the TSCs are not as well sychronised as they were in 8.x? Can you please show us verbose dmesg output? FYI, TSC and TSC-low are not very different. TSC-low is just lower resolution version of TSC for SMP. Only difference is, we have automated your timecounter choice, i.e., if TSCs seem reasonably well-synchronized, select it by default but give lower resolution. In other words, if your TSC timecounter was never going backwards previously, TSC-low timecounter won't, guaranteed. So, the root cause should be somewhere else. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 17:00:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0C84106566B; Fri, 17 Feb 2012 17:00:26 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id 8E2248FC13; Fri, 17 Feb 2012 17:00:26 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id A5E9539030; Fri, 17 Feb 2012 18:00:24 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id IReJtAnKw0TY; Fri, 17 Feb 2012 18:00:19 +0100 (CET) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 6AF8439026; Fri, 17 Feb 2012 18:00:19 +0100 (CET) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 3DF1F194108; Fri, 17 Feb 2012 18:00:19 +0100 (CET) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id ZjcTCRTYQZqm; Fri, 17 Feb 2012 18:00:18 +0100 (CET) Received: from [192.168.10.83] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id B8AFD194103; Fri, 17 Feb 2012 18:00:18 +0100 (CET) Message-ID: <4F3E87A2.80000@zirakzigil.org> Date: Fri, 17 Feb 2012 18:00:18 +0100 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kerberized NFS 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, 17 Feb 2012 17:00:27 -0000 Thanks everybody again for your help with setting up a working kerberized nfsv4 system. I was able to user-mount a nfsv4 share with krb5 security, and I was trying to do the same as root. Unfortunately the patch I found here: http://people.freebsd.org/~rmacklem/rpcsec_gss.patch fails to apply cleanly on a 9 stable system. Is there a more recent patch available or some better way to automatically mount the share at boot time? Thanks again. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 17:10:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C321E10656A9 for ; Fri, 17 Feb 2012 17:10:15 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB908FC1B for ; Fri, 17 Feb 2012 17:09:59 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E3DE528426; Fri, 17 Feb 2012 18:09:56 +0100 (CET) Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id AADF628424; Fri, 17 Feb 2012 18:09:55 +0100 (CET) Message-ID: <4F3E89E3.3060608@quip.cz> Date: Fri, 17 Feb 2012 18:09:55 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Pete French References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, mandrews@bit0.com, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 17:10:15 -0000 Pete French wrote: >> I wasn't aware you could do that. I was only aware that it was the >> other way around. That (my) misconception seems to also be relayed >> by others such as Miroslav who said: > > Should this not be the recommended way of doing things even for MBR > disks ? I have a lot of machines booting from gmirror, but we always > do it by mirroring MBR partitions (or GPT ones). I cant see why you would > want to do it the other way round in fact. It doesnt gain you anything > does it ? Yes it does? Am I the only one person on the whole earth seeing the big difference in easy setup of mirroring two drives instead of many individual partitions? Freddie Cash already write about disk thrashing on rebuild after power failure, but initial setup or repair after disk replacement is also pain with mirroring individual partitions. > As someone else pointed out, you do need to partition the two drives > to match, and add bootloaders to them. But thats not really a great > hardship is it, and everything just works properly. You dont need > any different bootloader (as it sees the start of the drive and the > gmirror stuff is at the end). > Comparing our usual setup with 7 partitions after disk failure and replacement: Mirroring whole drives (after failed disk replacement): 1) gmirror forget -v gm0 2) gmirror insert -v gm0 ada1 And I am done! Mirroring individual partitions (maintenance nightmare)): 1) find sizes of partitions 2) create partitions on new drive 3) install boot sector 4) gmirror forget -v gm0p1 5) gmirror insert -v gm0p1 ada1p1 (and wait til synchronized) 6) gmirror forget -v gm0p2 7) gmirror insert -v gm0p2 ada1p2 (and wait til synchronized) 8) gmirror forget -v gm0p3 9) gmirror insert -v gm0p3 ada1p3 (and wait til synchronized) 10) gmirror forget -v gm0p4 11) gmirror insert -v gm0p4 ada1p4 (and wait til synchronized) 12) gmirror forget -v gm0p5 13) gmirror insert -v gm0p5 ada1p5 (and wait til synchronized) 14) gmirror forget -v gm0p6 15) gmirror insert -v gm0p6 ada1p6 (and wait til synchronized) 16) gmirror forget -v gm0p7 17) gmirror insert -v gm0p7 ada1p7 And after 15 more steps, you are done too. I think you cannot compare mirrored partitions to what can be done by ZFS mirror or gmirror on whole drives and I am not willing to go by this way. I will use gmirror and MBR where possible. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 17:59:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B5F106566C for ; Fri, 17 Feb 2012 17:59:23 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id 775768FC17 for ; Fri, 17 Feb 2012 17:59:23 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyS59-0001R3-Ej; Fri, 17 Feb 2012 17:58:55 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RyS59-0001ek-Eb; Fri, 17 Feb 2012 17:58:55 +0000 To: 000.fbsd@quip.cz, petefrench@ingresso.co.uk In-Reply-To: <4F3E89E3.3060608@quip.cz> Message-Id: From: Pete French Date: Fri, 17 Feb 2012 17:58:55 +0000 Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@freebsd.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 17:59:24 -0000 > Yes it does? Am I the only one person on the whole earth seeing the big > difference in easy setup of mirroring two drives instead of many > individual partitions? Sorry, I wasnt suggesting that you should always mirror the indiviudual partititons - just I happen to do that where I am mixing ZFS and gmirror. Obviosuly you dont want to create lots of little mirrors if you dont have to. But even with one mirror, you can mirror a big partiton covering the whole drive, and then carve that up with bsdlabel. No need to ever mirror the actual raw discs, and it works with GPT. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 18:04:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAAC1106567A; Fri, 17 Feb 2012 18:04:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4AC8FC21; Fri, 17 Feb 2012 18:04:51 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1HI4na8027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 10:04:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3E971E.6070204@freebsd.org> Date: Fri, 17 Feb 2012 10:06:22 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: davidxu@freebsd.org References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org> <4F3DA27A.3090903@freebsd.org> <4F3DB3DB.2060603@gmail.com> <4F3DB91A.2090806@freebsd.org> <4F3DBE90.5030305@gmail.com> <4F3E04AB.2000508@freebsd.org> <4F3E0A90.6080400@freebsd.org> <4F3E39EF.3030209@gmail.com> In-Reply-To: <4F3E39EF.3030209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , Alexander Kabaev , Andriy Gapon , threads@freebsd.org, FreeBSD Stable , Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 17 Feb 2012 18:04:51 -0000 On 2/17/12 3:28 AM, David Xu wrote: > On 2012/2/17 16:06, Julian Elischer wrote: >> On 2/16/12 11:41 PM, Julian Elischer wrote: >>> adding jkim as he seems to be the last person working with TSC. >>> >>> >>> On 2/16/12 6:42 PM, David Xu wrote: >>>> On 2012/2/17 10:19, Julian Elischer wrote: >>>>> On 2/16/12 5:56 PM, David Xu wrote: >>>>>> On 2012/2/17 8:42, Julian Elischer wrote: >>>>>>> Adding David Xu for his thoughts since he reqrote the code in >>>>>>> quesiton in revision 213098 >>>>>>> >>>>>>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>>>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>>>>>> >>>>>>>>>>> the following code (from fio-2.0.3, but its in earlier >>>>>>>>>>> code too) >>>>>>>>>>> has suddenly started misbehaving. >>>>>>>>>>> >>>>>>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>>>>>> t.tv_sec += seconds + 10; >>>>>>>>>>> >>>>>>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>>>>>> >>>>>>>>>>> while (!mutex->value&& !ret) { >>>>>>>>>>> mutex->waiters++; >>>>>>>>>>> ret = >>>>>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>>>>>> mutex->waiters--; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> if (!ret) { >>>>>>>>>>> mutex->value--; >>>>>>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It turns out that 'ret' sometimes comes back instantly (on >>>>>>>>>>> my machine) with a >>>>>>>>>>> value of 60 (ETIMEDOUT) >>>>>>>>>>> despite the fact that we set the timeout 10 seconds into >>>>>>>>>>> the future. >>>>>>>>>>> >>>>>>>>>>> Has anyone else seen anything like this? >>>>>>>>>>> (and yes the condition variable attribute have been set to >>>>>>>>>>> use the REALTIME clock). >>>>>>>>>> But why? >>>>>>>>>> >>>>>>>>>> Just a hypothesis that maybe there is some issue with time >>>>>>>>>> keeping on that system. >>>>>>>>>> How would that code work out for you with MONOTONIC? >>>>>>>>> >>>>>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and >>>>>>>>> CLOCK_MONOTONIC, and they both had the same problem.. >>>>>>>>> i.e. random early returns with ETIMEDOUT. >>>>>>>>> >>>>>>>>> I think we will try move out machine forward to a newer >>>>>>>>> -stable to see if it resolves. >>>>>>>> Kan upgraded the machine today to today's 9.x branch tip and >>>>>>>> the problem still occurs. >>>>>>>> 8.x does not have this problem. >>>>>>>> >>>>>>>> I have not got a 9-RELEASE machine to test on.. so I can not >>>>>>>> tell if this came in with the burst of stuff >>>>>>>> that came in after the 9.x branch was unfrozen after the >>>>>>>> release of 9.0. >>>>>>>> >>>>>>>> >>>>>>> >>>>>> I am trying to reproduce the problem, do you have complete >>>>>> sample code to test ? >>>>> >>>>> I'm still looking the exact set >>>>> but on my machine (4 cpus) the program from ports sysutils/fio >>>>> exhibits the problem when used with >>>>> kern.timecounter.hardware=TSC-low and with the following config >>>>> file: >>>>> >>>>> pu05 # cat config.fio >>>>> >>>>> [global] >>>>> #clocksource=cpu >>>>> direct=1 >>>>> rw=randread >>>>> bs=4096 >>>>> fill_device=1 >>>>> numjobs=16 >>>>> iodepth=16 >>>>> #ioengine=posixaio >>>>> #ioengine=psync >>>>> ioengine=psync >>>>> group_reporting >>>>> norandommap >>>>> time_based >>>>> runtime=60000 >>>>> randrepeat=0 >>>>> >>>>> [file1] >>>>> filename=/dev/ada0 >>>>> >>>>> pu05 # >>>>> pu05 # fio config.fio >>>>> fio: this platform does not support process shared mutexes, >>>>> forcing use of threads. Use the 'thread' option to get rid of >>>>> this warning. >>>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, >>>>> iodepth=16 >>>>> ... >>>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, >>>>> iodepth=16 >>>>> fio 2.0.3 >>>>> Starting 15 threads and 1 process >>>>> fio: job startup hung? exiting. >>>>> fio: 5 jobs failed to start >>>>> Segmentation fault (core dumped) >>>>> pu05# >>>>> >>>>> >>>>> The reason 5 jobs failed to start is because the parent timed >>>>> out on them immediately. >>>>> It didn't time out on 10 of them apparently. >>>>> >>>>> >>>>> if I set the timer to ACPI-fast it works as expected.. >>>> maybe following code can check to see if TSC-LOW works by let the >>>> thread run >>>> on each cpu. >>>> >>>> gettimeofday(&prev, NULL); >>>> int cpu = 0; >>>> for (;;) { >>>> cpuset_t set; >>>> cpu = ++cpu % 4; >>>> CPU_ZERO(&set); >>>> CPU_SET(cpu, &set); >>>> pthread_setaffinity_np(pthread_self(), sizeof(set), &set); >>>> gettimeofday(&cur, NULL); >>>> if ( timercmp(&prev, &cur, >=)) { >>>> abort(); >>>> } >>>> } >>>> >>>> >> >> pu05# sysctl kern.timecounter.hardware=TSC-low >> kern.timecounter.hardware: ACPI-fast -> TSC-low >> pu05# ./test >> ^C >> pu05# cat test.c >> >> #include >> #include >> #include >> #include >> >> #include >> >> main() >> { >> int cpu = 0; >> struct timeval prev, cur; >> >> gettimeofday(&prev, NULL); >> for (;;) { >> cpuset_t set; >> cpu = ++cpu % 4; >> CPU_ZERO(&set); >> CPU_SET(cpu, &set); >> pthread_setaffinity_np(pthread_self(), sizeof(set), &set); >> gettimeofday(&cur, NULL); >> if ( timercmp(&prev, &cur, >)) { >> abort(); >> } >> prev = cur; >> } >> } >> >> pu05# ./test >> >> minutes pass....... >> >> ^C >> pu05# >> >> so it looks as if the TSC is working ok.. >> I'm just going to check that the program is actually moving CPU... >> yes it is moving around but I can't tell at what speed. (according >> to top). >> >> so we are still left with a question of "where is the problem?" >> >> kernel TSC driver? >> generic gettimeofday() code? >> pthreads cond code? >> the application? >> >> > I am running the fio test on my notebook which is using TSC-low, > it is on 9.0-RC3, I can not reproduce the problem for > minutes, then I interrupt it with ctrl-c: looks mot > > http://people.freebsd.org/~davidxu/tsc_pthread/dmesg.txt > http://people.freebsd.org/~davidxu/tsc_pthread/tc.txt > http://people.freebsd.org/~davidxu/tsc_pthread/fio.txt > > looks normal to me.. I have to been able to test this on a 9-RELEASE machine.. just 9-stable.. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 18:09:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28682106564A; Fri, 17 Feb 2012 18:09:29 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 9F1D78FC0C; Fri, 17 Feb 2012 18:09:28 +0000 (UTC) Date: Fri, 17 Feb 2012 18:49:17 +0100 From: vermaden To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org X-Mailer: interia.pl/pf09 X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329500958; bh=SryWECdGWvUbfmxaVo93dEJ0eU2ybjVooud7hOM6YHo=; h=Date:From:Subject:To:X-Mailer:X-Originating-IP:Message-Id: MIME-Version:Content-Type:Content-Transfer-Encoding; b=FA14eL5cVhvKO1viBUZ89uN/5Y3h9VFU7kDefeztMNaxlM6Jj9iV9bD7OrkRV13dA teELeG2V14Y5AK3mxYk4KSiClCxc8S+BHXHmm5tOoVfvwWwnuGYFfyc1R00n8RbJx7 pylQOH1fh0260qTnhKwWx/VW5IhSugFRQjaT4DDE= Cc: Subject: devd based AUTOMOUNTER 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, 17 Feb 2012 18:09:29 -0000 Hi, I have finally made some effort on writing flexible yet very simple automou= nter for FreeBSD desktop. Feel free to submit me BUG reports ;) It currently supports these file formats: -- NTFS(rw) requires [port]sysutils/fusefs-ntfs[/port] -- FAT/FAT32 -- exFAT requires [port]sysutils/fusefs-exfat[/port] -- EXT2 -- EXT3 -- EXT4 requires [port]sysutils/fusefs-ext4fuse[/port] -- UFS (DOH!) It keeps state of the mounted devices at /var/run/automount.state and logs = all activities to /var/log/automount.log file. The place for the script is at /usr/local/sbin/automount.sh executable. The only additional configuration it requires are those lines at the end of= /etc/devd.conf file along with restarting /etc/rc.d/devd daemon. notify 200 { match "system" "DEVFS"; match "type" "CREATE"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev attach"; }; notify 200 { match "system" "DEVFS"; match "type" "DESTROY"; match "cdev" "(da|mmcsd)[0-9]+"; action "/usr/local/sbin/automount.sh $cdev detach"; }; The /usr/local/sbin/automount.sh executable is here: #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ LINE=3D$( grep -n -E "${1}$" ${2} | cut -d : -f 1 ) sed -i '' ${3}d ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -o longnames -l -L pl_PL.ISO8859-2 -D cp85= 2 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep " ${MNT} " | awk '{printf $1}' ) ${M= NT} done ;; (detach) MOUNTED=3D$( mount ) __state_lock while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNTED}" | grep -E "^${PROVIDER} " | awk '{print= $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done < ${STATE} __state_unlock __log "/dev/${1}:detach" ;; esac PS. Below are links for 'mirror' threads. http://forums.freebsd.org/showthread.php?t=3D29895 http://daemonforums.org/showthread.php?t=3D6838 Regards, vermaden --- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 19:48:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5C1D106564A for ; Fri, 17 Feb 2012 19:48:05 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 8EBB88FC1C for ; Fri, 17 Feb 2012 19:48:05 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 548F352E0B; Fri, 17 Feb 2012 19:48:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> Date: Fri, 17 Feb 2012 20:48:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58E551A9-C047-478B-883E-540DC12AE716@lassitu.de> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) 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, 17 Feb 2012 19:48:05 -0000 Am 14.02.2012 um 12:37 schrieb Alexander Leidinger: > 1 FLOWTABLE The last time I included this in a kernel it seemed to have odd effects = on TCP connections. Admittedly, that was probably two years or so ago, = and I never bothered to find out what was happening in detail. Is it = safe now? Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 20:34:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5283A1065675 for ; Fri, 17 Feb 2012 20:34:01 +0000 (UTC) (envelope-from edwinlculp@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CEB168FC17 for ; Fri, 17 Feb 2012 20:34:00 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so4533248bkc.13 for ; Fri, 17 Feb 2012 12:33:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zLC3TAtx1Ojhg7FGntdDAUf9ObNgLNtFQIOrAAygd3U=; b=i+06GKRZCJztPtddc0fgdw3xCXUvopy+3gU5vkQ9FE0199w+bx7qE6qbLHjjONkMXN WD4peN6bSbbh9l+U/Hmo3uowhhXnsu566IrpmxNCD9XN3rkM+XdhY3LMIOuRCIFhRxVA QV5jzWW44EmkDtXK/cYsfLvB2MZqjleFlVB44= MIME-Version: 1.0 Received: by 10.205.125.8 with SMTP id gq8mr4682532bkc.129.1329509319980; Fri, 17 Feb 2012 12:08:39 -0800 (PST) Received: by 10.205.115.4 with HTTP; Fri, 17 Feb 2012 12:08:39 -0800 (PST) Date: Fri, 17 Feb 2012 14:08:39 -0600 Message-ID: From: "Edwin L. Culp W." To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: The "New BSD Installer" thread has shown me that I am totally obsolete in disk partitioning. 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, 17 Feb 2012 20:34:01 -0000 I've been following the above mentioned thread because I wasn't convinced by the new bsd installer on my latest installation. Now, the problem that I am seeing is no longer the new installer but that I am obsolete in modern freebsd disk partitioning options and reliability of each. I've been doing it the same way since before "the turn of the century" (13 or 14 years). Hopefully I'm not alone. If such a thing exists, I need a howto in mixing and matching all the different partitioning options and combinations, pro's and con's, for as many modern situations as possible. Any suggestions appreciated. I did look at the handbook but it seems to have changed little and uses sysinstall for the examples at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html#SYSINSTALL-FDISK2 Thanks for any suggestions. I apologize for my ignorance. ed P.S. I have wanted to understand and try things like the following comment to the thread, but I have no idea where to begin or options for doing it. Sorry, I wasnt suggesting that you should always mirror the indiviudual partititons - just I happen to do that where I am mixing ZFS and gmirror. Obviosuly you dont want to create lots of little mirrors if you dont have to. But even with one mirror, you can mirror a big partiton covering the whole drive, and then carve that up with bsdlabel. No need to ever mirror the actual raw discs, and it works with GPT. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 20:41:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC4F1065672; Fri, 17 Feb 2012 20:41:09 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7058FC1D; Fri, 17 Feb 2012 20:41:08 +0000 (UTC) Date: Fri, 17 Feb 2012 21:41:06 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329511266; bh=ngddleKd97CoYvRfe/1NV/RUwArZ3nb7wf7lqdu+V/w=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=RJLtUwqxMALnXxOW9du9hD7jxHYCXkE7UFDX1H8B/Y37WXioL9E9iOe5zANpBL9cX RpwBkuUmh/8D7Z9t07+kwzvX3zzc/Dp3Cdx/4yf1kyt5BcmveOB5DpzAv9bnX4RSWv fcU4E/wpXU9MoIrB/KzxzkracUPuqT+lgBhTmIcg= Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER 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, 17 Feb 2012 20:41:09 -0000 I already made some changes for the 'better' ... Here is the latest version: #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}$" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -o longnames -l -L pl_PL.ISO8859-2 -D cp85= 2 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep " ${MNT} " | awk '{printf $1}' ) ${M= NT} || continue done ;; (detach) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( mount | grep -E "^${PROVIDER} " | awk '{print $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac I have made tests with 3 different USB drives, with different and same fail= esystems, connecting them all at once, disconnecting all at once, random co= nnect, disconnect etc. Currently it seems to work ok but suggestions are very welcome. > Some things to consider/test: >=20 > How do I set custom flags, like nosuid,noatime,nodev,noexec,async (or > sync) for mounts? Currently You can add these options to filesystem specific mount command, b= ut its definitely possible. > What if make a usb drive with an illegal name, existing name or other dan= gerous values? The filesystem label is not used at all, I just use device names, which are= reported by FreeBSD, so quite bulletproof here and then create appreciate = /mnt/da0s1 directories. > Can I use the automounter to either mount over another mount to > impersonate it, or can I overwrite arbitrary files or directories? I have done everything to check that and to omit that, if not, then submit = a BUG ;) Thanks for suggestions Matt. Regards, vermaden --=20 ... From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 21:20:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 511561065670 for ; Fri, 17 Feb 2012 21:20:42 +0000 (UTC) (envelope-from nzp@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by mx1.freebsd.org (Postfix) with ESMTP id 319308FC1A for ; Fri, 17 Feb 2012 21:20:42 +0000 (UTC) Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 85E1259562 for ; Fri, 17 Feb 2012 13:02:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: nzp@fulvetta.riseup.net) with ESMTPSA id 0A76E1A7 Date: Fri, 17 Feb 2012 22:02:50 +0100 From: Nikola =?utf-8?B?UGF2bG92acSH?= To: freebsd-stable@freebsd.org Message-ID: <20120217210250.GA77709@sputnjik.localdomain> Mail-Followup-To: freebsd-stable@freebsd.org References: <4F3E89E3.3060608@quip.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F3E89E3.3060608@quip.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.3 at mx1 X-Virus-Status: Clean Subject: Re: New BSD Installer 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, 17 Feb 2012 21:20:42 -0000 On Fri, Feb 17, 2012 at 06:09:55PM +0100, Miroslav Lachman wrote: > Pete French wrote: > > > >Should this not be the recommended way of doing things even for MBR > >disks ? I have a lot of machines booting from gmirror, but we always > >do it by mirroring MBR partitions (or GPT ones). I cant see why you would > >want to do it the other way round in fact. It doesnt gain you anything > >does it ? > > Yes it does? Am I the only one person on the whole earth seeing the > big difference in easy setup of mirroring two drives instead of many > individual partitions? > You are not. In fact, the current situation is ironic considering the following passage from geom(4): "Compared to traditional “volume managementâ€, GEOM differs from most and in some cases all previous implementations in the following ways: [...] " · GEOM is topologically agnostic. Most volume management implementa†tions have very strict notions of how classes can fit together, very often one fixed hierarchy is provided, for instance, subdisk - plex - volume. [...] "Fixed hierarchies are bad because they make it impossible to express the intent efficiently. In the fixed hierarchy above, it is not possible to mirror two physical disks and then partition the mirror into subdisks, instead one is forced to make subdisks on the physical volumes and to mirror these two and two, resulting in a much more complex configuration. GEOM on the other hand does not care in which order things are done, the only restriction is that cycles in the graph will not be allowed." So there, even the docs agree that mirror-partition ordering is not so outlandish as some are suggesting. IIRC, that's the way gmirror-ing is described in the Handbook as well. I would like to be understood that I didn't write this just to make a smartass comment--I understand the difficulty and that the regression is unintentional (as they all are). But on the other hand, I don't think it's now OK to just tell people something like "oh well, you are all better of with partition-mirror order anyway, problem solved". It's true that it can be better sometimes, but that's not the point. The point is, specifically, you are now forced to set up mirroring in a way that may not suit your needs or you have to start jumping through hoops (the workaround with one big GPT and bsdlabel inside that doesn't seem *too* bad though), and generally, an important aspect of GEOM is now formally broken. It must be fixed IMO, no ifs and buts, but OTOH people affected by this should also have a certain degree of patience and understanding as longs as the whole thing is not swept under the rug. -- He that is giddy thinks the world turns round. -- William Shakespeare, "The Taming of the Shrew" From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 21:39:13 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96F8B106566B; Fri, 17 Feb 2012 21:39:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8A68D8FC08; Fri, 17 Feb 2012 21:39:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA11724; Fri, 17 Feb 2012 23:39:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RyVWH-0008LJ-8O; Fri, 17 Feb 2012 23:39:09 +0200 Message-ID: <4F3EC8DD.6040500@FreeBSD.org> Date: Fri, 17 Feb 2012 23:38:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120202 Thunderbird/10.0 MIME-Version: 1.0 To: Hiroki Sato References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> In-Reply-To: <20120217.232843.2212672671663755444.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: wblock@wonkity.com, mandrews@bit0.com, 000.fbsd@quip.cz, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 21:39:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 on 17/02/2012 16:28 Hiroki Sato said the following: > Andriy Gapon wrote in <4F3E3000.9000206@FreeBSD.org>: > > av> -----BEGIN PGP SIGNED MESSAGE----- av> Hash: SHA1 av> av> on 17/02/2012 > 09:04 Hiroki Sato said the following: av> > No, the issue is our gptloader > assumes the backup header is always located av> > at the (physical) last > sector while this is not mandatory in the UEFI av> > specification. av> av> > Are you sure? > > Yes, sure. In the gm0->md0+md1 case, the last LBA of the "device" is > changed (growed in size) but they can still have a valid backup header at > "the last LBA - 1" before an attempt to grow the size of the volume as the > last paragraph of your excerpts says. If we *choose* to grow the device > size permanently, the backup header must be relocated at the new last LBA. > However, before the relocation happens, the specification says both the > primary and secondary header must be valid in the previous device size. > This is my understanding. No, not before the relocation, but before the resizing. The specification just tries to protect against unexpected situations during the resizing, which otherwise should be a quick "almost-atomic" operation. > This means software should assume the device size can grow and should not > assume the backup header is always located at the last possible LBA on the > device. If AlternateLBA does not match "the device size - 1", the software > should recognize the location of the backup header based on the information > in the primary header first. Nowhere in the specification this requirement is placed on software. The specification is quite explicit in using the word "must" when referring to the placement of the backup header at the last LBA. I don't follow your suggestion of putting FreeBSD into a position of permanently living "in the moment" between now and potentially resizing the volume in the undetermined future. And just in case: Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A September 7, 2011 says: [snip] > Two GPT Header structures are stored on the device: the primary and the > backup. The primary GPT Header must be located in LBA 1 (i.e., the second > logical block), and the backup GPT Header must be located in the last LBA > of the device. I can not see any ambiguity or openness to interpretation in this paragraph. - -- Andriy Gapon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPPsjdAAoJEHSlLSemUf4vdlgIAK+iYLdNKK+ICREBcADHwdrN vzht66LRhgghZAfiJ3ZYmWnV2dLcy1c2y676L2dRu+BKBEaS26sEKinieUAIVpaI L3H/Wer8du9ywkTzZ+wBIo6aHOhxn+/Aj7dTDr9nUj7aNBY0pQbTqNLZfqSkrrUB 2y/oy1dCrw8J4VQnRXPhsieG7e4NHVvHzKLNfT9ShduuBd8jBBPDneZvXoZcBh0z x9wDmBMshVISVz53s9mQGKQ2+nKTX9Y1dtCEHOOYmmRHWWWfFru8ABN7/F6lJA3p UPEQU6UUfIFYNKf5g4mz5pOcOMfagNFmCAlZnso/DSIV6DaGj0b4Sn/oI0hf9eM= =/R4S -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 21:50:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5754106566C; Fri, 17 Feb 2012 21:50:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id AC30C8FC08; Fri, 17 Feb 2012 21:50:10 +0000 (UTC) Received: by daec6 with SMTP id c6so4181046dae.13 for ; Fri, 17 Feb 2012 13:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QNGZf7kKO+bVyr+a6Lt4lLIJFi6TMGUKIWCSD9qawK4=; b=tJqGv5Q9+Yt8v7AJqh0pGlQv6o1LHAcn9qzNhmBGV7hlNRhN2LbGqNLDX+/IY04PZe XykkPiXeG5Ij37t0e/TEB9+c0CLw00q2y1fY4KxBhjAX6dLpIIddPXlqpOI4fbSnjQUy d6M1o/5yev9d0F/Vmdw/3Pb9GNCR9lcGx8u/4= MIME-Version: 1.0 Received: by 10.68.74.74 with SMTP id r10mr28667052pbv.83.1329515410298; Fri, 17 Feb 2012 13:50:10 -0800 (PST) Received: by 10.68.193.132 with HTTP; Fri, 17 Feb 2012 13:50:08 -0800 (PST) In-Reply-To: <4F3EC8DD.6040500@FreeBSD.org> References: <20120217.160430.406937514120319292.hrs@allbsd.org> <4F3E3000.9000206@FreeBSD.org> <20120217.232843.2212672671663755444.hrs@allbsd.org> <4F3EC8DD.6040500@FreeBSD.org> Date: Fri, 17 Feb 2012 13:50:08 -0800 Message-ID: From: Freddie Cash To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: wblock@wonkity.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, mandrews@bit0.com, freebsd@jdc.parodius.com Subject: Re: New BSD Installer 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, 17 Feb 2012 21:50:11 -0000 On Fri, Feb 17, 2012 at 1:38 PM, Andriy Gapon wrote: > And just in case: > Unified Extensible Firmware Interface Specification Version 2.3.1, Errata A > September 7, 2011 says: > [snip] >> Two GPT Header structures are stored on the device: the primary and the >> backup. The primary GPT Header must be located in LBA 1 (i.e., the second >> logical block), and the backup GPT Header must be located in the last LBA >> of the device. > > I can not see any ambiguity or openness to interpretation in this paragraph. Unless it's specified somewhere else (which is possible), in this paragraph, "device" does not necessarily mean "physical disk". "Last LBA of the device" could be interpreted as "last LBA of the GEOM provider". The beauty of GEOM is that "device" is whatever logical mapping it provides. After all, LBAs are logical addresses (it's right there in the name!), not hardwired physical sector addresses. ;) If they were hardwired, then how would internal sector remapping work? ;) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 21:59:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5BE1065678; Fri, 17 Feb 2012 21:59:07 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id F39708FC1B; Fri, 17 Feb 2012 21:59:06 +0000 (UTC) Date: Fri, 17 Feb 2012 22:59:05 +0100 From: vermaden To: freebsd-stable@FreeBSD.org X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329515945; bh=iwBGyDJMPyb9jofdjq5ClTzYd0zr8nKvv2w/c4zui+0=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=mLvHmePOdr69MXFVHNHlh4J4VnpUte6qP/lTaCOMBNOBH1OcKlkpVibczySgd1Smt tvNbDFXsFHVhYijYrFJCJiyxOqM8lF5byideaL4G9WyaED6Pjle2bV3KppjKLHkpv9 srFYBK9Q9gBN6xtSEAOc5XL/vCkCAXRidXar91U4= Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: devd based AUTOMOUNTER 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, 17 Feb 2012 21:59:07 -0000 ... even newer version, seems to have all 'problems' fixed now ;) #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} ) in (*NTFS*) __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" ;; (*FAT*) __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${MNT} __log "${I}:mount (fat)" ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${O} count=3D1 | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 23:22:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE571065675; Fri, 17 Feb 2012 23:22:53 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 77BA28FC24; Fri, 17 Feb 2012 23:22:52 +0000 (UTC) Date: Sat, 18 Feb 2012 00:22:50 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EA8F6.6040702@gmail.com> References: <4F3EA8F6.6040702@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329520970; bh=Rq6BOSYujGFJ8d36cubqzTWHDdqUc9jlNJzsPyRAEeU=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=qQS11x1NTDbiTgiUDgXh2XRAtj59iVXJbl+AJ4nEYv5/7uykoW+JBHHSIZwDlPVAx CaEkADmIic4Na8nOVznApAZvTez2pHethx4hqkR31aT7Q3MxMAw4qngviCh2jfb5Dh aj0LvLB2flxOv0ClOjXKkmRBpqHTtmwa+pKy/lYw= Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER 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, 17 Feb 2012 23:22:53 -0000 Latest version with additional checks for NTFS and FAT32, to be precise, for NTFS filesystem with label "FAT" and for FAT filesystem with label "NTF= S" ;) #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"/mnt/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | head -1 \ | grep -q "NTFS" && { __create_mount_point ${I} ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ __log "${I}:mount (ntfs)" } ;; (*FAT*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | grep -q "FAT32" && { __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${= MNT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" ;; esac From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 00:11:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5862106564A; Sat, 18 Feb 2012 00:11:22 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 86E128FC1C; Sat, 18 Feb 2012 00:11:22 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAD3sPk+DaFvO/2dsb2JhbABDFoUCrhaBdQEBAQMBAQEBICsgCwUWDgoCAg0ZAikBCSYGCAcEARwEh18JrAGKCoEviBGCOAEDBgwMBAMOAgICEAgCAgIDCREDgxEBA1CCNoEWBIhOikGCKJMHgT4 X-IronPort-AV: E=Sophos;i="4.73,441,1325480400"; d="scan'208";a="160070978" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 17 Feb 2012 19:11:21 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 564F3B404F; Fri, 17 Feb 2012 19:11:21 -0500 (EST) Date: Fri, 17 Feb 2012 19:11:21 -0500 (EST) From: Rick Macklem To: Giulio Ferro Message-ID: <1210936597.1596873.1329523881317.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F3E87A2.80000@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kerberized NFS 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, 18 Feb 2012 00:11:23 -0000 Giulio Ferro wrote: > Thanks everybody again for your help with setting up a working > kerberized nfsv4 system. > > I was able to user-mount a nfsv4 share with krb5 security, and I was > trying to do the same as root. > > Unfortunately the patch I found here: > http://people.freebsd.org/~rmacklem/rpcsec_gss.patch > > fails to apply cleanly on a 9 stable system. > I'll try and generate an updated patch. I guess some commit has changed the code enough that "patch" gets confused and it's a little big to do the patch manually. (I'm pretty sure any changes done to the sys/rpc/rpcsec_gss code hasn't broken the patch, but I have no way of doing Kerberos testing these days.) > Is there a more recent patch available or some better way to > automatically > mount the share at boot time? > > Thanks again. > _______________________________________________ > 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 Feb 18 01:27:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5731106564A for ; Sat, 18 Feb 2012 01:27:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 376828FC08 for ; Sat, 18 Feb 2012 01:27:54 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1I1RmQC032868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2012 03:27:48 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1I1RlQf028215; Sat, 18 Feb 2012 03:27:47 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1I1RlW2028214; Sat, 18 Feb 2012 03:27:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 18 Feb 2012 03:27:47 +0200 From: Konstantin Belousov To: Paul Mather Message-ID: <20120218012746.GA3283@deviant.kiev.zoral.com.ua> References: <20120215004753.GQ3283@deviant.kiev.zoral.com.ua> <8F48D496-59BD-431D-B7F1-962A79C7ACC5@gromit.dlib.vt.edu> <20120216154932.GM3283@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QJ8Fh8pYRWS0QZcB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 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: ZFS + nullfs + Linuxulator = 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: Sat, 18 Feb 2012 01:27:55 -0000 --QJ8Fh8pYRWS0QZcB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 12:07:46PM -0500, Paul Mather wrote: > On Feb 16, 2012, at 10:49 AM, Konstantin Belousov wrote: >=20 > > On Thu, Feb 16, 2012 at 10:09:27AM -0500, Paul Mather wrote: > >> On Feb 14, 2012, at 7:47 PM, Konstantin Belousov wrote: > >>=20 > >>> On Tue, Feb 14, 2012 at 09:38:18AM -0500, Paul Mather wrote: > >>>> I have a problem with RELENG_8 (FreeBSD/amd64 running a GENERIC kern= el, last built 2012-02-08). It will panic during the daily periodic script= s that run at 3am. Here is the most recent panic message: > >>>>=20 > >>>> Fatal trap 9: general protection fault while in kernel mode > >>>> cpuid =3D 0; apic id =3D 00 > >>>> instruction pointer =3D 0x20:0xffffffff8069d266 > >>>> stack pointer =3D 0x28:0xffffff8094b90390 > >>>> frame pointer =3D 0x28:0xffffff8094b903a0 > >>>> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >>>> processor eflags =3D resume, IOPL =3D 0 > >>>> current process =3D 72566 (ps) > >>>> trap number =3D 9 > >>>> panic: general protection fault > >>>> cpuid =3D 0 > >>>> KDB: stack backtrace: > >>>> #0 0xffffffff8062cf8e at kdb_backtrace+0x5e > >>>> #1 0xffffffff805facd3 at panic+0x183 > >>>> #2 0xffffffff808e6c20 at trap_fatal+0x290 > >>>> #3 0xffffffff808e715a at trap+0x10a > >>>> #4 0xffffffff808cec64 at calltrap+0x8 > >>>> #5 0xffffffff805ee034 at fill_kinfo_thread+0x54 > >>>> #6 0xffffffff805eee76 at fill_kinfo_proc+0x586 > >>>> #7 0xffffffff805f22b8 at sysctl_out_proc+0x48 > >>>> #8 0xffffffff805f26c8 at sysctl_kern_proc+0x278 > >>>> #9 0xffffffff8060473f at sysctl_root+0x14f > >>>> #10 0xffffffff80604a2a at userland_sysctl+0x14a > >>>> #11 0xffffffff80604f1a at __sysctl+0xaa > >>>> #12 0xffffffff808e62d4 at amd64_syscall+0x1f4 > >>>> #13 0xffffffff808cef5c at Xfast_syscall+0xfc > >>>=20 > >>> Please look up the line number for the fill_kinfo_thread+0x54. > >>=20 > >>=20 > >> Is there a way for me to do this from the above information? As > >> I said in the original message, I failed to get a crash dump after > >> reboot (because, it turns out, I hadn't set up my gmirror swap device > >> properly). Alas, with the latest panic, it appears to have hung[1] > >> during the "Dumping" phase, so it looks like I won't get a saved crash > >> dump this time, either. :-( > >=20 > > Load the kernel.debug into kgdb, and from there do > > "list *fill_kinfo_thread+0x54". >=20 >=20 > gromit# kgdb /usr/obj/usr/src/sys/GENERIC/kernel.debug > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... > (kgdb) list *fill_kinfo_thread+0x54 > 0xffffffff805ee034 is in fill_kinfo_thread (/usr/src/sys/kern/kern_proc.c= :854). > 849 thread_lock(td); > 850 if (td->td_wmesg !=3D NULL) > 851 strlcpy(kp->ki_wmesg, td->td_wmesg, sizeof(kp->ki= _wmesg)); > 852 else > 853 bzero(kp->ki_wmesg, sizeof(kp->ki_wmesg)); > 854 strlcpy(kp->ki_ocomm, td->td_name, sizeof(kp->ki_ocomm)); > 855 if (TD_ON_LOCK(td)) { > 856 kp->ki_kiflag |=3D KI_LOCKBLOCK; > 857 strlcpy(kp->ki_lockname, td->td_lockname, > 858 sizeof(kp->ki_lockname)); > (kgdb)=20 This is indeed strange. It can only occur if td pointer is damaged. Please, try to get a core and at least print the content of *td in this cas= e. --QJ8Fh8pYRWS0QZcB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8+/pIACgkQC3+MBN1Mb4h16QCeNKaul23WwziJMvi+WuqkPZD4 K64AoL3+hOqkdstuY7NUqWCmYeEkfgrq =W/BX -----END PGP SIGNATURE----- --QJ8Fh8pYRWS0QZcB-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 01:28:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 999931065677; Sat, 18 Feb 2012 01:28:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 53E258FC23; Sat, 18 Feb 2012 01:28:58 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1I1Sv5F028778 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 17:28:58 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3EFF35.8040901@freebsd.org> Date: Fri, 17 Feb 2012 17:30:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Jung-uk Kim References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3E0A90.6080400@freebsd.org> <4F3E39EF.3030209@gmail.com> <201202171117.46626.jkim@FreeBSD.org> In-Reply-To: <201202171117.46626.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Kabaev , "threads@freebsd.org" , FreeBSD Stable , "davidxu@freebsd.org" , Andriy Gapon Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) 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, 18 Feb 2012 01:28:59 -0000 > On Friday 17 February 2012 06:28 am, David Xu wrote: >> On 2012/2/17 16:06, Julian Elischer wrote: >>> On 2/16/12 11:41 PM, Julian Elischer wrote: >>>> adding jkim as he seems to be the last person working with TSC. >>>> >>>> On 2/16/12 6:42 PM, David Xu wrote: >>>>> On 2012/2/17 10:19, Julian Elischer wrote: >>>>>> On 2/16/12 5:56 PM, David Xu wrote: >>>>>>> On 2012/2/17 8:42, Julian Elischer wrote: >>>>>>>> Adding David Xu for his thoughts since he reqrote the code >>>>>>>> in quesiton in revision 213098 >>>>>>>> >>>>>>>> On 2/16/12 2:57 PM, Julian Elischer wrote: >>>>>>>>> On 2/16/12 1:06 PM, Julian Elischer wrote: >>>>>>>>>> On 2/16/12 9:34 AM, Andriy Gapon wrote: >>>>>>>>>>> on 15/02/2012 23:41 Julian Elischer said the following: >>>>>>>>>>>> The program fio (an IO test in ports) uses pthreads >>>>>>>>>>>> >>>>>>>>>>>> the following code (from fio-2.0.3, but its in earlier >>>>>>>>>>>> code too) has suddenly started misbehaving. >>>>>>>>>>>> >>>>>>>>>>>> clock_gettime(CLOCK_REALTIME,&t); >>>>>>>>>>>> t.tv_sec += seconds + 10; >>>>>>>>>>>> >>>>>>>>>>>> pthread_mutex_lock(&mutex->lock); >>>>>>>>>>>> >>>>>>>>>>>> while (!mutex->value&& !ret) { >>>>>>>>>>>> mutex->waiters++; >>>>>>>>>>>> ret = >>>>>>>>>>>> pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t); >>>>>>>>>>>> mutex->waiters--; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> if (!ret) { >>>>>>>>>>>> mutex->value--; >>>>>>>>>>>> pthread_mutex_unlock(&mutex->lock); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It turns out that 'ret' sometimes comes back instantly >>>>>>>>>>>> (on my machine) with a >>>>>>>>>>>> value of 60 (ETIMEDOUT) >>>>>>>>>>>> despite the fact that we set the timeout 10 seconds into >>>>>>>>>>>> the future. >>>>>>>>>>>> >>>>>>>>>>>> Has anyone else seen anything like this? >>>>>>>>>>>> (and yes the condition variable attribute have been set >>>>>>>>>>>> to use the REALTIME clock). >>>>>>>>>>> But why? >>>>>>>>>>> >>>>>>>>>>> Just a hypothesis that maybe there is some issue with >>>>>>>>>>> time keeping on that system. >>>>>>>>>>> How would that code work out for you with MONOTONIC? >>>>>>>>>> Jens Axboe, (CC'd) tried both CLOCK_REALTIME and >>>>>>>>>> CLOCK_MONOTONIC, and they both had the same problem.. >>>>>>>>>> i.e. random early returns with ETIMEDOUT. >>>>>>>>>> >>>>>>>>>> I think we will try move out machine forward to a newer >>>>>>>>>> -stable to see if it resolves. >>>>>>>>> Kan upgraded the machine today to today's 9.x branch tip >>>>>>>>> and the problem still occurs. >>>>>>>>> 8.x does not have this problem. >>>>>>>>> >>>>>>>>> I have not got a 9-RELEASE machine to test on.. so I can >>>>>>>>> not tell if this came in with the burst of stuff >>>>>>>>> that came in after the 9.x branch was unfrozen after the >>>>>>>>> release of 9.0. >>>>>>> I am trying to reproduce the problem, do you have complete >>>>>>> sample code to test ? >>>>>> I'm still looking the exact set >>>>>> but on my machine (4 cpus) the program from ports sysutils/fio >>>>>> exhibits the problem when used with >>>>>> kern.timecounter.hardware=TSC-low and with the following >>>>>> config file: >>>>>> >>>>>> pu05 # cat config.fio >>>>>> >>>>>> [global] >>>>>> #clocksource=cpu >>>>>> direct=1 >>>>>> rw=randread >>>>>> bs=4096 >>>>>> fill_device=1 >>>>>> numjobs=16 >>>>>> iodepth=16 >>>>>> #ioengine=posixaio >>>>>> #ioengine=psync >>>>>> ioengine=psync >>>>>> group_reporting >>>>>> norandommap >>>>>> time_based >>>>>> runtime=60000 >>>>>> randrepeat=0 >>>>>> >>>>>> [file1] >>>>>> filename=/dev/ada0 >>>>>> >>>>>> pu05 # >>>>>> pu05 # fio config.fio >>>>>> fio: this platform does not support process shared mutexes, >>>>>> forcing use of threads. Use the 'thread' option to get rid of >>>>>> this warning. file1: (g=0): rw=randread, bs=4K-4K/4K-4K, >>>>>> ioengine=psync, iodepth=16 ... >>>>>> file1: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=psync, >>>>>> iodepth=16 fio 2.0.3 >>>>>> Starting 15 threads and 1 process >>>>>> fio: job startup hung? exiting. >>>>>> fio: 5 jobs failed to start >>>>>> Segmentation fault (core dumped) >>>>>> pu05# >>>>>> >>>>>> >>>>>> The reason 5 jobs failed to start is because the parent timed >>>>>> out on them immediately. >>>>>> It didn't time out on 10 of them apparently. >>>>>> >>>>>> >>>>>> if I set the timer to ACPI-fast it works as expected.. >>>>> maybe following code can check to see if TSC-LOW works by let >>>>> the thread run >>>>> on each cpu. >>>>> >>>>> gettimeofday(&prev, NULL); >>>>> int cpu = 0; >>>>> for (;;) { >>>>> cpuset_t set; >>>>> cpu = ++cpu % 4; >>>>> CPU_ZERO(&set); >>>>> CPU_SET(cpu,&set); >>>>> pthread_setaffinity_np(pthread_self(), sizeof(set),&set); >>>>> gettimeofday(&cur, NULL); >>>>> if ( timercmp(&prev,&cur,>=)) { >>>>> abort(); >>>>> } >>>>> } >>> pu05# sysctl kern.timecounter.hardware=TSC-low >>> kern.timecounter.hardware: ACPI-fast -> TSC-low >>> pu05# ./test >>> ^C >>> pu05# cat test.c >>> >>> #include >>> #include >>> #include >>> #include >>> >>> #include >>> >>> main() >>> { >>> int cpu = 0; >>> struct timeval prev, cur; >>> >>> gettimeofday(&prev, NULL); >>> for (;;) { >>> cpuset_t set; >>> cpu = ++cpu % 4; >>> CPU_ZERO(&set); >>> CPU_SET(cpu,&set); >>> pthread_setaffinity_np(pthread_self(), sizeof(set), >>> &set); gettimeofday(&cur, NULL); >>> if ( timercmp(&prev,&cur,>)) { >>> abort(); >>> } >>> prev = cur; >>> } >>> } >>> >>> pu05# ./test >>> >>> minutes pass....... >>> >>> ^C >>> pu05# >>> >>> so it looks as if the TSC is working ok.. >>> I'm just going to check that the program is actually moving >>> CPU... yes it is moving around but I can't tell at what speed. >>> (according to top). >>> >>> so we are still left with a question of "where is the problem?" >>> >>> kernel TSC driver? >>> generic gettimeofday() code? >>> pthreads cond code? >>> the application? >> I am running the fio test on my notebook which is using TSC-low, >> it is on 9.0-RC3, I can not reproduce the problem for >> minutes, then I interrupt it with ctrl-c: >> >> http://people.freebsd.org/~davidxu/tsc_pthread/dmesg.txt >> http://people.freebsd.org/~davidxu/tsc_pthread/tc.txt >> http://people.freebsd.org/~davidxu/tsc_pthread/fio.txt > Your CPU is single-package, dual-core, and SMT-enabled. All cores > should be in perfect sync. > > Jung-uk Kim > mine is too, yet it still has problems.. CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8214368256 (7833 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 03:13:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E59106566B; Sat, 18 Feb 2012 03:13:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AE0048FC0A; Sat, 18 Feb 2012 03:13:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACMXP0+DaFvO/2dsb2JhbABEFoR+rhWBdQEBAQMBAQEBICsgCwUWDgoCAg0ZAikBCSYGCAcEARwEh18JpwWRbYEviBGCOAEDEgwEAw4CAgIQCAICAgMJEQODEQEDUII2gRYEiE6KQYIokweBPg X-IronPort-AV: E=Sophos;i="4.73,441,1325480400"; d="scan'208";a="156964496" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 17 Feb 2012 22:13:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 7E773B3EB2; Fri, 17 Feb 2012 22:13:48 -0500 (EST) Date: Fri, 17 Feb 2012 22:13:48 -0500 (EST) From: Rick Macklem To: Giulio Ferro Message-ID: <1224440280.1601713.1329534828468.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4F3E87A2.80000@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: kerberized NFS 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, 18 Feb 2012 03:13:50 -0000 Giulio Ferro wrote: > Thanks everybody again for your help with setting up a working > kerberized nfsv4 system. > > I was able to user-mount a nfsv4 share with krb5 security, and I was > trying to do the same as root. > > Unfortunately the patch I found here: > http://people.freebsd.org/~rmacklem/rpcsec_gss.patch > > fails to apply cleanly on a 9 stable system. > There is now a patch called: http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch that should apply to a FreeBSD9 or later kernel. For the kernel to build after applying the patch, you will need a kernel config with options KGSSAPI in it, since the patch adds a function that can't be called via one of the XXX_call() functions using the function pointers. Also, review the section of the wiki where it discusses setting vfs.rpcsec.keytab_enctype because the host based initiator keytab entry won't work unless it is set correctly. Good luck with it, rick > Is there a more recent patch available or some better way to > automatically > mount the share at boot time? > > Thanks again. > _______________________________________________ > 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 Feb 18 05:47:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01691106564A; Sat, 18 Feb 2012 05:47:10 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C0A7A8FC14; Sat, 18 Feb 2012 05:47:09 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1I5l5uh054728; Sat, 18 Feb 2012 05:47:07 GMT (envelope-from listlog2011@gmail.com) Message-ID: <4F3F3B57.5070700@gmail.com> Date: Sat, 18 Feb 2012 13:47:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3E0A90.6080400@freebsd.org> <4F3E39EF.3030209@gmail.com> <201202171117.46626.jkim@FreeBSD.org> <4F3EFF35.8040901@freebsd.org> In-Reply-To: <4F3EFF35.8040901@freebsd.org> Content-Type: multipart/mixed; boundary="------------040401090208010403080104" Cc: FreeBSD Stable , Alexander Kabaev , Andriy Gapon , "davidxu@freebsd.org" , "threads@freebsd.org" , Jung-uk Kim Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 05:47:10 -0000 This is a multi-part message in MIME format. --------------040401090208010403080104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012/2/18 9:30, Julian Elischer wrote: >> > > mine is too, yet it still has problems.. > CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2500.14-MHz > K8-class CPU) > Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 > Stepping = 6 > > Features=0xbfebfbff > > Features2=0xce3bd > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8214368256 (7833 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > > Attached file is a small patch, don't know if it works for you, I can only find this at the moment. --------------040401090208010403080104 Content-Type: text/plain; name="thr_umtx.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="thr_umtx.c.diff" Index: src/lib/libthr/thread/thr_umtx.c =================================================================== --- src/lib/libthr/thread/thr_umtx.c (revision 231637) +++ src/lib/libthr/thread/thr_umtx.c (working copy) @@ -205,7 +205,7 @@ if (abstime != NULL) { clock_gettime(clockid, &ts); TIMESPEC_SUB(&ts2, abstime, &ts); - if (ts2.tv_sec < 0 || ts2.tv_nsec <= 0) + if (ts2.tv_sec < 0 || (ts2.tv_sec == 0 && ts2.tv_nsec <= 0)) return (ETIMEDOUT); tsp = &ts2; } else { --------------040401090208010403080104-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 09:48:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2E1106566C; Sat, 18 Feb 2012 09:48:13 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id A2D458FC08; Sat, 18 Feb 2012 09:48:12 +0000 (UTC) Date: Sat, 18 Feb 2012 10:48:11 +0100 From: vermaden To: matt X-Mailer: interia.pl/pf09 In-Reply-To: <4F3EE186.4020801@gmail.com> References: <4F3EA8F6.6040702@gmail.com> <4F3EE186.4020801@gmail.com> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1329558491; bh=sKfXBtqP9LdO6CuRPV5e5Ua4y5ZYmcz6EfXzdGSTKuw=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=e6pI6h6g0szgcJb+xNL8Q2b6JgQxK7eZNNygrz+LHa2imaGrd/xc8UWDh7gCe7DXK S+ER3am4a+hOvmVt/BdCbJv2WJI7hl2jZ4Qt7qtczSjsmzLovLIuplYQSvu/lGmTjT /Y2a3P5ZuS7pswlnRXMM0IC+6GUHLdudaoqvTDYQ= Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER 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, 18 Feb 2012 09:48:13 -0000 Added a check if ntfs-3g is available, if not then mount_ntfs is used inste= ad. Added deleting of empty directories at ${MNTPREFIX}. Added ${MNTPREFIX} to be set to /mnt or /media according to preference #! /bin/sh PATH=3D/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin MNTPREFIX=3D"/media" LOG=3D"/var/log/automount.log" STATE=3D"/var/run/automount.state" DATEFMT=3D"%Y-%m-%d %H:%M:%S" __create_mount_point() { # /* 1=3DDEV */ MNT=3D"${MNTPREFIX}/$( basename ${1} )" mkdir -p ${MNT} } __state_lock() { while [ -f ${STATE}.lock ]; do sleep 0.5; done :> ${STATE}.lock } __state_unlock() { rm ${STATE}.lock } __state_add() { # /* 1=3DDEV 2=3DPROVIDER 3=3DMNT */ __state_lock grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { __log "${1}:duplicated '${STATE}'" return 1 } echo "${1} ${2} ${3}" >> ${STATE} __state_unlock } __state_remove() { # /* 1=3DMNT 2=3DSTATE 3=3DLINE */ BSMNT=3D$( echo ${1} | sed 's/\//\\\//g' ) sed -i '' "/${BSMNT}\$/d" ${2} } __log() { # /* @=3DMESSAGE */ echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} } case ${2} in (attach) for I in /dev/${1}* do case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in (*NTFS*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | head -1 \ | grep -q "NTFS" && { __create_mount_point ${I} which ntfs-3g 1> /dev/null 2> /dev/null && { ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ } || { mount_ntfs ${I} ${MNT} } __log "${I}:mount (ntfs)" } ;; (*FAT*) dd < ${I} count=3D1 2> /dev/null \ | strings \ | grep -q "FAT32" && { __create_mount_point ${I} fsck_msdosfs -y ${I} mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${= MNT} __log "${I}:mount (fat)" } ;; (*ext2*) __create_mount_point ${I} fsck.ext2 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext2)" ;; (*ext3*) __create_mount_point ${I} fsck.ext3 -y ${I} mount -t ext2fs ${I} ${MNT} __log "${I}:mount (ext3)" ;; (*ext4*) __create_mount_point ${I} fsck.ext4 -y ${I} ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ __log "${I}:mount (ext4)" ;; (*Unix\ Fast\ File*) __create_mount_point ${I} fsck_ufs -y ${I} mount ${I} ${MNT} __log "${I}:mount (ufs)" ;; (*) case $( dd < ${I} count=3D1 2> /dev/null | strings | head -1 ) in (EXFAT) __create_mount_point ${I} mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ __log "${I}:mount (ufs)" ;; (*) continue ;; esac ;; esac __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' = ) \ ${MNT} || continue done ;; (detach) MOUNT=3D$( mount ) __state_lock grep ${1} ${STATE} \ | while read DEV PROVIDER MNT do TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{pri= nt $3}' ) [ -z ${TARGET} ] && { __state_remove ${MNT} ${STATE} ${LINE} continue } umount -f ${TARGET} & unset TARGET __state_remove ${MNT} ${STATE} ${LINE} __log "${DEV}:umount" done __state_unlock __log "/dev/${1}:detach" find ${MNTPREFIX} -type d -empty -delete ;; esac > Not sure if you've looked at disktype in sysutils > but it may be useful to you. I will get look into that, thanks ;) > Neat scripts! > Matt Thanks mate. Regards, vermaden --=20 ... From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 12:42:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEE501065676 for ; Sat, 18 Feb 2012 12:42:02 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 19D1C8FC14 for ; Sat, 18 Feb 2012 12:42:01 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.3]) by msrv.matik.com.br (8.14.5/8.14.2) with ESMTP id q1IBhRTR009872 for ; Sat, 18 Feb 2012 09:43:27 -0200 (BRST) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1329565407; bh=xw51ALee9xmFiWgk2VU6Nzp74CL7d6GNyKtKP9i9xK8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=aTyDdwdhDX61TegsJB7IZQxaoMeInAUzovhysecdhx40wJGW2eiINqTTbaFoAh2n/ ssD0bANLJnBGs+/XHhdblKBJhHr4K/im0otmuj3T2qCyQv3kauaH6yTdbGiKbROW+5 pPTiurSUHp1EgJglZ4aZceKXH32dnPmmtBxY7KW4= DomainKey-Signature: a=rsa-sha1; s=default; d=hm.net.br; c=nofws; q=dns; h=authentication-results:message-id:date:from:user-agent: mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type; b=mj1NNu95tMB06YHSqTUsiltp4txn1NjstP7rmzjjeCGgEev5n4cgn4h+rsESpIQFY 6QwaGvXQURHn7VWhaRYED732VVChaFdKdnEY1hVph9zv/OeBpmldqUCFNvNHaV9hEOz Z4FZ4E9pwg0FQFbOecrBn+9hnAB7J/5LbH2WhLY= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F3F8F0C.3000606@hm.net.br> Date: Sat, 18 Feb 2012 09:44:12 -0200 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> In-Reply-To: <20120214200258.GA29641@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFD54DD8ACB13E9DE1172A4FD" X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2-dcmatik_hm_4.18.a X-Spam-Checker-Version: SpamAssassin 3.3.2-dcmatik_hm_4.18.a (2011-06-06) on msrv.matik.com.br Subject: disk access seems unitask and ant-slow 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, 18 Feb 2012 12:42:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD54DD8ACB13E9DE1172A4FD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi I have 9-Stable on one partition of my SATAII disk, with kde4, to be sure I compiled yesterday sources world and kernel happens that any secondary task with diskaccess is so very slow that it is inacceptable for example, compiling firefox and then trying to open an image with gimp, I am sitting here for over 5 minutes and the open image dialog still do not show the directory content ..., same with dolphin or any other diskaccess I have enough cpu and ram, I go back to 8.2 and everything runs smooth and fast as usual, same on fedora10 partition my disk is good and found as ada, no fault anywhere system is almost sleeping CPU: 2.6% user, 0.0% nice, 3.6% system, 1.3% interrupt, 92.5% idle I would be glad to get any good hint how to change that thank's --=20 H +55 (17) 4141.2222 --------------enigFD54DD8ACB13E9DE1172A4FD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8/jxcACgkQvKVfg5xjCDw8bgCfX3XkQ6NhnGSDkFUBAuRMxsBm x/sAn0uLw17d/Wu40iEYm4qnoLd8v2YC =vshB -----END PGP SIGNATURE----- --------------enigFD54DD8ACB13E9DE1172A4FD-- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 13:15:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 376A3106566C for ; Sat, 18 Feb 2012 13:15:28 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.78]) by mx1.freebsd.org (Postfix) with ESMTP id DA67F8FC12 for ; Sat, 18 Feb 2012 13:15:27 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Ryk8L-0005TZ-Cu for freebsd-stable@freebsd.org; Sat, 18 Feb 2012 14:15:25 +0100 Received: from dhcp-077-251-052-224.chello.nl ([77.251.52.224] helo=pinky) by smtp.greenhost.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Ryk8L-00078s-PL for freebsd-stable@freebsd.org; Sat, 18 Feb 2012 14:15:25 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> <4F3F8F0C.3000606@hm.net.br> Date: Sat, 18 Feb 2012 14:15:27 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: <4F3F8F0C.3000606@hm.net.br> User-Agent: Opera Mail/11.61 (Win32) X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.0 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=disabled version=3.2.5 X-Scan-Signature: 9090f8a1960d7f777b94d17b6f36e747 Subject: Re: disk access seems unitask and ant-slow 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, 18 Feb 2012 13:15:28 -0000 On Sat, 18 Feb 2012 12:44:12 +0100, H wrote: > Hi > > I have 9-Stable on one partition of my SATAII disk, with kde4, to be > sure I compiled yesterday sources world and kernel > > happens that any secondary task with diskaccess is so very slow that it > is inacceptable > > for example, compiling firefox and then trying to open an image with > gimp, I am sitting here for over 5 minutes and the open image dialog > still do not show the directory content ..., same with dolphin or any > other diskaccess > > I have enough cpu and ram, I go back to 8.2 and everything runs smooth > and fast as usual, same on fedora10 partition > > my disk is good and found as ada, no fault anywhere > > system is almost sleeping > CPU: 2.6% user, 0.0% nice, 3.6% system, 1.3% interrupt, 92.5% idle > > > I would be glad to get any good hint how to change that > > > > thank's Please post the output of dmesg so people have some information about your system. And /etc/sysctl.conf, /boot/loader.conf and the output of 'mount -v' are interesting also. Ronald. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 13:21:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB2F1065674 for ; Sat, 18 Feb 2012 13:21:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.c2i.net [212.247.154.2]) by mx1.freebsd.org (Postfix) with ESMTP id 152008FC12 for ; Sat, 18 Feb 2012 13:20:59 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.208.111] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe01.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 243331715; Sat, 18 Feb 2012 14:10:56 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Sat, 18 Feb 2012 14:09:08 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <4F3EE186.4020801@gmail.com> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202181409.08859.hselasky@c2i.net> Cc: matt , vermaden , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: devd based AUTOMOUNTER 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, 18 Feb 2012 13:21:00 -0000 On Saturday 18 February 2012 10:48:11 vermaden wrote: > Added a check if ntfs-3g is available, if not then mount_ntfs is used > instead. Added deleting of empty directories at ${MNTPREFIX}. > Added ${MNTPREFIX} to be set to /mnt or /media according to preference > > #! /bin/sh > > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > DATEFMT="%Y-%m-%d %H:%M:%S" > > __create_mount_point() { # /* 1=DEV */ > MNT="${MNTPREFIX}/$( basename ${1} )" > mkdir -p ${MNT} > } > > __state_lock() { > while [ -f ${STATE}.lock ]; do sleep 0.5; done > > :> ${STATE}.lock > > } > > __state_unlock() { > rm ${STATE}.lock > } > > __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */ > __state_lock > grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { > __log "${1}:duplicated '${STATE}'" > return 1 > } > echo "${1} ${2} ${3}" >> ${STATE} > __state_unlock > } > > __state_remove() { # /* 1=MNT 2=STATE 3=LINE */ > BSMNT=$( echo ${1} | sed 's/\//\\\//g' ) > sed -i '' "/${BSMNT}\$/d" ${2} > } > > __log() { # /* @=MESSAGE */ > echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} > } > > case ${2} in > (attach) > for I in /dev/${1}* > do > case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in > (*NTFS*) > dd < ${I} count=1 2> /dev/null \ > > | strings \ > | head -1 \ > | grep -q "NTFS" && { > > __create_mount_point ${I} > which ntfs-3g 1> /dev/null 2> /dev/null && { > ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > } || { > mount_ntfs ${I} ${MNT} > } > __log "${I}:mount (ntfs)" > } > ;; > (*FAT*) > dd < ${I} count=1 2> /dev/null \ > > | strings \ > | grep -q "FAT32" && { > > __create_mount_point ${I} > fsck_msdosfs -y ${I} > mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} > ${MNT} __log "${I}:mount (fat)" > } > ;; > (*ext2*) > __create_mount_point ${I} > fsck.ext2 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext2)" > ;; > (*ext3*) > __create_mount_point ${I} > fsck.ext3 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext3)" > ;; > (*ext4*) > __create_mount_point ${I} > fsck.ext4 -y ${I} > ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > __log "${I}:mount (ext4)" > ;; > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} > mount ${I} ${MNT} > __log "${I}:mount (ufs)" > ;; > (*) > case $( dd < ${I} count=1 2> /dev/null | strings | head -1 ) in > (EXFAT) > __create_mount_point ${I} > mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > __log "${I}:mount (ufs)" > ;; > (*) continue ;; > esac > ;; > esac > __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' > ) \ ${MNT} || continue > done > ;; > > (detach) > MOUNT=$( mount ) > __state_lock > grep ${1} ${STATE} \ > > | while read DEV PROVIDER MNT > > do > TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print > $3}' ) [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done > __state_unlock > __log "/dev/${1}:detach" > find ${MNTPREFIX} -type d -empty -delete > ;; > > esac > > > Not sure if you've looked at disktype in sysutils > > but it may be useful to you. > Hi, Should your script be written like an rc.d script, so that one can enable/disable this automounting from /etc/rc.conf? --HPS From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 16:18:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358E1106566B for ; Sat, 18 Feb 2012 16:18:03 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4F08FC17 for ; Sat, 18 Feb 2012 16:18:02 +0000 (UTC) X-RZG-AUTH: :LWIKdA2leu0bPbLmhzXgqn0MTG6qiKEwQRWfNxSw4HzYIwjsnvdDt2oX8drk23muf0EHTOG56w== X-RZG-CLASS-ID: mo05 Received: from [192.168.179.39] (hmbg-5f767079.pool.mediaWays.net [95.118.112.121]) by post.strato.de (mrclete mo19) (RZmta 27.6 DYNA|AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id C03169o1IFo9yk for ; Sat, 18 Feb 2012 17:17:55 +0100 (MET) Message-ID: <4F3FCF32.7060501@brockmann-consult.de> Date: Sat, 18 Feb 2012 17:17:54 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F3E89E3.3060608@quip.cz> <20120217210250.GA77709@sputnjik.localdomain> In-Reply-To: <20120217210250.GA77709@sputnjik.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: New BSD Installer 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, 18 Feb 2012 16:18:03 -0000 Can't you just create a slice, make a gmirror out of your slice, and then slice your mirror again? This is the way you would do it for mdadm on Linux (probably with swap outside the mirror). (and in the old days you would have 2 copies of /boot non-mirrored; dunno about today) Am 17.02.2012 22:02, schrieb Nikola Pavlović: > On Fri, Feb 17, 2012 at 06:09:55PM +0100, Miroslav Lachman wrote: >> Pete French wrote: >>> Should this not be the recommended way of doing things even for MBR >>> disks ? I have a lot of machines booting from gmirror, but we always >>> do it by mirroring MBR partitions (or GPT ones). I cant see why you would >>> want to do it the other way round in fact. It doesnt gain you anything >>> does it ? >> Yes it does? Am I the only one person on the whole earth seeing the >> big difference in easy setup of mirroring two drives instead of many >> individual partitions? >> > You are not. In fact, the current situation is ironic considering the > following passage from geom(4): > > "Compared to traditional “volume managementâ€, GEOM differs from most and > in some cases all previous implementations in the following ways: > > [...] > > " · GEOM is topologically agnostic. Most volume management implementa†> tions have very strict notions of how classes can fit together, very > often one fixed hierarchy is provided, for instance, subdisk - plex - > volume. > > [...] > > "Fixed hierarchies are bad because they make it impossible to express > the intent efficiently. In the fixed hierarchy above, it is not possible to > mirror two physical disks and then partition the mirror into subdisks, > instead one is forced to make subdisks on the physical volumes and to > mirror these two and two, resulting in a much more complex configuration. > GEOM on the other hand does not care in which order things are done, the > only restriction is that cycles in the graph will not be allowed." > > So there, even the docs agree that mirror-partition ordering is not so > outlandish as some are suggesting. IIRC, that's the way gmirror-ing is > described in the Handbook as well. > > > I would like to be understood that I didn't write this just to make a > smartass comment--I understand the difficulty and that the regression is > unintentional (as they all are). But on the other hand, I don't think > it's now OK to just tell people something like "oh well, you are all > better of with partition-mirror order anyway, problem solved". It's true > that it can be better sometimes, but that's not the point. The point > is, specifically, you are now forced to set up mirroring in a way that > may not suit your needs or you have to start jumping through hoops (the > workaround with one big GPT and bsdlabel inside that doesn't seem *too* > bad though), and generally, an important aspect of GEOM is now formally > broken. > > It must be fixed IMO, no ifs and buts, but OTOH people affected by > this should also have a certain degree of patience and understanding as > longs as the whole thing is not swept under the rug. > > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 17:28:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7044106566B; Sat, 18 Feb 2012 17:28:13 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26DEA8FC13; Sat, 18 Feb 2012 17:28:12 +0000 (UTC) Received: by lagz14 with SMTP id z14so7242037lag.13 for ; Sat, 18 Feb 2012 09:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PBKAlx46k2x4ueJrx2YXOdyrCBp8k5B/D0Kgf+gCcpE=; b=jCOyAqzwSU32DdZWGZFC+IYGnd5Cfa36GblJeBLI9P/4gErotEK0+/W1U/kZGRxdnu LfuyV0hbTaeZLlD0drdF0XBDqTIqUyGp8wgDBNRulJoqhVyPXAcrtAg8xjLksFqny+z3 4y+Lk0mUwq11RT3HYe8da0ej+YICTkiwDGzCA= Received: by 10.152.130.102 with SMTP id od6mr8395303lab.14.1329584201455; Sat, 18 Feb 2012 08:56:41 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id j4sm16417332lbf.6.2012.02.18.08.56.39 (version=SSLv3 cipher=OTHER); Sat, 18 Feb 2012 08:56:40 -0800 (PST) Date: Sat, 18 Feb 2012 18:56:51 +0200 From: Gleb Kurtsou To: vermaden Message-ID: <20120218165650.GA3552@reks> References: <4F3EA8F6.6040702@gmail.com> <4F3EE186.4020801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: matt , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Subject: Re: devd based AUTOMOUNTER 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, 18 Feb 2012 17:28:13 -0000 On (18/02/2012 10:48), vermaden wrote: > Added a check if ntfs-3g is available, if not then mount_ntfs is used instead. > Added deleting of empty directories at ${MNTPREFIX}. > Added ${MNTPREFIX} to be set to /mnt or /media according to preference > > #! /bin/sh > > PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > DATEFMT="%Y-%m-%d %H:%M:%S" > > __create_mount_point() { # /* 1=DEV */ > MNT="${MNTPREFIX}/$( basename ${1} )" > mkdir -p ${MNT} > } > > __state_lock() { > while [ -f ${STATE}.lock ]; do sleep 0.5; done > :> ${STATE}.lock > } Why not keep it stateless, unmounting by hand would kill integrity. Usage of `file` is a big security concern. I think geom config and list of mounted file systems should be sufficient for collecting information at runtime. Although it may not be that easy for disks without partitioning. I'm using a python script for mounting/unmounting removable disks, but having similar tool written in sh would be great. https://github.com/glk/mmount Thanks, Gleb. > > __state_unlock() { > rm ${STATE}.lock > } > > __state_add() { # /* 1=DEV 2=PROVIDER 3=MNT */ > __state_lock > grep -E "${3}" ${STATE} 1> /dev/null 2> /dev/null && { > __log "${1}:duplicated '${STATE}'" > return 1 > } > echo "${1} ${2} ${3}" >> ${STATE} > __state_unlock > } > > __state_remove() { # /* 1=MNT 2=STATE 3=LINE */ > BSMNT=$( echo ${1} | sed 's/\//\\\//g' ) > sed -i '' "/${BSMNT}\$/d" ${2} > } > > __log() { # /* @=MESSAGE */ > echo $( date +"${DATEFMT}" ) ${@} >> ${LOG} > } > > case ${2} in > (attach) > for I in /dev/${1}* > do > case $( file -L -s ${I} | sed -E 's/label:\ \".*\"//g' ) in > (*NTFS*) > dd < ${I} count=1 2> /dev/null \ > | strings \ > | head -1 \ > | grep -q "NTFS" && { > __create_mount_point ${I} > which ntfs-3g 1> /dev/null 2> /dev/null && { > ntfs-3g ${I} ${MNT} # /* sysutils/fusefs-ntfs */ > } || { > mount_ntfs ${I} ${MNT} > } > __log "${I}:mount (ntfs)" > } > ;; > (*FAT*) > dd < ${I} count=1 2> /dev/null \ > | strings \ > | grep -q "FAT32" && { > __create_mount_point ${I} > fsck_msdosfs -y ${I} > mount_msdosfs -o large -l -L pl_PL.ISO8859-2 -D cp852 ${I} ${MNT} > __log "${I}:mount (fat)" > } > ;; > (*ext2*) > __create_mount_point ${I} > fsck.ext2 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext2)" > ;; > (*ext3*) > __create_mount_point ${I} > fsck.ext3 -y ${I} > mount -t ext2fs ${I} ${MNT} > __log "${I}:mount (ext3)" > ;; > (*ext4*) > __create_mount_point ${I} > fsck.ext4 -y ${I} > ext4fuse ${I} ${MNT} # /* sysutils/fusefs-ext4fuse */ > __log "${I}:mount (ext4)" > ;; > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} > mount ${I} ${MNT} > __log "${I}:mount (ufs)" > ;; > (*) > case $( dd < ${I} count=1 2> /dev/null | strings | head -1 ) in > (EXFAT) > __create_mount_point ${I} > mount.exfat ${I} ${MNT} # /* sysutils/fusefs-exfat */ > __log "${I}:mount (ufs)" > ;; > (*) continue ;; > esac > ;; > esac > __state_add ${I} $( mount | grep -m 1 " ${MNT} " | awk '{printf $1}' ) \ > ${MNT} || continue > done > ;; > > (detach) > MOUNT=$( mount ) > __state_lock > grep ${1} ${STATE} \ > | while read DEV PROVIDER MNT > do > TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print $3}' ) > [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done > __state_unlock > __log "/dev/${1}:detach" > find ${MNTPREFIX} -type d -empty -delete > ;; > > esac > > > > > Not sure if you've looked at disktype in sysutils > > but it may be useful to you. > > I will get look into that, thanks ;) > > > > > Neat scripts! > > Matt > > Thanks mate. > > > > Regards, > vermaden From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 17:55:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FA91065674; Sat, 18 Feb 2012 17:55:55 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2A0F38FC0C; Sat, 18 Feb 2012 17:55:54 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q1IHtR0x055181 ; Sat, 18 Feb 2012 18:55:40 +0100 (CET) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q1IHtI5t037430; Sat, 18 Feb 2012 18:55:18 +0100 (CET) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q1IHtHdr037427; Sat, 18 Feb 2012 18:55:17 +0100 (CET) (envelope-from arno) To: Martin Simmons From: "Arno J. Klaassen" References: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> Date: Sat, 18 Feb 2012 18:55:17 +0100 In-Reply-To: <201202141820.q1EIK1MP032526@higson.cam.lispworks.com> (Martin Simmons's message of "Tue\, 14 Feb 2012 18\:20\:01 GMT") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 4F3FE60F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4F3FE60F.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 9-stable : geli + one-disk ZFS fails 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, 18 Feb 2012 17:55:55 -0000 Hello, Martin Simmons writes: > Some random ideas: > > 1) Can you dd the whole of ada0s3.eli without errors? > > 2) If you scrub a few more times, does it find the same number of errors each > time and are they always in that XNAT.tar file? > > 3) Can you try zfs without geli? yeah, and it seems to rule out geli : [ splitted original /dev/ada0s3 in equally sized /dev/ada0s3 and /dev/ada0s4 ] geli init /dev/ada0s3 geli attach /dev/ada0s3 zpool create zgeli /dev/ada0s3.eli zfs create zgeli/home zfs create zgeli/home/arno zfs create zgeli/home/arno/.priv zfs create zgeli/home/arno/.scito zfs set copies=2 zgeli/home/arno/.priv zfs set atime=off zgeli [put some files on it, wait a little : ] [root@cc ~]# zpool status -v pool: zgeli state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub in progress since Sat Feb 18 17:46:54 2012 425M scanned out of 2.49G at 85.0M/s, 0h0m to go 0 repaired, 16.64% done config: NAME STATE READ WRITE CKSUM zgeli ONLINE 0 0 1 ada0s3.eli ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /zgeli/home/arno/8.0-CURRENT-200902-amd64-livefs.iso [root@cc ~]# zpool scrub -s zgeli [root@cc ~]# [then idem directly on next partition ] zpool create zgpart /dev/ada0s4 zfs create zgpart/home zfs create zgpart/home/arno zfs create zgpart/home/arno/.priv zfs create zgpart/home/arno/.scito zfs set copies=2 zgpart/home/arno/.priv zfs set atime=off zgpart [put some files on it, wait a little : ] pool: zgpart state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scan: scrub repaired 0 in 0h0m with 1 errors on Sat Feb 18 18:04:45 2012 config: NAME STATE READ WRITE CKSUM zgpart ONLINE 0 0 1 ada0s4 ONLINE 0 0 2 errors: Permanent errors have been detected in the following files: /zgpart/home/arno/.scito/ .... [root@cc ~]# I still do not particuliarly suspect the disk since I cannot reproduce similar behaviour on UFS. That said, this disk is supposed to be 'hybrid-SSD', maybe something special ZFS doesn't like ??? : ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: Serial Number 5YX0J5YD ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 GEOM: new disk ada0 Please let me know what information to provide more. Best, Arno > 4) Is the slice/partition layout definitely correct? > > __Martin > > >>>>>> On Mon, 13 Feb 2012 23:39:06 +0100, Arno J Klaassen said: >> >> hello, >> >> to eventually gain interest in this issue : >> >> I updated to today's -stable, tested with vfs.zfs.debug=1 >> and vfs.zfs.prefetch_disable=0, no difference. >> >> I also tested to read the raw partition : >> >> [root@cc /usr/ports]# dd if=/dev/ada0s3 of=/dev/null bs=4096 conv=noerror >> 103746636+0 records in >> 103746636+0 records out >> 424946221056 bytes transferred in 13226.346738 secs (32128768 bytes/sec) >> [root@cc /usr/ports]# >> >> Disk is brand new, looks ok, either my setup is not good or there is >> a bug somewhere; I can play around with this box for some more time, >> please feel free to provide me with some hints what to do to be useful >> for you. >> >> Best, >> >> Arno >> >> >> "Arno J. Klaassen" writes: >> >> > Hello, >> > >> > >> > I finally decided to 'play' a bit with ZFS on a notebook, some years >> > old, but I installed a brand new disk and memtest passes OK. >> > >> > I installed base+ports on partition 2, using 'classical' UFS. >> > >> > I crypted partition 3 and created a single zpool on it containing >> > 4 Z-"file-systems" : >> > >> > [root@cc ~]# zfs list >> > NAME USED AVAIL REFER MOUNTPOINT >> > zfiles 10.7G 377G 152K /zfiles >> > zfiles/home 10.6G 377G 119M /zfiles/home >> > zfiles/home/arno 10.5G 377G 2.35G /zfiles/home/arno >> > zfiles/home/arno/.priv 192K 377G 192K /zfiles/home/arno/.priv >> > zfiles/home/arno/.scito 8.18G 377G 8.18G /zfiles/home/arno/.scito >> > >> > >> > I export the ZFS's via nfs and rsynced on the other machine some backup >> > of my current note-book (geli + UFS, (almost) same 9-stable version, no >> > problem) to the ZFS's. >> > >> > >> > Quite fast, I see on the notebook : >> > >> > >> > [root@cc /usr/temp]# zpool status -v >> > pool: zfiles >> > state: ONLINE >> > status: One or more devices has experienced an error resulting in data >> > corruption. Applications may be affected. >> > action: Restore the file in question if possible. Otherwise restore the >> > entire pool from backup. >> > see: http://www.sun.com/msg/ZFS-8000-8A >> > scan: scrub repaired 0 in 0h1m with 11 errors on Sat Feb 11 14:55:34 >> > 2012 >> > config: >> > >> > NAME STATE READ WRITE CKSUM >> > zfiles ONLINE 0 0 11 >> > ada0s3.eli ONLINE 0 0 23 >> > >> > errors: Permanent errors have been detected in the following files: >> > >> > /zfiles/home/arno/.scito/contrib/XNAT.tar >> > [root@cc /usr/temp]# md5 /zfiles/home/arno/.scito/contrib/XNAT.tar >> > md5: /zfiles/home/arno/.scito/contrib/XNAT.tar: Input/output error >> > [root@cc /usr/temp]# >> > >> > >> > As said, memtest is OK, nothing is logged to the console, UFS on the >> > same disk works OK (I did some tests copying and comparing random data) >> > and smartctl as well seems to trust the disk : >> > >> > SMART Self-test log structure revision number 1 >> > Num Test_Description Status Remaining LifeTime(hours) >> > # 1 Extended offline Completed without error 00% 388 >> > # 2 Short offline Completed without error 00% 387 >> > >> > >> > Am I doing something wrong and/or let me know what I could provide as >> > extra info to try to solve this (dmesg.boot at the end of this mail). >> > >> > Thanx a lot in advance, >> > >> > best, Arno >> > >> > >> > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 19:55:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1416D1065679 for ; Sat, 18 Feb 2012 19:55:11 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 481E28FC14 for ; Sat, 18 Feb 2012 19:55:09 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.3]) by msrv.matik.com.br (8.14.5/8.14.2) with ESMTP id q1IJt2Gp055047; Sat, 18 Feb 2012 17:55:03 -0200 (BRST) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1329594903; bh=iGF1o3sr4Aure+jereHkQBj+nfHmTE69PUhWbdMoE/E=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZCfYO/VkEQld7zSPikQW8bhza4oS5iTbsLab5txlIgRd98EIMsTHafOwCTW7PzHo6 sf48ph9pE+9FwbJl1iro7syS8QPRsfTBsGKtFsy8J2wOfC43tCnRNGnDmZ6O+vy/RN GweUUdMJarskyPqx9Lo4HCxdtJPTMYmDbIupnk3k= DomainKey-Signature: a=rsa-sha1; s=default; d=hm.net.br; c=nofws; q=dns; h=authentication-results:message-id:date:from:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:content-type:content-transfer-encoding; b=ZR/wnIHffAQ5HQkZcLIumDWMF6N1vLTLRjvnSPYHRT1BRsBDP5Z0WCQBTZUCZdumy q/JLNXhJLLKjEnQu/9vQXLmmG/HQGRHUAoLPY/lfvZNrflVUIgOS0fKLmwGWD3OqLnf q2iAZ7rKJQussfVIFPPwQwsJFVMT8Ok1lQ+UVGg= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F40024E.9010609@hm.net.br> Date: Sat, 18 Feb 2012 17:55:58 -0200 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Ronald Klop References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> <4F3F8F0C.3000606@hm.net.br> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.8 required=5.0 tests=AWL, BAYES_40, J_CHICKENPOX_12, J_CHICKENPOX_63, MANGLED_SAVELE, TW_BD, TW_BF, TW_EV, TW_II, TW_KB, TW_OC, TW_PF, TW_TK,TW_XB,TW_XD,TW_XF,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=no version=3.3.2-dcmatik_hm_4.18.a X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2-dcmatik_hm_4.18.a (2011-06-06) on msrv.matik.com.br Cc: freebsd-stable@freebsd.org Subject: Re: disk access seems unitask and ant-slow 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, 18 Feb 2012 19:55:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Klop wrote: > On Sat, 18 Feb 2012 12:44:12 +0100, H wrote: > >> Hi >> >> I have 9-Stable on one partition of my SATAII disk, with kde4, to >> be sure I compiled yesterday sources world and kernel >> >> happens that any secondary task with diskaccess is so very slow >> that it is inacceptable >> >> for example, compiling firefox and then trying to open an image >> with gimp, I am sitting here for over 5 minutes and the open >> image dialog still do not show the directory content ..., same >> with dolphin or any other diskaccess >> >> I have enough cpu and ram, I go back to 8.2 and everything runs >> smooth and fast as usual, same on fedora10 partition >> >> my disk is good and found as ada, no fault anywhere >> >> system is almost sleeping CPU: 2.6% user, 0.0% nice, 3.6% >> system, 1.3% interrupt, 92.5% idle >> >> >> I would be glad to get any good hint how to change that >> >> >> >> thank's > > Please post the output of dmesg so people have some information > about your system. And /etc/sysctl.conf, /boot/loader.conf and the > output of 'mount -v' are interesting also. > > Ronald. thank's for your attention but it would not help and of course, first thing I did was disabling all custom settings, I have no setting which could influence disk access, it's a desktop ... other then loading glabel,sem,tmpfs I do not have no any fancy settings in loader.conf either please don't start on the machine, it runs fine and is ok well, for the piece what you asked for: mount -v /dev/label/root on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/label/var on /var (ufs, local, journaled soft-updates) /dev/label/usr on /usr (ufs, local, journaled soft-updates) procfs on /proc (procfs, local) linprocfs on /compat/linux/proc (linprocfs, local) dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #8: Fri Feb 17 07:00:02 BRST 2012 hmm@pop1.hm.net.br:/usr/obj/usr/src/sys/WIPMINI i386 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2611.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 1073741824 (1024 MB) avail memory = 1030991872 (983 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <042910 APIC1103> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: <042910 XSDT1103> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fec00000, fed40000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x900-0x9ff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xdfcff000-0xdfcfffff irq 21 at device 2.0 on pci0 usbus0: on ohci0 ehci0: mem 0xdfcfec00-0xdfcfecff irq 22 at device 2.1 on pci0 usbus1: EHCI version 1.0 usbus1: on ehci0 pcib1: at device 4.0 on pci0 pci1: on pcib1 ath0: mem 0xdfdf0000-0xdfdfffff irq 16 at device 6.0 on pci1 ath0: AR5413 mac 10.5 RF5413 phy 6.1 hdac0: mem 0xdfcf8000-0xdfcfbfff irq 23 at device 5.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 nfe0: port 0xc480-0xc487 mem 0xdfcfd000-0xdfcfdfff irq 20 at device 7.0 on pci0 miibus0: on nfe0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: Ethernet address: 48:5b:39:af:5e:2b atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xdfcfc000-0xdfcfcfff irq 21 at device 8.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 pcib2: at device 9.0 on pci0 pci2: on pcib2 vgapci0: port 0xd800-0xd8ff mem 0xc0000000-0xcfffffff,0xdfef0000-0xdfefffff irq 17 at device 0.0 on pci2 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Initialized radeon 1.31.0 20080613 hdac1: mem 0xdfeec000-0xdfeeffff irq 18 at device 0.1 on pci2 pcib3: at device 11.0 on pci0 pci3: on pcib3 em0: port 0xec00-0xec1f mem 0xdffe0000-0xdfffffff,0xdffc0000-0xdffdffff irq 19 at device 0.0 on pci3 em0: Using an MSI interrupt em0: Ethernet address: 00:1b:21:14:6c:05 pcib4: at device 12.0 on pci0 pci4: on pcib4 acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 aibs0: on acpi0 aibs0: V0: 0x06020000 Vcore Voltage 850 / 1600 0x1 aibs0: V1: 0x06020001 +3.3 Voltage 2970 / 3630 0x1 aibs0: V2: 0x06020002 +5 Voltage 4500 / 5500 0x1 aibs0: V3: 0x06020003 +12 Voltage 10200 / 13800 0x1 aibs0: T0: 0x06030000 CPU Temperature 600 / 950 0x10001 aibs0: T1: 0x06030001 MB Temperature 450 / 950 0x10001 aibs0: F0: 0x06040000 CPU FAN Speed 600 / 7200 0x10001 aibs0: F1: 0x06040001 CHASSIS FAN Speed 600 / 7200 0x10001 hpet0: iomem 0xfed00000-0xfed00fff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 950 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x4 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff pnpid ORM0000 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 ppc0: parallel port not found. powernow0: on cpu0 powernow1: on cpu1 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded load_dn_sched dn_sched FIFO loaded hdac0: HDA Codec #0: Realtek ALC662 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: ATI R6xx HDMI pcm2: at cad 0 nid 1 on hdac1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 305244MB (625140335 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, SMP: AP CPU #1 Launched! ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata0 bus 0 scbus0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed uhub0: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:4:0:-1: Attached to scbus4 (probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-5 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen1.3: at usbus1 umass1: on usbus1 umass1: SCSI over Bulk-Only; quirks = 0x4100 umass1:5:1:-1: Attached to scbus5 Trying to mount root from ufs:/dev/label/root [rw]... da1 at umass-sim1 bus 1 scbus5 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 7640MB (15646720 512 byte sectors: 255H 63S/T 973C) wlan0: Ethernet address: 00:19:5b:68:71:8a - -- H +55 (17)4141.2222 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9AAk4ACgkQvKVfg5xjCDwq1gCfaAZ7oTAQc5m599JdyEXmOHxL scwAnRovNHmbhuH0TqAbXXeOflHRYwN5 =J412 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sat Feb 18 22:15:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id AAA99106564A for ; Sat, 18 Feb 2012 22:15:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B21C114EE46; Sat, 18 Feb 2012 22:15:57 +0000 (UTC) Message-ID: <4F40231D.2080308@FreeBSD.org> Date: Sat, 18 Feb 2012 14:15:57 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: H References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <20120214200258.GA29641@server.vk2pj.dyndns.org> <4F3F8F0C.3000606@hm.net.br> In-Reply-To: <4F3F8F0C.3000606@hm.net.br> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: disk access seems unitask and ant-slow 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, 18 Feb 2012 22:15:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 First, please don't start a new thread by replying to an existing message and changing the subject line. That screws up threading for those of us who use threaded mail readers, and may cause your message to be ignored. On 02/18/2012 03:44, H wrote: > > Hi > > I have 9-Stable on one partition of my SATAII disk, with kde4, to be > sure I compiled yesterday sources world and kernel > > happens that any secondary task with diskaccess is so very slow that it > is inacceptable > > for example, compiling firefox and then trying to open an image with > gimp, I am sitting here for over 5 minutes and the open image dialog > still do not show the directory content ..., same with dolphin or any > other diskaccess Please try compiling a custom kernel with the 4BSD scheduler instead of SCHED_ULE and see if that helps. hth, Doug - -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPQCMdAAoJEFzGhvEaGryEoPoH/3v1oqE/sVAbBrJkV+Tz4+N/ ugaDUIjwUR+IYC1TlSx1p1pHk8qJ9u1F9FLViNeHwXGQIaH+7wb94JrT6piUalu2 yj1EAcNZmcQrC+WJIhe+9osuSaAjm83ut0d6Y4Ad4XUDT2JGs92Z/uQ7Jf9ZF6ws 2ZwXOptm7JibHuNSnTSmAyzxEH4vkp9SgnOPTmT032fOZqaFr5v76dVSiLXCSkln /atV6zngEJexQMb7chEcIY5OhT8gyHVwQN6avThMr8C7grQAnTXaHfKN/QuK2uqM AZPe3DZTggHXrabrWC10/nncDNr1/hklbrsER2rXo1rVjs7b/jQPqfYjcu9fSH0= =VR4/ -----END PGP SIGNATURE-----